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…

 

4.3.8  Selection functionsWord‑p. 48

4.3.8.1  PDN-GW selection function (3GPP accesses)Word‑p. 48

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, 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.
Up

4.3.8.2  Serving-GW selection functionWord‑p. 50

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

4.3.8.3  MME selection functionWord‑p. 51

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

4.3.8.4  SGSN selection functionWord‑p. 52

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

4.3.8.5  Selection of PCRFWord‑p. 53

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.

4.3.9  IP network related functionsWord‑p. 53

4.3.9.1  Domain Name Service functionWord‑p. 53

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.

4.3.9.2  DHCP functionWord‑p. 53

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

4.3.9.3  Explicit Congestion Notification |R9|Word‑p. 53

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.

4.3.10  Functionality for Connection of eNodeBs to Multiple MMEsWord‑p. 53

An eNodeB may connect to several MMEs. This implies that an eNodeB must be able to determine which of the MMEs, covering the area where an UE is located, should receive the signalling sent from a UE. To avoid unnecessary signalling in the core network, a UE that has attached to one MME should generally continue to be served by this MME as long as the UE is in the radio coverage of the pool area to which the MME is associated. The concept of pool area is a RAN based definition that comprises one or more TA(s) that, from a RAN perspective, are served by a certain group of MMEs. This does not exclude that one or more of the MMEs in this group serve TAs outside the pool area. This group of MMEs is also referred to as an MME pool.
To enable the eNodeB to determine which MME to select when forwarding messages from an UE, this functionality defines a routing mechanism (and other related mechanism). A routing mechanism (and other related mechanism) is defined for the MMEs. The routing mechanism is required to find the correct old MME (from the multiple MMEs that are associated with a pool area). When a UE roams out of the pool area and into the area of one or more MMEs that do not know about the internal structure of the pool area where the UE roamed from, the new MME will send the Identification Request message or the Context Request message to the old MME using the GUTI. The routing mechanism in both the MMEs and the eNodeB utilises the fact that every MME that serves a pool area must have its own unique value range of the GUTI parameter within the pool area.
Up

4.3.11  E-UTRAN Sharing FunctionWord‑p. 53

E-UTRAN Sharing is an agreement between operators and shall be transparent to the user. This implies that an E-UTRAN UE needs to be able to discriminate between core network operators available in a shared radio access network and that these operators can be handled in the same way as operators in non-shared networks. E-UTRAN terminals support E-UTRAN Sharing.
An E-UTRAN Sharing architecture allows different core network operators to connect to a shared radio access network. The operators do not only share the radio network elements, but may also share the radio resources themselves. In addition to this shared radio access network the operators may or may not have additional dedicated radio access networks, like for example, 3G or 2G radio access networks. For E-UTRAN both Multi-Operator Core Network (MOCN) configuration and Gateway Core Network (GWCN) configuration as defined in TS 23.251 are supported over the S1 reference point. E-UTRAN terminals shall support shared networks and hence, only functions for "Supporting UEs" in TS 23.251 applies for E-UTRAN Sharing.
E-UTRAN Radio Access Network Sharing functions is further described in TS 36.300.
In networks that support network sharing as defined in TS 23.251, for a UE in state ECM-CONNECTED, the Handover Restriction List provided by the core-network to the radio access network is also used to inform the radio access network about the Selected PLMN and equivalent PLMNs as defined in TS 36.413.
Up

Up   Top   ToC