CN116420347A - Method and apparatus for multicast service support in a time sensitive network - Google Patents

Abstract

Embodiments of a method and apparatus for multicast service support in a Time Sensitive Network (TSN) are disclosed. A method may include: determining, from a first set of listener User Equipments (UEs), a second set of listener UEs ready to receive TSN streams for the multicast group; and triggering the establishment of the TSC multicast session and the TSC multicast QoS stream for the second group of listener UEs to receive the TSN stream.

Description

Method and apparatus for multicast service support in a time sensitive network

Technical Field

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

Background

Certain abbreviations that may be found in the specification and/or drawings are defined as follows:

5GC 5G core network

5GS 5G system

AF application function

AMF access and mobility management functions

CP control plane

DS-TT equipment side TSN converter

FAR forwarding operation rules

gNB next generation NodeB

IIoT industrial Internet of things

MMRP multi-MAC registration protocol

MSRP multi-stream registration protocol

NF network function

NW-TT network TSN converter

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 communication

TSN time sensitive network/networking

UE user equipment

UP user plane

UPF user plane functionality

Time Sensitive Networks (TSNs) have been used in many application scenarios including, for example, industrial internet of things (IIoT) to provide low latency and high reliability connections. It is desirable to integrate a 5G system (5 GS) as a virtual node in a TSN network, such as a bridge (bridge), to provide ultra-reliable low latency communications in a flexible manner.

Disclosure of Invention

The following presents a simplified summary of example embodiments in order to provide a basic understanding of some aspects of various embodiments. It should be noted that this summary is not intended to identify key features of the essential elements or to define the scope of the embodiments, and its sole purpose is to introduce some concepts in a simplified form as a prelude to the more detailed description that is presented below.

In a first aspect, an example embodiment of a method for multicast (multicast) service support in a Time Sensitive Network (TSN) is provided. The method may include: determining, from a first set of listener User Equipments (UEs), a second set of listener UEs ready to receive TSN streams for the multicast group; and triggering the establishment of the TSC multicast session and the TSC multicast QoS stream 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 include forwarding a talker advertisement statement received from a talker (talker) to a first group of listeners UE. The talker advertisement claims may instruct talkers to provide TSN streams for multicast groups identified by group addresses. The method may further include forwarding listener assertions received from one or more of the first set of listener UEs to the talker. The listener declaration may indicate whether one or more of the first set of listeners UE are ready to receive the TSN stream. Furthermore, the method may further comprise applying rules for forwarding traffic data of the TSN stream received from the talker to a second group of listeners UE 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 include receiving, at a Base Station (BS), a multicast registration request from a Core Network (CN) Network Function (NF). The multicast registration request may include one or more of a Time Sensitive Communication (TSC) session context ID, qoS flow information, a second group of UEs, and a related port number. 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 a second group based on the received multicast registration request; and reporting to the CN NF the setup status of the one or more radio bearers for the TSC multicast QoS flows of the one or more listener UEs.

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 include forwarding, at a listener User Equipment (UE), a multicast transmission of a Time Sensitive Communication (TSC) stream received from a talker to a listener over a radio bearer of the TSN stream multicast QoS stream established for the listener. The TSN stream is provided from the talker to a multicast group identified by the destination address of the TSN stream that has been joined by the listener UE.

In a fifth aspect, an example embodiment of a network function in a control plane is provided. The network functions may include 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 include: determining, from a first set of listener User Equipments (UEs), a second set of listener UEs ready to receive Time Sensitive Network (TSN) streams for the multicast group; and triggering the establishment of a Time Sensitive Communication (TSC) multicast session and a TSC multicast quality of service (QoS) stream 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 functions may include 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 include forwarding a speaker advertisement claim received from a speaker to a first set of listeners UE. The talker advertisement claims may instruct talkers to provide Time Sensitive Network (TSN) streams for multicast groups identified by a group address. The actions may also include forwarding listener assertions received from one or more of the first set of listener UEs to the talker. The listener declaration may indicate whether one or more of the first set of listeners UE are ready to receive the TSN stream. The actions may also include applying rules for forwarding traffic data of the TSN stream received from the talker to a second set of listeners UE ready to receive the TSN stream.

In a seventh aspect, an example embodiment of a network device is provided. The network device may include 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 include: receiving a multicast registration request from a Core Network (CN) Network Function (NF) that includes one or more of a Time Sensitive Communication (TSC) session context ID, qoS flow information, a second group of UEs, and related port numbers; one or more radio bearers for a Time Sensitive Communication (TSC) multicast QoS flow are established for one or more listener UEs in the second group based on the received multicast registration request and an establishment status of the one or more radio bearers for the TSC multicast QoS flow for one or more listener UEs is reported 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 include forwarding a multicast transmission of a Time Sensitive Network (TSN) stream received from a talker to a listener over a radio bearer of a Time Sensitive Communication (TSC) multicast QoS stream established for the listener. The TSN stream may be provided from the talker to a multicast group identified by the destination address of the TSN stream to 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 include: means for determining, from a first set of listener User Equipments (UEs), a second set of listener UEs that are ready to receive TSN streams for the multicast group; and means for triggering the establishment of the TSC multicast session and the SC multicast TQoS stream for the second group of listeners UE 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 include: means for forwarding a talker advertisement announcement received from a talker to a first group of listeners UE, the talker advertisement announcement indicating that the talker provides a TSN stream for a multicast group identified by a group address; means for forwarding listener claims received from one or more of a first set of listeners UE to a talker, the listener claims indicating whether the one or more of the first set of listeners UE 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 listeners ready to receive the TSN stream.

In an eleventh aspect, an example embodiment of a device for multicast service support in a Time Sensitive Network (TSN) is provided. The apparatus may include: means for receiving, at a Base Station (BS), a multicast registration request including one or more of a Time Sensitive Communication (TSC) session context ID, qoS flow information, a second set of UEs, and related 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 of the second set of listener UEs based on the received multicast registration request: and means for reporting to the CN NF an established state of one or more radio bearers for the TSC multicast QoS flows of the one or more listener UEs.

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 include: means for forwarding, at a listener User Equipment (UE), a multicast transmission of a Time Sensitive Communication (TSC) stream received from a talker to the listener over a radio bearer established for the TSN stream. The TSN stream may be provided from the talker to a multicast group identified by the destination address of the TSN stream to 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 the method of the first aspect described above.

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 the method of the second aspect described above.

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 the method of the third aspect described above.

In a sixteenth aspect, example embodiments of a computer readable medium are provided. The computer-readable medium has instructions stored thereon. The instructions, when executed by at least one processor of the terminal device, may cause the terminal device to perform the method of the fourth aspect described above.

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

Drawings

Some example embodiments will now be described, by way of non-limiting example, 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 a 5GS TSN bridge integrated in a TSN network.

Fig. 4 is an example block diagram showing a TSN speaker and TSN listener attached to a 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 5GS, according to some embodiments.

Fig. 6 is an example interaction diagram illustrating operations for joining a multicast group in accordance with some embodiments.

Fig. 7 is an example diagram illustrating control information maintained in 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 in accordance with some embodiments.

Fig. 9 is an example flow diagram illustrating a method for multicast service support in a TSN network in accordance with some embodiments.

Fig. 10 is an example flow diagram illustrating a method for multicast service support in a TSN network in accordance with some embodiments.

Fig. 11 is an example flow diagram illustrating a method for multicast service support in a TSN network in accordance with some embodiments.

Fig. 12 is an example flow diagram illustrating a method for multicast service support in a TSN network in accordance with some embodiments.

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

Detailed Description

Hereinafter, some example embodiments are described in detail with reference to the accompanying drawings. The following description includes specific details in order to provide a thorough understanding of the various concepts. It will be apparent, however, to one skilled in the art that the concepts may be practiced without these specific details. In some instances, well-known circuits, techniques, and components have been shown in block diagram form in order not to obscure the described concepts and features.

As used herein, the term "network device" refers to any suitable entity or device that can provide a cell or coverage area through which a terminal device can access a network or receive services. The network device may be generally referred to as a base station. The term "base station" as used herein may refer to 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. A base station may be comprised 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 functionality of these distributed units depends on the split RAN architecture selected.

As used herein, the term "Network Function (NF)" refers to a processing function in a network and defines functional behavior and interfaces. The network functions may be implemented using dedicated hardware, or may be implemented by running software on dedicated hardware, or may be implemented in the form of virtual functions on a general-purpose hardware platform. From an implementation point of view, the network functions may be divided into physical network functions and virtual network functions. From a usage perspective, network functions may be divided into private network functions and shared network functions.

As used herein, the term "terminal device" or "user equipment" (UE) refers to any entity or device that can communicate wirelessly with network devices or with each other. Examples of the terminal device may 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 in-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" may be used interchangeably with UE, user terminal, mobile station, or wireless device.

The current 3GPP standard supports 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 simply "talker") 103A and one or more listener end stations (simply "listeners") 103B, may communicate TSN stream requirements to a Centralized User Configuration (CUC) block 101. CUC 101 may forward TSN flow requirements from the found speaker to a Centralized Network Configuration (CNC) block 102. The CNC 102 may also obtain network capability information and active topology information from the TSN bridge 104. The CNC 102 may then determine an end-to-end communication path from the talker 103A to the respective listener 103B meeting the TSN stream requirements and provide network configuration information to each TSN bridge 104 in the path. CNC 102 may also provide the state of each flow to CUC 101 so that CUC 101 may inform end stations 103 to begin transmission.

It is expected that a fully distributed configuration model of TSN networks will be supported in the 3GPP standards promulgated in the future to extend 5GS support for diversified Time Sensitive Communication (TSC) services. An example of a fully distributed configuration model of a TSN network is shown in fig. 2. Referring to fig. 2, the fully distributed model does not include CUCs 101 or CNCs 102, and TSN end stations 103 may communicate TSN flow requirements directly to the TSN network. TSN bridges on the path from talker 103A to listener 103B may propagate TSN users along with network configuration information and the active topology of the TSN streams to neighboring bridges and may manage network resources locally in the TSN bridges.

Fig. 3 shows 5GS integration as a TSN bridge in a TSN network. As shown in fig. 3, the 5GS TSN bridges 104A, 104B enable the TSN end stations 103A, 103B, 103C to communicate with the TSN system via a wireless network, which greatly facilitates flexible deployment of the TSN end stations. For example, TSN end stations 103 may be deployed remotely from the TSN system while they are under TSN system control. Examples of TSN end station 103 may include a robot, a controller, an actuator, a remote sensor, or any other industrial device or equipment.

The granularity of the 5GS TSN network is per UPF, and fig. 3 schematically shows two bridges 104A, 104B associated with the UPFs 105A, 105B, respectively. For interoperability between 5GS and TSN networks, TSN converter functionality is provided in the respective 5GS TSN bridge 104, including a device side TSN converter (DS TT) 108 and a network side TSN converter (nwtt) 106. The TSN end station 103 connected to the UE 107 obtains the DS-TT port number during the PDU session establishment procedure and the DS-TT port number is associated with the PDU session 109 providing the connection to the TSN network. PDU sessions (such as 109B, 109C in fig. 3) connected to the TSN network via a particular UPF (such as 105B in fig. 3) may be grouped into virtual bridges (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 the UE (107A in fig. 3) via different DS-TT ports (108A, 108B in fig. 3)/PDU sessions (109A, 109B in fig. 3), and one PDU session per DS-TT port for a given UPF. During reporting of logical TSN bridge information, the binding between DS-TT port numbers and PDU sessions may be stored in TSN AF (115 in fig. 4).

In an industrial control scenario, one or more talker end stations may need to control a large number of listener end stations to perform a common task. In this case, the multicast data forwarding solution preferably distributes the same traffic data from one speaker to multiple listeners. If more than one listener is located in the 5GS TSN bridge, the multicast solution is expected to reduce resource consumption. However, multicast data forwarding is not yet supported in the fully distributed configuration model of TSN networks integrated with 5 GS.

Fig. 4 is an example block diagram showing a scenario in which a TSN speaker and a TSN listener are attached to 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 a 5GS TSN bridge 104A. It should be appreciated that one or more of the TSN end stations may operate as a talker, while the remaining TSN end stations may operate as listeners. Furthermore, the end station may operate as a speaker in one process, but will operate as a listener in another process. For simplicity and clarity of description, hereinafter, TSN end station 103A will be considered the speaker and TSN end stations 103B, 103C will be considered listeners.

Referring to fig. 4, end stations 103A, 103B, 103C may be connected to UEs 107A, 107B, 107C, respectively. UE 107A is connected to a base station, e.g., g NB 110A, via an air link, and UEs 107B, 107C are connected to a base station, e.g., g NB 110B. It should be appreciated that the UEs 107A, 107B, 107C may be connected to the same or different gNBs. The gnbs 110A, 110B, which may be referred to as "Radio Access Networks (RANs)", may be connected to a 5G core network (5 GC) via backhaul connections, and the 5GC may include Control Plane (CP) Network Functions (NF) such as AMF 111, SMF 112, PCF 113, UDR 114, and TSN AF 115/and User Plane (UP) NF such as UPF 105. Fig. 5 shows that UE 107A and UEs 107B, 107C are connected to the same PDU Session Anchor (PSA) UPF 105, and it is understood that UE 107 may be connected to a different PSAUPF than the anchor UPF 105 of UEs 107B and 107C. The 5GC NF may be implemented in a single physical entity or in separate physical entities. The 5GS TSN bridge 104A may be connected to a neighboring bridge, such as TSN bridge 104. It is understood that additional TSN end stations may be connected to TSN bridge 104B.

For example, when the speaker 103A needs to send the same instruction to listeners 103B, 103C, multicasting will be an efficient way, as indicated by the arrows in fig. 4. In the example shown in fig. 4, speaker 103A is attached to 5GS. It should be appreciated that in some embodiments, talker 103A may be connected to a TSN bridge, such as bridge 104B, instead of 5GS bridge 104A, and may also need to send traffic data to end stations 103B, 103C via multicast. Hereinafter, an embodiment of a multicast data forwarding solution for a TSN network integrated with 5GS will be discussed. The TSN network may have a fully distributed configuration model.

Fig. 5 is an example interaction diagram illustrating operations for supporting multicast services in a TSN network integrated with 5GS, according to some embodiments. For simplicity and better understanding, only relevant entities for support of multicast services are shown. It is assumed that at the beginning of the procedure shown in fig. 5, the talker and listener have registered with the TSN network through the PDU session establishment procedure, and the PDU session and DS-TT ports have been determined for the talker and listener.

Referring to fig. 5, in operation 210, the listeners UE 107B, 107C may forward a request to join the multicast group sent from the listener end stations 103B, 103C to the network so that the network may determine a first group of listeners UE that are intended to join the multicast group. An example of operation 210 is shown in fig. 6. Referring to fig. 6, in operation 212, the listener end stations 103B, 103C may be preconfigured with group addresses of a plurality of multicast groups, such as ethernet group MAC addresses. Then, in operation 214, the listener end stations 103B, 103C may send a request to join the multicast group, e.g., to the UPF 105 via the respective listener UEs 107B, 107C, and the request may contain a group address, such as an ethernet group MAC address, of the multicast group that the listener end stations 103B, 205C want to join. In some embodiments, the request may be sent via a Multiple MAC Registration Protocol (MMRP) message. MMRP is a protocol that allows an end station to dynamically register group membership or single MAC address information with a bridge, and it may be considered a definition that a network entity such as an end station or bridge registers as a member of a multicast group.

In operation 216, when the UPF 105 receives a request from one or more listener UEs, such as listener UEs 107B, 107C, it may extract information contained in the request, such as information representing the group address of the multicast group, and send the extracted information along with the corresponding UE ID and DS-TT port number, such as SUPI, to a Control Plane (CP) Network Function (NF), such as SMF 112, PCF 113, or TSN AF 115. In some embodiments, the UPF 105 may alternatively forward the request to the CP NF, and the CP NF will extract the relevant information from the request. The SMF 112, PCF 113, or TSN AF 115 may then collect the group address extracted from the request in operation 218 to determine the first group of listeners UE to join the multicast group. In some embodiments, CP NFs such as SMF 112, PCF 113, or TSN AF 115 may also maintain (e.g., establish or update) and store group binding information that binds the multicast group with the first group of listener UEs. Fig. 7 illustrates an example of control information including group binding information maintained in 5GS, according to some embodiments. Referring to fig. 7, the group binding information may include 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, such that the SMF 112, PCF 113, or TSN AF 115 may query and update the group binding information in the database.

Referring back to fig. 5, at operation 220, a talker UE, such as talker UE 107A, may forward talker advertisement claims transmitted from talker end station 103A to a multicast group. In some embodiments, the talker advertisement claims may be sent via a Multicast Stream Registration Protocol (MSRP) message. MSRP is a protocol defined by IEEE for network resource reservation of flows with QoS requirements, which also specifies which network entity to listen to a particular flow. The talker advertisement claims may include a flow ID of the TSC flow, qoS information such as a traffic specification for the TSC flow (TSCpec), and a destination address of the TSC.

Upon receiving the talker advertisement claims in operation 220, the 5GS will process the talker advertisement and extract relevant information from the talker advertisement claims, such as stream ID, qoS information, and destination address. In some embodiments, the CP NF or UP NF performs the process. Then, in operation 222, a CP NF, such as SMF 112, PCF 113, or TSN AF 115, may query the group binding information for a group address matching the target address in the talker advertisement claims. If a group address matching the target address of the talker advertisement claims is identified, SMF 112, PCF 113, or TSN AF 115 may determine to route the talker advertisement claims to the first group of UEs that have joined the multicast group with the group address. For example, TSN AF 115 may determine a PDU session and DS-TT port for the first group of listener UEs and forward such information to SMF 112 via PCF 113.

In some embodiments, operation 210 may be omitted. In such a case, speaker UE 107A would forward the speaker advertisement claims from speaker 103A to a TSN bridge, such as 5GS TSN bridge 104A to which speaker UE 107 connects. Since operation 210 is omitted and the 5GS TSN bridge 104A does not register a group MAC address on its port or ports via an MMRP message, the 5GS TSN bridge 104A will distribute talker advertisement claims to all its active outbound ports in the Spanning Tree Protocol (STP) domain. That is, the 5GS TSN bridge 104A will distribute the talker advertisement claims from talker 103A to the individual UEs connected to the active outbound port of the 5GS TSN bridge 104A deployed in the same VLAN as talker 103A.

The 5GS TSN bridge 104A may then forward the talker advertisement claims received from the talker UE 107A to a first group of listeners UE, such as listeners UE 107B, 107C, which in turn forward the talker advertisement claims to the listener end stations 103B, 103C via respective DS-TT ports in operation 230. As described above, the first set of listener UEs may include UEs as follows: a UE that has joined the multicast group identified by a group address that matches a target address contained in the talker advertisement claims; or a UE connected to an active outbound port of a bridge that receives a talker advertisement announcement from talker UE 107A and is disposed in the same VLAN as talker 103A.

In operation 240, a first group of listeners UE, such as listeners UE 107B, 107C, may forward MSRP listener claims sent from respective listener end stations 103B, 103C to the talker UE107A in response to talker advertisement claims received from the talker UE107A. Examples of listener declarations may include listener readiness and listener query failure. If the listener end station is ready to receive the TSN stream specified in the talker advertisement claims and the resources on the path from the talker to the listener can guarantee that the transmission of the TSN stream has the required quality of service (QoS), the listener should send a listener ready claim. If the listener end station receives a talker failure statement due to, for example, a resource reservation problem along the path from the listener to the listener, and the listener end station is ready to receive the stream, it should send a listener query failure statement. In some embodiments, the listener declaration may include a stream ID, a direction of the stream, e.g., to the listener, and a declaration type indicating whether the listener is ready to receive the TSN stream specified in the talker advertisement declaration.

In some embodiments, if listeners are ready to receive the TSN stream, they may post VLAN membership claims via a multi-VLAN registration protocol (MVRP) message before sending the listener claims. The MVRP VLAN membership declaration may contain a VLAN ID (VID) included in the dataframe parameters of the talker advertisement declaration and VLAN registration will be performed for the listener in the Spanning Tree Protocol (STP) domain. It should be appreciated that the MSRP and MMRP signaling mentioned in the embodiments may be performed in the context of VLANs.

Then, in operation 242, a CP NF, such as SMF 112, PCF 113, or TSN AF 115, may determine a second set of listener UEs (and associated DS-TT ports) from the first set of listener UEs that sent listener ready announcements for the TSN stream identified in the talker advertisement announcements. Obviously, the second group is a subset of the first group. In some embodiments, SMF 112, PCF 113, or TSN AF 115 may maintain (e.g., establish or update) flow binding information to bind the TSN flow with the second set of listener UEs. Examples of flow binding information, as shown in fig. 7, may include a 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 listener UEs of the second group, a flow ID of the TSN flow, a VLAN ID (VID), and flow QoS information (TSpec). In some embodiments, when the CP NF determines to route the talker advertisement claims to the first group of listener UEs, the CP NF may establish preliminary flow binding information including a list of UEs in the first group in operation 222, and then update the preliminary flow binding information with the list of UEs in the second group and the list of corresponding DS-TT port numbers when the second group of listener UEs is determined in operation 242. In some embodiments, a flow ID, VID, and flow QoS information (TSpec) for the TSN flow is created in operation 222. In some embodiments, as shown in fig. 7, a first set of listener UEs may receive and respond to multiple talker advertisement claims from one or more talkers advertising multiple TSN streams for a multicast group, and may then maintain multiple pieces of stream binding information for the multicast group. It should be appreciated that the second set of UEs included in one piece of stream binding information may be the same as or at least partially different from another second set of UEs included in another piece of stream binding information.

When the second set of listener UEs and associated DS-TT ports are determined in operation 242, the multicast range of the TSN streams from talker to listener is determined. A CP NF, such as SMF 112, PCF 113, or TSN AF 115, may then maintain (e.g., establish or update) the TSC multicast session context and TSC multicast QoS flow information for the second group of listener UEs in operation 250. The CP NF may maintain a TSC multicast session context for each TSC multicast session, and the TSC multicast session is a set of TSC multicast QoS flows for the multicast group. That is, the PDUs carrying the user payloads of the TSC multicast QoS flows belonging to the TSC multicast session context have the same destination address (i.e., group address of the multicast group). A QoS Flow Identifier (QFI) may be assigned to a TSC multicast QoS flow. It should 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 thus the number S1 of TSN streams is equal to or greater than the TSC multicast sessionNumber S2. One TSC multicast session may include multiple (S3 in fig. 7) TSC multicast QoS flows and one or more TSN flows may be transmitted on one multicast QoS flow. Thus, the number of TSN flows S1, the number of TSC multicast sessions S2 and the number of TSC multicast QoS flows S3 satisfy the following relationship: s1 is more than or equal to S2,

Referring to fig. 7, the tsc multicast session context may include a session context ID, a group address, an anchor UPF ID of the talker UE, a list of listener UEs in the second group, and a list of DS-TT port numbers associated with the listener UEs of the second group. The TSC multicast QoS flow information may include a multicast QoS Flow ID (QFI), a PDU session ID and/or MAC address of the talker UE, a group address, a list of listener UEs in the second group, a list of DS-TT port numbers associated with the listener UEs of the second group, a flow ID, a VLAN ID, and a flow QoS requirement (TSpec). It should be appreciated that the above control information including group binding information, flow binding information, TSC multicast session context, and TSC multicast QoS flow information may be stored in a CP NF such as SMF 112, PCF 113, or TSN AF 115, or in UDR 114. In some embodiments, a CP NF, such as SMF 112, PCF 113, or TSN AF 115, may further maintain (e.g., establish or update) the association between the control information shown in fig. 7. For example, the CP NF may maintain associations of TSN flows, TSC multicast sessions, and TSC multicast QoS flows. This is required when the control information is stored in a different entity. For example, when a TSC multicast session context is stored in UDR 114 and TSC multicast QoS flow information is stored in SMF 112, SMF 112 may retrieve information for one or more QoS flows corresponding to the TSC multicast session from UDR 114 using an association between the TSC multicast QoS flow and the TSC multicast session.

When the TSC multicast session context and the TSC multicast QoS flow information are determined, a TSC multicast session and a TSC multicast QoS flow may be established for the TSN flow in operation 260. By indicating the TSC multicast session context ID, the TSC multicast QoS Flow ID (QFI), and the second group of listener UEs to one or more base stations, such as the gNB 110B in fig. 4, the procedure for establishing the TSC multicast session and the TSC multicast QoS flow may be triggered at the 5GC-CP, such as the SMF112, PCF 113, or TSN AF 115. An example of a process for establishing a TSC multicast session and a TSC multicast QoS flow is shown in fig. 8.

Referring to fig. 8, in operation 262, TSC multicast sessions and QoS establishment procedures may be triggered at 5GC-CP, e.g., SMF112, by sending a multicast registration request for a second group of listeners, UEs 107B, 107C, to the gNB 110B. The multicast registration request may include parameters of the multicast session and QoS flows such as a multicast session context ID, a group MAC address, a multicast QFI, a list of UEs, and a list of DS-TT port numbers. It should be appreciated that the multicast registration request may be forwarded to the gNB 110B via the AMF 111. For example, SMF112 may send a namf_communication_n1n2messagetransfer message to AMF 111 that includes the multicast registration request, and AMF 111 may forward the request to gNB 110B via the N2 message. In some embodiments, the procedure for establishing a TSC multicast session and TSC multicast QoS flows may be triggered at PCF 113 or TSN AF 115. For example, PCF 113 may trigger the procedure by sending a PCF-initiated SM (session management) policy association modification message to SMF112 that includes multicast registration parameters, or TSN AF 115 may trigger the procedure by sending a QoS mapping request to PCF 113 and then to SMF112 that includes multicast registration parameters.

In 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 RAN, such as the gNB110B, connecting the second group of listener UEs for forwarding the flow traffic of the one or more TSC multicast QoS flows from the anchor UPF to the RAN.

When the gNB110B receives the multicast registration parameters, the gNB110B may reserve resources and set up links for the multicast session and QoS flows. In operation 264, the gNB110B may establish one or more radio bearers, such as Data Radio Bearers (DRBs), for the TSC multicast QoS flows of the one or more listener UEs in the second group. In some embodiments, the gNB110B may establish a shared radio bearer for the second group of listener UEs, or it may establish multiple unicast radio bearers for each listener UE. Further, the user plane configuration information received in operation 262 may be applied between the anchor UPF of the talker 103A and the RAN connecting the second set of listeners UE.

In operation 266, the gNB110B may further report the setup status of the one or more radio bearers for the TSC multicast QoS flows of the one or more listener UEs. For example, if the radio bearer is successfully established, in operation 266a, the gNB110B may send a multicast registration response to the SMF 112 via the AMF 111. The multicast registration response may include a multicast QoS Flow ID (QFI). Alternatively, if the gNB110B fails to establish one or more radio bearers for the multicast QoS flows for one or more listener UEs in the second group, then in operation 266B, the gNB110B may report to the 5GC-CP a failure to establish one or more radio bearers for the TSC multicast QoS flows of the one or more listener UEs. For example, the gNB110B may transmit 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 that did not successfully establish the radio bearer, and a DS-TT port number of the at least one listener UE. The SMF 112 (or PCF 113, TSN AF 115) may then update the parameters of the multicast control information in local memory or stored in UDR 114. For example, SMF 112 may remove the UE and associated DS-TT port number from the flow binding information, TSC multicast session context, and TSC multicast QoS flow information.

Referring back to fig. 5, in operation 270, a 5G-CP, such as SMF 112, PCF 113, or TSN AF 115, may configure resources for an Uplink (UL) TSC QoS flow of talker 103A. In some embodiments, the resource configuration of UL TSC QoS flows may be achieved through a PDU session modification procedure.

When the resource configuration is successfully performed, the listener declaration may be forwarded to speaker 103A in operation 280. In some embodiments, the listener declaration may be processed in the control plane or user plane and then the processing results sent to speaker 103A.

In operation 290, a 5GC-CP, such as SMF 112, PCF 113, or TSN AF 115, may further configure rules in the anchor UPF105 of talker 103A for forwarding TSN streams with specific source MAC addresses and/or destination MAC addresses from the anchor UPF105 of talker 103A to a second set of listeners UE 107B, 107C, and finally to 103B, 103C via established TSC multicast QoS streams. For example, the rules may include data forwarding rules, such as Packet Detection Rules (PDR) and Forwarding Action Rules (FAR). With such rules, the UPF105 will detect and receive TSN stream traffic data received from talker 103A having a particular source MAC address and/or destination MAC address in operation 292 and forward the detected TSN stream data to a second set of listeners UE 107B, 107C and ultimately to listeners 103B, 103C via the assigned one or more TSC multicast QoS streams in operation 294.

It should be appreciated that the 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 connected to a UE in the first and/or second group of UEs may request to exit receiving an existing TSN stream. For another example, the talker may decide to provide a new TSN stream or to stop an existing TSN stream. Thus, in addition to establishing control information when establishing the first and/or second set of listeners UE, the operations described above to maintain control information for the multicast group may further include updating the control information in response to changes in the TSN streams and the first and/or second set of listeners UE, e.g., adding parameters to the control information when a new listener UE joins the first and/or second set of listeners UE and/or advertises a new TSN stream; when the listener UEs exit the first and/or second group of listener UEs and/or the existing TSN stream stops, the parameters are removed from the control information. For example, when a new UE requests to join a 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 talker advertisement claims to the first group of listeners UE. When the new UE responds to the talker advertisement claims with a listener ready claim, the 5GC-CP may add the new listener UE to the second group by adding parameters of the new listener UE to the flow binding information, the TSC multicast session context, and the TSC multicast QoS flow information. The new listener UE may then be mapped to a new or existing TSC multicast session and QoS flow and receive the TSN flow from the talker over the QoS flow. When a listener UE in the second group exits the second group, the 5GC-CP may remove parameters of the listener UE from the flow binding information, TSC multicast session context, and TSC multicast QoS flow information. At this point in time, the listener UE may still be in the first group. The 5GC-CP may also remove parameters of the listener UE from the group binding information if the listener UE exits the first group. In this way, the first group of listeners UE and the second group of listeners UE may be dynamically changed.

The operation at the various network devices, network functions and terminal devices will now be discussed in more detail with reference to fig. 9-16. It should be appreciated that some details of the operation at the various devices/functions may have been discussed above with reference to the network shown in fig. 4 and the process shown in fig. 5, and thus will be briefly described below. For a better understanding, the following description may be read with reference to the description above with respect to fig. 3-8.

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

Referring to fig. 9, the method 300 optionally includes a step 310, where step 310 is determining a first group of listeners UE joining the multicast group identified by the group address. As described above, for example, the 5GC-CP NF may determine the first group of listener UEs based on a request to join the multicast group received from the first group of listener UEs via a UPF such as UPF 105.

In step 320, the 5GC-CP NF may determine from the first group of listeners UE a second group of listeners UE that are ready to receive TSN streams for the multicast group. For example, the 5GC-CP NF may determine the second set of listeners UE based on listener assertions received from one or more of the first set of listeners UE. The first group of listeners UE may send a listener announcement in response to a talker advertisement announcement received from a talker, the announcement stating that the talker provides a TSN stream for the multicast group. Examples of listener declarations may include, but are not limited to, listener readiness and listener query failure. The 5GC-CP may determine that UEs connected to listeners that respond with listeners ready to fall into the second group.

With step 310 omitted, the TSN bridge receiving the talker advertisement claims from the talker will distribute talker advertisements on the active outbound port of the TSN bridge in the Spanning Tree Protocol (STP) domain (e.g., in the talker's VLAN domain). Then, UEs connected to the active outbound port of the bridge in the STP domain (e.g., deployed in the same VLAN as the talker) may be considered a first set of listener UEs. Based on listener readiness declarations sent from such UEs in response to talker advertisement declarations, the 5GC-CP NF may determine a second group of listener UEs that are ready to receive TSN streams provided by talkers for the multicast group.

When a talker providing a TSN stream and a second set of listeners UE receiving the TSN stream are identified, the multicast range 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, stream binding information for binding the multicast group with the second group of listener UEs, TSC multicast session context indicating TSC multicast sessions for TSN streams, TSC multicast QoS stream information indicating TSC multicast QoS streams for TSN streams, and associations between the above information for the first and/or second group of UEs. Example parameters of the control information have been described in detail above with reference to fig. 7, and repeated descriptions thereof are omitted herein.

The control information may be maintained in a separate operation. For example, group binding information may be established when a first group of listener UEs is determined, flow binding information may be established when a second group of listener UEs is determined, and TSC multicast session context and TSC multicast QoS flow information may be established after the flow binding information is established. The control information may be further updated in response to a change in the multicast group. For example, when a new listener UE joins the first group and/or the second group, parameters of the new listener UE may be added to the control information. When the listener UE exits the first and/or second group, parameters of the listener UE may be removed from the control information.

The method 300 may further include a step 340 of triggering a process of establishing a TSC multicast session and a TSC QoS flow for the TSN flow based on the TSC multicast session context and the TSC multicast QoS flow information. In some embodiments, the 5GC-CP NF may trigger the setup 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 setup procedure by sending a QoS mapping request to the PCF, or the PCF may trigger the setup procedure by sending a session management policy association modification message to the SMF, or the SMF may trigger the setup procedure via the AMF by transmitting a multicast registration request to one or more base stations providing network access for a second set of listener UEs. It should be appreciated that a TSC multicast session may include multiple TSCs multicasting QoS flows and that one or more TSN flows may be transmitted on the QoS flows. In some embodiments, the 5GC-CP NF may further provide user plane configuration information to the anchor UPF of the talker and the RAN connecting the second group of listeners UE for forwarding the flow traffic of the one or more TSC multicast QoS flows from the anchor UPF to the RAN. Details of the setup process have been discussed above with reference to fig. 8, and a repeated description thereof is omitted here.

If a TSC multicast session and TSC multicast QoS flows are successfully established for the TSN flows, then in step 350, the 5G-CP may configure rules in the anchor UPF of the talker UE for forwarding the TSN flows from the talker UE to the second group of listeners UE via the established TSC multicast QoS flows. 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 forwards the TSN stream traffic data to the RAN connecting the second set of listeners UE and eventually to the listeners.

In some embodiments, if the TSC multicast QoS flow fails to be established, for example, when the base station and/or listener UE does not have available resources that meet 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 UEs that fail to establish QoS flows and their DS-TT port numbers from the second group of listener UEs, or may also remove 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 a TSN network integrated with 5GS as one or more bridges. The TSN network may have a fully distributed configuration model. The method 400 may be performed by a 5GC-UP network function, such as a UPF, e.g., UPF 105 shown in fig. 4. For example, the steps of method 400 may be performed by means, modules or elements of a device implemented at a 5GC-UP network function.

Referring to fig. 10, the method 400 may optionally include a step 410 of receiving a request from a first group listener UE to join a multicast group identified by a group address. For example, as described above with reference to fig. 6, the UPF 105 may receive a request carried in an MMRP message. In some embodiments, step 410 may be omitted.

The method 400 may also include step 420 of forwarding the talker advertisement claims received from the talker to the first group of listeners UE. The talker advertisement claims may indicate that the talker provides TSN streams for the multicast group and has a target address that matches the group address of the multicast group. The first group of listener UEs may be determined to be UEs that have joined the multicast group. For example, the first group listener UE may be determined by querying group binding information binding the group address with the first group listener UE. In some embodiments where step 410 is omitted and no listener UE issues a request to join the multicast group, the talker advertisement claims received from talkers may be forwarded in step 420 to a first group of listeners UE connected to an active outbound port of a bridge in the STP domain to which the talker is connected.

In step 430, the UPF may forward the listener claims received from one or more of the first set of listeners UE to the talker. One or more of the first set of listeners UE may send a listener claim to the talker in response to a talker advertisement claim received from the talker. The listener declaration may indicate whether 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 the RAN connecting the second group of listeners UE ready to receive the TSN stream. The second group is a subset of the first group and may be determined based on listener assertions received from one or more of the first group of UEs. Rules for forwarding TSN flows may include, 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 may detect the traffic data in the TSN stream based on the PDR and FAR rules and forward it to the RAN connecting the second set of listener UEs.

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

Referring to fig. 11, the method 500 may include a step 510 of receiving a multicast registration request from a core network, e.g., from an SMF. The multicast registration request may include, for example, a TSC session context ID, qoS flow information, a list of listener UEs in the second group, and an associated DS-TT port number.

The method 500 may further comprise step 520 of establishing one or more radio bearers, e.g. Data Radio Bearers (DRBs), for TSC multicast QoS flows of 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 one or more listener UEs, or the base station may establish one unicast radio bearer for each listener UE.

The method 500 may further comprise a step 530 of reporting the setup state of the one or more radio bearers to the core network. For example, the gNB110B may send a multicast registration response when one or more radio bearers are successfully established, or the gNB110B may send a multicast registration failure message when the gNB110B fails to establish one or more radio bearers for the multicast QoS flow for one or more listener UEs in the second group. From the failure report, the core network learns that one or more listener UEs cannot receive the TSN stream and may remove the one or more listener UEs from the second group.

Fig. 12 is an example flow chart illustrating a method 600 for multicast service support in a TSN network integrated with 5GS as one or more bridges. The TSN network may have a fully distributed configuration model. The method 600 may be performed by a terminal device, such as the listener UE 107B or 107C shown in fig. 4. For example, the steps of method 600 may be performed by an apparatus, module, or element of a device implemented at a network device.

Referring to fig. 12, method 600 optionally includes step 610 forwarding a request to join a multicast group identified by a group address received from a listener connected to a listener UE to a network. For example, the listener may be preconfigured with a plurality of 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 through an MMRP message.

In step 620, the listener UE may forward the speaker advertisement claims received from the speaker to the listener. The talker advertisement claims indicate that the talker provides TSN streams for the multicast group and may include a destination address that matches the group address of the multicast group.

In response to the speaker advertisement claims, the listener may send a listener ready claim to the speaker indicating that the listener is ready to receive the TSN stream from the speaker. In step 630, the listener UE may forward the listener declaration to the speaker.

To the listener receiving the TSN stream from the talker, a TSC multicast QoS stream and associated radio bearers will be established for the listener UE's TSN stream. Then, in step 640, the listener UE may forward the multicast transmission of the TSN stream received from the talker to the listener over the radio bearer established for the listener's TSC multicast QoS stream. The TSN stream is provided from the talker to a multicast group identified by the destination address of the TSN stream to which the listener has joined.

Fig. 13 illustrates a block diagram of an example communication system 700 in which embodiments of the present disclosure may be implemented. For example, as shown in fig. 4, communication system 700 may be integrated as one or more virtual bridges in a TSN network. The communication system 700 may include a User Equipment (UE) 710, a network function 730, and a network device 720, the network device 720 in communication with the UE 710 via an air link and in communication with the network function 730 via a backhaul connection 728. UE 710 may be implemented as UE 107A, 107B, or 107C described above, network device 720 may be implemented as base station 110A or 110B discussed above, and 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 include one or more processors 711, one or more memories 712, one or more transceivers 713, and one or more communication interfaces 717, interconnected by 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 a series of lines on a motherboard or integrated circuit, optical fibers, optical or other optical communication devices, etc. Each of the one or more transceivers 713 may include a receiver and a transmitter connected to one or more antennas 716. The UE 710 may communicate wirelessly with a network device 720 via one or more antennas 716. One or more communication interfaces 717 may provide a wired or wireless communication link by which the UE 710 can communicate with other devices, entities, elements, or functions. For example, UE 710 may communicate with one or more TSN end stations or neighboring TSN bridges via 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, when executed by the one or more processors 711, to cause the UE 710 to perform the processes and steps described above in connection with the UE 107.

Network device 720 may include one or more processors 721, one or more memories 722, one or more transceivers 723, and one or more communication interfaces 727 interconnected by one or more buses 724. The one or more buses 724 may be an address, data, or control bus, and may include any interconnection mechanism, such as a series of wires on a motherboard or integrated circuit, fiber optics, or other optical communications device, etc. Each of the one or more transceivers 723 may include a receiver and a transmitter coupled to one or more antennas 726. The network device 720 may operate as a BS for the UE 710 and communicate wirelessly with the UE 710 through one or more antennas 726. One or more of the communication interfaces 727 can provide a wired or wireless communication link by which the network device 720 can communicate with other network devices, entities, elements, or functions. The one or more memories 722 may include computer program code 725. Network device 720 may communicate with network function 730 via backhaul connection 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 the processes and steps related to BS 110 as described above.

The network functions 730 may include one or more processors 731, one or more memories 732, and one or more communication interfaces 737 interconnected by 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 communications device, etc. The network function 730 may operate as a core network function in a control plane or user plane and may communicate with the BS 720 by wire or wirelessly through one or more links. One or more communication interfaces 737 may provide a wired or wireless communication link through which network function 730 can 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, when executed by the one or more processors 731, to cause the network function 730 to perform processes and steps related 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 may be of any suitable type for a local technology network, and may include general purpose processors, special purpose processors, microprocessors, digital Signal Processors (DSPs), one or more processors in a processor-based multi-core processor architecture, as well as special purpose processors such as Field Programmable Gate Arrays (FPGAs) and Application Specific Integrated Circuit (ASIC) based development. The one or more processors 1011, 1021, and 1031 may be configured to control and operate in cooperation with other elements of the UE/network device/network element to implement the above-described processes.

The one or more memories 712, 722, and 732 may include various forms of at least one storage medium, such as volatile memory and/or nonvolatile memory. Volatile memory can include, for example, random Access Memory (RAM) or cache memory, but is not limited to. The non-volatile memory may include, but is not limited to, for example, read Only Memory (ROM), hard disk, flash memory, and the like. Further, the one or more memories 712, 722, and 732 may include, but are not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof.

It should be understood that the blocks in the figures may be implemented in various ways including software, hardware, firmware, or any combination thereof. In some embodiments, one or more of the blocks may be implemented using software and/or firmware, such as machine executable instructions stored on a storage medium. Some or all of the blocks in the figures may be implemented, at least in part, by one or more hardware logic components in addition to or in place of machine-executable instructions. For example, but not limited to, exemplary types of hardware logic that may be used include Field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems On Chip (SOCs), complex Programmable Logic Devices (CPLDs), and the like.

Some example embodiments also provide computer program code or instructions that, when executed by one or more processors, may cause an apparatus or device to perform the above-described processes. Computer program code for carrying out processes for 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 processors or controllers, causes the implementation of the functions/operations specified in the flowchart and/or block diagram. The program code may execute entirely on the 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 computer or server.

Some example embodiments further provide a computer program product or a computer readable medium having computer program code or instructions stored therein. A computer readable medium may be any tangible medium that can 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. The 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 a 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.

Moreover, although operations are described in a particular order, this should not be construed 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 some cases, multitasking and parallel processing may be advantageous. Also, while in the foregoing discussion contains several specific implementation details, these should not be construed as limitations on the scope of the 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 can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example of implementing the claims.

Claims (40)

1. A method for multicast service support in a Time Sensitive Network (TSN), comprising:

Determining from the first set of listener user equipments UE a second set of listener UEs ready to receive TSN streams for the multicast group; and

triggering the establishment of a TSC multicast session and a TSC multicast QoS stream for the second group of listener UEs to receive the TSN stream.

2. The method of claim 1, further comprising, prior to determining the second set of listeners UE:

the first group of listener UEs is determined based on a request to join a multicast group identified by a group address received from the first group of listener UEs.

3. The method of claim 1, wherein the first set of listener UEs includes UEs connected to active ports of bridges in the TSN network that receive talker advertisement claims from talkers and are deployed with the talkers in a Virtual Local Area Network (VLAN), the talker advertisement claims instructing the talkers to provide the TSN streams for the multicast group.

4. The method of claim 1, wherein the second set of listeners is determined based on listener declarations received from one or more of the first set of listeners UE indicating whether the one or more of the first set of listeners UE are ready to receive the TSN stream.

5. The method of claim 4, wherein the listener declaration is transmitted from one or more of the first set of listener UEs in response to a talker advertisement declaration from a talker, the talker advertisement declaration indicating that the talker provides the TSN stream for the multicast group.

6. The method of claim 1 or 2, further comprising maintaining control information for the multicast group, the control information including one or more of:

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

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

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

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

the association between the above information for the first and/or second set of UEs.

7. The method of claim 6, wherein,

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

The flow binding information includes 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 flow ID, VLAN ID and flow QoS information,

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

the TSC multicast QoS flow information includes one or more of a multicast QoS Flow ID (QFI), a PDU session ID and/or MAC address of the talker, the group address, a list of listener UEs in the second group, a list of DS-TT port numbers associated with the listener UEs of the second group, the flow ID, the vlan ID, and the flow QoS information.

8. The method of claim 7, wherein triggering establishment of a TSC multicast session and a TSC multicast QoS stream for the second group of listener UEs to receive the TSN stream comprises:

indicating to one or more Radio Access Networks (RANs) connected for the second set of UEs at least one of: the second set of UEs, associated port numbers, the session context IDs, and QoS flow information; and

Configuration information is provided to the anchor UPF and the RAN for forwarding flow data of one or more of the TSC multicast QoS flows from the anchor UPF to the RAN.

9. The method of claim 6, wherein maintaining control information for the multicast group comprises:

when the first group of listeners UE and/or the second group of listeners UE are determined, establishing control information for the multicast group;

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

The parameters are removed from the control information when the listener UE exits from the second set of UEs and/or the first set of UEs and/or the TSN flow stops.

10. The method of claim 6, wherein the TSC multicast session comprises a plurality of TSC multicast QoS flows for forwarding a plurality of TSN flows from one or more talker UEs to the second group of listener UEs via an anchor UPF represented by the anchor UPF ID.

11. The method of claim 6, further comprising:

in case the establishment of the TSC multicast QoS flow for the TSC flow fails, updating parameters of the group binding information, the flow binding information, the TSC multicast session context and/or the TSC multicast QoS flow information.

12. The method of claim 1, further comprising:

rules are configured in the anchor UPF of a talker UE for forwarding the TSN stream from the talker UE to a second group of listeners UE via the established TSC multicast QoS stream.

13. A method for multicast service support in a Time Sensitive Network (TSN), comprising:

forwarding a talker advertisement announcement received from a talker to a first group of listeners UE, the talker advertisement announcement indicating that the talker provides a TSN stream for a multicast group identified by a group address;

forwarding listener assertions received from one or more of the first set of listeners UE to the talker, the listener assertions indicating whether the one or more of the first set of listeners UE are ready to receive the TSN stream; and

rules are applied for forwarding traffic data of the TSN stream received from the talker to a second set of listeners UE ready to receive the TSN stream.

14. The method of claim 13, further comprising, prior to forwarding the talker advertisement claims:

a request to join the multicast group is received from the first group of listener UEs.

15. A method for multicast service support in a Time Sensitive Network (TSN), comprising:

Receiving, at a Base Station (BS), a multicast registration request from a Core Network (CN) Network Function (NF), the multicast registration request including one or more of a Time Sensitive Communication (TSC) session context ID, qoS flow information, a second group of UEs, and related port numbers;

establishing, at the BS, one or more radio bearers for Time Sensitive Communication (TSC) multicast QoS flows for one or more listener UEs in the second group based on the received multicast registration request; and

the set-up status of one or more radio bearers for the TSC multicast QoS flows of one or more listener UEs is reported to the CN NF.

16. A method for multicast service support in a Time Sensitive Network (TSN), comprising:

at a listener User Equipment (UE), a multicast transmission of a time sensitive communication (TSN) stream received from a talker is forwarded to the listener over a radio bearer established for a TSC multicast QoS stream for the listener, the TSN stream being provided from the talker to a multicast group identified by a destination address of the TSN stream the listener UE has joined.

17. 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:

Determining, from a first set of listener User Equipments (UEs), a second set of listener UEs ready to receive Time Sensitive Network (TSN) streams for the multicast group; and

the method includes triggering a Time Sensitive Communication (TSC) multicast session and establishment of a TSC multicast quality of service (QoS) stream for a second group of listener UEs to receive the TSN stream.

18. 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:

the first group of listeners UE is determined based on a request to join the multicast group identified by a group address received from the first group of listeners UE before the second group of listeners UE is determined.

19. The network function of claim 17, wherein the first set of listener UEs includes UEs connected to active ports of bridges in the TSN network that receive talker advertisement claims from talkers and are deployed with the talkers in a Virtual Local Area Network (VLAN), the talker advertisement claims indicating that the talkers provide the TSN streams for the multicast group.

20. The network function of claim 17, wherein the second set of listener UEs is determined based on listener declarations received from one or more of the first set of listener UEs indicating whether the one or more of the first set of listener UEs are ready to receive the TSN stream.

21. The network function of claim 20, wherein the listener declaration is transmitted from one or more of the first set of listener UEs in response to a talker advertisement declaration from a talker, the talker advertisement declaration instructing the talker to provide the TSN stream for the multicast group.

22. 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 including one or more of:

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

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

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

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

the association between the above information for the first and/or second set of UEs.

23. The network function of claim 22, wherein,

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

the flow binding information includes 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 flow ID, VLAN ID and flow QoS information,

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

the TSC multicast QoS flow information includes one or more of a multicast QoS Flow ID (QFI), a PDU session ID and/or MAC address of the talker, the group address, a list of listener UEs in the second group, a list of DS-TT port numbers associated with the listener UEs of the second group, the flow ID, the vlan ID, and the flow QoS information.

24. 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 TSC multicast sessions and TSC multicast QoS flows by:

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

configuration information is provided to the anchor UPF and the RAN for forwarding flow data of one or more of the TSC multicast QoS flows from the anchor UPF to the RAN.

25. 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:

when the first group of listeners UE and/or the second group of listeners UE are determined, establishing control information for the multicast group;

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

Parameters are removed from the control information when listener UEs exit from the second set of UEs and/or the first set of UEs and/or TSN flow ceases.

26. 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 flows from one or more talker UEs to the second group of listener UEs via an anchor UPF represented by the anchor UPF ID.

27. 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:

in case the establishment of the TSC multicast QoS flow for the TSC flow fails, updating parameters of the group binding information, the flow binding information, the TSC multicast session context and/or the TSC multicast QoS flow information.

28. 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:

rules are configured in an anchor UPF of a talker UE for forwarding the TSN stream from the talker UE to the second group of listeners UE via an established TSC multicast QoS stream.

29. 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:

forwarding a talker advertisement announcement received from a talker to a first group of listeners UE, the talker advertisement announcement indicating that the talker provides a Time Sensitive Network (TSN) stream for a multicast group identified by a group address;

forwarding listener assertions received from one or more of the first set of listeners UE to the talker, the listener assertions indicating whether the one or more of the first set of listeners UE are ready to receive the TSN stream; and

rules are applied for forwarding traffic data of the TSN stream received from the talker to a second set of listeners UE ready to receive the TSN stream.

30. 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:

a request to join the multicast group is received from the first set of listener UEs before forwarding the talker advertisement claims.

31. 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:

receiving a multicast registration request including one or more of a Time Sensitive Communication (TSC) session context ID, qoS flow information, a second set of UEs, and associated 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 to the CN NF an established state of one or more radio bearers for the TSC multicast QoS flows of one or more listener UEs.

32. 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:

multicast transmissions of Time Sensitive Network (TSN) streams received from a talker are forwarded to a listener over a radio bearer established for a TSC multicast QoS stream for the listener, the TSN streams being provided from the talker to a multicast group identified by a destination address of a TSN stream that the listener UE has joined.

33. An apparatus for multicast service support in a Time Sensitive Network (TSN), comprising:

means for determining, from a first set of listener User Equipments (UEs), a second set of listener UEs ready to receive TSN streams for the multicast group; and

means for triggering a TSC multicast session and establishment of a TSC multicast QoS stream for the second group of listener UEs to receive the TSN stream.

34. An apparatus for multicast service support in a Time Sensitive Network (TSN), comprising:

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

means for forwarding a listener declaration received from one or more of the first set of listeners UE to the talker, the listener declaration indicating whether the one or more of the first set of listeners UE 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 set of listeners UE ready to receive the TSN stream.

35. 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 from a Core Network (CN) Network Function (NF), the multicast registration request including one or more of a Time Sensitive Communication (TSC) session context ID, qoS flow information, a second set of UEs, and related port numbers;

means for establishing, at the BS, one or more radio bearers for Time Sensitive Communications (TSC) multicast QoS flows for one or more listener UEs in the second group based on the received multicast registration request; and

means for reporting to the CN NF an established state of one or more radio bearers for the TSC multicast QoS flows of one or more listener UEs.

36. An apparatus for multicast service support in a Time Sensitive Network (TSN), comprising:

means for forwarding, at a listener User Equipment (UE), a multicast transmission of a Time Sensitive Communication (TSC) stream received from a talker to a listener over a radio bearer established for a TSN stream provided from the talker to a multicast group identified by a destination address of the TSN stream to which the listener UE has joined.

37. A computer readable medium having instructions stored thereon, which when executed by at least one processor of a network function in a control plane, cause the network function to perform the method of any of claims 1-12.

38. A computer-readable medium having instructions stored thereon, which, when executed by at least one processor of a network function in a user plane, cause the network function to perform the method of any of claims 13-14.

39. A computer-readable medium having instructions stored thereon, which when executed by at least one processor of a network device, cause the network device to perform the method of claim 15.

40. A computer readable medium having instructions stored thereon, which when executed by at least one processor of a terminal device, cause the terminal device to perform the method of claim 16.

Images