4.3.8 Selection functions

23.4013GPPGeneral Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) accessRelease 18TS

4.3.8.1 PDN GW selection function (3GPP accesses)

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.

NOTE 1: Selection of PDN GWs optimised for different RATs (e.g. NB-IoT) can be achieved by the allocation of different APNs to subscribers allowed to use specific RATs and/or using the UE Usage Type.

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 [61].

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.

NOTE 2: How Weight Factors can be used in conjunction with Load Information received via GTP control plane signalling is left up to Stage 3.

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 [9]), 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.

NOTE 3: The MME uses this information to determine an appropriate APN-OI and S8 protocol type (PMIP or GTP) when the MME and PDN GW are located in different PLMNs.

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

NOTE 4: Provision of a PDN GW identity of a PDN GW as part of the subscriber information allows also for a PDN GW allocation by HSS.

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 [61] 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 [61] 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 [36]. 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 [61], 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 [7] and clause 9 of TS 23.003 [9]. 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).

NOTE 5: The APN as constructed by the MME/SGSN for PDN GW resolution takes into account the APN-OI Replacement field. This differs from the APN that is provided in charging data to another SGSN and MME over the S3, S10 and S16 interfaces as well as to Serving GW and PDN GW over the S11, S4 and S5/S8 interfaces, in that the APN-OI Replacement field is not applied. See clause 5.7.2 of the present document for more details.

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 [2], 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 [61]) 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.

4.3.8.2 Serving GW selection function

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 [61].

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.

NOTE 1: How Weight Factors can be used in conjunction with Load Information received via GTP control plane signalling is left up to Stage 3.

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 [2].

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 [61]) 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.

NOTE 2: Selection of Serving GWs optimised for different RATs (e.g. NB-IoT) can be achieved by using UE Usage Type and/or by using different TAIs for different RATs.

4.3.8.3 MME selection function

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 [37].

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 [92].

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 [37], 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 [37]. The UE included RLOS indication in RRC signalling may be used by the eNodeB to select an appropriate MME.

4.3.8.4 SGSN selection function

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.

4.3.8.5 Selection of PCRF

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 [6].