Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.401  Word version:  18.4.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…

 

5.11  UE Capability Handlingp. 359

5.11.1  Generalp. 359

The UE Capability information is made up of the UE Radio Capability information and the UE Core Network Capability information.
The UE Radio Capability for Paging Information is separate from both the UE Radio Capability information and the UE Core Network Capability information. While some of the UE Radio Capability for Paging Information may be used to enhance the paging in the E-UTRAN, other E-UTRAN features are critically dependent upon it (see TS 36.300).
Up

5.11.2  UE Radio Capability Handlingp. 359

The UE Radio Capability information contains information on RATs that the UE supports (e.g. power class, frequency bands, etc). Consequently, this information can be sufficiently large (e.g. >50 octets for a UE supporting a small number of frequency bands; or multiple kilo bytes for a UE supporting many frequency bands and a large multiplicity of combinations of these frequency bands) that it is undesirable to send it across the radio interface at every transition from ECM-IDLE to ECM-CONNECTED. To avoid this radio overhead, the MME stores the UE Capability information during ECM-IDLE state and the MME shall, if it is available, send its most up-to-date UE Radio Capability information to the E-UTRAN in the S1 interface INITIAL CONTEXT SETUP REQUEST message unless the UE is performing an Attach procedure or a Tracking Area Update procedure for the "first TAU following GERAN/UTRAN Attach" or for a "UE radio capability update".
If a UE supports both NB-IoT and WB-E-UTRAN, the UE handles the UE Radio capability information as follows:
  • When the UE is camping on NB-IoT the UE provides only NB-IoT UE radio capabilities to the network.
  • When the UE is camping on WB-E-UTRAN, the UE provides UE radio capabilities including WB-E-UTRAN UE radio capabilities but not NB-IoT UE radio capabilities to the network.
In order to handle the distinct UE radio capabilities, the MME stores a separate NB-IoT specific UE Radio Capability information when the UE provides the UE Radio Capability information while camping on NB-IoT.
When the UE is camping on NB-IoT, the MME sends, if available, the NB-IoT specific UE Radio Capability information to the E-UTRAN.
When the UE is camping on WB-E-UTRAN, the MME sends, if available, UE radio capabilities including WB-E-UTRAN UE radio capabilities but not NB-IoT radio capabilities.
For a UE that supports NR as a Secondary RAT, the UE's NR radio capabilities are contained within the UE Radio Capability IE.
If the UE is performing an Attach procedure or a Tracking Area Update procedure for the "first TAU following GERAN/UTRAN Attach" or for "UE radio capability update", the MME shall delete (or mark as deleted) any UE Radio Capability information that it has stored, and, if the MME sends an S1 interface INITIAL CONTEXT SETUP REQUEST or UE RADIO CAPABILITY MATCH REQUEST message during that procedure, the MME shall not send any UE Radio Capability information to the E-UTRAN in that message. This triggers the E-UTRAN to request the UE Radio Capability from the UE and to upload it to the MME in the S1 interface UE CAPABILITY INFO INDICATION message. The size of the UE Radio Capability information may be greater than can be carried in single RRC message but less than the maximum size of messages on the S1 interface. In this case, to obtain the information that it needs the RAN should send multiple requests to the UE for different sub-sets of UE Radio Capability information (e.g. one request per RAT). Then the RAN shall combine these subsets (excluding UTRAN and NB-IoT capabilities) into a single UE Radio Capability IE and upload it to the MME in the S1 interface UE CAPABILITY INFO INDICATION message.
The MME stores the UE Radio Capability information, and includes it in further INITIAL CONTEXT SETUP REQUEST or UE RADIO CAPABILITY MATCH REQUEST messages in other cases than Attach procedure, Tracking Area Update procedure for the "first TAU following GERAN/UTRAN Attach" and "UE radio capability update" procedure.
If the UE is performing a Service Request (or other) procedure and the MME does not have UE Radio Capability information available (or it is available, but marked as "deleted"), then the MME sends an S1 interface INITIAL CONTEXT SETUP REQUEST message to the E-UTRAN without any UE Radio Capability information in it. This triggers the E-UTRAN to request the UE Radio Capability from the UE and upload it to the MME in the S1 interface UE CAPABILITY INFO INDICATION message.
When the CIoT EPS Optimisations do not apply, if the MME has not stored the UE Radio Capability information, in order to obtain UE radio capability for paging information, the MME can trigger the retrieval of the UE Radio Capability information by indicating UE Radio Capability request in DOWNLINK NAS TRANSPORT message during Attach or TAU procedure.
For the CIoT EPS Optimisations, during the Attach procedure or the Tracking Area Update procedure e.g. for the "first TAU following GERAN/UTRAN Attach", or mobility between a cell that does not broadcast SystemInformationBlockType31(-NB) and an E-UTRA cell that broadcasts SystemInformationBlockType31(-NB)), if the MME does not send an S1 interface INITIAL CONTEXT SETUP REQUEST to the E-UTRAN, the MME should obtain the UE Radio Capability information by sending either the DOWNLINK NAS TRANSPORT message indicating UE Radio Capability request or the CONNECTION ESTABLISHMENT INDICATION message without UE Radio Capability information included to the E-UTRAN. This triggers the E-UTRAN to request the UE Radio Capability from the UE and upload it to the MME in the S1 interface UE CAPABILITY INFO INDICATION message, as specified in TS 36.300. In subsequent ECM connections, if the MME does not send an S1 interface INITIAL CONTEXT SETUP REQUEST to the E-UTRAN, the MME sends the UE Radio Capability to the E-UTRAN in the CONNECTION ESTABLISHMENT INDICATION message or DOWNLINK NAS TRANSPORT message.
The UE Radio Capability is not provided directly from one CN node to another. It will be uploaded to the MME when the E-UTRAN requests the UE Radio Capability information from the UE.
During handover via the MME (both intra RAT and inter RAT), the radio capability information for the source and target 3GPP RATs (with the possible exception of UTRAN and E-UTRAN) are transferred in the "source to target transparent container". Information on additional 3GPP RATs is optionally transferred in the "source to target transparent container".
At handover, transfer of the radio capability information related to the source and/or additional RATs is beneficial as it avoids the need for the target RAT to retrieve the information from the UE prior to a subsequent inter-RAT handover. However, there may be situations where the size of the UE Radio Capability may be too large for the information on all of the UE's RATs to be carried in a single message on one or more of the network interfaces involved in the handover. Hence, the source RAN shall ensure that the size of the UE Radio Capability information does not cause the size of the "source to target transparent container" to exceed the limits that can be handled by interfaces involved in the handover (e.g. Iu interface (TS 25.413) and, following SRVCC, E interface (TS 29.002)). This may result in some radio capability information being omitted from the "source to target transparent container" at inter-RAT handover.
In the case that a source RAN node omits some radio capability information from the "source to target transparent container" at handover, the source RAN node shall ensure that any future target RAN node can detect that that radio capability information has been omitted.
Owing to issues with dynamic UTRAN security parameters, special rules apply to the handling of the UTRAN radio capability information at inter-RAT handover (see e.g. the HandoverPreparationInformation message description in TS 36.331 and the usage of the PS Handover Complete Ack message in TS 43.129 and TS 48.018)
To allow for the addition of future radio technologies, frequency bands, and other enhancements, the MME shall store the UE Radio Capability Information as defined in TS 23.008.
The E-UTRAN stores the UE Radio Capability information, received in the S1 interface INITIAL CONTEXT SETUP REQUEST message or obtained from the UE, for the duration of the RRC connection for that UE. Before any handover attempt from E-UTRAN to UTRAN, the E-UTRAN retrieves the UE's UTRAN Radio Capabilities from the UE.
If the UE's non-UTRAN UE Radio Capability information changes while in ECM-IDLE state (including cases of being in GERAN/UTRAN coverage), the UE shall perform a Tracking Area Update indicating "UE radio capability update" when it next returns to E-UTRAN coverage. When the UE is in ECM-IDLE with AS information stored (as defined in clause 4.11 for User Plane CIOT EPS optimisation), NAS shall trigger AS to establish a new RRC connection and not resume the existing one in order to send Tracking Area Update indicating "UE radio capability update". As a result of this, the access stratum in the UE will discard the AS information and establish a new RRC connection as defined in TS 36.331.
The UE shall perform a Tracking Area Update procedure at every change between a cell that does not broadcast SystemInformationBlockType31(-NB) and an E-UTRA cell that broadcasts SystemInformationBlockType31(-NB). This Tracking Area Update shall indicate that the Tracking Area Update is for a "UE radio capability update".
The MME may also request for Voice Support Match Information. If requested, the eNodeB then derives and provides an indication to the MME whether the UE radio capabilities are compatible with the network configuration (e.g. whether the UE supports the frequency bands that the network may rely upon for providing "full" PS voice coverage or whether the UE supports the SRVCC configuration of the network e.g. E-UTRAN to GERAN) as defined in clause 5.3.14.
The signalling of the UE Radio Access Capabilities described in this clause can be optimised by means of the RACS feature defined in clause 5.11.3a.
Up

5.11.3  UE Core Network Capabilityp. 361

The UE Core Network Capability is split into the UE Network Capability IE (mostly for E-UTRAN access related core network parameters) and the MS Network Capability IE (mostly for UTRAN/GERAN access related core network parameters) and contains capabilities, e.g. for CIoT, NAS/AS security algorithms (that also indicate support for EPS-UPIP), etc. Both the UE Network Capability and the MS Network Capability are transferred between CN nodes at MME to MME, MME to SGSN, SGSN to SGSN, and SGSN to MME changes.
In order to ensure that the UE Core Network Capability information stored in the MME is up to date (e.g. to handle the situation when the USIM is moved into a different device while out of coverage, and the old device did not send the Detach message; and the cases of inter-RAT Tracking Area Update), the UE shall send the UE Core Network Capability information to the MME during the Attach and non-periodic Tracking Area Update procedure within the NAS message.
The MME shall store always the latest UE Core Network Capability received from the UE. Any UE Core Network Capability that an MME receives from an old MME/SGSN is replaced when the UE provides the UE Core Network Capability with Attach and the Tracking Area Update signalling. The MME shall remove the stored MS Network Capability, if MS Network Capability is not included in Attach or non-periodic Tracking Area Update signalling e.g. UE is only capable of E-UTRAN.
If the UE's UE Core Network Capability information changes (in either ECM-CONNECTED or in ECM-IDLE state (including cases of being in GERAN/UTRAN coverage and having ISR activated)), the UE shall perform a Tracking Area Update ('type' different to 'periodic') when it next returns to E-UTRAN coverage - see clause 5.3.3.0.
If the UE supports multiple user plane radio bearers on the NB-IoT RAT (see TS 36.306, TS 36.331), then the UE shall indicate this in the UE Network Capability IE.
If the UE supports, the RACS feature defined in clause 5.11.3a, and in this specification for the impact on the EPS procedures, then the UE shall indicate this in the UE Network Capability IE.
If the UE supports dual connectivity with NR (see clause 4.3.2a), then the UE shall indicate its support in a NAS indicator.
If the UE supports Service Gap Control (see clause 4.3.17.9), then the UE shall indicate this in the UE Network Capability IE.
If a UE operating two or more USIMs, supports and intends to use one or more Multi-USIM features (see clause 4.3.33) in a PLMN, it shall indicate in the UE Core Network Capability for this USIM in this PLMN that it supports these one or more Multi-USIM features, i.e. by means of one or more of the Connection Release Supported, Paging Cause Indication for Voice Service Supported, Reject Paging Request Supported, Paging Timing Collision Control Supported, and Paging Restriction Supported. Otherwise, the UE with the capabilities of Multi-USIM features shall indicate these one or more Multi-USIM features are not supported.
A UE not operating two or more USIMs shall indicate the Multi-USIM features are not supported.
If the UE supports Enhanced support of discontinuous network coverage for satellite access (see clause 4.3.18.1), then the UE shall indicate this in the UE Network Capability IE.
To allow for the addition of future features, the MME shall store the UE Network Capability and the MS Network Capability even if either or both is larger than specified in TS 24.008/TS 24.301, up to a maximum size of 32 octets for each IE.
Up

5.11.3a  UE Radio Capability Signalling optimization |R16|p. 362

With the increase of the size of UE radio capabilities driven e.g. by additional frequency bands and combinations thereof for E-UTRA and NR, an efficient approach to signal UE Radio Access Capability information over the radio interface and other network interfaces is defined with RACS.
In this Release of the specification, RACS does not apply to NB-IOT (terrestrial or satellite).
RACS works by assigning an identifier to represent a set of UE radio capabilities. This identifier is called UE Radio Capability ID. A UE Radio Capability ID can be either UE manufacturer-assigned or PLMN-assigned, as specified in clause 5.2.7. The UE Radio Capability ID is an alternative to the signalling of the UE Radio Capability information over the radio interface, within E-UTRAN, from E-UTRAN to NG-RAN, from MME to E-UTRAN and between CN nodes supporting RACS.
The UCMF (UE radio Capability Management Function) stores all UE Radio Capability ID mappings in a PLMN and is responsible for assigning every PLMN-assigned UE Radio Capability ID in this PLMN, see clause 4.4.13. The UCMF shall be configured with a Version ID for PLMN assigned UE Radio Capability IDs, defined in clause 4.4.13.
The UCMF stores the UE Radio Capability IDs alongside the UE Radio Capability information and the UE Radio Capability for Paging they map to. Each UE Radio Capability ID stored in the UCMF can be associated to one or both UE radio capabilities formats specified in TS 38.331 and TS 36.331. The two UE radio capabilities formats shall be identifiable by the MME and UCMF and the MME shall store the TS 36.331 format only.
An E-UTRAN which supports RACS can be configured to operate with one of two modes of operation when providing the UE radio capabilities to the MME when the E-UTRAN executes a UE Radio Capability Enquiry procedure (see TS 36.331) to retrieve UE radio capabilities from the UE.
  • Mode of operation A): The E-UTRAN provides to the MME both UE Radio Capability formats (i.e. the TS 36.331 format and TS 38.331 format). The E-UTRAN derives one of the formats using local transcoding of the other format it receives from the UE and extracts the E-UTRAN UE Radio Capability for Paging and NR UE Radio Capability for Paging from the UE Radio capabilities.
  • Mode of operation B): The E-UTRAN provides to the MME the TS 36.331 format only.
In a PLMN supporting RACS only in EPS, Mode of Operation B shall be configured.
If the PLMN supports RACS in both EPS and 5GS:
  • If RAN nodes in the EPS and 5GS are configured in Mode of operation B, then the UCMF shall be capable to transcode between TS 38.331 and TS 36.331 formats. The UCMF shall be able to generate the RAT-specific UE Radio Capability for Paging information from the UE Radio capabilities.
  • If E-UTRAN is configured to operate according to Mode A, then also the NG-RAN shall be configured to operate according to mode A and the UMCF is not required to transcode between TS 38.331 and TS 36.331 formats. The MME shall provide the UCMF with the UE Radio Capability for Paging information.
When the E-UTRAN updates the MME with new UE radio capabilities information, the MME provides the information obtained from the E-UTRAN to the UCMF even if the MME already stores a UE Radio Capability ID for the UE. The UCMF then returns a value of UE Radio Capability ID. If the value is different from the one stored in the MME, the MME updates the UE Radio Capability ID it stores and provides this new value to the E-UTRAN (if applicable) and to the UE.
PLMN-assigned UE Radio Capability ID is assigned to the UE using the GUTI Reallocation procedure, Attach Accept or TAU Accept as defined in present specification. In order to be able to interpret the UE Radio Capability ID a network entity or node may store a local copy of the mapping between the UE Radio Capability ID and its corresponding UE Radio Capability information i.e. a dictionary entry. When no mapping is available between a UE Radio Capability ID and the corresponding UE Radio Capability information in a network entity or node, this network entity or node shall be able to retrieve it and store it.
  • An MME which supports RACS shall store such UE Radio Capability ID mapping at least for all the UEs that it serves that have a UE Radio Capability ID assigned.
  • The E-UTRAN performs local caching of the UE Radio Capability information for the UE Radio Capability IDs for the UEs it is serving, and potentially for other UE Radio Capability IDs according to suitable local policies.
  • When the E-UTRAN needs to retrieve the mapping of a UE Radio Capability ID to the corresponding UE Radio Capability information, it queries the MME using S1 signalling defined in TS 36.413.
  • When the MME needs to get the UE Radio Capability Information and the UE Radio Capability for Paging associated to a UE Radio Capability ID it provides the UE Radio capability ID to the UCMF with an indication that it is requesting the TS 36.331 format, and the UCMF returns a mapping of the UE Radio Capability ID to the corresponding UE Radio Capability information in TS 36.331 format to the MME along with the E-UTRAN UE Radio Capability for Paging.
  • When the MME needs to obtain a PLMN assigned UE Radio Capability ID for a UE from the UCMF, it provides the UE Capability information it has for the current radio configuration of the UE and the IMEI/TAC for the UE. The MME shall provide to the UCMF the UE Radio Capability information (and at least in Mode A, the UE Radio Capability for Paging) obtained from the E-UTRAN in one or both the TS 38.331 and TS 36.331 formats depending on how the RAN is configured. The UCMF stores the association of IMEI/TAC with this UE Radio Capability ID and the UE Radio Capability information and the UE Radio Capability for Paging in all the formats it receives. The UE Radio Capability information formats the MME provides shall be identifiable at the UCMF.
  • UEs, MMEs and RAN nodes which support RACS learn the current value of the Version ID when a new PLMN assigned UE Radio Capability ID is received from the UCMF and the Version ID it contains is different from the ones in their PLMN assigned UE Radio Capability ID cache. For a PLMN, PLMN assigned UE Radio Capability IDs related to old values (i.e. not current value) of the Version ID can be removed from cache but, if so, prior to removing any cached PLMN-assigned UE radio Capability IDs with the current value of the Version ID. The MME, RAN and UE may still continue to use the stored PLMN assigned UE Radio Capability IDs with old values of the Version ID, until these are purged from cache. If an out of date PLMN assigned UE Radio Capability ID is removed from an MME cache, the MME shall proceed to assign a new PLMN assigned UE Radio Capability ID to all the UEs for which the UE context includes the removed PLMN-assigned UE Radio Capability ID, using the GUTI Reallocation procedure, or when these UEs perform a Tracking Area Update. If the MME attempts to resolve a PLMN assigned UE Radio capability ID with an old Version ID, the UCMF shall return an error code indicating that this Version ID is no longer current.
  • If at any time the MME has neither a valid UE Radio Capability ID nor any stored UE radio capabilities for the UE, the MME may trigger the RAN to provide the UE Radio Capability information and subsequently request the UCMF to allocate a UE Radio Capability ID.
  • The RAN, in order to support MOCN network sharing scenarios, shall be capable to cache PLMN assigned UE Radio Capability IDs per PLMN ID.
A network may utilise the PLMN-assigned UE Radio Capability ID, without involving the UE, e.g. for use with legacy UEs.
Mutual detection of the support of the RACS feature happens between directly connected E-UTRAN nodes and between E-UTRAN and MME using protocol means as defined in TS 36.413 and TS 36.423. To allow for a mix of RACS-supporting and non-RACS-supporting RAN nodes over the X2 interfaces, the UE Radio Capability ID should be included in the Path Switch signalling during X2 based handover and Handover Request during S1 based handover between MME and E-UTRAN. In addition, RACS-supporting RAN nodes can be discovered across inter-CN node boundaries during S1 handover using the "RACS Indication" in "Target eNB to Source eNB Transparent Container" within the HANDOVER REQUEST ACKNOWLEDGE message to indicate that that target eNodeB is able to acquire the UE radio capabilities through reception of the UE Radio Capability ID in future mobility actions, as defined in TS 36.413. The support of RACS by peer MMEs or AMFs is based on configuration in a PLMN or across PLMNs.
A UE that supports WB-EUTRA and/or NR indicates its support for RACS to MME using UE Core Network Capability as defined in clause 5.11.3.
A UE that supports RACS and is already assigned with an applicable UE Radio Capability ID in the PLMN, shall signal the UE Radio Capability ID in Attach procedure, as defined in clause 5.3.2, and Tracking Area Update procedure, as defined in clause 5.3.3 and based on triggers defined in TS 24.301. If both PLMN-assigned and UE manufacturer-assigned UE Radio Capability IDs are available in the UE and applicable in the PLMN, the UE shall signal the PLMN-assigned UE Radio Capability ID. The UE shall delete the PLMN-assigned UE Radio Capability ID(s) for the related PLMN upon receiving an indication from this PLMN.
When a PLMN decides to request a particular type of UE to use UE manufacturer-assigned UE Radio Capability ID(s):
  • The UCMF sends either a Nucmf_UECapabilityManagement_Notify or URCMP Event Notification Request message defined in TS 29.674 to the MME including either a list of UE Radio Capability IDs (if the UE was previously using any PLMN assigned IDs) or the IMEI/TAC values corresponding to UE types that are requested to use UE manufacturer-assigned UE Radio Capability ID. These values are stored in a "UE Manufacturer Assigned operation requested list" in the MME.
  • The MME uses the GUTI reallocation command message, Attach Accept message or Tracking Area Update Accept message to request the UE to delete all the PLMN-assigned UE Radio Capability ID(s) for this PLMN if the UE is, respectively, registering or is registered with PLMN assigned UE Radio Capability ID or IMEI/TAC values matching one value in the UE manufacturer-assigned operation requested list.
  • a UE that receives indication to delete the all the PLMN-assigned UE Radio Capability IDs in the Attach Accept message, Tracking Area Update Accept message or GUTI reallocation command message, deletes any PLMN-assigned UE Radio Capability IDs for this PLMN. The UE proceeds to register with a UE manufacturer-assigned UE Radio Capability ID that is applicable to the current UE Radio configuration.
  • When the "UE Manufacturer Assigned operation requested list" contains PLMN assigned UE Radio Capability IDs, the UCMF shall avoid re-assigning PLMN assigned UE Radio Capability IDs that were added to the "UE Manufacturer Assigned operation requested list" in the MMEs to any UE.
  • The MME stores a PLMN assigned ID in the UE manufacturer-assigned operation requested list for a time duration that is implementation specific, but TACs are stored until the UCMF require to remove certain TACs from the list (i.e. the list of TACs which are requested to use UE manufacturer-assigned UE Radio Capability IDs in the MME and UCMF is synchronised at all times).
  • The UCMF can request at any time the MME to remove PLMN assigned ID(s) or TAC(s) values form the UE manufacturer-assigned operation requested list.
The serving MME stores the UE Radio Capability ID for a UE in the UE context and provides this UE Radio Capability ID to E-UTRAN as part of the UE context information using S1 signalling. During inter PLMN mobility, the new MME shall delete the UE Radio Capability ID received from the old MME, unless the operator policy indicates that all UE Radio Capability IDs used in the old PLMN are also valid in the new PLMN.
The UE stores the PLMN-assigned UE Radio Capability ID in non-volatile memory when in EMM-DEREGISTERED state and can use it again when it registers in the same PLMN.
At any given time at most one UE Radio Capability ID is stored in the UE context in CN and RAN.
The number of PLMN-specific UE Radio Capability IDs that the UE stores in non-volatile memory is left up to UE implementation. However, to minimise the load (e.g. from radio signalling) on the Uu interface and to provide smoother inter-PLMN mobility (e.g. at land borders) the UE shall be able to store at least the latest 16 PLMN-assigned UE Radio Capability IDs (along with the PLMN that assigned them). This number is independent of the UE manufacturer-assigned UE Radio Capability ID(s) the UE may store.
It shall be possible for a UE to change, e.g. upon change in its usage settings, the set of UE radio capabilities in time and signal the associated UE Radio Capability ID, if available. The UE stores the mapping between the UE Radio Capability ID and the corresponding UE Radio Capability information for every UE Radio Capability ID it stores.
If the UE's Radio Capability information changes and there is no associated UE Radio Capability ID for the updated UE Radio Capability information, the UE shall perform the Tracking Area Update procedure for "UE radio capability update" as defined in clause 5.11.2.
The UE shall perform a Tracking Area Update procedure at every change between a cell that does not broadcast SystemInformationBlockType31(-NB) and an E-UTRA cell that broadcasts SystemInformationBlockType31(-NB). This Tracking Area Update shall either include the UE Radio Capability ID applicable to the new area, or, shall indicate that the Tracking Area Update is for a "UE radio capability update".
The E-UTRAN may apply RRC filtering of UE radio capabilities when it retrieves the UE Radio Capability information from the UE as defined in TS 36.331.
If a UE supports both NB-IoT and possibly other RATs the UE handles the RACS procedures as follows:
  • Since there is no support for RACS in NB-IoT, if the UE supports RACS in non-NB-IoT RATs (i.e. for WB-EUTRA and/or NR):
  • NB-IoT specific UE Radio Capability information is handled in UE, RAN and MME according to clause 5.11.2.
  • when the UE is not camping on NB-IoT, the UE provides UE radio capabilities for other RATs but not NB-IoT UE radio capabilities, according to TS 36.331. As a result the UE Radio Capability ID that is assigned by the network corresponds only to the UE radio capabilities of the non-NB-IoT RATs. The UE uses the UE Radio Capability IDs assigned only in Attach and TAU procedures performed over non-NB-IoT RATs.
Support for RACS in 5GS is defined in TS 23.501 and TS 23.502.
Up

5.11.4  UE Radio Capability for Paging Information |R12|p. 366

Depending upon the features implemented in the E-UTRAN, this procedure may assist the E-UTRAN in optimising the radio paging procedures, or this procedure can be essential for mobile terminating services to succeed.
Using procedures specified in TS 36.413, the eNodeB shall upload the UE Radio Capability for Paging Information to the MME in the S1 interface UE CAPABILITY INFO INDICATION message (in a separate IE from the UE Radio Capability). As specified in TS 36.331, the UE Radio Capability for Paging Information may contain UE Radio Paging Information provided by the UE to the eNodeB, and other information derived by the eNodeB (e.g. band support information) from the UE Radio Capability information.
The UE Radio Capability for Paging Information for NB-IoT and WB-E-UTRAN are separately stored in the MME. The RAT Type (derived from the UE's Tracking Area Code) is used to determine which RAT the information relates to.
The handling of the UE Radio Capability for Paging Information with RACS is described in clause 5.11.3a.
If a UE supports both NB-IoT and WB-E-UTRAN, the UE and eNodeB handle the UE Radio Capability for Paging Information as follows:
  • when the UE is camping on NB-IoT the UE provides only NB-IoT information to the network;
  • when the UE is camping on WB-E-UTRAN, the UE provides only WB-E-UTRAN information to the network.
Typically, this information is sent to the MME at the same time as the eNodeB uploads the UE Radio Capability information. The MME stores the UE Radio Capability for Paging Information in the MME context. When it needs to page, the MME provides the UE Radio Capability for Paging Information for that RAT to the eNodeB as part of the S1 paging message. The eNodeB may use the UE Radio Capability for Paging Information to enhance the paging towards the UE and/or to calculate when or how to broadcast paging information or the Wake Up Signal to the UE, see TS 36.304.
If the UE is performing an Attach procedure or a Tracking Area Update procedure for the "first TAU following GERAN/UTRAN/ Attach" or for "UE radio capability update", the MME shall delete all UE Radio Capability for Paging Information that it has stored for that UE.
If the UE Radio Capability for Paging Information changes for either RAT, the UE shall follow the same procedures as if the UE Radio Capability changes.
During a change of MME, the old MME includes in the MM context in the Context Response message the UE Radio Capability for Paging of the UE if available. If the RAT type is indicated by the new MME, then the old MME includes the UE Radio Capability for Paging for the corresponding RAT type, if available.
In order to handle the situations of connected mode inter-MME change, the UE Radio Capability for Paging Information is sent to the target MME as part of the MM Context information.
The UE Radio Capability for Paging Information is only applicable for MMEs, i.e. it is not applicable for SGSNs. Therefore, it will not be included by MME during context transfers towards SGSNs.
Up

5.11.5  UE Radio Capability for Category M Differentiation |R15|p. 367

This functionality is used by the Core Network to be able to identify traffic to/from Category M UEs for charging differentiation.
The eNodeB determines whether a UE is of Category M from the UE's radio capability if UE signals one or more of the specific Category M. The eNodeB then indicates to the MME whether the UE is Category M using the "LTE-M Indication" information in S1-AP message(s) used to upload the UE Radio Capabilities to the MME.
Typically this is at the same time as the eNodeB uploads the UE Radio Capability information. When the UE is of Category M, the MME receives one "LTE-M Indication" from eNB irrespective of whether the UE supports terrestrial WB-E-UTRAN or satellite WB-E-UTRAN or both and irrespective of whether the UE Radio Capability information of the UE is retrieved from terrestrial or satellite access eNB. The MME stores the "LTE-M Indication" in the MME context.
If the UE context in MME contains the "LTE-M Indication" the MME indicates to the S-GW that the RAT type of the UE is one of the LTE-M RAT types in every Create Session Request message and every Modify Bearer Request message, so this is handled for charging and PCC purposes. The MME additionally takes into account whether the UE is accessing over terrestrial WB-E-UTRAN or satellite WB-E-UTRAN when determine the LTE-M RAT type. If the MME requests the SGW to pass LTE-M RAT type to the PDN-GW, based on operator policy (e.g. based on roaming agreements or based on the need to pass the LTE-M RAT type information to PGW also), the MME informs the Serving-GW that it is requested to relay the LTE-M RAT type to the PGW also. Otherwise, the Serving-GW indicates WB-E-UTRAN RAT type to the PDN-GW.
In order to handle the situations of inter-MME change, the "LTE-M Indication" is sent from the source MME to the target MME as part of the MM Context information. The UE Radio Capability for Category M Differentiation is only applicable for MMEs, i.e. it is not applicable for SGSNs. Therefore, it will not be included during context transfers from and towards SGSNs.
Up

5.12  Warning message deliveryp. 367

5.12.1  Generalp. 367

Warning message delivery is similar to Cell Broadcast Service defined in TS 23.041, it permits a number of unacknowledged Warning messages to be broadcast to UEs within a particular area.
The maximum size of the Warning message for E-UTRAN is different from that of UTRAN/GERAN.
When S1-flex is used, the eNodeB may receive duplicated Warning messages.
For details on the Warning system message delivery, see TS 23.041.
Up

5.12.2Void

5.12.3Void

5.13  Discontinuous Reception and UE Specific DRX Parameter handlingp. 368

During the Attach and Tracking/Routing Area Update procedures in E-UTRAN, UTRAN and/or GERAN, the UE can signal its UE Specific DRX Parameters to the Core Network (MME in the E-UTRAN case and SGSN in UTRAN/GERAN case).
In E-UTRAN and UTRAN, the UE may signal that it wishes to use the DRX cycle length broadcast in the RAN's System Information. Alternatively, the UE can propose a DRX cycle length separately for WB-EUTRA and NB-IoT. For NB-IoT, the cell broadcasts an indication of support of UE specific DRX for NB-IoT in that cell, and the UE can request UE specific DRX for NB-IoT during Attach and Tracking Area Update procedures irrespective of whether the cell broadcasts that support indication. The MME shall accept the value proposed by the UE for WB-E-UTRAN. For NB-IoT the MME should accept the UE requested value, but subject to operator policy the MME may change the UE requested values. The MME shall respond to the UE with the Accepted DRX parameter for NB-IoT.
In each S1 interface Page Request message, the MME shall send the UE Specific DRX Parameters for the UE's current RAT (to help determine the DRX cycle length) and information derived from the IMSI (which defines when the UE will be awake from its sleep mode). Details are specified in TS 36.304.
At MME to MME, MME to SGSN and SGSN to MME mobility, the UE Specific DRX Parameters for RATs other than NB-IoT are sent from the old CN node to the new CN node as part of the MM context information and (except for NB-IoT) should not be sent by the UE in the Tracking Area Update message.
During Attach and non-periodic Tracking Area Update procedures on NB-IoT cells, the UE shall ensure that it has provided the MME with any UE Specific DRX parameter that applies to NB-IoT and optionally UE specific DRX parameter that applies for WB-E-UTRAN.
If a CN node receives UE Specific DRX Parameters in a dedicated message from the UE (e.g. in a Tracking Area Update or Attach message), then the CN node updates any stored information with the information supplied by the UE and uses the UE provided information in preference to any information that might be received from another CN node during the same procedure.
If the UE wishes to alter its GERAN or UTRAN/WB-E-UTRAN/NB-IoT UE Specific DRX Parameters while in E-UTRAN, then it shall send a Tracking Area Update Request message to the MME containing its new UE Specific DRX Parameters. If ISR had been activated for the UE, then the UE shall deactivate ISR by setting its TIN to "GUTI" so that the UE performs a Routing Area Update when it next enters GERAN/UTRAN coverage. When the UE performs that Routing Area Update, the SGSN will receive the updated DRX parameters within the MM context information sent by the MME and hence the UE should not include them again in the Routing Area Update Request message.
If the UE wishes to alter its WB-E-UTRAN/UTRAN or GERAN DRX Parameters while in GERAN or UTRAN coverage, then the UE shall send a Routing Area Update Request message to the SGSN containing its new UE DRX Parameters. If ISR has been activated, the UE shall deactivate ISR by setting its TIN to "P-TMSI" so that the UE performs a Tracking Area Update when it next returns to E-UTRAN coverage. When the UE performs that Tracking Area Update, the MME will receive the updated DRX parameters (excluding the one for NB-IoT) within the MM context information sent by the SGSN and hence the UE should not include them again in the Tracking Area Update message.
For NB-IoT, the UE shall apply the DRX cycle broadcast in the cell by the RAN unless it has received Accepted DRX parameters for NB-IoT from the MME and the cell supports UE specific DRX for NB-IoT, in which case the UE shall apply either the DRX cycle broadcast in the cell or the Accepted DRX parameters for NB-IoT, as defined in TS 36.304.
Up

5.13a  Extended Idle mode Discontinuous Reception (DRX) |R13|p. 368

The extended idle mode DRX value range is described in TS 23.682.
A UE and the core network may negotiate the use of extended idle mode DRX as described in TS 23.682. The MME includes the extended idle mode DRX cycle length in paging message to assist the eNodeB in paging the UE
For extended idle mode DRX cycle length of 5.12s, the network should follow regular paging strategy as defined in clause 5.13
For extended idle mode DRX cycle length of 10.24s or longer, the following applies:
If the UE decides to request for extended idle mode DRX, the UE includes an extended idle mode DRX parameters information element in the attach request and/or TAU request message. The UE may also include the UE specific DRX parameters for regular idle mode DRX according to clause 5.13. The extended idle mode DRX parameters information element includes the idle mode DRX length.
The MME decides whether to accept or reject the UE request for enabling extended idle mode DRX as described in TS 23.682. If the MME accepts the extended idle mode DRX, the MME based on operator policies and, if available, the extended idle mode DRX cycle length value in the subscription data from the HSS, may also provide different values of the extended idle mode DRX parameters than what was requested by the UE. The MME taking into account the RAT specific Subscribed Paging Time Window, the UEs current RAT -NB-IOT or WB-E-UTRAN) and local policy also assigns a Paging Time Window length to be used, and provides this value to the UE during Attach/TAU procedures together with the extended idle mode DRX cycle length in extended idle mode DRX parameter. If the MME accepts the use of extended idle mode DRX, the UE shall apply extended idle mode DRX based on the received extended idle mode DRX length, the UEs current RAT -NB-IOT or WB-E-UTRAN) and RAT specific Paging Time Window length. If the UE does not receive the extended idle mode DRX parameters information element in the relevant accept message because the SGSN/MME rejected its request or because the request was received by SGSN/MME not supporting extended idle mode DRX, the UE shall apply its regular discontinuous reception as defined in clause 5.13.
When the UE has bearers for emergency bearer services, the UE and MME follow regular discontinuous reception as defined in clause 5.13 and shall not use the extended idle mode DRX. Extended idle mode DRX parameters may be negotiated while the UE has bearers for emergency bearer services. When the bearers for emergency bearer services are released, the UE and MME shall reuse the negotiated extended idle mode DRX parameters in the last TAU/Attach procedure.
When the UE is attached for RLOS services, the UE and the MME follow regular discontinuous reception as defined in clause 5.13 and shall not use the extended idle mode DRX.
The UE shall include the extended idle mode DRX parameters information element in each TAU message if it still wants to use extended idle mode DRX. At MME to MME, MME to SGSN and SGSN to MME mobility, the extended idle mode DRX parameters are not sent from the old CN node to the new CN node as part of the MM context information.
If extended idle mode DRX is enabled, the MME handles paging as defined in TS 23.682.
If the MME is requested to monitor Reachability for Data and the UE is about to become reachable for paging, the MME sends a Monitoring Report message to the address that was indicated in the related Monitoring Request as described in TS 23.682.
Up

5.14  Configuration Transfer procedurep. 369

The purpose of the Configuration Transfer is to enable the transfer of information between two eNodeBs at any time via S1 interface and the Core Network. An example of application is to exchange the eNodeBs IP addresses in order to be able to use X2 interface between the eNodeBs for Self-Optimised Networks (SON), as specified in TS 36.413.

5.14.1  Architecture Principles for Configuration Transferp. 370

Configuration Transfer between two eNodeBs follows the principles used by RAN Information Management (RIM) procedures (see clause 5.15) between UTRAN, E-UTRAN and GERAN i.e. providing a generic mechanism for the exchange of arbitrary information between applications belonging to the RAN nodes. However Configuration Transfer is only used for intra- E-UTRAN information exchange whereas RIM procedures are designed for inter-RAT information exchange involving GERAN/UTRAN. Such a separate procedure allows avoiding impacts to other RAT access systems when transferred information is added or modified.
The information is transferred via the MME core network node(s). In order to make the information transparent for the Core Network, the information is included in an E-UTRAN transparent container that includes source and target eNodeB addresses, which allows the Core Network nodes to route the messages. If the information is to be transferred between a source eNodeB and a target en-gNB via a target eNodeB for Dual Connectivity with E-UTRAN as Master RAN node and NR as Secondary RAN node as defined in TS 37.340, the source eNodeB indicates the target en-gNB and may indicate the connected target eNodeB as described in TS 36.300, and the target eNode B further transfers the E-UTRAN transparent container to the en-gNB transparently. The mechanism is depicted in Figure 5.14-1. An example for such transferred information is the SON information, as specified in TS 36.413.
Reproduction of 3GPP TS 23.401, Fig. 5.14-1: inter E-UTRAN Configuration Transfer basic network architecture
Up
The E-UTRAN transparent containers are transferred from the source E-UTRAN node to the destination E-UTRAN node by use of Configuration Transfer messages.
An eNodeB Configuration Transfer message is used from the eNodeB to the MME over S1 interface, a MME Configuration Transfer message is used from the MME to the eNodeB over S1 interface, and a Configuration Transfer Tunnel message is used to tunnel the E-UTRAN transparent container from a source MME to a target MME over the S10 interface.
Each Configuration Transfer message carrying the E-UTRAN transparent container is routed and relayed independently by the core network node(s). Any relation between messages is transparent for the MME, i.e. a request/response exchange between applications, for example SON applications, is routed and relayed as two independent messages by the MME. An MME supporting the Configuration Transfer procedures provides addressing, routing and relaying functions.
Up

5.14.2  Addressing, routing and relayingp. 371

5.14.2.1  Addressingp. 371

All the Configuration Transfer messages contain the addresses of the source and destination RAN nodes. An eNodeB is addressed by the Target eNodeB Identifier. For Dual Connectivity with E-UTRAN as Master RAN node and NR as Secondary RAN node as defined in TS 37.340, the destination RAN node includes the candidate en-gNB Identifier and may include a target eNodeB Identifier for the target eNodeB which is X2 connected to the candidate en-gNB and a TAI associated with the en-gNB.
Up

5.14.2.2  Routingp. 371

The following description applies to all the Configuration Transfer messages used for the exchange of the E-UTRAN transparent container.
The source RAN node sends a message to its MME including the source and destination addresses. The MME uses the destination address to route the message encapsulated in a GTPv2 message to the correct MME via the S10 interface (see TS 29.274).
The MME connected to the target eNodeB decides which RAN node to send the message to, based on the destination address. For Dual Connectivity with E-UTRAN as Master RAN node and NR as Secondary RAN node as defined in TS 37.340, target eNodeB decides which candidate en-gNB to send the message to, based on the destination address.
Up

5.14.2.3  Relayingp. 371

The MME performs relaying between GTPv2 messages as described in TS 29.274. The MME performs relaying between S1 and S10 messages as described in TS 36.413, TS 23.501 and TS 29.274. The Target eNodeB performs relaying between S1 and X2 message as described in TS 36.413 and TS 36.423.
Up

5.14.2.4  Applications using the Configuration Transfer proceduresp. 371

The RAN node applications, which use the Configuration Transfer procedures, are fully transparent for the MME. These applications are described in RAN specifications. An example of application is the transfer of information required for Self-Optimised Networks (SON).

5.15  RAN Information Management (RIM) procedures |R9|p. 371

5.15.1  Generalp. 371

The RAN Information Management (RIM) procedures provide a generic mechanism for the exchange of arbitrary information between applications belonging to the RAN nodes. The RAN information is transferred via the MME and SGSN core network node(s). In order to make the RAN information transparent for the Core Network, the RAN information is included in a RIM container that shall not be interpreted by the Core Network nodes.
The RIM procedures are optional both in the RAN and the CN nodes. For the Gb interface the use of RIM procedures is negotiated at start/restart of the Gb link. For the Iu interface there is no negotiation of using RIM procedures or not at Iu link start/restart.
The RAN information is transferred in RIM containers from the source RAN node to the destination RAN node by use of messages. Source and destination RAN nodes can be E-UTRAN, UTRAN or GERAN. Each message carrying the RIM container is routed and relayed independently by the core network node(s). Any relation between messages is transparent for the MME/SGSN, i.e. a request/response exchange between RIM applications, for example, is routed and relayed as two independent messages by the MME/SGSN.
The interfaces which will be used are the Gb, the Iu, the S1, Gn and the S3 interfaces. The RAN information in the RIM container shall be transparent for the Core Network. An MME or SGSN supporting the RIM procedures provides addressing, routing and relaying functions.
Up

5.15.2  Addressing, routing and relayingp. 372

5.15.2.1  Addressingp. 372

All the messages used for the exchange of RAN information contain the addresses of the source and destination RAN nodes. A BSS is addressed by Routing Area Identity (RAI) + Cell Identity (CI) of one of its cells. An eNodeB is addressed by the Target eNodeB Identifier. An RNC is addressed by Global RNC-Id as defined in TS 23.003.

5.15.2.2  Routingp. 372

The following description applies to all the messages used for the exchange of RAN information.
The source RAN node sends a message to its MME or SGSN including the source and destination addresses. The SGSN/MME uses the destination address to route the message encapsulated in a GTP message to the correct MME/SGSN via the S3 or Gn interface.
The MME/SGSN connected to the destination RAN node decides which RAN node to send the message to based on the destination address.

5.15.2.3  Relayingp. 372

The SGSN performs relaying between BSSGP messages, RANAP messages and GTP messages as described in TS 48.018, TS 25.413, TS 29.060 and TS 29.274. The MME performs relaying between S1 and S3/Gn messages as described in TS 36.413 and TS 29.274 / TS 29.060.
Up

5.15.3  Applications using the RIM Proceduresp. 372

The RAN node applications, which use the RIM procedures, are fully transparent for the MME and SGSN. These applications are described in RAN specifications. An example between E-UTRAN and GERAN is the Network Assisted Cell Change described in TS 48.018, TS 25.413 and TS 36.413. An example between E-UTRAN and UTRAN is the exchange of SON related information described in TS 36.413
Up

5.16  MME-initiated procedure on UE's CSG membership change |R9|p. 372

If the UE is in ECM-CONNECTED state and connected via a CSG cell and the MME detects that the UE's CSG membership to that cell has expired, the MME shall send an S1AP UE CONTEXT MODIFICATION REQUEST message to the eNodeB which includes an indication that the CSG membership of the UE has expired. The eNodeB receiving this indication may initiate a handover to another cell. If the UE is not handed over the eNodeB should initiate the S1 release procedure with an appropriate cause. The MME initiates S1 release after a configurable time if the UE is not handed over or released by the CSG cell. If the CSG membership expires for a UE with ongoing emergency bearer service, no indication that the CSG membership of the UE has expired is sent to the eNodeB and the MME shall deactivate all non-emergency PDN connections.
If the UE is in ECM-CONNECTED state and connected via a hybrid cell and the MME detects that the UE's CSG membership to that cell has changed or expired, and the CSG Information Reporting Action indicates User CSG Information shall be reported to the P-GW then the MME shall modify the last known CSG membership and send a Change Notification message to the Serving-GW with User CSG Information to indicate the CSG membership change. The Serving-GW shall send the Change Notification message with the User CSG Information to the PDN-GW. The MME shall also send the S1AP UE CONTEXT MODIFICATION REQUEST message to the eNodeB which includes an indication of whether the UE is a CSG member. Based on this information the eNodeB may perform differentiated treatment for CSG and non-CSG members. MME shall release the impacted LIPA PDN connection if the LIPA CSG authorization data for this CSG cell is no longer valid due to UE's CSG membership changed or expired.
Up

5.17  Home eNodeB Multicast Packet Forwarding Function |R10|p. 373

A Home eNodeB L-GW should receive and process multicast group membership report messages (e.g. according to RFC 3376 / RFC 3810) sent either by the network accessed by LIPA or by the UE. Based upon these messages, the L-GW should forward multicast IP datagrams sent by the UE to the network accessed by LIPA, or from the network accessed by LIPA to the UE, as appropriate.
The UE may implement RFC 3376 or RFC 3810 to report multicast groups that the UE seeks to receive.
To make UPnP/DLNA service advertisements sent with an IP TTL=1 available to UEs that employ LIPA, a proxying function in the L-GW may be implemented, e.g. to retransmit UPnP service advertisements to UEs after changing the source address. This proxying to the UE shall not be performed if the multicast packet is transmitted with an IPv4 or IPv6 link-local source address, RFC 3927, RFC 4291.
Up

5.18  HPLMN Notification with specific indication due to MME initiated Bearer removal |R11|p. 373

When initiating a Delete Session Request procedure, the MME shall add an appropriate cause code facilitating the operator of the P-GW to take appropriate action (e.g. Alarm, O&M action by operator's management network) if needed.
Up

Up   Top   ToC