Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.502  Word version:  16.5.1

Top   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.11.3  Handover procedures between EPS and 5GC-N3IWFWord‑p. 233

4.11.3.1  Handover from EPS to 5GC-N3IWF

Reproduction of 3GPP TS 23.502, Figure 4.11.3.1-1: Handover from EPS to 5GC-N3IWF
Up
Step 0.
Initial status: one or more PDN connections have been established in EPC between the 5G capable UE and the PGW via E-UTRAN.
Step 1.
The UE initiates Registration procedure on untrusted non-3GPP access via N3IWF (with 5G-GUTI is available or SUCI if not) per clause 4.12.2.
Step 2.
The UE initiates a UE requested PDU Session Establishment with Existing PDU Session indication in 5GC via Untrusted non-3GPP Access via N3IWF per clause 4.12.5.
If the Request Type indicates "Existing Emergency PDU Session", the AMF shall use the Emergency Information received from the HSS+UDM which contains PGW-C+SMF FQDN for S5/S8 interface for the emergency PDN connection established in EPS and the AMF shall use the S-NSSAI locally configured in Emergency Configuration Data.
The combined PGW+SMF/UPF initiates a PDN GW initiated bearer deactivation as described in TS 23.401, clause 5.4.4.1 to release the EPC and E-UTRAN resources.
Up

4.11.3.2  Handover from 5GC-N3IWF to EPS

Reproduction of 3GPP TS 23.502, Figure 4.11.3.2-1: Handover from 5GC-N3IWF to EPS
Up
Step 0.
Initial status: one or more PDU Sessions have been established in 5GC between the UE and the SMF/UPF via untrusted non-3GPP access and N3IWF. During PDU Session setup, and in addition to what is specified in clause 4.3.2.2.1 and clause 4.3.2.2.2, the AMF includes an indication that EPS interworking is supported to the PGW-C+SMF as specified in clause 4.11.5.3, and the PGW-C+SMF sends the FQDN related to the S5/S8 interface to the HSS+UDM which stores it as described in clause 4.11.5.
Step 1.
For the UE to move PDU session(s) from 5GC/N3IWF to EPC/E-UTRAN, the UE's behaviour is as follows:
  • If the UE is operating in single-registration mode (as described in clause 5.17.2.1 in TS 23.501) and the UE is registered via 3GPP access to 5GC,
    • the UE behaves as specified in clause 4.11.1 or 4.11.2 and moves its PDU session from 5GC/N3IWF to EPC/E-UTRAN using the PDN connection establishment with "Handover" indication procedure as described in TS 23.401.
    • otherwise, i.e. either the UE is operating in single registration mode and is not registered via 3GPP access to 5GC, or the UE is operating in dual registration mode, and
  • if the UE is not attached to EPC/E-UTRAN,
    • the UE initiates Handover Attach procedure in E-UTRAN as described in TS 23.401 for a non-3GPP to EPS handover with "Handover" indication, except note 17.
    • otherwise (i.e. the UE is attached to EPC/E-UTRAN), the UE initiates the PDN Connection establishment with "Handover" indication procedure as described in TS 23.401.
Step 2.
The combined PGW+SMF/UPF initiates a network requested PDU Session Release via untrusted non-3GPP access and N3IWF according to Figure 4.12.7-1 steps 3 to 12 to release the 5GC and N3IWF resources with the following exception:
  • the H-SMF indicates in the Nsmf_PDUSession_Update Request that the UE shall not be notified. This shall result in the V-SMF not sending the N1 SM Container (PDU Session Release Command) to the UE.
  • Nsmf_PDUSession_StatusNotify service operation invoked by H-SMF to V-SMF indicates the PDU Session is moved to a different system;
  • Nsmf_PDUSession_SMContexStatusNotify service operation invoked by the (V-)SMF indicates the PDU Session is moved to another system.
  • The Npcf_SMPolicyControl_Delete service operation to PCF shall not be performed.
Up

4.11.4  Handover procedures between EPC/ePDG and 5GSWord‑p. 234

4.11.4.1  Handover from EPC/ePDG to 5GS

Reproduction of 3GPP TS 23.502, Figure 4.11.4.1-1: Handover from EPC/ePDG to 5GS
Up
Step 0.
Initial status: one or more PDN Connections have been established between the UE and the EPC/ePDG via untrusted non-3GPP access as specified in clauses 7.2.4 and 7.6.3 of TS 23.402 with modification described in clauses 4.11.4.3.3 and 4.11.4.3.5.
Step 1.
For the UE to move its PDU session(s) from EPC/ePDG to 5GC/3GPP access, the UE's behaviour is as follows:
  • If the UE is operating in single-registration mode (as described in clause 5.17.2.1 in TS 23.501) and the UE is attached to EPC/E-UTRAN:
    • the UE behaves as specified in clause 4.11.1 or clause 4.11.2 and gets registered to 5GC via 3GPP access.
    • otherwise i.e. either the UE is operating in single registration mode and is not attached to EPC/E-UTRAN, or the UE is operating in dual registration mode, and
  • if the UE is already registered in 5GS via 3GPP access,
    • the UE skips to step 2.
    • otherwise (i.e UE is not registered in 5GS via 3GPP access), the UE performs Registration procedure of type initial registration in 5GS via 3GPP access as described in clause 4.2.2.2.
Step 2.
The UE initiates a UE requested PDU Session Establishment via 3GPP Access acording to clause 4.3.2.2 and includes the "Existing PDU Session" indication or "Existing Emergency PDU Session" and the PDU Session ID.
For Request Type "Existing PDU Session", the UE provides a DNN, the PDU Session ID and S-NSSAI corresponding to the existing PDN connection it wants to transfer from EPC/ePDG to 5GS. The S-NSSAI and PLMN ID sent to the UE are set in the same way as for EPS to 5GS mobility as specified in clause 5.15.7.1 of TS 23.501.
If the Request Type indicates "Existing Emergency PDU Session", the AMF shall use the Emergency Information containing PGW-C+SMF FQDN for the S2b interface it has received from the HSS+UDM. The PGW-C+SMF FQDN was sent by PGW-C when the Emergency PDN connection was established in EPC via ePDG and the AMF shall use the S-NSSAI locally configured in Emergency Configuration Data.
Step 3.
The combined PGW+SMF/UPF initiates a PDN GW initiated Resource Allocation Deactivation with GTP on S2b as described in TS 23.402, clause 7.9.2 to release the EPC and ePDG resources when S6b is used. When S6b is not used between PGW-C+SMF and AAA, impacts to step 5 of TS 23.402 Figure 7.9.2-1 are captured in clause 4.11.4.3.6.
Up

4.11.4.2  Handover from 5GS to EPC/ePDGWord‑p. 235
Reproduction of 3GPP TS 23.502, Figure 4.11.4.2-1: Handover from 5GS to EPC/ePDG
Up
Step 0.
Initial status: one or more PDU Sessions have been established between the UE and the SMF/UPF via NG-RAN.
Step 1.
The UE connects to an untrusted non-3GPP access and the N3IWF-ePDG selection process results in selecting an ePDG.
Step 2.
The UE initiates a Handover Attach procedure as described in TS 23.402, clause 8.6.2.1, except step 11 of referenced Figure 8.2.3-1 that corresponds to the release of resources in source system.
Step 3.
The combined PGW+SMF/UPF initiates a network requested PDU Session Release via 3GPP access according to Figure 4.3.4.2-1 steps 3b to 7b, step 11 or Figure 4.3.4.3-1 steps 3a-16b to release the 5GC and NG-RAN resources with the following exception:
  • For non-roaming or local breakout in clause 4.3.4.2, the SMF does not include N1 SM Container in Namf_Communication_N1N2MessageTransfer service operation.
  • For home routing roaming in clause 4.3.4.3, the H-SMF indicates in the Nsmf_PDUSession_Update Request that the UE shall not be notified. This shall result in the V-SMF not sending the N1 SM Container (PDU Session Release Command) to the UE.
  • Nsmf_PDUSession_StatusNotify service operation invoked by H-SMF to V-SMF, and Nsmf_PDUSession_SMContexStatusNotify service operation invoked by the (V-)SMF to the AMF indicate that the PDU Session is moved to a different system.
  • The Npcf_SMPolicyControl_Delete service operation to PCF shall not be performed.
Up

4.11.4.3  Impacts to EPC/ePDG Procedures |R16|Word‑p. 236
4.11.4.3.1  General
This clause captures enhancements to procedures in TS 23.402 to support interworking with 5GS. The architecture for interworking is shown in TS 23.501, clause 4.3.4. with the ePDG connected to SMF+PGW-C and UPF+PGW-U using GTP based S2b.
4.11.4.3.2  ePDG FQDN construction
TS 23.402, clause 4.5.4.2 applies with the following modification:
  • Tracking/Location Area Identity FQDN: When the 5GC NAS capable UE uses the Tracking Area of the NG-RAN when the UE is registered with the 5GC when constructing the Tracking Area Identity FQDN.
4.11.4.3.3  Initial Attach with GTP on S2b
The procedure in TS 23.402, clause 7.2.4 applies with the following modifications:
  • In Step A.1 IKEv2 tunnel establishment procedure, the 5GC NAS capable UE shall indicate its support of 5GC NAS in IKEv2. The UE allocates a PDU Session ID and also includes this in IKEv2 to the ePDG.
  • In Step A.1, UE's mobility restriction parameters related to 5GS or indication of support for interworking with 5GS for this APN or both as defined for MME in clause 4.11.0a.3 apply to the ePDG and are obtained by the ePDG as part of the reply from the HSS via the 3GPP AAA Server. These parameters and the 5G NAS support indicator from the UE, may be used by the ePDG to determine if a combined PGW-C+SMF or a standalone PGW should be selected.
  • In Step B.1, if the UE supports 5G NAS and the PDN connection is not restricted to interworking with 5GS by user subscription, the ePDG shall send the 5GS Interworking Indication and the PDU Session ID to the PGW-C+SMF.
  • In Step B.1, if the PGW-C+SMF supports more than one S-NSSAI and the APN is valid for more than one S-NSSAI, the PGW-C+SMF selects S-NSSAI as specified in clause 4.11.0a.5.
  • In Step D.1 (Create Session Response), the PGW-C+SMF assigns a S-NSSAI to be associated with the PDN connection as specified in TS 23.501, clause 5.15.7.1. The PGW-C+SMF sends the S-NSSAI to the ePDG together with a PLMN ID that the S-NSSAI relates to.
  • In Steps B.1 and D.1, if the UE does not support 5GC NAS but has 5GS subscription, and a PGW-C+SMF is selected and interaction with UDM, PCF and UPF is required, the PGW-C+SMF assigns PDU Session ID as specified in clause 4.11.0a.5. The PGW-C+SMF shall not provide any 5GS related parameters to the UE.
  • In the IKEv2 Authentication Response message, the ePDG sends S-NSSAI and the PLMN ID that the S-NSSAI relates to, to the UE. The UE associates the received S-NSSAI and the PLMN ID that the S-NSSAI relates to, with the PDN Connection.
Up
4.11.4.3.3a  Initial Attach for emergency session (GTP on S2b)Word‑p. 237
The procedure in TS 23.402, clause 7.2.5 applies with the following modification or modification:
  • Step 3 (Create Session Request): ePDG determines if interworking with 5GC is supported based on UE's 5G NAS capability and local configuration. In PGW-C+SMF, only one S-NSSAI is configured for the emergency APN.
  • Step 6 (Create Session Response), compared to step D.1 of clause 4.11.4.3.3, PGW-C+SMF does not include S-NSSAI in PCO for emergency PDN connection.
Up
4.11.4.3.4  Interaction with PCC
When interworking with 5GS is supported and a PGW-C+SMF is selected by the ePDG, policy interactions between PDN GW and PCRF specified in TS 23.402 are replaced by equivalent interactions between PGW-C+SMF and PCF as captured in clause 4.11.0a.2.
If PGW-C+SMF is selected and interaction with PCF is required for a UE that does not support 5GC NAS, the PGW-C+SMF determines the PDU Session ID and S-NSSAI in the same way as for PDN connection via MME as specified in clause 4.11.0a.5.
Up
4.11.4.3.5  UE initiated Connectivity to Additional PDN with GTP on S2b
The procedure in TS 23.402, clause 7.6.3 references the Initial Attach procedure with GTP on S2b. Impacts to the initial attach procedure with GTP on S2b are captured in clause 4.11.4.3.3 above. If the additional PDN connection is for emergency service, impact as captured in clause 4.11.4.3.3a applies.
Up
4.11.4.3.6  Use of N10 interface instead of S6b
This clause applies to scnearios when ePDG is connected to SMF+PGW-C and S6b in not used. It is applicable for procedures specified in TS 23.402 including mobility between EPC/ePDG and EPC/EUTRAN and also for mobility between EPC/ePDG and 5GS.
When S6b, as specified in TS 23.402, is not deployed between PGW-C+SMF and AAA and the UE creates and deletes a PDN connection via ePDG connected to SMF+PGW-C, the registration and de-registration of PDN GW is performed on the N10 interface instead of the S6b interface.
If PGW-C+SMF is selected for a UE that does not support 5GC NAS, the PGW-C+SMF determines the PDU Session ID and S-NSSAI in the same way as for PDN connection via EPC/EUTRAN as specified in clause 4.11.0a.5.
For roaming scenario with local-breakout (TS 23.501, Figure 4.3.4.2.1), the use of N10 interface instead of S6b interface may be based on support of this feature from HSS+UDM to SMF+PGW-C on N10 interface.
The specific impacts to procedures in clauses 7 and 8 of TS 23.402 are as follows:
7.2.4  Initial Attach with GTP on S2b
  • Instead of Step C.1 in Figure 7.2.4-1 of TS 23.402, step 16c (Nudm_UECM_Registration with an optional indication that access is from ePDG) from Figure 4.3.2.2.1-1 are performed between the SMF+PGW-C and HSS+UDM. Based on this indication, the HSS+UDM does not send notification of PGW-C assignment on SWx to AAA.
7.2.5  Initial Attach for emergency session (GTP on S2b)
  • Instead of step 5 in Figure 7.2.5-1 of TS 23.402, step 16c (Nudm_UECM_Registration with an optional indication that access is from ePDG) from Figure 4.3.2.2.1-1 are performed between the SMF+PGW-C and HSS+UDM. Based on this indication, the HSS+UDM does not send notification of PGW-C assignment on SWx to AAA.
    The indication of access from ePDG is forwarded on the interface between UDM and HSS.
7.4.3  UE/ePDG-initiated Detach Procedure and UE-Requested PDN Disconnection with GTP on S2b
7.4.3.1
Non-Roaming, Home Routed Roaming and Local Breakout Case
  • Instead of Step A.2 in Figure 7.4.3-1 of TS 23.402, step 12 (Nudm_UECM_Deregistration) from Figure 4.3.4.2-1 is performed between the SMF+PGW-C and HSS+UDM.
7.4.4  HSS/AAA-initiated Detach Procedure with GTP on S2b
7.4.4.1  Non-Roaming, Home Routed Roaming and Local Breakout Case
  • Instead of step 3 in Figure 7.4.1-1 of TS 23.402 (referenced by Figure 7.4.4-1 of TS 23.402), Step 12 (Nudm_UECM_Deregistration) from Figure 4.3.4.2-1 is performed between the SMF+PGW-C and HSS+UDM
7.9.2  PDN GW initiated Resource Allocation Deactivation with GTP on S2b
  • Instead of step 5 in Figure 7.9.2-1 of TS 23.402, Step 12 (Nudm_UECM_Deregistration) from Figure 4.3.4.2-1 is performed between the SMF+PGW-C and HSS+UDM.
8.6.1.1  General Procedure for GTP based S5/S8 for E-UTRAN Access
8.6.2.1  3GPP Access to Untrusted Non-3GPP IP Access Handover with GTP on S2b
  • In Step B.2 of clause 8.6.2.1 of TS 23.402, if the registration of the PGW-C+SMF in the HSS+UDM is not already done, step 16c (Nudm_UECM_Registration with an optional indication that access is from ePDG) from Figure 4.3.2.2.1-1 is performed between the PGW-C+SMF and HSS+UDM.
The impacts to procedure in clause 4.11.4.1 (Handover from EPC/ePDG to 5GS) are as follows:
  • For step 0, the impacts to clause 7.2.4 of TS 23.402 are captured above.
  • In step 2, if the Request Type indicates "Existing Emergency PDU Session", the AMF shall use the Emergency Information containing PGW-C+SMF FQDN for the S2b interface and the S NSSAI locally configured in Emergency Configuration Data.
  • In step 3, the impacts to clause 7.9.2 of TS 23.402 are captured above. Nudm_UECM_Deregistration is not performed by PGW-C+SMF, as resources in the PGW-C+SMF are not released.
The impacts to procedures in clause 4.11.4.2 (Handover from 5GS to EPC/ePDG) are as follows:
  • For step 2, impacts to clause 8.6.2.1 (3GPP Access to Untrusted Non-3GPP IP Access Handover with GTP on S2b) of TS 23.402 are captured above and Step 16c of Figure 4.3.2.2.1-1 is not performed as PGW-C+SMF already registered in the HSS+UDM when the UE is in 5GS.
Up

4.11.5  Impacts to 5GC ProceduresWord‑p. 238

4.11.5.1  General

This clause captures impacts to 5GC procedures in other clauses of this specification to support interworking with EPS. These impacts are applicable to interworking based on N26 and interworking without N26 for PDU Session via 3GPP access, and for PDU Session via non-3GPP access.
This clause also captures the impact to 5GC if the UE was previously in GERAN/UTRAN as specified in clause 5.17.2.4 of TS 23.501.

4.11.5.2  Registration procedure

The following impacts are applicable to clause 4.2.2.2 (Registration procedure):
  • Step 1: If the Registration type is set to "Initial Registration", the UE is not registered in EPS and the UE provides the 5G-GUTI mapped from EPS GUTI as the old GUTI, then the UE includes complete EPS Attach Request in the Registration request message.
  • Step 4: If the Registration type is "Initial Registration" as in step 1 of the Registration Procedure captured in clause 4.2.2.2.2, the target AMF may perform Identification Request towards MME along with complete EPS Attach Request message for MME to verify it as in step 3 as specified in TS 23.401, clause 5.3.2.1.
  • Step 14a: If mobility between GERAN/UTRAN and 5GS is required (as specified in clause 5.17.2.4 of TS 23.501), at Initial Registration, the AMF serving 3GPP access shall also register with the Nudm_UECM_Registration even if the AMF has a valid context.
  • Step 14d: If mobility between GERAN/UTRAN and 5GS is required (as specified in clause 5.17.2.4 of TS 23.501), when the UDM stores the associated 3GPP Access Type together with the serving AMF as indicated in step 14a, it will also cause cancellation of any other previously registered serving node (e.g. MME if AMF does not indicate not to cancel or SGSN) via HSS/HLR.
For PDU Session via 3GPP access the following impacts are applicable to clause 4.2.2.2 (Registration procedure) when the UE has established PDU Session(s):
In clause 4.3.2.2.1 Non-roaming and Roaming with Local Breakout:
  • Step 17: Additional trigger for step 17 Nsmf_PDUSession_UpdateSMContext are:
    • If status of interworking with EPS for a PDU session changes, e.g. due to change of 5GMM capability (e.g. "S1 mode supported"), the UE subscription data change (e.g. Core Network Type Restriction to EPC), the AMF invokes Nsmf_PDUSession_UpdateSMContext (EPS Interworking Indication with N26 or without N26) to SMF. The SMF determines whether the PDU session supports interworking with EPS need be changed. If it needs to be changed, the SMF invokes Nudm_UECM_Update service operation to add or remove the PGW-C FQDN for S5/S8 interface from the UE context in SMF data stored at the UDM.
For interworking with the N26 interface, if status of interworking with EPS for a PDU session is changed at PGW-C+SMF, the PGW-C+SMF invokes EBI allocation or revocation as described in clause 4.11.1.4.1 and clause 4.11.1.4.2 respectively.
For PDU Session via non-3GPP, the AMF determines if EPS interworking is supported and sends the indication to the SMF in the same way as for PDU Session via 3GPP PDU Session. The SMF makes the final decision on the EPS interworking in the same way as for PDU Session via 3GPP PDU Session with the following modification:
If the SMF does not receive the interworking indication, the SMF makes its decision based on subscription.
Up

4.11.5.3  UE Requested PDU Session Establishment procedureWord‑p. 239
For PDU Session via 3GPP, the following impacts are applicable to clause 4.3.2.2 (UE Requested PDU Session Establishment procedure) to support interworking with EPS:
In clause 4.3.2.2.1 Non-roaming and Roaming with local breakout:
  • Step 1: In PDU Session Establishment Request message, the UE includes also the UE capability of Ethernet PDN type support in EPS to the SMF (or H-SMF in home routing roaming);
  • Step 3: The AMF determines that a PDU Session supports EPS interworking with N26 or without N26, based on e.g. 5GMM capability (e.g. "S1 mode supported"), UE subscription data (e.g. Core Network Type Restriction to EPS, EPC interworking support per (S-NSSAI, subscribed DNN)) and network configuration if EPS interworking with N26 or without N26 is supported. The AMF then includes in the Nsmf_PDUSession_CreateSMContext an indication whether the PDU Session supports EPS Interworking with N26 or without N26.
    For PDU Session with Request Type "initial emergency request", the AMF decides the EPS interworking with N26 or without N26 based on 5GMM capability and local configuration.
    For PDU Session with Request Type "Existing Emergency PDU Session", the AMF shall use Emergency Information received from HSS+UDM and the S-NSSAI locally configured in Emergency Configuration Data.
    If the AMF has stored APN Rate Control Status and the PDU Session is considered a new first PDU Session to a DNN that is the same as the APN in stored APN Rate Control Status and interworking with EPC is enabled for this PDU Session, then the AMF sends the APN Rate Control Status to the SMF.
  • Step 4: If the EPS Interworking indication received from AMF indicates that the UE supports EPS interworking and the SMF determines, based on the EPS interworking support indication from the AMF and additional UE subscription data (e.g. whether UP integrity protection of UP Security Enforcement Information is not set to required, EPS interworking is allowed for this DNN and S-NSSAI), that the PDU Session supports EPS interworking, the PGW-C+SMF FQDN for S5/S8 interface is included in the Nudm_UECM_Registration Request.
  • Step 10a: If APN Rate Control Status is received from the AMF then the SMF provides the configured APN Rate Control Status to the PGW-U+UPF.
  • Step 13 In PDU Session Establishment Accept message, the SMF also includes indication of Ethernet PDN type supported if the Ethernet PDN type is supported by both the UE and the PGW-C+SMF. The SMF and the UE stores the information if Ethernet PDN type is supported for later use when UE moves from 5GS to EPS.
In clause 4.3.2.2.2 Home-routed Roaming:
  • Step 3a: Same impact as for step 3 for the non-roaming and roaming with local lreakout case above.
  • Step 5: Same impact as for step 10a for the Non-roaming and Roaming with Local Breakout case above.
  • Step 6 The V-SMF pass the EPS interworking support indication received from the AMF to the H-SMF in Nsmf_PDUSession_Create.
  • Step 7: If the EPS interworking indication received from V-SMF indicates that the PDU Session supports EPS interworking and the H-SMF determines, based on the EPS interworking support indication from the AMF and additional information such as UP integrity protection of UP Security Enforcement Information as described in clause 4.11.1.1, that the PDU Session supports EPS interworking, the PGW-C+SMF FQDN for S5/S8 interface is included in the Nudm_UECM_Registration Request.
  • Step 15: Same impact as in step 13 for the non-roaming and roaming with local breakout case above with the difference that it's the home PGW-C+SMF that includes the indication of Ethernet PDN type supported.
For interworking with the N26 interface, if the PDU Session supports interworking with EPS, the PGW-C+SMF invokes EBI allocation as described in clause 4.11.1.4.1.
For non-emergency PDU Session via non-3GPP, the AMF determines if EPS interworking is supported and sends the indication to the SMF in the same way as for PDU Session via 3GPP. The SMF makes the final decision on the EPS interworking in the same way as for PDU Session via 3GPP with the following modification:
  • If the SMF does not receive the interworking indication, the SMF makes its decision based on subscription.
For emergency PDU Session via non-3GPP, the AMF determines if EPS interworking is supported and sends the indication to the SMF in the same way as for emergency PDU Session via 3GPP supporting EPS interworking.
Up

4.11.5.4  UE or Network Requested PDU Session Modification procedureWord‑p. 240
For PDU Session via 3GPP, the following impacts are applicable to clause 4.3.3.2 (UE or network requested PDU Session Modification (non-roaming and roaming with local breakout)) to support interworking with EPS:
  • Step 1: In addition to the triggers listed in step 1 of clause 4.3.3.2, the procedure may be also triggered by the following event:
    • AMF initiated modification: If the support of EPS Interworking for this PDU Session has changed, e.g. the change of the UE's subscription data (e.g. Core Network Type Restriction to EPS), or change of 5GMM capability (e.g. "S1 mode supported"), the AMF invokes Nsmf_PDUSession_UpdateSMContext update the status of EPS interworking support in the to SMF.
  • Step 3a: This step also applies to AMF initiated modification. For AMF initiated modification, the SMF may determines whether the PDU session supports EPS interworking need be changed. If it need be changed, the SMF invokes Nudm_UECM_Update service operation to add or remove the PGW-C FQDN for S5/S8 interface from the UE context in SMF data stored at the UDM,
For PDU Session via 3GPP, the following impacts are applicable to clause 4.3.3.3 (UE or network requested PDU Session Modification (home-routed roaming)) to support interworking with EPS:
  • Step 1a (AMF to V-SMF): Same impact as for step 1 of clause 4.3.3.2 above.
  • Step 1a (V-SMF to H-SMF): The V-SMF pass the status of EPS interworking support to the H-SMF.
  • Step 1a (H-SMF to V-SMF): Same impact as for step 3a of clause 4.3.3.2 above.
For interworking with the N26 interface, if status of interworking with EPS for a PDU session is changed at PGW-C+SMF, the PGW-C+SMF invokes EBI allocation or revocation as described in clause 4.11.1.4.1 and clause 4.11.1.4.2 respectively.
For PDU Session via non-3GPP, the AMF determines if EPS interworking is supported and sends the indication to the SMF in the same way as for PDU Session via 3GPP PDU Session. The SMF makes the final decision on the EPS interworking in the same way as for PDU Session via 3GPP PDU Session with the following modification:
If the SMF does not receive the interworking indication, the SMF makes its decision based on subscription.
Up

4.11.5.5  Xn based inter NG-RAN handoverWord‑p. 241
The following impacts are applicable to clause 4.9.1.2.1 (General) to support interworking with EPS:
  • If there is Mapping between EBI(s) and QFI(s) for the UE in the source NG-RAN, the sourcre NG-RAN sends the Mapping to target NG-RAN during handover.

4.11.5.6  Inter NG-RAN node N2 based handover

The following impacts are applicable to clause 4.9.1.3.2 (Preparation phase) to support interworking with EPS:
  • Step 7: If the PDU session supports EPS interworking, the N2 SM information contains the Mapping between EBI(s) and QFI(s).

4.11.5.7  UE or Network Requested PDU Session Release procedure |R16|

The following impacts are applicable to clause 4.3.4.2 (UE or network requested PDU Session Release for Non-Roaming and Roaming with Local Breakout) to support interworking with EPS:
  • Step 2b: If the released PDU Session used APN Rate Control in EPC then the PGW-U+UPF provides the APN Rate Control Status to the SMF if the released PDU Session supported interworking with EPC and it is the last PDU Session to the DNN that is the same as the APN identified in the APN Rate Control Status.
  • Step 3: If the PGW-U+UPF provided APN Rate Control Status to the SMF then the SMF provides the APN Rate Control Status to the AMF.
The following impacts are applicable to clause 4.3.4.3 (UE or network requested PDU Session Release for Home-routed Roaming) to support interworking with EPS:
  • Step 2b: Same impact as for step 2b for the Non-roaming and Roaming with Local Breakout case above.
  • Step 3: Same impact as for step 3 for the Non-roaming and Roaming with Local Breakout case above.
Up

4.11.5.8  Network Configuration |R16|Word‑p. 242
To avoid the need for identifier coordination between AMFs and MMEs, the AMF provides to the NG-RAN its served GUAMIs by separating the values between native AMF values and the values mapped from MME.

4.11.6  Interworking for common network exposure |R16|

4.11.6.1  Subscription and Notification of availability or expected level of support of a service API

Figure 4.11.6.1 1 represent the information flow subscribing and notifying the availability or expected level of support of a service API.
For the subscription to Nnef_APISupportCapability service, the subscription request may include the Duration of Reporting. If the Duration of Reporting is expired, the SCEF+NEF deletes the subscription without any explicit signalling interaction.
For the CN type Change Event subscription to the HSS+UDM, the subscription request may include the Duration of Reporting. If the Duration of Reporting is expired, the HSS+UDM locally unsubscribe the CN Type Change Event without any explicit signalling interaction.
The SCEF+NEF informs the AF of the API Indication which indicates list of available north-bound API(s).
Reproduction of 3GPP TS 23.502, Figure 4.11.6.1-1: Subscription and Notification of availability or expected level of support of a service API
Up
Step 1.
The AF subscribes to Nnef_APISupportCapability service for a UE or a group of UEs by sending Nnef_APISupportCapability_Subscribe Request (UE ID or External Group ID, Report Type, callback URI, Duration of Reporting) message.
The callback URI parameter is optional and is used in step 6 if provided.
The Report Type can be either One-time report or Continuous report. If this is a subscription for Continuous report type, then the Duration of Reporting may be included. The Duration of Reporting is optional and is used to indicate when the subscription is invalid. If the SCEF+NEF has established direct connection with MME or AMF or SMF, steps 2 - 3 and step 5 are omitted. If this is a subscription for One-time report type, and if the Freshness Timer of last One-time report type subscribe request is not expired or a direct connection has been set up with MME or AMF or SMF, the SCEF+NEF determines the CN type locally, steps 2 - 3 are omitted.
Step 2.
SCEF+NEF subscribes the CN Type Change Event to HSS+UDM by sending Nudm_EventExposure_Subscribe Request (CN Type Change, Report Type, UE ID or External Group ID, Duration of Reporting) message.
If Duration of Reporting is received at step 1, it shall include Duration of Reporting in this message.
Step 3.
The HSS+UDM determines the CN type that is serving the indicated UE or the indicated group of UEs based on the registered MME or AMF. The HSS+UDM informs SCEF+NEF of the CN type by sending Nudm_EventExposure_Subscribe Response (CN Type) message. If the Report Type indicates One-time report, the HSS+UDM delete the CN Type Change Event subscription after sending the response with CN Type. The Freshness Timer is set in SCEF+NEF per operator's policy, e.g. based on the statistics of UE activities. If the Report Type indicates Continuous report, HSS+UDM stores the CN Type Change Event subscription.
Step 4.
According to the CN type received or local stored, the SCEF+NEF determines the availability or expected level of support of common north-bound APIs for the indicated UE or the indicated group of UEs. SCEF+NEF responds to AF by sending Nnef_APISupportCapability_Subscribe Response (API Indication).
If the subscription is for One-time report type, then steps 5 - 6 are omitted.
Step 5.
When HSS+UDM detects that the indicated UE is switching between EPC and 5GC the HSS+UDM determines the CN type that is serving the indicated UE or the indicated group of UEs. The HSS+UDM informs SCEF+NEF of the CN type by sending Nudm_EventExposure_Notify (CN type).
The CN type denotes the 5GC or EPC or 5GC+EPC serving the UE or the group of UEs.
Step 6.
According to the CN type received and local detected, the SCEF+NEF node determines the availability or expected level of support of common north-bound APIs for the indicated UE or the indicated group of UEs. SCEF+NEF inform AF of such API information by sending Nnef_APISupportCapability_Notify (API Indication) message.
If callback URI is provided at step 1, then SCEF+NEF will send the Nnef_APISupportCapability_Notify (API Indication) message to the node addressed by callback URI.
Upon reception of API Indication in step 4 or step 6, the AF obtains the availability or expected level of support of a given service for the indicated UE or the indicated group of UEs. If required, the AF can select the valid north-bound API based on such API information.
Up

4.11.6.2  Unsubscribing to Notification of availability or expected level of support of a service APIWord‑p. 243
Figure 4.11.6.2-1 represent the information flow unsubscribing to Continuous report type subscription of the availability or expected level of support of a service API.
If the AF invokes Nnef_APISupportCapability_Subscribe service to SCEF+NEF node with the Duration of Reporting parameter for Continuous report type, the subscription on the SCEF+NEF and HSS+UDM are implicitly unsubscribed if the Duration of Reporting timer expires, i.e. the explicit unsubscribe service operation is not needed.
If the explicit unsubscribe operation is needed, the information flow is as follows.
Reproduction of 3GPP TS 23.502, Figure 4.11.6.2-1: Unsubscribing to notification of the availability or expected level of support of a service API
Up
Step 1.
The AF unsubscribes to Nnef_APISupportCapability service for a UE or a group of UEs by sending APISupportCapability_Unsubscribe Request (UE ID or External Group ID) message.
Step 2.
If SCEF+NEF has subscribed to CN Type Change Event for the indicated UE or the indicated group of UEs, SCEF+NEF unsubscribes the CN Type Change Event by sending Ndum_EventExposure_Unsubscribe Request (CN Type Change, UE ID or External Group ID) message to HSS+UDM.
Step 3.
HSS+UDM deletes the CN Type Change Event subscription for the indicated UE or the indicated group of UEs, HSS+UDM responses to the SCEF+NEF by sending Ndum_EventExposure_Unsubscribe Response (Operation execution result indication) message.
Step 4.
If result indication indicates the operation is successful, the SCEF+NEF deletes the subscription to Nnef_APISupportCapability service. SCEF+NEF acknowledges the operation result by sending Nnef_APISupportCapability_Unsubscribe Response (Operation execution result indication) to AF.
Up

4.11.6.3  Configuration of monitoring events for common network exposureWord‑p. 244
Figure 4.11.6.3-1 represent the information flow to configure monitoring events applicable to both EPC and 5GC using 5GC procedures towards UDM in scenarios where interworking between 5GS and EPC is possible.
Reproduction of 3GPP TS 23.502, Figure 4.11.6.3-1: Configuration of monitoring events for common network exposure
Up
Step 1.
The AF configures a monitoring event via the SCEF+NEF using the Nnef_EventExposure_Subscribe service operation.
Step 2.
SCEF+NEF configures the monitoring event in the UDM+HSS using the Nudm_EventExposure_Subscribe service operation.
The combined SCEF+NEF indicates that the monitoring event is also applicable to EPC (i.e. the event must be reported both by 5GC and EPC). Depending on the type of event, the SCEF+NEF may include a SCEF address (i.e. if the event needs to be configured in the MME and the corresponding notification needs to be sent directly to the SCEF).
Step 3.
The HSS+UDM configures the monitoring event. For events that need to be reported from a serving node (e.g. location change) the HSS+UDM requests the configuration of the monitoring event to the corresponding serving node in the 5GC and EPC. The HSS+UDM uses the corresponding Event Exposure Subscribe service operation to configure monitoring events in 5GC serving NFs (e.g. Namf_EventExposure_Subscribe or Nsmf_EventExposure_Subscribe). The HSS+UDM uses the procedures defined in TS 23.682 to configure monitoring events in MME. The HSS+UDM provides the MME with the SCEF address during the configuration of the monitoring event in EPC. If the HSS and UDM are deployed as separate network entities, UDM shall use HSS services to configure the monitoring event in EPC as defined in TS 23.632.
Step 4.
The HSS+UDM replies the SCEF+NEF with the indication that the monitoring event was successfully configured in 5GC and EPC by sending the Nudm_EventExposure_Subscribe Response.
Step 5.
The SCEF+NEF responds to AF by sending Nnef_EventExposure_Subscribe Response.
Step 6.
The SCEF+NEF is notified when HSS+UDM or the serving node at the 5GC or EPC detects the corresponding event. The HSS+UDM notifies the SCEF+NEF using the Nudm_EventExposure_Notify service operation. A serving NF in the 5GC notifies the SCEF+NEF using the corresponding Event Exposure Notify service operation (e.g. Namf_EventExposure_Notify or Nsmf_EventExposure_Notify). The MME notifies the SCEF+NEF using the procedures defined in TS 23.682 using the SCEF address provided by the HSS+UDM in step 3.
Step 7.
The SCEF+NEF notifies the AF using the Nnef_EventExposure_Notify service operation.
Up


Up   Top   ToC