Content for  TS 23.434  Word version:  19.4.2

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 source UE and the destination UE via Uu and also the transport requirements (i.e., QoS requirements for the 3GPP system (e.g. 5GS)). Further, the NRM server derives the individual QoS requirements for the source UE and the destination UE from the transport requirement accordingly, i.e., the QoS requirements required between the source UE of NRM client 1 and the 3GPP network and the QoS requirements required between the destination UE of NRM client 2 and the 3GPP network. 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 QoS flow between the UE of NRM client 1 and the 3GPP network and the QoS flow between the UE of NRM client 2 and the network with individual QoS requirements derived from step 3 followed the procedure as specified in TS 23.502, 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)). Further, the NRM server derives the individual QoS requirements for the source UE and the destination UE from the transport requirement accordingly, i.e., the QoS requirements required between the source UE of NRM client 1 and the 3GPP network and the QoS requirements required between the destination UE of NRM client 2 and the 3GPP network. 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 QoS flow between the source UE and the network, and the QoS flow between the destination UE and the network 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 as per the procedure as specified in TS 23.502, TS 23.501.

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.

The NRM Server determines an initial UE unified traffic pattern, e.g. by using all Traffic pattern configurations received for the UE .

The NRM Server determines, based on local policy that UE monitoring events are to be configured and executes the corresponding Monitoring procedure as described in clause 4.4.2 of TS 29.122.

The NRM Server updates the UE unified traffic pattern based on the received monitoring events as follows:

• If a Monitoring Notification report for UE_REACHABILITY is received, and idleStatusInfo information is provided in the report, the NRM Server changes the schedule element of the UE unified traffic pattern such that the duration of activity is set to the value of the activeTime parameter configured in the idleStatusInfo.
• If a Monitoring Notification report for AVAILABILITY_AFTER_DDN_FAILURE is received after UEs transition to idle mode, the NRM Server updates the schedule element of the UE unified traffic pattern such that: the start of an activity window is based on the Idle Timestamp, with a periodicity equal to the TAU/RAU Timer; the duration of the activity window indicates the Active Time value.
• If a Monitoring Notification report for COMMUNICATION_FAILURE is received The NRM updates the schedule element of the UE unified traffic pattern to indicate that no communications are currently available (e.g. by using a keyword such as "NULL"). Local policies may specify events/ thresholds further defining when the NRM may provide a UE unified traffic pattern update based on monitoring events. For example, the update may be provided only after repeated communication failures are received within a timespan, or only if high reliability communications are expected. It is recommended that UE Reachability monitoring is also enabled in conjunction with the Communication Failure monitoring. This enables the NRM to provide updated timing information once the UE becomes reachable again.
• If a Monitoring Notification report for LOSS_OF_CONNECTIVITY is received, the NRM Server changes the schedule element of the UE unified traffic pattern to indicate that no communications are currently available.

Conditional: The NRM Server notifies subscribers of the UE unified traffic pattern updates, as described in clause 14.3.2.55

The NRM Server determines to provide Network parameter configuration to 5GC. This determination can be based on updates to the UE unified traffic patterns resulting from interactions with VAL Servers (e.g. Traffic pattern configuration updates), on local policies, etc. The NRM Server determines parameters the needed for NpConfiguration data structure as specified in TS 29.122 from the UE unified traffic patterns as follows:

• maximumLatency - This value tells the network how long the UE is allowed to sleep. Setting it to 0 will disable PSM, extended idle mode DRX, and extended buffering. The NRM Server can extract the periodicity derived from the UE unified traffic pattern, which includes the schedule elements for the UEs communications with all VAL servers. The NRM Server sets Maximum Latency to be approximately the periodicity of the active periods derived from the schedule element of the UE unified traffic pattern.
• maximumResponseTime - When the UE uses PSM, Maximum Response Time tells the network how long the UE should stay reachable after a transition to idle. When the UE uses eDRX, Maximum Response Time is used by the network to determine when to send a reachability notification before a UE's paging occasion. The NRM Server extracts a duration of activity from the schedule element of the UE unified traffic pattern and sets Maximum Response Time to reflect the duration of activity, indicating how long the UE should stay reachable for downlink communications.

The NRM Server performs the Network Parameter Configuration procedure as described in clause 4.4.12 of TS 29.122.