Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.401  Word version:  17.2.0

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

 

5.10  Multiple-PDN support and PDN activation for UEs supporting "Attach without PDN connectivity"Word‑p. 338

5.10.1  GeneralWord‑p. 338

The EPS shall support simultaneous exchange of traffic to multiple PDNs through the use of separate PDN GWs or a single PDN GW. The usage of multiple PDNs is controlled by network policies and defined in the user subscription EPS Optimisation.
The EPS shall support UE-initiated connectivity establishment in order to allow multiple PDN connections to one or more PDNs. It shall be possible for a UE to initiate disconnection from any PDN.
All simultaneously active PDN connections of a UE that are associated with the same APN shall be provided by the same PDN-GW.
UE support for multiple PDN connections is optional.
If the Control Plane CIoT EPS Optimisation is supported:
  • a PDN connection of Non-IP PDN Type may also be served by an SCEF (see TS 23.682); multiple PDN connections of Non-IP PDN Type may be served by the same or multiple SCEFs; and
  • the MME decides, based on APN Configuration information, whether a PDN connection is served by an SCEF or a PDN GW.
Up

5.10.2  UE requested PDN connectivityWord‑p. 339

The UE requested PDN connectivity procedure for an E-UTRAN is depicted in Figure 5.10.2-1. The procedure allows the UE to request for connectivity to an additional PDN over E-UTRAN including allocation of a default bearer, if the UE already has active PDN connections over E-UTRAN. This procedure may also be used when a UE has set "Attach without PDN Connectivity is supported" in the Preferred Network behaviour at attach time and the network has acknowledged its support to the UE. If so, the UE may remain attached without a Default PDN connection and, at any time, request a PDN connection to be established. This procedure is also used to request for connectivity to an additional PDN over E-UTRAN, if the UE is simultaneously connected to E-UTRAN and a non-3GPP access and the UE already has active PDN connections over both accesses. The PDN connectivity procedure may trigger one or multiple Dedicated Bearer Establishment procedures to establish dedicated EPS bearer(s) for that UE.
An emergency attached or RLOS attached UE shall not initiate any PDN Connectivity Request procedure. A normal attached UE shall request a PDN connection for emergency services when Emergency Service is required and an emergency PDN connection is not already active.
The UE supporting 15 EPS bearers as defined in clause 4.12 shall not initiate a UE requested PDN connectivity procedure if it has already 8 EPS bearers established and the UE has not received an Indication for support of 15 EPS bearers per UE or has received cause #65 "maximum number of EPS bearers reached".
Reproduction of 3GPP TS 23.401, Figure 5.10.2-1: UE requested PDN connectivity
Up
Step 1.
The UE initiates the UE Requested PDN procedure by the transmission of a PDN Connectivity Request (APN, PDN Type, Protocol Configuration Options, Request Type, Header Compression Configuration) message. If the UE was in ECM-IDLE mode, this NAS message is preceded by the Service Request procedure if any of the exiting PDN connections were using the User Plane without CIoT EPS Optimisation, or, if the user plane was used just with User Plane CIoT EPS Optimisations, a Connection Resume Procedure is executed instead. PDN type indicates the requested IP version (IPv4, IPv4v6, IPv6, Non-IP, Ethernet).
The MME verifies that the APN provided by UE is allowed by subscription. If the APN provided by the UE is not allowed by subscription, based on operator policy, the MME may reject the request from the UE with an appropriate cause, or accept the 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 UE did not provide an APN, the MME shall use the APN from the default PDN subscription context, and, use this APN for the remainder of this procedure.
Protocol Configuration Options (PCO) are used to transfer parameters between the UE and the Network and are sent transparently through the MME and the Serving GW. The Protocol Configuration Options may include the Address Allocation Preference, which indicates that the UE prefers to obtain an IPv4 address only after the default bearer activation by means of DHCPv4. 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. The Request Type indicates "initial request" if the UE requests new additional PDN connectivity over the 3GPP access network for multiple PDN connections, the Request Type indicates "handover" when the UE is performing a handover from non-3GPP access and the UE has already established connectivity with the PDN over the non-3GPP access.
The UE shall indicate Request Type "Emergency" when it requests a PDN connection for emergency services.
If the message is being sent via a HeNB which has a collocated L-GW, it includes the L-GW address in the Uplink NAS transport message to the MME.
If a UE indicated Control Plane CIoT EPS Optimisation supported in Preferred Network Behaviour and supports header compression, it shall include the Header Compression Configuration, unless "Non-IP" or "Ethernet" PDN type is indicated. The Header Compression Configuration includes the information necessary for the ROHC channel setup. Optionally, the Header Compression Configuration may also include additional header compression context setup parameters, if the UE already has the application traffic information, e.g. the target server IP address.
The UE 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.
Step 2.
If the MME receives a PDN Connectivity Request from an emergency attached or RLOS attached UE or the PDN Connectivity Request is for normal services and the mobility or access restrictions do not allow the UE to access normal services the MME shall reject this request.
If the Request Type indicates "Emergency" and the MME is not configured to support PDN connections for emergency services the MME shall reject the PDN Connectivity Request with an appropriate reject cause.
If the Request Type is not set to "Emergency", 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 MME should reject the PDN Connectivity Request with an appropriate cause value.
If the Request Type indicates "Emergency", the MME derives a PDN GW from the MME Emergency Configuration Data or the MME selects a PDN GW as described in clause 4.3.12.4 on PDN GW Selection Function (3GPP accesses) according to the Emergency APN in the MME Emergency Configuration Data. This selection shall provide a PDN GW from visited PLMN only.
If the Request Type indicates "Emergency" and the MME is configured to support PDN connections for emergency services, it uses the MME Emergency Configuration Data for the bearer establishment in this step and ignores any subscription data limitation.
If the Request Type indicates "Handover", the MME uses the PDN GW stored in the Subscription Data retrieved by the MME during the Update Location performed at attach. If the Request Type indicates "initial request" the MME selects a PDN GW as described in clause 4.3.8.1 on PDN GW Selection Function (3GPP accesses).
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.
If the subscription context does not indicate that the APN is for a PDN connection to an SCEF the MME allocates a Bearer Id, and sends a Create Session Request (IMSI, MSISDN, MME TEID for control plane, RAT type, LTE-M RAT type reporting to PGW flag, PDN GW address, PDN Address, Default EPS Bearer QoS, PDN Type, subscribed APN-AMBR, APN, EPS Bearer Id, Protocol Configuration Options, Handover Indication, ME Identity, 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) message to the 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.
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.
For PDN type "non-IP", if the 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 established connection to the SCEF address indicated in subscription data according to TS 23.682 and the steps 2,3,4,5,6 are not executed. The rest of the interactions with the UE apply as specified below.
The RAT type is provided in this message for the later PCC decision. The RAT type shall enable NB-IoT, LTE-M and WB-E-UTRAN to be differentiated by the PDN-GW The MSISDN is included if the MME has it stored for that UE. 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. The P-GW may use Selection Mode when deciding whether to accept or reject the default bearer activation. For example, if an APN requires subscription, the P-GW is configured to accept only the default bearer activation that requests a subscribed APN as indicated by Selection Mode. Charging Characteristics indicates which kind of charging the bearer context is liable for.
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 PDN subscription context contains a subscribed IPv4 address and/or IPv6 prefix, the MME indicates it in the PDN address. 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.
If there is an APN Rate Control Status in the MME MM Context for the UE, the MME forwards it to the SGW.
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.
Step 3.
The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI, MSISDN, 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, APN, Bearer Id, 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, APN Rate Control Status) message to the PDN GW indicated in 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 until receives the message in step 13 below. The MSISDN is included if received from the MME. If the Handover Indication is included, the Serving GW includes it in the Create Session Request message.
If the Serving GW has received the Control Plane Only PDN Connection Indicator in step 2, 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.
P-GWs shall not perform any checks of Maximum APN Restriction if Create Default Bearer Request includes emergency APN.
If the PDN GW detects that the 3GPP PS Data Off UE Status has changed, the PDN GW shall indicate this event to the charging system for offline and online charging.
Step 4.
If dynamic PCC is deployed and the Handover Indication is not present, the PDN GW may employ an IP-CAN Session Establishment procedure as defined in TS 23.203 with the PCRF to get the default PCC rules for the UE. 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 RAT type is provided to the PCRF by the PDN GW if received by the previous message. If the PDN GW/PCEF is configured to activate predefined PCC rules for the default bearer, the interaction with the PCRF is not required (e.g. operator may configure to do this) at the moment.
The ETFTU is provided to the PCRF by the PDN GW, if received in the PCO from the UE and the PDN GW supports the extended TFT filter format. If the PCRF decides that the PDN connection may use extended TFT filters, 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 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 TS 23.203. If dynamic PCC is not deployed, the PDN GW is configured to set the ARP to a value that is reserved for emergency services.
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 bearer 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. 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.
If the 3GPP PS Data Off UE Status indicates that 3GPP PS Data Off is activated for the UE, the PDN GW shall enforce the PCC rules for downlink traffic to be used when 3GPP PS Data Off is activated.
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.
Step 5.
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 Id, 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 are 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, the PDN GW uses the PDN type if it is supported in the PDN, otherwise an appropriate error cause will be returned. 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. PDN Address may contain an IPv4 address for IPv4 and/or an IPv6 prefix and an Interface Identifier. 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 address shall be negotiated by the UE with 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 IP6 prefix contained in the PDN address to the UE. If Handover Indication indicates "Handover", the PDN Address Information shall contain the same IP address the UE obtained during PDN connectivity establishment over the non-3GPP access. 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.
If the PDN type is Non-IP or Ethernet, the PDN-GW uses the APN and IMSI to determine what local actions to perform before answering the Serving GW.
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 13a.
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 10 via the direct user plane path for Local IP Access.
If the 3GPP PS Data Off UE Status was present in the Create Session Request PCO, and if the network supports 3GPP PS Data Off, the PDN GW shall include the 3GPP PS Data Off Support Indication in the Create Session Response PCO.
Step 6.
The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving GW address for User Plane, Serving GW TEID for User Plane, Serving GW TEID for control plane, EPS Bearer Id, EPS Bearer QoS, PDN GW address and TEID (GTP-based S5/S8) or GRE key (PMIP-based S5/S8) at the PDN GW for uplink traffic, Protocol Configuration Options, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action (Start), CSG Information Reporting Action (Start), Presence Reporting Area Action, APN-AMBR, DTC) message to the MME. The DL TFT for PMIP-based S5/S8 is obtained from interaction between the Serving GW and the PCRF as described in clause 5.6.1 of TS 23.402, when PCC is deployed; otherwise, the DL TFT IE is wildcarded, matching any downlink traffic. If the UE indicates the Request Type as "Handover", this message also serves as an indication to the MME that the S5/S8 bearer setup and update has been successful. At this step the GTP tunnel(s) over S5/S8 are established
If Control Plane CIoT EPS Optimisation applies, and if MME doesn't 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 the 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.
Step 7.
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 consequence of this check results in the PDN connectivity being rejected, the MME shall initiate a Bearer Deactivation and return an appropriate error cause. If the PDN Connectivity Request 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.
The P-GW shall ignore Maximum APN restriction if the request includes the Emergency APN.
For emergency service MME shall not deactivate bearer(s), if present, to maintain valid APN restriction combination.
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 Information 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 may need to modify the UE AMBR, which has been assigned to the eNodeB, based on the subscribed UE-AMBR and the updated set of APN-AMBRs in use. The principles to determine the UE-AMBR are described in clause 4.7.3.
The MME sends PDN Connectivity Accept Session Management Request (APN, PDN Type, PDN Address, EPS Bearer Id, Protocol Configuration Options, Header Compression Configuration, Control Plane Only Indicator) message to the UE. If the PDN connection uses the user plane over the radio, this message is contained in an S1_MME control message Bearer Setup Request (EPS Bearer QoS, UE-AMBR, PDN Connectivity Accept, S1-TEID) to the eNodeB. However, if Control Plane CIoT EPS Optimisation applies to the PDN connection, an S1-AP Downlink NAS transport message is used. The S1-AP Initial Context Setup Request message includes the TEID at the Serving GW used for user plane and the address of the Serving GW for user plane. 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 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.
In the PDN Connectivity Accept message, the MME does not include the IPv6 prefix within the PDN Address. The MME includes the APN-AMBR and the EPS Bearer QoS parameter QCI 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 parameters 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 that it does not support BSS packet flow procedures, then the MME shall not include the Packet Flow Id. MME will not send the S1 Bearer Setup Request message until any outstanding S1 Bearer Setup Response message for the same UE has been received or timed out. If the APN-AMBR has changed the MME may update the UE-AMBR if appropriate. 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. If the UE has indicated PDN type "Non-IP" or "Ethernet", the MME and PDN GW shall not change PDN type.
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 Control Plane CIoT EPS Optimisation applies for an IP PDN connection, and the UE has sent in the PDN Connectivity Request the Header Compression Configuration, 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 ROHC context setup parameters in Header Compression Configuration in the PDN Connectivity Request, the MME may acknowledge ROHC context setup parameters. If the ROHC context is not established during the PDN connection establishment procedure, 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. If there is an existing SGi PDN connection for this UE for which the MME included a Control Plane Only Indicator, the MME shall include it also for the additional SGi PDN connection. If the MME did not include a Control Plane Only Indicator for any of the existing SGi PDN connections of this UE, the MME shall not include it for the additional SGi PDN connection. 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.
Step 8.
If the eNodeB received an S1-AP Initial Context Setup Request, the eNodeB sends RRC Connection Reconfiguration to the UE including the PDN Connectivity Accept message.
If the eNodeB received an S1-AP Downlink NAS Transport message containing the NAS PDN Connectivity Accept message, the eNode B sends a RRC Direct Transfer message to the UE and the steps 9 and 10 are not executed.
The UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id and TI, which it received in the Session Management Request IE, for use when accessing via GERAN or UTRAN. The UE may provide EPS Bearer QoS parameters to the application handling the traffic flow. 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 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.
Step 9.
The UE sends the RRC Connection Reconfiguration Complete to the eNodeB.
Step 10.
The eNodeB send an S1-AP Bearer Setup Response to the MME. The S1-AP message includes the TEID of the eNodeB and the address of the eNodeB used for downlink traffic on the S1_U reference point.
If the Correlation ID or SIPTO Correlation ID is included in the Bearer Setup Request, the eNodeB shall use the included information to establish a direct user plane path to 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.
Step 11.
The UE NAS layer builds a PDN Connectivity Complete message including EPS Bearer Identity. The UE then sends a Direct Transfer (PDN Connectivity Complete) message to the eNodeB.
Step 12.
The eNodeB sends an Uplink NAS Transport (PDN Connectivity Complete) message to the MME.
After the PDN Connectivity Accept message and once the UE (if applicable to the PDN type) has obtained a PDN Address Information, the UE can then send uplink packets towards the eNodeB which may then be tunnelled by the MME to the Serving GW and PDN GW, or transferred by the MME to an SCEF (see TS 23.682), as per subscription information related to APN discussed above in step 2. 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, 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 8 in response to a 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.
Step 13.
Upon reception of the Bearer Setup Response message in step 10 and the PDN Connectivity Complete message in step 12, the MME sends a Modify Bearer Request (EPS Bearer Identity, eNodeB address, eNodeB TEID, Handover Indication, Presence Reporting Area Information) message to the Serving GW. If the Control Plane CIoT EPS Optimisation applies and the PDN connection is not served via a SCEF type of connectivity, steps 13 and 14 are executed only if the MME needs to report a change of UE presence in Presence Reporting Area, otherwise, if the PDN connection is served by SCEF, steps 13,14, 15, and 16 are not executed. If Request Type indicates "handover", the Handover Indication is also included. 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.
Step 13a.
If the Handover Indication is included in step 13, 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 13, the Serving GW sends a Modify Bearer Request (Presence Reporting Area Information) message to the PDN GW.
Step 13b.
The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW.
Step 14.
The Serving GW acknowledges by sending Modify Bearer Response (EPS Bearer Identity) to the MME. The Serving GW can then send its buffered downlink packets.
Step 15.
After the MME receives Modify Bearer Response in step 14, if Request type does not indicate handover and an EPS bearer was established and if the subscription data indicates that the user is allowed to perform handover to non-3GPP accesses and if this is the first PDN connection associated with this APN and if the MME selected a PDN GW that is different from the PDN GW identity which was previously indicated by the HSS in the PDN subscription context, the MME shall send a Notify Request including the PDN GW address and the APN 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.
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 the 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), 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.
Step 16.
In the case of non-emergency services, the HSS stores the PDN GW identity and the associated APN. In the case of emergency services, the HSS stores the "PDN GW currently in use for emergency services". Then the HSS sends a Notify Response to the MME.
Up

5.10.3  UE or MME requested PDN disconnectionWord‑p. 347

The UE or MME requested PDN disconnection procedure for an E-UTRAN is depicted in Figure 5.10.3-1. The procedure allows the UE to request for disconnection from one PDN. Bearers including the default bearer of this PDN shall be deleted during this procedure. The procedure also allows the MME to initiate the release of a PDN connection.
This procedure is also used as part of the SIPTO function when the MME determines that GW relocation is desirable. In this situation the MME deactivates the PDN connection(s) relevant to SIPTO-allowed APN(s) using the "reactivation requested" cause value, and the UE should then re-establish those PDN connection(s).
It shall be possible to configure the MME to deactivate a PDN connection, for PDN GW relocation due to SIPTO above RAN, only when UE is in ECM-IDLE mode or during a Tracking Area Update procedure without established RAB(s).
This procedure is not used to terminate the last PDN connection unless "Attach without PDN Connectivity is supported" in the Preferred Network behaviour indicated by the UE at attach time is supported by the network and the UE at any time it requires the last PDN connection to be disconnected. The UE uses the UE-initiated Detach procedure in clause 5.3.8.2 to disconnect the last PDN connection. The MME uses the MME-initiated Detach procedure in clause 5.3.8.3 to release the last PDN connection.
Reproduction of 3GPP TS 23.401, Figure 5.10.3-1: UE or MME requested PDN disconnection
Up
Step 1.
The procedure is triggered by either step 1a or step 1b.
Step 1a.
The UE initiates the UE requested PDN disconnection procedure by the transmission of a PDN Disconnection Request (LBI) message. The LBI indicates the default bearer associated with the PDN connection being disconnected. If the UE was in ECM-IDLE mode, this NAS message is preceded by the Service Request procedure if any of the exiting PDN connections were using the User Plane without CIoT EPS Optimisation, or, if the user plane was used just with User Plane CIoT EPS Optimisations, a Resume Procedure is executed instead.
Step 1b.
The MME decides to release the PDN connection. This may be e.g. due to change of subscription, lack of resources, due to SIPTO if the PDN connection serves a SIPTO-allowed APN or on receiving a PDN GW Restart Notification from the Serving GW as specified in TS 23.007. If the UE is in ECM-IDLE state and the reason for releasing PDN connection is "reactivation requested" e.g. due to SIPTO, the MME initiates paging via Network Triggered Service Request procedure in clause 5.3.4.3 from step 3a onwards in order to inform UE of the request.
Step 2.
If the PLMN has configured secondary RAT usage reporting, the MME shall perform step 7 through 10 before step 2 onwards. If the PDN connection was served by a P-GW, the EPS Bearers in the Serving GW for the particular PDN connection are deactivated by the MME by sending Delete Session Request (Cause, LBI, User Location Information (ECGI), Secondary RAT usage data) to the Serving GW. This message indicates that all bearers belonging to that PDN connection shall be released. If the UE Time Zone has changed, the MME includes the UE Time Zone IE in this message. For PDN connection to the SCEF the MME indicates to the SCEF the connection for the UE is no longer available according to TS 23.682 and steps 2,3,4,5,6 are not executed. If the MME received Secondary RAT usage data in step 9b, the MME shall include it in this Delete Session Request message.
Step 3.
The Serving GW sends Delete Session Request (Cause, LBI, User Location Information (ECGI), Secondary RAT usage data) to the PDN GW. The S-GW also includes User Location Information IE and/or UE Time Zone IE if it is present in step 2. The Serving GW also includes the Secondary RAT usage data in this message if it was present in step 2 and if PDN GW secondary RAT usage data reporting is active.
Step 4.
The PDN GW acknowledges with Delete Session Response (optionally, APN Rate Control Status).
Step 5.
The PDN GW employs the PCEF-initiated IP-CAN Session Termination procedure as defined in TS 23.203 to indicate to the PCRF that the IP-CAN session is released if PCRF is applied in the network. If requested the PDN GW indicates User Location Information and/or UE Time Zone Information to the PCRF as defined in TS 23.203.
Step 6.
The Serving GW acknowledges with Delete Session Response (optionally, APN Rate Control Status).
If received, the MME stores the APN Rate Control Status in the MM context.
Step 7.
If the UE is in ECM IDLE state and the PDN disconnection is decided by the MME, the MME shall delete the corresponding contexts of the PDN connection locally, steps 7 to 10b are skipped except if the MME has decided to restore certain PDN connections as specified in TS 23.007 or for other reasons e.g. SIPTO. The MME initiates the deactivation of all Radio Bearers associated with the PDN connection to the eNodeB by sending the Deactivate Bearer Request message to the eNodeB. The MME shall re-calculate the UE-AMBR (see clause 4.7.3). This S1-AP message carries the list of EPS bearers to be released, the new UE-AMBR, and a NAS Deactivate EPS Bearer Context Request (LBI) message. The MME builds a NAS message Deactivate EPS Bearer Context Request including the EPS Bearer Identity, and includes it in the S1-AP Deactivate Bearer Request message.
If the network wants to trigger GW relocation (e.g. for SIPTO), the NAS message Deactivate EPS Bearer Context Request includes the request for reactivation of the same PDN connection via the same APN by the UE.
If the MME released the PDN connection due to failed bearer set up during handover, the UE and the MME deactivate the failed contexts locally without peer-to peer ESM signalling.
Step 8.
The eNodeB sends the RRC Connection Reconfiguration message including the corresponding bearers to be released and the NAS Deactivate EPS Bearer Context Request (LBI) message to the UE.
Step 9a.
The UE releases all resources corresponding to the PDN connection and acknowledges this by sending the RRC Connection Reconfiguration Complete message to the eNodeB.
Step 9b.
The eNodeB sends an acknowledgement of the deactivation to the MME. If the PLMN has configured secondary RAT usage reporting and the eNodeB has Secondary RAT usage data to report, the Secondary RAT usage data is included.
Step 10a.
The UE NAS layer builds a Deactivate EPS Bearer Context Accept message. The UE then sends a Direct Transfer (Deactivate EPS Bearer Context Accept) message to the eNodeB.
If the Deactivate EPS Bearer Context Request message from the MME indicated reactivation requested, the UE starts the UE initiated PDN connection request procedure as specified in clause 5.10.2 by using the same APN of the released PDN connection.
Step 10b.
The eNodeB sends an Uplink NAS Transport (Deactivate EPS Bearer Context Accept) message to the MME.
The MME determines the Maximum APN Restriction for the remaining PDN connections and stores this new value for the Maximum APN Restriction.
Up

5.10.4  MME triggered Serving-GW relocation |R12|Word‑p. 350

The MME triggered Serving GW relocation procedure for E-UTRAN is depicted in Figure 5.10.4-1. The procedure allows the MME to trigger Serving GW relocation due to events other than those described in the mobility scenarios (see clause 5.3.3.1 and clause 5.5.1). Such scenario exists during the establishment of a SIPTO at local network PDN connection with stand-alone GW or during the establishment of a SIPTO above RAN PDN connection.
Reproduction of 3GPP TS 23.401, Figure 5.10.4-1: MME triggered Serving GW relocation
Up
Step 1.
The Serving GW relocation procedure may be triggered by the MME due to events that may benefit from a Serving GW relocation other than those described in the mobility events scenarios.
Step 2.
If the MME determines that the Serving GW is to be relocated then it selects a new Serving GW according to clause 4.3.8.2. The MME sends a Create Session Request (bearer context(s) with PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, eNodeB address(es) and TEIDs for downlink user plane for the existing EPS bearers, the Protocol Type over S5/S8, Serving Network) message per PDN connection to the new Serving GW. The new Serving GW allocates the S-GW addresses and TEIDs for the uplink traffic on S1_U reference point (one TEID per bearer). The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. If the PDN GW requested UE's location info, the MME also includes the User Location Information IE in this message. If the PDN GW requested UE's User CSG information (determined from the UE context), the MME includes the User CSG Information IE in this message if the User CSG Information has changed.
Step 3.
The new Serving GW assigns addresses and TEIDs (one per bearer) for downlink traffic from the PDN GW. The Serving GW allocates DL TEIDs on S5/S8. It sends a Modify Bearer Request (Serving GW addresses for user plane and TEID(s), Serving Network) message per PDN connection to the PDN GW(s). The S-GW also includes User Location Information IE and/or UE Time Zone IE and/or User CSG Information IE if it is present in step 2. The PDN GW updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN, etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. The PDN GW starts sending downlink packets to the new GW using the newly received address and TEIDs. These downlink packets will use the new downlink path via the new Serving GW to the eNodeB. This step is performed for all connected PDN-GWs for that specific UE.
Step 4.
The new Serving GW sends a Create Session Response (Serving GW addresses and uplink TEID(s) for user plane) message back to the MME. The MME starts a timer, to be used in step 6.
Step 5.
The MME sends a Bearer Modify Request (Serving GW addresses and uplink TEID(s) for user plane, Secondary RAT usage data request) message to eNodeB. The eNodeB starts using the new Serving GW address(es) and TEID(s) for forwarding subsequent uplink packets and sends a Bearer Modify Response message to the MME. If the PLMN has configured secondary RAT usage reporting, the MME may request the eNodeB for Secondary RAT usage data in the Bearer Modify request message. If the eNodeB has Secondary RAT usage data, it provides it in the Bearer Modify Response message.
Step 5a.
If Secondary RAT usage data is included in the previous message and if PDN GW Secondary RAT usage reporting is active, the MME uses the Secondary RAT usage data reporting procedure as described in clause 5.7A.3 Figure 5.7A.3-2 to provide this information to the Serving GW and PDN GW. The MME includes a flag that the Serving GW shall not process this information and forward it to the PDN GW.
Step 6.
When the timer has expired after step 4, the MME releases the bearer(s) in the old Serving GW by sending a Delete Session Request message (Cause, Operation Indication, Secondary RAT usage data). The operation Indication flag is not set, that indicates to the old Serving GW that the old Serving GW shall not initiate a delete procedure towards the PDN GW. The old Serving GW acknowledges with Delete Session Response messages. The MME includes the Secondary RAT usage data if the eNodeB had provided it to the MME in step 5.
If the Serving GW relocation procedure towards a new Serving GW fails, based on operator policy, the MME should go back to the old Serving GW and disconnects the affected PDN connections (e.g. SIPTO at local network) that are no longer allowed to remain connected.
Up

Up   Top   ToC