Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.433  Word version:  19.0.0

Top   Top   Up   Prev   Next
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.10…   A…   C… 
9.2.2.3 SEALDD enabled regular data transmission connection establishment based on policy  9.2.2.4 SEALDD enabled regular data transmission connection deletion based on policy  9.2.2.5 SEALDD client initiated connection release  9.2.2.6 SEALDD connection status procedure  9.2.2.6.1 General  9.2.2.6.2 Procedures 
...

 

9.2.2.3  SEALDD enabled regular data transmission connection establishment based on policy  p. 27

The SEALDD servers has Data Delivery (DD) policy being provisioned. Before the application communication between VAL client and VAL server starts, the DD policy is enforced by the SEALDD server to establish the SEALDD connection.
Pre-conditions:
  1. The SEALDD server has DD policies available.
Reproduction of 3GPP TS 23.433, Fig. 9.2.2.3-1: Policy enforced by SEALDD server for connectivity
Figure 9.2.2.3-1: Policy enforced by SEALDD server for connectivity
Up
Step 1.
The VAL server subscribes to SEALDD event exposure for connection status using the procedure defined in clause 9.2.2.6.
Step 2.
When the time for data transmission is about to start, the SEALDD server enforces the policy to trigger regular data transmission connection establishment. If spatial condition for UE is provided, the SEALDD server also ensures the UE's location requirement is satisfied when establishing regular data transmission connection (e.g. by using NEF service for monitoring UE location or SEAL location service for UE entering area of interest).
Step 3.
If there is a special routing requirement for SEALDD user plane traffic (e.g. running on a specific slice and DNN), the SEALDD server interacts with 3GPP CN to provision service specific parameters with NEF as described in clause 4.15.6.10 and clause 4.15.6.7 of TS 23.502.
If there are QoS requirements in the DD policy, the SEALDD server also applies QoS to ensure the quality for SEALDD traffic by utilizing NEF/PCF/NRM/EES service for QoS adjustment. Specifically, the SEALDD server relies on the northbound Policy Authorization Service API exposed by the PCF as specified in TS 23.502 and TS 23.503, if the SEALDD server is connected to the PCF via the N5 reference point, or the northbound AF Session with QoS Service API and/or the PFD Management northbound APIs exposed by the NEF as specified in TS 23.502 and TS 23.503, if the SEALDD server is connected to the PCF via NEF. SEALDD may also rely upon the EES Session with QoS API as specified in TS 23.558 and/or the NRM QoS functionality as described in TS 23.434.
If the DD policy specifies failure detection report, the SEALDD server may subscribe to CN analytics (e.g. DN performance analytics) from NEF/NWDAF and further notify data delivery status of application traffic to VAL client (via SEALDD client) and VAL server based on analytics result.
Step 4.
The SEALDD server allocates an IP address and port for sending and receiving packet over SEAL-S reference point, then SEALDD server sends SEALDD connection establishment notification to the VAL server with VAL service ID, the IP address and port.
Step 5-6.
The SEALDD server allocates an IP address and port for sending and receiving packet over SEAL-Uu reference point, then SEALDD server sends regular data transmission connection establishment request to the SEALDD client with SEALDD flow ID, VAL service ID, the IP address and port. The request is responded by the SEALDD client. UE IP address (and port) may be included by the SEALDD client in the response or sent in a separate update message by SEALDD client if a different UE IP address is to be used in SEALDD connection user plane.
Step 7.
The SEALDD client further notifies the VAL client about the SEALDD connection being established.
Upon receiving application traffic from VAL client (not shown in the Figure), the SEALDD client sends it to SEALDD server in SEALDD traffic. The SEALDD server identifies application traffic based on the VAL service ID and further sends the application traffic to VAL server. The downlink application traffic sent from VAL server to VAL client is processed similarly.
Up

9.2.2.4  SEALDD enabled regular data transmission connection deletion based on policy  p. 28

Reproduction of 3GPP TS 23.433, Fig. 9.2.2.4-1: SEALDD enabled regular data transmission connection deletion
Figure 9.2.2.4-1: SEALDD enabled regular data transmission connection deletion
Up
Step 1.
SEALDD server decides to remove the connection. Such a decision may be based on decision in SEALDD server in the following cases:
  1. DD policy removal or validity time expiration;
  2. DD policy specified end time reached for SEALDD communication;
  3. UE is leaving the area of interest (if spatial condition for UE is provided in the policy).
Step 2-3.
The SEALDD server notifies SEALDD connection deletion to the VAL server. The VAL server removes the connection information. The application traffic is stopped on both sides.
Step 4-5.
The SEALDD server requests regular data transmission connection deletion to the SEALDD client. The request is responded by the SEALDD client. The application traffic is stopped on both sides.
Step 6.
The SEALDD client further notifies the VAL client about the SEALDD connection being removed. The application traffic is stopped on both sides.
Step 7.
If a special routing requirement for SEALDD user plane traffic was provided to 3GPP CN, the SEALDD server interacts with 3GPP CN to remove service specific parameters with NEF as described in clause 4.15.6.7 of TS 23.502.
Step 8.
The SEALDD server removes the SEALDD connection (i.e. deletes the SEALDD connection context).
Up

9.2.2.5  SEALDD client initiated connection release  p. 29

Figure 9.2.2.5-1 illustrates the procedure for SEALDD client initiated connection release procedure from the SEALDD client to the SEALDD server.
Reproduction of 3GPP TS 23.433, Fig. 9.2.2.5-1: SEALDD client initiated connection release
Figure 9.2.2.5-1: SEALDD client initiated connection release
Up
Step 1.
The SEALDD client sends the SEALDD connection release request to the SEALDD server to release the established connection.
Step 2.
The SEALDD server releases the SEALDD-UU data transmission connection (which was established by SEALDD client or SEALDD server) and sends the response in the SEALDD connection release response message. Upon receiving the acknowledgement, the SEALDD client can release the connection resources.

9.2.2.6  SEALDD connection status procedure |R19|  p. 29

9.2.2.6.1  General  p. 29
The following clauses specify procedures, information flow for SEALDD connection status.
9.2.2.6.2  Procedures  p. 29
9.2.2.6.2.1  SEALDD connection status procedure  p. 29
Figure 9.2.2.6.2.1-1 illustrates the procedure for SEALDD connection status from the VAL server to the SEALDD server.
Reproduction of 3GPP TS 23.433, Fig. 9.2.2.6.2.1-1: SEALDD connection status procedure
Figure 9.2.2.6.2.1-1: SEALDD connection status procedure
Up
Step 1.
The VAL server sends the SEALDD connection status subscribe request to the SEALDD server. The request includes the identifiers of the application traffic (e.g. VAL service ID, VAL server ID), VAL UE identity, and the SEALDD client connection status check periodicity.
Step 2.
The SEALDD server subscribes to the NEF UE reachability, Application Detection and Loss of connectivity events using the procedure defined in clause 4.15.3.2.3b of TS 23.502. It can also use the NRM Event monitoring procedure defined in clause 14.3.6.2.2 of TS 23.434.
Step 3.
The SEALDD server also sends a SEALDD client connection status reporting configuration request to the SEALDD client. The request message consists of reporting interval, flow ID, and method of reporting. The SEALDD client configures the connection status reporting configuration and sends a SEALDD client connection status reporting configuration response. The flow ID identifies the application traffic flow for which the reporting notification is configured. The SEALDD client monitors the application using flow ID. The method of reporting is defined as regular or irregular. The regular reporting method uses the reporting interval to send the notification. The irregular reporting method sends the notification if the current connection status state is different from the previous connection status state or if the application state changes (like crash, close, stop).
Step 4.
The SEALDD client configures the reporting configuration and provides the response to the SEALDD server.
Step 5.
The SEALDD server sends the connection status subscription response to the VAL server.
Step 6a-6b.
The SEALDD server receives the notification for the UE connection status from the subscribed NEF, NRM. It can also receive a notification from the SEALDD client regarding the connection status. If the UE is in power saving mode, then the SEALDD client sends the connection status reporting notification with the status as sleeping to the SEALDD server and suspends the connection status periodic reporting.
Step 7.
Based on the NRM, NEF event subscription response and SEALDD client connection status reporting notification message, the SEALDD server processes the responses and sends the SEALDD client connection status of unreachable or sleeping status notification to the VAL server.
Up

Up   Top   ToC