Content for TS 23.433 Word version: 19.3.0

0… 4… 7… 8… 9.2… 9.2.2.3… 9.2.3… 9.2.4… 9.3… 9.3.2.2… 9.3.3… 9.3.4… 9.4… 9.5… 9.5.3… 9.5.4… 9.6… 9.7… 9.7.3… 9.7.4… 9.8… 9.9… 9.9.3… 9.10… 9.10.3… 9.11… 9.11.3… 9.12… A… C D…

9.6 SEALDD server relocation 9.6.1 General 9.6.2 Procedures 9.6.2.1 SEALDD context transfer 9.6.2.2 SEALDD relocation in EDN 9.6.3 Information flows 9.6.3.1 SEALDD context push request 9.6.3.2 SEALDD context push response 9.6.3.3 SEALDD context pull request 9.6.3.4 SEALDD context pull response 9.6.3.5 SEALDD Inform ACR event request 9.6.3.6 SEALDD Inform ACR event response 9.6.3.7 SEALDD Inform ACR event notification 9.6.4 APIs 9.6.4.1 General 9.6.4.2 Sdd_DDContext_Push Request operation 9.6.4.3 Sdd_DDContext_Pull Request operation 9.6.4.4 Sdd_InformACREvent_Request operation 9.6.4.5 Sdd_ InformACREvent _Notify operation
...

9.6 SEALDD server relocation p. 65

9.6.1 General p. 65

The SEALDD server may be relocated due to UE mobility or load re-balance.

If SEALDD server is adapted to EDGEAPP as an EAS, the EAS relocation procedure can be used to support SEALDD server relocation for both UE mobility and SEALDD server load re-balance. If SEALDD is not adapted to EDGEAPP, for UE mobility, the SEALDD client can discover (e.g. using DNS) a new SEALDD server in the target area and establish a new SEALDD communication channel including the old SEALDD communication channel information. For load re-balance, the SEALDD server can discover (e.g. using DNS) an equivalent SEALDD server and communicate with the new SEALDD server.

Based on existing service continuity mechanism supported by 3GPP core network (e.g. BP/ULCL), during SEALDD server relocation with UPF change, the new UPF takes care of the existing unfinished application traffic flow towards the old VAL server and inter-UPF tunnel is used to forward the traffic. For new application traffic flow which may have UE's new IP address as source IP address, the new SEALDD server sends it directly to the new VAL server.

For SEALDD server relocation, the inter-SEALDD server communication via SEALDD-E reference point is needed, which transfers the SEALDD context from the old SEALDD server to the new SEALDD server.

The following procedures detail the EDGEAPP ACT part between old SEALDD server (i.e. S-EAS) and new SEALDD server (i.e. T-EAS) as described in clause 8.8.2.2 to clause 8.8.2.6 of TS 23.558. Also, a high-level flow is provided to show the scenario used in EDN.

9.6.2 Procedures p. 65

9.6.2.1 SEALDD context transfer p. 65

Figure 9.6.2.1-1 describes SEALDD context transfer procedure in pull (step 1a and 2a) or push (step 1b and 2b) operation.

Pre-conditions:

For pull operation, the old SEALDD server endpoint is available in the new SEALDD server
For push operation, the new SEALDD server endpoint is available in the old SEALDD server.

Reproduction of 3GPP TS 23.433, Fig. 9.6.2.1-1: SEALDD context transfer

Figure 9.6.2.1-1: SEALDD context transfer

The transferred SEALDD context includes the service subscription information created upon VAL server's interaction for requesting SEALDD transmission service (e.g. step 1 and 2 in Figure 9.2.2.1-1), and also the SEALDD client and SEALDD server communication tunnel management information (e.g. UE IP address) which is created upon SEALDD client's interaction for requesting data transmission (e.g. step 5 and 6 in Figure 9.2.2.1-1). If new SEALDD server supports transportation layer service continuity, additional transport layer context (e.g. TCP/TLS/QUIC) is transferred from old SEALDD server to new SEALDD server. If the new SEALDD Server is not provisioned with the VAL server configured SEALDD policy, then it can pull from the Old SEALDD server via the pull operation. The push operation does not support the transfer of the VAL server configured SEALDD policy between Old and New SEALDD server.

The new SEALDD server, after receiving the SEALDD context from the old SEALDD server, allocates IP address and port for SEALDD-Uu user plane communication. The new SEALDD server also sends back to the old SEALDD server with the allocated endpoint information If operation is push. Then the old SEALDD server can request 5GC to perform IP replacement procedure, as defined in clause 6.3.3 of TS 23.548. The request includes the traffic descriptor of old SEALDD server (i.e., SEALDD-UU address/port), the traffic descriptor of new SEALDD server (i.e., SEALDD-UU address/port) and/or the target DNAI.

Optionally, after receiving the SEALDD context with the SEALDD-UU endpoint from the old SEALDD server, the new SEALDD server can request 5GC to perform IP replacement procedure.

To improve the seamless SEALDD relocation, the old SEALDD server may stop the downlink data transmission before pushing the SEALDD context to the new SEALDD server, the context data may include content breakpoint information, as defined in clause 9.6.3.1. After the SEALDD client connects to the new SEALDD server, the new SEALDD server transmits the downlink traffic to the SEALDD client based on content breakpoint information.

9.6.2.2 SEALDD relocation in EDN p. 66

Pre-conditions:

VAL Server 1 and 2 are adapted to the EDGEAPP as EAS.
VAL Server 1 and 2 register its associated SEALDD server in EES as described in clause 9.4.3.2.

Reproduction of 3GPP TS 23.433, Fig. 9.6.2.2-1: SEALDD support of UE's service continuity

Figure 9.6.2.2-1: SEALDD support of UE's service continuity

Step 1.

An application client on a UE, acting as a VAL client, establishes a SEALDD-UU flow over SEALDD-UU to send application data to VAL Server 1. SEALDD client and SEALD server 1 maintain SEALDD-UU flow information (e.g., SEALDD-UU flow ID, VAL IDs/addresses, VAL requirements).

Step 2.

Application data between the VAL Client and VAL Server 1 is sent via the SEALDD-UU flow.

Step 3.

The UE moves and generates a mobility event in the 5GC.

Step 4.

The UE's mobility event triggers the execution of an Application Context Relocation (ACR) procedure as described in TS 23.558; or VAL server 1 triggers ACR due to load re-balancing reason. Any of the ACR scenarios detailed in clauses 8.8.2.2 - 8.8.2.6 of TS 23.558 may occur. In this step, the first three phases of the ACR procedure are performed, up to ACT. In this step VAL Server 1 acts as EAS 1 and VAL Server 2 as EAS 2, therefore participating in corresponding signalling. VAL server 2 has been selected as SEALDD-enabled server meeting the ACR criteria to be the target EAS. The associated SEALDD server 2 has also been selected and may support transportation layer (e.g. UDP/TCP/QUIC) service continuity.

Step 5a.

Before triggering ACT, VAL Server 1 sends a SEALDD notification of ACR event to SEALDD Server 1.

Step 5b.

Before triggering ACT, VAL Server 2 sends a SEALDD notification of ACR event to SEALDD Server 2.

Step 6a.

SEALDD server 1 transfers the SEALDD context to the SEALDD server 2 which serves VAL Server 2 as described in clause 9.6.2.1, with push operation. The SEALDD server 1 can obtain the SEALDD server 2 endpoint for SEALDD-Uu user plane to the SEALDD client, as specified in clause 9.6.2.1.

Step 6b.

SEALDD server 2 can obtain the SEALDD context from the SEALDD server 1 by using the pull operation, as described in clause 9.6.2.1.

Step 7.

SEALDD server 1 applies the functionality specified in clause 5.2.6.7 of TS 23.502 for AF traffic influence, providing the N6 routing information for the SEALDD client and SEALDD server 2. The SEALDD server 1 may:

If the SEALDD server 2 supports transportation layer service continuity, additionally includes SEALDD IP replacement information (i.e. SEALDD server 1 endpoint and SEALDD server 2 endpoint for SEALDD-Uu user plane) in the AF traffic influence. Since the UE is not aware of SEALDD server change, the new SEALDD traffic (due to new VAL traffic sent by VAL client) is sent by UPF towards the new SEALDD server, this handling in UPF is agnostic to the SEALDD server 2. Or,
send AF traffic influence with target DNAI of SEALDD server 2, and simultaneous connectivity indicator, to request 5GC to maintain the simultaneous connectivity over source PSA and target PSA with source SEALDD server and target SEALDD server, as described in clause 6.3.4 of TS 23.548.

Step 8.

If the SEALDD server 2 has no transportation layer service continuity support, a SEALDD Connection info update notification is sent to SEALDD client, e.g. to update the allocated IP address and port for SEALDD-Uu user plane communication. Then the SEALDD client acknowledges the received SEALDD Connection info update notification. After SEALDD client is aware of the new SEALDD-Uu IP address and port, it starts to send new SEALDD traffic (received from the VAL client) over the new connection. The new SEALDD server maps the received SEALDD traffic to the application traffic according to the SEALDD traffic descriptor and VAL service ID. The new SEALDD server sends the recovered application traffic to new VAL server. The downlink application traffic sent from the new VAL server to VAL client is processed similarly.

Step 9.

SEALDD Server 1 notifies VAL Server 1 of the completion of the SEALDD-UU flow transfer.

Step 10.

VAL Server 1 (acting as EAS1) and VAL Server 2 (acting as EAS 2) execute the Application Context Transfer (ACT) procedure step corresponding to the pending ACR scenario (clauses 8.8.2.2 - 8.8.2.6 of TS 23.558), which is out the 3GPP scope.

Step 11.

The post-ACR clean-up phase is executed, as described in the corresponding ACR scenario (clauses 8.8.2.2 - 8.8.2.6 of TS 23.558).

Step 12.

The application data from the VAL Client is sent via the SEALDD-UU flow (with SEALDD server 2) to VAL Server 2.

9.6.3 Information flows p. 68

9.6.3.1 SEALDD context push request p. 68

Table 9.6.3.1-1 describes the information flow from the old SEALDD server to the new SEALDD server to push the SEALDD context.

Table 9.6.3.1-1: SEALDD context push request

Information element	Status	Description
Requestor ID	M	Identifies the requestor (i.e. old SEALDD server).
SEALDD-Uu Context	M	Identifies the context related to SEALDD-Uu connection, which is created upon SEALDD connection establishment.
SEALDD-S Context	M	Identifies the context related to SEALDD-S subscription.
Transport layer context	O	Identifies the context related to Transport layer (e.g. TCP/TLS/QUIC) for SEALDD-Uu user plane communication.
Content breakpoint information	O	The downlink data breakpoint information for pre-provisioned data.

9.6.3.2 SEALDD context push response p. 68

Table 9.6.3.2-1 describes the information flow from the new SEALDD server to the old SEALDD server for responding to the SEALDD context push request.

Table 9.6.3.2-1: SEALDD context push response

Information element	Status	Description
Result	M (NOTE)	Success or failure.
New SEALDD server endpoint	O	The endpoint (IP address and port) on the new SEALDD for SEALDD-Uu user plane communication. Applicable for successful result.
NOTE: The result is failed if the new SEALDD server rejects the relocation for SEALDD client.

9.6.3.3 SEALDD context pull request p. 69

Table 9.6.3.3-1 describes the information flow from the new SEALDD server to the old SEALDD server to pull the SEALDD context.

Table 9.6.3.3-1: SEALDD context pull request

Information element	Status	Description
Requestor ID	M	Identifies the requestor (i.e. new SEALDD server).
SEALDD policy indication	O	Indicates the need to transfer the VAL server configured SEALDD policy.

9.6.3.4 SEALDD context pull response p. 69

Table 9.6.3.4-1 describes the information flow from the old SEALDD server to the new SEALDD server for responding to the SEALDD context pull request.

Table 9.6.3.4-1: SEALDD context pull response

Information element	Status	Description
Result	M	Success or failure.
SEALDD-Uu Context	O (NOTE)	Identifies the context related to SEALDD-Uu connection, which is created upon SEALDD connection establishment.
SEALDD-S Context	O (NOTE)	Identifies the context related to SEALDD-S subscription.
Transport layer context	O (NOTE)	Identifies the context related to Transport layer (e.g. TCP/TLS/QUIC) for SEALDD-Uu user plane communication.
SEALDD policy	O (NOTE)	Indicates the VAL server configured SEALDD policy.
NOTE: These IEs are applicable when the result is success.

9.6.3.5 SEALDD Inform ACR event request |R19| p. 69

Table 9.6.3.5-1 describes the information flow from the VAL server to the SEALDD server to inform the ACR event, for ACR coordination purpose.

Table 9.6.3.5-1: SEALDD Inform ACR event request

Information element	Status	Description
VAL server ID	M	Identity of the VAL server.
VAL service ID	O	Identity of the VAL service.

9.6.3.6 SEALDD Inform ACR event response |R19| p. 69

Table 9.6.3.6-1 describes the information flow from the SEALDD server to the VAL server for responding to the SEALDD Inform ACR event request.

Table 9.6.3.6-1: SEALDD Inform ACR event response

Information element	Status	Description
Result	M	Success or failure.

9.6.3.7 SEALDD Inform ACR event notification |R19| p. 70

Table 9.6.3.7-1 describes the information flow from the SEALDD server to the VAL server for notifying ACR event related information.

Table 9.6.3.7-1: SEALDD Inform ACR event notifiation

Information element	Status	Description
SEALDD flow transfer result	M	Success or failure.

9.6.4 APIs p. 70

9.6.4.1 General p. 70

Table 9.6.4.1-1 illustrates the APIs exposed by SEALDD server for UE's service continuity.

Table 9.6.4.1-1: List of SEALDD server APIs for UE's service continuity

API Name	API Operations	Operation Semantics	Consumer(s)
Sdd_DDContext	Push Request	Request/Response	SEALDD server
Sdd_DDContext	Pull Request	Request/Response	SEALDD server
Sdd_InformACREvent	Request	Subscribe/Notify	VAL server
Sdd_InformACREvent	Notify	Subscribe/Notify	VAL server

9.6.4.2 Sdd_DDContext_Push Request operation p. 70

API operation name:

Sdd_DDContext_Push Request

Description:

The consumer requests to push SEALDD context.

Inputs:

See clause 9.6.3.1.

Outputs:

See clause 9.6.3.2

See clause 9.6.2.1 for details of usage of this operation.

9.6.4.3 Sdd_DDContext_Pull Request operation p. 70

API operation name:

Sdd_DDContext_Pull Request

Description:

The consumer requests to pull SEALDD context.

Inputs:

See clause 9.6.3.3.

Outputs:

See clause 9.6.3.4

See clause 9.6.2.1 for details of usage of this operation.

9.6.4.4 Sdd_InformACREvent_Request operation |R19| p. 70

API operation name:

Sdd_InformACREvent_Request

Description:

The consumer informs ACR event to SEALDD server, for ACR coordination purpose.

Inputs:

See clause 9.6.3.5.

Outputs:

See clause 9.6.3.6.

See clause 9.6.2.2 for details of usage of this operation.

9.6.4.5 Sdd_ InformACREvent _Notify operation |R19| p. 71

API operation name:

Sdd_InformACREvent_Notify

Description:

SEALDD server notifies information about previously informed ACR event.

Inputs:

See clause 9.6.3.7.

Outputs:

See clause 9.6.3.7.

See clause 9.6.2.2 for details of usage of this operation.