Content for  TS 23.434  Word version:  19.0.0

The NRM client 1 sends the application connectivity request (source identity and IP address, destination identities, service requirements) to the NRM Server. The service requirement from the source includes packet size, packet transmission interval, packet E2E latency, allowed packet loss rate/packet loss amount/packet error rate, etc. The destination may be multiple UEs (devices). The identity of source and destination may be the application user identity or the MAC address. 1b. The NRM server determines whether the UE of NRM client 1 is authorized to connect to the destination UEs for direct service communications via Uu. If UE of NRM client 1 is authorized to connect to the destination UEs, then a response is provided to the NRM client 1 indicating acceptance of the request.

The NRM client 2 sends the application connectivity request (destination identity and IP address, source identity, service requirements) to the NRM server. The service requirements from the destination includes the service requirements as described in step 1a.

The NRM server determines whether the UE of NRM client 2 is authorized to connect to the destination UEs for direct service communications via Uu. If UE of NRM client 2 is authorized to connect to the destination UEs, then a response is provided to the NRM client 2 indicating acceptance of the request.

Based on the service requirements received in step 1 and step 2, the NRM server determines the parameters and patterns for direct service connectivity between the UEs via Uu and also the transport requirements, i.e., QoS requirements for the 3GPP system (e.g. 5GS). This step may also include retrieving the direct link status of the UEs (e.g. PDU Session Status, UE reachability). If the NRM server determines that direct service connectivity via Uu is not authorized or not possible with the given connectivity requirements, it skips step 4 and proceeds to steps 5 and 6, informing each NRM client accordingly. NRM server will process E2E connectivity establishment between NRM client 1 and NRM client 2 only after it receives the request from NRM client 2. There can be several NRM clients (destinations) which will perform step 2 and NRM server will process their E2E connectivity with NRM client 1 (source) as and when the requests are received by the NRM server.

The NRM server triggers 3GPP system to establish Uu connectivity between the UE of NRM client 1 and UE of NRM client 2 with required QoS as specified in TS 23.501.

The NRM server sends the application connectivity notification (connectivity/session information) to NRM client 1 indicating successful establishment of the connectivity. The connectivity/session information may contain the accepted destination identities.

The NRM server sends the application connectivity notification (connectivity/session information) to NRM client 2 indicating successful establishment of the connectivity.

The NRM client 1 sends the application connectivity request (source identity and IP address, destination identities, application requirements) to the NRM server to establish connectivity for VAL client 1 on UE 1. The destination VAL client(s) may be hosted on one or multiple UEs (devices).

The NRM server determines whether VAL client 1 is authorized to connect to VAL client 2 for application-level direct UE-to-UE communications. If VAL client 1 is authorized to connect to VAL client 2, the NRM server performs the get application connectivity context request to retrieve VAL UE-to-UE connection coordination context procedure as described in clause 14.3.2.56. This step can be skipped if the NRM server is already aware of VAL client 2's context information.

The NRM client 2 sends the get application connectivity context response to the NRM server 2. Using the request information and local policies, the NRM client 2 determines whether context information is to be provided for establishing application-level direct connectivity to the counterpart UE for the VAL application indicated. If the NRM client determines that context information is to be provided, it responds to the NRM server and provides the VAL connection coordination context data for the VAL client served.

The NRM server sends the application connectivity response to NRM client 1.

The NRM server uses VAL client 1's and VAL client 2's context information, their application-level direct UE-to-UE connectivity requirements, location information, and network context as input, checks connectivity service policies, and determines the parameters and patterns for application-level direct UE-to-UE connectivity between the VAL clients. The NRM server may also determine transport requirements, e.g. QoS requirements, for the 3GPP system (e.g. 5GS). If network provided location information is used, location information may be obtained from the SEAL location management server. Alternatively, Location Reporting monitoring as described in TS 23.502 may be used. This step may also include a request for direct link status (e.g. PDU Session Status, UE reachability, etc. as described in TS 23.502). This action may be skipped if the clients provide location information or if there are no location requirements for establishing the application-level direct UE-to-UE connectivity. If the NRM server determines that UE-to-UE application-level direct connectivity is not authorized or not possible with the given connectivity requirements, it skips step 5 and proceeds to steps 6 and 7, informing each NRM client accordingly.

The NRM server may request the 3GPP system to establish or modify the 3GPP system level connectivity that enables the application-level direct UE-to-UE connection for VAL client 1 and VAL client 2 services, e.g. via modification of existing radio bearers. NRM server provides the necessary information (e.g. identifiers of VAL client 1 and VAL client 2, transport requirements) in this request message.

a. The NRM server notifies NRM client 1 of the established UE-to-UE connection b. The NRM server notifies the NRM client 2 of the established UE-to-UE connection.