Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.502  Word version:   16.4.0

Top   Up   Prev   Next
1…   4.2.2.2.2   4.2.2.2.3…   4.2.3…   4.2.3.3   4.2.4…   4.2.6   4.2.7…   4.2.9…   4.3…   4.3.2.2…   4.3.2.2.2   4.3.2.2.3…   4.3.3   4.3.4   4.3.5…   4.3.5.2…   4.3.5.4…   4.3.5.6…   4.3.6…   4.4…   4.5…   4.9…   4.9.1.3…   4.9.2…   4.11…   4.11.1.2.2…   4.11.1.3…   4.11.1.4…   4.11.1.5…   4.11.2   4.11.3…   4.12…   4.12.6…   4.12a   4.12b   4.13…   4.13.4…   4.13.6…   4.14…   4.15…   4.15.4…   4.16…   4.16.4…   4.16.8…   4.17…   4.17.9…   4.18…   4.19…   4.23…   4.23.7…   4.23.9…   4.23.11…   4.24   4.25   4.26…   5…   5.2.3…   5.2.5…   5.2.6…   5.2.7…   5.2.8…   5.2.9…   5.2.12…   A…   E…   F…

 

4.3.2.2.3  SMF selectionWord-p. 102
4.3.2.2.3.1  General
The SMF selection function, as described in TS 23.501, clause 6.3.2, is supported by the AMF and is used to allocate an SMF that manages the PDU Session.
The SMF selection function described in this clause does not apply to the selection of an SMF for Emergency services. For SMF selection for Emergency services is described in clause 5.16.4.5 of TS 23.501.
Two main branches of deployment scenarios to consider:
In the case of non-roaming and local breakout, there are two operational scenarios dependent on the configuration of AMF and the deployment option of NSSF in the serving PLMN.
In the case of home-routed, there are two main options dependent on the operators' choices in terms of involvement of NRF, NSSF and configuration of AMF. The decision of which option to use is part of the roaming agreements.
NOTE:
The use of NSI ID and the use of multiple NRFs in the network are optional and depend on the deployment choices of the operator.
Up
4.3.2.2.3.2  Non-roaming and roaming with local breakoutWord-p. 103
Up
This procedure may be skipped altogether if SMF information is available in the AMF by other means (e.g. locally configured); otherwise:
  • when the serving AMF is aware of the appropriate NRF to be used to select NFs/services within the corresponding Network Slice instance based on configuration or based on the Network Slice selection information received during Registration, only steps 3 and 4 in the following procedure are executed as described in Figure 4.3.2.2.3.2-1;
  • when the serving AMF is not aware of the appropriate NRF to be used to select NFs/services within the corresponding Network Slice instance, all steps in the following procedure are executed as described in Figure 4.3.2.2.3.2-1.
Step 1.
The AMF invokes the Nnssf_NSSelection_Get service operation from the NSSF in serving PLMN with the S-NSSAI of the Serving PLMN from the Allowed NSSAI requested by the UE, PLMN ID of the SUPI, TAI of the UE and the indication that the request is within a procedure of PDU Session establishment in either the non-roaming or roaming with local breakout scenario.
Step 2.
The NSSF in serving PLMN selects the Network Slice instance, determines and returns the appropriate NRF to be used to select NFs/services within the selected Network Slice instance, and optionally may return a NSI ID corresponding to the Network Slice instance.
Step 3.
AMF queries the appropriate NRF in serving PLMN by issuing the Nnrf_NFDiscovery_Request including at least the S-NSSAI of the Serving PLMN for this PDU Session from the Allowed NSSAI, PLMN ID of the SUPI, DNN and possibly NSI ID if the AMF has stored an NSI ID for the S-NSSAI of the Serving PLMN for this PDU Session from the Allowed NSSAI.
NOTE:
The list of parameters for SMF selection is defined in clause 6.3.2 of TS 23.501. See also clause 5.34.3 of TS 23.501 for I-SMF selection.
Step 4.
The NRF in serving PLMN provides to the AMF, e.g. FQDN or IP address, of a set of the discovered SMF instance(s) or Endpoint Address(es) of SMF service instance(s) in Nnrf_NFDiscovery_Request response message, and possibly an NSI ID for the selected Network Slice instance corresponding to the S-NSSAI for subsequent NRF queries.
Up
4.3.2.2.3.3  Home routed roaming
The selection of the SMF in VPLMN is performed in the same way as for non-roaming and roaming with local breakout (see clause 4.3.2.2.3.2). The selection of the SMF in HPLMN is performed by means of one of two main options. Which of these two options to use is decided based on Service Level Agreements between the operators.
NOTE 1:
The procedures described in this clause are not limited to SMF selection but can be used to discover and select any NF/NF service in the HPLMN part of a Network Slice instance.
In the first option, requiring the use of NSSF in both the VPLMN and the HPLMN, the selection of the SMF in HPLMN is performed by means of the procedure depicted in Figure 4.3.2.2.3.3-1.
Up
Step 1.
Based on the operator's configuration, if the AMF is not aware of the appropriate NRF to be used to select NFs/services in the HPLMN, the AMF invokes the Nnssf_NSSelection_Get service operation from the NSSF in VPLMN with the VPLMN S-NSSAI from the Allowed NSSAI requested by the UE for this PDU Session, the HPLMN S-NSSAI that maps to the VPLMN S-NSSAI, PLMN ID of the SUPI, the TAI of the UE and the indication that the request is within a procedure of PDU Session establishment in the home-routed roaming scenario.
Step 2.
If slicing configuration information for the S-NSSAI in the HPLMN is not available (e.g. the NSSF has no cached information), the NSSF of the VPLMN invokes the Nnssf_NSSelection_Get service operation from NSSF of the HPLMN according to the PLMN ID of SUPI by including the HPLMN S-NSSAI.
Step 3.
The NSSF in HPLMN may include the NSI ID, if needed, for the Network Slice instance in HPLMN selected for the corresponding S-NSSAI of the HPLMN in the Nnssf_NSSelection_Get response. The NSSF in HPLMN also includes the appropriate hNRF to be used to select NFs/services within HPLMN in the Nnssf_NSSelection_Get response.
Step 4.
The serving NSSF includes in the Nnssf_NSSelection_Get response all the information that has been received from the NSSF in HPLMN when responding to the AMF.
Step 5.
The AMF queries the target vNRF using the Nnrf_NFDiscovery_Request by including PLMN ID of the SUPI, DNN, HPLMN S-NSSAI, and possibly an HPLMN NSI ID if the AMF has stored an NSI ID for the selected Network Slice instance corresponding to the HPLMN S-NSSAI.
Step 6.
The NRF in serving PLMN identifies NRF in HPLMN (hNRF) based on the information provided by the NSSF in the serving PLMN, and it invokes the Nnrf_NFDiscovery_Request service from hNRF according the procedure in Figure 4.17.4-1 to get the expected SMF instance(s) deployed in the HPLMN. As the vNRF in VPLMN triggers the "NF Discovery" on behalf of the AMF, the NRF in the VPLMN shall not replace the information of the NF, i.e. AMF ID, in the Nnrf_NFDiscovery_Request message it sends to the hNRF.
Step 7-8.
The hNRF provides to the AMF, via vNRF, the information e.g. FQDN or IP address, of a set of the SMF instance(s) in Nnrf_NFDiscovery_Request response message and possibly an NSI ID for the selected Network Slice instance corresponding to the S-NSSAI of the HPLMN for subsequent NRF queries.
When the NSSF is not deployed in HPLMN then the AMF in VPLMN relies on either the configuration to obtain the NRF in HPLMN or on the option below.
The second option for the selection of the SMF in HPLMN is performed by means of the procedure depicted in Figure 4.3.2.2.3.3-2.
Up
Step 1.
Based on the operator's configuration, the AMF queries the vNRF with PLMN ID of the SUPI, PLMN ID of the serving PLMN, DNN, the HPLMN S-NSSAI that maps to the S-NSSAI from the Allowed NSSAI of the Serving PLMN the UE has requested, NSI ID (if the AMF has stored an HPLMN NSI ID for the selected Network Slice instance corresponding to the S-NSSAI of the HPLMN) and DNN.
Step 2.
The vNRF queries, on behalf of the AMF in VPLMN, the hNRF identified by means of the PLMN ID of the SUPI. The NRF in VPLMN requests "NF Discovery" service from hNRF according the procedure in Figure 4.17.4-1 to get the expected SMF instance(s) deployed in the HPLMN. As the NRF in the serving PLMN triggers the "NF Discovery" on behalf of the AMF, the NRF in the VPLMN shall not replace the information of the NF, i.e. AMF ID, in the Nnrf_NFDiscovery_Request message it sends to the hNRF.
Depending on the available information and based on configuration, the hNRF may either execute steps in 3(A) or in 3(B).
Step 3(A).
The hNRF provides to the AMF, via vNRF, the information e.g. FQDN or IP address, of a set of the discovered SMF instance(s) and possibly an NSI ID for the selected HPLMN part of the Network Slice instance corresponding to the S-NSSAI of the HPLMN for subsequent NRF queries in Nnrf_NFDiscovery_Request response message(steps 3a and 3b).
Step 3(B).
The hNRF queries, on behalf of the AMF, an appropriate local NRF in HPLMN (e.g. a slice level NRF); this local NRF provides the IP address or the FQDN of expected SMF instance(s) and possibly an NSI ID for the selected HPLMN part of the Network Slice instance corresponding to the S-NSSAI of the HPLMN for subsequent NRF queries (steps 3a and 3b) that the hNRF returns, via vNRF, to the AMF (steps 3c and 3d).
Up
4.3.2.2.4  Multiple PDU Sessions towards the same DNN and S-NSSAI [R16]Word-p. 105
A UE may establish multiple PDU Sessions associated with the same DNN and S-NSSAI, and the AMF may select the same SMF or different SMFs as specified in clause 6.3.2 of TS 23.501.
During PDU Session establishment, the AMF checks if the SMF selection subscription data indicates that the same SMF is required for multiple PDU Sessions, and if required, the AMF checks if any SMF is already selected for the same DNN and S-NSSAI, if so, the same SMF will be used for the additional PDU Session.
NOTE 1:
The SMF ID can be notified from UDM to the AMF when one AMF is selected for 3GPP access in VPLMN and a different AMF is selected in HPLMN for non-3GPP access.
NOTE 2:
The same SMF is selected for multiple PDU Sessions towards the same DNN and S-NSSAI to facilitate the selection of the same PCF e.g. for the purpose of usage monitoring.
Up
4.3.2.3  Secondary authorization/authentication by an DN-AAA server during the PDU Session establishmentWord-p. 106
The PDU Session establishment authentication/authorization is optionally triggered by the SMF during a PDU Session establishment and performed transparently via a UPF or directly with the DN-AAA server without involving the UPF if the DN-AAA server is located in the 5GC and reachable directly, as described in TS 23.501, clause 5.6.6.
In the case of Home Routed Roaming, unless specified otherwise, the SMF in the information flow defined in this clause is the H-SMF.
Up
NOTE 1:
Steps 2, 3a, 3f and 4 are not defined in this specification. Steps 3 can be repeated depending on the mechanism used.
NOTE 2:
When the SMF directly communicates with the DN-AAA server without involving the UPF, Step 1 is skipped and Step 2, 3a, 3f, 4 and 6 are executed without involving the UPF.
Step 0.
The SMF determines that it needs to contact the DN-AAA server. The SMF identifies the DN-AAA server based on local configuration or using the DN-specific identity (TS 33.501) provided by the UE inside the SM PDU DN Request Container provided by the UE in the PDU Session Establishment request or inside the EAP message in the PDU Session Authentication Complete message (TS 24.501).
NOTE 3:
The content of the SM PDU DN Request Container is defined in TS 24.501.
Step 1.
If there is no existing N4 session that can be used to carry DN-related messages between the SMF and the DN, the SMF selects a UPF and triggers N4 session establishment.
Step 2.
The SMF initiates the authentication procedure with the DN-AAA via the UPF to authenticate the DN-specific identity provided by the UE as specified in TS 29.561.
When available, the SMF provides the GPSI in the signalling exchanged with the DN-AAA.
The UPF transparently relays the message received from the SMF to the DN-AAA server.
Step 3a.
The DN-AAA server sends an Authentication/Authorization message towards the SMF. The message is carried via the UPF.
Step 3b.
Transfer of DN Request Container information received from DN-AAA towards the UE.
In non-roaming and LBO cases, the SMF invokes the Namf_Communication_N1N2MessageTransfer service operation on the AMF to transfer the DN Request Container information within N1 SM information sent towards the UE.
In the case of Home Routed roaming, the H-SMF initiates a Nsmf_PDUSession_Update service operation to request the V-SMF to transfer DN Request Container to the UE and the V-SMF invokes the Namf_Communication_N1N2MessageTransfer service operation on the AMF to transfer the DN Request Container information within N1 SM information sent towards the UE. In Nsmf_PDUSession_Update Request, the H-SMF additionally includes the H-SMF SM Context ID.
Step 3c.
The AMF sends the N1 NAS message to the UE
Step 3d-3e.
Transfer of DN Request Container information received from UE towards the DN-AAA.
When the UE responds with a N1 NAS message containing DN Request Container information, the AMF informs the SMF by invoking the Nsmf_PDUSession_UpdateSMContext service operation. The SMF issues an Nsmf_PDUSession_UpdateSMContext response.
In the case of Home Routed roaming, the V-SMF relays the N1 SM information to the H-SMF using the information of PDU Session received in step 3b via a Nsmf_PDUSession_Update service operation.
Step 3f.
The SMF (In HR case it is the H-SMF) sends the content of the DN Request Container information (authentication message) to the DN-AAA server via the UPF.
Step 3 may be repeated until the DN-AAA server confirms the successful authentication/authorization of the PDU Session.
Step 4.
The DN-AAA server confirms the successful authentication/authorization of the PDU Session. The DN-AAA server may provide:
  • an SM PDU DN Response Container to the SMF to indicate successful authentication/authorization;
  • DN Authorization Data as defined in TS 23.501, clause 5.6.6;
  • a request to get notified with the IP address(es) allocated to the PDU Session and/or with N6 traffic routing information or MAC address(es) used by the UE for the PDU Session; and
  • an IP address (or IPV6 Prefix) for the PDU Session.
The N6 traffic routing information is defined in TS 23.501, clause 5.6.7.
After the successful DN authentication/authorization, a session is kept between the SMF and the DN-AAA. If the SMF receives a DN Authorization Data, the SMF uses the DN Authorization Profile Index to apply the policy and charging control (see TS 23.501, clause 5.6.6).
Step 5.
The PDU Session establishment continues and completes. In the step 7b of the Figure 4.3.2.2.1-1, if the SMF receives the DN Authorization Profile Index in DN Authorization Data from the DN-AAA, it sends the DN Authorization Profile Index to retrieve the PDU Session related policy information (described in TS 23.503, clause 6.4) and the PCC rule(s) (described in TS 23.503, clause 6.3) from the PCF. If the SMF receives the DN authorized Session AMBR in DN Authorization Data from the DN-AAA, it sends the DN authorized Session AMBR within the Session AMBR to the PCF to retrieve the authorized Session AMBR (described in TS 23.503, clause 6.4).
Step 6.
If requested so in step 4 or if configured so by local policies, the SMF notifies the DN-AAA with the IP/MAC address(es) and/or with N6 traffic routing information allocated to the PDU Session together with the GPSI.
Later on the SMF notifies the DN-AAA if the DN-AAA had requested to get notifications about:
  • allocation or release of an IPV6 Prefix for the PDU Session of IP type or addition or removal of source MAC addresses for the PDU Session of Ethernet type (e.g. using IPV6 multi-homing as defined in TS 23.501, clause 5.6.4.3),
  • Change of N6 traffic routing information.
When later on the PDU Session gets released as described in clause 4.3.4, the SMF notifies the DN-AAA.
The DN-AAA server may revoke the authorization for a PDU Session or update DN authorization data for a PDU Session. According to the request from DN-AAA server, the SMF may release or update the PDU Session.
At any time after the PDU Session establishment, the DN-AAA server or SMF may initiate Secondary Re-authentication procedure for the PDU Session as specified in clause 11.1.3 of TS 33.501. Step 3a to step 3f are performed to transfer the Secondary Re-authentication message between the UE and the DN-AAA server. The Secondary Re-authentication procedure may start from step 3a (DN-AAA initiated Secondary Re-authentication procedure) or step 3b (SMF initiated Secondary Re-authentication procedure). For the DN-AAA server initiated Secondary Re-authentication, the message in step 3a shall include GPSI, if available, and the IP/MAC address(es) of the PDU session, for SMF to identify the corresponding UE and PDU session.
DN-AAA may initiate DN-AAA Re-authorization without performing re-authentication based on local policy. DN-AAA Re-authorization procedure may start from step 4.
During Secondary Re-authentication/Re-authorization, if the SMF receives DN Authorization Profile Index and/or DN authorized Session AMBR, the SMF reports the received value(s) to the PCF (as described in TS 23.501) by triggering the Policy Control Request Trigger as described in TS 23.503.
Up

Up   Top   ToC