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 22.214.171.124.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.
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.
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.
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 126.96.36.199.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.
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.
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.
Figure 188.8.131.52.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.
It is assumed that there is at least one active MBMS bearer
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.
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.
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.
Figure 184.108.40.206.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.
It is assumed that a bearer (unicast or MBMS) has been activated by the VAL server for downlink delivery.
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 220.127.116.11. The NRM server notifies a user plane delivery mode to the VAL server.
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.
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.
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.
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.
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).
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 18.104.22.168.1).
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).
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 22.214.171.124a: AF session with required QoS update procedure).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
Each UE has an established Ethernet PDU session for its DS-TT port MAC address.
Connectivity between the DS-TTs has been validated by the TSC stream availability discovery procedure.
NRM server maintains mapping from the traffic class to TSC QoS.
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.
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.
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 126.96.36.199), 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.
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.
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.502Annex 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.
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.
The NRM server receives from the TSN CNC per-stream filtering, policing parameters and related flow information according to IEEE 802.1Q  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.
NRM server triggers via N5 the AF request procedure as described in TS 23.502Annex 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.