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.434  Word version:  19.5.0

Top   Top   Up   Prev   Next
0…   6…   8…   9…   9.3…   9.3.3…   9.3.8…   9.3.13…   9.3.20…   9.3.23…   9.4…   10…   10.3…   10.3.3…   10.3.7…   10.4…   11…   12…   13…   14…   14.3…   14.3.3   14.3.4   14.3.4A…   14.3.4A.5…   14.3.4A.8…   14.3.5…   14.3.9…   14.4…   15…   17…   18…   A… 
14.3.5 QoS/resource management for network-assisted UE-to-UE/VN group communications  14.3.6 Event Monitoring  14.3.7 5G TSC resource management procedures  14.3.8 TSN resource management procedures 
...

 

14.3.5  QoS/resource management for network-assisted UE-to-UE/VN group communications |R17|  p. 285

14.3.5.1  General  p. 285

This feature provides the SEAL NRM support for coordinated QoS/resource management for network assisted UE-to-UE communications. Such capability may be required for guaranteeing end-to-end QoS fulfilment (primarily for meeting end-to-end latency requirements) in network assisted UE to UE communications and may accommodate various vertical-specific application services, e.g.:
  • Network-assisted Command and Control (C2) communications in UASAPP (TS 23.255), where the UAV controller navigates its UAV over the 5GS;
  • Teleoperated Driving (ToD) in eV2XAPP (TS 23.286), where the a V2X UE acting as server may remotely control a further V2X UE over the 5GS;
  • Network-assisted Device-to-Device communications in Factory of the Future (FF) use cases, such as control-to-control communications.
  • 5G LAN-Type communication within a 5G VN group as specified in TS 23.501.
  • Application QoS coordination for Mobile Metaverse Services in distributed VAL servers.
Up

14.3.5.2  QoS/resource management capability initiation in network assisted UE-to-UE communications  p. 285

This procedure provides a mechanism for initiating the capability at the NRM server for managing the end-to-end application QoS requirement fulfilment for a network-assisted VAL UE to VAL UE session (comprising a PDU session for each of the constituent links, e.g. VAL UE 1 to PLMN, and PLMN to VAL UE 2). The request may come from NRM client of either of the VAL UEs within the service and will trigger the end-to-end QoS/resource management by the NRM server. The triggering the end-to-end QoS management request can be initiated by the VAL application at the VAL UE, and the conditions may depend on the requirements of the VAL service, e.g. for UAS such triggering may be needed when a UAV is in-flight, or for V2X such trigger may be initiated when a controlled VAL UE enters an urban area, or for 5G LAN-type service such trigger may be initiated by the AF (e.g. on VAL UE1) that manages the corresponding 5G VN group.
The clause 14.3.5.2.1 describes the end-to-end QoS/resource management capability for network-assisted UE-to-UE communications for a single pair of UEs.
The clause 14.3.5.2.2 describes the end-to-end QoS/resource management capability for network-assisted UE-to-UE communications for a group of UEs.
Up
14.3.5.2.1  Procedure for a single pair of UEs  p. 285
Figure 14.3.5.2.1-1 illustrates the procedure where the NRM server is initiating the end-to-end QoS/resource management capability for network-assisted UE-to-UE communications for a single pair of UEs.
Pre-conditions:
  1. The NRM client is connected to the NRM server.
  2. The VAL UEs involved in the end-to-end session (VAL UE 1 and VAL UE 2) are connected to one or more PLMNs and have ongoing PDU sessions.
  3. NRM server has used the "Setting up an AF session with required QoS procedure" (clause 4.15.6.6 of TS 23.502).
Reproduction of 3GPP TS 23.434, Fig. 14.3.5.2.1-1: end-to-end QoS management request / response
Figure 14.3.5.2.1-1: end-to-end QoS management request / response
Up
Step 1.
The NRM client 1 (of VAL UE 1) sends to the NRM server an end-to-end QoS management request for managing the QoS for the end-to-end application session.
Step 2.
The NRM server configures the application QoS parameters by decomposing the end-to-end QoS requirements (VAL UE 1 to VAL UE 2) to application QoS parameters for each individual session (e.g. network session for VAL UE 1 -and network session for VAL UE 2) which are part of the end-to-end application session.
Step 3.
The NRM server sends to the NRM client 1 an end-to-end QoS management response with a positive or negative acknowledgement of the request.
Step 4.
The NRM server may also send a notification to NRM client 2 (of VAL UE 2) to inform about the end-to-end QoS management initiation by the NRM server.
Up
14.3.5.2.2  Procedure for a group of UEs |R18|  p. 286
Figure 14.3.5.2.2-1 illustrates the procedure where the NRM server is initiating the end-to-end QoS/resource management capability for network-assisted UE-to-UE communications for a group of UEs.
Pre-conditions:
  1. The NRM client is connected to the NRM server.
  2. The VAL UEs involved in the end-to-end session (VAL UE 1 and a group of VAL UEs) are connected to one or more PLMNs and have ongoing PDU sessions.
Reproduction of 3GPP TS 23.434, Fig. 14.3.5.2.2-1: end-to-end QoS management request / response for a group of UEs
Figure 14.3.5.2.2-1: end-to-end QoS management request / response for a group of UEs
Up
Step 1.
The NRM server receives from the AF on NRM client 1 (of VAL UE 1) the end-to-end QoS management request for managing the QoS on UE-to-UE traffic for a group of UEs.
Step 2.
The NRM server retrieves from 5GC or subscribe to 5GC to obtain additional VAL-UE associated information for each member in the group identified by the VAL group ID, which is account for decomposition. The VAL-UE associated information could be from the 5GC (NEF Monitoring Events as in TS 23.502, QoS sustainability analytics as in TS 23.288) or SEAL LMS (on demand location reporting).
Step 3.
The NRM server configures the application QoS parameters by decomposing the end-to-end QoS requirements (UE-to-UE traffic for any two UEs in a group) to application QoS parameters for each individual session (uplink network session for ingress group member and downlink network session for egress group member). The NRM server needs to take the additional VAL-UE associated information into account for evaluation during such decomposition.
Step 4.
The NRM/SEAL server, acting as AF, sends to the 5GC a "Procedures for AF requested QoS for a UE or group of UEs not identified by a UE address" to set the application QoS parameters respectively for uplink network session for each ingress group member in the group and for downlink network session for egress group member.
Additionally, the NRM/SEAL server may activate monitoring of the performance to receive QoS monitoring event notifications from 5GC by setting the (optionally with Alternative QoS Profiles) in the request, in this case the AF may receive the QoS downgrade notification for e.g. latency thus to initiate the NRM-assisted coordinated QoS provisioning for 5G LAN-Type communication in clause 14.3.5.3.x
Step 5.
The NRM server sends to the NRM client 1an end-to-end QoS management response with a positive or negative acknowledgement of the request.
Step 6.
If the NRF server receives the end-to-end QoS management request including VAL UE2 as any of the List of VAL UEs, then the NRM server may also send a notification to NRM client 2 (of VAL UE 2) to inform about the end-to-end QoS management initiation by the NRM server.
Up

14.3.5.3  Procedure for coordinated QoS provisioning operation in network assisted UE-to-UE communications  p. 287

This procedure provides a mechanism for ensuring the end-to-end application QoS requirement fulfilment for the application service (which is between two or more VAL UEs), considering that the QoS of one of the links may downgrade. It is assumed that the application session is ongoing, and both the source and target VAL UEs are connected to 3GPP network (the same or different). The communication between the VAL UEs is assumed to be in-direct / network-assisted; hence two PDU sessions are established respectively (one per VAL UE).
The clause 14.3.5.2.1 describes the end-to-end QoS/resource management capability for network-assisted UE-to-UE communications for a single pair of UEs.
The clause 14.3.5.2.2 describes the end-to-end QoS/resource management capability for network-assisted UE-to-UE communications for a group of UEs.
Up
14.3.5.3.1  Procedure for a single pair of UEs  p. 287
Figure 14.3.5.3.1-1 illustrates the procedure where the NRM server supports the coordinated QoS provisioning for network-assisted UE-to-UE communications for a single pair of UEs.
Pre-conditions:
  1. NRM server has activated the end-to-end QoS/resource management capability, as described in clause 14.3.5.2.1.
  2. NRM server, acting as AF, has registered to receive QoS monitoring event notifications from 5GC and notifications from VAL UEs (from both UEs), as specified in TS 23.501.
Reproduction of 3GPP TS 23.434, Fig. 14.3.5.3.1-1: NRM-assisted coordinated QoS provisioning for C2 communication
Figure 14.3.5.3.1-1: NRM-assisted coordinated QoS provisioning for C2 communication
Up
Step 1a.
A QoS downgrade trigger event is sent from the NRM client of the VAL UE 1 to the NRM server, denoting an application QoS degradation (experienced or expected) e.g. based on the experienced packet delay or packet loss for the Uu link (e.g. packet loss great than threshold value). The conditions for triggering the QoS downgrade indication from the NRM client is based on the threshold that may be provided in advance by the NRM server (at the end-to-end QoS management response by the NRM server in 14.3.5.2.1).
Step 1b.
Alternatively, the NRM server receives a trigger event from the 5GC (SMF/NEF), denoting a QoS downgrade notification for the VAL UE 1 session. (described in clause 5.7.2.4.1b of TS 23.501).
Step 2.
The NRM server evaluates the fulfilment/non-fulfilment of the end-to-end QoS based on the trigger event. NRM server may retrieve additional information based on subscription to support its evaluation. This could be from the 5GC (NEF Monitoring Events as in TS 23.502, QoS sustainability analytics as in TS 23.288) or SEAL LMS (on demand location reporting for one or both VAL UEs 1 and 2).
Then, the NRM server, determines an action, which is the QoS parameter adaptation of one or both links (QoS profile downgrade for the link receive QoS notification control, and QoS upgrade for the link which can be upgraded).
Step 3.
The NRM/SEAL server, acting as AF, sends to the 5GC (to SMF via NEF or to PCF via N5) a request for a change of the QoS profile mapped to the one or both network sessions (for VAL UE 1 and UE 2) or the update of the PCC rules to apply the new traffic policy (as specified in clause 4.15.6.6a of TS 23.502: AF session with required QoS update procedure).
Step 4.
The NRM server sends an application QoS change notification to the affected NRM clients, to inform on the adaptation of the QoS requirements for the individual session.
Up
14.3.5.3.2  Procedure for a group of UEs |R18|  p. 288
Figure 14.3.5.3.2-1 illustrates the procedure where the NRM server supports the coordinated QoS provisioning for network-assisted UE-to-UE communications.
Pre-conditions:
  1. NRM server has activated the end-to-end QoS/resource management capability, as described in clause 14.3.5.2.1.
  2. NRM server, acting as AF, has registered to receive QoS monitoring event notifications from 5GC and notifications from VAL UEs (from any UEs in a group), as specified in TS 23.501.
Reproduction of 3GPP TS 23.434, Fig. 14.3.5.3.2-1: NRM-assisted coordinated QoS provisioning for 5G LAN-Type communication
Figure 14.3.5.3.2-1: NRM-assisted coordinated QoS provisioning for 5G LAN-Type communication
Up
Step 1.
The NRM server receives a trigger event from the 5GC (SMF/NEF), denoting a QoS downgrade notification for the network session of any group member in a group. (described in clause 5.7.2.4.1b of TS 23.501).
Step 2.
The NRM server evaluates the fulfilment/non-fulfilment of the end-to-end QoS based on the trigger event. NRM server may retrieve additional information based on subscription to support its evaluation. This could be from the 5GC (NEF Monitoring Events as in TS 23.502, QoS sustainability analytics as in TS 23.288) or SEAL LMS (on demand location reporting for one or both VAL UEs 1 and 2).
Then, the NRM server, determines an action, which is the QoS parameter adaptation of only uplink/downlink network session or both uplink and downlink network sessions for each ingress group member in the group.
Step 3.
The NRM/SEAL server, acting as AF, sends to the 5GC (to SMF via NEF or to PCF via N5) a request for a change of the QoS profile mapped to the impacted network sessions or the update of the PCC rules to apply the new traffic policy (as specified in clause 4.15.6.14 of TS 23.502: AF requested QoS for a UE or group of UEs not identified by a UE address procedure).
Step 4.
The NRM server sends an application QoS change notification to the affected NRM clients, to inform on the adaptation of the QoS requirements for the individual session.
Up

14.3.5.4  Application QoS coordination for Mobile Metaverse Services in distributed VAL servers |R19|  p. 289

14.3.5.4.1  General  p. 289
This clause provides a mechanism for application session QoS coordination for mobile metaverse (MM) services where these services are offered by more than one VAL server.
It is assumed that the MM service consists of the following VAL sessions which can be present for multi-user interactions. The sessions may include VAL UE1 and VAL UE2 and digital counterparts of UE1 and UE2 instantiated in one or more DNs (called as virtual or avatar VAL UEs).
  • VAL session #1: VAL client 1 sends to VAL server 1 (including virtual VAL UE 1 at DN side) sensor data / measurements on the physical environment related to VAL UE1 over VAL-UU interface. VAL server (virtual VAL UE1) sends back haptic feedback to VAL UE1 (for UE1 and/or UE2 and the environment).
  • VAL session #2: VAL client 2 sends to VAL server 2 (including virtual VAL UE 2 at DN side) sensor data / measurements on the physical environment related to VAL UE2 over VAL-UU interface. VAL server (virtual VAL UE2) sends back haptic feedback to UE2 (for UE1 and/or UE2 and the environment).
  • VAL session #3: Exchange of service related / feedback data between VAL server 1 and 2 for interactions between virtual UE 1 and 2 (for example micro-transactions such as avatar updates/modifications or environment changes).
  • VAL session #4: Sensor data / measurements are exchanged between VAL UEs over VAL-PC5 (communication can be over side link) for traffic related to the MM service.
There is a coupling in the performance requirements for all the above VAL sessions which is corresponding to the end-to-end MM service. The end-to-end MM service may be related e.g., to 5G-enabled Traffic Flow Simulation and Situational Awareness, where the physical objects including UEs (e.g. V2X UEs) in cars and trucks in each lanes, will have a corresponding digital twin in the virtual world in distributed VAL servers, and the virtual and physical UEs form the mobile metaverse.
One possible coupling of such requirements is about the expected sequence of certain messages to be transferred via the 5GS. For example, the delay of the collection of sensor information from the physical environment may have impact on the expected delay of haptic feedback from the server to the VAL UE which will result in degrading the QoE for the MM service.
In the procedure as defined in clause 14.3.5.4.2, the NRM server takes the performance of VAL Session # 1, VAL Session # 2, VAL Session # 3, VAL Session # 4 into consideration to ensure the E2E performance (UE#1 - VAL server#1 - VAL server#2 - UE#2). For example, if the delay of VAL session # 1 is long, the delay of other sessions needs to be reduced.
Up
14.3.5.4.2  Procedure on application QoS coordination for Mobile Metaverse Services  p. 290
Figure 14.3.5.4.2-1 illustrates the procedure where the NRM server is supporting application QoS coordination for the VAL sessions within a MM Service.
Pre-conditions:
  1. The NRM clients are connected to the NRM server.
  2. The VAL servers are connected to the NRM server.
  3. The VAL sessions which are coupled to support the Mobile Metaverse (MM) Service (e.g., VAL client 1 to VAL server 1, VAL client 2 to VAL server 2) are established.
  4. The NRM client 1 has acquired information on the dependencies among different sessions (e.g. sequence of data to be exchanged among VAL servers and clients) from the VAL client.
Reproduction of 3GPP TS 23.434, Fig. 14.3.5.4.2-1: Application QoS coordination for VAL MM services
Figure 14.3.5.4.2-1: Application QoS coordination for VAL MM services
Up
Step 1.
The NRM client 1 (acting on behalf of VAL client 1) sends to the NRM server an MM-specific QoS management request to trigger the application QoS coordination between the physical and virtual VAL UEs within MM service. This request may also include the end-to-end QoS/service provisioning requirement for the MM service, and the expected dependencies among different sessions (e.g. sequence of data to be exchanged among VAL servers and clients).
Step 2.
The NRM server decomposes the MM service performance requirement (end to end application QoS target) to per VAL session requirement taking into account the dependencies among sessions, where in this step the NRM server identifies the VAL sessions for which the application QoS parameters need to be configured or updated.
Step 3.
The NRM server configures the application QoS parameters per VAL session, for the identified VAL sessions to ensure meeting the end-to-end QoS requirements for the MM service.
Step 4.
he NRM server sends the MM-specific QoS management response to the NRM client 1 to provide the configuration information for the QoS attributes for the VAL sessions related to VAL UE 1.
Step 5.
The NRM server sends a QoS configuration notification to the VAL servers 1 and 2 as well as to the NRM client 2 to provide the configuration information for the QoS attributes for the corresponding VAL sessions. The QoS configuration notification may include per session QoS requirements for each metaverse session received/sent at/by the UE, where each metaverse session may be composed of multi-modal type of communication conveying audio, video or haptic/sensor information from/between the UE.
Up

14.3.6  Event Monitoring |R17|  p. 291

14.3.6.1  General  p. 291

The VAL server utilizes the NRM server for monitoring the events related to its VAL UEs and receive the event reports. The NRM server shall subscribe to multiple core network services to fetch all the required events related to the multiple VAL UEs served by the VAL server and report the same to the VAL server with the event details.
To monitor and report the events related to the VAL UE from the 3GPP core network, the NRM server shall use the Monitoring Events procedures as specified in TS 23.502.
To monitor and report the analytics events related to the VAL UE, the NRM server shall use the procedures specified in TS 23.288.
Up

14.3.6.2  Monitoring Events Subscription Procedure  p. 291

14.3.6.2.1  General  p. 291
The VAL server subscribes to the NRM server to monitor the events related to VAL UE(s). Based on the VAL server request, the NRM server consumes the relevant core network services to receive the events related to the VAL UE(s). The related procedure is illustrated in the next clause.
14.3.6.2.2  Procedure  p. 291
The procedure for VAL server subscribing to the NRM server, to monitor the VAL UE(s) related events is described in Figure 14.3.6.2.2-1.
Pre-conditions:
  • The NRM server is authorized to consume the core network services (Monitoring events as specified in TS 23.502 and Analytics services as specified in TS 23.288);
Reproduction of 3GPP TS 23.434, Fig. 14.3.6.2.2-1: Monitoring Events Subscription Procedure
Figure 14.3.6.2.2-1: Monitoring Events Subscription Procedure
Up
Step 1.
The VAL server sends Monitoring Events Subscription request to the NRM server, requesting the NRM server to monitor the events related to the VAL UE(s) as per the subscription request, and shall include the information related to the events that the VAL server is interested in.
Step 2.
The NRM server shall check if the VAL server is authorized to initiate the Monitoring Events Subscription request and if authorized, shall respond with Monitoring Events Subscription Response message, indicating the successful subscription status along with subscription information to the VAL server. The VAL service ID may be used by the NRM server to derive event specific information in 3GPP core network services (e.g. QoS requirement in analytics event subscription), based on e.g. local configuration. The NRM server maps the VAL group ID (if received) to the External Group ID known to the 3GPP core network.
Step 3.
Based on the events of interest information in the subscription request message, if applicable, the NRM server shall subscribe to the UE monitoring events (LOSS_OF_CONNECTIVITY, COMMUNICATION_FAILURE, etc.) for the set of UEs (VAL UEs) in the subscription request, as specified in TS 23.502.
Step 4.
Based on the events of interest information in the subscription request message, if applicable, the NRM server shall subscribe to the UE analytics events (like ABNORMAL_BEHAVIOUR etc.) for the set of UEs (VAL UEs) in the subscription request, as specified in TS 23.288.
Up

14.3.6.3  Monitoring Events Notification Procedure  p. 292

14.3.6.3.1  General  p. 292
The NRM server receives the events related to VAL UE(s) from the 3GPP core network. The NRM server reports the monitoring events information to the VAL server.
14.3.6.3.2  Procedure  p. 292
The procedure for NRM server notifying the VAL server with VAL UE(s) related events is described in Figure 14.3.6.3.2-1.
Pre-conditions:
  • The VAL server has subscribed with NRM server using Monitoring Events Subscription Procedure as specified in clause 14.3.6.2;
Reproduction of 3GPP TS 23.434, Fig. 14.3.6.3.2-1: Monitoring Events Notification Procedure
Figure 14.3.6.3.2-1: Monitoring Events Notification Procedure
Up
Step 1.
If applicable, the NRM server receives the VAL UE related monitoring event notifications from the 3GPP core network as specified in TS 23.502.
Step 2.
If applicable, the NRM server receives the VAL UE related Analytics event notifications from the 3GPP core network as specified in TS 23.288.
Step 3.
The NRM server notifies the VAL server about the events related to the VAL UE in Notify Monitorng Events message. If multiple events are to be notified, then the NRM server may aggregate the notifications and send to the VAL server.
Up

14.3.7  5G TSC resource management procedures |R17|  p. 293

14.3.7.1  General  p. 293

The procedures related to the 5G TSC network resource management are described in the following subclauses.

14.3.7.2  TSC stream availability discovery procedure  p. 293

The TSC stream availability discovery procedure is used by the VAL server to discover the availability of resources for TSC communication for the given stream specification (i.e., between the target UEs) prior to creating the stream.
Pre-conditions:
  1. Each UE has an established Ethernet PDU session and DS-TTs are connected to the 5GS TSC bridge. The traffic classes are configured on each DS-TT.
  2. The NRM server has collected the 5GS TSC bridge management and port management information. The latter is related to the Ethernet ports located in the DS-TTs including bridge delay per DS-TT Ethernet port pair per traffic class.
  3. NRM server has calculated the bridge delay for each port pair, i.e. composed of (ingress DS-TT Ethernet port, egress DS-TT Ethernet port) including the UE-DS-TT residence time, packet delay budget (PDB) and propagation delay for both UL from sender UE and DL to receiver UE.
Reproduction of 3GPP TS 23.434, Fig. 14.3.7.2-1: TSC stream availability discovery procedure
Figure 14.3.7.2-1: TSC stream availability discovery procedure
Up
Step 1.
The NRM server receives a request from a VAL server on NRM-S reference point to discover the connectivity and available QoS characteristics between DS-TTs identified by the stream specification.
Step 2.
The NRM server validates the connectivity between the DS-TTs connected in the same 5GS TSC bridge based on the collected 5GS TSC bridge management and port management information, identifies the traffic classes supported by the DS-TTs and determines the end-to-end latency (including the UE-DS-TT residence times, PDBs and propagation delay).
Step 3.
NRM server responds to the VAL server with the stream specification and a list of traffic specifications with the available end-to-end latency and the traffic classes supported by the DS-TTs.
Up

14.3.7.3  TSC stream creation procedure  p. 294

This procedure allows the VAL server to create a TSC stream. The TSC stream creation procedure enables the VAL server to establish TSC connectivity with the required QoS between the UEs connected to the 5GS after the stream discovery procedure.
Pre-conditions:
  1. Each UE has an established Ethernet PDU session for its DS-TT port MAC address.
  2. Connectivity between the DS-TTs has been validated by the TSC stream availability discovery procedure specified in clause 14.3.7.2.
  3. The NRM server maintains mapping from the traffic class to TSC QoS.
Reproduction of 3GPP TS 23.434, Fig. 14.3.7.3-1: TSC stream creation procedure
Figure 14.3.7.3-1: TSC stream creation procedure
Up
Step 1.
The NRM server receives a TSC stream creation request from a VAL server to create a TSC stream identified by a VAL Stream ID, between DS-TT ports in the stream specification and for the traffic class in the traffic specification.
Step 2.
The NRM server calculates the schedule for the VAL Stream ID based on the information collected earlier from the 5GS via N5. It provides per-stream filtering and policing parameters (e.g. as defined in IEEE 802.1Q [36]) used to derive the TSC QoS information and related flow information. NRM server also provides the forwarding rule (e.g. as defined in IEEE 802.1Q [36]) used to identify the DS-TT MAC address of the corresponding PDU session. Based on the 5GS bridge delay information it determines the TSC QoS information and TSC Assistance information for the stream.
Step 3.
Based on the Traffic specification (from the TSC stream creation request in step 1), the SEAL NRM server determines whether time synchronization needs to be activated for the TSC stream on the DS-TTs. If the DS-TTs are time synchronized, then the NRM does not activate the time synchronization for the corresponding DS-TT.
Step 4.
As a TSCTSF, the NRM server triggers via N84 the Npcf_PolicyAuthorization_Create service operation as described in TS 23.502 for the TSC stream for both UL QoS flow (sender UE to UPF/bridge) and DL QoS flow (UPF/bridge to receiver UE). The Policy Authorization request includes the DS-TT port MAC address, TSC QoS information, TSC Assistance Information (clause 5.27.2.3 of TS 23.501), flow bit rate, priority, Service Data Flow Filter containing flow description including Ethernet Packet Filters. The QoS flow will be assigned for the PDU session for the source MAC address for the UL direction and for the PDU session for the destination MAC address for the DL direction. This information is delivered to the DS-TT by the 5GS.
If time synchronization is determined to be needed for the TSC stream on the DS-TTs in step 3, the NRM server uses the procedures in clause K.2.2 of TS 23.501 to activate the time synchronization via the Npcf_PolicyAuthorization_Update service operation. The procedure includes the configuration and initialization of the PTP instance in the DS-TTs, the construction of PMICs to each DS-TT/UE to activate the time synchronization service in the DS-TT and to subscribe for the port management information changes in the DS-TTs.
Step 5.
The NRM server sends TSC stream creation response to the VAL server with the result of TSC stream creation for the VAL Stream ID.
Up

14.3.7.4  TSC stream deletion procedure  p. 295

This procedure allows the VAL server to delete a TSC stream.
Pre-conditions:
  1. The TSC stream is configured in the 5GS and the DS-TTs.
Reproduction of 3GPP TS 23.434, Fig. 14.3.7.4-1: TSC stream deletion procedure
Figure 14.3.7.4-1: TSC stream deletion procedure
Up
Step 1.
The NRM server receives a request from VAL server to delete a TSC stream for with a VAL Stream ID.
Step 2.
The NRM server identifies the MAC addresses of the DS-TTs involved in the stream based on the stored information for the VAL Stream ID. If none of the streams require to keep the time synchronization activated, the NRM server deactivates the time synchronization for the corresponding DS-TTs, otherwise keeps the time synchronization activated if the time synchronization for the DS-TTs was activated by the NRM server.
Step 3.
As a TSCTSF, the NRM server triggers via N84 the Npcf_PolicyAuthorization_Delete service operation defined in TS 23.502 for MAC addresses referred to by the VAL Stream ID. The NRM server uses the procedure to delete both UL QoS flow (sender UE to UPF/bridge) and DL QoS flows (UPF/bridge to receiver UE) from the PDU sessions of the UEs referred to by the VAL Stream ID. Before invoking the Npcf_PolicyAuthorization_Delete procedure, if the time synchronization service for the DS-TTs needs deactivation, the NRM server deactivates the time synchronization for the DS-TTs as described in clause K.2.2 of TS 23.501 via the Npcf_PolicyAuthorization_Update service operation.
Step 4.
The NRM server sends TSC stream deletion response to the VAL server with the result of TSC stream deletion for the VAL Stream ID.
Up

14.3.8  TSN resource management procedures |R17|  p. 296

14.3.8.1  General  p. 296

The procedures related to the TSN network resource management are described in the following subclauses.

14.3.8.2  5GS TSN Bridge information reporting  p. 296

Pre-conditions:
  1. There is already an established session between the TSN CNC and the NRM server acting as TSN-AF.
Reproduction of 3GPP TS 23.434, Fig. 14.3.8.2-1: TSN Bridge information reporting procedure
Figure 14.3.8.2-1: TSN Bridge information reporting procedure
Up
Step 1.
Acting as the TSN AF the NRM server collects 5GS TSN Bridge information by interaction with the 5GS via the N5 reference point, as described in in TS 23.502 Annex F.1. The NRM server stores the binding relationship between 5GS Bridge ID, MAC address of the DS-TT Ethernet port and also updates 5GS bridge delay as defined in clause 5.27.5 of TS 23.501. The NRM server retrieves txPropagationDelay and Traffic Class table from DS-TT and it also retrieves txPropagationDelay and Traffic Class table from NW-TT.
Step 2.
Whenever there is a new or updated bridge information the NRM server interacts with the TSN CNC and reports the TSN Bridge information to register a new TSN Bridge or update an existing TSN Bridge. The TSN CNC stores the TSN Bridge information and confirms to the NRM server.
Up

14.3.8.3  5GS TSN Bridge configuration procedure  p. 297

Pre-conditions:
  1. The TSN CNC has stored the 5GS TSN Bridge information received from the NRM server acting as TSN AF.
  2. The NRM server acting as TSN AF has stored the 5GS TSN Bridge information collected from the 5GS, as described in clause 14.3.8.2.
Reproduction of 3GPP TS 23.434, Fig. 14.3.8.3-1: TSN Bridge configuration procedure
Figure 14.3.8.3-1: TSN Bridge configuration procedure
Up
Step 1.
The NRM server receives from the TSN CNC per-stream filtering, policing parameters and related flow information according to IEEE 802.1Q [36] and it uses them to derive TSN QoS information and related flow information. The TSN AF uses this information to identify the DS-TT MAC address of the corresponding PDU session.
Step 2.
NRM server triggers via N5 the AF request procedure as described in TS 23.502 Annex F.2. The AF request includes the DS-TT port MAC address, TSC QoS information, TSC Assistance Information, flow bit rate, priority, Service Data Flow Filter containing flow description including Ethernet Packet Filters.
Step 3.
NRM server responds with a TSN Bridge configuration.
Up

Up   Top   ToC