Content for  TS 23.401  Word version:  18.6.0

The PDN-GW selection function allocates a PDN-GW that shall provide the PDN connectivity for the 3GPP access. The function uses subscriber information provided by the HSS and possibly additional criteria such as SIPTO/LIPA support per APN configured in the SGSN/MME, UE support for dual connectivity with NR, 15 EPS bearers support by the UE, CIoT EPS Optimisation(s) impacting PDN-GW e.g. Non-IP support, Ethernet support, NB-IoT RAT support (for generation of accounting information), etc. The criteria for PDN-GW selection may include load balancing between PDN-GWs. When the PDN-GW IP addresses returned from the DNS server include Weight Factors, the MME should use it if load balancing is required. The Weight Factor is typically set according to the capacity of a PDN-GW node relative to other PDN-GW nodes serving the same APN. For further details on the DNS procedure see TS 29.303. When the MME supports the GTP-C Load Control feature, it takes into account the Load Information received from the PDN-GW in addition to the Weight Factors received from the DNS server to perform selection of an appropriate PDN-GW. The PDN subscription contexts provided by the HSS contain:

• the identity of a PDN-GW and an APN (PDN subscription contexts with subscribed PDN-GW address are not used when there is interoperation with pre Rel-8 2G/3G SGSN), or
• an APN and an indication for this APN whether the allocation of a PDN-GW from the visited PLMN is allowed or whether a PDN-GW from the home PLMN shall be allocated. Optionally an identity of a PDN-GW may be contained for handover with non-3GPP accesses.
• optionally for an APN, an indication of whether SIPTO above RAN, or SIPTO at the Local Network, or both, is allowed or prohibited for this APN.
• optionally for an APN, an indication of whether LIPA is conditional, prohibited, or only LIPA is supported for this APN.

In the case of static address allocation, a static PDN-GW is selected by either having the APN configured to map to a given PDN-GW, or the PDN-GW identity provided by the HSS indicates the static PDN-GW. The HSS also indicates which of the PDN subscription contexts is the Default one for the UE. To establish connectivity with a PDN when the UE is already connected to one or more PDNs, the UE provides the requested APN for the PDN-GW selection function. If one of the PDN subscription contexts provided by the HSS contains a wild card APN (see TS 23.003), a PDN connection with dynamic address allocation may be established towards any APN requested by the UE. An indication that SIPTO (above RAN, at the local network, or both) is allowed or prohibited for the wild card APN allows or prohibits SIPTO for any APN that is not present in the subscription data. If the HSS provides the identity of a statically allocated PDN-GW, or the HSS provides the identity of a dynamically allocated PDN-GW and the Request Type indicates "Handover", no further PDN-GW selection functionality is performed. If the HSS provides the identity of a dynamically allocated PDN-GW, the HSS also provides information that identifies the PLMN in which the PDN-GW is located. If the HSS provides the identity of a dynamically allocated PDN-GW and the Request Type indicates "initial Request", either the provided PDN-GW is used or a new PDN-GW is selected. When a PDN connection for an APN with SIPTO-allowed is requested, the PDN-GW selection function shall ensure the selection of a PDN-GW that is appropriate for the UE's location. The PDN-GW identity refers to a specific PDN-GW. If the PDN-GW identity includes the IP address of the PDN-GW, that IP address shall be used as the PDN-GW IP address; otherwise the PDN-GW identity includes an FQDN which is used to derive the PDN-GW IP address by using Domain Name Service function, taking into account the protocol type on S5/S8 (PMIP or GTP). If the HSS provides a PDN subscription context that allows for allocation of a PDN-GW from the visited PLMN for this APN and, optionally, the MME is configured to know that the visited VPLMN has a suitable roaming agreement with the HPLMN of the UE, the PDN-GW selection function derives a PDN-GW identity from the visited PLMN. If a visited PDN-GW identity cannot be derived, or if the subscription does not allow for allocation of a PDN-GW from the visited PLMN, then the APN is used to derive a PDN-GW identity from the HPLMN. The PDN-GW identity is derived from the APN, subscription data and additional information by using the Domain Name Service function. If the PDN-GW identity is a logical name instead of an IP address, the PDN-GW address is derived from the PDN-GW identity, protocol type on S5/S8 (PMIP or GTP) by using the Domain Name Service function. The S8 protocol type (PMIP or GTP) is configured per HPLMN in MME/SGSN. In order to select the appropriate PDN-GW for SIPTO above RAN service, the PDN-GW selection function uses the TAI (Tracking Area Identity), the serving eNodeB identifier, or TAI together with serving eNodeB identifier depending on the operator's deployment during the DNS interrogation as specified in TS 29.303 to find the PDN-GW identity. In roaming scenario PDN-GW selection for SIPTO is only possible when a PDN-GW in the visited PLMN is selected. Therefore in a roaming scenario with home routed traffic, PDN-GW selection for SIPTO is not performed. In order to select the appropriate GW for SIPTO at the local network service with a stand-alone GW (with S-GW and L-GW collocated), the PDN-GW selection function uses the APN and the Local Home Network ID during the DNS interrogation as specified in TS 29.303 to find the PDN-GW identity. The Local Home Network ID is provided to the MME by the (H)eNB in every INITIAL UE MESSAGE and every UPLINK NAS TRANSPORT control message as specified in TS 36.413. The MME uses the Local Home Network ID to determine if the UE has left its current local network and if S-GW relocation is needed. For SIPTO at the Local Network with L-GW function collocated with the (H)eNB the PDN-GW selection function uses the L-GW address proposed by the (H)eNB in the S1-AP message, instead of DNS interrogation. In order to select the appropriate L-GW for LIPA service, if permitted by the CSG subscription data and if the UE is roaming, the VPLMN LIPA is allowed, the PDN-GW selection function uses the L-GW address proposed by HeNB in the S1-AP message, instead of DNS interrogation. If no L-GW address is proposed by the HeNB and the UE requested an APN with LIPA permissions set to "LIPA-only", the request shall be rejected. If no L-GW address is proposed by the HeNB and the UE requested an APN with LIPA permissions set to "LIPA-conditional", the MME uses DNS interrogation for PDN-GW selection to establish a non-LIPA PDN connection. The PDN subscription context for an APN with LIPA permissions set to "LIPA-only" shall not contain a statically configured PDN address or a statically allocated PDN-GW. A static PDN address or a static PDN-GW address, if configured by HSS for an APN with LIPA permissions set to "LIPA-conditional", is ignored by MME when the APN is established as a LIPA PDN connection. When establishing a PDN connection for a LIPA APN, the VPLMN Address Allowed flag is not considered. The PDN-GW domain name shall be constructed and resolved by the method described in TS 29.303, which takes into account any value received in the APN-OI Replacement field for non-roaming or home routed traffic. Otherwise, or when the resolution of the above PDN-GW domain name fails, the PDN-GW domain name shall be constructed by the serving node using the method specified in Annex A of TS 23.060, and clause 9 of TS 23.003. If the Domain Name Service function provides a list of PDN-GW addresses, one PDN-GW address is selected from this list. If the selected PDN-GW cannot be used, e.g. due to an error, then another PDN-GW is selected from the list. The specific interaction between the MME/SGSN and the Domain Name Service function may include functionality to allow for the retrieval or provision of additional information regarding the PDN-GW capabilities (e.g. whether the PDN-GW supports PMIP-based or GTP-based S5/S8, or both). If the UE provides an APN for a PDN, this APN is then used to derive the PDN-GW identity as specified for the case of HSS provided APN if one of the subscription contexts allows for this APN. If there is an existing PDN connection to the same APN used to derive the PDN-GW address, the same PDN-GW shall be selected. As part of PDN-GW selection, an IP address of the assigned PDN-GW may be provided to the UE for use with host based mobility as defined in TS 23.402, if the PDN-GW supports host-based mobility for inter-access mobility towards accesses where host-based mobility can be used. If a UE explicitly requests the address of the PDN-GW and the PDN-GW supports host based mobility then the PDN-GW address shall be returned to the UE. When DCNs with dedicated PDN-GWs are used, the DNS procedure (TS 29.303) for PDN-GW selection may be used such that a PDN-GW belonging to a DCN serving a particular category of UEs, e.g. identified by UE Usage Type, is selected. When UEs with the same UE Usage type are served by multiple DCNs, it shall also be possible to select the PDN-GW belonging to the DCN serving the particular UE.

The Serving-GW selection function selects an available Serving-GW to serve a UE. The selection bases on network topology, i.e. the selected Serving-GW serves the UE's location and for overlapping Serving-GW service areas, the selection may prefer Serving-GWs with service areas that reduce the probability of changing the Serving-GW. When SIPTO is allowed then it is also considered as a criterion for Serving-GW selection, e.g. when the first PDN connection is requested. Other criteria for Serving-GW selection should include load balancing between Serving-GWs, UE support for dual connectivity with NR, CIoT EPS Optimisation(s) impacting Serving-GW e.g. Non-IP support, Ethernet support, NB-IoT RAT support (for generation of accounting information), etc. When the Serving-GW IP addresses returned from the DNS server include Weight Factors, the MME should use it if load balancing is required. The Weight Factor is typically set according to the capacity of a Serving-GW node relative to other Serving-GW nodes serving the same Tracking area. For further details on DNS procedure see TS 29.303. When the MME supports the GTP-C Load Control feature, it takes into account the Load Information received from the Serving-GW in addition to the Weight Factors received from the DNS server to perform selection of an appropriate Serving-GW. If a subscriber of a GTP only network roams into a PMIP network, the PDN-GWs selected for local breakout support the PMIP protocol, while PDN-GWs for home routed traffic use GTP. This means the Serving-GW selected for such subscribers may need to support both GTP and PMIP, so that it is possible to set up both local breakout and home routed sessions for these subscribers. For a Serving-GW supporting both GTP and PMIP, the MME/SGSN should indicate the Serving-GW which protocol should be used over S5/S8 interface. The MME/SGSN is configured with the S8 variant(s) on a per HPLMN granularity. If a subscriber of a GTP only network roams into a PMIP network, the PDN-GWs selected for local breakout may support GTP or the subscriber may not be allowed to use PDN-GWs of the visited network. In both cases a GTP only based Serving-GW may be selected. These cases are considered as roaming between GTP based operators. If combined Serving and PDN-GWs are configured in the network the Serving-GW Selection Function may preferably derive a Serving-GW that is also a PDN-GW for the UE. In order to provide SIPTO at the local network service with stand-alone GW, the L-GW and Serving-GW shall be co-located. The Serving-GW selection function in the MME is used to ensure that the Serving-GW is provided according to operator policy as described in clause 4.3.15a. When the L-GW is collocated with the (H)eNB, the Serving-GW remains located in the mobile operator's core network. The Domain Name Service function may be used to resolve a DNS string into a list of possible Serving-GW addresses which serve the UE's location. The specific interaction between the MME/SGSN and the Domain Name Service function may include functionality to allow for the retrieval or provision of additional information regarding the Serving-GW capabilities (e.g. whether the Serving-GW supports PMIP-based or GTP-based S5/S8, or both). The details of the selection are implementation specific. For handover from non-3GPP accesses in roaming scenario, the Serving-GW selection function for local anchoring is described in TS 23.402. The Serving-GW selection function in the MME is used to ensure that all Tracking Areas in the Tracking Area List belong to the same Serving-GW service area. When DCNs with dedicated Serving-GWs are used, the DNS procedure (TS 29.303) for Serving-GW selection may be used such that a Serving-GW belonging to a DCN serving a particular category of UEs, e.g. identified by UE Usage Type, is selected. When UEs with the same UE Usage type are served by multiple DCNs, it shall also be possible to select the Serving-GW belonging to the DCN serving the particular UE.

The MME selection function selects an available MME for serving a UE. The selection is based on network topology, i.e. the selected MME serves the UE's location and for overlapping MME service areas, the selection may prefer MMEs with service areas that reduce the probability of changing the MME. When a MME/SGSN selects a target MME, the selection function performs a simple load balancing between the possible target MMEs. In networks that deploy dedicated MMEs/SGSNs for UEs configured for low access priority, the possible target MME selected by source MME/SGSN is typically restricted to MMEs with the same dedication. When a MME/SGSN supporting DCNs selects a target MME, the selected target MME should be restricted to MMEs that belong to the same DCN. The DNS procedure may be used by the source CN node to select the target MME from a given DCN. If both low access priority and UE Usage Type parameter are used for MME selection, selection based on UE Usage type parameter overrides selection based on the low access priority indication. When a MME supporting CIoT EPS Optimisation(s) selects a target MME, the selected MME should all support the CIoT EPS Optimisations applicable to the given UE's attachment. if the source MME is unable to find a target MME matching all CIoT EPS Optimisation(s) applicable to a given UE's attachment, then the source MME, based on implementation, selects a target MME which provides the CIoT EPS Optimisation(s) best applicable to that UE's attachment. When an eNodeB selects an MME, the eNodeB may use a selection function which distinguishes if the GUMMEI is mapped from P-TMSI/RAI or is a native GUMMEI. The indication of mapped or native GUMMEI shall be signalled by the UE to the eNodeB as an explicit indication. The eNodeB may differentiate between a GUMMEI mapped from P-TMSI/RAI and a native GUMMEI based on the indication signalled by the UE. Alternatively, the differentiation between a GUMMEI mapped from P-TMSI/RAI and a native GUMMEI may be performed based on the value of most significant bit of the MME Group ID, for PLMNs that deploy such mechanism. In this case, if the MSB is set to "0" then the GUMMEI is mapped from P-TMSI/RAI and if MSB is set to "1", the GUMMEI is a native one. Alternatively the eNodeB makes the selection of MME only based on the GUMMEI without distinguishing on mapped or native. When an eNodeB selects an MME, the selection shall achieve load balancing as specified in clause 4.3.7.2. When an eNodeB selects an MME, the selection shall consider the IAB support capability if the UE includes an IAB-Indication in the RRC connection establishment signalling as defined in TS 36.331. When the UE attempts to establish a signalling connection and the following conditions are met:

• the eNodeB serves more than one country (e.g. it supports E-UTRA satellite access); and
• the eNodeB knows in what country the UE is located; and
• the eNodeB is connected to MMEs serving different PLMNs of different countries; and
• the UE provides an S-TMSI or GUMMEI, which indicates an MME serving a different country to where the UE is currently located; and
• the eNodeB is configured to enforce selection of the MME based on the country the UE is currently located;

then the eNodeB shall select an MME serving a PLMN corresponding to the UE's current location. How the eNodeB selects the MME in this case is defined in TS 36.410. When DCNs are deployed, to maintain a UE in the same DCN when the UE enters a new MME pool area, the eNodeB's NNSF should have configuration that selects, based on the MMEGIs or NRIs of neighbouring pool areas, a connected MME from the same DCN. Alternately, for PLMN wide inter-pool intra-RAT mobility, the operator may divide up the entire MMEGI and NRI value space into non-overlapping sets with each set allocated to a particular DCN. In this case all eNodeBs may be configured with the same MME selection configuration. If UE assisted DCN selection feature is supported and a DCN-ID is provided by the UE, the DCN-ID shall be used in the eNodeB for MME selection to maintain the same DCN when the serving MME is not available. When selecting an MME for a UE that is using the NB-IoT RAT, and/or for a UE that signals support for CIoT EPS Optimisations in RRC signalling (as specified in TS 36.331, for NB-IoT, UE indicates whether it supports "User Plane CIoT EPS Optimisation" and "EPS Attach without PDN Connectivity". And for WB-E-UTRAN, UE indicates whether it supports "Control Plane CIoT EPS Optimisation", "User Plane CIoT EPS Optimisation" and "EPS Attach without PDN Connectivity"), the eNodeB's MME selection algorithm shall select an MME taking into account the MME's support (or non-support) for the Release 13 NAS signalling protocol. When DCN are deployed for the purpose of CIoT EPS Optimisation, UE included CIoT EPS Optimisation information in the RRC signalling, may depending on eNodeB configuration, be used to perform initial DCN selection. When Restricted Local Operator Services feature is supported, a UE initiates access to Restricted Local Operator Services via RRC signalling as defined in TS 36.331. The UE included RLOS indication in RRC signalling may be used by the eNB to select an appropriate MME.

The SGSN selection function selects an available SGSN to serve a UE. The selection is based on network topology, i.e. the selected SGSN serves the UE's location and for overlapping SGSN service areas, the selection may prefer SGSNs with service areas that reduce the probability of changing the SGSN. When a MME/SGSN selects a target SGSN, the selection function performs a simple load balancing between the possible target SGSNs. In networks that deploy dedicated MMEs/SGSNs for UEs configured for low access priority, the possible target SGSN selected by source MME/SGSN is typically restricted to SGSNs with the same dedication. When a MME/SGSN supporting DCNs selects a target SGSN, the selected target SGSN should be restricted to SGSNs that belong to the same CN. The DNS procedure may be used by the source CN node to select the target SGSN from a given DCN. If both low access priority and UE Usage Type parameter are used for SGSN selection, selection based on UE Usage type parameter overrides selection based on the low access priority indication.

The PDN-GW and AF may be served by one or more PCRF nodes in the HPLMN and, in roaming with local breakout scenarios, one or more PCRF nodes in the VPLMN. The selection of PCRF and linking of the different UE's PCC sessions over the multiple PCRF interfaces (e.g. Rx session, Gx session, S9 session etc.) for a UE IP-CAN session is described in TS 23.203.

The Domain Name Service function resolves logical PDN-GW names to PDN-GW addresses. This function is standard Internet functionality according to RFC 1034, which allows resolution of any name to an IP address (or addresses) for PDN-GWs and other nodes within the EPS.

The Dynamic Host Configuration Function allows to deliver IP configuration information for UEs. This function is standard Internet functionality according to RFC 2131, RFC 8415 and RFC 4039.

The E-UTRAN/UTRAN and the UE support the RFC 3168 Explicit Congestion Notification (ECN), as described in TS 36.300, TS 25.401 and TS 26.114.