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.3.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.9.3…   9.10…   9.10.3…   9.11…   9.11.3…   9.12…   A…   C   D… 
9.2 SEALDD regular connection management  9.2.1 General  9.2.2 Procedure  9.2.2.1 SEALDD enabled signalling transmission connection establishment procedure  9.2.2.2 SEALDD enabled regular data transmission connection establishment procedure 
...

 

9.2  SEALDD regular connection management  p. 23

9.2.1  General  p. 23

The following clauses specify procedures, information flow and APIs for establishing an SEALDD enabled end-to-end connection between VAL client and VAL server. The end-to-end connection (also termed SEALDD-UU flow) is uniquely identified in the SEALDD layer by the SEALDD-UU flow ID. The specific procedures detailed in the subsequent clauses are for cases in which the SEALDD regular connection is used respectively for application signalling, application data delivery initiated by VAL server, and application data delivery initiated based on DD policy.
Up

9.2.2  Procedure  p. 24

9.2.2.1  SEALDD enabled signalling transmission connection establishment procedure  p. 24

Figure 9.2.2.1-1 illustrate the procedure for signalling transmission connection establishment.
Pre-condition:
  • The VAL server can discover and select the SEALDD server by CAPIF functions.
Reproduction of 3GPP TS 23.433, Fig. 9.2.2.1-1: SEALDD signalling transmission connection establishment procedure
Figure 9.2.2.1-1: SEALDD signalling transmission connection establishment procedure
Up
Step 1.
The VAL server decides to use SEALDD service for application signalling transfer and allocates address/port as SEALDD-S Data transmission connection information for receiving the application signalling packets from SEALDD server. The VAL server sends Sdd_RegularTransmission request to the SEALDD server. The service request includes the VAL server ID, VAL service ID to identify the VAL application traffic, the SEALDD-S Data transmission connection information of the VAL server side.
Step 2.
Upon receiving the request, the SEALDD server performs an authorization check. If authorization is successful, the SEALDD server allocates a specific address or port used for SEALDD traffic transfer with the incoming SEALDD client(s) for the VAL server and responds with a SEALDD service response.
Step 3.
The VAL client sends a SEALDD service request to SEALDD client. The service request also indicates to establish application signalling transmission connection. The VAL client receives a SEALDD service response to the SEALDD client. The response indicates that whether the SEALDD service request is successful or not.
Step 4.
The VAL/SEALDD client discovers and selects the proper SEALDD server for the VAL application, as described in clause 9.4.3. After this step, the VAL server is discovered and selected along with the associated SEALDD server, the SEALDD client can get the SEALDD server's address.
Step 5.
The SEALDD client allocates SEALDD-UU flow ID(s) mapping to application traffic for application signalling transmission. The SEALDD client sends Sdd_RegularTransmissionConnection_Establish request to SEALDD server with the SEALDD client ID, the SEALDD-UU flow ID(s), VAL server ID, VAL service ID and the SEALDD traffic descriptor of the SEALDD client side (the address/port of the SEALDD client for receiving the downlink SEALDD traffic). The request message also contains the selected VAL server endpoint information. The SEALDD server retrieves the location information of the VAL UE or SEALDD client from SEAL LM services defined in clause 9.3.12 of TS 23.434 and verifies with the Geofence policy configured by the VAL server to allow or restrict the signalling connection establishment. If the location information is allowed as per the configured geofence policy then the SEALDD server allows the signalling connection establishment, otherwise SEALDD server returns failed result e.g. performs connection reject.
Step 6.
The SEALDD server responds to the SEALDD client with the SEALDD traffic descriptor of SEALDD server side (e.g. address/port allocated in step 2, transport layer protocol) mapping to the application traffic.
Step 7.
The SEALDD server stores the SEALDD client ID, SEALDD-UU flow ID(s) to identify the SEALDD traffic and establishes SEALDD-S connection with VAL server for the VAL client to transmit application traffic mapping to the SEALDD traffic. SEALDD server may use different address/port to establish the SEALDD-S data transmission connection for application signalling transfer towards the VAL server for different SEALDD client and SEALDD-UU flow. Then each VAL client will have different SEALDD-S data transmission connection at the SEALDD server side.
Step 8.
The SEALDD client uses the SEALDD traffic descriptor of SEALDD server side for SEALDD connection establishment.
After this step, the SEALDD client and SEALDD server both get the whole SEALDD traffic descriptor (including the UE's address/port and SEALDD server's address/port for the SEALDD traffic transmission). The SEALDD client gets the mapping information (i.e. SEALDD-UU flow ID for the application signalling transfer). The SEALDD server gets the mapping information between the SEALDD-UU flow ID, the signalling transmission Session ID and the SEALDD-S connection. The SEALDD client and SEALDD server store the mapping between the application traffic and SEALDD traffic.
Upon receiving application signalling traffic from VAL client, the SEALDD client maps it into SEALDD traffic with SEALDD traffic descriptor as negotiated with SEALDD server. The SEALDD server maps the SEALDD traffic to the application traffic according to the stored SEALDD traffic descriptor, SEALDD client ID, SEALDD-UU flow ID. The SEALDD server sends the recovered application traffic to VAL server via the connection established in step 7 according to the mapping relationship between the SEALDD-S connection and the SEALDD traffic.
For the downlink application signalling traffic in response to the uplink application signalling, the VAL server can respond to the source address/port (SEALDD-S address/port of the SEALDD server side) of the uplink signalling traffic. Upon receiving the downlink application signalling traffic from the SEALDD-S connection, the SEALDD server can map the downlink application signalling traffic to the related SEALDD client ID and SEALDD-UU flow ID and send the mapped SEALDD traffic to the SEALDD client. The rest of the downlink application traffic transfer is processed similarly with the uplink traffic.
After the connection establishment, the VAL server can communicate with VAL client for application layer signalling traffic transfer via the established SEALDD connection.
Up

9.2.2.2  SEALDD enabled regular data transmission connection establishment procedure  p. 25

Figure 9.2.2.2-1 illustrate the procedure for establishing regular SEALDD data transmission connection.
Pre-condition:
  • The VAL server can discover and select the SEALDD server by CAPIF functions.
Reproduction of 3GPP TS 23.433, Fig. 9.2.2.2-1: SEALDD enabled regular data transmission connection establishment procedure
Figure 9.2.2.2-1: SEALDD enabled regular data transmission connection establishment procedure
Up
Step 1.
The VAL server decides to use SEALDD service for application traffic transfer and allocates address/port as SEALDD-S Data transmission connection information for receiving the data packets from SEALDD server. The VAL server sends Sdd_RegularTransmission request to the SEALDD server discovered by CAPIF. The service request includes UE ID/address, VAL server ID, VAL service ID, SEALDD-S Data transmission connection information of the VAL server side, and optionally, the QoS information for the application traffic, e.g. QoS requirements.
Step 2.
Upon receiving the request, the SEALDD server performs an authorization check. If authorization is successful, SEALDD server allocates address/port of the SEALDD server to receive the packets from the VAL server for application data transfer as SEALDD-S data transmission connection information of the SEALDD server side. The SEALDD server allocates a specific address or port used for SEALDD traffic transfer with the specific UE for the VAL server and responds with a SEALDD service response (including SEALDD-S data transmission connection information of the SEALDD server side). The VAL server and SEALDD server can use SEALDD-S data transmission connection information to establish the data transmission connection between VAL server and SEALDD server for application data transfer.
The SEALDD server may send the AF request to provide the required QoS information to 5GC via N33/N5, as defined in clause 5.2.6.9 and in clause 5.2.5.3 of TS 23.502. The AF request includes the application traffic descriptor containing the address or ports allocated by SEALDD server, and the QoS information for application traffic. The QoS information may be determined by SEALDD server according to VAL service ID for different service type of application traffic if the QoS information is not provided by VAL server. 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 APIs 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.
Step 3.
Data transmission session information is provisioned to the VAL client by the VAL server via application signalling.
Step 4.
The VAL client sends a SEALDD service request to SEALDD client. The VAL client receives a SEALDD service response to the SEALDD client. The response indicates that whether the SEALDD service request is successful or not.
Step 5.
The VAL/SEALDD client discover and select the proper SEALDD server for the VAL application, as described in clause 9.4.3. After this step, the VAL server is discovered and selected along with the associated SEALDD server, the SEALDD client can get the SEALDD server's address.
Step 6.
The SEALDD client allocates SEALDD-UU flow ID(s) mapping to the identifiers of the application traffic. The SEALDD client sends Sdd_RegularTransmissionConnection_Establish request to SEALDD server with the SEALDD client ID, the SEALDD-UU flow ID(s), the SEALDD traffic descriptor of the SEALDD client side (the address/port of the SEALDD client for receiving the downlink SEALDD traffic), VAL server ID, VAL service ID. The request message also contains the selected VAL server endpoint information and UE ID. The SEALDD server retrieves the location information of the VAL UE or SEALDD client from SEAL LM services defined in clause 9.3.12 of TS 23.434 and verifies with the Geofence policy configured by the VAL server to allow or restrict the data connection establishment. If the location information is allowed as per the configured geofence policy then the SEALDD server allows the data connection establishment, otherwise SEALDD server returns a failed result e.g. performs connection reject.
Step 7.
The SEALDD server responds to the SEALDD client with the SEALDD traffic descriptor of SEALDD server side (e.g. address/port allocated in step 2, transport layer protocol) mapping to the application traffic.
Step 8.
If the connection between VAL server and SEALDD server is not established in step 2, the SEALDD server establishes connection with VAL server for the VAL client to transmit application traffic mapping to the SEALDD traffic according to the SEALDD-S information negotiated in step 1-2.
Step 9.
The SEALDD client uses the SEALDD traffic descriptor of SEALDD server side for SEALDD connection establishment.
After this step, the SEALDD client and SEALDD server both get the whole SEALDD traffic descriptor (including the UE's address/port and SEALDD server's address/port for the SEALDD traffic transmission).
After the negotiation and establishment of the connections, the SEALDD client gets the mapping information between application traffic and SEALDD-UU flow ID. The SEALDD server gets the mapping information between the SEALDD-UU flow ID and the SEALDD-S connection. Upon receiving application traffic from VAL client, the SEALDD maps it to SEALDD traffic with SEALDD traffic descriptors as negotiated with SEALDD server in step 6 and step 7. The SEALDD traffic is sent to the SEALDD server. The SEALDD server maps the SEALDD traffic to the application traffic according to the stored SEALDD traffic descriptor, SEALDD client ID and SEALDD-UU flow ID. The SEALDD server sends the recovered application traffic to the address provided by VAL server in step 1, via the connection established in step 2 or 8 according to the mapping information. The downlink application traffic sent from VAL server to VAL client is processed similarly.
The SEALDD server receives any UE location change notification using SEAL LM services defined in clause 9.3.12 of TS 23.434, then the SEALDD server performs the data delivery in alignment with the geofence policy. If the UE is in the forbidden location or not allowed for the given VAL service to send/receive data as per the Geofence policy, then the SEALDD server performs action like releases the connection and informs the VAL server that UE is not reachable because in a forbidden location using connection event status procedure. If UE enters the allowed location area then the SEALDD server initiates the connection establishment using the procedure defined in clause 9.2.2.3.
Up

Up   Top   ToC