CN114205907A - Multicast service configuration - Google Patents

Abstract

There is provided a method for a network node of a wireless communication network, the method comprising: receiving information from a core network element of the wireless communication network, the information comprising at least one identifier corresponding to at least one data flow of the multicast service and a user equipment, UE, list indicating a group of UEs to which the multicast service is targeted, wherein the information indicates, for a UE on the UE list, a port association between the UE and a port to which data of the at least one data flow is to be forwarded; determining, based on the received information, a multicast service change involving at least one UE of the group of UEs; a notification of a multicast service change is sent to at least one UE to trigger multicast service acquisition.

Description

Multicast service configuration

Technical Field

The following exemplary examples relate to communications.

Background

Modern wireless communication networks support multicast services. In multicasting, one sender may send data to multiple receivers. It may be beneficial to provide a solution that enhances the configuration of multicast services in order to enhance the efficiency of a wireless communication network.

Disclosure of Invention

According to one aspect, the subject matter of the independent claims is provided.

According to an aspect, there is provided a computer program comprising instructions for causing an apparatus to: receiving, by a network node of a wireless communication network, information from a core network element of the wireless communication network, the information comprising at least one identifier corresponding to a data stream of at least one multicast service and a user equipment, UE, list indicating a group of UEs to which the multicast service is targeted, wherein the information further indicates, for the UEs on the UE list, port associations between the UEs and ports to which data of the at least one data stream is to be forwarded; determining, based on the received information, a multicast service change involving at least one UE of the group of UEs; and sending a notification of the multicast service change to at least one UE to trigger multicast service acquisition.

According to an aspect, there is provided a computer program comprising instructions for causing an apparatus to: receiving, by a user equipment, UE, of a wireless communication network, a notification from a network node of the wireless communication network regarding a multicast service change involving the UE, and the multicast service change being determined by the network node based on information received from a core network element of the wireless communication network, the information comprising at least one identifier corresponding to at least one data stream of the multicast service and a UE list indicating a group of UEs to which the multicast service is targeted, the UEs being comprised in said group of UEs, wherein the information further indicates port associations between the UEs and ports to which data of the at least one data stream is to be forwarded; and triggering multicast service acquisition after receiving the notification.

Some embodiments are defined in independent claims.

Embodiments that do not fall within the scope of the claims are not to be construed as examples useful for understanding the present disclosure.

One or more examples of an implementation are set forth in more detail in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.

Drawings

Some embodiments will now be described with reference to the accompanying drawings, in which

Fig. 1A illustrates an example of a wireless communication system to which embodiments may be applied;

fig. 1B illustrates an example of a wireless communication system to which the embodiments may be applied;

FIGS. 2 and 3 illustrate flow diagrams according to some embodiments;

FIGS. 4A and 4B illustrate some embodiments;

FIG. 5 illustrates a signal diagram according to some embodiments;

fig. 6, 7A, 7B, 8 and 9 illustrate some embodiments; and

fig. 10 and 11 illustrate an apparatus according to some embodiments.

Detailed Description

The following embodiments are examples. Although the specification may refer to "an", "one", or "some" embodiment(s) in several places, this does not necessarily mean that such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Individual features of different embodiments may also be combined to provide further embodiments. Furthermore, the words "comprising" and "including" should be understood not to limit the described embodiments to consist of only those features that have been mentioned, but such embodiments may also contain features/structures that are not specifically mentioned.

Hereinafter, various exemplary embodiments will be describedBy way of example of an access architecture to which embodiments may be applied, the radio access architecture is based on long term evolution advanced (LTE-advanced, LTE-a) or new radio (NR, 5G), however, without limiting embodiments to such architectures. Those skilled in the art will recognize that embodiments may also be applied to other types of communication networks with appropriate components by appropriately adjusting parameters and procedures. Some examples of other options for suitable systems are Universal Mobile Telecommunications System (UMTS) radio access network (UTRAN or E-UTRAN), Long Term Evolution (LTE), wireless local area network (WLAN or WiFi), Worldwide Interoperability for Microwave Access (WiMAX),

Personal Communication Services (PCS),

Wideband Code Division Multiple Access (WCDMA), systems using ultra-wideband (UWB) technology, sensor networks, mobile ad hoc networks (MANET), and internet protocol multimedia subsystems (IMS), or any combination thereof.

Fig. 1A depicts an example of a simplified system architecture, showing some units and functional entities, whose implementation may differ from what is shown. The connections shown in FIG. 1A are logical connections; the actual physical connections may differ. It will be apparent to those skilled in the art that the system will typically also include the other functions and structures shown in FIG. 1A.

However, the embodiments are not limited to the systems given as examples, but a person skilled in the art may apply the solution to other communication systems providing the necessary properties.

The example of fig. 1A shows a portion of an exemplary radio access network. Fig. 1 shows that terminal devices or user equipment 100 and 102 are configured for wireless connection over one or more communication channels in a cell with an access node (such as an (e/g) NodeB)104 providing the cell. As defined in the 3GPP specifications, (e/g) NodeB refers to eNodeB or gdnodeb. The physical link from the user equipment to the (e/g) NodeB is called an uplink or reverse link, and the physical link from the (e/g) NodeB to the user equipment is called a downlink or forward link. It should be understood that the (e/g) nodebs or their functions may be implemented by using any entity, such as nodes, servers or access points, suitable for such usage.

A communication network typically comprises more than one (e/g) NodeB, in which case the (e/g) nodebs may also be configured to communicate with each other via wired or wireless links designed for this purpose. These links may be used for signaling purposes, but also for routing data from one (e/g) NodeB to another. (e/g) a NodeB is a computing device configured to control the radio resources of the communication system to which it is coupled. The NodeB may also be referred to as a base station, an access point, or any other type of interface device, including relay stations capable of operating in a wireless environment. (e/g) the NodeB includes or is coupled to a transceiver. A connection is provided from the transceiver of the (e/g) NodeB to an antenna unit, which establishes a bi-directional radio link to the user equipment. The antenna unit may comprise a plurality of antennas or antenna elements. (e/g) the NodeB is also connected to the core network 110(CN or next generation core NGC). Depending on the system, the counterpart on the CN side may be a serving gateway (S-GW, routing and forwarding user data packets), a packet data network gateway (P-GW), for providing connectivity of User Equipment (UE) with external packet data networks, or a Mobility Management Entity (MME), etc.

A user equipment (also referred to as UE, user equipment, user terminal, terminal equipment, etc.) illustrates one type of means for resource allocation and designation on the air interface, and thus any features and user equipment described herein may be implemented using corresponding means, such as a relay node. An example of such a relay node is a base station-oriented layer 3 relay (self-backhauling relay).

User equipment generally refers to portable computing devices, including wireless mobile communication devices with or without Subscriber Identity Module (SIM) operation, including but not limited to the following device types: mobile stations (mobile phones), smart phones, Personal Digital Assistants (PDAs), handheld devices, devices using wireless modems (alarm or measurement devices, etc.), laptop and/or touch screen computers, tablets, game consoles, notebook computers, and multimedia devices. It should be understood that the user equipment may also be a near-exclusive uplink device, an example of which is a camera or camcorder that loads an image or video clip to the network. The user device may also be a device capable of operating in an internet of things network (IoT), such as an industrial IoT (iiot) network, which is a scenario in which objects are provided the ability to transmit data over the network without requiring human-to-human or high quality interaction. The user device may also utilize the cloud. In some applications, the user device may include a small portable device with a radio (such as a watch, headset, or glasses), and the computing is implemented in the cloud. The user equipment (or in some embodiments the third layer relay node) is configured to perform one or more user equipment functions. A user equipment may also be called a subscriber unit, mobile station, remote terminal, access terminal, user terminal, or User Equipment (UE), just to mention a few names or devices. User equipment herein may also refer to a vehicular implementation, such as a vehicular UE. Such terminals may be included and/or communicatively coupled with the vehicle so that they may be understood as part of the vehicle or vehicles.

The various techniques described herein may also be applied to Cyber Physical Systems (CPS) (systems that control cooperating computing elements of physical entities). CPS can implement and utilize a large number of interconnected ICT devices (sensors, actuators, processor microcontrollers, etc.) embedded in physical objects at different locations. Mobile network physical systems are a subcategory of cyber physical systems in which the physical systems in question have inherent mobility. Examples of mobile physical systems include mobile robots and electronic devices transported by humans or animals.

Additionally, although the apparatus is depicted as a single entity, different units, processors, and/or memory units (not necessarily shown in fig. 1A) may be implemented.

5G supports the use of Multiple Input Multiple Output (MIMO) antennas, more base stations or nodes than LTE (the so-called small cell concept), including macro sites operating in cooperation with smaller base stations, and using various radio technologies depending on service requirements, use cases and/or available spectrum. The 5G mobile communication supports a wide range of use cases and related applications including video streaming, augmented reality, different data sharing approaches, and various forms of machine type applications such as (large scale) machine type communication (mtc) including vehicle safety, different sensors, and real time control. It is expected that 5G will have multiple radio interfaces, i.e. below 6GHz, centi-and millimeter-waves, and can also be integrated with existing legacy radio access technologies, such as LTE. At least in the early stages, integration with LTE may be implemented as one system, where LTE provides macro coverage and 5G radio interface access through small cells converged to LTE. In other words, 5G is intended to support inter-RAT operability (such as LTE-5G) and inter-RI operability (inter-radio interface operability, such as less than 6 GHz-centimeter wave, less than 6 GHz-centimeter wave-millimeter wave). One of the concepts considered for use in 5G networks is network slicing, where multiple independent and dedicated virtual subnetworks (network instances) can be created in substantially the same infrastructure to run services with different requirements for latency, reliability, throughput and mobility.

The architecture in LTE networks is currently fully distributed in the radio and usually fully centralized in the core network. Low latency applications and services in 5G may require bringing the content close to the radio, resulting in local breakout and multiple access edge computing (MEC). 5G enables analysis and knowledge generation to occur at the data source. Such an approach may require the utilization of resources such as laptops, smart phones, tablets, and sensors that may not be continuously connected to the network. The MEC provides a distributed computing environment for application and service hosting. It also enables content to be stored and processed close to the cellular user for faster response times. Edge computing covers a wide range of technologies such as wireless sensor networks, mobile data acquisition, mobile signature analysis, collaborative distributed peer-to-peer ad hoc networks and processes, and can also be classified as local cloud/fog computing and grid/mesh computing, ew computing, mobile edge computing, cloudlet, distributed data storage and retrieval, autonomous self-healing networks, remote cloud services, augmented reality and virtual reality, data caching, internet of things (large-scale connectivity and/or latency critical), critical communications (autonomous driving vehicles, traffic safety, real-time analysis, time critical control, healthcare applications).

The communication system is also capable of communicating with, or utilizing, other networks, such as the public switched telephone network or the internet 112. The communication network may also be capable of supporting the use of cloud services, e.g., at least a portion of the core network operations may be implemented as cloud services (illustrated in fig. 1A by "cloud" 114). The communication system may also comprise a central control entity or similar entity providing facilities for networks of different operators to cooperate, e.g. spectrum sharing.

Edge clouds may incorporate a Radio Access Network (RAN) by utilizing network function virtualization (NVF) and Software Defined Networking (SDN). Using an edge cloud may mean performing access node operations at least in part in a server, host, or node operatively coupled with a remote radio head or base station that includes a radio. Node operations may also be distributed among multiple servers, nodes, or hosts. The application of the cloud RAN architecture enables RAN real-time functions to be performed on the RAN side (in the distributed unit, DU 104) and non-real-time functions to be performed in a centralized manner (in the centralized unit, CU 108).

It should be understood that the distribution of functionality between core network operation and base station operation may be different from LTE or even non-existent. Other technological advances that may be used are big data and all IP, which may change the way the network is built and managed. A 5G (or new radio, NR) network is designed to support multiple hierarchies, where MEC servers can be placed between the core and base stations or node bs (gnbs). It should be understood that MEC may also be applied to 4G networks.

The 5G may also utilize satellite communications to enhance or supplement the coverage of the 5G service, such as by providing backhaul. Possible use cases provide service continuity for machine-to-machine (M2M) or internet of things (IoT) devices or for passengers on a vehicle, or ensure service availability for critical communications as well as future rail, maritime, and/or aviation communications. Satellite communications may utilize Geostationary Earth Orbit (GEO) satellite systems, but also Low Earth Orbit (LEO) satellite systems, in particular giant constellations (systems deploying hundreds of (nanometer) satellites). The satellites 106 in the giant constellation may cover multiple satellite-enabled network entities that create terrestrial cells. The terrestrial cell may be created by the terrestrial relay node 104 or by a gNB located in the ground or in a satellite.

As will be apparent to those skilled in the relevant art: the described system is an example of a part of a radio access system and in practice the system may comprise a plurality of (e/g) nodebs, the user equipment may have access to several radio cells and the system may also comprise other means, such as physical layer relay nodes or other network elements etc. At least one of the (e/g) nodebs may be a Home (e/g) NodeB. In addition, within a geographical area of the radio communication system, a plurality of heterogeneous radio cells and a plurality of radio cells may be provided. The radio cells may be macro cells (or umbrella cells), which are large cells, typically having a diameter of up to ten kilometers, or smaller cells such as micro cells, femto cells or pico cells. The (e/g) NodeB of fig. 1A may provide any kind of these cells. A cellular radio system may be implemented as a multi-layer network comprising several cell classes. Typically, in a multi-layer network, one access node provides one or more cells. And thus may require multiple (e/g) nodebs to provide such a network structure.

To meet the need for improved deployment and performance of communication systems, the concept of "plug and play" (e/g) nodebs was introduced. Typically, a network capable of using "plug and play" (e/g) nodebs includes, in addition to the Home (e/g) NodeB (H (e/g) NodeB), a Home plus-point B gateway, or HNB-GW (not shown in fig. 1A). An HNB gateway (HNB-GW), typically installed within an operator network, may aggregate traffic from a large number of HNBs back to the core network. For example, the networks discussed herein may refer to cellular networks such as 5G and the like.

As indicated by the arrows in fig. 1A, the UEs 100, 102 (and/or any other UE of the described system) may support device-to-device (D2D) communication. D2D communication may sometimes be referred to as side chain communication.

One of the targets of development of NR is Multicast Broadcast Service (MBS) or multiple MBS. MBS may include one or both of multicast and broadcast transmissions. MBS services may be provided to UEs (e.g., by network node 104 as point-to-point (PtP) or point-to-multiple (PtM) transmissions). The former may sometimes be referred to as unicast transmission and the latter as multicast transmission. Further, MBS may be provided to UEs in a Dual Connectivity (DC) scenario, where one UE may be connected to two or more network nodes providing one or more services to the UE. For example, there may be a primary network node (referred to simply as a primary node (MN)) and a secondary network node (referred to simply as a Secondary Node (SN)) controlled by the primary network node (or some other entity) in the DC, where the MN and the SN together provide the MBS to the UE. The MN and SN may be similar to those described with respect to fig. 1A (see, e.g., node 104). For example, both the MN and the SN may connect to the UE and provide substantially the same or different services to the UE. MBS may sometimes be referred to as 5 MBS. In particular, such terms may be used for MBS provided in 5G or NR systems, for example.

As described above, the multicast service may be a service provided to many UEs. For example, in an industrial control use case, one talker (talker) may distribute the same traffic data to more than one listener. The multicast data forwarding solution may reduce resource consumption if more than one listener (listener) is located/located in the same 5G system (5GS) Time Sensitive Network (TSN) bridge. UEs configured for one or more multicast services may participate in one service identified by a particular service identifier, e.g., a Temporary Mobile Group Identity (TMGI). However, currently the UE can be aware of the existence of a Time Sensitive Communication (TSC) multicast group through configuration information from the gNB. Thus, there may be room for developing solutions aimed at enhancing the configuration of multicast services.

FIG. 1B illustrates an example system in which embodiments may be applied. For example, the system of FIG. 1B may be included in the system of FIG. 1A. Referring to fig. 1B, listeners may be depicted by end stations (end stations) 172, 174, and talkers are depicted by end station 170. Accordingly, these entities 170, 172, 174 may be comprised in a wireless communication system, such as a 5 GS. However, in some examples, the speaker may be outside of the example system, e.g., in a different system outside of the 5GS such as LTE or as part of an ethernet Local Area Network (LAN), while the receiver is within the system. With further reference to fig. 1B, the TSN bridge (bridge)150 may also include entities such as: admission Management Function (AMF)162, Session Management Function (SMF)164, Unified Data Repository (UDR)170, Policy Control Function (PCF)166, and Time Sensitive Network (TSN) Application Function (AF) 168. In some examples, the TSN bridge 150 may also be connected to the TSN bridge/end station 176 via an NW-TT port associated with a User Plane Function (UPF) 176.

An end station 170 acting as a talker (i.e., data source) may transmit data to a plurality of end stations 172, 174 acting as listeners (i.e., data destinations). Transmissions may be performed from end station 170 to gNB 194 via UE 182 and further to gNB 192 via User Plane Function (UPF) 176. The gNB 192 may forward the data to the UE 184, and the UE 184 provides the data to the listeners 172, 174. However, the UE 184 may have difficulty in determining which ports it should forward the received data to so that it can reach the correct listener (see the device-side time-sensitive network transducer (DS-TT) ports associated with the UEs 182, 184 in fig. 1B). Thus, the present solution may aim to provide a solution aimed at providing information to the UE about where received multicast data should be forwarded. This may enhance the effectiveness of the multicast because the correct receiver may receive the forwarded data.

In this regard, it may be beneficial to note that an end station as used herein may refer to a terminal device that may be equipped with, for example, an ethernet protocol. For example, the end station may be a sensor, an individual machine in a factory environment, or a mobile robot. Further, the UEs 182, 184 may be similar to those explained with reference to fig. 1A (e.g., UEs 100, 102). The UE may not necessarily require human interaction and may therefore comprise, for example, a device operating autonomously or semi-autonomously. For example, a UE may include and/or refer to an IoT UE. The term network node (e.g., network node 104) may include a gNB 192, 194. In the following, reference is made to the network node 104 and the UEs 100, 102 for simplicity.

Fig. 2 illustrates a flow diagram according to an embodiment. Referring to fig. 2, there is provided a method for a network node of a wireless communication network, the method comprising: receiving information from a core network element of a wireless communication network, the information comprising at least one identifier corresponding to at least one data flow of a multicast service and a User Equipment (UE) list indicating a group of UEs to which the multicast service is targeted, wherein the information further indicates, for a UE on the UE list, a port association between the UE and a port to which data of the at least one data flow is to be forwarded; determining a multicast service change involving at least one UE in a group of UEs based on the received information (block 204); and sending a notification of the multicast service change to at least one UE to trigger multicast service acquisition (block 206).

Fig. 3 illustrates a flow diagram according to an embodiment. Referring to fig. 3, there is provided a method for a UE of a wireless communication network, the method comprising: receiving a notification from a network node of the wireless communication network, the notification regarding a multicast service change involving the UE, and the multicast service change being determined by the network node based on information received from a core network element of the wireless communication network, the information comprising at least one identifier corresponding to at least one data stream of the multicast service and a UE list indicating a group of UEs to which the multicast service is targeted, the UEs being included in the group of UEs, wherein the information further indicates a port association between the UE and a port to which data of the at least one data stream is to be forwarded (block 302); and after receiving the notification, triggers multicast service acquisition (block 304).

For example, the methods described in fig. 2 and 3 may be applicable to the systems of fig. 1A and 1B (e.g., wireless communication networks). The UE(s) discussed with respect to fig. 2 and 3 may be, for example, UE100 or UE102 or some other similar network device. For example, the network node discussed with reference to fig. 2 and 3 may refer to network node 104, or some other network node configured to perform the described method steps. For example, a network node may refer to one or more network entities (e.g., physically separate network entities). Furthermore, a core network element of a wireless communication network may refer to CN 110 or some other control function or control element of the described system. In some embodiments, the core network element may be an element of CN 110. For example, referring to fig. 1B, SMF 164 and/or AMF 162 may perform operations of CN 110.

The proposed method may enable the UE(s) to determine that a change has occurred or will occur. This may enable the UE(s) to trigger multicast service acquisition. This may mean that the UE(s) obtain information about the change so that the UE(s) may act accordingly. For example, the UE may acquire information that it should receive a new multicast service and further acquire information that enables it to receive the indicated new multicast service. The notification may enable the UE(s) to acquire information about the change when necessary. Thus, for example, periodic polling by the UE to determine the changes and changed parameters and/or services (e.g., periodic polling of Downlink Control Information (DCI)) may not be required. This may provide higher reliability and lower control overhead compared to dynamic scheduling.

The change may be related to a control channel, such as a Multicast Control Channel (MCCH), or a data channel, such as a Multicast Traffic Channel (MTCH). Sometimes, the MCCH may be referred to as Time Sensitive Communication (TSC) -MCCH, and the MTCH is referred to as TSC-MTCH. This may mean that a control channel and/or a data channel is used in the TSC system. For example, the system of fig. 1A and/or 1B may support TSC. The MCCH may be used for transmitting multicast TSC control information for all multicast TSC services and one or more MTCH channels may be used for transmitting multicast TSC traffic data for a multicast TSC service per multicast TSC service. That is, for example, there may be MTCH channels specific to the multicast service, which means that the corresponding MTCH channels are used for the multicast service.

In an embodiment, the UE triggers multicast service acquisition in response to receiving a notification of a multicast service change (which may be referred to simply as a change).

The multicast service change may include adding a new multicast service, terminating an existing multicast service, and/or a change in one or more parameters of an existing multicast service, to name a few examples. Note that the information received by network node 104 in block 202 may include information about one or more multicast services, and thus may indicate a change in one or more multicast services. It should also be noted that not all multicast services may change and thus some multicast services may remain unchanged, while other multicast services may change or new service(s) may be added. Thus, the change may be, for example, a new multicast service for a new set of UEs (i.e., a multicast group), an updated multicast group for an existing multicast TSC service (UE list and/or associated port changes), or a new multicast service for an existing multicast group. As explained above, the change may also include a change in one or more parameters of an existing multicast service (e.g., other parameters besides those related to the multicast group). Such parameters may include, for example, quality of service (QoS) parameters.

Adding a multicast service may mean that a new multicast service will be provided to the indicated UE. A new service may be provided to an existing group of UEs or a new group of UEs. For example, an existing group may refer to a group that has been served by a network node with another multicast service. A new group may refer to a group of UEs that have not yet utilized some other multicast service. That is, some but not all members of the new group may be served with the other multicast service. Thus, for example, if one or more UEs are added to an existing group, a new group may be formed. Terminating a multicast service may in turn refer to a situation where an existing service is terminated, i.e. no longer provided to the group of UEs.

The change of one or more parameters of an existing multicast service may include different things. In one example, a group of UEs utilizing a multicast service may be updated (e.g., UEs may be added to or removed from the group). In some examples, the port association may be changed such that for one or more UEs, the associated port may be changed. As a simple example, if the port of UE #1 for some multicast service is port # a, it may be changed to port # B. As indicated above, there may be more than one mapping per UE. For example, port # C may be associated with multicast service or data stream #1 and port D # may be associated with multicast service or data stream #2 for UE # 1. It should also be noted that a multicast service may include one or more data streams. For simplicity, the example used herein is one multicast service comprising one data stream. Thus, a particular data stream may be mapped to a particular port. Indeed, in some examples, this may mean that radio bearers for providing multicast services are mapped to specific ports on the UE side. Thus, when the UE receives data on a particular data bearer, it can determine the port it needs to forward the data based on the port association discussed above. These example embodiments are discussed in more detail below. A port as used herein may refer to, for example, a DS-TT port. Thus, multicast services may be used for TSNs and the ports include DS-TT ports.

Then let us look at the embodiment of fig. 4A and 4B, fig. 4A and 4B show some different ways how to provide notification to a UE about a multicast service change. Referring first to fig. 4A, in the event that the network node 104 does not provide another multicast service for at least one UE in the group of UEs, a notification of the determined change may be sent via Radio Resource Control (RRC) signaling. An example of which is given by block 402, which illustrates transmitting the notification as dedicated RRC signaling 400. In an embodiment, the signaling is dedicated RRC, which may refer to signaling sent to one or more UEs, i.e., it is different from shared signaling that targets all UEs (e.g., typically via System Information Blocks (SIBs)).

The information received by network node 104 from CN 110 may include multicast service information and multicast group information, and the change may be determined based on these information. For example, the multicast service information may include a multicast QoS Flow Identifier (QFI). For example, the multicast group information may include a list of UEs and a list of port numbers. The data flows discussed herein may sometimes refer to QoS flows. The list of UEs may indicate a group of UEs to which the identified data stream should be provided. Furthermore, for UEs on the list, associated port numbers may be provided. For example, QFI #1 may be associated with UE #1 port # a, QFI #2 may be associated with UE #1 port # B; QFI #1 may be associated with UE #2 port # B and QFI #2 may be associated with UE #2 port # C. The information received from CN 110 may indicate these kinds of associations. Thus, a port association may refer to an association between a UE and a port number. In case the network node 104 does not provide another multicast service for at least one UE of the group of UEs to which a certain new multicast service is to be provided, the notification may be sent as indicated in fig. 4A, i.e. as dedicated RRC signaling. The notification of block 402 may be understood as an announcement of a new service for at least one UE of the set of UEs. It is noted that at least one UE of the group of UEs may refer to one or more UEs of the group or the entire group, for example.

The network node may also determine, for at least one UE of a group of UEs, a radio bearer for at least one data flow providing the multicast service; and indicating the port association to the at least one UE in order to enable the UE to forward data received on the determined radio bearer to the associated port. In the example embodiment of fig. 4A, the port association may be indicated as, for example, separate RRC signaling. For example, port association may be provided as dedicated RRC signaling. That is, a port association involving a UE may be sent to the UE as dedicated signaling. In another example, the port association may be provided to a UE in a group of UEs as shared RRC signaling on MCCH. Thus, for example, UE #1 may receive port associations relating to itself as well as other UEs in the group.

The notification of block 402 may enable the UE to initiate acquisition of the multicast service. This may include obtaining information about the service via shared RRC signaling (blocks 404 and 406). As shown, signaling may be received via a control channel. Accordingly, based on the notification (e.g., upon receipt of the notification), the UE may decode the control channel information transmitted as shared signaling. The control channel information may be transmitted one or more times. In the example of fig. 4, the information is sent twice (see blocks 404, 406) to increase the reliability of the reception.

Sending the notification and initiating decoding of the control channel information based on the notification provides the benefit that the UE does not need to decode the shared control channel information all the time (e.g., periodically), but rather upon receiving the notification. The shared signaling may indicate to at least one UE of the group of UEs a multicast service change that has an impact on the UE. For example, the information may indicate a periodicity 420 of the data window 412, the data window 414, the data window 416, and the data window 418. Further, based on the information received in block 404 and/or block 406, the UE may acquire DCI in the subframe indicated by block 412 and/or block 414. The collected DCI may enable the UE to receive multicast traffic data 410 in one or more of blocks 412, 414, 416, 418 transmitted on the traffic channel. If a particular periodicity is used, transmission and/or reception may be according to the indicated periodicity 420. Indicating the period 420 in the control channel sharing signaling may enable the UE to receive multicast traffic data without periodically monitoring the DCI.

Referring now to fig. 4B, where the network node 104 provides another multicast service to the group of UEs, a notification of the multicast service change may be sent on a radio bearer associated with the other multicast service. This is indicated by blocks 422, 424 which show a Notification (NF) sent on the data channel. In this particular example, the notification is indicated as being transmitted on two subframes. However, the notification may be transmitted one or more times depending on the configuration. The UE may need to successfully receive the transmitted notification once in order to act accordingly as explained in more detail later. Thus, if the radio bearer is configured to provide the other multicast service to the group of UEs, the radio bearer may be used to transmit a notification of the multicast service change to the group of UEs. For example, multicast service #1 may have been configured for UE group # 1. Thus, multicast service #1 may be used to provide notification. For example, the change may be that multicast service #2 should be received by the same UE group # 1. However, the notification does not necessarily indicate how the service changes; it may indicate that a change has occurred or will occur and that the UEs in the group may therefore need to obtain further information about the change.

According to an embodiment, the network node 104 sends the notification multiple times (see blocks 422, 424), e.g. as shown in fig. 4B, wherein the sent notification comprises a countdown number or an absolute time reference indicating the time the multicast service change was in effect. This is also shown in fig. 6, for example.

After receiving (e.g., in response to) the notification transmitted in blocks 422, 424, the UE may determine to decode control channel information (e.g., decode MCCH 434 and/or MCCH 436), which may be transmitted as common RRC signaling (e.g., one or more times) similarly as in fig. 4A. After correctly decoding the control channel, the UE may determine to decode the DCI and thus determine the time-frequency resources to receive the data transmission(s) 426, 428, 430, 432. Similarly, as in fig. 4A, a periodicity 440 (e.g., the MCCHs 434, 436) may be indicated on the control channel. At this point, it is noted that while DCI is shown as being transmitted twice, it may only need to be received once to acquire the relevant resources. That is, similar to the notification, the DCI may be transmitted one or more times to enhance the reliability of the resource indication.

In some embodiments, the notification sent on the data channel in fig. 4B may be sent in a Medium Access Control (MAC) Control Element (CE). For example, the notification may be included in a header of the MAC CE.

The notification of the multicast service change (e.g., as described in blocks 422, 424 of fig. 4B) may simply include an indicator that the change has occurred or will occur. For example, such an indicator may be a 1-bit indicator: change/no change (e.g., zero or one). For example, the indicator may indicate whether the data channel or the control channel has changed or will change: control channel/data channel (e.g., zero or one). Thus, if such a notification is sent, it may mean that a change is determined, and an indicator in the notification may indicate whether the change relates to a control channel or a data channel. In some examples, changes to both channels may be indicated by the notification. In some examples, the notification includes two indicators: one to indicate change/not change and one to indicate which channel will change: control channel/data channel.

Thus, based on the notification, the UE may determine what kind of action(s) they should perform: change information is obtained regarding a control channel and/or a data channel. That is, if the change of the data channel is indicated by the notification, the UE may acquire information about the change of the data channel. Similarly, if a control channel is indicated, the UE may acquire information about the control channel variation. Furthermore, higher efficiencies may be achieved by these further solutions, since the UE may not need to separately determine whether the change relates to a data channel or a control channel, and therefore directly proceed to obtain information about the change itself.

In an embodiment, the notification (e.g., described in blocks 422, 424 of fig. 4B) includes a countdown number of hours indicating a time reference when the determined change is in effect. This example embodiment will be discussed in more detail later with reference to fig. 6, 7A and 8.

In an embodiment, the notification of the change in multicast service includes the updated one or more Physical Downlink Shared Channel (PDSCH) parameters. For example, the notification may include a complete PDSCH parameter list or a subset of parameters. For example, the subset may include parameters that are changing, to name a few. The varying parameters may include a Modulation and Coding Scheme (MCS) index, a Time Domain (TD) allocation, and/or a Frequency Domain (FD) allocation. An example of these can be seen in fig. 7B, which illustrates one embodiment. That is, the change may be related to the data channel. Thus, using fig. 4B as an illustrative example, the UE may not need the monitoring blocks 434 and 436 in which to transmit control channel information.

Then let us focus on fig. 5, fig. 5 shows a flow chart according to some embodiments. Blocks 502 to 514 relate to embodiments in which the notification is transmitted as RRC signaling (see e.g. fig. 4A) and blocks 522 to 532 relate to the notification transmitted with a radio bearer (e.g. a multicast radio bearer) for another multicast service (see e.g. fig. 4B). In the latter case, the notification may be transmitted on the MAC CE, for example.

Referring to fig. 5, in block 502, CN 110 may send a multicast registration request to network node 104. The multicast registration request may include information including at least one identifier corresponding to at least one data flow of the multicast service, a UE list indicating a group of UEs, and a port list indicating ports for UEs on the UE list. For example, per multicast service, a port may be indicated for each UE on the UE list. Thus, for example, port a may be indicated for UE #1, port C may be indicated for UE #2, and port D may be indicated for UE # 3. According to an embodiment, the information includes a multicast QFI (i.e., QFI indicates multicast QoS), a list of UEs, and a list of DS-TT port numbers. For example, each multicast service may be identified by a multicast QFI. Note again that there may be multiple multicast services and thus the request of block 502 may indicate one or more services. The multicast registration request may also further or alternatively comprise a de-registration request for one or more multicast services. Therefore, the messages deblocked 502 should be broadly understood. For example, the message of block 502 may be received from the SMF via the AMF.

In an embodiment, network node 104 also receives transmission parameter information from CN 110 (block 504). The transmission parameter information may include, for example, assistance information and/or QoS information. The auxiliary information may indicate information related to traffic characteristics of the multicast QFI, such as periodicity and/or burst arrival time, to name a few. The side information may include, for example, TSC side information (TSCAI). The QoS information may include, for example, a maximum data volume burst size. The periodicity may indicate, for example, the periodicity 420, 440, which may be further indicated by the network node 104 to the UE100, 102.

In block 506, the network node 104 may configure new radio bearers for the new multicast service. That is, the MTCH may be configured for a new multicast service. This assumes that the multicast registration request of block 502 requests establishment of a new service for the group of UEs. According to an embodiment, the new radio bearer is established if the number of UEs on the UE list exceeds a threshold. Otherwise, the existing unicast radio bearers for each UE may be used. The threshold may depend on the use case, but may be, for example, 3 UEs. The network node may perform configuration of radio bearers transparent to the UE.

In fig. 5, block 506 is depicted as RRC Configuration (RRC Configuration). This may sometimes be understood as RRC reconfiguration (rrcrconfiguration). It may also include determining, by the network node 104, a unique Radio Network Temporary Identifier (RNTI), such as a group RNTI (G-RNTI), for scheduling of multicast services in the air interface. Alternatively, the same RNTI may be utilized to schedule the multicast service and an explicit ID (e.g., MTCH identifier) may be used to distinguish among multiple multicast services.

Further, in block 506, the network node 104 may provide notification to the UE(s) 100, 102 regarding the multicast service change. It should be noted that, at least in this example, the UEs 100, 102 are included in the group of UEs indicated in the message of block 502. In some embodiments, it can be seen that the UEs 100, 102 are comprised of the group of UEs.

The network node may also inform each UE in the group of UEs (i.e. the multicast group) of the relevant port number to instruct the UE100, 102 to establish the indicated binding information for the multicast radio bearer and the indicated port number. As mentioned above, such an association between a UE and a port may be referred to as a port association, and based on the port association, the UE may determine where it should forward data received on a radio bearer associated with a certain multicast service. For example, the network node 104 may indicate a port number for a given UE using dedicated RRC signaling for radio bearer configuration. That is, the port number may be sent with the radio bearer configuration, and thus the UE may determine an association between the multicast service (which may be associated with a certain radio bearer) and the port number.

In an embodiment, the network node 104 stores the information received in the multicast registration request (e.g., multicast QFI, UE list, port number list). The stored information may be associated with the corresponding multicast service, e.g. using an MTCH identifier or a corresponding RNTI. This may enable the network node 104 to maintain the UE group(s) and map data received from the CN to the correct radio bearers.

In block 508, a control channel may be used to communicate one or more resource allocation parameters from the network node 104 to the UE100, 102. These one or more parameters may be part of resource allocation parameters for the data channel and may be transmitted as RRC signaling (see, e.g., blocks 404, 406 of fig. 4A). The transmitted parameters may periodically indicate the MTCH identifier and/or RNTI for a particular multicast service (or simply for a data channel for the multicast service). Based on the configuration of block 508, the UE100, 102 may monitor one or more data channels according to the multicast radio bearer configured by the network node in block 506. Thus, basically the network node 104 may inform via common RRC signaling that a particular data channel or channels should be listened to by the UE100, 102. The UE may determine that it should listen to common RRC signaling on the control channel based on receiving notification of the multicast service change. For example, if the UE receives a notification on RRC signaling, the UE may determine that the change relates to a control channel. Thus, the UE may determine to listen to the control channel to obtain information about the change. However, if a notification is received on the MTCH (see, e.g., fig. 4B), the notification may include an indicator indicating whether the change relates to a control channel or a data channel, in some examples.

In block 510, the network node 104 may send a resource allocation to the UE100, 102. The resource allocation may include DCI indicating resource allocation information for a data channel. The transmission may be similar to that indicated in blocks 412, 414. Thus, the DCI may be transmitted one or more times. If an RNTI is assigned per multicast service, DCI indicating resource allocation on a data channel may be scrambled with the corresponding RNTI. The UE100, 102 may thus obtain the correct DCI information since it may have received the RNTI in block 508. If a common RNTI is used (i.e. the same for multiple multicast services), the DCI may include an explicit indication of the scheduled data channel. That is, for example, the DCI may include an MTCH identifier, which may be used as an alternative to the multicast service specific RNTI. For example, 4 bits may be included in the DCI, which allows up to 16 different multicast services to be indicated.

In block 512, after the UE receives the DCI in block 510, it may continue to receive data of at least one data stream on a data channel (or radio bearer) associated with the multicast service. Data may be transmitted on the physical layer on the PDSCH. According to an embodiment, the network node 104 may send data periodically or semi-persistently according to a periodicity. For example, the periodicity may be indicated in the transmission parameter information of block 504. Further, the network node 104 may indicate to the UE100, 102 a periodicity of the periodic or semi-persistent data transmission in order to enable the UE100, 102 to initiate reception of at least one data flow on the radio bearer according to the transmission that occurs periodically or semi-persistently. The UE100, 102 may receive the indicated periodicity and perform reception of data on the data channel according to the periodicity. It should be noted that the periodicity may be multicast service specific (i.e. specific to a certain data channel).

In block 514, the UE100, 102 may forward the received data to the correct port. That is, the UE100, 102 may determine on which data channel or radio bearer data is received, and based on the determined data channel or radio bearer and the acquired port information, determine the correct port and forward the data to the correct port. It should be noted that the network node 104 may receive at least one data flow on a radio bearer and transmit the at least one data flow to the UE100, 102. For example, referring to fig. 1B, the end station 170 may transmit data to the end stations 172, 174. In this case, the gNB 192 may receive the transmitted data and transmit it to the UE 184 on the radio bearer associated with the multicast service in question. The UE 184 may forward the data to the correct end station 172, 174 by forwarding the received data to the correct port. For example, one port may be associated with end station 172 and another port associated with end station 174.

Still referring to fig. 5, let us now study the embodiments relating to sending notifications on another radio bearer more closely. The notification may indicate a change on the control channel. In block 522, the network node 104 may receive another multicast registration request. This may be similar to that explained above with reference to block 502. Further, in some embodiments, network node 104 may receive transmission parameter information from CN 110. Thus, for example, the request of block 522 may include the multicast QFI, the UE list, and the port number list. For example, the request may indicate a new multicast service for an existing group of UEs.

The network node 104 may determine, based on the request of block 522 and stored information (e.g., information about the multicast service provided or to be provided), that it has served the indicated group of UEs with another multicast service (e.g., MTCH 1). Thus, the radio bearer may already be configured. Thus, in block 524, the network node 104 may transmit a notification to the UE100, 102 (i.e., to the group of UEs) about the multicast service change (i.e., the new service to the existing group of UEs). For example, the notification may be transmitted in the MAC CE. The MAC CE may be transmitted on the PDSCH together with ongoing MTCH 1 traffic. In an example embodiment, the MAC CE includes an indicator instructing the UE to receive the updated control channel information.

Based on the notification sent on MTCH 1, the UE100, 102 may determine that there is a change and it may need to obtain information about the change. The notification may include an indication to change relating to the control channel and thus the UE100, 102 may determine to obtain information about the change by listening to common signaling on the control channel.

In block 526, the resource allocation parameters may be obtained by the UE100, 102. The parameter may be obtained in response to detecting a need to obtain information about the change. Block 526 may be similar to block 508.

Similarly, in block 528, the UE100, 102 may obtain a resource allocation for a data channel associated with the new multicast service (i.e., the new service indicated by the request of block 522). The channel may be depicted by MTCH 2. Block 528 may be similar to block 510, i.e., one or more times DCI may be sent for MTCH 2.

In block 530, MTCH 2 data may be transmitted by the network node 104 to the UEs 100, 102. The UE100, 102 may forward data according to the port association as shown in block 532. The new serving port association (i.e., MTCH 2) may be received from the network node 110 as dedicated RRC signaling or as shared RRC signaling. If both MTCHs 1 and 2 are configured for the UEs 100, 102 as indicated in fig. 5, the UEs 100, 102 may forward data of different multicast services according to a multicast service specific port association or mapping. The port association for MTCH 1 may have been previously received. However, dedicated or shared RRC signaling is used to update the port mapping for existing multicast services.

Fig. 6 illustrates an embodiment in which the change relates to a control channel and may be instructed to utilize a radio bearer for an existing multicast service. Referring to fig. 6, blocks 601, 602, 603, 604, 612, and 622 may describe a data window, such as a subframe. In an example, data windows 601 to 604 may be used to provide MTCH 1. Data window 601-604 may include a notification of a multicast service change (e.g., addition of MTCH 2). The notification (e.g., MAC CE) may be sent four times in the example, and the countdown number of hours 606 (i.e., 4, 3, 2, 1) may be used to indicate when the indicated change takes effect. That is, in the example, the change takes effect during data window 612. Thus, the countdown number may indicate, for example, how many windows of data are before the change takes effect. Thus, the count down per notification transmission may be reduced. An explicit time reference may be used instead of the countdown number of hours. This is possible because the UE and the network node may be time synchronized with each other. In an embodiment, timing information (e.g., countdown number of hours and/or time reference) is sent on the control channel instead of the data channel.

Based on the notifications sent in the windows 601 to 604, the UE may obtain updated control channel information, as indicated by reference numeral 608. This information may be sent, for example, on the control channel shown at reference numeral 692 during data windows 601 through 604. It is noted that the control channel information transmitted in the windows 601 to 604 may be the same. Keeping in mind that in this example, the notification may be sent on the data channel indicated by reference numeral 694. Thus, upon successful decoding of any notification sent over window 601-604, the UE may send updated control channel information 608. Once the UE reads the control channel information, for example, the DCI 614 may be decoded and MTCH 2 data received by the UE during the windows 612, 622. MTCH 1 data may also be received during the windows 612, 622. Data for different multicast services (i.e., MTCHs 1 and 2) may be forwarded to the correct port accordingly.

Fig. 7A, 7B, 8 and 9 illustrate some embodiments in which a multicast service change is related to a data channel. For example, data channel parameters may change and this may need to be indicated to the served UE. For example, the resource allocation for an ongoing multicast service may change. This may mean that the MCS, transport block size, time domain allocation and/or frequency domain allocation may change. In the example embodiment of fig. 7A, the updated one or more parameters may be included in the MAC CEs transmitted over data windows 701 through 704. Similarly, as shown in FIG. 6, a countdown number 706 is depicted that may indicate when a change has occurred (i.e., in the data window 712). A time reference may be used instead to transmit the time information on the MAC CE or on the control channel alone is feasible.

Thus, in the example of fig. 7A, the notification of the multicast service change may include one or more parameters of the data channel. For example, all PDSCH parameters or a subset of parameters may be indicated (e.g., parameters that are changing may be indicated). For example, the notification may be sent on the MAC CE. As with the change indicator, for example, the change information (i.e., one or more parameters) may be included in a header of the MAC CE. By providing the parameter(s) over one or more data windows 701-704 for transmitting existing multicast service data, the UE may directly acquire the updated parameter(s) without acquiring DCI to acquire the updated parameter(s). The data windows 712, 722 describe data windows in which changes in the data channel (i.e., parameter (s)) have taken effect, and the UE and network node 104 may act accordingly.

In FIG. 7B, an example structure of the notification used in FIG. 7A is shown. The notification may include an identifier (e.g., MTCH identifier) that identifies the multicast service (or data channel) associated with the change. The MAC CE may include a Time Domain Resource Allocation (TDRA), a Frequency Domain Resource Allocation (FDRA), and/or an MCS index. In an example, the size of the FDRA field (19 bits) has been selected to cover the maximum allowed bandwidth of 275 Physical Resource Blocks (PRBs); however, a variable size MAC CE may also be used, where the FDRA field size is selected according to the size of the bandwidth part of the scheduled PDSCH. As discussed, the notification of fig. 7B may be included in the MAC CE, for example.

Fig. 8 relates to an embodiment in which a notification of a change in a multicast service indicates a change related to a data channel used to provide an existing multicast service. Further, the notification may include an indicator indicating that the UE decoded DCI on the PDCCH, the DCI including the updated one or more parameters of the data channel. That is, in the embodiments discussed with respect to fig. 7A and 7B, one or more updated parameters may be included in the notification, while in the embodiment of fig. 8, the notification may simply include, for example, an indicator regarding the change, and the updated parameters may be obtained separately (e.g., similar to obtaining control channel parameters in some examples of fig. 6).

Thus, data window 801, data window 802, data window 803, data window 804 may be used for transmitting data of an existing multicast service from the network node 104 to the group of UEs. The notification may be sent in one or more data windows, for example in the MAC CE. Similarly, as described above, timing information (e.g., count-down number 806 or a time reference) may be provided separately on the notification (e.g., on the MAC CE) or on the control channel. Based on the notification, the UE may determine when the change is in effect (i.e., during the data window 812) and initiate monitoring of the resource allocation information (e.g., DCI 814) accordingly. Thus, the UE may monitor the DCI in response to receiving the notification, and thereby obtain the DCI as it is transmitted. Thus, the UE may acquire the updated parameters and service provisioning may continue in the data windows 812, 822 with the updated parameters. Further, the UE may not need to continuously monitor the DCI, as monitoring may be initiated based on receiving the notification.

Fig. 9 shows a signal diagram relating to indicating to the UEs 100, 102 (i.e. illustrating a group or subset of groups of UEs) a change in data channel by utilizing the notifications discussed in fig. 7A, 7B and 8. Before the steps shown in fig. 9, the multicast service may have been configured and further utilized for the UEs 100, 102. This may be performed similarly as shown in steps 502-514 of fig. 5, for example.

In step 932, network node 104 may receive transmission parameter information from CN 110. For example, the information may be similar to the transmission parameter information shown in block 504 of fig. 5. Thus, for example, the transport block size and/or burst arrival time may be updated (i.e., changed) according to the multicast service provided. A change in transmission parameter information may cause the network node 104 to detect a change in multicast service and thereby trigger the transmission of a notification to the UE100, 102.

It is feasible to trigger the notification transmission based on channel quality information, such as Channel Quality Indicator (CQI), received from one or more of the UE100, UE102, i.e. from a group of UEs. For example, network node 104 may determine to change (e.g., decrease or increase) the MCS of the multicast data transmission based on the received channel quality information. This may also be understood as a multicast service change and thus trigger a notification. Thus, the information of block 932 may not need to be received to trigger the transmission of a notification regarding the multicast service change.

In step 934, network node 104 sends a notification to UE100, UE102 regarding the change. The notification may include information as discussed with respect to fig. 7A and 7B or fig. 8. In both cases, the UE100, 102 may obtain updated parameters such as MCS, transport block size, FD allocation, TD allocation, and/or burst rate.

In step 936, the network node 104 transmits the multicast service data according to the updated data channel parameter(s).

In step 938, the UE100, 102 may receive the multicast service data according to the updated parameters and forward the data to the correct port (i.e., may obtain the port mapping before the steps shown in fig. 9).

According to an embodiment, the multicast service change comprises updated transmission parameter information for the existing multicast service. The network node 110 may determine to update the radio bearers for the existing multicast service based on the updated transmission parameter information. The transmission parameter information may include TSCAI and/or QoS information (e.g., QoS parameter (s)). For example, if the burst arrival time or maximum data burst size changes, the radio bearer may be advantageously updated to meet the requirements of the changed parameters.

Fig. 10 and 11 provide an apparatus 1000, an apparatus 1100, comprising control Circuitry (CTRL)1010, 1110, such as at least one processor, and at least one memory 1030, 1130 comprising computer program code (software) 1032, 1132, wherein the at least one memory and the computer program code (software) 1032, 1132 are configured with the at least one processor to cause the respective apparatus 1000, 1100 to perform any one of the embodiments of fig. 1A to 9, or an operation thereof.

Referring to fig. 10 and 11, the memories 1030, 1130 may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The memories 1030, 1130 may include databases 1034, 1134 for storing data. For example, an identifier (e.g., QFI) identifying at least one data flow, UE group, and port list may be stored thereon.

The apparatus 1000, 110 may further include a radio interface (TRX)1020, 1120 including hardware and/or software for enabling communication connectivity according to one or more communication protocols. For example, the TRX may provide the device with communication capabilities to access a radio access network. The TRX may include standard well-known components such as amplifiers, filters, frequency converters, (de) modulators and encoder/decoder circuitry, and one or more antennas.

The devices 1000, 1100 may include user interfaces 1040, 1140 including, for example, at least one keypad, microphone, touch display, speaker, and the like. The user interfaces 1040, 1140 may be used to control the respective devices by users of the devices 1000, 1100.

In an embodiment, the apparatus 1000 may be or be comprised in a network node performing the method described above (e.g. with reference to fig. 2). For example, the apparatus 1000 may be or be comprised in the network node 104.

In an embodiment, the apparatus 1100 may be or be comprised in a network node performing the method described above (e.g. with reference to fig. 3). For example, the apparatus 1100 may be or be included in the UE100 or the UE 102.

According to an embodiment, referring to fig. 10, the control circuitry 1010 includes receiving circuitry 1012 configured to perform at least the operations described with respect to block 202 of fig. 2; the determination circuitry 1014 is configured to perform at least the operations described with respect to block 204 of fig. 2; and transmit circuitry 1016 configured to perform at least the operations described with respect to block 206 of fig. 2.

According to an embodiment, referring to fig. 11, control circuitry 1110 includes receive circuitry 1112 configured to perform at least the operations described with respect to block 302 of fig. 3; and the trigger circuit 1114 is configured to perform at least the operations described with respect to block 304 of fig. 3.

In an embodiment, at least some of the functionality of the apparatus 1000 may be shared between two physically separated devices, forming one operational entity. Thus, it can be seen that apparatus 1000 describes an operational entity comprising one or more physically separate devices for performing at least some of the described processes. Accordingly, an apparatus 1000 utilizing such a shared architecture may include a Remote Control Unit (RCU), such as a host or server computer, operatively coupled (e.g., via a wireless or wired network) to a Remote Radio Head (RRH) located in a base station or network node 104, for example. In an embodiment, at least some of the described procedures may be performed by the RCU. In an embodiment, execution of at least some of the described processes may be shared between the RRH and the RCU. For example, CU/DU splitting may take advantage of this shared architecture.

In an embodiment, the RCU may generate a virtual network through which the RCU communicates with the RRH. In general, virtual networking may involve the process of combining hardware and software network resources and network functions into a single software-based management entity, a virtual network. Network virtualization may involve platform virtualization, typically in combination with resource virtualization. Network virtualization may be classified as an external virtual network that combines many networks or portions of networks into a server computer or host computer (i.e., RCU). External network virtualization aims to optimize network sharing. Another type is an internal virtual network that provides network-like functionality for software containers on a single system.

In an embodiment, the virtual network may provide flexible operational distribution between the RRHs and the RCUs. In fact, any digital signal processing task may be performed in the RRH or RCU, and the boundary of the responsibility transfer between the RRH and RCU may be selected depending on the implementation.

According to an aspect, a system is provided that includes one or more apparatuses 1000 and a plurality of apparatuses 1100. In an embodiment, the system further comprises CN 110 or CN element.

The term "circuitry" as used in this application may refer to the following: (a) hardware circuit implementations, such as implementations in analog and/or digital circuitry, and (b) combinations of circuits and software (and/or firmware), such as (as applicable): (i) a combination of processors or (ii) a processor/portion of software, including a digital signal processor, software and memory, working together to cause an apparatus to perform various functions, and (c) a circuit, such as a microprocessor or a portion of a microprocessor, utilizing the software or firmware for operation even if the software or firmware is not physically present. This definition of "circuitry" applies to the use of this term in this application. As another example, as used in this application, the term "circuitry" would also encompass an implementation of merely a processor (or multiple processors) or portion of a processor and its (or their) accompanying software and/or firmware. The term "circuitry" would also cover, for example, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or other network device if applicable to the particular element.

In an embodiment, at least some of the processes described in connection with fig. 1A to 9 may be performed by an apparatus comprising respective means for performing at least some of the described processes. Some example components for performing a process may include at least one of: detectors, processors (including dual and multi-core processors), digital signal processors, controllers, receivers, transmitters, encoders, decoders, memories, RAMs, ROMs, software, firmware, displays, user interfaces, display circuitry, user interface software, display software, circuitry, antennas, antenna circuitry, and circuitry. In an embodiment, the at least one processor, the memory, and the computer program code form processing means or comprise one or more computer program code portions for performing one or more operations according to any of the embodiments of fig. 1A to 9, or operations thereof.

According to yet another embodiment, an apparatus for performing an embodiment comprises circuitry comprising at least one processor and at least one memory including computer program code. When activated, the circuitry causes the apparatus to perform at least some of the functions of any of the embodiments according to figures 1A to 9 or the operations thereof.

The techniques and methods described herein may be implemented by various means. For example, the techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or a combination thereof. For a hardware implementation, the apparatus of an embodiment may be implemented within one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the functions described herein may be performed by at least one module of a chipset (e.g., procedures, functions, and so on). The software codes may be stored in memory units and executed by processors. The memory unit may be implemented within the processor or external to the processor. In the latter case, it may be communicatively coupled to the processor via various means as is known in the art. Moreover, components of systems described herein may be rearranged and/or complimented by additional components in order to facilitate implementation of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in a given figure, as will be appreciated by one skilled in the art.

The described embodiments may also be implemented in the form of a computer process defined by a computer program or portions thereof. The embodiments of the method described in connection with fig. 1A to 9 may be performed by executing at least a part of a computer program comprising corresponding instructions. The computer program may be in source code form, object code form or in some intermediate form, and it may be stored on some carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example, but is not limited to, a recording medium, computer memory, read-only memory, electrical carrier wave signals, telecommunications signals, and software distribution packages, for example. For example, the computer program medium may be a non-transitory medium. Software code for implementing the illustrated and described embodiments is well within the purview of one of ordinary skill in the art. In an embodiment, a computer readable medium comprises the computer program.

Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted thereto but it can be modified in several ways within the scope of the appended claims. Accordingly, the words and expressions herein have been broadly interpreted and they are intended to illustrate, not to limit, the embodiments. It is obvious to a person skilled in the art that with the advancement of technology, the inventive concept may be implemented in various ways. Furthermore, it is obvious to a person skilled in the art that the described embodiments may, but need not, be combined in various ways with other embodiments.

Claims (42)

1. A method for a network node of a wireless communication network, the method comprising:

receiving information from a core network element of the wireless communication network, the information comprising at least one identifier corresponding to at least one data flow of a multicast service and a user equipment, UE, list indicating a group of UEs to which the multicast service is targeted, wherein the information further indicates, for UEs on the UE list, a port association between the UE and a port to which data of the at least one data flow is to be forwarded;

determining, based on the received information, a multicast service change involving at least one UE of the set of UEs; and

sending a notification of the multicast service change to the at least one UE to trigger multicast service acquisition.

2. The method of claim 1, wherein the multicast service change comprises adding a new multicast service, terminating an existing multicast service, and/or changing one or more parameters of an existing multicast service.

3. The method of claim 1 or 2, further comprising:

determining, for the at least one UE of the set of UEs, a radio bearer for the at least one data flow providing the multicast service; and

indicating the port association to the at least one UE to enable the UE to forward data received on the determined radio bearer to the associated port.

4. The method of any preceding claim, wherein the notification of the multicast service change indicates a change involving a data channel or a control channel.

5. The method of any preceding claim, further comprising:

in an instance in which the network node provides another multicast service to the group of UEs, the notification of the multicast service change is sent on a radio bearer associated with the other multicast service.

6. The method of claim 5, further comprising:

sending the notification a plurality of times, wherein the notification sent comprises a countdown number of hours or an absolute time reference indicating a time at which the multicast service change takes effect.

7. The method of any preceding claim, further comprising:

in case the network node does not provide another multicast service for the at least one UE of the set of UEs, the notification of the determined change is sent via dedicated radio resource control, RRC, signaling.

8. The method of any preceding claim, wherein the multicast service change comprises updated transmission parameter information for an existing multicast service, the method further comprising:

determining to update a radio bearer for the existing multicast service based on the updated transmission parameter information.

9. The method of any preceding claim, further comprising:

establishing a new radio bearer for the at least one data flow providing the multicast service if the number of UEs on the UE list exceeds a threshold.

10. The method of any preceding claim, further comprising:

transmitting the at least one data flow to the group of UEs on the radio bearer.

11. The method of any preceding claim, wherein a data window for transmitting data on the radio bearer is scheduled such that the data window occurs periodically, the method further comprising:

indicating a periodicity of the scheduled data window to the group of UEs to enable the group of UEs to initiate reception of the at least one data flow on the radio bearer according to the periodically occurring data window.

12. The method of any preceding claim, wherein the multicast service is for a Time Sensitive Network (TSN) and the port comprises a device side TSN converter (DS-TT) port.

13. A method for a user equipment, UE, of a wireless communication network, the method comprising:

receiving a notification from a network node of the wireless communication network, the notification pertaining to a multicast service change involving the UE, and the multicast service change being determined by the network node based on information received from a core network element of the wireless communication network, the information comprising at least one identifier corresponding to at least one data stream of a multicast service and a UE list indicating a group of UEs to which the multicast service is targeted, the UEs being included in the group of UEs, wherein the information further indicates a port association between the UE and a port to which data of the at least one data stream is to be forwarded; and

triggering multicast service acquisition after receiving the notification.

14. The method of claim 13, wherein the multicast service change comprises adding a new multicast service, terminating an existing multicast service, and/or changing one or more parameters of an existing multicast service.

15. The method of claim 13 or 14, wherein the notification of the multicast service change indicates a change involving a data channel or a control channel, the method further comprising:

obtaining information about the data channel change or control channel change based on the notification.

16. The method of claim 13, 14 or 15, further comprising:

obtaining the port association for a radio bearer from the network node for providing the at least one data flow of the multicast service; and

forwarding data received on the radio bearer to the corresponding port in accordance with the port association.

17. The method according to any of the preceding claims 13 to 16, wherein in case the network node provides a further multicast service for the group of UEs, the notification about the multicast service change is received on a radio bearer associated with the further multicast service.

18. The method of claim 17, wherein the notification comprises a countdown number of hours or an absolute time reference indicating a time at which the multicast service change takes effect.

19. The method according to any of the preceding claims 13 to 18, wherein the notification of the multicast service change is received via radio resource control, RRC, signalling in case the network node does not provide another multicast service for the group of UEs.

20. The method of any preceding claim 13 to 19, wherein a data window for transmitting data on the radio bearer is scheduled such that the data window occurs periodically, the method further comprising:

receiving an indication of a periodicity of the scheduled data window from the network node to enable the UE to initiate reception of the at least one data flow on the radio bearer according to the periodically occurring data window.

21. An apparatus comprising at least one processor, and at least one memory including computer program code, wherein the at least one memory and the computer code are configured to, with the at least one processor, cause the apparatus to perform operations comprising:

receiving, by a network node of a wireless communication network, information from a core network element of the wireless communication network, the information comprising at least one identifier corresponding to at least one data flow of a multicast service and a user equipment, UE, list, the user equipment list indicating a group of UEs to which the multicast service is targeted, wherein the information further indicates, for UEs on the UE list, port associations between the UEs and ports to which data of the at least one data flow is to be forwarded;

determining, based on the received information, a multicast service change involving at least one UE of the set of UEs; and

sending a notification of the multicast service change to the at least one UE to trigger multicast service acquisition.

22. The apparatus of claim 21, wherein the multicast service change comprises adding a new multicast service, terminating an existing multicast service, and/or changing one or more parameters of an existing multicast service.

23. The apparatus according to claim 21 or 22, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to further perform operations comprising:

determining, for the at least one UE of the set of UEs, a radio bearer for the at least one data flow providing the multicast service; and

indicating the port association to the at least one UE to enable the UE to forward data received on the determined radio bearer to the associated port.

24. The apparatus according to any of the preceding claims 21 to 23, wherein the notification of the multicast service change indicates a change involving a data channel or a control channel.

25. The apparatus of any preceding claim 21 to 24, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform operations comprising:

in an instance in which the network node provides another multicast service to the group of UEs, the notification of the multicast service change is sent on a radio bearer associated with the other multicast service.

26. The apparatus of claim 25, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform operations comprising:

sending the notification a plurality of times, wherein the notification sent comprises a countdown number of hours or an absolute time reference indicating a time at which the multicast service change takes effect.

27. The apparatus of any preceding claim 21 to 26, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform operations comprising:

in case the network node does not provide another multicast service for at least one UE of the set of UEs, the notification of the determined change is sent via dedicated radio resource control, RRC, signaling.

28. The apparatus according to any of the preceding claims 21 to 27, wherein the multicast service change comprises updated transmission parameter information for an existing multicast service, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform operations comprising:

determining to update a radio bearer for the existing multicast service based on the updated transmission parameter information.

29. The apparatus of any preceding claim 21 to 28, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform operations comprising:

establishing a new radio bearer for the at least one data flow providing the multicast service if the number of UEs on the UE list exceeds a threshold.

30. The apparatus of any preceding claim 21 to 29, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform operations comprising:

transmitting the at least one data flow to the group of UEs on the radio bearer.

31. The apparatus according to any of the preceding claims 21 to 30, wherein a data window for transmitting data on the radio bearer is scheduled such that the data window occurs periodically, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform operations comprising:

indicating a periodicity of the scheduled data window to the group of UEs to enable the group of UEs to initiate reception of the at least one data flow on the radio bearer according to the periodically occurring data window.

32. The apparatus of any preceding claim 21 to 31, wherein the multicast service is for a Time Sensitive Network (TSN) and the port comprises a device side TSN converter (DS-TT) port.

33. An apparatus comprising at least one processor, and at least one memory including computer program code, wherein the at least one memory and the computer code are configured to, with the at least one processor, cause the apparatus to perform operations comprising:

receiving, by a user equipment, UE, of a wireless communication network, a notification from a network node of the wireless communication network, the notification relating to a multicast service change involving the UE, and the multicast service change being determined by the network node based on information received from a core network element of the wireless communication network, the information comprising at least one identifier corresponding to at least one data flow of a multicast service and a UE list indicating a group of UEs to which the multicast service is targeted, the UEs being comprised in the group of UEs, wherein the information further indicates a port association between the UE and a port to which data of the at least one data flow is to be forwarded; and

triggering multicast service acquisition after receiving the notification.

34. The apparatus of claim 33, wherein the multicast service change comprises adding a new multicast service, terminating an existing multicast service, and/or changing one or more parameters of an existing multicast service.

35. The apparatus according to claim 33 or 34, wherein the notification of the multicast service change indicates a change involving a data channel or a control channel, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform operations comprising:

based on the notification, information about the data channel change or the control channel change is acquired.

36. The apparatus of claim 33, 34 or 35, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform operations comprising:

obtaining the port association for a radio bearer from the network node for providing the at least one data flow of the multicast service; and

forwarding data received on the radio bearer to the corresponding port in accordance with the port association.

37. The apparatus according to any of the preceding claims 33 to 36, wherein in case the network node provides another multicast service for the group of UEs, the notification of the multicast service change is received on a radio bearer associated with the other multicast service.

38. The device of claim 37, wherein the notification comprises a countdown number of hours or an absolute time reference indicating a time at which the multicast service change takes effect.

39. The apparatus according to any of the preceding claims 33 to 38, wherein the notification of the multicast service change is received via radio resource control, RRC, signaling in case the network node does not provide another multicast service for the group of UEs.

40. The apparatus according to any of the preceding claims 33 to 39, wherein a data window for transmitting data on the radio bearer is scheduled such that the data window occurs periodically, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform operations comprising:

receiving an indication of a periodicity of the scheduled data window from the network node to enable the UE to initiate reception of the at least one data flow on the radio bearer in accordance with the periodically occurring data window.

41. A computer program comprising instructions for causing an apparatus to perform the method of any of claims 1 to 20.

42. An apparatus comprising means for performing the method of any of claims 1-20.

Images