Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 23.700-89  Word version:  18.0.0

Top   Top   Up   Prev   None
1…   5…   6…   6.1…   6.2…   6.3…   6.4…   6.5…   6.6…   6.7…   6.8…   6.9…   6.10…   7…   8…

 

8  Conclusionsp. 33

8.1  Conclusion on Key Issue #1: RFSP Index consistency when UE moves from 5GC to EPCp. 33

8.1.1  For deployment without N26 interface interworkingp. 33

For deployment scenario without N26 interface it is concluded that no normative work is required at this point.

8.1.2  For deployment with N26-based interworkingp. 33

The following conclusion are agreed:
  • When a UE moves from 5GC to EPC, the MME sets the "RFSP Index in use" value the same as the value in the UE context received from AMF via N26 if the UE context in AMF also contains a validity period.
  • When the validity period expires, the MME re-evaluates the RFSP Index value according to current specification (see clause 4.3.6 of TS 23.401).
  • The validity period, i.e. "RFSPinUseExpiryTime" is selected by PCF for a UE. When the PCF for a UE provides the Authorized RFSP Index indicating the UE to move to 4G, it may also provide the value of "RFSPinUseExpiryTime". If the AMF selects the RFSP Index in use identical to the authorized RFSP Index, it should store the received "RFSPinUseExpiryTime" in UE context in AMF and further also send the received "RFSPinUseExpiryTime" to MME in UE context along with the "RFSP Index in use" when N26 interface applied.
  • When mobility happens between MMEs before the "RFSPinUseExpiryTime" expires, the remaining value of the "RFSPinUseExpiryTime" should also be sent to the new MME. The new MME handles RFSP Index in the same way as for mobility from the AMF to the MME as described above.
  • When a UE is served by the EPC, there is no use case or requirement to provide updated RFSP Index from 5GC to the EPC.
Up

$  Change historyp. 35


Up   Top