Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.434  Word version:  18.1.0

Top   Top   Up   Prev   Next
0…   4…   6…   6.4…   6.5…   7…   8…   8.2.2…   9…   9.3…   9.3.6…   9.4…   10…   10.3…   10.3.2.22…   10.3.3…   10.3.7…   10.4…   11…   11.3…   12…   13…   14…   14.3…   14.3.3…   14.3.3.3…   14.3.4…   14.3.4.6…   14.4…   15…   A…

 

14.3.4.6  Service continuity in MBMS scenariosp. 155

14.3.4.6.1  Generalp. 155
This subclause specifies service continuity scenarios when MBMS bearers are used. There are different solutions for different scenarios.
14.3.4.6.2  Service continuity when moving from one MBSFN to anotherp. 155
The service continuity solution described in this subclause is suitable in the scenario when multiple MBMS bearers are used with the purpose to cover a larger area. In VAL communications several VAL service communication streams may be multiplexed in one MBMS bearer. Furthermore, one VAL service communication stream may be sent on more than one MBMS bearer if the receiving users are distributed over more than one MBMS service area. A VAL UE that is interested in receiving a VAL service communication stream that is broadcasted in both MBMS bearers is a candidate for this service continuity procedure.
Figure 14.3.4.6.2-1 illustrates a deployment scenario that provides service continuity between two MBSFN areas. Two different MBMS bearers are activated (TMGI 1 and TMGI 2), the activation of the bearers is done in the two MBSFN areas (MBSFN 1 and MBSFN 2). The MBSFN areas 1 and 2 are partially overlapping, meaning that some transmitting cells belong to both MBSFN area 1 and MBSFN area 2.
Reproduction of 3GPP TS 23.434, Fig. 14.3.4.6.2-1: Two MBMS bearer using overlapping MBSFN areas
Up
Figure 14.3.4.6.2-2 illustrates the procedure:
Reproduction of 3GPP TS 23.434, Fig. 14.3.4.6.2-2: Service continuity when moving from one MBSFN to another
Up
Step 1.
The VAL UE is located in MBSFN 1 and can listen to TMGI 1. No additional MBMS bearers that the NRM client is interested in are active in the current cell.
Step 2a.
The NRM client notifies the NRM server that the VAL UE is successfully receiving the VAL service communication over TMGI 1. The NRM client may also notify the MBMS reception quality level of TMGI 1.
Step 2b.
The NRM server notifies a user plane delivery mode to the VAL server.
Step 3.
The VAL UE moves into a new cell in which both TMGI 1 and TMGI 2 are active. This cell is part of both MBSFN area 1 and MBSFN area 2, and broadcast the same service on both TMGIs.
Step 4.
The NRM client sends a location information report to the NRM server. For that, the UE uses the SAI information found in the system information block (SIB) transmitted by the radio cells.
Step 5.
The NRM server sends to the NRM client a MBMS bearer announcement with information related to TMGI 2 (if the NRM server had not done it before). Hence, the NRM client knows that TMGI 2 transmits the same VAL service communication.
Step 6a.
The NRM client notifies the NRM server that it is successfully receiving TMGI 1 and TMGI 2. The NRM client may also notify the MBMS reception quality level per TMGI.
Step 6b.
The NRM server notifies a user plane delivery mode to the VAL server.
Step 7.
The VAL UE may receive the VAL service communication over both MBMS bearers, i.e. TMGI 1 and TMGI 2. The VAL UE may also verify that it is the same content sent on both bearers. The duplicated packets may also be used to perform error corrections.
Step 8.
The VAL UE moves into a new cell in MBSFN area 2, where only TMGI 2 is active.
Step 9a.
The NRM client notifies the NRM server that the VAL UE is successfully receiving the VAL service communication over TMGI 2. The NRM client may also notify the MBMS reception quality level of TMGI 2.
Step 9b.
The NRM server notifies a user plane delivery mode to the VAL server.
Step 10.
The VAL UE receives the VAL service communication only over TMGI 2.
This service continuity procedure mitigates the risk of packet loss that may occur if the VAL UE would request to transfer the VAL service communication stream to a unicast bearer when moving into the new area and then back to a multicast bearer when the UE can listen to TMGI 2. However, it is still required that the NRM client sends a location report (and MBMS listening report), as described in steps 4-6 above. To send the location report and the MBMS listening report by the NRM client to the NRM server a unicast bearer is needed. The location report from the NRM client is required, since the NRM server must know that the VAL UE has entered a new area and can only listen to MBMS bearer active in that area. If this is not done the VAL server might send a VAL service communication stream that the VAL UE is required to listen to on the MBMS bearer 1, since the NRM server still assumes that the VAL:UE is located in the MBSFN area 1.
The solution can be improved as illustrated in Figure 14.3.4.6.2-3. In this case two different MBMS bearers are activated (TMGI 1 and TMGI 2), these MBMS bearers are used only for VAL service communication. An application level signalling bearer is activated (TMGI 9), in both MBSFN areas. This bearer is used for application level signalling messages that are sent on the MBMS bearer TMGI 9. By using an application level signalling bearer (e.g. TMGI 9) the VAL UEs can receive application control messages for all VAL service communication going on in the areas of both TMGI 1 and TMGI 2. A VAL UE that is located in the area of TMGI 2 and is interested in a VAL service group transmission (e.g. V2X) only going on in TMGI 1, can with the information received in TMGI 9 initiate a unicast bearer and request to receive that specific VAL service communication over a unicast instead. Without the information received over TMGI 9 the NRM client must immediately report that the VAL UE has left the broadcast area that the NRM server assumes that the VAL UE is located in. With the use of TMGI 9 there is no immediate need for the NRM client to inform the NRM server of a location change.
Reproduction of 3GPP TS 23.434, Fig. 14.3.4.6.2-3: Two MBMS bearer using overlapping MBSFN areas with a separate application signalling bearer
Up
The procedural steps in this scenario will be the same as described above in this subclause. However, in this scenario the NRM client is not required to initiate a unicast bearer to send location report (or MBMS listening report). The VAL UE may move between the two MBMS bearers (TMGI 1 and TMGI 2) without the need to report an area change. A condition for this to work is that there is an application level signalling bearer (TMGI 9) activated in the full area (i.e. the area of both TMGI 1 and TMGI 2). The TMGI 9 will broadcast all application control messages for all VAL service communications ongoing in both areas. If the VAL UE is in coverage of one of the two MBMS bearers that does not transmit the VAL service communication of interest the VAL UE can report to the NRM server that it is not able to listen to the VAL service communication over the MBMS bearer, which triggers the NRM server to switch to a unicast bearer instead.
Up

14.3.4.7  MBMS suspension notificationp. 158

14.3.4.7.1  Generalp. 158
In this procedure the NRM client is requested by the NRM server to send a MBMS suspension report. This request for MBMS suspension report can be included in the MBMS bearer announcement and the NRM server may choose to only send this request for MBMS suspension report to a subset of all NRM clients.
14.3.4.7.2  Procedurep. 158
Figure 14.3.4.7.2-1 illustrates a procedure in which the NRM client notifies the NRM server about an MBMS suspension decision in RAN.
The NRM server can decide on a subset of all VAL UEs in the MBMS broadcast area that shall report on MBMS bearer suspension. When the NRM server makes the decision of the VAL UE subset, consideration shall be taken to the location of the VAL UEs, since VAL UEs' location is dynamically changed. This means that the MBMS suspension reporting instruction may need to be updated regularly based on the VAL UEs mobility.
Pre-condition:
  • It is assumed that there is at least one active MBMS bearer
Reproduction of 3GPP TS 23.434, Fig. 14.3.4.7.2-1:	MBMS suspension notification
Up
Step 1.
The NRM server sends an MBMS suspension reporting instruction to the NRM client.
Step 2.
RAN decides to suspend the MBMS bearer, according to existing procedures in TS 36.300.
Step 3.
An MBMS suspension indication is sent in the MSI (MCH Scheduling Information), according to existing procedures in TS 36.300.
Step 4.
The NRM client detect the MBMS suspension and sends an MBMS suspension report.
Step 5.
Based on the MBMS suspsension report received, the NRM server determines whether to switch to a new bearer (unicast or MBMS). If NRM server determines to switch to unicast bearer, then the NRM server sends the user plane delivery mode message to VAL server , and the VAL server sends the downlink data over the new bearer.
The NRM client that is not instructed to send an MBMS suspension report shall still detect the MBMS suspension indication from RAN (step 3). A NRM client shall in this case not send other types of report (e.g. MBMS listening reports).
The same procedure can be applied at MBMS resumption or other MBMS events that may be detected by the NRM client.
Up

14.3.4.8  MBMS bearer event notificationp. 159

14.3.4.8.1  Generalp. 159
The NRM server is an instantiation of a GCS AS. For the NRM server to know the status of the MBMS bearer, and thus know the network's ability to deliver the VAL service, it is required that the network provides MBMS bearer event notifications to the NRM server. The different events notified to the NRM server include the MBMS bearer start result (e.g. when the first cell successfully allocated MBMS resources), including information if any cells fail to allocate MBMS resources to a specific MBMS bearer, the current status of the MBMS bearer, MBMS bearer suspension/resume or overload scenarios.
Up
14.3.4.8.2  Procedurep. 159
The procedure in Figure 14.3.4.8.2-1 shows notification information flows from NRM server to BM-SC.
Reproduction of 3GPP TS 23.434, Fig. 14.3.4.8.2-1: MBMS bearer event notification
Up
Step 1.
The NRM server activates an MBMS bearer. The activation of the MBMS bearer is done on the MB2-C reference point and according to TS 23.468.
Step 2.
The BMSC will respond to the activation with an Activate MBMS bearer response message, according to TS 23.468.
Step 3.
The EPC and RAN will initiate the MBMS session start procedure according to TS 23.246. This procedure is outside the scope of this specification.
Step 4a.
At the first indication of a successful MBMS session start procedure, the BM-SC sends a MBMS bearer event notification, indicating that the MBMS bearer is ready to use.
Step 4b.
The NRM server notifies user plane delivery mode to the VAL server.
Step 5.
The VAL server starts to use the MBMS bearer according to the MBMS procedures in this specification.
Step 6.
An event from RAN related to the MBMS session is received by the BM-SC.
Step 7a.
The BM-SC notifies the NRM server of certain MBMS related events including references to affected MBMS services areas or list of cells. Example of such events may be radio resources not available, overload, MBMS suspension.
Step 7b.
The NRM server notifies user plane delivery mode to the VAL server.
Step 8.
The NRM server may decide, based on the received events, to switch to unicast transmission for relevant VAL UEs.
Up

14.3.4.9  Switching between MBMS bearer and unicast bearerp. 161

14.3.4.9.1  Generalp. 161
The NRM server monitors the bearers used for VAL service communications and decides to switch between MBMS and unicast bearers.
14.3.4.9.2  Procedurep. 161
Figure 14.3.4.9.2-1 shows the procedure for service continuity when a UE is about to move out of MBMS coverage or getting into good MBMS coverage by switching between MBMS bearer and unicast bearer.
Pre-condition:
  • It is assumed that a bearer (unicast or MBMS) has been activated by the VAL server for downlink delivery.
  • Reproduction of 3GPP TS 23.434, Fig. 14.3.4.9.2-1: Switching between MBMS delivery and unicast delivery
    Up
    Step 1.
    The VAL UE detects changing MBMS bearer condition (good or bad MBMS coverage) for the corresponding MBMS service. The method to detect is implementation specific.
    Step 2.
    The NRM client notifies the NRM server about the MBMS bearer condition for the corresponding MBMS service by sending the MBMS listening status report.
    Step 3.
    The NRM server makes the decision to switch between MBMS delivery and unicast delivery based on available information at the NRM server including the MBMS listening status report as described in clause 14.3.4.5. The NRM server notifies a user plane delivery mode to the VAL server.
    Step 4.
    The VAL server sends the downlink data over the new bearer (unicast or MBMS) to the VAL client as per step 3.
    Step 5.
    During the switching, the VAL client simultaneously receives downlink data through both bearers (unicast bearer and MBMS bearer). If there is no downlink data to the VAL client, this step can be skipped.
    Step 6.
    The VAL client ceases to receive the downlink data through previous bearer but continues receiving data through new bearer.
    Up

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

    14.3.5.1  Generalp. 162

    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.
    Up

    14.3.5.2  QoS/resource management capability initiation in network assisted UE-to-UE communicationsp. 162

    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.
    Up
    14.3.5.2.1  Procedurep. 162
    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.
    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
    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.3  Procedure for coordinated QoS provisioning operation in network assisted UE-to-UE communicationsp. 163

    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).
    Up
    14.3.5.3.1  Procedurep. 163
    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.
    Pre-conditions:
    1. NRM server has activated the end-to-end QoS/resource management capability, as described in 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
    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 TS 23.502, clause 4.15.6.6a: 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.6  Event Monitoring |R17|p. 164

    14.3.6.1  Generalp. 164

    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 Procedurep. 164

    14.3.6.2.1  Generalp. 164
    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  Procedurep. 164
    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
    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 (like, 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 Procedurep. 165

    14.3.6.3.1  Generalp. 165
    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  Procedurep. 165
    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
    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. 166

    14.3.7.1  Generalp. 166

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

    14.3.7.2  TSC stream availability discovery procedurep. 166

    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
    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 procedurep. 167

    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.
    3. 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
    Up
    Step 1.
    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.
    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 [IEEE8021Q]) 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 [IEEE8021Q]) 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.
    As a TSCTSF, the NRM server triggers via N5 the Npcf_policy_Authorization_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 (TS 23.501, clause 5.27.2.3), 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.
    Step 4.
    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 procedurep. 168

    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
    Up
    Step 1.
    NRM server receives a request from VAL server to delete a TSC stream for with a VAL Stream ID.
    Step 2.
    NRM server identifies the MAC addresses of the DS-TTs involved in the stream based on the stored information for the VAL Stream ID.
    Step 3.
    As a TSCTSF, the NRM server triggers via Nxx the Npcf_PolicyAuthorization_Delete service operation defined in TS 23.502 for MAC addresses referred to by the VAL Stream ID. 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.
    Step 4.
    NRM server sends TSC stream deletion response to the VAL server with the result of TSC stream deletion for the VAL Stream ID.
    14.3.8 TSN resource management procedures
    Up

    14.3.8  TSN resource management procedures |R17|p. 169

    14.3.8.1  Generalp. 169

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

    14.3.8.2  5GS TSN Bridge information reportingp. 169

    Pre-conditions:
    1. There is already an established session between the TSN CNC and the NRM-S acting as TSN-AF.
    Reproduction of 3GPP TS 23.434, Fig. 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 procedurep. 169

    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
    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