Content for  TS 23.401  Word version:  19.0.0

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).

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.

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. In the case of satellite access for NB-IoT, if the UE supports reporting its Coarse Location Information via NAS, 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.

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.

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.

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.

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.

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.

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.

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.

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