Multicast-broadcast service tunneling

Abstract

A method is provided for a second network node, the method comprising: receiving a message from a first network node configured to provide a multicast-broadcast service (MBS) for a user equipment (UE), the message comprising an MBS identifier identifying the MBS and at least one data flow identifier corresponding to at least one data flow for providing the MBS to be offloaded from the first network node to the second network node; determining whether a tunnel associated with the MBS identifier exists between the second network node and a user plane entity; based on the determination, sending a response message to the first network node indicating whether a new tunnel for the MBS is requested to be established; and utilizing the existing tunnel or the new tunnel requested to be established to provide the MBS.

Description

[Technical field]

[0001] The following exemplary embodiments relate to communications. [Background technology]

[0002] Modern wireless communication networks provide different types of services to User Equipment (UE). It may be beneficial to develop solutions aimed at enhancing the effectiveness of such services. One example of such a service may be the Multicast-Broadcast Service (MBS). Summary of the Invention

[0003] According to aspects, the subject matter of the independent claims is provided. Some embodiments are defined in the dependent claims.

[0004] According to an aspect, there is provided a computer program comprising instructions for causing an apparatus to carry out the method according to any one of claims 16 to 30.

[0005] The non-claimed embodiments should be construed as examples that are helpful in understanding the disclosure.

[0006] One or more examples of implementations are described in detail in the accompanying drawings and the description that follows. Other features will be apparent from the description and drawings, and from the claims.

[0007] In the following, several embodiments will be described with reference to the accompanying drawings. [Brief description of the drawings]

[0008] [Figure 1A] FIG. 1 illustrates an example of a wireless communication system in which embodiments may be applied. [Figure 1B] 1A-1C illustrate examples of several exemplary wireless communication system architectures to which embodiments may be applied. [Figure 1C] 1A-1C illustrate examples of several exemplary wireless communication system architectures to which embodiments may be applied. [Diagram 2] FIG. 1 is a flow diagram according to some embodiments. [Diagram 3] FIG. 1 is a flow diagram according to some embodiments. [Figure 4A] FIG. 2 is a signaling diagram according to some embodiments. [Figure 4B] FIG. 2 is a signaling diagram according to some embodiments. [Figure 4C] FIG. 2 is a signaling diagram according to some embodiments. [Diagram 5] FIG. 2 is a signaling diagram according to some embodiments. [Figure 6] FIG. 1 illustrates an apparatus according to some embodiments. [Figure 7] FIG. 1 illustrates an apparatus according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] The following embodiments are examples. Although the specification may refer to "a," "an," or "some" embodiments in several places, this does not necessarily mean that such references are referring to the same embodiment or that a feature applies only to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments. Furthermore, it should be understood that the terms "comprise" and "include" do not limit the described embodiment to consist only of the mentioned features, and such an embodiment may also include features / structures not specifically mentioned.

[0010] In the following, different exemplary embodiments are described using radio access architecture based on Long Term Evolution Advanced (LTE Advanced, LTE-A) or New Radio (NR, 5G) as an example of an access architecture to which the embodiments may be applied, but the embodiments are not limited to such architecture. Those skilled in the art will recognize that by appropriately adjusting parameters and procedures, the embodiments may also be applied to other types of communication networks having suitable means. Some examples of other options of 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 Standard Communication System (WiMAX), Bluetooth®, Personal Communication Service (PCS), ZigBee®, Wideband Code Division Multiple Access (WCDMA), Ultra Wideband (UWB) technology-based systems, sensor networks, Mobile Ad Hoc Networks (MANET), and Internet Protocol Multimedia Subsystem (IMS), or any combination thereof.

[0011] FIG. 1A shows an example of a simplified system architecture showing some elements and functional entities, the implementation may differ from that shown. The connections shown in FIG. 1A are logical connections, and the actual physical connections may differ. It will be apparent to one skilled in the art that the system typically also includes functions and structures other than those shown in FIG. 1A.

[0012] However, the embodiment is not limited to the system given as an example, and a person skilled in the art may apply the solution to other communication systems with the required characteristics.

[0013] The example of Figure 1A shows a portion of an illustrative radio access network. Figure 1A shows terminal devices or user devices 100, 102 configured to wirelessly connect with an access node (such as an (e / g)NodeB) 104 serving the cell in one or more communication channels within the cell. The (e / g)NodeB may refer to an eNodeB or a gNodeB as defined in the 3GPP specifications. The physical link from the user device to the (e / g)NodeB is referred to as an uplink or reverse link, and the physical link from the (e / g)NodeB to the user device is referred to as a downlink or forward link. It should be appreciated that the (e / g)NodeB or their functionality may be implemented by using any node, host, server, or access point, or other entity suitable for such use.

[0014] A communication system typically comprises multiple (e / g)NodeBs, where the (e / g)NodeBs may be configured to communicate with each other via wired or wireless links designed for the purpose. These links may be used for signaling purposes, but also for routing data from one (e / g)NodeB to another (e / g)NodeB. An (e / g)NodeB is a computing device configured to control radio resources of the communication system to which the (e / g)NodeB is connected. A NodeB may also be referred to as a base station, an access point, an access node, or any other type of interface device including a relay station operable in a wireless environment. An (e / g)NodeB includes or is coupled to a transceiver. A connection is provided from the transceiver of the (e / g)NodeB to an antenna unit that establishes a bidirectional radio link to a user device. The antenna unit may comprise multiple antennas or antenna elements. The (e / g)NodeB is further connected to a core network 110 (CN or Next Generation Core NGC). Depending on the system, the CN-side counterpart can be a serving gateway (S-GW, which routes and forwards user data packets), a packet data network gateway (P-GW) for providing connectivity for user devices (UEs) to external packet data networks, or a mobility management entity (MME), etc.

[0015] A user device (also referred to as UE, user equipment, user terminal, terminal device, etc.) refers to one type of device to which resources in the air interface are assigned and designated, and any functionality described herein with respect to a user device may be implemented in a corresponding device, such as a relay node. An example of such a relay node is a Layer 3 relay (self-backhauling relay) to a base station.

[0016] A user device generally refers to a portable computing device, including wireless mobile communication devices that operate with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: mobile stations (mobile phones), smartphones, personal digital assistants (PDAs), handsets, devices that use wireless modems (such as alarm or measurement devices), laptops and / or touch screen computers, tablets, game consoles, notebooks, and multimedia devices. It should be recognized that a user device may also be an almost exclusively uplink device, of which a camera or video camera that loads images or video clips onto the network is an example. A user device may also be a device with the capability to operate in an Internet of Things (IoT) network, such as an Industrial IoT (IIoT) network, a scenario that provides objects with the capability to transfer data over a network without the need for human-to-human or human-to-computer interaction. A user device may also utilize the cloud. In some applications, a user device may comprise a small portable device with a wireless component (such as a watch, earphones or glasses), and computations are performed in the cloud. A user device (or, in some embodiments, a Layer 3 relay node) is configured to perform one or more of the user equipment functions. A user device may also be referred to as a subscriber unit, a mobile station, a remote terminal, an access terminal, a user terminal, or user equipment (UE), just to mention a few names or devices. A user device herein may also refer to a vehicular implementation, such as a vehicular UE. Such a UE may be included in and / or communicatively coupled to a vehicle, such that it may be understood as part of one or more vehicles.

[0017] The various techniques described herein may also be applied to cyber-physical systems (CPS), systems that cooperate with computational elements to control physical entities. CPS may enable the implementation and exploitation of a large number of interconnected ICT devices (sensors, actuators, processors microcontrollers, etc.) embedded in physical objects in different locations. Mobile cyber-physical systems, where the physical system in question has inherent mobility, are a subcategory of cyber-physical systems. Examples of mobile physical systems include mobile robots and electronic devices carried by humans or animals.

[0018] In addition, although the apparatus is shown as a single entity, different units, processors and / or memory units (not necessarily shown in FIG. 1A) may be implemented.

[0019] 5G allows the use of multiple-input multiple-output (MIMO) antennas and many more base stations or nodes than LTE (so-called small cell concept), including macro sites working in conjunction with smaller stations and employing different radio technologies depending on the service needs, use cases, and / or available spectrum. 5G mobile communications will support a wide range of use cases and related applications, including video streaming, augmented reality, different methods of data sharing, and different forms of machine-type applications (such as (massive) machine-type communications (mMTC) including vehicle safety, different sensors, and real-time control). 5G is expected to have multiple air interfaces, namely sub-6 GHz, cmWave, mmWave, and can also be integrated with existing legacy radio access technologies such as LTE. Integration with LTE may be implemented, at least in the initial stages, as a system where macro coverage is provided by LTE and 5G air interface access comes from small cells by aggregation to LTE. In other words, 5G is planned to support both inter-RAT interoperability (such as LTE-5G) and inter-RI interoperability (inter-air interface interoperability such as below 6GHz-cmWave, below 6GHz-cmWave-mmWave, etc.). One of the concepts being considered for use in 5G networks is network slicing, where multiple independent and dedicated virtual sub-networks (network instances) can be created within essentially the same infrastructure to run services with different requirements regarding latency, reliability, throughput, and mobility.

[0020] The current architecture in LTE networks is fully distributed over the air and typically fully centralized in the core network. Low latency applications and services in 5G may require content to be brought closer to the air, which brings us to local breakouts and multi-access edge computing (MEC). 5G allows analytics and knowledge generation to happen at the source of the data. This approach may require leveraging resources that are not continuously connected to the network, such as laptops, smartphones, tablets, and sensors. MEC provides a distributed computing environment for application and service hosting. It also has the ability to store and process content closer to the cellular subscriber 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 networking and processing (which can also be categorized as local cloud / fog computing and grid / mesh computing), dew computing, mobile edge computing, cloudlets, distributed data storage and retrieval, autonomic self-healing networks, remote cloud services, augmented and virtual reality, data caching, Internet of Things (where massive connectivity and / or latency are critical), and critical communications (autonomous vehicles, road safety, real-time analytics, time-critical control, healthcare applications).

[0021] The communication system may also communicate with or use services provided by other networks, such as the Public Switched Telephone Network or the Internet 112. The communication network may also support the use of cloud services, e.g., at least a portion of the core network operations may be performed as cloud services (this is shown in FIG. 1A as "Cloud" 114). The communication system may also comprise a central control entity, etc., that provides functionality to networks of different operators, e.g., to cooperate in spectrum sharing.

[0022] Edge clouds can be embedded in radio access networks (RANs) by utilizing network function virtualization (NVF) and software-defined networking (SDN). Using edge clouds can mean access node operations that are at least partially performed in a server, host, or node that is operatively coupled to a remote radio head or base station that comprises a radio part. Node operations can also be distributed among multiple servers, nodes, or hosts. The application of cloud RAN architecture allows RAN real-time functions to be performed on the RAN side (in distributed unit DU104) and non-real-time functions to be performed in a centralized manner (in centralized unit CU108).

[0023] It should be understood that the distribution of functions between the core network operations and the base station operations may also differ from that of LTE or may not even exist. Some other technological advances that may possibly be used are big data and all-IP, which may change the way the network is built and managed. 5G (or new radio NR) networks are designed to support multiple hierarchies where MEC servers can be placed between the core and the base station or nodeB (gNB). It should be recognized that MEC is equally applicable to 4G networks.

[0024] 5G may also utilize satellite communications to enhance or complement the coverage of 5G services, for example by providing backhaul. Possible use cases are to provide service continuity for machine-to-machine (M2M) or Internet of Things (IoT) devices, or for passengers on board, or to ensure service availability for critical communications and future rail, maritime, and / or aeronautical communications. Satellite communications may utilize geostationary Earth orbit (GEO) satellite systems as well as low Earth orbit (LEO) satellite systems, especially mega-constellations (systems in which hundreds of (nano)satellites are deployed). A satellite 106 in a mega-constellation may cover several satellite-enabled network entities creating ground cells. The ground cells may be generated via terrestrial relay nodes 104 or by gNBs located on the ground or in the satellites.

[0025] It is clear to those skilled in the art that the illustrated system is an example of a part of a radio access system, and in practice the system may comprise multiple (e / g)NodeBs, a user device may have access to multiple radio cells, and the system may also comprise other devices such as physical layer relay nodes or other network elements. At least one of the (e / g)NodeBs may be a Home(e / g)nodeB. In addition, in a geographical area of ​​a wireless communication system, not only multiple radio cells but also multiple different types of radio cells may be provided. The radio cells may be macrocells (or umbrella cells), which are usually large cells with a diameter of up to tens of kilometers, or smaller cells such as microcells, femtocells, or picocells. The (e / g)NodeB in FIG. 1A may provide any type of these cells. A cellular radio system may be implemented as a multi-layer network including several types of cells. Usually, in a multi-layer network, one access node provides one or more cells of one type, so multiple (e / g)NodeBs may be required to provide such a network structure.

[0026] To meet the need to improve the deployment and performance of communication systems, the concept of "Plug and Play" (e / g) NodeB was introduced. Typically, a network that can use "Plug and Play" (e / g) NodeB includes a Home (e / g) NodeB (H(e / g)nodeB) as well as a Home nodeB Gateway or HNB-GW (not shown in FIG. 1A). Typically, the HNB Gateway (HNB-GW), installed in an operator's network, can aggregate traffic from multiple HNBs back to a core network. The network discussed herein may refer to a cellular network, such as 5G, for example.

[0027] 1A, the UEs 100, 102 (and / or any other UEs in the described system) may support device-to-device (D2D) communication. D2D communication may often be referred to as sidelink communication.

[0028] One of the development goals in NR is the Multicast-Broadcast Service (MBS), or MBS. MBS may comprise either or both of multicast and broadcast transmissions. MBS services may be provided to UEs, for example, by network node 104, as point-to-point (PtP) or point-to-many (PtM) transmissions. The former may often be referred to as unicast transmissions, and the latter may be referred to as multicast transmissions. Furthermore, MBS may be provided to UEs in a dual connectivity (DC) scenario, where one UE may be connected to two or more network nodes that provide one or more services to the UE. For example, in DC, there may be a master network node (simply master node (MN)) and a secondary network node (simply secondary node (SN)) controlled by the master network node (or other entity), and the MN and SN work together to provide the MBS to the UE. The MN and SN may be similar to those described with respect to FIG. 1A (see, for example, node 104). For example, the MN and SN may both be connected to the UE and provide substantially the same or different services to the UE. The MBS may often be referred to as 5MBS. In particular, such terms may be used for MBS provided in, for example, a 5G or NR system.

[0029] 1B and 1C show some examples of wireless communication system architectures to which the embodiments may be applied. SDAP may refer to Service Data Application Protocol, PDCP may refer to Packet Data Convergence Protocol, RLC may refer to Radio Link Control, MAC may refer to Medium Access Control, and PHY may refer to the physical layer. S may refer to the location in the protocol stack where data duplication and forwarding (i.e., switching) takes place. Data flow is represented by arrows showing the direction of data flow in different protocol layers from SDAP to PHY.

[0030] 1B, an alternative example 1 of a Layer 2 (L2) architecture is shown that uses a DRB for PtP transmissions and an SC-MRB for PtM transmissions. The network may configure a DRB for at least one UE in a multicast group and one SC-MBR for the multicast group (i.e., per session).

[0031] Referring to FIG. 1C, for split bearer, L2 architecture alternative 2 is shown using SC-MRB for both PtP and PtM transmission, i.e., PDCP PDUs can be transmitted on either the PtP leg or the PtM leg of the bearer. At least one leg of the SC-MRB bearer can have its own RLC entity. It should be noted that for the F1-U interface, L2 architecture alternative 1 can utilize F1-U tunnels not only for at least one SC-MRB but also for at least one radio bearer, i.e., at least one DRB. For L2 architecture alternative 2, if the data duplication and forwarding function is in the DU, one shared F1-U tunnel can be used.

[0032] It should be noted that the exemplary architectures of FIGS. 1B and 1C should be understood as examples, and other types of architectures may be utilized to which the embodiments may be applied.

[0033] Therefore, in general, MBS may be provided to UE in DC scenario. For example, UE utilizing a certain MBS may be served by MN. It may be advantageous to change the serving node to SN. Therefore, it may be beneficial to further develop a solution that enhances dynamic switching of serving nodes for providing MBS to UE. For example, switching may be performed between PtP transmission and PtM transmission.

[0034] FIG2 shows a flow diagram according to an embodiment. Referring to FIG2, a method is provided for a second network node of a wireless communication network, the method comprising: receiving a message from a first network node configured to provide an MBS for a UE, the message comprising an identifier identifying the MBS and at least one data flow identifier corresponding to at least one data flow for providing the MBS to be offloaded from the first network node to the second network node (block 202); determining whether a tunnel exists between the second network node and a user plane function associated with the MBS identifier (block 204); sending a response message to the first network node indicating whether a new tunnel for the MBS is requested to be established based on the determination (block 206); and utilizing the existing tunnel or the new tunnel requested to be established to provide the MBS (block 208).

[0035] Figure 3 shows a flow diagram according to an embodiment. Referring to Figure 3, a method is provided for a first network node of a wireless communication network, the method comprising: determining to offload at least one data flow for providing an MBS provided for a UE to a second network node (block 302); transmitting a message to the second network node, the message comprising an identifier identifying the MBS and at least one data flow identifier corresponding to the at least one data flow to be offloaded from the first network node to the second network node (block 304); receiving a response message from the second network node indicating whether a new tunnel is requested to be established between the second network node and a user plane function for providing the MBS (block 306); and initiating establishment of the new tunnel if the new tunnel is requested to be established (block 308).

[0036] The described methods of Figures 2 and 3 may be applicable, for example, in the system of Figure 1A (i.e., wireless communication network) and in the architectures shown in Figures 1B and 1C. The UE discussed with respect to Figures 2 and 3 may be, for example, the UE 100, or the UE 102, or some other similar network device. The network node discussed with respect to Figures 2 and 3 may be, for example, the network node 104, or the CN 110 / CU 108, or some other network element configured to perform the described method steps. In particular, in some exemplary embodiments, the first network node may be a MN and the second network node may be a SN. The described solutions may enable a PtP to PtM switch when providing an MBS, for example, when a serving node (e.g., a first network node) decides to offload an MBS data flow (sometimes referred to as a traffic flow or an MBS traffic flow) to another node (e.g., a second network node).

[0037] The tunnel described with reference to Figures 2 and 3 may be a tunnel that enables MBS data transfer from a user plane core network node (e.g., User Plane Function (UPF)) to a network node (e.g., radio network node). That is, this tunnel may be established for a specific MBS with a specific identifier (i.e., MBS identifier) ​​between a user plane core network node (e.g., UPF) and a network node that provides the MBS to the UE. For example, a second network node and a UPF may be connected via a tunnel for the MBS. This kind of tunnel may often be referred to as an N3 tunnel. In a sense, it may be understood that the MBS may be provided to a second network node via the described tunnel, and the second network node may provide the MBS to one or more UEs. The destination of the MBS may be, for example, one or more UEs.

[0038] An identifier that identifies an MBS may often be referred to as an MBS identifier. A data flow identifier may correspond to a data flow (i.e., may identify a data flow). Thus, when multiple data flows exist or are utilized to provide an MBS, there may be one data flow identifier to identify a member of at least one data flow. Often, a data flow may be described as a quality of service (QoS) flow that is identified by a QoS flow indicator (QFI). A QFI may identify (or correspond to) a QoS flow. For example, when two MBS QoS flows (i.e., QoS flows for an MBS) are used, a first QFI may be associated with the first QoS flow and a second QFI may be associated with the second QoS flow. In this example, both the first and second QoS flows may be used to provide an MBS identified by an MBS identifier (or simply an identifier). One or more QoS flows may be used to provide a given MBS to one or more UEs. The QoS flows may utilize existing or established tunnels (e.g., N3 tunnels).

[0039] According to an embodiment, the at least one data flow described herein comprises and / or is at least one QoS flow.

[0040] As shown in block 208, for example, an existing tunnel or a new tunnel (i.e., requested to be established in block 206) may be utilized to provide the MBS to one or more UEs. Thus, if a tunnel is determined to exist (i.e., block 204), the existing tunnel may be used to provide the MBS. However, if a tunnel is determined to not exist (i.e., block 204), a new tunnel for the MBS may be requested to be established (block 206) and utilized to provide the MBS (block 208). Establishment of the tunnel may occur after the request is sent to the first network node. The first network node may then send a tunnel generation request message to a session management function (SMF).

[0041] The proposed solution may enable the use of substantially the same tunnel to provide MBS to multiple UEs. For example, if three UEs receive substantially the same MBS service, the MBS data does not need to be replicated three times through the tunnel, but needs to be transmitted once between the UPF and the network node. There may be multiple tunnels for a given node, such as one tunnel for at least one MBS provided to the UE. For example, the first network node may have a tunnel to the UPF to receive and / or transmit applicable data flows when providing an MBS to the UE 100. For example, the substantially same tunnel may be utilized by the first network node when providing the substantially same MBS to the UE 102. In the first example, the first network node may provide a PtP transmission to the UE 100, and in the latter example, a PtM to the UE 100, 102. Similarly, as presented above in the proposed method, the second network node may utilize an existing tunnel to provide MBS to multiple UEs (e.g., two or more UEs). Or, if a tunnel does not exist, a tunnel may be created and then used to provide the MBS to at least one UE (or, perhaps, later, to multiple UEs, as needed). For example, if a tunnel exists for a particular MBS, the transfer from a UE served by the MN to a UE served by the SN may be smooth. Note also that the MN is not necessarily aware that the SN already has a tunnel for the offloaded MBS. That is, the SN may provide the MBS to a UE that was offloaded to the SN from a different MN.

[0042] In an embodiment, the second network node provides a primary secondary cell (PSCell). In an embodiment, the second network node is in a PtP mode. However, the second network node may change the mode to PtM.

[0043] Some aspects will be described in detail with reference to Figures 4A to 4C, which illustrate some embodiments. First, with reference to Figure 4A, an embodiment is illustrated in which, if a request message 452 is received by the second network node 420, there is no tunnel between the UPF 430 and the second network node 420 for the MBS. That is, the second network node 420 may not provide the MBS to one or more UEs at that time. Thus, in block 452, the first network node 452 may send a request message to the second network node 420. The request message may be similar to the messages described with respect to Figures 2 and 3 (blocks 202, 304). The message may indicate that the MBS, or in particular one or more data flows of the MBS, should be offloaded from the first network node 410 to the second network node 420, and may further indicate the MBS to be offloaded. Thus, the first network node may indicate in the message that the offloaded data flow is for the MBS. Thus, the message may be sent by the first network node 410 after and / or in response to a determination that the MBS should be offloaded to the second network node 420. The first network node 410 may decide to offload the MBS based on, for example, a load at the first network node exceeding a threshold, or the second network node 420 having excess capacity. The sending of the request message in block 452 may comprise a DC bearer setup, in which the first network node 410 sets up a DC bearer in a radio cell provided by the second network node 420. The first network node 410 may inform the second network node 420 that the offloaded QoS flow is for an MBS unicast and provide the second network node 420 with a corresponding MBSID (e.g., Mcast ID=1). This may enable the second network node 420 to identify that the QoS flow is for a given MBS service and detect whether a tunnel for this service already exists or not.

[0044] In an embodiment, the request message comprises an identifier (e.g., MBS identifier) ​​that identifies the MBS. For example, for a given MBS (e.g., MBS service 1), this may mean Mcast ID=1. An MBS service may comprise one or more data flows that may sometimes be referred to as and / or transmitted in a Quality of Service (QoS) flow. A QoS flow may be the smallest level of granularity at which a 5G system may differentiate user data and provide differentiated treatment (i.e., quality of service). A QoS flow may be identified by a QoS flow ID (QFI) and may have an associated QoS profile. In some exemplary embodiments, the message may comprise a list of data QoS flows and / or their associated profiles. The described message may be referred to as a request message because it may request the SN to start serving the UE with the indicated MBS. The request message may sometimes be referred to as an SN Add / Modify Request, or simply a message, as discussed with respect to FIG. 2 and FIG. 3.

[0045] At block 454, the second network node 420 may determine that a new tunnel for the MBS is needed between the second network node 420 and the UPF 430. In particular, a new tunnel may be needed to forward one or more data flows of the MBS between the second network node 420 and the UPF 430. This determination may be based on detecting that there is no tunnel for the MBS between the node 420 and the UPF 430. For example, using the MBS identifier Mcast ID=1 above, the network node 420 may determine that it does not have a tunnel for Mcast ID=1.

[0046] The second network node 420 may send a response message to the first network node at block 456. If a new tunnel is needed, as determined at block 454, the response message may indicate that a new tunnel is needed. In an embodiment, the response message is sent in response to a determination of whether a new tunnel is needed for the MBS (e.g., in response to block 454).

[0047] In an embodiment, the response message of block 456 comprises a transmission network layer information (TNLI) for establishing a new tunnel between the second network node 420 and the UPF 430. Thus, the TNLI may be used by the network to set up the new tunnel. The TNLI may comprise information about the tunnel (e.g., N3 tunnel) to be established. For example, the TNLI may comprise a tunnel endpoint IP address and a tunnel endpoint identifier. The second network node 420 may allocate a new TNLI for the MBS (i.e., if no tunnel exists for the offloaded MBS) and indicate the allocated TNLI to the first network node 410 to set up the new tunnel.

[0048] The response message may often be referred to as a SN Addition / Modification Request Acknowledge message. In some embodiments, the message includes a list of MBS QoS flows that may be accepted by the second network node 420. In some embodiments, the message may indicate the accepted QoS flows, including the TNLI used for the tunnel to be set up along with the mapped DRB. Note that the DRB may be indicated, for example, if architecture alternative 1 (see FIG. 1B) is used. The accepted QoS flows may indicate substantially the same QoS flows or a subset of the QoS flows requested to be offloaded to the second network node 420. In some cases, a subset of the requested flows may be accepted by the second network node 420, and the remaining flows may be provided by the first network node 410 or offloaded to other network nodes. However, if at least one data flow (or simply referred to as an MBS data flow) configured to be used to provide MBS is accepted by the second network node 420, a tunnel may still be established between the second network node 420 and the UPF 430.

[0049] At block 458, the first network node 410 may initiate establishment of the requested new tunnel by sending a tunnel creation request to the session management function (SMF) 440. In an embodiment, the tunnel creation request comprises the TNLI received from the second network node 420 via the response message sent at block 456. In some example embodiments, the tunnel creation request is a protocol data unit (PDU) session change indication message.

[0050] In block 460, the SMF 440 may request the UPF 430 to create a tunnel using the received TNLI. The creation of the tunnel 462 between the second network node 420 and the UPF 430 may comprise creating a bearer for the tunnel, as shown in block 460. The tunnel may be created by the UPF 430 according to the TNLI indicated by the second network node 420 to the first network node 410 and reported from the node 410 to the SMF 440 and from the SMF 440 to the UPF 430. The created tunnel 462 may be used by the second network node 420 to provide MBS to one or more UEs.

[0051] In block 464, the SMF 440 may acknowledge receipt of the tunnel creation request 458 and successful creation of the tunnel by the UPF 430 to the first network node 410 by sending a response to the tunnel creation request.

[0052] Next, refer to FIG. 4B, which illustrates some embodiments where a tunnel for an offloaded MBS (block 470) already exists, when a request message is received (block 472). The request message of block 472 may be the same or substantially the same as block 452. That is, a particular MBS may be indicated in the message, and the MBS may be offloaded to the second network node 420.

[0053] At block 474, the second network node 420 may determine that a tunnel for the MBS to be offloaded already exists between the node 420 and the UPF 430. The tunnel may have been created, for example, prior to receiving the request message at block 474. The tunnel may have been created, for example, to provide the MBS to some other UEs based on a request message (e.g., the same as block 452 or block 472) received from another network node (e.g., a third network node).

[0054] In block 476, the second network node 420 may send a response message to the first network node 410. The message may indicate that a tunnel for the MBS already exists. In other words, this may mean that the message indicates that a new tunnel is not requested to be established.

[0055] In an embodiment, the response message of block 476 comprises a TNLI corresponding to an existing tunnel for the MBS and / or an additional indicator for indicating that a new tunnel for the MBS is not requested to be established. The additional indicator may be, for example, a flag, such as a one-bit indicator. The TNLI may be understood to be, for example, the TNLI of an existing tunnel. The additional indicator may simply be referred to as an indicator for indicating that a new tunnel for the MBS is not requested to be established. An indicator may be used independently or together with the TNLI to indicate that a new tunnel is needed (e.g., a tunnel for the TNLI already exists). As mentioned above, it may not be necessary to indicate the TNLI, but in some cases it may be beneficial.

[0056] In an embodiment, the response message of block 476 is generated to not include the TNLI in the existing tunnel, i.e., the message may not have a TNLI or at least may not be in the existing tunnel (i.e., tunnel 470).

[0057] The message of block 476 may sometimes be referred to as a SN addition / modification request acknowledge message and may further include a list of MBS flows that may be accepted.

[0058] Based on the response message of block 476, the first network node 410 may determine that a new tunnel is not required to perform DC offloading of the MBS.

[0059] In an embodiment, the first network node 410 sends an indication to the SMF 440 in block 478 indicating the TNLI and an additional indicator or no TNLI. However, this is not always necessary in the described embodiment. Instead, the first network node 410 may not send this PDU session modification indication message because no new tunnel is set up. In either case, the SMF 440 may determine, based on the sent or not sent indication, that no new tunnel is needed and therefore may not request the UPF 430 to open an additional tunnel for the second network node 420.

[0060] Thus, in an embodiment, the first network node 410 determines based on the response message (block 476) that a tunnel for the MBS already exists between the second network node and the user plane function, and indicates to the SMF 440 based on the determination that a tunnel for the MBS already exists between the second network node 420 and the user plane function 430. This indication may comprise sending an indication (see, e.g., block 478) or may be an implicit indication. That is, the first network node 410 may prevent sending a tunnel creation request to the SMF 440. Even if a PDU session modification indication message is sent, it may not be a tunnel creation request in that it does not request the creation of a new tunnel. That is, in one example, the message may be sent without including the transport network layer information, as already discussed above. In another example, the message may be sent including the transport network layer information and an additional indicator (e.g., a flag) to indicate that a new tunnel for the MBS is not requested to be established. That is, a tunnel for the indicated TNLI already exists. In another example, the message may be sent without the transport network layer information and with an additional indicator (e.g., a flag) to indicate that a new tunnel for the MBS is not requested to be established.

[0061] In an embodiment, the first network node 410's determination that the tunnel exists is based on the response message comprising a TNLI on the tunnel and an additional indicator to indicate that a new tunnel for the MBS is not requested to be established.

[0062] In an embodiment, the determination by the first network node 410 that the tunnel exists is based on a response message that does not include a TNLI for the tunnel.

[0063] FIG. 4C illustrates an embodiment. Referring to FIG. 4C, in block 482, the first network node 410 may send a tunnel release request to the SMF 440 in response to and / or after determining that the first network node 410 no longer serves a UE for a given MBS. That is, for example, if the first network node 410 no longer serves any UE after offloading the MBS to the second network node 420 (as in FIG. 4A and FIG. 4B), the tunnel may no longer be needed between the first network node 410 and the UPF 430. Thus, the tunnel may be released. The release request may sometimes be referred to as a PDU session change indication. The tunnel release request may comprise a TNLI associated with the tunnel to be released, i.e., the TNLI may indicate the tunnel to be released. Based on this request, the SMF 440 may communicate with the UPF 430 to release the tunnel, for example, by removing the bearer (block 484). The SMF 440 may further acknowledge receipt of the tunnel release request, or at least the request, to the first network node 410 (block 486).

[0064] At this point, it should be noted that the request messages sent in FIGS. 4A and 4B (blocks 452 and 472) may be sent by one or more MNs for one or more UEs.

[0065] 5, a related embodiment is shown when a UE leaves a cell provided by a second network node 420 that provides the MBS or serves the UE with the MBS. That is, as shown in block 502, the second network node 420 may have a tunnel between the second network node 420 and the UPF 430 to provide the MBS to at least two UEs. For simplicity, it is assumed that there are two UEs: UE1 and UE2, for which a tunnel for the MBS is established.

[0066] The first network node may determine, for example, based on an indication received from the SMF 440 in block 504, that at least one data flow configured to be used to provide an MBS for a served UE needs to be released. In this example, the UE may be UE1. The MBS to be released may be indicated in the message of block 504, for example, by using an MBS identifier of the MBS. In some embodiments, the message of block 504 is transmitted as a PDU session modification request message. Said message may thus request the second network node 420 to release the MBS bearer for UE1 (i.e., for the given MBS).

[0067] In block 506, the first network node 410 may send a release request to the second network node 420. The release request may indicate that at least one data flow configured to be used to provide the MBS needs to be released, i.e., the MBS service for UE1 needs to be released. The release request may indicate the data flow to be released, or simply the MBS to be released, for example using an MBS identifier.

[0068] The second network node 420 may receive, for UE1, a request to release at least one data flow associated with the MBS and may release the at least one data flow in accordance with the request (block 508).

[0069] However, in block 510, the second network node 420 may determine the need to continue using the tunnel 502 between the second network node 420 and the UPF 430 to provide the MBS to at least one other UE. In this example, the UE may be UE2. This determination may be performed after releasing the MBS service.

[0070] Thus, in block 512, the second network node 420 may indicate to the first network node 410 the need to continue using said tunnel 502. This indication may comprise, for example, a TNLI so that the correct tunnel may be identified and / or a flag indicating the continued need for the tunnel, i.e. that the existing tunnel should not be released.

[0071] The first network node 410 may receive the indication and further indicate the need to the SMF 440 (block 514). The indication may comprise, for example, a TNLI such that the correct tunnel may be identified and / or a flag indicating the continued need for the tunnel. Thus, the SMF 440 may prevent the UPF 430 from requesting to terminate or release the tunnel 502. Thus, the UE2 may continue to be served in MBS by the second network node 420. The indication of block 514 may comprise sending a message to the SMF as described above or may be an implicit indication. For example, the first network node 410 may prevent sending a tunnel release request to the SMF 440. That is, the SMF 440 may be configured to operate in response to receiving an explicit message requesting release to initiate the release of the tunnel. Thus, if no such message / request is received, the SMF 440 may not release or terminate one or more tunnels.

[0072] Therefore, even if UE1 leaves the MBS service at the second network node 420, the second network node 420 may not release the tunnel and continue to provide service to UE2 using the tunnel.

[0073] According to an aspect, a method is provided for a session management entity, the method comprising receiving from a first network node 410 a tunnel generation request without a TNLI or with a TNLI and an additional indicator (e.g., a flag) to indicate that a new tunnel for the MBS is not requested to be established, determining based on the request that a tunnel already exists between a user plane entity of the MBS and a second network node 420, and preventing initiation of establishment of the new tunnel between the user plane entity and the second network node 420 based on the determination.

[0074] As used herein, the SMF 440 may often be referred to simply as a session management entity, and the UPF 430 may be referred to as a user plane entity.

[0075] Some advantages of the proposed solution may include at least the following:

[0076] When an MBS with MBS ID=1 is offloaded to an SN using DC, the MN may not need to request the SMF to create a tunnel between the UPF and the SN if the SN is already included in the requested MBS ID=1. Here, included may mean that the SN already provides the MBS with ID=1 to some other UE or UEs. Of course, the ID may be different from 1, which is used as an example in this specification.

[0077] ●When an MBS is offloaded back to the MN (e.g. because the UE leaves MBS service 1), the MN may not request the SMF to release the tunnel between the UPF and the SN if the SN is still included in the MBS service, i.e., if it still continues to provide MBS ID=1 to some other UE or UEs.

[0078] 6 and 7 provide apparatus 600, 700 comprising control circuitry (CTRL) 610, 710 such as at least one processor, and at least one memory 630, 730 containing computer program code (software) 632, 732, the at least one memory and the computer program code (software) 632, 732 being configured, using the at least one processor, to cause the respective apparatus 600, 700 to perform any one of the embodiments of Figures 1A to 5, or operations thereof.

[0079] 6 and 7, the memory 630, 730 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 and removable memory, etc. The memory 630, 730 may include a database 634, 734 for storing data.

[0080] The device 600, 700 may further comprise a radio interface (TRX) 620, 720 comprising hardware and / or software for realizing a communication connection according to one or more communication protocols. The TRX may provide the device with communication capabilities for accessing, for example, a radio access network. The TRX may comprise standard well-known components such as amplifiers, filters, frequency converters, (de)modulators, and encoder / decoder circuitry, as well as one or more antennas. The TRX may provide, for example, access to F1 and / or Xn interfaces and / or provide UL / DL communication capabilities. Additionally, the TRX may provide D2D capabilities for the UE. For example, the TRX may enable tunnels for MBS, such as N3 tunnels.

[0081] The devices 600, 700 may include a user interface 640, 740 comprising, for example, at least one keypad, microphone, touch display, display, speaker, etc. The user interface 640, 740 may be used by a user of the devices 600, 700 to control the respective devices.

[0082] In an embodiment, the apparatus 600 may be or may be included in a second network node that performs the method described above, for example with respect to Figure 2. For example, the apparatus 600 may be or may be included in the network node 104. The apparatus 600 may be or may be included in an SN.

[0083] In an embodiment, the apparatus 700 may be or may be included in a first network node that performs the method described above, for example with respect to Figure 3. For example, the apparatus 700 may be or may be included in the network node 104. The apparatus 700 may be or may be included in a MN.

[0084] According to an embodiment, and referring to FIG. 6 , control circuitry 610 comprises receiving circuitry 612 configured to perform at least the operations described with respect to block 202 of FIG. 2 , determining circuitry 614 configured to perform at least the operations described with respect to block 204 of FIG. 2 , transmitting circuitry 616 configured to perform at least the operations described with respect to block 206 of FIG. 2 , and utilization circuitry 618 configured to perform at least the operations described with respect to block 208 of FIG. 2 .

[0085] According to an embodiment, and referring to FIG. 7, control circuitry 710 comprises determining circuitry 712 configured to perform at least the operations described with respect to block 302 of FIG. 3, transmitting circuitry 714 configured to perform at least the operations described with respect to block 304 of FIG. 3, receiving circuitry 716 configured to perform at least the operations described with respect to block 306 of FIG. 3, and initiating circuitry 718 configured to perform at least the operations described with respect to block 308 of FIG. 3.

[0086] In an embodiment, at least some of the functions of the apparatus 600, 700 may be shared between two physically separate devices to form one operational entity. Thus, the apparatus 600, 700 may be considered to be indicative of an operational entity comprising one or more physically separate devices for performing at least some of the described processes. Thus, the apparatus 600, 700 utilizing such a shared architecture may comprise a remote control unit (RCU), such as a host computer or a server computer, operably coupled (e.g., via a wireless or wired network) to a remote radio head (RRH) located at, for example, a base station or a network node 104. In an embodiment, at least some of the described processes 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, a CU / DU split may utilize such a shared architecture.

[0087] In an embodiment, the RCU may generate a virtual network through which the RCU communicates with the RRH. In general, virtual networking may include a process of combining hardware and software network resources and network functions into a single software-based management entity, a virtual network. Network virtualization may often include platform virtualization combined with resource virtualization. Network virtualization may be classified as external virtual networking, which combines many networks or parts of networks into a server computer or a host computer (i.e., into the RCU). External network virtualization targets optimized network sharing. Another category is internal virtual networking, which provides network-like capabilities to software containers on a single system.

[0088] In an embodiment, the virtual network may provide flexible distribution of operations between the RRH and the RCU. In practice, any digital signal processing task may be performed in either the RRH or the RCU, and the boundary at which responsibility is shifted between the RRH and the RCU may be selected depending on the implementation.

[0089] According to an aspect, a system is provided comprising one or more apparatuses 600 and one or more apparatuses 700. In an embodiment, the system further comprises one or more UEs. In an embodiment, the system further comprises an SMF and a UPF.

[0090] The term "circuitry" as used herein may refer to (a) hardware circuit implementations, such as implementations in analog and / or digital circuitry; (b) (where applicable) combinations of circuits and software (and / or firmware), such as (i) a combination of a processor, or (ii) a portion of a processor / software including a digital signal processor, software, and memory that cooperate to cause a device to perform various functions; and (c) circuits, such as a microprocessor or a portion of a microprocessor that utilizes software or firmware for operation, even when the software or firmware is not physically present. This definition of "circuitry" applies to the use of the term in this application. As a further example, as used herein, the term "circuitry" also covers merely a processor (or processors) or a portion of a processor and its (or their) associated software and / or firmware implementations. The term "circuitry" would also cover, for example, a baseband integrated circuit or an application processor integrated circuit for a mobile phone, or a similar integrated circuit in a server, a cellular network device, or another network device, if applicable to the particular element.

[0091] In an embodiment, at least some of the processes described in connection with Figures 1A to 5 may be performed by an apparatus comprising corresponding means for performing at least some of the described processes. Some exemplary means for performing a process may include at least one of a detector, a processor (including dual-core and multi-core processors), a digital signal processor, a controller, a receiver, a transmitter, an encoder, a decoder, a memory, a RAM, a ROM, software, firmware, a display, a user interface, a display circuitry, a user interface circuitry, a user interface software, a display software, a circuit, an antenna, an antenna circuitry, and a circuitry. In an embodiment, at least one processor, a memory, and a computer program code form a processing means or comprise one or more computer program code portions for performing one or more operations according to any of the embodiments of Figures 1A to 5 or their operations.

[0092] According to yet another embodiment, an apparatus for carrying out the embodiments comprises circuitry including at least one processor and at least one memory containing computer program code, which when activated causes the apparatus to perform a function or at least some of the operations according to any one of the embodiments of Figures 1A to 5.

[0093] 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. In the case of a hardware implementation, the apparatus of the embodiments may be implemented in 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, microcontrollers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. In the case of firmware or software, the implementation may be performed via modules (e.g., procedures, functions, etc.) of at least one chipset that performs the functions described herein. The software code may be stored in a memory unit and executed by the processor. The memory unit may be implemented within the processor or external to the processor. In the latter case, the memory unit may be communicatively coupled to the processor via various means as known in the art. In addition, the system components described herein may be reconfigured and / or supplemented with additional components to facilitate accomplishment of various aspects, etc., described with respect to the system components, and the system components are not limited to the precise configurations described in the given figures, as will be understood by those skilled in the art.

[0094] The described embodiments may also be implemented in the form of a computer process defined by a computer program or a portion thereof. The method embodiments described in relation to Figures 1A to 5 may be implemented by executing at least a portion of a computer program comprising corresponding instructions. The computer program may be in source code form, object code form, or any intermediate form, and may be stored on any type of carrier, which may be any entity or device capable of transmitting a program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or processor. The computer program medium may be, for example, but is not limited to, a recording medium, a computer memory, a read-only memory, an electrical carrier signal, an electrical communication signal, and a software distribution package. The computer program medium may be, for example, a non-transitory medium. Coding software to execute the illustrated and described embodiments is well within the scope of one skilled in the art. In an embodiment, a computer readable medium comprises said computer program.

[0095] Although the present invention has been described above with reference to examples according to the accompanying drawings, it is clear that the present invention is not limited thereto and can be modified in several ways within the scope of the appended claims. Therefore, the words and expressions in this specification should be interpreted broadly and are intended to describe, not limit, the embodiments. It will be clear to those skilled in the art that the concept of the present invention can be implemented in various ways as technology advances. Moreover, it is clear to those skilled in the art that the described embodiments can be combined with other embodiments in various ways, although not necessarily.

[0096] Abbreviation 5MBS 5G Multicast Broadcast Service DC Dual Connection MBS Multicast Broadcast Service MN Master Node QoS Quality of Service QFI QoS Flow Identifier TNLI Transmission Network Layer Information SC-MRB Single Cell Multicast Radio Bearer SN Secondary Node PSCell Primary Secondary Cell UE User Equipment

Claims

1. An apparatus comprising at least one processor and at least one memory containing program code, the at least one memory and computer program code configured to, using the at least one processor, transmit to a second network node of a wireless communications network: receiving a message from a first network node configured to provide a multicast-broadcast service (MBS) for a user equipment (UE), the message comprising an MBS identifier identifying the MBS and at least one data flow identifier corresponding to at least one data flow for providing the MBS to be offloaded from the first network node to the second network node; determining whether a tunnel exists between the second network node and a user plane entity, the tunnel being associated with the MBS identifier; sending a response message to the first network node indicating whether a new tunnel for the MBS is requested to be established based on the determination; utilizing existing tunnels or the new tunnels requested to be established to provide the MBS; An apparatus configured to perform the operations comprising:

2. 2. The apparatus of claim 1, wherein if the tunnel does not exist between the second network node and the user plane entity associated with the MBS identifier, the response message comprises transport network layer information for establishing a tunnel between the second network node and the user plane entity.

3. 2. The apparatus of claim 1, wherein if the tunnel exists between the second network node and the user plane entity associated with the MBS identifier, the response message comprises transport network layer information corresponding to the existing tunnel and / or an indicator to indicate that a new tunnel for the MBS identifier is not requested to be established.

4. 2. The apparatus of claim 1, wherein if the tunnel exists between the second network node and the user plane entity associated with the MBS identifier, the response message is generated to not include transport network layer information regarding the existing tunnel.

5. The at least one memory and the computer program code are configured to, using the at least one processor, cause the second network node to: receiving a request from the first network node for a served UE to release at least one data flow configured to be used for providing the MBS for the served UE; Releasing said at least one data flow in accordance with said request; The apparatus of claim 1 , further configured to perform an operation comprising:

6. 1. An apparatus comprising at least one processor and at least one memory containing program code, the at least one memory and the computer program code being configured to, using the at least one processor, transmit to a first network node of a wireless communications network: - determining to offload to a second network node at least one data flow for providing a multicast-broadcast service MBS provided for a user equipment UE; sending a message to the second network node, the message comprising an MBS identifier identifying the MBS and at least one data flow identifier corresponding to the at least one data flow to be offloaded from the first network node to the second network node; receiving a response message from the second network node indicating whether a new tunnel is requested to be established between the second network node and a user plane entity to provide the MBS; if said new tunnel is requested to be established, initiating establishment of said new tunnel; An apparatus configured to perform the operations comprising:

7. The apparatus of claim 6 , wherein the initiating the establishment of the new tunnel comprises sending a tunnel creation request to a session management entity.

8. 8. The apparatus of claim 7, wherein if the new tunnel is requested to be established, the response message comprises transport network layer information for establishing the new tunnel between the second network node and the user plane entity.

9. The apparatus of claim 8 , wherein the tunnel creation request comprises the transport network layer information received from the second network node.

10. The at least one memory and the computer program code are configured to, using the at least one processor, cause the first network node to: determining, based on the response message, that a tunnel for the MBS already exists between the second network node and the user plane entity; indicating to the session management entity that the tunnel for the MBS already exists between the second network node and the user plane entity based on the determining; The apparatus of claim 7 , further configured to perform the operations comprising:

11. A method for a second network node of a wireless communications network, comprising: receiving a message from a first network node configured to provide a multicast-broadcast service (MBS) for a user equipment (UE), the message comprising an MBS identifier identifying the MBS and at least one data flow identifier corresponding to at least one data flow for providing the MBS to be offloaded from the first network node to the second network node; determining whether a tunnel exists between the second network node and a user plane entity, the tunnel being associated with the MBS identifier; sending a response message to the first network node indicating whether a new tunnel for the MBS is requested to be established based on the determination; utilizing existing tunnels or the new tunnels requested to be established to provide the MBS; A method comprising:

12. 12. The method of claim 11 , wherein if the tunnel does not exist between the second network node and the user plane entity associated with the MBS identifier, the response message comprises transport network layer information for establishing a tunnel between the second network node and the user plane entity.

13. 12. The method of claim 11, wherein if the tunnel exists between the second network node and the user plane entity associated with the MBS identifier, the response message comprises transport network layer information corresponding to the existing tunnel and / or an indicator to indicate that a new tunnel for this MBS identifier is not requested to be established.

14. 12. The method of claim 11, wherein if the tunnel exists between the second network node and the user plane entity associated with the MBS identifier, the response message is generated such that it does not include transport network layer information regarding the existing tunnel.

15. receiving a request from the first network node for a served UE to release at least one data flow configured to be used for providing the MBS for the served UE; Releasing said at least one data flow in accordance with said request; The method of claim 11 further comprising:

16. A method for a first network node of a wireless communication system, comprising: - determining to offload to a second network node at least one data flow for providing a multicast-broadcast service MBS provided for a user equipment UE; sending a message to the second network node, the message comprising an MBS identifier identifying the MBS and at least one data flow identifier corresponding to the at least one data flow to be offloaded from the first network node to the second network node; receiving a response message from the second network node indicating whether a new tunnel is requested to be established between the second network node and a user plane entity to provide the MBS to the UE; if said new tunnel is requested to be established, initiating establishment of said new tunnel; A method comprising:

17. 17. The method of claim 16, wherein the initiating the establishment of the new tunnel comprises sending a tunnel creation request to a session management entity.

18. 18. The method of claim 17, wherein if the new tunnel is requested to be established, the response message comprises transport network layer information for establishing the new tunnel between the second network node and the user plane entity.

19. 20. The method of claim 18, wherein the tunnel creation request comprises the transport network layer information received from the second network node.

20. determining, based on the response message, that a tunnel for the MBS already exists between the second network node and the user plane entity; indicating to the session management entity that the tunnel for the MBS already exists between the second network node and the user plane entity based on the determining; 20. The method of claim 17, further comprising:

Images