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.
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.
Step 1.
An application client on a UE, acting as a VAL client, establishes a SEALDD flow over SEALDD-UU to send application data to VAL Server 1. SEALDD client and SEALD server 1 maintain SEALDD flow information (e.g., SEALDD flow ID, VAL IDs/addresses, VAL requirements).
Step 2.
Application data is sent via the SEALDD flow between the VAL Client and VAL Server 1.
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 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.
Step 12.
The application data from the VAL Client is sent via the SEALDD flow (with SEALDD server 2) to VAL Server 2.