The NRM client and the NRM server (acting as an AS) are involved in the exchange and analysis of the desired service requirements (e.g. packet size, packet transmission interval, reliability, packet error rate) for the E2E communication amongst the Vertical UEs. The NRM server triggers the establishment of application-level direct service connectivity between two UEs via Uu, based on the information provided by the UEs and static configuration information available to the NRM server prior to the UE interaction. Note that service connectivity among VAL clients is established over the Uu, without device-to-device direct radio connectivity (e.g. PC5) requirement.
The procedure for establishing Uu-based application-level direct communications between two UEs, with application service requirements is as illustrated in Figure 14.3.9.2.1-1. In this procedure the source and destination VAL clients correlate their triggering of the procedure establishment before the NRM Server provides the service.
Pre-conditions:
NRM client 1 and NRM client 2 are provided configuration information for the VAL clients served e.g. connectivity requirements, which destination UEs to connect to over Uu, etc.
The NRM client 1 and NRM client 2 are configured with the information of the NRM server and have connectivity enabled to communicate with the NRM server. The information is provided via pre-configuration.
The NRM server is configured with policies and information of the UEs to determine authorization of the UEs requesting connectivity via Uu.
The VAL clients associated with NRM client 1 and NRM client 2 have triggered the establishment of connectivity.
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.
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.
This procedure is used for establishing Uu-based application-level direct communications between two UEs, based on a single client initiating and providing application requirements. The procedure is as illustrated in Figure 14.3.9.2.2-1. The NRM Server provides the service by coordinating with the destination client.
Pre-conditions:
NRM client 1 and NRM client 2 are provided configuration information for the VAL clients served e.g. connectivity requirements, etc.
Pre-processing determines that network assisted UE-to-UE communications is required. VAL application policies and destination information for NRM clients are available at the NRM server.
The VAL client associated with NRM client 1 triggers the establishment of connectivity and provides information about (one or more) destination VAL client(s).
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 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.
Each NRM client notifies the corresponding VAL client of the established application-level direct UE-to-UE connection.
The SEALDD server (or VAL server) has decided to use reliable transmission for a specific SEALDD client (or VAL client) and has got the UE address or UE ID.
The NRM server receives from the SEALDD server (or VAL server) about the request for reliable transmission service with the application descriptors for the two redundant transmission paths. The SEALDD client's current UE address or UE ID is also provided to identify the affected UE.
After receiving the request from SEALDD server (or VAL server), the NRM server associates the available DNN and S-NSSAI information for the two application descriptors. NRM server triggers via N5/N33 with the AF guidance for URSP procedure as described in clause 4.15.6.10 of TS 23.502. The AF request includes the application traffic descriptors and the associated DNN, S-NSSAI, and also includes UE address or UE ID received in step 1.
The VAL server consumes the network resource management services from the NRM server. As specified in TS 23.501, a dedicated user plane anchor point, i.e. UPF + PGW-U function, is defined for interworking between 5GS and EPS. This enables that the network can directly handle PDU sessions (in 5GS) and PDN connections (in EPS) associated to VAL service sessions of a VAL UE during inter-system mobility.
The inter-system mobility of a VAL UE will be transparent to the NRM server and VAL server. The NRM server will continue interacting with the same control plane functions, e.g. PCF, and the VAL server will continue interacting with the same user plane function, e.g. UPF + PGW-U.