E.4 Session Breakout
23.5483GPP5G System Enhancements for Edge ComputingRelease 17Stage 2TS
As traffic offload via UL CL/BP is not supported over EPC, when a PDN connection is initiated in EPS or a PDU Session is handed-over to EPS, the SMF+PGW-C can send to the EASDF DNS message handling rules requesting the EASDF to transparently forward any DNS traffic. The SMF+PGW-C can send to the EASDF new DNS message handling rules (with actual reporting and actions as defined in clause 6.2.3.2.2) when the PDU Session/PDN connection is handed-over (back) to 5GS.
When a PDN connection is initiated in EPS, the SMF+PGW-C can also select a normal DNS Server (i.e. different from an EASDF) to serve the PDN Connection, and then indicate to the UE to use the EASDF as DNS Server when the PDU Session/PDN connection is moved to 5GS.
Annex F (Informative):
EAS Relocation on Simultaneous Connectivity over Source and Target PSA
This annex describes how EAS relocation can make use of network capabilities that, at PSA change, provide simultaneous connectivity over the source and the target PSA during a transient period.
At PSA change, simultaneous connectivity to Application over former and new PSA allows the application to build its own EAS relocation solution and minimize the impact on latency:
– If the decision for when to start using a target EAS is taken by the application, this decision can consider application specific aspects, like for example, the time interval between packets or end of a video frame to minimize impact on latency.
– When there are multiple applications on a PDU Session, if connectivity over the former PSA is maintained for some time, each application can schedule EAS relocation to suit the application specific needs without interfering with the other applications.
The procedure is shown in below Figure F-1:
Figure F-1: EAS relocation on simultaneous connectivity over source and target PSA
The user has established a PDU Session. This PDU Session has a local PSA (source L-PSA), which could be the PSA of a PDU Session with Distributed Anchor connectivity or one additional local PSA of a PDU Session with Session Breakout. There has been an EAS Discovery procedure as described in clauses 6.2.2.2 and 6.2.3.2 (the procedure is conditioned to the connectivity model) for one or more applications. Application traffic is served by source EAS over the Local PSA.
1. User mobility triggers SMF to select a new Local PSA (target L-PSA) that is closer to current user location. In this scenario, the re-anchoring procedures that provide Simultaneous Connectivity over Source and Target PSA are described in TS 23.502 [3]:
– For Distributed Anchor, in clause 4.3.5.2 for Change of SSC mode 3 PDU Session Anchor with multiple PDU Sessions and in clause 4.3.5.3 for Change of SSC mode 3 PDU Session Anchor with IPv6 Multi-homed PDU Session.
– For Session Breakout, in clause 4.3.5.7 for Simultaneous change of Branching Point or UL CL and additional PSA for a PDU Session.
The SMF may notify an AF for the early and/or late notifications on the UP-path change event as described in clause 4.3.6.3 in TS 23.502 [3].
2. When the connectivity is available on target L-PSA, the connectivity via source L-PSA is still available during certain time (that is provisioned and controlled as described in these TS 23.502 [3] procedures). The application traffic can continue to run over the established UE-EAS connections.
3. The EAS Rediscovery Procedures described in clauses 6.2.2.3 and 6.2.3.3 allow the UE to discover a new EAS (i.e. target EAS) for the application that is closer to the UE over the new path (there could be multiple triggers as described in those respective clauses). If multiple applications are being served by this PDU Session, each of them performs rediscovery. This discovery procedure may lead to EAS reselection.
4. New L4 connections may now be established between the UE and the target EAS with the following considerations:
– For Distributed anchor or session breakout with MH, the UE uses the IP address /prefix associated with the target PSA (that is referred to as IP#2 in Figure F-1).
– For Session breakout with ULCL, there has not been connection/IP address change. Same IP address is still used by UE (that is referred to as IP#1 in Figure F-1).
NOTE 1: If Session Breakout is used for connectivity and if the application wants to build service continuity on simultaneous connections, source EAS and target EAS cannot share the same IP address (e.g. by using anycast).
EAS Relocation may involve EAS context migration in the case of stateful applications. The following examples are part of the application implementation details and fall out of 3GPP specification scope:
– In case that SMF notifies an AF for the early and/or late notification in Step 1, based on the notifications, the AF can interact with the source Application server, which can recreate the context to the target EAS and then provide switching instructions to the Application client.
– The Application server can recreate the service context when first contacted by the client using a Context Id: when suitable, the application client sets up a connection to the target EAS including a Context Id. The target EAS uses this Context Id to retrieve the latest service context available and subsequent updates, if needed.
– The Application server can recreate the context when first contacted by the client using a Context Id: the application client sets up a connection to the target EAS but for some time it sends traffic to both source and target EAS. In this way it triggers the context migration before the actual EAS switch.
– The source Application server is able to provide the client with switching instructions when a new EAS is selected: upon UE request (if UE selected) or as an EAS initiative (if server selected), the source EAS provides the Application client with switching instructions while it continues to serve traffic and drives any context migration towards the selected target EAS.
NOTE 2: This application procedure may be designed to solve EAS relocation in all scenarios, not only when triggered by Edge Relocation, which may simplify the application design.
5. At some points all traffic for all applications in this session are sending traffic to their target EAS only and traffic ceases over the source L- PSA. The source L-PSA is then released. The timers should be set to allow EAS relocation.
6. UE only maintains connection(s) to target EAS(s).
Annex G (Informative):
Change history
Change history |
|||||||
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
2021-03 |
SA2#143E |
S2-2100114 |
– |
– |
– |
Proposed skeleton approved at S2#143E |
0.0.0 |
2021-06 |
SA#92E |
SP-210365 |
– |
– |
– |
MCC editorial update for presentation to TSG SA#92E for information |
1.0.0 |
2021-09 |
SA#93E |
SP-210942 |
– |
– |
– |
MCC editorial update for presentation to TSG SA#93E for approval |
2.0.0 |
2021-09 |
SA#93E |
– |
– |
– |
– |
MCC editorial update for publication after SA#93E approval |
17.0.0 |
2021-12 |
SA#94E |
SP-211290 |
0001 |
3 |
F |
Correction related to uniqueness of Update related to a buffered DNS message in EASDF |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0003 |
– |
F |
Correction and removal of misleading Note |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0005 |
1 |
F |
Not all EC scenarios requires EASDF |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0014 |
1 |
F |
Clarify the local AF subscription for the QoS Monitoring during UE mobility |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0017 |
4 |
F |
Updates on EAS Discovery Procedure with EASDF |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0018 |
3 |
F |
Mega CR for minor fixes to TS 23.548 |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0024 |
– |
F |
Update Neasdf_DNSContext services |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0030 |
4 |
C |
EAS rediscovery: Edge DNS Client based EAS (re-)discovery |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0031 |
3 |
F |
UE authorization for 5GC assisted EAS discovery |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0034 |
1 |
F |
Updating related to EAS Discovery Procedure |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0035 |
1 |
F |
Corrections on enabling EAS IP Replacement procedure by AF |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0036 |
1 |
F |
Improvements and correction to annex C |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0038 |
1 |
F |
Change of DNS server address during EPC IWK |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0039 |
1 |
F |
Alignment of EASDF functional description |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0040 |
1 |
F |
Added the situation of AF relocation to uplink Packet Buffer |
17.1.0 |
2021-12 |
SA#94E |
SP-211290 |
0042 |
1 |
F |
Local NEF selection |
17.1.0 |
2022-03 |
SA#95E |
SP-220055 |
0043 |
1 |
F |
Corrections on enabling EAS IP Replacement procedure by AF |
17.2.0 |
2022-03 |
SA#95E |
SP-220055 |
0046 |
1 |
F |
Correction related EHE in EC architecture |
17.2.0 |
2022-03 |
SA#95E |
SP-220055 |
0047 |
1 |
F |
Update of EAS discovery procedure and BaselineDNSPattern management in EASDF |
17.2.0 |
2022-03 |
SA#95E |
SP-220055 |
0048 |
1 |
F |
On NAT between PSA UPF and EASDF |
17.2.0 |
2022-03 |
SA#95E |
SP-220055 |
0050 |
1 |
F |
Removing inconsistency in the definition of ECS Address Configuration Information |
17.2.0 |
2022-03 |
SA#95E |
SP-220055 |
0051 |
1 |
F |
Corrections of EDC functionality description |
17.2.0 |
2022-06 |
SA#96 |
SP-220398 |
0052 |
1 |
F |
Correction related to EAS IP Address in EDI |
17.3.0 |
2022-06 |
SA#96 |
SP-220398 |
0053 |
– |
F |
Corrections on enabling EAS IP Replacement procedure by AF |
17.3.0 |
2022-06 |
SA#96 |
SP-220398 |
0054 |
1 |
F |
Correction of EAS Deployment Information Management procedures and services |
17.3.0 |
2022-06 |
SA#96 |
SP-220398 |
0056 |
1 |
F |
Parameter supplement of EDI |
17.3.0 |
2022-06 |
SA#96 |
SP-220398 |
0061 |
1 |
F |
Alignment of ECS Address Configuration Information to SA6’s definition |
17.3.0 |
2022-09 |
SA#97E |
SP-220777 |
0062 |
1 |
F |
EDNS Client Subnet option correction |
17.4.0 |
2022-12 |
SA#98E |
SP-221069 |
0063 |
– |
F |
Clarifications for local event notification control |
17.5.0 |