Re: [Idr] 3GPP SSC Mode 3 in draft-dunbar-idr-5g-edge-compute-app-meta-data-03

[Linda Dunbar <[e-mail]>]

Gyan and Jeffrey,

For 5G Edge Computing (and mission critical new features), please use TR23.501 versions for Release 17:  https://itectec.com/archive/3gpp-specification-ts-23-501/#google_vignette

Section 5.8.2.2 of TR23.501-h20, released Sept 2021, has the detailed description of UE IP address management. There are many options, UE can choose its own static IP address, use DHCP, or get assigned by SMF based on a pool of UPFs. For 4G, the P-GW is centralized, UE most likely to change IP addresses when anchored to a different P-GW. For 5G, there are many UPFs, SMF might assign one IP address for  a pool of UPFs to an UE (if UE opts for getting IP address assignment from SMF).

I will update the document with the detailed description.

Thanks, Linda

From: Gyan Mishra <[e-mail]>
Sent: Friday, November 12, 2021 10:14 PM
To: Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>
Cc: Linda Dunbar <[e-mail]>; idr@ietf. org <[e-mail]>
Subject: Re: [Idr] 3GPP SSC Mode 3 in draft-dunbar-idr-5g-edge-compute-app-meta-data-03


Hi Jeffrey

I read the text as well and as long mode 1 the address does not change and mode 2 it does change and mode 3 is dual homed is like a MOB (make before break) where it disconnects the old IP once the new is established.

So mode 2 is the where the session will reset

https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/15.02.00_60/ts_123501v150200p.pdf<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.etsi.org%2Fdeliver%2Fetsi_ts%2F123500_123599%2F123501%2F15.02.00_60%2Fts_123501v150200p.pdf&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C120e5d94fd244c0b3ddb08d9a65c13ed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637723736671027898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ai3aaBPA9JxEMDHb7aELj2BRXu7FfTi1Mb9GsjL0kY4%3D&reserved=0>

Mode 3

After the new IP address/prefix has been allocated, the old IP address/prefix is maintained during some time indicated to the UE via NAS signalling (as described in TS 23.502 [3] clause 4.3.5.2) or via Router Advertisement (as described in TS 23.502 [3] clause 4.3.5.3) and then released.


If a PDU Session of SSC mode 3 has multiple PDU Session Anchors (i.e., in the case of multi-homed PDU Sessions or in the case that UL CL applies to a PDU Session of SSC mode 3), the additional PDU Session Anchors may be released or allocated.

5.6.9.3 SSC mode selection
The SSC mode selection policy shall be used to determine the type of session and service continuity mode associated with an application or group of applications for the UE.

I wonder what determines what mode is used by the N6 interface.

Thanks

Gyan

On Thu, Nov 11, 2021 at 3:27 PM Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]<mailto:[e-mail]>> wrote:
Hi Linda,

In draft-dunbar-idr-5g-edge-compute-app-meta-data-03 there is the following updated text:

   When the UE moves out of coverage of its current gNB (next-
   generation Node B) (gNB1), handover procedures are initiated,
   and the 5G SMF (Session Management Function) selects a new
   UPF-PSA. The standard handover procedures described in 3GPP TS
   23.501 and TS 23.502 are followed. When the handover process
   is complete, the UE is anchored to the new UPF-PSA, meaning
   the packets to/from the UE is carried by the GTP tunnel to the
   new UPF-PSA. The UE usually maintains its IP address when
   anchored to the new UPF-PSA unless the new UFP-PSA belongs to
   different mobile operators. 5GC may maintain a path from the
   old UPF to new the UPF for a short time for the SSC [Session
   and Service Continuity] mode 3 to make the handover process
   more seamless.

It's different from -02 which says that a new address would be assigned. I am curious which is correct - http://4g5gworld.com/blog/session-and-service-continuity-evolution-5g-networks<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F4g5gworld.com%2Fblog%2Fsession-and-service-continuity-evolution-5g-networks&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C120e5d94fd244c0b3ddb08d9a65c13ed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637723736671037847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2K5lY2rG4F6G5GfnOxaj4mF%2FjXSeKWuy9XFSGJdSeAg%3D&reserved=0> says that only mode 1 (where the anchoring UPF does not change) maintains persistent address. That seems to be consistent with 23.501:

---------------------23.501------
5.6.9.2.3       SSC Mode 3
For PDU Session of SSC mode 3, the network allows the establishment of UE connectivity via a new PDU Session Anchor to the same data network before connectivity between the UE and the previous PDU Session Anchor is released. When trigger conditions apply, the network decides whether to select a PDU Session Anchor UPF suitable for the UE's new conditions (e.g. point of attachment to the network).
In this Release of specification, SSC mode 3 only applies to IP PDU Session type and to any access type.
In the case of a PDU Session of IPv4 or IPv6 or IPv4v6 type, during the procedure of change of PDU Session Anchor, the following applies:
a.      For a PDU Session of IPv6 type, the new IP prefix anchored on the new PDU Session Anchor may be allocated within the same PDU Session (relying on IPv6 multi-homing specified in clause 5.6.4.3), or
b.      The new IP address and/or IP prefix may be allocated within a new PDU Session that the UE is triggered to establish.
After the new IP address/prefix has been allocated, the old IP address/prefix is maintained during some time indicated to the UE via NAS signalling (as described in TS 23.502 [3] clause 4.3.5.2) or via Router Advertisement (as described in TS 23.502 [3] clause 4.3.5.3) and then released.
If a PDU Session of SSC mode 3 has multiple PDU Session Anchors (i.e., in the case of multi-homed PDU Sessions or in the case that UL CL applies to a PDU Session of SSC mode 3), the additional PDU Session Anchors may be released or allocated.
------------------------

In fact, I introduced a proposal in 3GPP to assign persistent addresses in Release 17 EC Enhancement SID. It was accepted in the early stage but I was not available to defend the proposal when it came to the final conclusion stage so it was not eventually taken to WID. It would be nice if we could push that through in Release 18.

Thanks.
Jeffrey


Juniper Business Use Only
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C120e5d94fd244c0b3ddb08d9a65c13ed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637723736671037847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ROP6y2VuQJd%2B0Nu6uB0XYSn0jWqQ%2FYDJ89Rg63A09iI%3D&reserved=0>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C120e5d94fd244c0b3ddb08d9a65c13ed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637723736671047804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AxP4YGAlapWdkSG5NKZ5Si1hi5Tvr3QsyUIbEpHxdsA%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347