Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.401  Word version:  17.2.0

Top   Top   Up   Prev   Next
1…   4…   4.2.2…   4.3…   4.3.6…   4.3.8…   4.3.12…   4.3.16…   4.3.20…   4.3.25…   4.4…   4.6…   4.7…   5…   5.1.2…   5.3…   5.3.2…   5.3.3…   5.3.3.2   5.3.3.3…   5.3.4…   5.3.4B   5.3.5…   5.3.8   5.3.9…   5.4…   5.4.4…   5.5…   5.5.1.2   5.5.2…   5.5.2.2   5.5.2.3   5.5.2.4…   5.6…   5.7.3…   5.7A…   5.10   5.11…   5.19…   D…   D.3…   D.3.4   D.3.5   D.3.6   D.3.7   D.3.8   E   F…   J…   K…   L…   M…

 

4.3  High level functionsWord‑p. 26

4.3.1  GeneralWord‑p. 26

The following list gives the logical functions performed within this system. Several functional groupings (meta functions) are defined and each encompasses a number of individual functions:
  • Network Access Control Functions.
  • Packet Routing and Transfer Functions.
  • Mobility Management Functions.
  • Security Functions.
  • Radio Resource Management Functions.
  • Network Management Functions.

4.3.2  Network access control functionsWord‑p. 26

4.3.2.1  GeneralWord‑p. 26

Network access is the means by which a user is connected to the evolved packet core system.

4.3.2.2  Network/Access network selectionWord‑p. 26

It is the means by which a UE selects a PLMN/Access network from which to gain connectivity. The network/access network selection procedure varies for different access technologies. For 3GPP access networks, the network selection principles are described in TS 23.122. For 3GPP access networks, the access network selection procedures are described in TS 36.300, TS 43.022 and TS 25.304.
Architectural impacts stemming from support for network/access network selection procedures for non-3GPP access and between 3GPP access and non-3GPP accesses are described in TS 23.402.
Up

4.3.2.3  Authentication and authorisation functionWord‑p. 27

This function performs the identification and authentication of the service requester, and the validation of the service request type to ensure that the user is authorised to use the particular network services. The authentication function is performed in association with the Mobility Management functions.

4.3.2.4  Admission control functionWord‑p. 27

The purpose of admission control is to determine if the requested resources are available, and then reserve those resources.

4.3.2.5  Policy and Charging Enforcement FunctionWord‑p. 27

This includes all the functionality of PCEF as defined by TS 23.203. The PCEF encompasses service data flow detection, policy enforcement and flow based charging functionalities as defined in TS 23.203.

4.3.2.6  Lawful InterceptionWord‑p. 27

Lawful interception is the action, performed by a network operator / access provider / service provider, of making available certain information and providing that information to a law enforcement monitoring facility.

4.3.2a  Support for Dual Connectivity |R12|Word‑p. 27

Dual Connectivity involves two RAN nodes, i.e. Master and Secondary RAN nodes (see TS 36.300 for the definitions), in providing radio resources to a given UE (with active radio bearers), while a single S1-MME termination point exists for an UE between a MME and the E-UTRAN. The E-UTRAN architecture and related functions to support Dual Connectivity with E-UTRAN is further described in TS 36.300. Dual Connectivity with E-UTRAN as Master RAN node and NR as Secondary RAN node is further described in TS 37.340.
Dual connectivity defines "Master Cell Group (MCG) bearer" and "Secondary Cell Group (SCG) bearer" alternatives (see TS 36.300). For E-RABs configured as "MCG bearers" the U-plane termination points are maintained, whereas for E-RABs configured as "SCG bearers" it enables changing the U-plane termination point in the E-UTRAN by means of S1-MME signalling without changing the S1-MME termination point.
Dual Connectivity also defines a "split bearer" alternative TS 36.300. The "split bearer" in the E-UTRAN is transparent to the core network entities (e.g. MME, S-GW etc.) with the exception of the CSG membership verification by the MME when the Secondary eNodeB is a hybrid access eNodeB.
The E-UTRAN uses the per-UE information supplied by the MME and local E-UTRAN configuration data to determine whether or not to use Dual Connectivity for that UE, and, on a per EPS bearer basis the E-UTRAN decides whether to use an MCG bearer or SCG bearer, and, whether or not that bearer is a "split bearer".
If the UE has indicated support for Dual Connectivity with NR and MME has an Access Restriction for NR for a UE (either signalled from the HSS, or, locally generated by VPLMN policy in the MME) then the MME shall signal this to the E-UTRAN as part of Handover Restriction List and to the UE in Attach and TAU Accept as defined in clauses 5.5.2.2.3, 5.5.2.4.3, 5.3.2.1, 5.3.3.1, 5.3.3.2 and D.3.6 respectively. An eNodeB supporting Dual Connectivity with NR checks whether the UE is allowed to use NR. If the UE is not allowed to use NR, the eNodeB shall not establish Dual Connectivity with NR as a secondary RAT.
The MME uses "UE support for dual connectivity with NR" for SGW and PGW selection when the UE indicates support for NR and there is no Access Restriction for NR for the UE.
An E-UTRAN cell, based on operator configuration, broadcasts whether it is capable of supporting dual connectivity with locally available NR secondary cell(s).
At inter-RAT handover from NR or GERAN/UTRAN, the Access Restriction for NR is either already in the MME's UE context, or, is obtained from the HSS during the subsequent Tracking Area Update procedure (i.e. not from the source AMF/SGSN or source RAN). In both inter-RAT handover cases, any NR Access Restriction is then signalled to the E-UTRAN.
The eNodeB, at which the S1-MME terminates, performs all necessary S1-MME related functions (as specified for any serving eNodeB) such as mobility management, relaying of NAS signalling, E-RAB handling, etc. and manages the handling of user plane connection of S1-U.
Additional functional characteristics are:
  • User location information reporting is based on the identity of the cell that is serving the UE and supported by the eNodeB terminating S1-MME.
  • Path update signalling for E-RABs configured as "SCG bearers" and Serving GW relocation cannot occur at the same time.
  • During handover with dual connectivity, the requirement of forwarding "end marker" packets to target node is also applicable to secondary RAN node if it is the source node for S1-U bearer.
  • After handover with data forwarding, the E-UTRAN initiated E-RAB modification procedure of clause 5.4.7 should not be initiated by the target eNodeB before "end marker" packet is received at the target RAN node or a timer in target eNodeB expires.
  • Relaying function is not supported.
  • CSG function may be supported if the Secondary eNodeB is a hybrid access eNodeB (see more details in clause 5.4.7 and in TS 36.300).
  • When the Secondary eNodeB is a hybrid access eNodeB, the Master eNodeB may ask CSG membership verification to the MME using E-RAB Modification Indication message (for SCG bearers) or UE Context Modification Indication (for split bearers) message. The MME shall determine the CSG membership based on the CSG Membership Information as specified in TS 36.300 and shall respond to the Master eNodeB using respectively a E-RAB Modification Confirm or a UE Context Modification Confirm, but shall not update the User CSG Information in the Core Network.
  • The LIPA function may be supported for the SCG bearer alternative, in the case that the Secondary eNodeB is a HeNB with a collocated L-GW (see more details in TS 36.300).
  • "SIPTO at the Local Network with L-GW function collocated with the (H)eNB" function may be supported (see more details in TS 36.300):
    • For the MCG and split bearer alternatives, if the Master eNodeB is collocated with a L-GW; and/or
    • For the SCG bearer alternative, if the Secondary eNodeB is a (H)eNB with a collocated L-GW.
  • "SIPTO at the Local Network with stand-alone GW" function may be supported for the MCG, SCG, and split bearer alternatives if the Master and Secondary eNodeBs belong to the same LHN (see more detail in TS 36.300).
Up

4.3.3  Packet routing and transfer functionsWord‑p. 29

4.3.3.1  GeneralWord‑p. 29

A route is an ordered list of nodes used for the transfer of packets within and between the PLMN(s). Each route consists of the originating node, zero or more relay nodes and the destination node. Routing is the process of determining and using, in accordance with a set of rules, the route for transmission of a message within and between the PLMN(s).
The EPS is an IP network and uses the standard routing and transport mechanisms of the underlying IP network.
The Maximum Transfer Unit (MTU) size considerations in clause 9.3 of TS 23.060 are also applicable to EPS.
Up

4.3.3.2  IP header compression functionWord‑p. 29

The IP header compression function optimises use of radio capacity by IP header compression mechanisms.
When Control Plane CIoT EPS Optimisation is supported for PDN connections of IP PDN Type, if the IP header compression based on ROHC framework RFC 5795 is implemented in the MME and the UE, the ROHC profiles defined in TS 36.323 may be supported.

4.3.3.3  Packet screening functionWord‑p. 29

The packet screening function provides the network with the capability to check that the UE is using the exact IPv4-Address and/or IPv6-Prefix that was assigned to the UE.

4.3.3.4  IP Multicast Forwarding between a network accessed by LIPA and a UE |R10|Word‑p. 29

The Home eNodeB L-GW should support IP forwarding of packets to multicast groups between the UE and the network accessed by LIPA.

4.3.4  Security functionsWord‑p. 29

The security functions are described in clause 5.3.10.

4.3.5  Mobility management functionsWord‑p. 29

4.3.5.1  GeneralWord‑p. 29

The mobility management functions are used to keep track of the current location of a UE.
Intra-RAT mobility for NB-IoT UEs is supported.
Inter-RAT idle mode mobility between NB-IoT and WB-EUTRAN/UTRAN/GERAN is supported. Tracking area list management as defined in clause 4.3.5.3 is required to ensure that at inter-RAT mobility, the UE performs a TAU or RAU procedure.

4.3.5.2  Reachability Management for UE in ECM-IDLE stateWord‑p. 29

The location of a UE in ECM-IDLE state is known by the network on a Tracking Area List granularity. All cells of the Tracking Areas in which a UE in ECM-IDLE is currently registered needs to be taken into account for paging. The UE may be registered in multiple Tracking Areas. All the tracking areas in a Tracking Area List to which a UE is registered are served by the same serving MME.
An EMM-REGISTERED UE performs periodic Tracking Area Updates with the network after the expiry of the periodic TAU timer.
The MME may allocate long periodic TAU timer value to the UE according to clause 4.3.17.3.
If the UE is out of E-UTRAN coverage (including the cases when the UE is camped on GERAN/UTRAN cells) when its periodic TAU timer expires, the UE shall:
  • if ISR is activated, start the E-UTRAN Deactivate ISR timer. After the E-UTRAN Deactivate ISR timer expires the UE shall deactivate ISR by setting its TIN to "P-TMSI".
  • if ISR is activated and the UE is camping on a GERAN/UTRAN cell (or returns to coverage in GERAN/UTRAN) and the UE is EPS/IMSI attached, perform a LAU procedure in NMO II or a combined RA/LA update procedure in NMO I.
  • when EMM-REGISTERED, perform a Tracking Area Update when it next returns to E-UTRAN coverage.
If the UE is camped on an E-UTRAN cell or is in ECM-CONNECTED state when the UE's periodic RAU timer expires, the UE shall:
  • if ISR is activated, start the GERAN/UTRAN Deactivate ISR timer. After the GERAN/UTRAN Deactivate ISR timer expires the UE shall deactivate ISR by setting its TIN to "GUTI".
  • perform a Routing Area Update when it next returns to GERAN/UTRAN coverage.
If the UE is EPS attached only and either camps on an E UTRAN cell or is in ECM CONNECTED state when the UE's periodic LAU timer expires, the UE shall perform a Location Area Update procedure in NMO II or combined RA/LA update in NMO I when it next returns to GERAN/UTRAN coverage.
The E-UTRAN Deactivate ISR timer is stopped when the UE performs a successful Tracking Area Update or combined TA/LA Update; and the GERAN/UTRAN Deactivate ISR timer is stopped when the UE performs a successful Routing Area Update or combined RA/LA Update.
Expiry of the periodic TAU timer, or, the periodic RAU timer, or, the periodic LAU timer shall not cause the UE to change RAT.
The UE's periodic TAU timer is restarted from its initial value whenever the UE enters ECM-IDLE mode and when the UE leaves the E-UTRAN connection due to handover to GERAN/UTRAN. UTRAN RRC state transitions and GERAN GPRS STANDBY/READY state transitions shall have no other impact on the periodic TAU timer.
E-UTRAN RRC state transitions shall have no impact on the periodic RAU timer or periodic LAU timer except that handover from GERAN/UTRAN to E-UTRAN shall cause the periodic RAU timer to be started from its initial value.
Handover from E-UTRAN to UTRAN/GERAN shall cause the periodic TAU timer to be started from its initial value.
Typically, the MME runs a mobile reachable timer. Whenever the UE enters ECM IDLE mode the timer is started with a value similar to the UE's periodic TAU timer. If this timer expires in the MME, the MME can deduce that the UE is not reachable. However, the MME does not know for how long the UE is not reachable, so, the MME shall not immediately delete the UE's bearers. Instead the MME should clear the PPF flag in the MME and start an Implicit Detach timer, with a relatively large value and if ISR is activated, at least slightly larger than the UE's E-UTRAN Deactivate ISR timer.
If MME has allocated an Active Time to the UE, then the MME starts the Active timer with the value of Active Time whenever the UE enters ECM IDLE mode. If this timer expires in the MME, the MME can deduce that the UE is not reachable and should clear the PPF flag in the MME.
With the PPF clear, the MME does not page the UE in E-UTRAN coverage and shall send a Downlink Data Notification Reject message to the Serving GW when receiving a Downlink Data Notification message from the Serving GW. If the Implicit Detach timer expires before the UE contacts the network, then the MME can deduce that the UE has been 'out of coverage' for a long period of time and implicitly detach the UE as described in clause 5.3.8.3 "MME-initiated Detach procedure".
If the MME is requested to monitor Reachability for Data and the UE enters ECM-CONNECTED, the MME sends a Monitoring Report message to the address that was indicated in the related Monitoring Request as described in TS 23.682.
When the MME applies General NAS level Mobility Management Congestion Control to a UE, the MME may need to adjust the mobile reachable timer and/or Implicit Detach timer (as clause 4.3.7.4.2.4).
Up

4.3.5.3  Tracking Area list managementWord‑p. 31

Tracking Area list management comprises the functions to allocate and reallocate a Tracking Area Identity list to the UE. All the tracking areas in a Tracking Area List to which a UE is registered are served by the same serving MME.
The "tracking area list concept" is used with E-UTRAN. With this concept, when the UE registers with the network, the MME allocates a set (a "list") of tracking areas to the UE. By making the centre of this set of tracking areas close to the UE's current location, the chance of a UE rapidly making another tracking area update can be reduced.
If SIPTO at local network with stand-alone GW, Serving GW relocation without mobility and ISR are supported in the core network the Tracking Area list should only contain either Tracking Areas inside one local network or inside the macro network. If the tracking area list covers both local network and macro network, the ISR shall not be activated if the UE is allowed to use SIPTO at local network.
The MME determines the RAT type the UE is camping on, i.e. NB-IoT or WB-E-UTRAN, based on the Tracking Area indicated in the INITIAL UE MESSAGE by the eNodeB.
To ensure a UE initiates tracking area updating procedure when perfoming inter-RAT mobility between NB-IoT and WB-E-UTRAN, the E-UTRAN shall be configured such that a Tracking Area does not contain both WB-E-UTRAN and NB-IoT cells, and, the MME shall not allocate a Tracking Area Identity list that contains both NB-IoT and WB-E-UTRAN Tracking Areas.
To ensure the UE initiates tracking area update procedure when it moves to and from an MME that supports 15 EPS bearers per UE as defined in clause 4.12 to an MME that does not support 15 EPS bearers per MME and vice versa, the MME shall allocate a Tracking Area Identity list that provides homogenous support for 15 EPS bearers per UE.
Other features (e.g. User Plane CIoT EPS Optimisation, Supporting up to 15 EPS bearers per UE) may require the MME to adapt how it creates the "list" of TAIs.
Up

4.3.5.4  Inter-eNodeB mobility anchor functionWord‑p. 31

The Inter-eNodeB Mobility Anchor is the functional entity that anchors the user plane for E-UTRAN mobility.

4.3.5.5  Inter-3GPP mobility anchor functionWord‑p. 31

The Inter-3GPP Mobility Anchor is the functional entity that anchors the user plane for mobility between 3GPP 2G/3G access systems and the E-UTRA access system.

4.3.5.6  Idle mode signalling reduction functionWord‑p. 31

The Idle mode Signalling Reduction (ISR) function provides a mechanism to limit signalling during inter-RAT cell-reselection in idle mode (ECM-IDLE, PMM-IDLE, GPRS STANDBY states).
The MME/SGSN activates ISR only if the Serving GW supports the ISR. How MME/SGSN determines a Serving GW supports ISR is implementation dependent.
ISR shall be activated by decision of the CN nodes and shall be explicitly signalled to the UE as "ISR activated" in the RAU and TAU Accept messages. The UE may have valid MM parameters both from MME and from SGSN. The "Temporary Identity used in Next update" (TIN) is a parameter of the UE's MM context, which identifies the UE identity that the UE shall indicate in the next RAU Request, TAU Request or Attach Request message. The TIN also identifies the status of ISR activation in the UE.
The TIN can take one of the three values, "P-TMSI", "GUTI" or "RAT-related TMSI". The UE shall set the TIN when receiving an Attach Accept, a TAU Accept or RAU Accept message according to the rules in Table 4.3.5.6-1.
Message received by UE Current TIN value stored by UE TIN value to be set by the UE when receiving message
Attach Accept via E-UTRAN (never indicates "ISR Activated") Any valueGUTI
Attach Accept via GERAN/UTRAN (never indicates "ISR Activated") Any valueP-TMSI
TAU Accept not indicating "ISR Activated" Any valueGUTI
TAU Accept indicating "ISR Activated" GUTI P-TMSI or RAT-related TMSIGUTI RAT-related TMSI
RAU Accept not indicating "ISR Activated" Any valueP-TMSI
RAU Accept indicating "ISR Activated" P-TMSI GUTI or RAT-related TMSIP-TMSI RAT-related TMSI
 
When "ISR Activated" is indicated by the RAU/TAU Accept message but the UE shall not set the TIN to "RAT-related TMSI" is a special situation. Here the UE has deactivated ISR due to special situation handling. By maintaining the old TIN value the UE remembers to use the RAT specific TMSI indicated by the TIN when updating with the CN node of the other RAT.
Only if the TIN is set to "RAT-related TMSI" ISR behaviour is enabled for the UE, i.e. the UE can change between all registered areas and RATs without any update signalling and it listens for paging on the RAT it is camped on. If the TIN is set to "RAT-related TMSI", the UE's P-TMSI and RAI as well as its GUTI and TAI(s) shall remain registered with the network and shall remain valid in the UE.
Message to be sent by UE TIN value: P-TMSI TIN value: GUTI TIN value: RAT-related TMSI
TAU RequestGUTI mapped from P-TMSI/RAIGUTIGUTI
RAU RequestP-TMSI/RAIP-TMSI/RAI mapped from GUTIP-TMSI/RAI
Attach Request via E-UTRANGUTI mapped from P-TMSI/RAIGUTIGUTI
Attach Request via GERAN/UTRANP-TMSI/RAIP-TMSI/RAI mapped from GUTIP-TMSI/RAI
 
Table 4.3.5.6-2 shows which temporary identity the UE shall indicate in a Tracking or Routing Area Update Request or in an Attach Request message, when the UE stores these as valid parameters.
Situations may occur that cause unsynchronized state information in the UE, MME and SGSN. Such special situations trigger a deactivation of ISR locally in the UE.
The UE shall deactivate ISR locally by setting its TIN to the temporary identity of the currently used RAT in following special situations:
  • Modification of any EPS bearer context or PDP context which was activated before the ISR is activated in the UE;
  • At the time when the UE moves from E-UTRAN to GERAN/UTRAN or moves from GERAN/UTRAN to E-UTRAN by means other than PSHO, if any EPS bearer context or PDP context activated after the ISR was activated in the UE exists;
  • At the time when the UE moves from GERAN/UTRAN to E-UTRAN by means other than PSHO and CS to PS SRVCC, if the PDP contexts were suspended in GERAN and not successfully resumed before returning to E-UTRAN;
  • After updating either MME or SGSN about the change of the UE specific DRX parameters to guarantee that the other CN node is also updated;
  • After updating either MME or SGSN about the change of the UE Core Network Capabilities to guarantee that the other CN node is also updated;
  • E-UTRAN selection by a UTRAN-connected UE (e.g. when in URA_PCH to release Iu on UTRAN side);
  • E-UTRAN selection from GERAN READY state;
  • GERAN selection by an E-UTRAN-connected UE via Cell Change Order that is not for CS fallback;
  • After a LAU procedure if the UE has CS fallback and/or SMS over SGs activated.
  • For a UE that is IMS registered for voice, then after that UE moves from a Registration Area that supports IMS voice over PS sessions (see 4.3.5.8 for more information) to one that does not, and vice versa. It shall be possible, e.g. using Device Management or initial provisioning, to configure the UE to apply/not apply this particular exception.
The UE shall deactivate ISR locally by setting its TIN to the temporary identity of the RAT that is still available to the UE in following special situations:
  • After the RAT-specific Deactivate ISR timer expires, e.g. because the coverage of that RAT is lost or the RAT is no more selected by the UE (this may result also in implicit detach by SGSN or MME).
ISR shall be deactivated in the UE by the CN node using normal update signalling, i.e. by omitting the signalling of "ISR Activated", in following special situations:
  • CN node change resulting in context transfer between the same type of CN nodes (SGSN to SGSN or MME to MME);
  • Serving GW change;
  • When the UE only has bearers related to emergency bearer service;
  • When the UE is registered for RLOS service;
  • TAU or RAU when UE moves over the border between local and macro network where SIPTO at local network with stand-alone GW and Serving GW relocation without mobility are supported in the core network.
  • TAU or RAU when the network confirms to use PSM for the UE.
If tracking area list or routing area covers both local network and macro network, the ISR shall not be activated if the UE is allowed to use SIPTO at local network and Serving GW relocation without mobility are supported in the core network.
Up

4.3.5.7  Mobility RestrictionsWord‑p. 33

Mobility Restrictions comprises the functions for restrictions to mobility handling of a UE in E-UTRAN access. The Mobility Restriction functionality is provided by the UE, the radio access network and the core network.
Mobility Restriction functionality in state ECM-IDLE is executed in UE based on information received from the core network. Mobility Restriction functionality in state ECM-CONNECTED is executed in the radio network and the core network.
In state ECM-CONNECTED, the core network provides the radio network with a Handover Restriction List. The Handover Restriction List specifies roaming, area and access restrictions. If roaming restriction to GERAN or UTRAN access needs to be enforced, a MME that is connected to eNodeBs that may handover or invoke release with redirection to UTRAN or GERAN is configured with a list of HPLMN IDs that are permitted to access GERAN or UTRAN unless restricted by the UE individual access restriction information received from HSS.
Up

4.3.5.8  IMS voice over PS Session Supported IndicationWord‑p. 33

The serving PLMN shall send an indication toward the UE during the Attach procedure and Tracking Area Update procedures if an IMS voice over PS session is supported. The serving PLMN uses this indicator to indicate to the UE whether it can expect a successful IMS voice over PS session according to TS 22.173 with a bearer that supports Conversational Voice as specified in TS 23.203. A UE with "IMS voice over PS" voice capability should take this indication into account when establishing voice over PS sessions (as specified in TS 23.221) as well as when determining whether to deactivate the special handling of ISR locally (as detailed in clause 4.3.5.6).
The serving PLMN provides this indication based e.g. on local policy, HPLMN, Voice Support Match Indicator, the SRVCC capability of the network and UE and/or extends of E-UTRAN/UTRAN coverage. The serving PLMN shall indicate to the UE that the UE can expect a successful IMS voice over PS session only if the MME is configured to know that the serving PLMN has a roaming agreement for IMS voice with the HPLMN of the UE. This indication is per TAI list.
On request by the HSS, the MME shall indicate the following:
  • whether or not an IMS voice over PS Session is supported in the TA(s) that are registered for the UE ("IMS voice over PS Session Supported Indication"), together with the time of the last radio contact with the UE; and
  • the current RAT type.
Up

4.3.5.8A  Homogenous Support of IMS Voice over PS Sessions Indication |R11|Word‑p. 34

The "Homogenous Support of IMS Voice over PS Sessions" indication is provided by the MME to the HSS, and can be used by the HSS to avoid requesting the serving nodes whether or not an IMS Voice over PS session according to TS 22.173 with a bearer that supports Conversational Voice as specified in TS 23.203 is supported. This indication is stored in the MME MM context.
The MME shall behave as follows whenever it sends a Update Location Request or a Notify Request message to the HSS:
  • if "IMS Voice over PS Sessions" is supported homogeneously in all TAs in the serving MME for the UE, the MME shall include the "Homogenous Support of IMS Voice over PS Sessions" indication set to "Supported".
  • if none of the TAs of the serving MME supports "IMS Voice over PS Sessions" for the UE, the MME shall include the "Homogenous Support of IMS Voice over PS Sessions" indication set to "Not supported".
  • if "IMS Voice over PS Sessions" support is either non-homogeneous or unknown, the MME shall not include the "Homogenous Support of IMS Voice over PS Sessions" indication.
Regarding homogenous support/non-support of IMS Voice over PS session for all registered TAs of the UE, see clause 4.3.5.8.
Up

4.3.5.9  Voice domain preference and UE's usage setting |R9|Word‑p. 34

If the UE supports CS fallback, or the UE is configured to support IMS voice, or both, the UE shall include the information element "Voice domain preference and UE's usage setting" in Attach Request, Tracking Area Update Request and Routing Area Update Request messages. The purpose of this information element is to signal to the network the UE's usage setting and voice domain preference for E-UTRAN. The UE's usage setting indicates whether the UE behaves in a voice centric or data centric way (as defined in TS 23.221). The voice domain preference for E-UTRAN indicates whether the UE is configured as CS Voice only, CS Voice preferred and IMS PS Voice as secondary, IMS PS Voice preferred and CS Voice as secondary, or IMS PS Voice only (as defined in TS 23.221).
In this Release of the specifications, inter-RAT mobility to/from the NB-IoT RAT is not supported, and GBR bearers are not supported in the NB-IoT RAT. Hence the UE should not include the "Voice domain preference and UE's usage setting" IE when sending an Attach Request or Tracking Area Update Request on the NB-IoT RAT.
Up

4.3.5.10  Preferred and Supported Network Behaviour |R13|Word‑p. 35

A UE includes in a Preferred Network Behaviour indication the Network Behaviour the UE can support and what it would prefer to use.
The Preferred Network Behaviour includes this information:
  • Whether Control Plane CIoT EPS Optimisation is supported.
  • Whether User Plane CIoT EPS Optimisation is supported.
  • Whether Control Plane CIoT EPS Optimisation is preferred or whether User Plane Plane CIoT EPS Optimisation is preferred.
  • Whether S1-U data transfer is supported.
  • Whether SMS transfer without Combined Attach is requested.
  • Whether Attach without PDN Connectivity is supported.
  • Whether header compression for Control Plane CIoT EPS Optimisation is supported.
If SMS transfer without Combined EPS Attach is requested by the UE, a supporting MME provides SMS transfer without the UE performing the combined EPS attach specified in TS 23.272. An MME connected to NB-IoT should support SMS transfer without the UE being required to perform a Combined Attach.This feature is only available to UEs that only support NB-IoT.
If S1-U data transfer is supported is indicated by the UE, the UE supports data transfer that is not subject to CIoT EPS Optimisations. If the UE indicates support of User Plane CIoT EPS Optimisation then it shall also indicate support of S1-U data transfer.
If Attach without PDN connection is supported, the UE need not establish a PDN connection as part of the Attach procedure and the UE and MME may at any time release all the PDN connections and remain EPS attached.
The MME indicates the network behaviour the network accepts in the Supported Network Behaviour information. This indication is per TAI List. The MME may indicate one or more of the following:
  • Whether Control Plane CIoT EPS Optimisation is supported.
  • Whether User Plane CIoT EPS Optimisation is supported.
  • Whether S1-U data transfer is supported.
  • Whether SMS transfer without Combined Attach is accepted.
  • Whether Attach without PDN Connectivity is supported.
  • Whether header compression for Control Plane CIoT EPS Optimisation is supported.
If the MME indicates support of User Plane CIoT EPS Optimisation then it shall also indicate support of S1-U data transfer. If the UE and MME indicate support for User Plane CIoT EPS Optimisation, MME sets the UE User Plane CIoT Support Indicator to "supported" in S1-AP messages as defined in TS 36.413.
For NB-IoT UEs that only support Control Plane CIoT EPS Optimisation, the MME shall include support for Control Plane CIoT EPS Optimisation in NAS accept messages.
A UE that supports the NB-IoT shall always indicate support for Control Plane CIoT EPS Optimisation.
In a network that supports Dedicated Core Networks (see clause 5.19), the Preferred Network Behaviour indication from the UE may be used to influence policy decisions that can cause rerouting of the Attach or TAU from an MME to another MME.
Other CIoT EPS Optimisations include "Attach without PDN connection establishment"; "PDN type = non-IP"; and "UE connection to SCEF". These features are requested by implicit and explicit signalling described within the relevant clauses of this TS.
Up

Up   Top   ToC