Content for  TS 23.401  Word version:  19.0.0

A UE, camping on an E-UTRAN cell reads the related System Information Broadcast. An E-UTRAN cell for a PLMN that supports CIoT enhancements shall broadcast: For the NB-IoT case:

• Whether it can connect to an MME which supports EPS Attach without PDN Connectivity.

For the WB-E-UTRAN case:

• Whether it supports Control Plane CIoT EPS Optimisation and it can connect to an MME which supports Control Plane CIoT EPS Optimisation.
• Whether it supports User Plane CIoT EPS Optimisation and it can connect to an MME which supports User Plane CIoT EPS Optimisation.
• Whether it can connect to an MME which supports EPS Attach without PDN Connectivity.

If the PLMN does not advertise support of EPS attach without PDN connectivity and the UE can only attach without PDN connectivity, then the UE shall not attach to the PLMN in this cell and shall proceed as specified in TS 23.122. In the case of WB-E-UTRAN, if the PLMN does not support Control Plane CIoT EPS Optimisation, and the UE only supports Control Plane CIoT EPS Optimisation and cannot otherwise attach, then the UE shall not proceed with the Attach to the PLMN in this cell and shall proceed as specified in TS 23.122. An E-UTRAN cell for a PLMN that supports Restricted Local Operator Service shall broadcast:

• Whether it supports Restricted Local Operator Service.

If the PLMN does not advertise support for Restricted Local Operator Services, the UE shall not proceed with the Attach with indication that the attach is to receive Restricted Local Operator Services to the PLMN in this cell. If a Service Gap timer is running in the UE (see clause 4.3.17.9) and the Attach Type is not Emergency Attach and it is not an Attach without PDN connectivity, then the UE shall not send Attach Requests to this PLMN or any other PLMN as long as the timer is running. If the UE can proceed to attach, it initiates the Attach procedure by the transmission, to the eNodeB, of an Attach Request (IMSI or old GUTI, Old GUTI type, last visited TAI (if available), UE Core Network Capability, UE Specific DRX parameters, extended idle mode DRX parameters, UE paging probability information, Attach Type, ESM message container (Request Type, PDN Type, Protocol Configuration Options, Ciphered Options Transfer Flag, Header Compression Configuration), KSIASME, NAS sequence number, NAS-MAC, additional GUTI, P-TMSI signature, Voice domain preference and UE's usage setting, Preferred Network behaviour, MS Network Capability, Support for restriction of use of Enhanced Coverage, UE has UE Radio Capability ID assigned for the selected PLMN, Requested IMSI Offset) message together with RRC parameters indicating the Selected Network and the old GUMMEI. In the RRC connection establishment signalling associated with the Attach Request, the UE indicates its support of the CIoT EPS Optimisations, relevant for MME selection. The UE shall also include an IAB-Indication in the RRC connection establishment signalling, if the UE is an IAB-node, as defined in TS 36.331. If the UE identifies itself with the old GUTI, the UE shall set the Old GUTI Type to indicate whether the Old GUTI is a native GUTI or is mapped from a P-TMSI and RAI. The old GUTI may be derived from a P-TMSI and RAI. IMSI shall be included if the UE does not have a valid GUTI or a valid P-TMSI available, or if the UE is configured to perform Attach with IMSI at PLMN change and is accessing a new PLMN. The UE stores the TIN in detached state. If the UE's TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a valid GUTI then the old GUTI indicates this valid GUTI. If the UE's TIN indicates "P-TMSI" and the UE holds a valid P-TMSI and related RAI then these two elements are indicated as the old GUTI. Mapping a P-TMSI and RAI to a GUTI is specified in TS 23.003. If the UE holds a valid GUTI and the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, then the UE indicates the GUTI as additional GUTI. If the old GUTI indicates a GUTI mapped from a P-TMSI and RAI and the UE has a valid P-TMSI signature associated to it, the P-TMSI signature shall be included. The UE sets the voice domain preference and UE's usage setting according to its configuration, as described in clause 4.3.5.9. Alternatively, when a UE only supports E-UTRAN, if the UE has a GUTI available and the UE is accessing the same PLMN (or ePLMN), then it identifies itself with the old GUTI and sets the Old GUTI Type to 'native', otherwise the UE configuration determines whether the UE identifies itself with its IMSI or the Old GUTI. The UE includes the extended idle mode DRX parameters information element if the UE needs to enable extended idle mode DRX. The UE may include UE paging probability information if it supports the assignment of WUS Assistance Information from the MME to assist the eNodeB's Wake-Up Signal (WUS) group decision (see TS 36.300). If available, the last visited TAI shall be included in order to help the MME produce a good list of TAIs for any subsequent Attach Accept message. Selected Network indicates the PLMN that is selected for network sharing purposes. The RRC parameter "old GUMMEI" takes its value from the "old GUTI" contained in the Attach Request. UE Network Capability is described in UE capabilities, see clause 5.11. If the UE has valid security parameters, the Attach Request message shall be integrity protected by the NAS-MAC in order to allow validation of the UE by the MME. KSIASME, NAS sequence number and NAS-MAC are included if the UE has valid EPS security parameters. NAS sequence number indicates the sequential number of the NAS message. If the UE does not have a valid EPS security association, then the Attach Request message is not integrity protected. In this case the security association is established in step 5a. The UE network capabilities indicate also the supported NAS and AS security algorithms. PDN type indicates the requested IP version (IPv4, IPv4/IPv6, IPv6). For a UE that support CIoT EPS Optimisations, the PDN type may also be "Non-IP". PDN type may also indicate Ethernet. Protocol Configuration Options (PCO) are used to transfer parameters between the UE and the PDN-GW, and sent transparently through the MME and the Serving-GW. The Protocol Configuration Options may include the Address Allocation Preference indicating that the UE prefers to obtain an IPv4 address only after the default bearer activation by means of DHCPv4. If the UE intends to send PCO which require ciphering (e.g., PAP/CHAP usernames and passwords) or send an APN, or both, the UE shall set the Ciphered Options Transfer Flag and send PCO or APN or both only after authentication and NAS security setup have been completed (see below). If the UE supports 3GPP PS Data Off, it shall include in the PCO the 3GPP PS Data Off UE Status, which indicates whether the user has activated or deactivated 3GPP PS Data Off. If the UE has UTRAN or GERAN capabilities, it shall send the NRSU in the PCO to indicate the support of the network requested bearer control in UTRAN/GERAN. The UE sends the ETFTU in the PCO to indicate the support of the extended TFT filter format. Request Type is included in the ESM message container and indicates "Handover" when the UE has already an activated PDN-GW/HA due to mobility with non-3GPP accesses. If a UE indicates support of CIoT EPS Optimisations in the RRC message, it may omit the ESM message container. If the ESM message container is omitted the MME shall not establish a PDN connection as part of the Attach procedure. In this case steps 6, 12 to 16 and 23 to 26 are not executed. In addition, for the case of UEs attaching with Control Plane CIoT EPS Optimisation with no user plane establishment, steps 17 to 22 are replaced by S1 AP NAS Transport and RRC Direct Transfer messages that just transport the NAS Attach Accept and NAS Attach Complete messages. Attach Type indicates whether it is an EPS attach or a combined EPS/IMSI attach or an Emergency Attach or an RLOS Attach. Emergency Attach and RLOS Attach shall not be indicated when the UE is using NB-IoT. When using CIoT EPS Optimisations, the UE may indicate EPS attach and request SMS by setting the "SMS transfer without Combined Attach" flag in the Preferred Network Behaviour IE. If a UE includes a Preferred Network Behaviour, this defines the Network Behaviour the UE is expecting to be available in the network as defined in clause 4.3.5.10. If a UE indicated Control Plane CIoT EPS Optimisation supported in Preferred Network Behaviour, and the UE included the ESM message container, and the PDN type was IPv4 or IPv6 or IPv4v6, and the UE supports header compression, it shall include the Header Compression Configuration. The Header Compression Configuration includes the information necessary for the ROHC channel setup. Optionally, the Header Compression Configuration may include additional header compression context setup parameters if the UE already has the application traffic information, e.g. the target server IP address. For an Emergency Attach the UE shall set both the Attach Type and the Request Type to "Emergency" and the IMSI shall be included if the UE does not have a valid GUTI or a valid P-TMSI available. The IMEI shall be included when the UE has no IMSI, no valid GUTI and no valid P-TMSI. For RLOS attach, the UE shall set the Attach Type to "RLOS" and the Request Type to "RLOS", the IMSI shall be included if available and if the UE does not have a valid GUTI or a valid P-TMSI available. The IMEI shall be included when the UE has no IMSI, no valid GUTI and no valid P-TMSI. If the UE supports RACS as defined in clause 5.11.3a, and if the UE is provisioned with a UE Radio Capability ID for use in the selected PLMN (i.e.PLMN-assigned for the specific PLMN or UE manufacturer-assigned), the UE includes a flag that indicates it has an assigned UE Radio Capability ID for use in the selected PLMN but the actual UE Radio Capability ID is provided to MME after security context is established in step 5a (see below). If a Multi-USIM UE needs to modify the Paging Occasions in order to avoid paging collisions, it sends a Requested IMSI Offset to the MME, in order to signal an alternative IMSI as described in clause 4.3.33.

The eNodeB derives the MME address from the RRC parameters carrying the old GUMMEI, the indicated Selected Network and the RAT (NB-IoT or WB-E-UTRAN). If that MME is not associated with the eNodeB or the old GUMMEI is not available, the eNodeB selects an MME as described in clause 4.3.8.3 on "MME selection function". The eNodeB forwards the Attach Request message in a S1-MME control message (Initial UE message) together with the Selected Network, CSG access mode, CSG ID, L-GW address, TAI+ECGI of the cell from where it received the message to the new MME. CSG ID is provided if the UE attaches via a CSG cell or hybrid cell. CSG access mode is provided if the UE attaches via a hybrid cell. If the CSG access mode is not provided but the CSG ID is provided, the MME shall consider the cell as a CSG cell. If the eNodeB has a collocated L-GW, it includes the L-GW address in the Initial UE message to the MME. If the IAB-Indication is received from the UE in step 1, the eNodeB selects an MME that supports IAB operation and includes the IAB-Indication in the Initial UE message to the MME. If the MME is not configured to support Emergency Attach the MME shall reject any Attach Request that indicates Attach Type "Emergency". If the MME is not configured to support RLOS Attach, the MME shall reject any Attach Request that indicates Attach Type "RLOS". If the UE has included the Preferred Network Behaviour, and what the UE indicated it supports in Preferred Network Behaviour is incompatible with the network support e.g. the UE indicated support only for Control Plane CIoT EPS Optimisation and the MME only supports User Plane CIoT EPS Optimisation, the MME shall reject the Attach Request with an appropriate cause value (e.g. one that avoids retries on this PLMN). To assist Location Services, the eNodeB indicates the UE's Coverage Level to the MME. If the UE supports MT-EDT as indicated in the UE Network Capability, the MME shall consider this parameter to provide the MT-EDT indication towards Serving-GW during PDN Connection establishment or mobility procedures, and handle the data size information that the MME may receive during Downlink Data Notification procedures as defined in clause 5.3.4B.6, and clause 5.3.5B. In the case of satellite access for Cellular IoT, the MME may verify the UE location and determine whether the PLMN is allowed to operate at the UE location, as described in clause 4.13.4. If the UE receives an Attach Reject message with cause value indicating that the selected PLMN is not allowed to operate at the present UE location, the UE shall attempt to select a PLMN as specified in TS 23.122.

If the UE identifies itself with GUTI and the MME has changed since detach, the new MME determines the type of the old node, i.e. MME or SGSN, as specified in clause 4.3.19, uses the GUTI received from the UE to derive the old MME/SGSN address, and sends an Identification Request (old GUTI, complete Attach Request message) to the old MME/SGSN to request the IMSI. If the request is sent to an old MME, the old MME first verifies the Attach Request message by NAS-MAC and then responds with Identification Response (IMSI, MM Context). If the request is sent to an old SGSN, the old SGSN first verifies the Attach Request message by the P-TMSI signature and then responds with Identification Response (MM Context). If the UE is not known in the old MME/SGSN or if the integrity check or P-TMSI signature check for the Attach Request message fails, the old MME/SGSN responds with an appropriate error cause. The MM context contains security related information as well as other parameters (including IMSI) as described in clause 5.7.2 (Information Storage for MME). The additional GUTI in the Attach Request message allows the new MME to find any already existing UE context stored in the new MME when the old GUTI indicates a GUTI mapped from a P-TMSI and RAI. For an Emergency Attach or a RLOS Attach, if the UE identifies itself with a temporary identity that is not known to the MME the MME immediately requests the IMSI from the UE. If the UE identifies itself with IMEI, the IMSI request shall be skipped. 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.

If the UE is unknown in both the old MME/SGSN and new MME, the new MME sends an Identity Request to the UE to request the IMSI. The UE responds with Identity Response (IMSI).

If no UE context for the UE exists anywhere in the network, if the Attach Request (sent in step 1) was not integrity protected, or if the check of the integrity failed, then authentication and NAS security setup to activate integrity protection and NAS ciphering are mandatory. Otherwise it is optional. If NAS security algorithm is to be changed, the NAS security setup is performed in this step. The authentication and NAS security setup functions are defined in clause 5.3.10 on "Security Function". If the UE supports RACS as indicated in the UE Network Capability, and if the UE indicated that it has UE Radio Capability ID assigned for use in the selected PLMN in step 1, then authentication and NAS security setup to activate integrity protection and NAS ciphering are mandatory and the MME shall request the UE to provide the UE Radio Capability ID in Security Mode Command and the UE shall include the UE Radio Capability ID in Security Mode Command Accept for the supported UE radio capabilities. For satellite access over NB-IoT, it the UE indicated support for reporting its Coarse Location Information, the MME may request the UE to send its Coarse Location Information by setting the Coarse Location Information Request in the Security Mode Command message and the UE then reports its Coarse Location Information in the Security Mode Complete message to the MME. To perform UE location verification as described in clause 4.13.4, the MME provides the reported Coarse Location Information to the E-SMLC as described in clause 9.1.17 of TS 23.271. If the MME is configured to support Emergency Attach for unauthenticated IMSIs and the UE indicated Attach Type "Emergency" the MME skips the authentication and security setup or the MME accepts that the authentication may fail and continues the attach procedure. If the MME is configured to support RLOS Attach and the UE indicated Attach Type "RLOS", based on local regulation and operator policy, the MME may skip the authentication and security setup, or the MME may perform authentication if security information is available or obtainable from HSS and continues the attach procedure regardless of the authentication result. After step 5a, all NAS messages shall be protected by the NAS security functions (integrity and ciphering) indicated by the MME unless the UE is emergency or RLOS attached and not successfully authenticated.

The ME Identity (IMEISV) shall be retrieved from the UE. The ME identity shall be transferred encrypted unless the UE performs Emergency Attach or RLOS Attach and cannot be authenticated. For an Emergency Attach or RLOS Attach, the UE may have included the IMEI in the Emergency Attach or RLOS Attach. If so, the ME Identity retrieval is skipped. In order to minimise signalling delays, the retrieval of the ME Identity may be combined with NAS security setup in step 5a. The MME may send the ME Identity Check Request (ME Identity, IMSI) to the EIR. The EIR shall respond with ME Identity Check Ack (Result). Dependent upon the Result, the MME decides whether to continue with this Attach procedure or to reject the UE. For an Emergency Attach or RLOS Attach, the IMEI check to the EIR may be performed. If the IMEI is blocked, operator policies determine whether the Emergency Attach or RLOS Attach procedure continues or is stopped. If the UE supports RACS, as indicated in the UE Core Network Capability IE, the MME shall use the IMEI of the UE to obtain the IMEI/TAC for the purpose of RACS operation.

If the UE has set the Ciphered Options Transfer Flag in the Attach Request message, the Ciphered Options i.e. PCO or APN or both, shall now be retrieved from the UE. In order to handle situations where the UE may have subscriptions to multiple PDNs, if the Protocol Configuration Options contains user credentials (e.g. user name/password within PAP or CHAP parameters) then the UE should also send the APN to the MME.

If there are active bearer contexts in the new MME for this particular UE (i.e. the UE re-attaches to the same MME without having properly detached before), the new MME deletes these bearer contexts by sending Delete Session Request (LBI) messages to the GWs involved. The GWs acknowledge with Delete Session Response (Cause) message. If a PCRF is deployed, the PDN-GW employs an IP-CAN Session Termination procedure to indicate that resources have been released.

If the MME has changed since the last detach, or if there is no valid subscription context for the UE in the MME, or if the UE provides an IMSI or the UE provides an old GUTI which doesn't refer to a valid context in the MME, or for some network sharing scenario (e.g. GWCN) if the PLMN-ID of the TAI supplied by the eNodeB is different from that of the GUTI in the UE's context, the MME sends an Update Location Request (MME Identity, IMSI, ME Identity (IMEISV), MME Capabilities, ULR-Flags, Homogeneous Support of IMS Voice over PS Sessions, UE SRVCC capability, equivalent PLMN list) message to the HSS. The MME capabilities indicate the MME's support for regional access restrictions functionality. ULR-Flags indicates "Initial-Attach-Indicator" as this is an Attach procedure. The inclusion of the equivalent PLMN list indicates that the MME supports the inter-PLMN handover to a CSG cell in an equivalent PLMN using the subscription information of the target PLMN. The "Homogenous Support of IMS Voice over PS Sessions" indication (see clause 4.3.5.8A) shall not be included unless the MME has completed its evaluation of the support of "IMS Voice over PS Session" as specified in clause 4.3.5.8. If the UE performs Initial or Handover Attach in a VPLMN supporting Autonomous CSG Roaming and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN (via Service Level Agreement) and the MME needs to retrieve the CSG subscription information of the UE from the CSS, the MME initiates the Update CSG Location Procedure with CSS as described in clause 5.3.12. If the MME determines that only the UE SRVCC capability has changed, the MME sends a Notify Request to the HSS to inform about the changed UE SRVCC capability. If there is a valid subscription context for the UE in the MME with a Service Gap timer running and the Attach Type is not Emergency Attach and it is not an Attach without PDN connectivity, the MME rejects the Attach Request from the UE with an appropriate cause value. In addition, MME may also provide a UE with a Mobility Management Back-off Timer set to the remaining value of the Service Gap timer. For an Emergency Attach in which the UE was not successfully authenticated, the MME shall not send an Update Location Request to the HSS. For an RLOS Attach the MME shall not send an Update Location Request to the HSS.

The HSS sends Cancel Location (IMSI, Cancellation Type) to the old MME. The old MME acknowledges with Cancel Location Ack (IMSI) and removes the MM and bearer contexts. If the ULR-Flags indicates "Initial-Attach-Indicator" and the HSS has the SGSN registration, then the HSS sends Cancel Location (IMSI, Cancellation Type) to the old SGSN. The Cancellation Type indicates the old MME/SGSN to release the old Serving-GW resource.

If there are active bearer contexts in the old MME/SGSN for this particular UE, the old MME/SGSN deletes these bearer contexts by sending Delete Session Request (LBI) messages to the GWs involved. The GWs return Delete Session Response (Cause) message to the old MME/SGSN. If a PCRF is deployed, the PDN-GW employs an IP-CAN Session Termination procedure as defined in TS 23.203 to indicate that resources have been released.

The HSS acknowledges the Update Location message by sending an Update Location Ack (IMSI, Subscription data) message to the new MME. The Subscription Data contain one or more PDN subscription contexts. Each PDN subscription context contains an 'EPS subscribed QoS profile' and the subscribed APN-AMBR (see clause 4.7.3) and the WLAN offloadability indication (see clause 4.3.23). The new MME validates the UE's presence in the (new) TA. If due to regional subscription restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to attach in the TA or due to subscription checking fails for other reasons, the new MME rejects the Attach Request with an appropriate cause. If all checks are successful then the new MME constructs a context for the UE. If the APN provided by the UE is not allowed by subscription, based on operator policy, the MME may reject the Attach Request from the UE with an appropriate cause, or accept the Attach Request by replacing the UE requested APN with a network supported APN. The MME uses that network supported APN for the remainder of this procedure, except that the MME provides to the UE the same APN that the UE requested. If the Update Location is rejected by the HSS, the new MME rejects the Attach Request from the UE with an appropriate cause. The Subscription Data may contain CSG subscription information for the registered PLMN and for the equivalent PLMN list requested by MME in step 8. The Subscription Data may contain the IAB-Operation Allowed indication the IAB operation. The MME shall use the IAB-Opeation Allowed indication to authorize the UE's IAB operation. The subscription data may contain Enhanced Coverage Restricted parameter. If received from the HSS, MME stores this Enhanced Coverage Restricted parameter in the MME MM context. The subscription data may contain Service Gap Time parameter. If received from the HSS, MME stores this Service Gap Time in the MME MM context and passes it to the UE in the Attach Accept message. The subscription data may contain Subscribed Paging Time Window parameter that applies to the UEs on a specific RAT, e.g. NB-IoT. If received from the HSS, MME stores this Subscribed Paging Time Window parameter in the MME MM context. The subscription data may contain an indication that the UE is subscribed to receive time reference information in access stratum. If received from the HSS and if supported by the MME, the MME stores this indication in the MME MM context. If the UE provided APN is authorized for LIPA according to the user subscription, the MME shall use the CSG Subscription Data to authorize the connection. For an Emergency Attach or RLOS Attach, the MME shall not check for access restrictions, regional restrictions or subscription restrictions (e.g. CSG restrictions). For an Emergency Attach, the MME shall ignore any unsuccessful Update Location Response from HSS and continue with the Attach procedure.

If an ESM container was not included in the Attach Request, steps 12, 13,14,15,16 are skipped. If the attach type is not set to "Emergency" or "RLOS", and the ESM container was included in the Attach Request, and the UE has indicated support for Attach without PDN Connectivity, and the network supports Attach without PDN Connectivity, and the PDN Connection Restriction is set in the subscriber data, then the new MME shall not establish PDN connection, and steps 12, 13, 14, 15 and 16 are skipped. For an Emergency Attach the MME applies the parameters from MME Emergency Configuration Data for the emergency bearer establishment performed in this step and any potentially stored IMSI related subscription data are ignored by the MME. For a RLOS Attach, the MME applies the parameters from MME RLOS Configuration Data for the RLOS default bearer establishment performed in this step and any potentially stored IMSI related subscription data are ignored by the MME. If the UE performs Initial or Handover Attach via a CSG cell and there is no subscription for that CSG or the CSG subscription is expired the MME shall reject the Attach Request with an appropriate cause. If the UE has this CSG ID and associated PLMN on its Allowed CSG list the UE shall remove the CSG ID and associated PLMN from the list when receiving this reject cause. If a subscribed PDN address is allocated for the UE for this APN, the PDN subscription context contains the UE's IPv4 address and/or the IPv6 prefix and optionally the PDN-GW identity. If the PDN subscription context contains a subscribed IPv4 address and/or IPv6 prefix, the MME indicates it in the PDN address. For Request Type indicating "Initial request", if the UE does not provide an APN, the MME shall use the PDN-GW corresponding to the default APN for default bearer activation. If the UE provides an APN, this APN shall be employed for default bearer activation. For Request Type indicating "Handover", if the UE provides an APN, the MME shall use the PDN-GW corresponding to the provided APN for default bearer activation, If the UE does not provide an APN, and the subscription context from HSS contains a PDN-GW identity corresponding to the default APN, the MME shall use the PDN-GW corresponding to the default APN for default bearer activation. The case where the Request Type indicates "Handover" and the UE does not provide an APN, and the subscription context from HSS does not contain a PDN-GW identity corresponding to the default APN constitutes an error case. If the Request Type indicates "Initial request" and the selected PDN subscription context contains no PDN-GW identity the new MME selects a PDN-GW as described in clause 4.3.8.1 on PDN-GW selection function (3GPP accesses). If the PDN subscription context contains a dynamically allocated PDN-GW identity and the Request Type does not indicate "Handover" the MME may select a new PDN-GW as described in clause 4.3.8.1 on PDN-GW selection function, e.g. to allocate a PDN-GW that allows for more efficient routing. For initial and handover Emergency Attach the MME uses the PDN-GW Selection function defined in clause 4.3.12.4 to select a PDN-GW. For initial RLOS Attach, the MME uses the PDN-GW Selection function defined in clause 4.3.12a.4 to select a PDN-GW. If the subscription context does not indicate that the APN is for a PDN connection to an SCEF, the new MME selects a Serving-GW as described in clause 4.3.8.2 on Serving-GW selection function and allocates an EPS Bearer Identity for the Default Bearer associated with the UE. Then it sends a Create Session Request (IMSI, MSISDN, MME TEID for control plane, PDN-GW address, PDN Address, APN, RAT type, LTE-M RAT type reporting to PGW flag, Default EPS Bearer QoS, PDN Type, APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity (IMEISV), User Location Information (ECGI and TAI), UE Time Zone, User CSG Information, MS Info Change Reporting support indication, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag, the Protocol Type over S5/S8, Serving Network, APN Rate Control Status) message to the selected Serving-GW. If Control Plane CIoT EPS Optimisation applies, then the MME shall also indicate S11-U tunnelling of NAS user data and send its own S11-U IP address and MME DL TEID for DL data forwarding by the SGW. User CSG Information includes CSG ID, access mode and CSG membership indication. For PDN type "non-IP" when Control Plane CIoT EPS Optimisations are enabled for the UE, if APN subscription data indicate a SCEF connection needs to be used, then the MME allocates an EPS Bearer Identity for the Default Bearer associated with the UE and establishes a connection to the SCEF address indicated in subscription data as per TS 23.682 and the steps 12,13,14,15,16 are not executed. The rest of the interactions with the UE apply as specified below. If the MME determines the PDN connection shall only use the Control Plane CIoT EPS Optimisation, the MME shall include a Control Plane Only PDN Connection Indicator in Create Session Request. If the Request Type indicates "Emergency" or "RLOS", Maximum APN restriction control shall not be performed. For emergency attached or RLOS attached UEs IMSI is included if available and if the IMSI cannot be authenticated then the IMSI shall be marked as unauthenticated. The RAT type is provided in this message for the later PCC decision. The RAT type shall distinguish between NB-IoT, LTE-M and WB-E-UTRA RAT types as specified in clause 4.3.5.3. The subscribed APN-AMBR for the APN is also provided in this message. The MSISDN is included if provided in the subscription data from the HSS. Handover Indication is included if the Request Type indicates handover. Selection Mode indicates whether a subscribed APN was selected, or a non-subscribed APN sent by the UE was selected. Charging Characteristics indicates which kind of charging the bearer context is liable for. The MME may change the requested PDN type according to the subscription data for this APN as described in clause 5.3.1.1. The MME shall set the Dual Address Bearer Flag when the PDN type is set to IPv4v6 and all SGSNs which the UE may be handed over to are Release 8 or above supporting dual addressing, which is determined based on node pre-configuration by the operator. The Protocol Type over S5/S8 is provided to Serving-GW which protocol should be used over S5/S8 interface. The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of handling Charging Characteristics and whether to send them or not to the P-GW is defined in TS 32.251. The MME shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S-GW and/or P-GW trace is activated. The MME shall copy Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or OMC. The Maximum APN Restriction denotes the most stringent restriction as required by any already active bearer context. If there are no already active bearer contexts, this value is set to the least restrictive type (see clause 15.4 of TS 23.060). If the P-GW receives the Maximum APN Restriction, then the P-GW shall check if the Maximum APN Restriction value does not conflict with the APN Restriction value associated with this bearer context request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with sending an appropriate error cause to the UE. If the MME requires the eNodeB to check whether the UE radio capabilities are compatible with the network configuration (e.g. whether the SRVCC or frequency support by the UE matches that of the network) to be able to set the IMS voice over PS Session Supported Indication (see clause 4.3.5.8), then the MME may send a UE Radio Capability Match Request to the eNodeB as defined in clause 5.3.14. The MME includes the latest APN Rate Control status if it has stored it. Based on UE and Serving-GW capability of supporting MT-EDT, Communication Pattern parameters or local policy, the MME may indicate to Serving-GW that MT-EDT is applicable for the PDN connection.

The Serving-GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI, MSISDN, APN, Serving-GW Address for the user plane, Serving-GW TEID of the user plane, Serving-GW TEID of the control plane, RAT type, Default EPS Bearer QoS, PDN Type, PDN Address, subscribed APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information (ECGI), UE Time Zone, User CSG Information, MS Info Change Reporting support indication, PDN Charging Pause Support indication, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag, Serving Network, APN Rate Control Status) message to the PDN-GW indicated by the PDN-GW address received in the previous step. After this step, the Serving-GW buffers any downlink packets it may receive from the PDN-GW without sending a Downlink Data Notification message to the MME until it receives the Modify Bearer Request message in step 23 below. The MSISDN is included if received from the MME. If the Serving-GW has received the Control Plane Only PDN Connection Indicator in step 12, the Serving-GW informs the PDN-GW this information in Create Session Request. The Serving-GW and PDN-GW shall indicate the use of CP only on their CDRs. PDN-GWs shall not perform any checks of Maximum APN Restriction if Create Session Request includes the emergency APN or RLOS APN. For emergency attached or RLOS attached UEs IMSI is included if available and if the IMSI cannot be authenticated then the IMSI shall be marked as unauthenticated. In the case of handover attach, and if the PDN-GW detects that the 3GPP PS Data Off UE Status is active, the PDN-GW shall indicate this status to the charging system for offline and online charging.

If dynamic PCC is deployed and the Handover Indication is not present, the PDN-GW performs an IP-CAN Session Establishment procedure as defined in TS 23.203, and thereby obtains the default PCC rules for the UE. If the UE is accessing over WB-E-UTRA, this may lead to the establishment of a number of dedicated bearers following the procedures defined in clause 5.4.1 in association with the establishment of the default bearer, which is described in Annex F. The IMSI, APN, UE IP address, User Location Information (ECGI), UE Time Zone, Serving Network, RAT type, APN-AMBR, Default EPS Bearer QoS, ETFTU (if ETFTU is not provided it means UE and/or the PDN-GW does not support the extended TFT filter format) are provided to the PCRF by the PDN-GW if received by the previous message. The User Location Information and UE Time Zone are used for location based charging. For emergency attached or RLOS attached UEs which are unauthenticated the PDN-GW provides the IMEI as the UE Identity instead of IMSI, to the PCRF. If the PCRF decides that the PDN connection may use the extended TFT filter format, it shall return the ETFTN indicator to the PDN-GW for inclusion in the protocol Configuration Options returned to the UE. The PCRF may modify the APN-AMBR and the QoS parameters (QCI and ARP) associated with the default bearer in the response to the PDN-GW as defined in TS 23.203. If the PCC is configured to support emergency services and if dynamic PCC is deployed, the PCRF, based on the emergency APN, sets the ARP of the PCC rules to a value that is reserved for emergency services and the authorization of dynamic PCC rules as described in of TS 23.203. If dynamic PCC is not deployed, the PDN-GW uses the ARP of the default emergency EPS bearer for any potentially initiated dedicated emergency EPS bearer. The P-GW determines that emergency services are requested based on the emergency APN received in Create Session Request message. If the PCC is configured to support Restricted Local Operator Services and if dynamic PCC is deployed, the PCRF, based on the RLOS APN, sets the ARP of the PCC rules to a value based on operator policy and the authorization of dynamic PCC rules as described in of TS 23.203. If dynamic PCC is deployed and the Handover Indication is present, the PDN-GW executes a PCEF Initiated IP-CAN Session Modification procedure with the PCRF as specified in TS 23.203 to report the new IP-CAN type. Depending on the active PCC rules, the establishment of dedicated bearers for the UE may be required. The establishment of those bearers shall take place in combination with the default bearer activation as described in Annex F. This procedure can continue without waiting for a PCRF response. If changes to the active PCC rules are required, the PCRF may provide them after the handover procedure is finished. In both cases (Handover Indication is present or not), if dynamic PCC is not deployed, the PDN-GW may apply local QoS policy. If the UE is accessing over WB-E-UTRA, this may lead to the establishment of a number of dedicated bearers for the UE following the procedures defined in clause 5.4.1 in combination with the establishment of the default bearer, which is described in Annex F. If the CSG information reporting triggers are received from the PCRF, the PDN-GW should set the CSG Information Reporting Action IE accordingly. If 3GPP PS Data Off status is received in the PCO from the UE and PDN-GW supports 3GPP PS Data Off, the PDN-GW shall provide the 3GPP PS Data Off status to the PCRF. If the PCRF supports 3GPP PS Data Off, it shall return 3GPP PS Data Off support to the PDN-GW for inclusion in the PCO returned to the UE. The additional behaviour of the PDN-GW for 3GPP PS Data Off is defined in TS 23.203. If received, the PDN-GW may take the APN Rate Control Status into account when encoding the APN Rate Control parameters in Protocol Configuration Options and when enforcing the APN Rate Control as described in clause 4.7.7.3.

The P-GW creates a new entry in its EPS bearer context table and generates a Charging Id for the Default Bearer. The new entry allows the P-GW to route user plane PDUs between the S-GW and the packet data network, and to start charging. The way the P-GW handles Charging Characteristics that it may have received is defined in TS 32.251. The PDN-GW returns a Create Session Response (PDN-GW Address for the user plane, PDN-GW TEID of the user plane, PDN-GW TEID of the control plane, PDN Type, PDN Address, EPS Bearer Identity, EPS Bearer QoS, Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action (Start) (if the PDN-GW decides to receive UE's location information during the session), CSG Information Reporting Action (Start) (if the PDN-GW decides to receive UE's User CSG information during the session), Presence Reporting Area Action (if the PDN-GW decides to receive notifications about a change of UE presence in Presence Reporting Area), PDN Charging Pause Enabled indication (if PDN-GW has chosen to enable the function), APN-AMBR, Delay Tolerant Connection) message to the Serving-GW. The PDN-GW takes into account the received PDN type, the Dual Address Bearer Flag and the policies of operator when the PDN-GW selects the PDN type to be used as follows. If the received PDN type is IPv4v6 and both IPv4 and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version addressing for this APN is possible in the PDN, the PDN-GW selects a single IP version (either IPv4 or IPv6). If the received PDN type is IPv4 or IPv6 or "Non-IP" or "Ethernet", the PDN-GW uses the received PDN type if it is supported in the PDN, otherwise an appropriate error cause will be returned. For IPv4, IPv6 and IPv4v6, the PDN-GW allocates a PDN Address according to the selected PDN type. If the PDN-GW has selected a PDN type different from the received PDN Type, the PDN-GW indicates together with the PDN type IE a reason cause to the UE why the PDN type has been modified, as described in clause 5.3.1.1. The PDN-GW shall either accept or reject (but not modify) the PDN type if the PDN type is set to "Non-IP" or "Ethernet". PDN Address may contain an IPv4 address for IPv4 and/or an IPv6 prefix and an Interface Identifier, or be omitted for PDN types "Non-IP" and "Ethernet". If the PDN has been configured by the operator so that the PDN addresses for the requested APN shall be allocated by usage of DHCPv4 only, or if the PDN-GW allows the UE to use DHCPv4 for address allocation according to the Address Allocation Preference received from the UE, the PDN Address shall be set to 0.0.0.0, indicating that the IPv4 PDN address shall be negotiated by the UE with DHCPv4 after completion of the Default Bearer Activation procedure. For external PDN addressing for IPv6, the PDN-GW obtains the IPv6 prefix from the external PDN using either RADIUS or Diameter client function. In the PDN Address field of the Create Session Response, the PDN-GW includes the Interface Identifier and IPv6 prefix. The PDN-GW sends Router Advertisement to the UE after default bearer establishment with the IPv6 prefix information for all cases. If the PDN address is contained in the Create Session Request, the PDN-GW shall allocate the IPv4 address and/or IPv6 prefix contained in the PDN address to the UE. The IP address allocation details are described in clause 5.3.1 on "IP Address Allocation". The PDN-GW derives the BCM based on the NRSU and operator policy. The PDN-GW derives whether the extended TFT filter format is to be used based on the ETFTU, ETFTN received from the PCRF and operator policy. Protocol Configuration Options contains the BCM, ETFTN as well as optional PDN parameters that the P-GW may transfer to the UE. These optional PDN parameters may be requested by the UE, or may be sent unsolicited by the P-GW. Protocol Configuration Options are sent transparently through the MME. The PDN-GW includes a Delay Tolerant Connection indication if the PDN-GW supports receiving a rejection cause from the SGW indicating that the UE is temporarily not reachable due to power saving and holding mobile terminated procedures, until the PDN-GW receives a message indicating that the UE is available for end to end signalling. When the Handover Indication is present, the PDN-GW does not yet send downlink packets to the S-GW; the downlink path is to be switched at step 23a. If the PDN-GW is an L-GW, it does not forward downlink packets to the S-GW. The packets will only be forwarded to the HeNB at step 20 via the direct user plane path. If the 3GPP PS Data Off UE Status was present in the Create Session Request PCO and the network supports 3GPP PS Data Off feature, the PDN-GW shall include the 3GPP PS Data Off Support Indication in the Create Session Response PCO.

The Serving-GW returns a Create Session Response (PDN Type, PDN Address, Serving-GW address for User Plane, Serving-GW TEID User Plane, Serving-GW TEID for control plane, EPS Bearer Identity, EPS Bearer QoS, PDN-GW addresses and TEIDs (GTP-based S5/S8) or GRE keys (PMIP-based S5/S8) at the PDN-GW(s) for uplink traffic, Protocol Configuration Options, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action (Start), Presence Reporting Area Action, CSG Information Reporting Action (Start), APN-AMBR, Delay Tolerant Connection) message to the new MME. If Control Plane CIoT EPS Optimisation applies, and if the MME does not include Control Plane Only PDN Connection Indicator in the Create Session Request:

• If separation of S11-U from S1-U is required, the Serving-GW shall include the Serving-GW IP address and TEID for S11-U and additionally the Serving-GW IP address and TEID for S1-U in Create Session Response.
• Otherwise, if separation of S11-U from S1-U is not required, the Serving-GW includes the Serving-GW IP address and TEID for S11-U in Create Session Response.

If an APN Restriction is received, then the MME shall store this value for the Bearer Context and the MME shall check this received value with the stored value for the Maximum APN Restriction to ensure there are no conflicts between values. If the Bearer Context is accepted, the MME shall determine a (new) value for the Maximum APN Restriction. If there is no previously stored value for Maximum APN Restriction, then the Maximum APN Restriction shall be set to the value of the received APN Restriction. MME shall not deactivate bearer(s) with emergency ARP, if present, to maintain valid APN restriction combination. The P-GW shall ignore Maximum APN restriction if the request includes the Emergency APN. If the MS Info Change Reporting Action (Start) and/or the CSG Information Reporting Action (Start) are received for this bearer context, then the MME shall store this for the bearer context and the MME shall report to that P-GW via the S-GW whenever a UE's location and/or User CSG information change occurs that meets the P-GW request, as described in clause 15.1.1a of TS 23.060. If Presence Reporting Area Action is received for this bearer context, the MME shall store this information for the bearer context and shall report to that P-GW via the S-GW whenever a change of UE presence in a Presence Reporting Area is detected, as described in clause 5.9.2.2. The MME determines the UE-AMBR to be used by the eNodeB based on the subscribed UE-AMBR and the APN-AMBR for the default APN, see clause 4.7.3. For emergency attach or RLOS attach the MME determines the UE-AMBR to be used by the eNodeB from the APN-AMBR received from the S-GW. If new MME hasn't received, from Step 12, Voice Support Match Indicator for the UE from the eNodeB then, based on implementation, the MME may set IMS Voice over PS session supported Indication and update it at a later stage. The new MME sends an Attach Accept (GUTI, TAI List, Session Management Request (APN, PDN Type, PDN Address, EPS Bearer Identity, Protocol Configuration Options, Header Compression Configuration, Control Plane Only Indicator, Connection Release Supported, Paging Cause Indication for Voice Service Supported, Reject Paging Request Supported, Paging Restriction Supported, Paging Timing Collision Control Supported), NAS sequence number, NAS-MAC, IMS Voice over PS session supported Indication, Emergency Service Support indicator, LCS Support Indication, Supported Network Behaviour, Service Gap Time, Enhanced Coverage Restricted, Indication for support of 15 EPS bearers per UE, PLMN-assigned UE Radio Capability ID, indication for PLMN-assigned UE Radio Capability ID deletion, Accepted IMSI Offset, Forbidden TAI(s), Enhanced Discontinuous Coverage Support, Return To Coverage Notification Not Required, Maximum Time Offset, Start of Unavailability Period, Unavailability Period Duration, Time Reference Information Distribution Indication) message to the eNodeB. GUTI is included if the new MME allocates a new GUTI. PDN Type and PDN Address are omitted if the Attach Request (step 1) did not contain an ESM message container. The MME indicates the CIoT EPS Optimisations it accepts in the Supported Network Behaviour information as defined in clause 4.3.5.10. Service Gap Time is included if Service Gap Time is present in the subscription information (step 11) and the UE has indicated UE Service Gap Control Capability. This message is contained in an S1_MME control message Initial Context Setup Request, unless the MME has selected to use the Control Plane CIoT EPS Optimisation, or, the UE did not include the ESM message container in the Attach Request (step 1), in which case an S1-AP Downlink NAS transport message is used. The S1-AP Initial Context Setup Request message also includes the AS security context information for the UE, the Handover Restriction List, the EPS Bearer QoS, the UE-AMBR, EPS Bearer Identity, as well as the TEID at the Serving GW used for user plane and the address of the Serving GW for user plane and whether User Plane CIoT EPS Optimisation is allowed for the UE. If the PDN type is set to "Non-IP" the MME includes it in the S1-AP Initial Context Setup Request so that the eNodeB disables header compression. If the PDN type is set to "Ethernet" the MME includes it in the S1-AP Initial Context Setup Request so that any eNodeB header compression functionality can act appropriately. In addition, if the PDN connection is established for Local IP Access, the corresponding S1 Initial Context Setup Request message includes a Correlation ID for enabling the direct user plane path between the HeNB and the L-GW. If the PDN connection is established for SIPTO at the Local Network with L-GW function collocated with the (H)eNB, the corresponding S1-AP Initial Context Setup Request message includes a SIPTO Correlation ID for enabling the direct user plane path between the (H)eNB and the L-GW. LIPA and SIPTO do not apply to Control Plane CIoT EPS Optimisation. If Control Plane CIoT EPS Optimisation applies for an IP PDN connection, and the UE has sent in the Attach Request the Header Compression Configuration, and the MME supports the header compression parameters, the MME shall include the Header Compression Configuration in the PDN Connectivity Accept message. The MME also binds the uplink and downlink ROHC channels to support header compression feedback signalling. If the UE has included header compression context setup parameters in Header Compression Configuration in the Attach Request, the MME may acknowledge the header compression context setup parameters. If the ROHC context is not established during the attach procedure for the PDN connection, before using the compressed format for sending the data, the UE and the MME need to establish the ROHC context with ROHC IR packet based on Header Compression Configuration. If the MME based on local policy determines the PDN connection shall only use the Control Plane CIoT EPS Optimisation, the MME shall include a Control Plane Only Indicator in the Session Management Request. For PDN connections with an SCEF, the MME shall always include the Control Plane Only Indicator. A UE receiving the Control Plane Only Indicator, for a PDN connection shall only use the Control Plane CIoT EPS Optimisation for this PDN connection. If the ESM container was not included in the Attach Request in step 1, then the Attach Accept message shall not include PDN related parameters, and the Downlink NAS transfer S1-AP message shall not include Access stratum context related information but may include CSG related information. If the attach type is not set to "Emergency", and the ESM container was included in Attach Request in step 1, and the UE indicated support of Attach without PDN Connection in the Attach Request, and the MME supports Attach without PDN Connection, and PDN connection restriction is set in subscriber data, then the MME shall discard the ESM container in the Attach Request message, and shall not include PDN related parameters in the Attach Accept, but may include CSG related information. In the Attach Accept message, the MME does not include the IPv6 prefix within the PDN Address. The MME includes the EPS Bearer QoS parameter QCI and APN-AMBR into the Session Management Request. Furthermore, if the UE has UTRAN or GERAN capabilities and the network supports mobility to UTRAN or GERAN, the MME uses the EPS bearer QoS information to derive the corresponding PDP context parameters QoS Negotiated (R99 QoS profile), Radio Priority, Packet Flow Id and TI and includes them in the Session Management Request. If the UE indicated in the UE Network Capability it does not support BSS packet flow procedures, then the MME shall not include the Packet Flow Id. Handover Restriction List is described in clause 4.3.5.7 "Mobility Restrictions". The MME sets the IMS Voice over PS session supported Indication as described in clause 4.3.5.8. LCS Support Indication indicates whether the network supports the EPC-MO-LR and/or CS-MO-LR as described in TS 23.271. The MME may include an indication whether the traffic of this PDN Connection is allowed to be offloaded to WLAN, as described in clause 4.3.23. Indication for support of 15 EPS bearers per UE indicates the network support for up to 15 EPS bearers per UE as defined in clause 4.12. If the UE initiates the Attach procedure at a hybrid cell, the MME shall check whether the CSG ID is contained in the CSG subscription and is not expired. The MME shall send an indication whether the UE is a CSG member to the RAN along with the S1-MME control message. Based on this information, the RAN may perform differentiated treatment for CSG and non-CSG members. If the MME or PDN-GW has changed the PDN Type, an appropriate reason cause shall be returned to the UE as described in clause 5.3.1.1. If the UE has indicated PDN type "Non-IP" or "Ethernet", the MME and PDN-GW shall not change PDN type. For an emergency attached UE, i.e. for UEs that have only emergency EPS bearers established, there is no AS security context information included in the S1 control messages and there is no NAS level security when the UE cannot be authenticated. The Emergency Service Support indicator informs the UE that Emergency bearer services are supported, i.e. the UE is allowed to request PDN connectivity for emergency services. For RLOS attached UEs, i.e. for UEs that have only RLOS PDN connection established, there is no AS security context information included in the S1 control messages and there is no NAS level security when the UE cannot be successfully authenticated. If the UE included extended idle mode DRX parameters information element, the MME includes extended idle mode DRX parameters information element if it decides to enable extended idle mode DRX with Paging Time Window length assigned considering Subscribed Paging Time Window (if available) and the local policy. Additionally, for a UE using an eNodeB that provides discontinuous coverage (e.g. for satellite access with discontinuous coverage), the MME may consider the use of discontinuous coverage as described in clause 4.13.8.2 when determining extended idle mode DRX parameters. If the UE provided the UE paging probability information in Step 1, the MME takes it into account when generating the WUS Assistance Information. If the MME has determined WUS Assistance Information for the UE, the MME shall send the WUS Assistance Information to the UE (see TS 36.300). If the UE included support for restriction of use of Enhanced Coverage in step 1, the MME sends Enhanced Coverage Restricted parameter to the eNodeB in S1-AP Initial Context Set-up Request message. MME also sends Enhanced Coverage Restricted parameter to the UE in the Attach Accept message. If the UE has indicated support for dual connectivity with NR in the Attach Request and the UE is not allowed to use NR as Secondary RAT, the MME indicates that to the UE in the Attach Accept message. If RACS is supported in the MME and MME has received UE Radio Capability ID earlier in this procedure, it signals the UE Radio Capability ID to the eNodeB in S1-AP Initial Context Set-up Request message. If the eNodeB does not have mapping between the specific UE Radio Capability ID and the UE radio capabilities, it shall use the procedure described in TS 36.413 to retrieve the mapping from the MME. When the UE supports RACS, and the MME needs to configure the UE with a UE Radio Capability ID, and the MME already has the UE radio capabilities for the UE, the MME may provide the UE with the UE Radio Capability ID for the UE radio capabilities the UCMF returns to the MME for this UE. If MME has authorized the UE's IAB operation in step 11 based on the IAB-Operation Allowed indication, it shall include an "IAB Authorized" indication in the S1-AP Initial Context Set-up Request message to the eNodeB. If the UE had included a UE Specific DRX parameter for NB-IoT in the Attach Request, the MME includes the Accepted NB-IoT DRX parameter. If the UE provided a Requested IMSI Offset in step 1, but the network prefers a different value, the MME provides the UE with an Accepted IMSI Offset different from the one provided in step 1. Otherwise the value of the Accepted IMSI Offset the MME sends is the value of the Requested IMSI Offset sent by the UE in step 1. The MME stores the value of the alternative IMSI derived from the Accepted IMSI Offset (see clause 4.3.33) provided to the UE in the UE context. If a Multi-USIM mode UE does not provide a Requested IMSI Offset in step 1, the MME erases any Alternative IMSI value in the UE context. If the Multi-USIM UE has indicated one or more Multi-USIM specific capabilities are supported in the UE Core Network Capability in step 1, the MME shall indicate whether the corresponding one or more Multi-USIM specific features described in clause 4.3.33 are supported based on network capability and preference by the network (i.e. based on local network policy) by providing one or more of the Connection Release Supported, Paging Cause Indication for Voice Service Supported, Reject Paging Request Supported, Paging Restriction Supported and Paging Timing Collision Control Supported indications. The MME shall only indicate Paging Restriction Supported together with either Connection Release Supported or Reject Paging Request Supported. The UE shall only use Multi-USIM specific features that the MME indicated as being supported. In the case of Emergency Attach, the MME shall not indicate support for any Multi-USIM feature to the UE. If the MME receives multiple TAIs from E-UTRAN in step 2 and determines that some, but not all, TAIs in the received list of TAIs are forbidden by subscription or by operator policy, the MME shall include the forbidden TAI(s) in the Attach Accept message. If both UE and network support discontinuous coverage, the MME provides the Enhanced Discontinuous Coverage Support indication as described in clause 4.13.8.1. The MME may provide Start of Unavailability Period and/or Unavailability Period Duration to UE in the Attach Accept message as described in clause 4.13.8.2. For a UE using a eNodeB that provides discontinuous coverage (e.g. for satellite access with discontinuous coverage), the MME may provide Return To Coverage Notification Not Required, which requests the UE in ECM_IDLE state to not perform the TAU procedure when it returns to coverage as described in clause 4.13.8.2. The MME may also provide a Maximum Time Offset as described in clause 4.13.8.6. If supported by the MME and if the UE is subscribed to receive time reference information, then the MME provides the Time Reference Information Distribution Indication to the eNodeB.

If the eNodeB received an S1-AP Initial Context Setup Request the eNodeB sends the RRC Connection Reconfiguration message including the EPS Radio Bearer Identity to the UE, and the Attach Accept message will be sent along to the UE. If the eNodeB received an S1-AP Downlink NAS Transport message (e.g. containing the Attach Accept message), the eNode B sends a RRC Direct Transfer message to the UE. The UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id and TI, which it received in the Session Management Request, for use when accessing via GERAN or UTRAN. The APN is provided to the UE to notify it of the APN for which the activated default bearer is associated. For further details, see TS 36.331. The UE may provide EPS Bearer QoS parameters to the application handling the traffic flow(s). The application usage of the EPS Bearer QoS is implementation dependent. The UE shall not reject the RRC Connection Reconfiguration on the basis of the EPS Bearer QoS parameters contained in the Session Management Request. If the UE receives Enhanced Coverage Restricted parameter in the Attach Accept message, UE shall store this information and shall use the value of Enhanced Coverage Restricted parameter to determine if enhanced coverage feature should be used or not. If the UE receives a Service Gap Time in the Attach Accept message, the UE shall store this parameter and apply Service Gap Control (see clause 4.3.17.9). If the attach procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving the Attach accept shall check if the CSG ID and associated PLMN of the cell where the UE has sent the Attach Request message is contained in its Allowed CSG list. If the CSG ID and associated PLMN is not in the UE's Allowed CSG list, the UE shall add the CSG ID and associated PLMN to its Allowed CSG list. Manual CSG selection is not supported when an emergency service has been initiated. When receiving the Attach Accept message the UE shall set its TIN to "GUTI" as no ISR Activated is indicated. If the UE receives an IPv4 address set to 0.0.0.0, it may negotiate the IPv4 address with DHCPv4 as specified in TS 29.061. If the UE receives an IPv6 interface identifier, it may wait for the Router Advertisement from the network with the IPv6 prefix information or it may send a Router Solicitation if necessary. If Control Plane CIoT EPS Optimisation applies or the UE has not included the ESM message container in the Attach Request in step 1, then the steps 19 and 20 are not executed.

The UE sends the RRC Connection Reconfiguration Complete message to the eNodeB. For further details, see TS 36.331.

The eNodeB sends the Initial Context Response message to the new MME. This Initial Context Response message includes the TEID of the eNodeB and the address of the eNodeB used for downlink traffic on the S1_U reference point. The MME shall be prepared to receive this message either before or after the Attach Complete message (sent in step 22). If the Correlation ID or SIPTO Correlation ID was included in the Initial Context Setup Request message, the eNodeB shall use the included information to establish direct user plane path with the L-GW and forward uplink data for Local IP Access or SIPTO at the Local Network with L-GW function collocated with the (H)eNB accordingly.

The UE sends a Direct Transfer message to the eNodeB, which includes the Attach Complete (EPS Bearer Identity, NAS sequence number, NAS-MAC) message. If the UE omitted the ESM message container from the Attach Request message in step 1, then the EPS Bearer Identity is omitted from the Attach Complete message.

The eNodeB forwards the Attach Complete message to the new MME in an Uplink NAS Transport message. If the ESM message container was included in step 1, after the Attach Accept message and once the UE has obtained (if applicable to the PDN type) a PDN Address, the UE can then send uplink packets towards the eNodeB which will then be tunnelled to the Serving-GW and PDN-GW. If Control Plane CIoT EPS Optimisations apply, UL data is sent as specified in clause 5.3.4B. If the UE requested for a dual address PDN type (IPv4v6) to a given APN and was granted a single address PDN type (IPv4 or IPv6) by the network with a reason cause indicating that only single IP version per PDN connection is allowed sent together with the PDN type, the UE should request for the activation of a parallel PDN connection to the same APN with a single address PDN type (IPv4 or IPv6) other than the one already activated. If the UE receives no reason cause in step 18 in response to an IPv4v6 PDN type and it receives an IPv6 Interface Identifier apart from the IPv4 address or 0.0.0.0 in the PDN Address field, it considers that the request for a dual address PDN was successful. It can wait for the Router Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation if necessary.

Upon reception of both, the Initial Context Response message in step 20 and the Attach Complete message in step 22, the new MME sends a Modify Bearer Request (EPS Bearer Identity, eNodeB address, eNodeB TEID, Handover Indication, Presence Reporting Area Information, RAT type, LTE-M RAT type reporting to PGW) message to the Serving-GW. If the Control Plane CIoT EPS Optimisation applies and the PDN connection is not served by a SCEF and if the MME does not need to report a change of UE presence in Presence Reporting Area, sending of Modify Bearer Request and steps 23a, 23b and 24 are skipped; otherwise if the PDN connection is served by SCEF, steps 23,24, 25, and 26 are not executed. If the MME has been requested to report a change of UE presence in Presence Reporting Area, the MME includes in this message the Presence Reporting Area Information comprising the PRA identifier(s) and indication(s) on whether the UE is inside or outside the area(s). When receiving the request for reporting change of UE presence in Presence Reporting Area, and the MME decides not to activate reporting UE presence in one or more of the received Presence Reporting Area(s), the MME reports also the inactive Presence Reporting Area(s) in this message. The RAT type information element is included if the UE is using the LTE-M RAT type. If PDN-GW expects the LTE-M RAT type reporting as specified in clause 5.11.5, the MME also includes the LTE-M RAT type reporting to PGW flag to indicate that the Serving-GW needs to forward the LTE-M RAT type to the PGW.

If the Handover Indication is included in step 23, the Serving-GW sends a Modify Bearer Request (Handover Indication) message to the PDN-GW to prompt the PDN-GW to tunnel packets from non 3GPP IP access to 3GPP access system and immediately start routing packets to the Serving-GW for the default and any dedicated EPS bearers established. If Presence Reporting Area Information is included in step 23, the Serving-GW sends a Modify Bearer Request (Presence Reporting Area Information) message to the PDN-GW. If the LTE-M RAT type and the LTE-M RAT type reporting to PGW flag were received at step 23, the Serving-GW shall include the LTE-M RAT type in the Modify Bearer Request message to the PGW. Otherwise the Serving-GW includes RAT type WB-E-UTRAN.

The PDN-GW acknowledges by sending Modify Bearer Response to the Serving-GW.

The Serving-GW acknowledges by sending Modify Bearer Response (EPS Bearer Identity) message to the new MME. The Serving-GW can then send its buffered downlink packets. If there is a "Availability after DDN Failure" monitoring event or a "UE Reachability" monitoring event configured for the UE in the EMM Context of the MME, the MME sends an event notification (see TS 23.682 for further information).

After the MME receives Modify Bearer Response (EPS Bearer Identity) message, if Request Type does not indicate handover and an EPS bearer was established and the subscription data indicates that the user is allowed to perform handover to non-3GPP accesses, and if the MME selected a PDN-GW that is different from the PDN-GW identity which was indicated by the HSS in the PDN subscription context, the MME shall send a Notify Request including the APN and PDN-GW identity to the HSS for mobility with non-3GPP accesses. The message shall include information that identifies the PLMN in which the PDN-GW is located. If the ME identity of the UE has changed and step 8 has not been performed, the MME sends a Notify Request (ME Identity) message to inform the HSS of the updated ME identity. For an unauthenticated or roaming UE, if the Request Type of the UE requested connectivity procedure indicates "Emergency", the MME shall not send any Notify Request to an HSS. For a non-roaming authenticated UE, based on operator configuration (e.g. on whether Voice over WLAN is supported or not by the operator, on whether the operator uses a fixed PDN-GW for emergency calls, etc.), if the Request Type indicates "Emergency", the MME may send a Notify Request to the HSS including the "PDN-GW currently in use for emergency services", which comprises the PDN-GW address and an indication that the PDN connection is for emergency services. The HSS shall store it as part of the UE context for emergency services. For any UEs, if Request Type of the UE requested connectivity procedure indicates "RLOS", the MME shall not send any Notify Request to an HSS. After step 8, and in parallel to any of the preceding steps, the MME shall send a Notify Request (Homogeneous Support of IMS Voice over PS Sessions) message to the HSS:

• If the MME has evaluated the support of IMS Voice over PS Sessions, see clause 4.3.5.8, and
• If the MME determines that it needs to update the Homogeneous Support of IMS Voice over PS Sessions, see clause 4.3.5.8A.

In the case of non-emergency services, the HSS stores the APN and PDN-GW identity pair. In the case of emergency services, the HSS stores the "PDN-GW currently in use for emergency services". The HSS then sends a Notify Response to the MME.