WO2022082724A1

WO2022082724A1 - Method and apparatus for multicast service support in time sensitive network

Info

Publication number: WO2022082724A1
Application number: PCT/CN2020/123229
Authority: WO
Inventors: Hua Chao; Pilar ANDRES MALDONADO; Rakash Sivasivaganesan; David Navratil; Devaki Chandramouli
Original assignee: Nokia Shanghai Bell Co., Ltd.; Nokia Solutions And Networks Oy; Nokia Technologies Oy
Priority date: 2020-10-23
Filing date: 2020-10-23
Publication date: 2022-04-28
Also published as: CN116420347A

Abstract

Disclosed are embodiments of methods and apparatuses for multicast service support in a time sensitive network (TSN). A method may comprise determining from a first group of listener user equipments (UEs) a second group of listener UEs that are ready to receive a TSN stream for a multicast group, and triggering establishment of a TSC multicast session and a TSC multicast QoS flow for the second group of listener UEs to receive the TSN stream.

Description

METHOD AND APPARATUS FOR MULTICAST SERVICE SUPPORT IN TIME SENSITIVE NETWORK

TECHNICAL FIELD

Various example embodiments described herein generally relate to methods and apparatuses for supporting multicast services in a Time Sensitive Network (TSN) .

BACKGROUND

Certain abbreviations that may be found in the description and/or in the figures are herewith defined as follows:

5GC 5G Core network

5GS 5G System

AF Application Function

AMF Access and Mobility Management Function

CP Control Plane

DS-TT Device-Side TSN Translator

FAR Forwarding Action Rules

gNB next Generation NodeB

IIoT Industrial Internet of Thing

MMRP Multiple MAC Registration Protocol

MSRP Multiple Stream Registration Protocol

NF Network Function

NW-TT Network TSN Translator

PCF Policy Control Function

PDR Packet Detection Rules

PDU Packet Data Unit

PSA PDU Session Anchor

QoS Quality of Service

SMF Session Management Function

TSC Time Sensitive Communications

TSN Time Sensitive Network/Networking

UE User Equipment

UP User Plane

UPF User Plane Function

Time sensitive network (TSN) has been used in many application scenarios including for example Industrial Internet of Thing (IIoT) to provide connectivity with low latency and high reliability. It is desirable to integrate the 5G system (5GS) as virtual nodes such as bridges in the TSN network to provide ultra-reliable low latency communications in a flexible manner.

SUMMARY

A brief summary of example embodiments is provided below to provide basic understanding of some aspects of various embodiments. It should be noted that this summary is not intended to identify key features of essential elements or define scopes of the embodiments, and its sole purpose is to introduce some concepts in a simplified form as a preamble for more detailed description provided below.

In a first aspect, an example embodiment of a method for multicast service support in a time sensitive network (TSN) is provided. The method may comprise determining, from a first group of listener user equipments (UEs) , a second group of listener UEs that are ready to receive a TSN stream for a multicast group, and triggering establishment of a TSC multicast session and a TSC multicast QoS flow for the second group of listener UEs to receive the TSN stream.

In a second aspect, an example embodiment of a method for multicast service support in a time sensitive network (TSN) is provided. The method may comprise forwarding a talker advertise declaration received from a talker to a first group of listener UEs. The talker advertise declaration may indicate that the talker provides a TSN stream for a multicast group identified by a group address. The method may further comprise forward listener declarations received from one or more of the first group of listener UEs to the talker. The listener declarations may indicate if the one or more of the first group of listener UEs are ready to receive the TSN stream. In addition, the method may further comprise apply rules for forwarding traffic data of the TSN stream received from the talker to a second group of listener UEs that are ready to receive the TSN stream.

In a third aspect, an example embodiment of a method for multicast service support in a time sensitive network (TSN) is provided. The method may comprise receiving at a base station (BS) a multicast registration request from a core network (CN) network function (NF) . The multicast registration request may comprise one or more of time sensitive communication (TSC) session context ID, QoS flow information, a second group of UEs and relevant port numbers. The method may further comprise establishing one or more radio bearers for a time sensitive communication (TSC) multicast QoS flow for one or more listener UEs in the second group based on the received multicast registration request, and reporting establishment status of one or more radio bearers for the TSC multicast QoS flow for one or more listener UEs to the CN NF.

In a fourth aspect, an example embodiment of a method for multicast service support in a time sensitive network (TSN) is provided. The method may comprise forwarding, at a listener user equipment (UE) , multicast transmissions of a TSN stream received from a Talker to a Listener on a radio bearer established for a time sensitive communication (TSC) multicast QoS flow for the Listener. The TSN stream is provided from the talker to a multicast group identified by a destination address of a TSN stream which the listener UE has joined.

In a fifth aspect, an example embodiment of a network function in a control plane is provided. The network function may comprise at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the network function to perform actions. The actions may comprise determining, from a first group of listener user equipments (UEs) , a second group of listener UEs that are ready to receive a time sensitive network (TSN) stream for a multicast group, and triggering establishment of a time sensitive communication (TSC) multicast session and a TSC multicast Quality of Service (QoS) flow for the second group of listener UEs to receive the TSN stream.

In a sixth aspect, an example embodiment of a network function in a user plane is provided. The network function may comprise at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the network function to perform actions. The actions may comprise forwarding a talker advertise declaration received from a talker to a first group of listener UEs. The talker advertise declaration may indicate that the talker provides a time sensitive network (TSN) stream for a multicast group identified by a group address. The actions may further comprise forwarding listener declarations received from one or more of the first group of listener UEs to the talker. The listener declarations may indicate if the one or more of the first group of listener UEs are ready to receive the TSN stream. The actions may further comprise applying rules for forwarding traffic data of the TSN stream received from the talker to a second group of listener UEs that are ready to receive the TSN stream.

In a seventh aspect, an example embodiment of a network device is provided. The network device may comprise at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the network device to perform actions. The actions may comprise receiving a multicast registration request comprising one or more of time sensitive communication (TSC) session context ID, QoS flow information, a second group of UEs and relevant port numbers from a core network (CN) network function (NF) , establishing one or more radio bearers for a time sensitive communication (TSC) multicast QoS flow for one or more listener UEs in the second group based on the received multicast registration request, and reporting establishment status of one or more radio bearers for the TSC multicast QoS flow for one or more listener UEs to the CN NF.

In an eighth aspect, an example embodiment of a terminal device is provided. The terminal device may comprise at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the terminal device to perform actions. The actions may comprise forwarding multicast transmissions of a time sensitive network (TSN) stream received from a Talker to a Listener on a radio bearer established for a time sensitive communication (TSC) multicast QoS flow for the Listener. The TSN stream may be provided from the talker to a multicast group identified by a destination address of a TSN stream which the listener UE has joined.

In a ninth aspect, an example embodiment of an apparatus for multicast service support in a time sensitive network (TSN) is provided. The apparatus may comprise means for determining, from a first group of listener user equipments (UEs) , a second group of listener UEs that are ready to receive a TSN stream for a multicast group, and means for triggering establishment of a TSC multicast session and a TSC multicast QoS flow for the second group of listener UEs to receive the TSN stream.

In a tenth aspect, an example embodiment of an apparatus for multicast service support in a time sensitive network (TSN) is provided. The apparatus may comprise means for forwarding a talker advertise declaration received from a talker to a first group of listener UEs, the talker advertise declaration indicating that the talker provides a TSN stream for a multicast group identified by a group address, means for forwarding listener declarations received from one or more of the first group of listener UEs to the talker, the listener declarations indicating if the one or more of the first group of listener UEs are ready to receive the TSN stream, and means for applying rules for forwarding traffic data of the TSN stream received from the talker to a second group of listener UEs that are ready to receive the TSN stream.

In an eleventh aspect, an example embodiment of an apparatus for multicast service support in a time sensitive network (TSN) is provided. The apparatus may comprise means for receiving, at a base station (BS) , a multicast registration request comprising one or more of time sensitive communication (TSC) session context ID, QoS flow information, a second group of UEs and relevant port numbers from a core network (CN) network function (NF) , means for establishing, at the BS, one or more radio bearers for a time sensitive communication (TSC) multicast QoS flow for one or more listener UEs in the second group, based on the received multicast registration request, and means for reporting establishment status of one or more radio bearers for the TSC multicast QoS flow for one or more listener UEs to the CN NF.

In a twelfth aspect, an example embodiment of an apparatus for multicast service support in a time sensitive network (TSN) is provided. The apparatus may comprise means for forwarding, at a listener user equipment (UE) , multicast transmissions of a TSN stream received from a Talker to a Listener on a radio bearer established for a time sensitive communication (TSC) multicast QoS flow for the Listener. The TSN stream may be provided from the talker to a multicast group identified by a destination address of a TSN stream which the listener UE has joined.

In a thirteenth aspect, an example embodiment of a computer readable medium is provided. The computer readable medium may have instructions stored thereon. The instructions, when executed by at least one processor of a network function in a control plane, may cause the network function to perform a method of the above first aspect.

In a fourteenth aspect, an example embodiment of a computer readable medium is provided. The computer readable medium may have instructions stored thereon. The instructions, when executed by at least one processor of a network function in a user plane, may cause the network function to perform a method of the above second aspect.

In a fifteenth aspect, an example embodiment of a computer readable medium is provided. The computer readable medium may have instructions stored thereon. The instructions, when executed by at least one processor of a network device, may cause the network device to perform a method of the above third aspect.

In a sixteenth aspect, an example embodiment of a computer readable medium is provided. The computer readable medium may have instructions stored thereon. The instructions, when executed by at least one processor of a terminal device, may cause the terminal device to perform a method of the above fourth aspect.

It is to be understood that the summary section is not intended to identify key or essential features of example embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Some example embodiments will now be described, by way of non-limiting examples, with reference to the accompanying drawings.

Fig. 1 is an example block diagram illustrating a fully centralized configuration model for a TSN network.

Fig. 2 is an example block diagram illustrating a fully distributed configuration model for a TSN network.

Fig. 3 is an example block diagram illustrating 5GS TSN bridges integrated in a TSN network.

Fig. 4 is an example block diagram illustrating TSN Talker and TSN Listeners attached to the 5GS integrated with a TSN network.

Fig. 5 is an example interaction diagram illustrating operations for supporting multicast services in a TSN network integrated with the 5GS according to some embodiments.

Fig. 6 is an example interaction diagram illustrating operations for joining a multicast group according to some embodiments.

Fig. 7 is an example diagram illustrating control information maintained in the 5GS according to some embodiments.

Fig. 8 is an example interaction diagram illustrating operations for establishing a time sensitive communication (TSC) multicast session and a TSC multicast QoS flow according to some embodiments.

Fig. 9 is an example flow chart illustrating a method for multicast service support in a TSN network according to some embodiments.

Fig. 10 is an example flow chart illustrating a method for multicast service support in a TSN network according to some embodiments.

Fig. 11 is an example flow chart illustrating a method for multicast service support in a TSN network according to some embodiments.

Fig. 12 is an example flow chart illustrating a method for multicast service support in a TSN network according to some embodiments.

Fig. 13 is an example block diagram illustrating a communication system in which embodiments of the present disclosure can be implemented.

DETAILED DESCRIPTION

Herein below, some example embodiments are described in detail with reference to the accompanying drawings. The following description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known circuits, techniques and components are shown in block diagram form to avoid obscuring the described concepts and features.

As used herein, the term "network device" refers to any suitable entities or devices that can provide cells or coverage, through which the terminal device can access the network or receive services. The network device may be commonly referred to as a base station. The term "base station" used herein can represent a node B (NodeB or NB) , an evolved node B (eNodeB or eNB) , or a gNB. The base station may be embodied as a macro base station, a relay node, or a low power node such as a pico base station or a femto base station. The base station may consist of several distributed network units, such as a central unit (CU) , one or more distributed units (DUs) , one or more remote radio heads (RRHs) or remote radio units (RRUs) . The number and functions of these distributed units depend on the selected split RAN architecture.

As used herein, the term "network function (NF) " refers to a processing function in a network, and defines a functional behavior and an interface. The network function may be implemented by using dedicated hardware, or may be implemented by running software on dedicated hardware, or may be implemented on a form of a virtual function on a common hardware platform. From a perspective of implementation, network functions may be classified into a physical network function and a virtual network function. From a perspective of use, network functions may be classified into a dedicated network function and a shared network function.

As used herein, the term "terminal device" or "user equipment" (UE) refers to any entities or devices that can wirelessly communicate with the network devices or with each other. Examples of the terminal device can include a mobile phone, a mobile terminal (MT) , a mobile station (MS) , a subscriber station (SS) , a portable subscriber station (PSS) , an access terminal (AT) , a computer, a wearable device, an on-vehicle communication device, a machine type communication (MTC) device, a D2D communication device, a V2X communication device, a sensor and the like. The term "terminal device" can be used interchangeably with a UE, a user terminal, a mobile terminal, a mobile station, or a wireless device.

Current 3GPP standards support a fully centralized configuration model of the TSN network, an example of which is shown in Fig. 1. Referring to Fig. 1, TSN end stations 103, including for example a Talker end station (or "Talker" for short) 103A and one or more listener end stations (or "Listener" for short) 103B, may communicate TSN stream requirements to a centralized user configuration (CUC) block 101. The CUC 101 may forward the TSN stream requirements from a found Talker to a centralized network configuration (CNC) block 102. The CNC 102 may also acquire network capabilities information and active topology information from TSN bridges 104. Then, the CNC 102 may determine end-to-end communication paths from the Talker 103A to respective Listeners 103B that fulfill the TSN stream requirements and provide network configuration information to each TSN bridge 104 in the paths. The CNC 102 may also provide the status of each stream to the CUC 101 so that the CUC 101 may inform the end stations 103 to start transmission.

It is expected that a fully distributed configuration model of the TSN network would be supported in a future release of the 3GPP standards in order to extend 5GS support for diversified time sensitive communication (TSC) services. An example of the fully distributed configuration model of the TSN network is shown in Fig. 2. Referring to Fig. 2, the fully distributed model does not include the CUC 101 or the CNC 102, and the TSN end stations 103 may communicate TSN stream requirements directly to the TSN network. The TSN bridge on the path from the Talker 103A to the Listeners 103B may propagate TSN user and network configuration information along with the active topology for the TSN stream to a neighboring bridge, and the network resources may be managed locally in the TSN bridges.

Fig. 3 illustrates 5GS integration as TSN bridges in the TSN network. As shown in Fig. 3, the 5GS TSN bridges 104A, 104B enable

TSN end stations

103A, 103B, 103C to communicate with a TSN system via a wireless network, which greatly facilitates flexible deployment of the TSN end stations. For example, the TSN end stations 103 may be deployed far away from the TSN system while they are under control of the TSN system. Examples of the TSN end stations 103 may include a robot, a controller, an actuator, a remote sensor or any other industrial devices or equipment.

The granularity of the 5GS TSN bridges is per UPF, and Fig. 3 schematically shows two

bridges

104A, 104B associated with

UPFs

105A, 105B, respectively. For interoperations between the 5GS and the TSN network, TSN translator functionalities are provided in the respective 5GS TSN bridges 104, including device-side TSN translators (DS-TTs) 108 and network-side TSN translators (NW-TTs) 106. The TSN end stations 103 connected to UEs 107 obtains a DS-TT port number during a PDU session establishment procedure, and the DS-TT port number is associated to a PDU session 109 providing connectivity to the TSN network. The PDU sessions (such as 109B, 109C in Fig. 3) which connect to the TSN network via a specific UPF (such as 105B in Fig. 3) may be grouped into a virtual bridge (such as 104B in Fig. 3) and handled by the same TSN AF (115 in Fig. 4) . Different TSN end stations (such as 103A, 103B in Fig. 3) may connect to a UE (107A in Fig. 3) via different DS-TT ports (108A, 108B in Fig. 3) /PDU sessions (109A, 109B in Fig. 3) , and there is one PDU session per DS-TT port for a given UPF. A binding relationship between the DS-TT port number and the PDU session may be stored in a TSN AF (115 in Fig. 4) during reporting of logical TSN bridge information.

In industry control scenarios, one or more Talker end stations may need to control a large number of Listener end stations to carry out a common task. In such a case, a multicast data forwarding solution is preferred to distribute the same traffic data from a Talker to a plurality of Listeners. If more than one Listener is located in a 5GS TSN bridge, the multicast solution is expected to reduce resource consumption. However, multicast data forwarding is not supported yet in the fully distributed configuration model of the TSN network integrated with 5GS.

Fig. 4 is an example block diagram illustrating a scenario where TSN Talker and TSN Listeners attach to the 5GS integrated with a TSN network. In the example embodiment shown in Fig. 4,

TSN end stations

103A, 103B and 103C are connected to the TSN network through the 5GS TSN bridge 104A. It would be understood that one or more of the TSN end stations may operate as Talkers, and remaining TSN end stations may operate as Listeners. In addition, an end station may operate as a Talker in a procedure but as a Listener in another procedure. For concision and clarity of the description, hereinafter the TSN end station 103A would be taken as the Talker, and the

TSN end stations

103B, 103C would be taken as the Listeners.

Referring to Fig. 4, the

end stations

103A, 103B, 103C may be connected to the

UEs

107A, 107B, 107C respectively. The UE 107A is connected via air links to a base station for example the gNB 110A, and the

UEs

107B, 107C are connected to a base station for example the gNB 110B. It would be understood that the

UEs

107A, 107B, 107C may connect to the same or different gNBs. The

gNBs

110A, 110B, which may be termed as "radio access network (RAN) " , may connect to the 5G core network (5GC) via backhaul connections, and the 5GC may include control plane (CP) network functions (NFs) such as an AMF 111, an SMF 112, a PCF 113, a UDR 114 and a TSN AF 115 and a user plane (UP) NF such as a UPF 105. Fig. 5 shows that the UE 107A and the

UEs

107B, 107C connect to the same PDU session anchor (PSA) UPF 105, and it would be understood that the UE 107 may connect to different PSA UPF than the anchor UPF 105 for the

UEs

107B, 107C. The 5GC NFs may be implemented in one single physical entity or in separate physical entities. The 5GS TSN bridge 104A may connect to a neighbor bridge for example the TSN bridge 104B. It would be appreciated that additional TSN end stations may connect to the TSN bridge 104B.

Multicast would be an efficient way when for example the Talker 103A needs to send the same instructions to the

Listeners

103B, 103C, as shown by the arrowed lines in Fig. 4. In the example shown in Fig. 4, the Talker 103A is attached to the 5GS. It would be appreciated that in some embodiments the Talker 103A may connect to a TSN bridge such as the bridge 104B instead of the 5GS bridge 104A, and it may also need to send traffic data to the

end stations

103B, 103C by multicast. Hereinafter, embodiments of multicast data forwarding solutions for the TSN network integrated with the 5GS would be discussed. The TSN network may have the fully distributed configuration model.

Fig. 5 is an example interaction diagram illustrating operations for supporting a multicast service in the TSN network integrated with the 5GS according to some embodiments. For simplification and better understanding, only related entities for support of the multicast service are shown. It is assumed that at the beginning of the procedure shown in Fig. 5, the Talker and the Listeners have registered with the TSN network by a PDU session establishment procedure, and the PDU sessions and the DS-TT ports have been determined for the Talker and the Listeners.

Referring to Fig. 5, at an operation 210, the

Listener UEs

107B, 107C may forward a request of joining a multicast group sent from the

Listener end stations

103B, 103C to the network so that the network can determine a first group of Listener UEs that intend to join the multicast group. An example of the operation 210 is shown in Fig. 6. Referring to Fig. 6, at an operation 212, the

Listener end stations

103B, 103C may be pre-configured with group addresses such as Ethernet group MAC addresses for a plurality of multicast groups. Then at an operation 214, the

Listener end stations

103B, 103C may send the request of joining a multicast group via corresponding

Listener UEs

107B, 107C to for example the UPF 105, and the request may contain a group address such as an Ethernet group MAC address for the multicast group that the

Listener end stations

103B, 103C intend to join. In some embodiments, the request may be sent via a Multiple MAC Registration Protocol (MMRP) message. The MMRP is a protocol that allows an end station to dynamically register a group membership or individual MAC address information with the bridges, and it can be seen as a definition which network entities such as end stations or bridges register as a member of a multicast group.

When the UPF 105 receives the request from one or more Listener UEs such as the

Listener UEs

107B, 107C, it may exact information contained in the request such as the group address representing the multicast group and send the exacted information as well as a corresponding UE ID such as SUPI and a DS-TT port numbers to a control plane (CP) network function (NF) such as the SMF 112, the PCF 113 or the TSN AF 115 in an operation 216. In some embodiments, alternatively, the UPF 105 may forward the request to the CP NF and the CP NF would extract relevant information from the request. Then in an operation 218, the SMF 112, the PCF 113 or the TSN AF 115 may collect the group addresses extracted from the requests so as to determine a first group of Listener UEs that intend to join the multicast group. In some embodiments, the CP NFs such as the SMF 112, the PCF 113 or the TSN AF 115 may also maintain (for example establish or update) and store group binding information that binds the multicast group with the first group of Listener UEs. Fig. 7 shows an example of control information including the group binding information maintained in the 5GS according to some embodiments. Referring to Fig. 7, the group binding information may comprise a group address such as an Ethernet group MAC address, a list of Listener UEs in the first group, and a list of DS-TT port numbers. In some embodiments, the group binding information may be stored in a database in the UDR 114 so that the SMF 112, the PCF 113 or the TSN AF 115 may query and update the group binding information in the database.

Referring back to Fig. 5, at an operation 220, the Talker UE such as the Talker UE 107A may forward a Talker advertise declaration sent from the Talker end station 103A to a multicast group. In some embodiments, the Talker advertise declaration may be sent via a Multicast Stream Registration Protocol (MSRP) message. The MSRP is a protocol defined by IEEE for network resource reservation of streams with QoS requirements, and it also specifies which network entity listens to a specific stream. The Talker advertise declaration may comprise a stream ID of a TSC stream, QoS information such as Traffic Specification (TSpec) for the TSC stream, and a destination address of the TSC stream.

When receiving the Talker advertise declaration in the operation 220, the 5GS will process the Talker advertise and extract relevant information such as the stream ID, the QoS information and the destination address from the Talker advertise declaration. In some embodiments, a CP NF or a UP NF performs the process. Then in an operation 222, a CP NF such as the SMF 112, the PCF 113 or the TSN AF 115 may query the group binding information for a group address that matches the destination address in the Talker advertise declaration. If a group address is identified matching the destination address of the Talker advertise declaration, the SMF 112, the PCF 113 or the TSN AF 115 may determine routing of the Talker advertise declaration to the first group of UEs that have joined the multicast group having the group address. For example, the TSN AF 115 may determine PDU sessions and DS-TT ports for the first group of Listener UEs and forward such information to the SMF 112 via the PCF 113.

In some embodiments, the operation 210 may be omitted. In such a case, the Talker UE 107A would forward the Talker advertise declaration from the Talker 103A to a TSN bridge such as the 5GS TSN bridge 104A that the Talker UE 107A connects to. As the operation 210 is omitted and the 5GS TSN bridge 104A does not register the group MAC address on one or more ports thereof via an MMRP message, the 5GS TSN bridge 104A would distribute the Talker advertise declaration to all active egress ports thereof in the Spanning Tree Protocol (STP) domain. That is, the 5GS TSN bridge 104A would distribute the Talker advertise declaration from the Talker 103A to UEs connected to active egress ports of the 5GS TSN bridge 104A deployed in the same VLAN as the Talker 103A.

Then in an operation 230, the 5GS TSN bridge 104A may forward the Talker advertise declaration received from the Talker UE 107A to the first group of Listener UEs such as the

Listener UEs

107B, 107C, which in turn forwards the Talker advertise declaration to the

Listener end stations

103B, 103C via corresponding DS-TT ports, respectively. As discussed above, the first group of Listener UEs may include UEs that have joined the multicast group identified by a group address that matches the destination address contained in the Talker advertise declaration, or UEs connected to active egress ports of the bridge receiving the Talker advertise declaration from the Talker UE 107A and deployed in the same VLAN as the Talker 103A.

In an operation 240, the first group of Listener UEs such as the

Listener UEs

107B, 107C may forward MSRP Listener declarations sent from corresponding

Listener end stations

103B, 103C to the Talker UE 107A responsive to the Talker advertise declaration received from the Talker UE 107A. Examples of the Listener declarations may include Listener Ready and Listener Asking Failed. If the Listener end station is ready to receive the TSN stream specified in the Talker advertise declaration and resources along the path from the Talker to the Listener can guarantee the transmission of the TSN stream with required Quality of Service (QoS) , the Listener shall send a Listener Ready declaration. If the Listener end station received a Talker Failed declaration because of for example a resource reservation issue along the path from the Talker to the Listener, and the Listener end station is ready to receive the stream, it shall send a Listener Asking Failed declaration. In some embodiments, the Listener declaration may include a stream ID, a direction of the stream for example to Listeners, and a declaration type indicate if the Listener is ready to receive the TSN stream specified in the Talker advertise declaration.

In some embodiments, if the Listeners are ready to receive the TSN stream, they may issue an VLAN membership declaration by a Multiple VLAN Registration Protocol (MVRP) message before sending the Listener declarations. The MVRP VLAN membership declaration may contain the VLAN ID (VID) included in DataFrameParameters of the Talker advertise declaration, and VLAN registration would be performed for the Listeners in a Spanning Tree Protocol (STP) domain. It would be understood that MSRP and MMRP signaling mentioned in the embodiments may be performed within the context of VLAN.

Then in an operation 242, the CP NF such as the SMF 112, the PCF 113 or the TSN AF 115 may determine a second group of Listener UEs (as well as relevant DS-TT ports) from the first group of Listener UEs that sent the Listener Ready declaration for the TSN stream identified in the Talker advertise declaration. Apparently, the second group is a subset of the first group. In some embodiments, the SMF 112, the PCF 113 or the TSN AF 115 may maintain (for example establish or update) stream binding information to bind the TSN stream with the second group of Listener UEs. An example of the stream binding information is shown in Fig. 7, which may comprise the group address for the multicast group, a list of Listener UEs in the second group, a list of DS-TT port numbers associated with the second group of Listener UEs, the stream ID of the TSN stream, the VLAN ID (VID) , and the stream QoS information (TSpec) . In some embodiments, the CP NF may establish preliminary stream binding information including a list of UEs in the first group when it determines routing of the Talker advertise declaration to the first group of Listener UEs in the operation 222, and then update the preliminary stream binding information with the list of UEs in the second group and a corresponding list of DS-TT port numbers when it determines the second group of Listener UEs in the operation 242. In some embodiments, the stream ID of the TSN stream, the VID, and the stream QoS information (TSpec) are created in the operation 222. In some embodiments, the first group of Listener UEs may receive and respond to multiple Talker advertise declarations from one or more Talkers advertising a plurality of TSN streams for the multicast group, and then multiple pieces of stream binding information may be maintained for the multicast group, as shown in Fig. 7. It would be understood that a second group of UEs included in one piece of stream binding information may be the same or at least partially different from another second group of UEs included in another piece of stream binding information.

When the second group of Listener UEs and relevant DS-TT ports are determined in the operation 242, a multicast scope for a TSN stream from the Talker to the Listeners is determined. Then in an operation 250, the CP NF for example the SMF 112, the PCF 113 or the TSN AF 115 may maintain (for example establish or update) TSC multicast session context and TSC multicast QoS flow information for the second group of Listener UEs. The CP NF may maintain the TSC multicast session context per TSC multicast session, and the TSC multicast session is a collection of TSC multicast QoS flows for the multicast group. That is, PDUs carrying user payload of the TSC multicast QoS flows belonging to the TSC multicast session context have the same destination address (i.e., the group address for a multicast group) . A QoS flow identifier (QFI) may be assigned to the TSC multicast QoS flow. It would be appreciated that two or more TSN streams may be mapped to one TSC multicast session established for a certain second group of UEs, and therefore the number S1 of the TSN streams is equal to or larger than the number S2 of the TSC multicast sessions. One TSC multicast session may comprise a number (S3 in Fig. 7) of TSC multicast QoS flows, and one or more TSN streams may be transmitted on one multicast QoS flow. Therefore, the number S1 of the TSN streams, the number S2 of the TSC multicast sessions, and the number S3 of the TSC multicast QoS flows satisfy the following relationships: S1≥S2,

Referring to Fig. 7, the TSC multicast session context may comprise a session context ID, the group address, an anchor UPF ID of the Talker UE, the list of listener UEs in the second group, and the list of DS-TT port numbers associated with the second group of Listener UEs. The TSC multicast QoS flow information may comprise a multicast QoS flow ID (QFI) , a PDU session ID and/or MAC address of the Talker UE, the group address, the list of Listener UEs in the second group, the list of DS-TT port numbers associated with the second group of Listener UEs, the stream ID, the VLAN ID, and the stream QoS requirements (TSpec) . It would be understood that the control information discussed above including the group binding information, the stream binding information, the TSC multicast session context and the TSC multicast QoS flow information may be stored in the CP NFs such as the SMF 112, the PCF 113 or the TSN AF 115, or stored in the UDR 114. In some embodiments, the CP NF for example the SMF 112, the PCF 113 or the TSN AF 115 may further maintain (for example establish or update) associations between the control information shown in Fig. 7. For example, the CP NF may maintain associations of the TSN streams, the TSC multicast sessions and the TSC multicast QoS flows. This is desirable when the control information is stored in different entities. For example, when the TSC multicast session context is stored in the UDR 114 and the TSC multicast QoS flow information is stored in the SMF 112, the SMF 112 may retrieve information of one or more QoS flows corresponding to a TSC multicast session from the UDR 114 using the association between the TSC multicast QoS flows and the TSC multicast sessions.

When the TSC multicast session context and the TSC multicast QoS flow information are determined, the TSC multicast sessions and the TSC multicast QoS flows may be established for the TSN streams in an operation 260. The procedure for establishing the TSC multicast session and the TSC multicast QoS flow may be triggered at the 5GC-CP such as the SMF 112, the PCF 113 or the TSN AF 115 by indicating the TSC multicast session context ID, the TSC multicast QoS flow ID (QFI) and the second group of Listener UEs to the one or more base stations for example the gNB 110B in Fig. 4 for the second group of Listener UEs. An example of the procedure for establishing a TSC multicast session and a TSC multicast QoS flow is shown in Fig. 8.

Referring to Fig. 8, the TSC multicast session and QoS establishment procedure may be triggered at the 5GC-CP for example the SMF 112 by sending s multicast registration request to the gNB 110B for the second group of

Listener UEs

107B, 107C in an operation 262. The multicast registration request may include parameters for the multicast session and the QoS flow such as the multicast session context ID, the group MAC address, the multicast QFI, the list of UEs, and the list of DS-TT port numbers. It would be appreciated that the multicast registration request may be forwarded via the AMF 111 to the gNB 110B. For example, the SMF 112 may send a Namf_Communication_N1N2MessageTransfer message including the multicast registration request to the AMF 111, and the AMF 111 may forward the request by a N2 message to the gNB 110B. In some embodiments, the procedure for establishing the TSC multicast session and the TSC multicast QoS flow may be triggered at the PCF 113 or the TSN AF 115. For example, the PCF 113 may trigger the procedure by sending a PCF initiated SM (Session Management) Policy Association Modification message including the multicast registration parameters to the SMF 112, or the TSN AF 115 may trigger the procedure by sending a QoS mapping request including the multicast registration parameters to the PCF 113 and then to the SMF 112.

In the operation 262, the 5GC-CP NF such as the SMF 112 may further provide user plane configuration information to the anchor UPF 105 of the Talker 103A and the RANs such as the gNB 110B connecting the second group of Listener UEs for forwarding stream traffic of one or more TSC multicast QoS flows from the anchor UPF to the RANs.

When the gNB 110B receives the multicast registration parameters, the gNB 110B may reserve resources and setups links for the multicast session and QoS flow. In an operation 264, the gNB 110B may establish one or more radio bearers for example data radio bears (DRBs) for the TSC multicast QoS flow for one or more Listener UEs in the second group. In some embodiments, the gNB 110B may establish a shared radio bearer for the second group of Listener UEs, or it may establish multiple unicast radio bearers per Listener UE. In addition, the user plane configuration information received in the operation 262 may be applied between the anchor UPF of the Talker 103A and the RANs connecting the second group of Listener UEs.

The gNB 110B may further report establishment status of the one or more radio bearers for the TSC multicast QoS flow for one or more Listener UEs in an operation 266. For example, if the radio bearer (s) is established successfully, the gNB 110B may send a multicast registration response to the SMF 112 via the AMF 111 in an operation 266a. The multicast registration response may include the multicast QoS flow ID (QFI) . Alternatively, if the gNB 110B failed to establish one or more radio bearers for the multicast QoS flow for one or more of the Listener UEs in the second group, the gNB 110B may report failure in establishment of the one or more radio bearers for the TSC multicast QoS flow for the one or more Listener UEs to the 5GC-CP in an operation 266b. For example, the gNB 110B may send a multicast registration failure message to the SMF 112 via the AMF 111, which may include the multicast QFI, at least one Listener UE identifier for which the radio bearer is not successfully established, and the DS-TT port number of the at least one Listener UE. Then, the SMF 112 (or the PCF 113, the TSN AF 115) may update parameters of the multicast control information in a local storage or stored in the UDR 114. For example, the SMF 112 may remove the UE and relevant DS-TT port number from the stream binding information, the TSC multicast session context and the TSC multicast QoS flow information.

Referring back to Fig. 5, in an operation 270, the 5G-CP such as the SMF 112, the PCF 113 or the TSN AF 115 may configure resource for an uplink (UL) TSC QoS flow of the Talker 103A. In some embodiments, the resource configuration for the UL TSC QoS flow may be implemented by a PDU session modification procedure.

When the resource configuration is performed successfully, the Listener declarations may be forwarded to the Talker 103A in an operation 280. In some embodiments, the Listener declarations may be processed in the control plane or user plane and then the processing result is sent to the Talker 103A.

In an operation 290, the 5GC-CP such as the SMF 112, the PCF 113 or the TSN AF 115 may further configure rules in the anchor UPF 105 of the Talker 103A for forwarding the TSN stream with certain source MAC address and/or destination MAC address from the anchor UPF 105 of the Talker 103A to the second group of

Listener UEs

107B, 107C and eventually to the

Listeners

103B, 103C via the established TSC multicast QoS flow. For example, the rules may include data forwarding rules such as Packet Detection Rules (PDR) and Forwarding Action Rules (FAR) . With such rules, the UPF 105 will detect and receive TSN stream traffic data received from the Talker 103A with certain source MAC address and/or destination MAC address in an operation 292 and forward the detected TSN stream traffic data to the second group of

Listener UEs

107B, 107C and eventually to the

Listeners

103B, 103C via the assigned one or more TSC multicast QoS flows in an operation 294.

It would be appreciated that UEs in the first group and/or the second group may change dynamically. For example, a new Listener may request to join an existing TSN stream, or a Listener connecting to an UE in the first and/or second group of UEs may request to quit from receiving an existing TSN stream. For another example, the Talker may decide to provide a new TSN stream or stop an existing TSN stream. Therefore, in addition to establishing the control information when first and/or second group of Listener UEs are established, the operation of maintaining the control information for the multicast group discussed above may further comprise updating the control information responsive to change in the TSN streams and the first and/or second group of listener UEs, for example adding parameters to the control information when a new Listener UE joins the first and/or second group of Listener UEs and/or a new TSN stream is advertised, removing parameters from the control information when a Listener UE quits from the first and/or second group of Listener UEs and/or an existing TSN stream is stopped. For example, when a new UE requests to join the multicast group, the 5GC-CP may add the new UE to the first group by adding parameters of the new UE to the group binding information. The Talker may periodically send the Talker advertise declaration to the first group of Listener UEs. When the new UE responds to the Talker advertise declaration with a Listener Ready declaration, the 5GC-CP may add the new Listener UE to the second group by adding parameters of the new Listener UE to the stream binding information, the TSC multicast session context and the TSC multicast QoS flow information. Then, the new Listener UE may be mapped to a new or existing TSC multicast session and QoS flow and receive the TSN stream on the QoS flow from the Talker. When a Listener UE in the second group quits from the second group, the 5GC-CP may remove parameters of the Listener UE from the stream binding information, the TSC multicast session context and the TSC multicast QoS flow information. At this point of time, the Listener UE may still in the first group. If the Listener UE quits from the first group, the 5GC-CP may also remove parameters of the Listener UE from the group binding information. In this way, the first group of Listener UEs and the second group of Listener UEs may dynamically change.

Now operations at respective network devices, network functions and terminal devices would be discussed in more detail with reference to Figs. 9-16. It would be appreciated that some details of the operations at respective devices/functions may have been discussed above with reference to the network shown in Fig. 4 and the procedure shown in Fig. 5 and thus a brief description thereof will be given below. For a better understanding, the below description may be read with reference to the above description relating to Figs. 3-8.

Fig. 9 illustrates an example method 300 for multicast service support in the TSN network integrated with 5GS as one or more bridges. The TSN network may have the fully distributed configuration model. The method 300 may be performed by a 5GC-CP network function including but not limited to a SMF, a PCF or a TSN AF, for example the SMF 112, the PCF 113 or the TSN AF 115 shown in Fig. 4. For example, steps of the method 300 may be performed by means, modules or elements of an apparatus implemented at the 5GC-CP network function.

Referring to Fig. 9, the method 300 may optionally include a step 310 of determining a first group of Listener UEs joining a multicast group identified by a group address. As discussed above, for example, the 5GC-CP NF may determine the first group of Listener UEs based on a request of joining the multicast group received from the first group of Listener UEs via a UPF such as the UPF 105.

In a step 320, the 5GC-CP NF may determine from the first group of Listener UEs a second group of Listener UEs that are ready to receive a TSN stream for the multicast group. For example, the 5GC-CP NF may determine the second group of Listener UEs based on Listener declarations received from one or more of the first group of Listener UEs. The first group of Listener UEs may send the Listener declarations responsive to a Talker advertise declaration received from a Talker declaring that the Talker provides a TSN stream for the multicast group. Examples of the Listener declarations may include but not limited to Listener Ready and Listener Asking Failed. The 5GC-CP may determine UEs connecting Listeners responded with Listener Ready belong to the second group.

In a case where the step 310 is omitted, the TSN bridge which receives the Talker advertise declaration from the Talker will distribute the Talker advertise declaration on active egress ports of the TSN bridge in the Spanning Tree Protocol (STP) domain (e.g., in the VLAN domain of the Talker) . Then, UEs connected to the active egress ports of the bridge in the STP domain (e.g., deployed in the same VLAN as the Talker) may be considered as the first group of Listener UEs. Based on Listener Ready declarations sent from such UEs responsive to the Talker advertise declaration, the 5GC-CP NF can determine the second group of Listener UEs that are ready to receive the TSN stream provided by the Talker for the multicast group.

When the Talker providing the TSN stream and the second group of Listener UEs receiving the TSN stream are identified, a multicast scope is determined accordingly. The 5G-CP NF may also maintain control information for the multicast group, including for example group binding information for binding the multicast group with the first group of Listener UEs, the stream binding information for binding the multicast group with the second group of Listener UEs, TSC multicast session context indicating a TSC multicast session for the TSN stream, TSC multicast QoS flow information indicating a TSC multicast QoS flow for the TSN stream, and associations between the above information for the first and/or second group of UEs. Example parameters of the control information have been detailed above with reference to Fig. 7, and a repetitive description thereof is omitted here.

The control information may be maintained in separate operations. For example, the group binding information may be established when the first group of Listener UEs are determined, the stream binding information may be established when the second group of Listener UEs are determined, and the TSC multicast session context and TSC multicast QoS flow information may be established after the stream binding information is established. The control information may further be updated responsive to changes in the multicast group. For example, when a new Listener UE joins the first and/or second group, parameters of the new Listener UE may be added to the control information. When a Listener UE quits from the first and/or second group, parameters of the Listener UE may be removed from the control information.

The method 300 may further comprise a step 340 of triggering a procedure of establishing a TSC multicast session and a TSC multicast QoS flow for the TSN stream based on the TSC multicast session context and the TSC multicast QoS flow information. In some embodiments, the 5GC-CP NF may trigger the establishment procedure by indicating the second group of Listener UEs, the TSC multicast session context ID and the TSC multicast QoS flow ID (QFI) to the radio access network serving the second group of Listener UEs. For example, the TSN AF may trigger the establishment procedure by sending a QoS mapping request to the PCF, or the PCF may trigger the establishment procedure by sending a Session Management Policy Association Modification message to the SMF, or the SMF may trigger the establishment procedure by sending a multicast registration request via the AMF to one or more base stations providing network access for the second group of Listener UEs. It would be appreciated that the TSC multicast session may comprise multiple TSC multicast QoS flows, and one or more TSN streams may be transmitted on a QoS flow. In some embodiments, the 5GC-CP NF may further provide user plane configuration information to the anchor UPF of the Talker and the RANs connecting the second group of Listener UEs for forwarding stream traffic of one or more TSC multicast QoS flows from the anchor UPF to the RANs. Details of the establishment procedure have been discussed above with reference to Fig. 8 and a repetitive description thereof is omitted here.

If the TSC multicast session and the TSC multicast QoS flow are successfully established for the TSN stream, then in a step 350, the 5G-CP may configure rules in an anchor UPF of the Talker UE for forwarding the TSN stream from the Talker UE to the second group of Listener UEs via the established TSC multicast QoS flow. For example, the configured rules may include Packet Detection Rules (PDR) and/or Forwarding Action Rules (FAR) . Thus, when the anchor UPF receives traffic data of the TSN stream from the Talker, it will forward the TSN stream traffic data to the RANs connecting the second group of Listener UEs and eventually to the Listeners.

In some embodiments, if the establishment of the TSC multicast QoS flow is failed, for example when the base station and/or the Listener UE have no resource available meeting the QoS flow requirements, the 5G-CP NF may further update parameters in the control information of the multicast group. For example, the 5G-CP NF may remove the UE which failed to establish the QoS flow and its DS-TT port number from the second group of Listener UEs or also from the first group of Listener UEs included in the control information.

Fig. 10 is an example flow chart illustrating a method 400 for multicast service support in the TSN network integrated with 5GS as one or more bridges. The TSN network may have the fully distributed configuration model. The method 400 may be performed by a 5GC-UP network function for example a UPF such as the UPF 105 shown in Fig. 4. For example, steps of the method 400 may be performed by means, modules or elements of an apparatus implemented at the 5GC-UP network function.

Referring to Fig. 10, the method 400 may optionally comprise a step 410 of receiving a request of joining a multicast group identified by a group address from a first group of Listener UEs. For example, as discussed above with reference to Fig. 6, the UPF 105 may receive the request carried in an MMRP message. In some embodiments, the step 410 may be omitted.

The method 400 may further comprise a step 420 of forwarding a Talker advertise declaration received from a Talker to the first group of Listener UEs. The Talker advertise declaration may indicate that the Talker provides a TSN stream for a multicast group and have a destination address matching a group address of the multicast group. The first group of Listener UEs may be determined as UEs that have joined the multicast group. For example, the first group of Listener UEs may be determined by querying group binding information which binds the group address with the first group of Listener UEs. In some embodiments where the step 410 is omitted and no Listener UE has issued a request of joining a multicast group, the Talker advertise declaration received from the Talker may be forwarded in the step 420 to a first group of Listener UEs that connect to active egress ports of the bridge to which the Talker connects in the STP domain.

In a step 430, the UPF may forward Listener declarations received from one or more of the first group of Listener UEs to the Talker. The one or more of the first group of Listener UEs may send the Listener declarations to the Talker responsive to the Talker advertise declaration received from the Talker. The Listener declaration may indicate if the Listener UE is ready to receive the TSN stream provided from the Talker.

The method 400 may further comprise a step 440 of applying rules for forwarding the TSN stream from the Talker to RANs connecting a second group of Listener UEs that are ready to receive the TSN stream. The second group is a subset of the first group and it may be determined based on the Listener declarations received from one or more of the first group of UEs. The rules for forwarding the TSN stream may comprise for example Packet Detection Rules (PDR) and Forwarding Action Rules (FAR) . Then, when the UPF 105 receives traffic data of the TSN stream from the Talker, it can detect and forward the traffic data of the TSN stream to the RANs connecting the second group of Listener UEs based on the PDR and FAR rules.

Fig. 11 is an example flow chart illustrating a method 500 for multicast service support in the TSN network integrated with 5GS as one or more bridges. The TSN network may have the fully distributed configuration model. The method 500 may be performed by a network device for example a base station such as the gNB 110B shown in Fig. 4. For example, steps of the method 500 may be performed by means, modules or elements of an apparatus implemented at the network device.

Referring to Fig. 11, the method 500 may comprise a step 510 of receiving a multicast registration request from the core network for example from the SMF. The multicast registration request may include for example TSC session context ID, QoS flow information, a list of Listener UEs in the second group and relevant DS-TT port numbers.

The method 500 may further comprise a step 520 of establishing one or more radio bearers for example data radio bearers (DRBs) for a TSC multicast QoS flow for one or more Listener UEs in the second group based on the received multicast registration request. In some embodiments, the base station may establish a shared radio bearer for the one or more Listener UEs, or the base station may establish one unicast radio bearer per Listener UE.

The method 500 may further comprise a step 530 of reporting establishment status of the one or more radio bearers to the core network. For example, the gNB 110B may send a multicast registration response when the one or more radio bearers are successfully established or a multicast registration failure message when the gNB 110B failed to establish one or more radio bearers for the multicast QoS flow for one or more of the Listener UEs in the second group. From the failure report, the core network knows that the one or more Listener UEs cannot receive the TSN stream, and the one or more Listener UEs may be removed from the second group.

Fig. 12 is an example flow chart illustrating a method 600 for multicast service support in the TSN network integrated with 5GS as one or more bridges. The TSN network may have the fully distributed configuration model. The method 600 may be performed by a terminal device for example the

Listener UE

107B or 107C shown in Fig. 4. For example, steps of the method 600 may be performed by means, modules or elements of an apparatus implemented at the network device.

Referring to Fig. 12, the method 600 may optionally comprise a step 610 of forwarding a request of joining a multicast group identified by a group address received from a Listener connected to the Listener UE to the network. For example, a Listener may be pre-configured with multiple group addresses, and the request sent from the Listener may include the group address of the multicast group that the Listener intends to join. In some embodiments, the Listener may send the request by a MMRP message.

In a step 620, the Listener UE may forward a Talker advertise declaration received from a Talker to the Listener. The Talker advertise declaration indicates that the Talker provides a TSN stream for a multicast group and it may include a destination address that matches the group address of the multicast group.

Responsive to the Talker advertise declaration, the Listener may send a Listener Ready declaration to the Talker indicating that the Listener is ready to receive the TSN stream from the Talker. The Listener UE may forward the Listener declaration to the Talker in a step 630.

For the Listener to receive the TSN stream from the Talker, a TSC multicast QoS flow and relevant radio bearer would be established for the TSN stream for the Listener UE. Then in a step 640, the Listener UE may forward multicast transmissions of the TSN stream received from the Talker to the Listener on the radio bearer established for the TSC multicast QoS flow for the Listener. The TSN stream is provided from the talker to a multicast group identified by a destination address of a TSN stream which the Listener has joined.

Fig. 13 illustrates a block diagram of an example communication system 700 in which embodiments of the present disclosure can be implemented. For example, the communication system 700 may be integrated as one or more virtual bridges in the TSN network as shown in Fig. 4. The communication system 700 may comprise a user equipment (UE) 710, a network function 730, and a network device 720 in communication with the UE 710 via air links and the network function 730 via backhaul connections 728. The UE 710 may be implemented as the

UE

107A, 107B or 107C discussed above, the network device 720 may be implemented as the

base stations

110A or 110B discussed above, and the network function 730 may be implemented as one or more of the 5GC-UP and 5GC-CP network functions discussed above.

The UE 710 may comprise one or more processors 711, one or more memories 712, one or more transceivers 713 and one or more communication interfaces 717 interconnected through one or more buses 714. The one or more buses 714 may be address, data, or control buses, and may include any interconnection mechanism such as series of lines on a motherboard or integrated circuit, fiber, optics or other optical communication equipment, and the like. Each of the one or more transceivers 713 may comprise a receiver and a transmitter, which are connected to one or more antennas 716. The UE 710 may wirelessly communicate with the network device 720 through the one or more antennas 716. The one or more communication interfaces 717 may provide wired or wireless communication links through which the UE 710 may communicate with other devices, entities, elements or functions. For example, the UE 710 may communicate with one or more TSN end stations or neighboring TSN bridges through the one or more communication interfaces 717. The one or more memories 712 may include computer program code 715. The one or more memories 712 and the computer program code 715 may be configured to, when executed by the one or more processors 711, cause the UE 710 to perform processes and steps relating to the UE 107 as described above.

The network device 720 may comprise one or more processors 721, one or more memories 722, one or more transceivers 723 and one or more communication interfaces 727 interconnected through one or more buses 724. The one or more buses 724 may be address, data, or control buses, and may include any interconnection mechanism such as a series of lines on a motherboard or integrated circuit, fiber, optics or other optical communication equipment, and the like. Each of the one or more transceivers 723 may comprise a receiver and a transmitter, which are connected to one or more antennas 726. The network device 720 may operate as a BS for the UE 710 and wirelessly communicate with the UE 710 through the one or more antennas 726. The one or more communication interfaces 727 may provide wired or wireless communication links through which the network device 720 may communicate with other network devices, entities, elements or functions. The one or more memories 722 may include computer program code 725. The network device 720 may communicate with the network function 730 via the backhaul connections 728. The one or more memories 722 and the computer program code 725 may be configured to, when executed by the one or more processors 721, cause the network device 720 to perform processes and steps relating to the BSs 110 as described above.

The network function 730 may comprise one or more processors 731, one or more memories 732, and one or more communication interfaces 737 interconnected through one or more buses 734. The one or more buses 734 may be address, data, or control buses, and may include any interconnection mechanism such as a series of lines on a motherboard or integrated circuit, fiber, optics or other optical communication equipment, and the like. The network function 730 may operate as a core network function in the control plane or the user plane and wired or wirelessly communicate with the BS 720 through one or more links. The one or more communication interfaces 737 may provide wired or wireless communication links through which the network function 730 may communicate with other devices, entities, elements or functions. The one or more memories 732 may include computer program code 735. The one or more memories 732 and the computer program code 735 may be configured to, when executed by the one or more processors 731, cause the network function 730 to perform processes and steps relating to one or more of the 5GC-CP and 5GC-UP network functions as described above.

The one or

more processors

711, 721 and 731 discussed above may be of any appropriate type that is suitable for the local technical network, and may include one or more of general purpose processors, special purpose processor, microprocessors, a digital signal processor (DSP) , one or more processors in a processor based multi-core processor architecture, as well as dedicated processors such as those developed based on Field Programmable Gate Array (FPGA) and Application Specific Integrated Circuit (ASIC) . The one or more processors 1011, 1021 and 1031 may be configured to control other elements of the UE/network device/network element and operate in cooperation with them to implement the procedures discussed above.

The one or

more memories

712, 722 and 732 may include at least one storage medium in various forms, such as a volatile memory and/or a non-volatile memory. The volatile memory may include but not limited to for example a random access memory (RAM) or a cache. The non-volatile memory may include but not limited to for example a read only memory (ROM) , a hard disk, a flash memory, and the like. Further, the one or

more memories

712, 722 and 732 may include but not limited to an electric, a magnetic, an optical, an electromagnetic, an infrared, or a semiconductor system, apparatus, or device or any combination of the above.

It would be understood that blocks in the drawings may be implemented in various manners, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more blocks may be implemented using software and/or firmware, for example, machine-executable instructions stored in the storage medium. In addition to or instead of machine-executable instructions, parts or all of the blocks in the drawings may be implemented, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs) , Application-Specific Integrated Circuits (ASICs) , Application-Specific Standard Products (ASSPs) , System-on-Chip systems (SOCs) , Complex Programmable Logic Devices (CPLDs) , etc.

Some exemplary embodiments further provide computer program code or instructions which, when executed by one or more processors, may cause a device or apparatus to perform the procedures described above. The computer program code for carrying out procedures of the exemplary embodiments may be written in any combination of one or more programming languages. The computer program code may be provided to one or more processors or controllers of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

Some exemplary embodiments further provide a computer program product or a computer readable medium having the computer program code or instructions stored therein. The computer readable medium may be any tangible medium that may contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable medium may include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

Although the subject matter has been described in a language that is specific to structural features and/or method actions, it is to be understood the subject matter defined in the appended claims is not limited to the specific features or actions described above. On the contrary, the above-described specific features and actions are disclosed as an example of implementing the claims.

Claims

A method for multicast service support in a time sensitive network (TSN) comprising:

determining, from a first group of listener user equipments (UEs) , a second group of listener UEs that are ready to receive a TSN stream for a multicast group; and

triggering establishment of a TSC multicast session and a TSC multicast QoS flow for the second group of listener UEs to receive the TSN stream.
The method of Claim 1 further comprising, before determining the second group of listener UEs:

determining the first group of listener UEs based on a request of joining the multicast group identified by a group address received from the first group of listener UEs.
The method of Claim 1 wherein the first group of listener UEs include UEs that are connected to active ports of a bridge in the TSN network receiving a talker advertise declaration from a talker and deployed in a virtual local area network (VLAN) with the talker, the talker advertise declaration indicating that the talker provides the TSN stream for the multicast group.
The method of Claim 1 wherein the second group of listener UEs are determined based on listener declarations received from one or more of the first group of listener UEs indicating if the one or more of the first group of listener UEs are ready to receive the TSN stream.
The method of Claim 4 wherein the listener declarations are sent from one or more of the first group of listener UEs responsive to a talker advertise declaration from a talker indicating that the talker provides the TSN stream for the multicast group.
The method of Claim 1 or 2 further comprising maintaining control information for the multicast group, the control information comprising one or more of the following information:

group binding information for binding the multicast group with the first group of listener UEs;

stream binding information for binding the TSN stream with the second group of listener UEs;

TSC multicast session context indicating a TSC multicast session for one or more TSN streams for the second group of listener UEs;

TSC multicast QoS flow information indicating a TSC multicast QoS flow for forwarding traffic data of one or more TSN streams to the second group of listener UEs; and

associations between the above information for the first and/or second group of UEs.
The method of Claim 6 wherein,

the group binding information comprises one or more of the group address, a list of listener UEs in the first group, and a list of device-side TSN translator (DS-TT) port numbers associated with the first group of listener UEs,

the stream binding information comprises one or more of the group address, a list of listener UEs in the second group, a list of DS-TT port numbers associated with the second group of listener UEs, the stream ID, a VLAN ID, and stream QoS information,

the TSC multicast session context comprises one or more of a session context ID, the group address, an anchor UPF ID for the talker, the list of listener UEs in the second group, and the list of DS-TT port numbers associated with the second group of listener UEs, and

the TSC multicast QoS flow information comprises one or more of a multicast QoS flow ID (QFI) , a PDU session ID and/or MAC address of the talker, the group address, the list of listener UEs in the second group, the list of DS-TT port numbers associated with the second group of listener UEs, the stream ID, the VLAN ID, and the stream QoS information.
The method of Claim 7 wherein triggering establishment of a TSC multicast session and a TSC multicast QoS flow for the second group of listener UEs to receive the TSN stream comprises:

indicating at least one of the following the second group of UEs, relevant port numbers, the session context ID, and the QoS flow information to one or more Radio Access Networks (RANs) connecting for the second group of UEs; and

provisioning configuration information to the anchor UPF and the RANs for forwarding stream data of one or more the TSC multicast QoS flows from the anchor UPF to the RANs.
The method of Claim 6 wherein maintaining control information for the multicast group comprising:

establishing the control information for the multicast group when the first group of Listener UEs and/or the second group of Listener UEs are determined;

adding parameters to the control information when a new Listener UE joins the first group of UEs and/or the second group of UEs and/or a new TSN stream is advertised; and/or

removing parameters from the control information when a Listener UE quits from the second group of UEs and/or the first group of UEs and/or a TSN stream is stopped.
The method of Claim 6 wherein the TSC multicast session comprises a plurality of TSC multicast QoS flows for forwarding a plurality of TSN streams from one or more talker UEs via the anchor UPF represented by the anchor UPF ID to the second group of listener UEs.
The method of Claim 6 further comprising:

updating parameters of the group binding information, the stream binding information, the TSC multicast session context and/or the TSC multicast QoS flow information in a case where the establishment of the TSC multicast QoS flow for the TSC stream is failed.
The method of Claim 1 further comprising:

configuring rules in an anchor UPF of a talker UE for forwarding the TSN stream from the talker UE to the second group of listener UEs via the established TSC multicast QoS flow.
A method for multicast service support in a time sensitive network (TSN) comprising:

forwarding a talker advertise declaration received from a talker to a first group of listener UEs, the talker advertise declaration indicating that the talker provides a TSN stream for a multicast group identified by a group address;

forwarding listener declarations received from one or more of the first group of listener UEs to the talker, the listener declarations indicating if the one or more of the first group of listener UEs are ready to receive the TSN stream; and

applying rules for forwarding traffic data of the TSN stream received from the talker to a second group of listener UEs that are ready to receive the TSN stream.
The method of Claim 13 further comprising, before forwarding the talker advertise declaration:

receiving a request of joining the multicast group from the first group of listener UEs.
A method for multicast service support in a time sensitive network (TSN) comprising:

receiving, at a base station (BS) , a multicast registration request comprising one or more of time sensitive communication (TSC) session context ID, QoS flow information, a second group of UEs and relevant port numbers from a core network (CN) network function (NF) ;

establishing, at the BS, one or more radio bearers for a time sensitive communication (TSC) multicast QoS flow for one or more listener UEs in the second group, based on the received multicast registration request; and

reporting establishment status of one or more radio bearers for the TSC multicast QoS flow for one or more listener UEs to the CN NF.
A method for multicast service support in a time sensitive network (TSN) comprising:

forwarding, at a listener user equipment (UE) , multicast transmissions of a TSN stream received from a Talker to a Listener on a radio bearer established for a time sensitive communication (TSC) multicast QoS flow for the Listener, the TSN stream being provided from the talker to a multicast group identified by a destination address of a TSN stream which the listener UE has joined.
A network function in a control plane comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the network function to:

determine, from a first group of listener user equipments (UEs) , a second group of listener UEs that are ready to receive a time sensitive network (TSN) stream for a multicast group; and

trigger establishment of a time sensitive communication (TSC) multicast session and a TSC multicast Quality of Service (QoS) flow for the second group of listener UEs to receive the TSN stream.
The network function of Claim 17 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the network function to:

determine the first group of listener UEs based on a request of joining the multicast group identified by a group address received from the first group of listener UEs, before determining the second group of listener UEs.
The network function of Claim 17 wherein the first group of listener UEs include UEs that are connected to active ports of a bridge in the TSN network receiving a talker advertise declaration from a talker and deployed in a virtual local area network (VLAN) with the talker, the talker advertise declaration indicating that the talker provides the TSN stream for the multicast group.
The network function of Claim 17 wherein the second group of listener UEs are determined based on listener declarations received from one or more of the first group of listener UEs indicating if the one or more of the first group of listener UEs are ready to receive the TSN stream.
The network function of Claim 20 wherein the listener declarations are sent from one or more of the first group of listener UEs responsive to a talker advertise declaration from a talker indicating that the talker provides the TSN stream for the multicast group.
The network function of Claim 17 or 18 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the network function to maintain control information for the multicast group, the control information comprising one or more of the following information:

group binding information for binding the multicast group with the first group of listener UEs;

stream binding information for binding the TSN stream with the second group of listener UEs;

TSC multicast session context indicating a TSC multicast session for one or more TSN streams for the second group of listener UEs;

TSC multicast QoS flow information indicating a TSC multicast QoS flow for forwarding traffic data of one or more TSN streams to the second group of listener UEs; and

associations between the above information for the first and/or second group of UEs.
The network function of Claim 22 wherein,

the group binding information comprises one or more of the group address, a list of listener UEs in the first group, and a list of device-side TSN translator (DS-TT) port numbers associated with the first group of listener UEs,

the stream binding information comprises one or more of the group address, a list of listener UEs in the second group, a list of DS-TT port numbers associated with the second group of listener UEs, the stream ID, a VLAN ID, and stream QoS information,

the TSC multicast session context comprises one or more of a session context ID, the group address, an anchor UPF ID for the talker, the list of listener UEs in the second group, and the list of DS-TT port numbers associated with the second group of listener UEs, and

the TSC multicast QoS flow information comprises one or more of a multicast QoS flow ID (QFI) , a PDU session ID and/or MAC address of the talker, the group address, the list of listener UEs in the second group, the list of DS-TT port numbers associated with the second group of listener UEs, the stream ID, the VLAN ID, and the stream QoS information.
The network function of Claim 23 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the network function to trigger establishment of a TSC multicast session and a TSC multicast QoS flow by:

indicating at least one of the following the second group of UEs, relevant port numbers, the session context ID, and the QoS flow information to one or more Radio Access Networks (RANs) connecting for the second group of UEs; and

provisioning configuration information to the anchor UPF and the RANs for forwarding stream data of one or more the TSC multicast QoS flows from the anchor UPF to the RANs.
The network function of Claim 22 wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the network function to maintain control information for the multicast group by:

establishing the control information for the multicast group when the first group of Listener UEs and/or the second group of Listener UEs are determined;

adding parameters to the control information when a new Listener UE joins the first group of UEs and/or the second group of UEs and/or a new TSN stream is advertised; and/or

removing parameters from the control information when a Listener UE quits from the second group of UEs and/or the first group of UEs and/or a TSN stream is stopped.
The network function of Claim 22 wherein the TSC multicast session comprises a plurality of TSC multicast QoS flows for forwarding a plurality of TSN streams from one or more talker UEs via the anchor UPF represented by the anchor UPF ID to the second group of listener UEs.
The network function of Claim 22 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the network function to:

update parameters of the group binding information, the stream binding information, the TSC multicast session context and/or the TSC multicast QoS flow information in a case where the establishment of the TSC multicast QoS flow for the TSC stream is failed.
The network function of Claim 17 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the network function to:

configure rules in an anchor UPF of a talker UE for forwarding the TSN stream from the talker UE to the second group of listener UEs via the established TSC multicast QoS flow.
A network function in a user plane comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the network function to:

forward a talker advertise declaration received from a talker to a first group of listener UEs, the talker advertise declaration indicating that the talker provides a time sensitive network (TSN) stream for a multicast group identified by a group address;

forward listener declarations received from one or more of the first group of listener UEs to the talker, the listener declarations indicating if the one or more of the first group of listener UEs are ready to receive the TSN stream; and

apply rules for forwarding traffic data of the TSN stream received from the talker to a second group of listener UEs that are ready to receive the TSN stream.
The network function of Claim 29 wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the network function to:

receive a request of joining the multicast group from the first group of listener UEs before forwarding the talker advertise declaration.
A network device comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the network device to:

receive a multicast registration request comprising one or more of time sensitive communication (TSC) session context ID, QoS flow information, a second group of UEs and relevant port numbers from a core network (CN) network function (NF) ;

establish one or more radio bearers for a time sensitive communication (TSC) multicast QoS flow for one or more listener UEs in the second group, based on the received multicast registration request; and

report establishment status of one or more radio bearers for the TSC multicast QoS flow for one or more listener UEs to the CN NF.
A terminal device comprising:

at least one processor; and

at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the terminal device to:

forward multicast transmissions of a time sensitive network (TSN) stream received from a Talker to a Listener on a radio bearer established for a time sensitive communication (TSC) multicast QoS flow for the Listener, the TSN stream being provided from the talker to a multicast group identified by a destination address of a TSN stream which the listener UE has joined.
An apparatus for multicast service support in a time sensitive network (TSN) comprising:

means for determining, from a first group of listener user equipments (UEs) , a second group of listener UEs that are ready to receive a TSN stream for a multicast group; and

means for triggering establishment of a TSC multicast session and a TSC multicast QoS flow for the second group of listener UEs to receive the TSN stream.
An apparatus for multicast service support in a time sensitive network (TSN) comprising:

means for forwarding a talker advertise declaration received from a talker to a first group of listener UEs, the talker advertise declaration indicating that the talker provides a TSN stream for a multicast group identified by a group address;

means for forwarding listener declarations received from one or more of the first group of listener UEs to the talker, the listener declarations indicating if the one or more of the first group of listener UEs are ready to receive the TSN stream; and

means for applying rules for forwarding traffic data of the TSN stream received from the talker to a second group of listener UEs that are ready to receive the TSN stream.
An apparatus for multicast service support in a time sensitive network (TSN) comprising:

means for receiving, at a base station (BS) , a multicast registration request comprising one or more of time sensitive communication (TSC) session context ID, QoS flow information, a second group of UEs and relevant port numbers from a core network (CN) network function (NF) ;

means for establishing, at the BS, one or more radio bearers for a time sensitive communication (TSC) multicast QoS flow for one or more listener UEs in the second group, based on the received multicast registration request; and

means for reporting establishment status of one or more radio bearers for the TSC multicast QoS flow for one or more listener UEs to the CN NF.
An apparatus for multicast service support in a time sensitive network (TSN) comprising:

means for forwarding, at a listener user equipment (UE) , multicast transmissions of a TSN stream received from a Talker to a Listener on a radio bearer established for a time sensitive communication (TSC) multicast QoS flow for the Listener, the TSN stream being provided from the talker to a multicast group identified by a destination address of a TSN stream which the listener UE has joined.
A computer readable medium having instructions stored thereon, the instructions, when executed by at least one processor of a network function in a control plane, causing the network function to perform a method of any one of Claims 1-12.
A computer readable medium having instructions stored thereon, the instructions, when executed by at least one processor of a network function in a user plane, causing the network function to perform a method of any one of Claims 13-14.
A computer readable medium having instructions stored thereon, the instructions, when executed by at least one processor of a network device, causing the network device to perform a method of Claim 15.
A computer readable medium having instructions stored thereon, the instructions, when executed by at least one processor of a terminal device, causing the terminal device to perform a method of Claim 16.