Access network node, second communication node and methods thereof

Abstract

A method is disclosed in which a User Equipment (UE) receives, from an access network node, information including configuration information for a multicast or broadcast service and a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, each identifier of the plurality of different identifiers being associated with a multicast or broadcast service but with a different respective network of a plurality of networks sharing the access network node.

Description

[Technical Field]

[0001] The present disclosure relates to communication systems. [Background technology]

[0002] The present disclosure has particular relevance to, but is not limited to, wireless communication systems and devices operating in accordance with 3rd Generation Partnership Project (3GPP®) standards or equivalent standards or derivatives thereof (including LTE-Advanced, Next Generation or 5G networks, future generations, and beyond). The present disclosure also has particular relevance, although not necessarily exclusive, to providing multimedia broadcast sessions in shared access networks operating in accordance with, for example, so-called "5G" (or "Next Generation") systems.

[0003] Previous developments in 3GPP standards include what are known as the Long Term Evolution (LTE) of the Evolved Packet Core (EPC) network and the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), also commonly referred to as “4G.” More recently, the terms “5G” and “New Radio” (NR) have been used to refer to evolving communications technologies that are expected to support a variety of applications and services, such as MTC / IoT communications, vehicular communications and autonomous vehicles, high-definition video streaming, and / or smart city services. Various details of 5G networks are described, for example, in the “NGMN 5G White Paper” V1.0 by the Next Generation Mobile Network (NGMN) Alliance, available at https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G through the so-called 3GPP Next Generation (NextGen) Radio Access Network (RAN) and the 3GPP Next Generation Core Network.

[0004] Under 3GPP standards, a NodeB (or eNB in ​​LTE, gNB in ​​5G) is a Radio Access Network (RAN) node (or simply "access node," "access network node," or "base station") through which communication devices (user equipment or "UE") connect to the core network and communicate with other communication devices or remote servers. Communication between UEs and base stations is controlled using the so-called Radio Resource Control (RRC) protocol. For simplicity, this application uses the term (R)AN node or base station to refer to any such access node.

[0005] In current 5G architectures, for example, a RAN node may be divided into two parts known as a Central Unit (CU) and a Distributed Unit (DU), connected by an F1 interface. This enables the use of a “split” architecture, whereby the “upper” CU layer (e.g., but not necessarily or exclusively), a Packet Data Convergence Protocol (PDCP) layer, and the “lower” DU layer (e.g., but not necessarily or exclusively, a Radio Link Control (RLC), Media Access Control (MAC), and / or Physical (PHY) sublayer) are implemented separately. Thus, for example, in each of the RAN nodes, the upper layer CU functions of some RAN nodes may be implemented centrally (e.g., by a single processing unit or in a cloud-based or virtualized system), while keeping the lower layer DU functions local.

[0006] For simplicity, this application uses the terms mobile device, user device, or UE to refer to any communication device that can connect to a core network via one or more base stations. While this application may refer to a mobile device in the description, it will be understood that the described techniques can be implemented in any communication device (mobile and / or generally fixed) that can connect to a communication system to transmit / receive data, regardless of whether such communication device is controlled by human input or software instructions stored in memory. For example, such communication devices may be human-operable or may be partially or fully automated (e.g., Machine-Type-Communication (MTC) / Internet of Things (IoT)) devices.

[0007] One of the more recent technologies being developed within the existing 5G framework is called Multicast and Broadcast Service (MBS), or "NR MBS" in 5G, which aims to reuse cellular infrastructure, such as so-called Low Power Low Tower (LPLT) infrastructure. This technology aims to enhance the performance of 5G New Radio and the 5G Core Network (5GC) to deploy a variety of multicast and broadcast services reliably, with low latency, resource efficiency, and at scale. MBS is designed to use existing (or already specified) 3GPP infrastructure, but can provide more efficient delivery of multicast / broadcast traffic than unicast communications using the same infrastructure. Among the many use cases that can benefit from resource-efficient delivery of multicast / broadcast services in the context of typical MBS services over 5G systems are public safety and mission-critical applications, vehicle-to-everything (V2X) applications, Internet Protocol Television (IPTV), live video, and software distribution over the air and IoT applications. Two delivery modes, MBS, have been agreed upon in previous 3GPP releases: delivery mode 1 (only for multicast) that can accommodate higher Quality-of-Service (QoS) services, and delivery mode 2 (only for broadcast) that focuses on lower QoS services. While previous 3GPP release versions of MBS provided the basic functionality required to support MBS services, there is nevertheless a continuing need to improve the functionality to enable better deployment of MBS (e.g., improved resource efficiency and / or capacity).

[0008] 3GPP is working on enhancements to improve resource efficiency for MBS reception in scenarios where RANs are shared among multiple Public Land Mobile Networks (PLMNs). Such RAN sharing is becoming increasingly common as operators seek to reduce capital expenditures (CapEx). Two well-known RAN sharing solutions are known as Multi Operator Core Network (MOCN) RAN sharing and Multi Operator RAN (MORAN) RAN sharing. In the case of MORAN, the physical infrastructure of the RAN (e.g., physical antennas, towers, installation locations, power sources, etc.) is shared between two or more operators, but the communication spectrum is not. In contrast, MOCN involves two or more core networks that share the same physical RAN, including the communication spectrum. Nevertheless, the existing core networks may remain separate. MOCN is generally more resource-efficient because it gives operators the opportunity to pool their spectrum allocations, resulting in improved efficiency.

[0009] RAN sharing does not require broadcast / multicast of the same content over multiple PLMNs, which may be useful, for example, for connected vehicles, TV streaming, among other things. RAN sharing allows UEs (e.g., vehicles) of multiple operators to receive MBS sessions (e.g., V2X MBS sessions) from the same PLMN. In the case of TV streaming, RAN sharing enables multicast / broadcast of TV content by one operator. It will be understood that in other (previous or later) generation communication technologies, functionality broadly corresponding to 5G Multicast and Broadcast Service (MBS) may be referred to differently, and references to "MBS" should be understood accordingly as relating to any such technology. For example, functionality corresponding to MBS in LTE is a PLMN-specific service and is referred to as Multimedia Broadcast / Multicast Service (MBMS).

[0010] In addressing the issue of introducing MBS in the context of RAN sharing, it is agreed that procedures based on the assumption that MOCN RAN nodes can identify the same MBS service based on information provided by the core network (e.g., 5GC) should be supported. When considering what information should be provided by the core network, the following principles should be taken into account:

[0011] From the core network perspective, the following principles should be considered: Any procedures provided for RAN sharing should not have any impact (or should have minimal impact) on UE or base station technology operating in accordance with previous standard releases. Any identity for providing reference to the same MBS service should not depend on temporarily participating shared operators (e.g., shared operators that occasionally move in and out of a common ongoing MBS session). In particular, any new procedures must be robust enough to cover the possibility that shared PLMNs start and stop MBS sessions at the same time and at different times.

[0012] Currently, NG-RAN nodes only inform the Access and Mobility Management Function (AMF) of the supported PLMNs, and there is no coordination with the Multicast / Broadcast Session Management Function (MB-SMF) / Application Function (AF) / Multicast / Broadcast Service Function (MBSF), so the new procedures should not be based on the assumption that the MB-SMF, AF, and / or MBSF know which NG-RAN nodes (or which cells of an NG-RAN node) are shared.

[0013] MBS is permitted for UEs operating in RRC idle mode (i.e., for UEs without an active / specific data connection with the network). Each UE interested in MBS monitors system information broadcast by nearby base stations and determines the resources to be used for the associated MBS Control Channel (MCCH) and MBS Data Channel (MTCH). Base stations also broadcast respective identifiers (MBS session identifiers or Temporary Mobile Group Identity (TMGI)) for each MBS session offered in their cell. TMGI is an MBS session identifier that uniquely identifies a particular MBS service or a session associated with that MBS service. TMGI has three parts: an MBMS service ID part, a Mobile Country Code (MCC) part, and a Mobile Network Code (MNC) part. Thus, effectively, the TMGI contains a specific PLMN ID (PLMN ID=MCC+MNC) of a single PLMN (e.g., associated with a particular Mobile Network Operator (MNO) and / or Mobile Virtual Network Operator (MVNO)).

[0014] The TMGI effectively prevents unauthorized UEs from using the service. If the PLMN ID of a PLMN that the UE is authorized to use (e.g., because the UE is served by an MNO / MVNO that provides or is consented to use that PLMN) is part of the TMGI, the UE can receive the associated MBS service in that MBS session. However, a UE that is not authorized to use that PLMN (e.g., because it is served by an MNO / MVNO that is not consented to do so) cannot receive the MBS service in that MBS session. A RAN shared between different operators that provide different PLMNs is effectively part of two or more PLMNs. Thus, in this case, the UE may be able to access a cell of the shared RAN (because it is authorized to use one of the PLMNs). Nevertheless, the UE may not be able to use a particular MBS service provided in that cell (which the UE would otherwise be able to access). This is because the MBS service is only available in an MBS session provided via a different PLMN that the shared RAN is also part of but that the UE is not authorized to use.

[0015] An MBS session has an associated Point-To-Multipoint (PTM) configuration, including, for example, a Group Radio Network Temporary Identifier (G-RNTI), a list of MBS Radio Bearers (MRBs) to which the associated broadcast MBS session is mapped ("MRB list"), Discontinuous Reception (DRX) scheduling information for the MTCH ("mtch-SchedulingInfo"), an associated Physical Downlink Shared Channel (PDSCH) configuration ("pdsch-Config"), etc. A respective PTM configuration can be configured for each TMGI value in the list of TMGIs, which means that a PTM configuration associated with one TMGI can be a duplicate of a PTM configuration associated with another TMGI. Thus, each TMGI of multiple TMGIs can be associated with a copy of essentially the same PTM configuration.

[0016] Therefore, in a scenario where a RAN is shared between two (or more) operators / virtual operators, the same MBS service can be provided separately by each operator using a different respective TMGI (associated with that operator's PLMN), and each different TMGI is associated with the same PTM configuration. However, this effectively results in duplicated PTM radio resource consumption in the same cell for the transmission of the same content. Furthermore, because each 5G core operator's core network may be shared by multiple virtual operators, the number of distinct PLMN IDs, and therefore the number of TMGIs allocated for the same MBS session, may increase significantly over time. Therefore, the problem of resource usage overlap may become even more significant.

[0017] Furthermore, an MBS broadcast session may include an MCCH. However, for a particular MCCH configuration, there may be a maximum number of PTM configurations (currently 1024). Therefore, if a base station of a shared RAN configures multiple overlapping PTM configurations, each with a different respective TMGI, it is possible that too many of the maximum number of PTM configurations may be used up. Similarly, there is a maximum number of MRB configurations (currently 32) that may be added for an MBS multicast session (e.g., using the MRB-ToAddModList-r17 IE in the 5G standard). Therefore, if a base station of a shared RAN configures too many overlapping PTM configurations with the same TMGI, it is possible that too many of the maximum number of PTM configurations may be used up.

[0018] Although the possibility of using a uniform TMGI for all PLMNs (e.g., a so-called "external" TMGI, coordinated by the service layer) has been considered, it has been generally agreed that a "native" TMGI (i.e., a PLMN-specific TMGI) should be supported.

[0019] In 5G, user plane transport for a UE occurs via a radio bearer RB between the UE and the RAN and one or more General Packet Radio Service (GPRS) Tunneling Protocol (GTP) / Internet Protocol (IP) transport tunnels between the RAN and the core network. One such transport tunnel is the Next Generation User-plane (NG-U) tunnel over the so-called "N3" or "user plane" interface / reference point in the case of a distributed RAN between the RAN and the User Plane Function (UPF) in the core network. In the case of a distributed RAN, another such tunnel, the F1 User plane (F1-U) tunnel, exists over the F1 interface / reference point between the DU and the CU of the distributed base station.

[0020] To provide MBS services, one or more shared NG-U tunnels can be established to provide transport for shared MBS traffic delivery towards the base station. However, in the context of RAN sharing, the question arises as to how best to establish one or more NG-U tunnels per session and / or per PLMN. Three different options for this are considered:

[0021] Option 1: Establishing different NG-U tunnels for different sessions to different PLMNs;

[0022] Option 2: Establishing a single shared NG-U tunnel for multiple MBS sessions from different PLMNs; and

[0023] Option 3: Establish one primary NG-U shared tunnel and one secondary ("backup") NG-U tunnel for multiple sessions from different PLMNs.

[0024] A fourth option is to provide support for all three options above in order to support flexible implementations where the RAN node decides which option (i.e., one NG-U tunnel or multiple NG-U tunnels) is adopted depending on the implementation. This can be summarized as follows:

[0025] Option 4: The NG-RAN node implementation decides the number of NG-U tunnels to be set up.

[0026] Although no definite conclusion has been reached, it is generally understood that, since there is no coordination between different PLMN core networks, the NG-RAN should decide how many NG-U tunnels should be established (i.e., option 4). When the AMF decides whether it can establish an additional tunnel with the NG-RAN for an MBS service, the AMF needs to know whether another PLMN already has an existing NG-U tunnel for that MBS service.

[0027] It will be appreciated that a similar issue arises with respect to F1-U tunnels, namely how many (shared) F1-U tunnels need to be established.

[0028] Thus, in the case of RAN sharing, where there may be multiple 5GCs connected to the same RAN node, if one NG-U tunnel (and F1-U tunnel for distributed RAN) is already established between one of these 5GCs and the RAN node, it can be seen that the NG-RAN node can decide to share this NG-U tunnel (and F1-U tunnel) with another operator's 5GC in order to save transport network resources (this is effectively option 2 above). Alternatively, the NG-RAN node may decide that multiple NG-U / F1-U tunnels should be established, for example, one NG-U / F1-U tunnel for each MBS session in different PLMNs (this is effectively option 1 above).

[0029] However, since there is no coordination between PLMNs of different 5GCs, the RAN node is the only node that knows whether a shared NG-U / F1-U tunnel should be established for an MBS service, or whether multiple such tunnels should be established. This raises the problem of how to efficiently handle tunnel establishment for different 5GCs / PLMNs that share a RAN while minimizing unnecessary signaling (e.g., from the AMF of one PLMN to request the establishment of an additional tunnel if a tunnel has already been established by another AMF of another PLMN and the shared RAN determines that this tunnel should be shared).

[0030] Furthermore, when sharing a distributed RAN, in some cases both the DU and CU may be shared, while in other cases only the DU is shared, with a different respective CU for each operator / PLMN. When both the DU and CU are shared, when an F1-U tunnel is established by a first operator for MBS service, the CU will know that this tunnel has been set up and will have relevant MBS-related information when coordinating with 5GC (e.g., another operator's AMF). However, when only the DU is shared, this raises the problem of how to handle the situation where a CU of one operator has already established an F1-U tunnel to the DU.

[0031] If there is no active service for a multicast MBS service, the UE is supposed to be released to an inactive state (e.g., RRC_INACTIVE). Therefore, some form of paging / notification mechanism is needed to reach UEs in the RRC inactive state and inform them about the activation of the MBS service. To facilitate this, a group-based paging mechanism has been developed to notify one or more UEs of the activation of a multicast service. As part of this, the TMGI of the multicast service is included in the paging message to notify one or more UEs of the activation of the multicast service. Thus, the receiving UE can check whether it is interested in receiving the service, and if so, the UE can enter a connected state (e.g., RRC_CONNECTED) to receive the activated multicast service. [Prior art documents] [Patent documents]

[0032] [Patent Document 1] International Publication No. 2023 / 286784 [Patent Document 2] European Patent Application Publication No. 3061293 [Patent Document 3] International Publication No. 2016 / 124983 [Patent Document 4] European Patent Application Publication No. 3449680 [Patent Document 5] International Publication No. 2022 / 262589 [Non-patent literature]

[0033] [Non-Patent Document 1] The “NGMN 5G White Paper” V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, available at https: / / www.ngmn.org / 5g-white-paper.html. Summary of the Invention [Problem to be solved by the invention]

[0034] However, a similar mechanism for notifying a UE of multicast service activation is challenging in the case of RAN sharing scenarios, where a multicast service can have multiple native TMGIs for different PLMNs. For example, including multiple TMGIs for the same multicast service in a single paging message can result in undesirably large paging messages, which increases signaling overhead over the air interface and reduces efficiency.

[0035] Therefore, another issue to be considered in the context of an MBS RAN sharing scenario is how paging should be performed to notify a group of UEs of the activation of a multicast / broadcast service.

[0036] Therefore, another issue to be considered in the context of an MBS RAN sharing scenario is how paging should be performed to notify a group of UEs of the activation of a multicast / broadcast service.

[0037] Therefore, there is significant room for further development and improvement in relation to the delivery of MBS-related functionality, both in the context of RAN sharing scenarios and the need to ensure efficient resource usage.

[0038] SUMMARY Accordingly, the present disclosure seeks to provide methods, and related apparatus, that address or at least mitigate one or more of the above-mentioned problems. [Means for solving the problem]

[0039] Aspects of the present disclosure are set out in the accompanying independent claims, with advantageous but optional features being set out in the accompanying dependent claims.

[0040] In one aspect, there is provided a method performed by an access network node, comprising: receiving a request for setup of a multicast or broadcast service identified by a second identifier for a Multicast and Broadcast Service (MBS) session from a second communication node of a second network of the plurality of networks sharing the access network node; determining whether resources of an MBS session for a multicast or broadcast service can be shared with at least one MBS session associated with a first identifier, the value of which corresponds to the value of the second identifier; Including, A method is provided in which at least one MBS session is requested from a first network of a plurality of networks sharing an access network node using a first identifier.

[0041] In one aspect, a method performed by a second communication node, comprising: receiving, from the access network node, information indicating that a first user plane tunnel has been established for a multicast or broadcast service, the information including a second identifier for a Multicast and Broadcast Service (MBS) session of the multicast or broadcast service; A method is provided in which a first user plane tunnel is established by a first communication node of a first network of a plurality of networks sharing an access network node for multicast or broadcast services, and a second network including a second communication node is included in the plurality of networks sharing the access network node.

[0042] In one aspect, a method performed by a user equipment (UE) includes: receiving, from an access network node, configuration information for a multicast or broadcast service including first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, each identifier of the plurality of different identifiers including information indicating the multicast or broadcast service and information indicating a different respective network of a plurality of networks sharing the access network node; Using an identifier from a plurality of different identifiers to initiate establishment of an MBS session for receiving multicast or broadcast services, the identifier corresponding to a network to which the UE belongs. A method is provided, comprising:

[0043] In one aspect, there is provided a method performed by an access network node, comprising: transmitting, to a user equipment (UE), configuration information for a multicast or broadcast service including first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, wherein each identifier of the plurality of different identifiers includes information indicating the multicast or broadcast service and information indicating a different respective network of a plurality of networks sharing an access network node; receiving information from the UE to establish an MBS session for receiving multicast or broadcast services by the UE by using an identifier from a plurality of different identifiers, the identifier corresponding to a network to which the UE belongs; A method is provided, comprising:

[0044] In one aspect, an access network node comprising: means for receiving a request for setup of a multicast or broadcast service (MBS) session from a second communication node of a second network of the plurality of networks sharing the access network node, the request being identified by a second identifier for the multicast and broadcast service (MBS) session; means for determining whether resources of an MBS session for a multicast or broadcast service can be shared with at least one MBS session associated with a first identifier, the value of which corresponds to the value of the second identifier; Equipped with An access network node is provided, where at least one MBS session is requested from a first network of a plurality of networks sharing the access network node using a first identifier.

[0045] In one aspect, a second communication node, means for receiving, from an access network node, information indicating that a first user plane tunnel has been established for a multicast or broadcast service, the information including a second identifier for a Multicast and Broadcast Service (MBS) session of the multicast or broadcast service; The first user plane tunnel is established by a first communication node of a first network of a plurality of networks sharing an access network node for multicast or broadcast services, and a second network including a second communication node is provided, the second network being included in the plurality of networks sharing the access network node.

[0046] In one aspect, a user equipment (UE) is provided, means for receiving, from an access network node, configuration information for a multicast or broadcast service including first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, wherein each identifier of the plurality of different identifiers includes information indicating the multicast or broadcast service and information indicating a different respective network of a plurality of networks sharing the access network node; means for using an identifier from a plurality of different identifiers to initiate establishment of an MBS session for receiving multicast or broadcast services, the identifier corresponding to a network to which the UE belongs; There is provided a user equipment (UE) comprising:

[0047] In one aspect, an access network node comprising: means for transmitting, to a User Equipment (UE), configuration information for a multicast or broadcast service including first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, wherein each identifier of the plurality of different identifiers includes information indicating the multicast or broadcast service and information indicating a different respective network of a plurality of networks sharing an access network node; means for receiving information from the UE to establish an MBS session for receiving a multicast or broadcast service by the UE by using an identifier from a plurality of different identifiers, the identifier corresponding to a network to which the UE belongs; An access network node is provided, comprising:

[0048] Aspects of the present disclosure extend to corresponding systems, apparatus, and computer program products, such as computer-readable storage media having instructions stored thereon, operable to program a programmable processor to perform the methods described in each aspect, and possible methods described above or claimed, and / or to program a computer suitably adapted to provide an apparatus as described in any of the claims.

[0049] Each feature disclosed in this specification (which term includes claims) and / or shown in the drawings may be incorporated into the disclosure independently of (or in combination with) any other disclosed and / or illustrated feature. In particular, but not exclusively, any feature of a claim dependent on a particular independent claim may be introduced into that independent claim in any combination or individually. [Effects of the Invention]

[0050] According to the present disclosure, there are provided a method performed by an access network node, a method performed by a second communication node, a method performed by a UE, an access network node, a second communication node, and a UE.

[0051] The foregoing and additional objects, features, and advantages of the present subject matter will become apparent from the following description of illustrative embodiments, which is to be read in conjunction with the accompanying drawings, in which like reference numerals are used to represent like elements, and in which:

[0052] It should be noted, however, that the attached drawings bearing reference numerals illustrate only typical embodiments of the present subject matter and therefore should not be considered to limit the scope of the present subject matter, which may admit of other equally effective embodiments.

[0053] Exemplary embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0054] [Figure 1] 1 illustrates a schematic diagram of a mobile ("cellular" or "wireless") communications system. [Figure 2A] 2 illustrates various types of shared RANs that may be used in the communication system of FIG. 1. [Figure 2B] 2 illustrates various types of shared RANs that may be used in the communication system of FIG. 1. [Figure 3A] 2 is a diagram showing the structure of a TMGI and the definition of an MBS session ID that can be used in the communication system of FIG. 1. [Figure 3B] 2 is a diagram showing the structure of a TMGI and the definition of an MBS session ID that can be used in the communication system of FIG. 1. [Figure 4] 2 is a simplified diagram of a portion of an ASN.1 definition of the data structure of a paging message that may be used in the communication system of FIG. 1. [Figure 5]FIG. 2 is a schematic block diagram illustrating the main components of a UE for the communication system of FIG. 1. [Figure 6] FIG. 2 is a simplified block schematic diagram illustrating the main components of a distributed RAN node that may be used as a shared RAN node in the communication system of FIG. 1. [Figure 7] FIG. 2 is a schematic block diagram illustrating the main components of a non-distributed RAN node that may be used as a shared RAN node in the communication system of FIG. 1. [Figure 8] FIG. 2 is a schematic block diagram illustrating the main components of a core network node that may be used in the communication system of FIG. 1. [Figure 9] 2 illustrates one way in which a list of TMGIs for an MBS service can be notified to a UE in the communication system of FIG. 1. [Figure 10] 2 is a simplified diagram of a portion of an ASN.1 definition of the data structure of a radio bearer configuration information element that may be used in the communication system of FIG. 1. [Figure 11] 10 illustrates another method by which a list of TMGIs for an MBS service can be notified to a UE in the communication system of FIG. 1. [Figure 12] 2 is a simplified diagram of a portion of an ASN.1 definition of the data structure of an MBS broadcast configuration message that may be used in the communication system of FIG. 1. [Figure 13A] 2A-2C are simplified message sequence diagrams of two different paging scenarios that may occur in the communication system of FIG. 1. [Figure 13B] 2A-2C are simplified message sequence diagrams of two different paging scenarios that may occur in the communication system of FIG. 1. [Figure 14] FIG. 2 is a simplified sequence diagram of a procedure for notifying a core network node of the existence of an existing user plane tunnel in the communication system of FIG. 1. [Figure 15] FIG. 2 is a simplified sequence diagram of another procedure for notifying a core network node of the existence of an existing user plane tunnel in the communication system of FIG. 1. DETAILED DESCRIPTION OF THE INVENTION

[0055] <Summary> An exemplary telecommunications system will now be described, by way of example only, with reference to Figures 1 to 4.

[0056] FIG. 1 illustrates schematically a mobile (“cellular” or “wireless”) communications system 1 to which embodiments of the present disclosure are applicable.

[0057] In the communication system 1, user equipment (UE) 3-1, 3-2, 3-3 (e.g., mobile phones and / or other mobile devices) can communicate with one another via (radio) access network ((R)AN) nodes 5 (RAN nodes 5, base stations 5) that operate according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN nodes 5 comprise distributed NR / 5G base stations or "gNBs" that operate one or more associated cells 9. Communications via the RAN nodes 5 are typically routed through one of associated core networks 7-X, 7-Y (e.g., a 5G core network or an evolved packet core network (EPC)).

[0058] As those skilled in the art will appreciate, although FIG. 1 shows three UEs 3, one RAN node 5 and two core networks 7-X, 7-Y for illustrative purposes, the communications system 1, when implemented, will typically include other core networks 7, other RAN nodes 5 and UEs 3.

[0059] Each RAN node 5 controls, either directly or through one or more other nodes (e.g., home base stations, repeaters, remote radio heads, distributed units, etc.), one or more associated cells 9. It will be appreciated that the RAN nodes 5 may be configured to support both 4G and 5G, and / or any other 3GPP or non-3GPP communication protocols.

[0060] In this example, the illustrated RAN node 5 includes a distributed base station comprising a distributed unit (DU) 5b and a central unit (CU) 5c. The CU 5c utilizes separate control and user planes and is thus itself divided between control plane functionality (CU-CP) and user plane functionality (CU-UP), which communicate with the DU 5b via an F1-C logical interface and an F1-U logical interface (together forming an F1 interface (or "reference point")), respectively, and with each other via an E1 logical interface. In this example, the DU 5b provides the functionality of the lower portion of the PHY layer and thus includes the physical and virtual elements necessary to communicate with one or more UEs 3 over the air interface, although it will be appreciated that the RAN node 5 may alternatively (or additionally) include one or more separate radio units (RUs) (e.g., providing this functionality of the lower portion of the PHY layer).

[0061] Although a distributed RAN node 5 is shown and described, it will be appreciated that the RAN node 5 may also be provided in a non-distributed manner, for example as an integrated gNB or eNB.

[0062] In this example, the illustrated RAN node 5 comprises a shared RAN (e.g., for Multi Operator Core Network (MOCN) RAN sharing / Multi Operator RAN (MORAN) RAN sharing), where the RAN node 5 is shared by operators of different core networks 7-X, 7-Y, each core network 7-X, 7-Y being associated with a different respective Public Land Mobile Network (PLMN) with its own PLMN identity.

[0063] Figures 2A and 2B show various types of shared RAN nodes 5 that may be used in the communication system 1. As explained in the introduction, the DU 5b and CU 5c of the shared RAN node 5 may be shared, as shown in Figures 2A and 2B(a). Alternatively, only the DU 5b may be shared, and there may be different respective CUs 5c-X, 5c-Y, and 5c-Z for each core network 7-X, 7-Y, 7-Z of the associated operators / PLMNs, as shown in Figures 2A and 2B(b).

[0064] Therefore, with reference to the communication system 1 of FIG. 1, the shared RAN node 5 shown in FIG. 1 is of a type in which both the DU 5b and the CU 5c are shared (e.g., as seen in (a) of FIG. 2A and FIG. 2B), but it will be understood that the shared RAN node 5 may also be configured in such a way that only the DU 5b is shared (e.g., as seen in (b) of FIG. 2A and FIG. 2B) and there are different dedicated CUs 5c for each of the core networks 7-X and 7-Y.

[0065] It will be appreciated that the communication system 1 may also include RAN nodes 5 that are not shared operating cells 9 .

[0066] One or more UEs 3 and their serving RAN node 5 are connected via a suitable air interface (such as, for example, the so-called "Uu" interface). Equipment of one or more neighboring RAN nodes 5 may be connected to each other via a suitable base station-to-base station interface (such as the so-called "X2" interface, "Xn" interface, etc.).

[0067] Each core network 7-X, 7-Y includes several logical nodes (or “functions”) for supporting communications in the communication system 1. In this example, it can be seen that the core network 7 comprises several Control Plane Functions (CPFs) 10-X and one or more User Plane Functions (UPFs) 11-X. The CPFs 10-X include one or more Access and Mobility Management Functions (AMFs) 10-1-X, one or more Session Management Functions (SMFs) 10-2-X, and several other functions 10-nX (such as, for example, an Authentication Server Function (AUSF) for facilitating 5G security processes, a Unified Data Management (UDM) entity for managing user-specific data (e.g., for access authorization, user registration, and data network profiles), a Policy Control Function (PCF), an Application Function (AF), etc.). It will be understood that the nodes or functions may have different names in different systems.

[0068] Although not shown, for clarity, those skilled in the art will understand that core network 7-Y (and any other core networks sharing RAN node 5) include corresponding logical nodes / functions. Each core network 7-X, 7-Y may also be connected to an Operations and Maintenance (OAM) function (not shown). For clarity, the suffixes "-X" and "-Y" are used herein to help distinguish between such nodes / functions of core network 7-X and such nodes / functions of core network 7-Y, respectively. When such nodes / functions are referred to in a more general sense applicable to either core network 7-X, 7-Y, the suffixes ("-X", "-Y") may be omitted.

[0069] The RAN node 5 is connected to each core network 7-X, 7-Y node via an appropriate interface (or "reference point"), such as the N2 reference point between the RAN node 5 and the AMF 10-1 for communication of control signaling, and the N3 reference point between the RAN node 5 and each UPF 11 for communication of user data. One or more UEs 3 are each connected to the AMF 10-1 via a logical Non-Access Stratum (NAS) connection over the N1 reference point (similar to the S1 reference point in LTE). It will be appreciated that N1 communications are transparently routed through the RAN node 5.

[0070] The one or more UPFs 11 are connected to an external data network (eg, an IP network such as the Internet) via a reference point N6 for the communication of user data.

[0071] The AMF 10-1 performs mobility management-related functions, maintains NAS signaling connections with each UE 3, and manages UE registration. The AMF 10-1 is also responsible for managing paging. The SMF 10-2 is connected to the AMF 10-1 via the N11 reference point. The AMF 10-1 and the RAN node 5 are mutually configured to communicate with each other to set up appropriate user plane transport tunnels (e.g., GTP-U tunnels) on the N3 interface between the RAN node 5 and the UPF 11 (e.g., NG-U tunnels) and on the F1-U interface between the CU 5c and the DU 5b within the RAN node 5 (e.g., F1-U tunnels). These tunnels typically comprise tunnel pairs (GTP-U pairs) with corresponding tunnels for uplink and downlink communications. The user plane tunnels may include, for example, one or more dedicated or shared user plane tunnels (e.g., F1-U / NG-U tunnels) for one or more MBS sessions of one or more PLMNs.

[0072] The SMF 10-2 provides session management functions (forming part of the MME functions in LTE) and also combines some control plane functions (provided by the Serving Gateway and Packet Data Network Gateway in LTE). The SMF 10-2 uses user information provided via the AMF 10-1 to determine which session manager is best assigned to the user. The SMF 10-2 can effectively be considered a gateway from the user plane to the network's control plane. The SMF 10-2 also allocates IP addresses to each UE 3. The SMF 10-2 may be a Multicast / Broadcast specific Session Management Function (MB-SMF) in the context of MBS.

[0073] The RAN node 5 is configured for the transmission of control information and user data over several Downlink (DL) physical channels and for the transmission of several physical signals, and one or more UEs 3 are configured for the reception of control information and user data over several Downlink (DL) physical channels and for the transmission of several physical signals, where DL physical channels correspond to Resource Elements (REs) carrying information originating from higher layers and DL physical signals correspond to REs used by the physical layer and not carrying information originating from higher layers.

[0074] The physical channels may include, for example, a Physical Downlink Shared Channel (PDSCH), a Physical Broadcast Channel (PBCH), a Physical Multicast Channel (PMCH), and a Physical Downlink Control Channel (PDCCH). The PDSCH carries data that shares the capacity of the PDSCH on a time and frequency basis. The PDSCH can carry various data items, including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, System Information Blocks (SIBs), and paging. The PDCCH carries Downlink Control Information (DCI) to support several functions, including, for example, scheduling downlink transmissions on the PDSCH and uplink data transmissions on the Physical Uplink Shared Channel (PUSCH). The PBCH provides a Master Information Block (MIB) to one or more UEs 3. The PBCH, in conjunction with the PDCCH, also supports time and frequency synchronization, which aids in cell acquisition, selection, and reselection.

[0075] DL physical signals may include, for example, Reference Signals (RS) and Synchronization Signals (SS). Reference signals (sometimes known as pilot signals) are signals having a predefined special waveform known to both the UE 3 and the RAN node 5. Reference signals may include, for example, cell-specific reference signals, UE-specific Reference Signals (UE-RS), the aforementioned Positioning Reference Signals (PRS), and Channel State Information Reference Signals (CSI-RS).

[0076] In the communication system 1, multicast and broadcast service (MBS) functionality may be provided to one or more UEs 3 via a shared RAN node 5 and one or more associated core network nodes 7, such as a UPF 11 and an SMF 10-2. Specifically, MBS functionality may be provided via the shared RAN node 5 to one or more UEs 3 of subscribers of each PLMN that shares the RAN node 5 (and is authorized to use MBS in the shared RAN node 5). The UPF 11 may be an MBS-specific UPF, in which case it may be referred to as an MB-UPF 11 (e.g., dedicated to providing MBS functionality). Similarly, the SMF 10-2 may be an MBS-specific SMF, in which case it may be referred to as an MB-SMF 10-2. However, it will be understood that any suitable UPF 11 / SMF 10-2 may be used for MBS. By using a shared RAN node 5 / base station 5, redundant MBS transmissions over multiple networks may be avoided or minimized, thereby improving the overall efficiency of multicast / broadcast traffic delivery.

[0077] As explained above, MBS is a PLMN-specific service. Each UE 3 interested in the MBS service monitors system information broadcast by the shared RAN node 5 to determine the resources to be used for the associated MBS Control Channel (MCCH) and / or MBS Data Channel (MTCH). The shared RAN node 5 also broadcasts a respective identifier (MBS session identifier or Temporary Mobile Group Identity (TMGI)) for each MBS session offered in the cell 9 it operates.

[0078] 3A and 3B show the structure of the TMGI and the definition of the MBS session ID.

[0079] 3A and 3B(a), the TMGI is an MBS session identifier that uniquely identifies a particular MBS service or a session associated with that MBS service. The TMGI has three parts: an MBMS service ID part, a Mobile Country Code (MCC) part, and a Mobile Network Code (MNC) part. Thus, effectively, the TMGI contains a specific PLMN ID (PLMN ID = MCC + MNC) of a single PLMN (e.g., associated with a particular Mobile Network Operator (MNO) and / or Mobile Virtual Network Operator (MVNO)).

[0080] The MCC consists of three digits (octets) and uniquely identifies the country of residence of the mobile subscriber. The MNC consists of two or three digits (octets) for 3GPP network applications (depending on the assignment to the PLMN by the national numbering plan administrator). The MNC identifies the home PLMN of the mobile subscription within the country of location, or together with the MCC and network identifier (NID) identifies the stand-alone non-public network (SNPN) of the mobile subscription. The length of the MNC (two or three digits) depends on the value of the MCC. The MBMS service ID is six digits (octets) and uniquely identifies the MBMS bearer service (represented by the MCC and MNC) within the PLMN. The TMGI shown in (a) of Figures 3A and 3B can be considered a "native" TMGI because it is PLMN-specific.

[0081] As can be seen in Figures 3A and 3B(b), the MBS Session ID, possibly together with an optional NID, corresponds to the TMGI.

[0082] In order to reach one or more UEs 3 in an RRC idle / inactive state to inform them about the activation of the MBS service, the communication system 1 implements a paging / notification mechanism. Specifically, to facilitate this, a group-based paging mechanism is implemented to notify one or more UEs 3 of the activation of a multicast service. As part of this, the TMGI of the multicast service is included in a paging message from the shared RAN node 5 to notify one or more UEs 3 of the activation of the multicast service. Thus, the receiving UEs 3 can check whether they are interested in receiving the service, and if so, the UEs 3 can enter a connected state (e.g., RRC_CONNECTED) to receive the activated multicast service.

[0083] Figure 4 is a simplified illustration of a portion of an Abstract Syntax Notation One (ASN.1) definition of the data structure of a paging message. The illustrated paging message can be used by the RAN node 5 to inform a group of one or more UEs 3 about one or more MBS sessions of one or more corresponding multicast services. The message can be transmitted from the RAN node 5 to the UEs 3 following an associated paging request from the AMF 10-1. This message can be transmitted, for example, on a logical Paging Control Channel (PCCH) that maps to a paging transport channel (Paging Channel (PCH)), and then on an associated Physical Downlink Shared Channel (PDSCH). As seen in Figure 4, the message includes a "paging group list" ("pagingGroupList") consisting of one or more TMGIs (i.e., representing the associated MBS session IDs), each identifying a respective MBS multicast service and associated PLMN. FIG. 4 is included purely for illustrative purposes, and those skilled in the art will understand that the use of the particular data structures shown, or the use of any of the particular information elements shown therein, is not required for paging.

[0084] In the communication system 1, the shared RAN node 5 is advantageously able to identify the association between the AMF 10-1 and the associated TMGI (for the same MBS service), for example, by determining different native TMGIs (and / or foreign TMGIs) that are associated with essentially the same MBS service / content provided via different PLMNs or otherwise. There are several ways in which this can be achieved.

[0085] In a first option, the shared RAN node 5 is configured with one or more TMGIs (or other information that allows determining the association between AMFs 10-1 of the same MBS service and the associated TMGIs) via an Operations Administration and Maintenance (OAM) function.

[0086] Alternatively (or additionally), the shared RAN node 5 may determine the association based on signaling from other communication entities (e.g., one or more of the core networks 7-X, 7-Y).

[0087] For example, an application function of one core network 7 associated with a first PLMN can allocate an identifier for a non-PLMN-specific broadcast MBS service, and the identifier is transmitted to the shared RAN node 5 during the MBS session creation procedure. The shared RAN node 5 recognizes the respective PLMN IDs of each operator participating in MBS RAN sharing via the shared RAN node 5 and can therefore determine the corresponding TMGI / association between the AMF 10-1 of the same MBS service and the associated TMGI. In this case, the service identifier allocated by the application function of the first PLMN is associated with the same MBS service for different PLMNs. Thus, the shared RAN node 5 can notify one or more AMFs 10-1 associated with other PLMNs participating in MBS RAN sharing of the identifier. Furthermore, when another AMF 10-1 receives this identifier from the shared RAN node 5, it can know that there is another existing user plane (e.g., NG-U) tunnel with another operator's AMF 10-1 for that service.

[0088] Another option is to use a common session identifier (e.g., a Source Specific IP Multicast (SSM) address) that is not an MBS session ID as an identifier to associate broadcast MBS sessions from different core networks 7-X, 7-Y that transmit the same content.

[0089] Specifically, an application function of one core network 7 associated with a first PLMN may provide an associated session identifier (rather than an MBS session ID) when creating a broadcast MBS session with the same broadcast content. For all core networks 7-X, 7-Y sharing a shared RAN node 5, the MB-SMF 10-2-X, 10-2-Y may provide the associated session ID to the shared RAN node 5 via one of the associated AMFs 10-1-X, 10-1-Y. The shared RAN node 5 may then utilize the associated session ID to associate those broadcast MBS sessions with each other and therefore with one or more associated TMGI / AMFs 10-1-X, 10-1-Y.

[0090] The shared RAN node 5 may establish one or more user planes for the first broadcast MBS session it receives. Thus, the shared RAN node 5 may wirelessly deliver packets received from the established user plane. For another broadcast MBS session associated with the broadcast MBS session, the shared RAN node 5 may create a broadcast MBS session context and know the associated TMGI, but does not need to establish another user plane. Specifically, the shared RAN node 5 in this case may determine whether the user plane of another broadcast MBS session associated with the session identifier has already been established, and may skip establishing the user plane of the further broadcast MBS session associated with the same session identifier.

[0091] Therefore, in this option, the application function initially provides the same session ID to the shared RAN node 5 via the first PLMN core network 7. Since this session ID is always associated with the same MBS service, the shared RAN node 5 can notify the session ID to the AMF 10-1 of a PLMN of another core network. Thus, when the other AMF 10-1 receives the session ID from the shared RAN node 5, it knows that there is another existing user plane (NG-U) tunnel established with the AMF 10-1 of another operator.

[0092] Another option relies on the configuration of the shared RAN node 5 and does not require any new parameters. Instead, the respective service ID portions of the TMGI for each RAN node 5 sharing a sharing partner (core network 7-X, 7-Y) corresponding to the same content are configured in the shared RAN node 5.

[0093] For example, if PLMNs associated with two core networks 7-X and 7-Y are involved in MBS RAN sharing, the shared RAN node 5 is already configured with the respective PLMN IDs of each sharing partner. The shared RAN node 5 may also be configured with the specific respective service IDs of each TMGI corresponding to the same content for the two PLMNs, or with the range of service IDs associated with that content. This means that the corresponding MB-SMFs 10-2-X and 10-2-Y in each PLMN can allocate service IDs for TMGIs based on the specific service IDs (or service ID ranges) expected for the same content.

[0094] Therefore, the shared RAN node 5 understands one or more TMGIs for different PLMNs because the Service ID / Service ID range is configured in the RAN node 5. This allows the shared RAN node 5 to notify the TMGI of one PLMN to the AMF 10-1 of another PLMN. When the other AMF 10-1 receives the TMGI from the NG-RAN, it knows that there is another existing user plane (NG-U) tunnel established with the AMF 10-1 of another operator.

[0095] On the other hand, another option is to use a single external TMGI to minimize the required updates and avoid multiple native TMGIs for the same multicast data broadcast. This is an "external" TMGI solution, and as explained in the introduction, it is generally agreed that a "native" TMGI (i.e., PLMN-specific TMGI) solution should be supported.

[0096] Beneficially, as described in more detail below, in the communications system 1, for each UE 3 that may be interested in receiving an MBS service, the shared RAN node 5 may configure the UE 3 with a respective list of PLMN-specific TMGIs (i.e., a native TMGI list) for that MBS service. This beneficially avoids the need to provide one or more UEs 3 with respective duplicate Point-To-Multipoint (PTM) configurations with different TMGIs for each PLMN.

[0097] More specifically, in the case of multicast, the shared RAN node 5 may advantageously transmit a respective list of PLMN-specific TMGIs (i.e., native TMGI list) for one or more multicast MBS services to the UE 3 via dedicated (e.g., RRC) signaling, and the UE 3 may maintain each TMGI list in association with the corresponding PTM configuration of the corresponding MBS session / service.

[0098] Similarly, in the case of broadcast, the shared RAN node 5 may advantageously transmit a respective list of PLMN-specific TMGIs (i.e., native TMGI list) for one or more broadcast MBS services to the UE 3 via other dedicated (e.g., RRC) signaling, and the UE 3 may maintain each TMGI list in association with the corresponding PTM configuration of the corresponding MBS session / service.

[0099] Thus, the UE 3 can beneficially see that it can identify the PTM configuration of the MBS service that it is interested in receiving based on the TMGI broadcasted by the shared RAN node 5, even if the broadcasted TMGI includes a PLMN ID of a PLMN that the UE 3 is not authorized to use. Specifically, the UE 3 can identify the list of TMGIs that includes the broadcast TMGI, and thus apply the correct PTM configuration to receive the MBS service, even if the MBS service is only provided via a single PLMN that is not the UE 3's PLMN.

[0100] Beneficially, as described in more detail below, when paging a UE 3 for an MBS service having different TMGIs associated with different PLMNs / core networks 7-X, 7-Y, the shared RAN node 5 is configured to include a single TMGI (forming a TMGI list associated with the MBS service) in the paging message, even if the shared RAN node 5 receives multiple paging requests from the AMFs 10-1-X, 10-1-Y of the different PLMNs / core networks 7-X, 7-Y. Because the UE 3 previously stored the TMGI list for the associated PTM configuration of the MBS service to which the paging message relates, the UE 3 can beneficially recognize the TMGI in the paging message, even if it is for a PLMN that the UE 3 is not authorized to access. This enables the UE 3 to enter a connected state (e.g., RRC_CONNECTED state) in response to the paging message and receive the MBS service.

[0101] In the communication system 1, the shared RAN node 5 can determine the number of (NG-U / F1-U) user plane tunnels to establish. Specifically, if one NG-U tunnel (and an F1-U tunnel of a distributed RAN) is already established between one of the core networks 7-X, 7-Y and the shared RAN node 5, the shared RAN node 5 can decide to share this NG-U tunnel (and an F1-U tunnel) with another one of the core networks 7-X, 7-Y of another operator to save transport network resources. Alternatively, the shared RAN node 5 can determine that multiple NG-U / F1-U tunnels should be established, for example, one NG-U / F1-U tunnel for each MBS session of different PLMNs.

[0102] Beneficially, as will be described in more detail below, when the shared RAN node 5 decides to establish only one NG-U / F1-U tunnel with the first PLMN / core network 7-X, the shared RAN node 5 may inform the AMF 10-1-Y of the second PLMN / core network 7-Y (e.g., via the first AMF 10-1-X of the first PLMN / core network 7-X) that there is already an existing NG-U / F1-U tunnel with a TMGI allocated by the first core network 7-X. In this case, the second AMF 10-1-Y may decide not to attempt to establish an additional NG-U tunnel by sending an association request, and if the second AMF 10-1-Y has already sent a request to establish the additional NG-U tunnel, the shared RAN node 5 may reject the request.

[0103] Beneficially, as described in more detail below, a distributed shared RAN node 5 (and / or a non-distributed shared RAN) in which both DU 5b and CU 5c are shared can implement a first procedure for notifying AMF 10-1-Y that an existing NG-U / F1-U tunnel with a TMGI allocated by another core network 7-X already exists, and a distributed shared RAN node 5 in which only DU 5b is shared can implement a different procedure for notifying AMF 10-1-Y that an existing NG-U / F1-U tunnel with a TMGI allocated by another core network 7-X already exists.

[0104] On the other hand, if the shared RAN node 5 decides to establish multiple NG-U tunnels, the AMF 10-1-Y of the second PLMN / core network 7-Y can proceed to independently request NG-U / F1-U tunnel establishment, and the shared RAN node 5 can simply accept these additional NG-U / F1-U tunnels.

[0105] <User Equipment (UE)> Figure 5 is a schematic block diagram illustrating the main components of a UE 3 for the communication system 1 shown in Figure 1. In this example, UE 3 is a UE capable of receiving MBS communications and associated configuration signaling as described herein.

[0106] As shown, the UE 3 has transceiver circuitry 31 operable to transmit signals to and receive signals from base stations 5 via one or more antennas 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 that controls the operation of the UE 3. The controller 37 is associated with memory 39 and is connected to the transceiver circuitry 31. Although not necessary for its operation, the UE 3 may, of course, have all the usual functionality of a conventional UE 3 (e.g., a user interface 35, such as a touchscreen / keypad / microphone / speaker, for enabling direct user control and interaction), which may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and / or downloaded, for example, via the communication system 1 or from a removable data storage device (RMD).

[0107] Controller 37, in this example, is configured to control the overall operation of UE 3 via program or software instructions stored in memory 39. As shown, these software instructions include, among other things, an operating system 41, a communications control module 43, and an MBS management module 45.

[0108] The communications control module 43 is operable to control overall communications between the UE 3 and its one or more serving RAN nodes 5 (and other communications devices connected to the RAN nodes 5, such as one or more further UEs 3 and / or one or more core network nodes 7). The communications control module 43 is configured for overall handling of uplink communications over associated uplink channels (e.g., over a Physical Uplink Control Channel (PUCCH), a Random Access Channel (RACH), and / or a Physical Uplink Shared Channel (PUSCH)), including both dynamic and semi-static signaling (e.g., SRS). The communications control module 43 is also configured for overall reception and processing of downlink communications over associated downlink channels (e.g., over a Physical Downlink Shared Channel (PDSCH), a Physical Broadcast Channel (PBCH), a Physical Multicast Channel (PMCH), and / or a Physical Downlink Control Channel (PDCCH). Downlink communications may include, for example, both dynamic and quasi-static signaling (e.g., CSI-RS, SSB, etc.), paging communications, dedicated (Radio Resource Control (RRC)) communications, multicast communications (including on the MCCH and / or MTCH), broadcast communications, etc. The communications control module 43 is responsible for, for example, determining the resources to be used by the UE 3, determining how the slots / symbols are configured (e.g., for UL, DL, flexible, full-duplex communication, etc.), determining which bandwidth portion or portions are configured for the UE 3, determining how uplink transmissions should be coded, etc.

[0109] It will be understood that the communication control module 43 includes several sub-modules for supporting corresponding functions of the different layers mentioned above. For example, the communication control module 43 typically includes an RRC sub-module, a PDCP sub-module, an RLC sub-module, a MAC sub-module, a PHY sub-module, an IP sub-module, etc. for providing corresponding functions.

[0110] The MBS management module 45 is responsible for the overall handling of MBSs and MBS-related signaling, which may include, for example, signaling to configure the UE 3 to receive one or more MBS sessions via the shared RAN node 5 / shared base station 5.

[0111] <Access network node (base station / RAN node) - distributed> FIG. 6 is a simplified block schematic diagram illustrating the main components of a distributed RAN node 5 that may be used as the shared RAN node 5 in the communication system 1 shown in FIG.

[0112] As shown, the RAN node 5 includes a distributed unit 5b and a central unit 5c. Each unit 5b, 5c includes a respective transceiver circuit 51b, 51c. The transceiver circuit 51b of the distributed unit 5b is operable to transmit signals to and receive signals from one or more UEs 3 over the air interface via one or more antennas 53b (e.g., single or multi-panel antenna arrays / large-scale antennas), and is also operable to transmit signals to and receive signals from the central unit 5c over an interface, e.g., the distributed unit side of an F1 interface.

[0113] The transceiver circuitry 51c of the central unit 5c is operable to transmit signals to and receive signals from functions of one or more core networks 7-X, 7-Y, 7-Z and / or other RAN nodes 5 via a network interface 55c (e.g., including N2, N3 and other reference points / interfaces) for communicating with one or more core networks 7-X, 7-Y, 7-Z and a RAN-RAN interface (e.g., the so-called "Xn" interface in NR) for communicating with other RAN nodes 5. The transceiver circuitry 51c of the central unit 5c is also operable to transmit signals to and receive signals from one or more distributed units 5b, e.g., the central unit side of the F1 interface.

[0114] Each unit 5b, 5c includes a respective controller 57b, 57c that controls the operation of the corresponding transceiver circuit 51b, 51c in accordance with software stored in the respective memories 59b and 59c of the distributed unit 5b and the central unit 5c. The software for each unit may be pre-installed in the memories 59b, 59c and / or downloaded, for example, via the communication system 1 or from a removable data storage device (RMD).

[0115] As shown, the software for each unit includes, among other things, a respective operating system 61b, 61c, a respective communications control module 63b, 63c, and a respective MBS management module 65b, 65c. While CU5c and DU5b are described as each having a corresponding unit, it will be understood that this may not be the case. For example, depending on the particular functionality distributed between CU5c and DU5b, any of these modules may reside in one of CU5c and DU5b only if the other unit does not contribute to the module's functionality.

[0116] Each communication control module 63b, 63c is operable to control the communications of its corresponding unit 5b, 5c, including communications from one unit to the other. The communication control module 63b of the distributed unit 5b controls communications between the distributed unit 5b and one or more UEs 3, and the communication control module 63c of the central unit 5c controls communications between the central unit 5c and other network entities connected to the distributed base stations 5.

[0117] The communication control modules 63b, 63c also control the parts of the communication between the base station 5 and one or more UEs 3 and other network entities connected to the RAN node 5 that are handled by the distributed unit 5b and the central unit 5c, respectively.

[0118] Each communication control module 63b, 63c is responsible for controlling the respective parts of the distributed unit 5b and the central unit 5c in receiving and decoding uplink communications over the associated uplink channel (e.g., over the Physical Uplink Control Channel (PUCCH), the Random Access Channel (RACH), and / or the Physical Uplink Shared Channel (PUSCH)), including, for example, both dynamic and quasi-static signaling (such as SRS). Each communication control module 63b, 63c is also responsible for controlling the respective parts handled by the distributed unit 5b and the central unit 5c in the overall processing of downlink communication transmissions, e.g., via an associated downlink channel (e.g., via a Physical Downlink Shared Channel (PDSCH), a Physical Broadcast Channel (PBCH), a Physical Multicast Channel (PMCH), and / or a Physical Downlink Control Channel (PDCCH)). Downlink communications may include, e.g., both dynamic and quasi-static signaling (e.g., CSI-RS, SSB, etc.), paging communications, dedicated (Radio Resource Control (RRC)) communications, multicast communications (including on the MCCH and / or MTCH), broadcast communications, etc. Each communication control module 63b, 63c is also responsible for controlling the respective parts handled by the distributed unit 5b and the central unit 5c in the overall control processing of communications between the different core networks 7-X, 7-Y, 7-Z that share the RAN node 5, including, for example, communications related to setting up user plane tunnels (e.g., GTP-U tunnels) for MBS services and other communications, paging requests from the AMF 10-1, etc.Each communication control module 63b, 63c is also responsible for controlling the respective parts of the distributed unit 5b and the central unit 5c in determining and scheduling the resources to be used by the UE3, e.g. for receiving in DL / transmitting in UL, appropriate configuration of slots / symbols (e.g. for UL, DL, flexible, full duplex communication, etc.), configuring one or more bandwidth portions for the UE3, and providing related configuration signaling to the UE3.

[0119] It will be appreciated that the communication control modules 63b, 63c may also include multiple sub-modules (or "layers") to support specific functions of the corresponding units 5b, 5c. The included modules depend on how the corresponding units 5b, 5c are configured (e.g., the precise CU-DU division). For example, the communication control module 63b of the distributed unit 5b may include a PHY sub-module, a MAC sub-module, and an RLC sub-module, while the communication control module 63c of the central unit 5c may include a PDCP sub-module, an IP sub-module, an RRC sub-module, etc.

[0120] Each MBS management module 65b, 65c is responsible, for example, for controlling the respective parts of the distributed unit 5b and the central unit 5c in the overall processing of MBSs and MBS-related signaling. The signaling may include signaling for configuring the UE 3 to receive MBS sessions via the shared RAN node 5 / shared base station 5, MBS-related signaling from the core network 7-X, 7-Y, 7-Z (e.g., from the associated AMF 10-1-X, 10-1-Y, 10-1-Z), and signaling for configuring other nodes to provide MBS sessions via the shared RAN node 5 / shared base station 5.

[0121] It will be appreciated by those skilled in the art that the central unit 5c may be implemented and physically located with the same RAN node 5 / base station 5, or may be implemented remotely as a single physical element or as a cloud-based or virtualized system. It will also be appreciated that a single central unit 5c may serve multiple distributed units 5b and vice versa.

[0122] <Access network node (base station / RAN node) - non-distributed> FIG. 7 is a schematic block diagram showing the main components of a non-distributed RAN node 5 (base station 5) that may be used as the shared RAN node 5 in the communication system 1 shown in FIG.

[0123] As shown, the RAN node 5 has transceiver circuitry 51 for transmitting signals to and receiving signals from one or more UEs 3 over the air interface via one or more antennas 53 (e.g., single or multi-panel antenna arrays / large-scale antennas), a core network interface 55 (e.g., including N2, N3 and other reference points / interfaces) for communicating with one or more core networks 7-X, 7-Y, 7-Z, and a RAN-RAN (e.g., Xn) interface for communicating with other RAN nodes 5 (e.g., so-called "Xn" interfaces in NR).

[0124] The RAN node 5 has a controller 57 that controls the operation of the RAN node 5. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded, for example, via the communication system 1 or from a removable data storage device (RMD). The controller 57 is configured, in this example, to control the overall operation of the RAN node 5 by means of program or software instructions stored in the memory 59.

[0125] As shown, these software instructions include, among other things, an operating system 61, a communications control module 63, and an MBS management module 65.

[0126] The communications control module 63 is operable to control communications between the base station 5, one or more UEs 3, and other network entities connected to the RAN node 5. The communications control module 63 is configured to generally control the reception and decoding of uplink communications over associated uplink channels (e.g., over a Physical Uplink Control Channel (PUCCH), a Random Access Channel (RACH), and / or a Physical Uplink Shared Channel (PUSCH)), including both dynamic and semi-static signaling (e.g., SRS). The communications control module 63 is also configured for overall transmission processing of downlink communications over associated downlink channels (e.g., over a Physical Downlink Shared Channel (PDSCH), a Physical Broadcast Channel (PBCH), a Physical Multicast Channel (PMCH), and / or a Physical Downlink Control Channel (PDCCH). Downlink communications may include, for example, both dynamic and quasi-static signaling (e.g., CSI-RS, SSB, etc.), paging communications, dedicated (Radio Resource Control (RRC)) communications, multicast communications (including on the MCCH and / or MTCH), broadcast communications, etc. The communication control module 63 is configured for overall control processing of communications between different core networks 7-X, 7-Y, 7-Z sharing the RAN node 5, including, for example, communications related to setting up user plane tunnels (e.g., GTP-U tunnels) for MBS services and other communications, paging requests from the AMF 10-1, etc.Each communication control module 63 is also responsible for determining and scheduling the resources to be used by the UE3, for example, receiving in DL / transmitting in UL, configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full-duplex communication, etc.), configuring one or more bandwidth portions for the UE3, and providing related configuration signaling to the UE3.

[0127] It will be understood that the communication control module 63 includes several sub-modules for supporting corresponding functions of the different layers mentioned above. For example, the communication control module 63 typically includes an RRC sub-module, a PDCP sub-module, an RLC sub-module, a MAC sub-module, a PHY sub-module, an IP sub-module, etc. for providing corresponding functions. The MBS management module 65 is responsible for overall processing of MBS and MBS-related signaling. The signaling may include signaling for configuring the UE 3 to receive MBS sessions via the shared RAN node 5 / shared base station 5, MBS-related signaling from the core networks 7-X, 7-Y, 7-Z (e.g., from the associated AMFs 10-1-X, 10-1-Y, 10-1-Z), and signaling for configuring other nodes to provide MBS sessions via the shared RAN node 5 / shared base station 5.

[0128] <Core network node> FIG. 8 is a schematic block diagram illustrating the main components of a core network node 7 that may be used in the communication system 1 (eg, the AMF 10-1, the UPF 11, or the SMF 10-2) shown in FIG.

[0129] As shown, core network node 7 includes transceiver circuitry 71 operable to transmit signals to and receive signals from other communication entities as needed via network interface 75 (which may include multiple logical reference points / interfaces for communicating with other communication entities such as those shown in FIG. 1). For example, core network node 7 configured as AMF 10-1 may communicate with UE 3 (e.g., via an N1 interface), RAN node 5 (e.g., via an N2 interface), SMF 10-2 (e.g., via an N11 interface), and / or other core network nodes 7 as needed via other interfaces. Core network node 7 configured as SMF 10-2 may communicate with AMF 10-1 (e.g., via an N11 interface), UPF 11 (e.g., via an N4 interface), and other core network nodes 7 as needed via other interfaces.

[0130] The controller 77 controls the operation of the core network node 7 in accordance with software stored in memory 79. The software may be pre-installed in the memory 79 and / or downloaded, for example, via the communication system 1 or from a removable data storage device (RMD). The software includes, among other things, an operating system 81, a communication control module 83, and an MBS management module 85 (if required).

[0131] The communication control module 83 is responsible for handling (generating / sending / receiving) signaling between the core network node 7 and other communication entities such as the UE 3, the (R)AN node 5, and other core network nodes 7 as needed.

[0132] When present, the MBS management module 85 (when present) is responsible for handling signaling related to multimedia broadcast services (control signaling and / or MBS traffic). The signaling may include signaling related to the provision of MBS sessions via the shared RAN node 5 / shared base station 5 (including, if necessary, paging requests, signaling for setting up user plane tunnels, etc.), and signaling for configuring other nodes to provide MBS sessions via the shared RAN node 5 / shared base station 5.

[0133] <A plurality of TMGIs configured in the UE via RRC dedicated signaling (multicast)> As mentioned above, in the communication system 1, for each UE 3 that may be interested in receiving MBS services, the shared RAN node 5 can configure a list of PLMN-specific TMGIs of its MBS services (i.e., the native TMGI list) for the UE 3. One possible way to achieve this will be described in more detail here by way of a mere example, with reference to FIGS. 9 and 10.

[0134] FIG. 9 is a diagram showing one way in which a list of TMGIs for MBS services can be notified to the UE 3 in the communication system 1 of FIG. 1.

[0135] As seen at S910 in FIG. 9, in this example, RRC dedicated signaling is used to configure a native TMGI list associated with a specific PTM configuration for the multicast MBS service to the UE 3. As seen in FIG. 9, in this example, an information element (IE) of the RRC reconfiguration (“RRCReconfiguration”) message is used to transfer the TMGI list to the UE 3. Specifically, an IE for notifying the UE 3 of the MBS radio bearers (MRBs) to be added in the UE 3 is used (“MRB-ToAddMod”).

[0136] It will be appreciated that the message shown in Figure 9 is simplified for clarity, and that in practice the data structure will be more complex. For example, although not shown in the simplified illustration of Figure 9, an IE for informing UE 3 of the MBS Radio Bearer (MRB) to be added at UE 3 may form part of a Radio Bearer Configuration IE (e.g., "RadioBearerConfig") included in the RRC reconfiguration message along with other information. The Radio Bearer Configuration IE is used to add, modify, and release signaling, multicast MRB, and / or data radio bearers. Specifically, this IE carries parameters for PDCP and, if applicable, Service Data Adaptation Protocol (SDAP) entities for the radio bearer.

[0137] Thus, upon receiving an RRC Reconfiguration message, if the TMGI corresponding to the multicast service that UE3 is interested in receiving (e.g., TMGI-X as allocated via the home operator's core network 7-X) is in the TMGI list for the associated PTM configuration, UE3 can establish an MRB for receiving that multicast service.

[0138] 10 shows a simplified portion of an Abstract Syntax Notation One (ASN.1) definition of a data structure for such a radio bearer configuration IE incorporating an IE ("tmgi-list-multicast") for transporting a list of TMGIs as a sequence of TMGIs. It will be understood that the terminology used to identify such a TMGI list IE ("tmgi-list-multicast") is exemplary and that different terminology may be used.

[0139] It will also be understood that other RRC messages may include a list of TMGIs (either as part of a radio bearer configuration IE or another IE). For example, an RRC resume message may include a radio bearer configuration IE that incorporates a list of TMGIs.

[0140] Thus, advantageously, even when the PTM configuration overlaps for multiple TMGIs, each PTM configuration is not associated with a single TMGI, but each PTM configuration is associated with a list of TMGIs of the same MBS session.

[0141] Thus, in this way, the network can configure the native TMGI list of UE3 instead of providing overlapping PTM configurations with different TMGIs to UE3.

[0142] <Multiple TMGIs (Broadcast) configured for the UE via MCCH> As mentioned above, in communication system 1, for each UE3 that may be interested in receiving MBS services, the shared RAN node 5 can configure a list of PLMN-specific TMGIs of its MBS services (i.e., the native TMGI list) for UE3. Another possible way to achieve this will be described in more detail here by way of a mere example, with reference to FIGS. 11 and 12.

[0143] FIG. 11 shows another way in which the list of TMGIs for MBS services can be notified to UE3 in communication system 1 of FIG. 1.

[0144] As seen in S1110 of Figure 11, in this example, a message is transmitted over the MBS Control Channel (MCCH) to configure a native TMGI list associated with a particular PTM configuration of an MBS broadcast service for UE3. As seen in Figure 11, in this example, an Information Element (IE) of an MBS Broadcast Configuration ("MBSBroadcastConfiguration") message is used to transfer the TMGI list to UE3. Specifically, an IE is used to provide MBS session information to UE3 ("MBSsessioninfo"). It will be understood that such an MCCH message is an RRC message that may be transmitted from the network to UE3 on the MCCH logical channel.

[0145] It will be appreciated that the messages shown in Figure 11 are simplified for clarity and that in practice the data structures will be more complex. For example, although not shown in the simplified illustration of Figure 11, the MBS Broadcast Configuration message includes control information applicable to the MBS Broadcast service transmitted via the Broadcast MRB. The MBS Broadcast Configuration information provided on the MCCH logical channel via the MBS Broadcast Configuration message indicates the MBS Broadcast sessions provided in the cell and corresponding scheduling-related information for these sessions.

[0146] FIG. 12 shows a simplified partial Abstract Syntax Notation One (ASN.1) definition of the data structure of an MBS Broadcast Configuration ("MBSBroadcastConfiguration") message incorporating MBS session information for transferring a list of TMGIs as a sequence of TMGIs. In this example, the information is shown as being provided within a TMGI List ("TMGI-list-broadcast") IE, which contains a list of MBS Session Information ("MBMS-SessionInfo") IEs. It will be understood that the MBS Session Information ("MBMS-SessionInfo") IEs each correspond to a single TMGI, as shown in FIGS. 3A and 3B. It will be understood that the terminology used to identify such TMGI List IEs ("tmgi-list-broadcast") is exemplary, and that different terminology may be used.

[0147] It can therefore be seen that in this way multiple TMGIs can be configured for one PTM configuration in an MCCH message for an MBS broadcast service. The configuration itself is similar to the multicast case described with reference to Figures 9 and 10, but a different RRC message (MBS Broadcast Configuration Message) is used for MBS broadcast.

[0148] <Native TMGI paging processing> As mentioned above, when paging a UE 3 for an MBS service having different TMGIs associated with different PLMNs / core networks 7-X, 7-Y, the shared RAN node 5 is configured to include a single TMGI (forming a TMGI list associated with the MBS service) in the paging message, even if the shared RAN node 5 receives multiple paging requests from AMFs 10-1-X, 10-1-Y of different PLMNs / core networks 7-X, 7-Y. The relevant paging procedure will now be described in more detail, by way of example only, with reference to Figures 13A and 13B.

[0149] 13A and 13B show simplified message sequence diagrams of two different paging scenarios that may occur in the communication system 1 of FIG.

[0150] It will be appreciated that in the examples of Figures 13A and 13B, it is assumed that UE3 stores native TMGI lists (as allocated by different PLMNs) corresponding to the same shared MBS service. This may be based on the received PTM configuration described with reference to Figures 9 and 10 or Figures 11 and 12, for example. However, it will be appreciated that the way in which the TMGI list can be configured in UE3 is not essential to the procedures of Figures 13A and 13B.

[0151] In this example, for the same MBS service (MBS service #1), TMGI1 is allocated from PLMN1 and TMGI2 is allocated from PLMN2, so the native TMGI list includes both TMGI1 and TMGI2 for this MBS service.

[0152] As seen in (a) of Figures 13A and 13B, when the shared RAN node 5 receives, at S1310a, a paging (or activation) request sent from one AMF 10-1-X of the core network 7-X associated with PLMN1 indicating one of the TMGIs in the TMGI list (e.g., TMGI1 in the illustrated example), the shared RAN node 5 forwards, at S1312a, a paging message indicating that TMGI (e.g., TMGI1) over the air interface.

[0153] Nevertheless, as seen in S1320a, after receiving the paging message including the TMGI (TMGI1) for PLMN1, UE3 associated with PLMN2 can find the TMGI (TMGI1) sent in the paging message in the TMGI list stored in that UE3 for the corresponding PTM configuration / MBS service, because UE3 previously stored that TMGI list in association with the PTM configuration for the MBS service. Thus, upon finding the TMGI (TMGI1) sent in the paging message in the TMGI list, UE3 can enter a connected (RRC_CONNECTED) state in response to the paging message.

[0154] Nevertheless, it will be appreciated that for a UE 3 associated with PLMN 1, because PLMN 1 has allocated a TMGI (TMGI 1) for the MBS service, when UE 3 in PLMN 1 finds that TMGI in the paging message, it can enter a connected (RRC_CONNECTED) state in response to the paging message to receive the MBS service without necessarily referring to the TMGI list.

[0155] As can be seen in (b) of Figures 13A and 13B, when the shared RAN node 5 receives, at S1310b-1 and S1310b-2, multiple paging (or activation) requests sent from different AMFs 10-1-X, 10-1-Y of different core networks 7-X, 7-Y associated with different PLMNs (PLMN1 and PLMN2), each paging / activation request indicates a different one of the TMGIs in the TMGI list (e.g., TMGI1 and TMGI2, respectively, in the illustrated example), and thus the shared RAN node 5 can forward, at S1312b, a paging message indicating only one of the TMGIs (e.g., TMGI1 or TMGI2) over the air interface.

[0156] As seen in S1320b, after receiving the paging message including the TMGI (TMGI1 or TMGI2), UE3 associated with PLMN 2 can find that TMGI in the TMGI list stored in it for the corresponding PTM configuration / MBS service, even though it is a TMGI (e.g., TMGI1) for a different PLMN (e.g., PLMN1), because UE3 previously stored that TMGI list in association with the PTM configuration for the MBS service. Thus, upon finding the TMGI sent in the paging message in its TMGI list, UE3 can enter a connected (RRC_CONNECTED) state in response to the paging message.

[0157] Nevertheless, it will be appreciated that if the TMGI in the paging message is a TMGI (e.g., TMGI2) of a PLMN (e.g., PLMN2) with which UE3 is associated, then when UE3 of that PLMN (e.g., PLMN2) finds that TMGI in the paging message, it can enter a connected (RRC_CONNECTED) state in response to the paging message to receive MBS services without necessarily referring to the TMGI list.

[0158] <User Plane (NG-U / F1-U) Tunnel Establishment - Shared DU and CU / Non-Distributed RAN> As mentioned above, the shared RAN node 5 can determine the number of (NG-U / F1-U) user plane tunnels to establish. Specifically, if one NG-U tunnel (and an F1-U tunnel of a distributed RAN) is already established between one of the core networks 7-X, 7-Y and the shared RAN node 5, the shared RAN node 5 can decide to share this NG-U tunnel (and an F1-U tunnel) with another one of the core networks 7-X, 7-Y of another operator in order to save transport network resources. Alternatively, the shared RAN node 5 can determine that multiple NG-U / F1-U tunnels should be established, e.g., one NG-U / F1-U tunnel for each MBS session of different PLMNs. Furthermore, if the shared RAN node 5 decides to establish only one NG-U / F1-U tunnel with the first PLMN / core network 7-X, the shared RAN node 5 may notify the AMF 10-1-Y of the second PLMN / core network 7-Y (e.g., via the first AMF 10-1-X of the first PLMN / core network 7-X) that there is already an existing NG-U / F1-U tunnel with a TMGI allocated by the first core network 7-X.

[0159] A procedure for informing the AMF 10-1-Y from a distributed shared RAN node 5 where both DU 5b and CU 5c are shared (or from a non-distributed RAN) that there is already an existing NG-U / F1-U tunnel with a TMGI allocated by another core network 7-X will now be described, by way of example only, with reference to Figure 14. It will be appreciated that the shared RAN node 5 in this procedure is aware of the association between the AMF 10-1-X, 10-1-Y and the associated TMGI (for the same MBS service), for example based on one of the options described above.

[0160] FIG. 14 is a simplified sequence diagram of a procedure for informing a core network node 7 of the existence of an existing user plane tunnel.

[0161] As seen at S1410 and S1412, in step 1 of the procedure, the shared RAN node 5 communicates with a first AMF 10-1-X of a first PLMN (PLMN1) to establish a user plane (NG-U) tunnel with a user plane function in the core network 7-X of the first PLMN (PLMN1).

[0162] The tunnel establishment procedure, in this example, includes the first AMF 10-1-X sending, at S1410, a broadcast session setup request message to the shared RAN node 5, including information for identifying the MBS service and / or MBS session to which the request relates. This information may be, for example, a TMGI associated with the first PLMN (e.g., "TMGI-X1"), an identifier (e.g., a service identifier as described above), a session ID (which need not be an MBS session ID as described above), etc. The broadcast session setup request message also includes information for identifying the user plane tunnel from the core network's perspective (e.g., a 5GC GTP-U tunnel ID) and an associated IP address.

[0163] The tunnel establishment procedure also includes, in this example, the shared RAN node 5 sending a broadcast session setup response message to the first AMF 10-1-X to complete the establishment procedure at S1412. The broadcast session setup response message includes information for identifying the MBS service and / or MBS session to which the request relates, and information for identifying the user plane tunnel from the RAN perspective (e.g., NG RAN GTP-U Tunnel ID), and the associated IP address.

[0164] As seen at S1414, in step 2 of the procedure, the shared RAN node 5 determines which of one or more other operators / AMFs 10-1 associated with one or more other PLMNs should be notified about the existing user plane (NG-U) tunnel.

[0165] As seen at S1416, in step 3 of the procedure, the shared RAN node 5 (specifically, the CU of the shared RAN) sends a configuration update message to the second AMF 10-1-Y of the second PLMN (PLMN2). The configuration update message includes, in this example, information for identifying the MBS service and / or MBS session to which the request relates. This information may be, for example, a TMGI (e.g., "TMGI-X2") associated with the second PLMN, an identifier (e.g., a service identifier as described above), a session ID (which need not be an MBS session ID as described above), etc. The configuration update message also includes a (shared) MBS session ID, a pair of user plane tunnel identifiers (e.g., a GTP-U tunnel ID pair), and an associated IP address. It will be appreciated that this message to the second AMF 10-1-Y may be any suitable message (including a new message for this purpose) for informing the second AMF 10-1-Y that the shared RAN node 5 has already established a user plane (GTP-U) tunnel pair with another AMF 10-1-X.

[0166] As seen in S1418, in step 4 of the procedure, the second AMF 10-1-Y may decide to do one of the following: still attempting to establish a new user plane (GTP-U) tunnel pair for the shared MBS service (i.e., one tunnel per MBS session per PLMN) by the following steps: Attempting to establish a new user plane (GTP-U) tunnel pair to provide a backup user plane (GTP-U) tunnel for the shared MBS service by the following steps: The following procedure reuses an existing GTP-U tunnel pair to provide a shared MBS service.

[0167] If the second AMF 10-1-Y decides to attempt to establish a new user plane (GTP-U) tunnel pair for a shared MBS service (i.e., for one tunnel per MBS session per PLMN), in step 5a (as seen in S1420), the second AMF 10-1-Y sends a broadcast session setup request message to the shared RAN node 5, in S1420, including information for identifying the MBS service and / or MBS session to which the request relates. This information may be, for example, a TMGI associated with the second PLMN (e.g., "TMGI-X2"), an identifier (e.g., a service identifier as described above), a session ID (which does not need to be an MBS session ID as described above), etc. The broadcast session setup request message also includes, in this case, information for identifying the new user plane tunnel from the perspective of the core network (e.g., a 5GC GTP-U tunnel ID) and an associated IP address.

[0168] If the second AMF 10-1-Y decides to attempt to establish a new user plane (GTP-U) tunnel pair for the shared MBS service (i.e., for one tunnel per MBS session per PLMN), the shared RAN node 5 may respond in one of the following ways: The shared RAN node 5 may proceed by establishing the new tunnel and sending a broadcast session setup response in step 5b (as in one option of S1422) including the newly established NG-RAN side (GTP-U) tunnel ID and IP address; The shared RAN node 5 may, in step 5b, send a broadcast session setup response including an indication of successful session setup, the (shared) MBS session ID, the previously established GTP-U tunnel ID pair and IP address of the shared MBS service in step 5b (as in the alternative of S1422), this response signifying that no new NG-RAN side GTP-U tunnel is established; the shared RAN node 5 may in step 5b send a broadcast session setup response including an indication of successful session setup, the (shared) MBS session ID, but without any NG-RAN side (GTP-U) tunnel ID and IP address of the shared MBS service, which response also means that no new NG-RAN side GTP-U tunnel is established; the shared RAN node 5 may in step 5b send a broadcast session setup failure message indicating that it is unable to establish a new user plane (GTP-U) tunnel for the shared MBS service by using a new appropriate cause value (such as, for example, "existing NG-U tunnel for the same MBS service"); or The shared RAN node 5 may send a broadcast session setup response in step 5b containing an indication of successful session setup but not containing the (shared) MBS session ID, the NG-RAN side tunnel ID and IP address of the shared MBS service, which also means that no new NG-RAN side GTP-U tunnel has been established.

[0169] If the second AMF 10-1-Y decides to attempt to establish a new user plane (GTP-U) tunnel pair to provide a backup user plane (GTP-U) tunnel for the shared MBS service, in step 5a (as seen in S1420), the second AMF 10-1-Y transmits a broadcast session setup request message to the shared RAN node 5, including information for identifying the MBS service and / or MBS session to which the request relates. This information may be, for example, a TMGI associated with the second PLMN (e.g., "TMGI-X2"), an identifier (e.g., a service identifier as described above), a session ID (which does not necessarily have to be an MBS session ID as described above), etc. The broadcast session setup request message also includes, in this case, information for identifying the new user plane tunnel from the perspective of the core network (e.g., a 5GC GTP-U tunnel ID) and an associated IP address. However, in this case, the broadcast session setup request message also includes an explicit indication of the intention that a backup GTP-U tunnel pair is about to be established.

[0170] If the second AMF 10-1-Y decides to attempt to establish a new user plane (GTP-U) tunnel pair to provide a backup user plane (GTP-U) tunnel for the shared MBS service, then in step 5b (as seen in S1420), the shared RAN node 5 may respond by establishing the new tunnel and sending a broadcast session setup response including the newly established NG-RAN side (GTP-U) tunnel ID and IP address in step 5a (as seen in one option of S1422).

[0171] If the second AMF 10-1-Y decides to reuse an existing GTP-U tunnel pair to provide a shared MBS service, the second AMF 10-1-Y can proceed in one of the following ways in step 5a: Sending a broadcast session setup request message without core network side user plane (GTU-U) tunnel information for the first AMF 10-1-X; sending a broadcast session setup request message with a (shared) MBS session ID but without user plane (GTU-U) tunnel information; Sending a broadcast session setup request message with the GTP-U tunnel ID pair and IP address of the existing user plane tunnel to indicate an explicit intent that the existing tunnel be reused (as seen in one option of S1420).

[0172] It will also be appreciated that the second AMF 10-1-Y may indicate its intention to reuse an existing user plane (GTP-U) tunnel pair by another explicit indicator.

[0173] If the second AMF 10-1-Y decides to reuse the existing GTP-U tunnel pair to provide the shared MBS service, the shared RAN node 5 may respond in step 5b by sending a broadcast session setup response to acknowledge successful establishment of the broadcast session. This message may also include the GTP-U tunnel ID pair and / or the (shared) MBS session ID received in the request message (as in one option of S1422).

[0174] The shared RAN node 5 may also reject the request from the second AMF 10-1-Y with an appropriate new cause value instructing the second AMF 10-1-Y to reuse the same user plane (GTP-U) tunnel pair previously indicated by the shared RAN node 5 (e.g., if that tunnel pair has already been separated).

[0175] Although the procedure of Figure 14 is described in the context of setting up a broadcast session, it will be appreciated that the same principles apply and similar procedures can be used for setting up a multicast session.

[0176] <Establishment of user plane (NG-U / F1-U) tunnel - shared DU / non-shared CU> As mentioned above, the shared RAN node 5 can determine the number of (NG-U / F1-U) user plane tunnels to establish. Specifically, if one NG-U tunnel (and an F1-U tunnel of a distributed RAN) is already established between one of the core networks 7-X, 7-Y and the shared RAN node 5, the shared RAN node 5 can decide to share this NG-U tunnel (and an F1-U tunnel) with another one of the core networks 7-X, 7-Y of another operator in order to save transport network resources. Alternatively, the shared RAN node 5 can determine that multiple NG-U / F1-U tunnels should be established, e.g., one NG-U / F1-U tunnel for each MBS session of different PLMNs. Furthermore, if the shared RAN node 5 decides to establish only one NG-U / F1-U tunnel with the first PLMN / core network 7-X, the shared RAN node 5 may notify the AMF 10-1-Y of the second PLMN / core network 7-Y (e.g., via the first AMF 10-1-X of the first PLMN / core network 7-X) that there is already an existing NG-U / F1-U tunnel with a TMGI allocated by the first core network 7-X.

[0177] Another procedure for informing the AMF 10-1-Y of the already existing NG-U / F1-U tunnel with a TMGI allocated by another core network 7-X from the distributed shared RAN node 5, in this case where the DU 5b is shared but the CU 5c is not, will now be described, by way of example only, with reference to Figure 15. It will be appreciated that the shared RAN node 5 in this procedure is aware of the association between the AMF 10-1 and the relevant TMGI (for the same MBS service), for example based on one of the options described above.

[0178] FIG. 15 is a simplified sequence diagram of an alternative procedure for informing a core network node 7 of the existence of an existing user plane tunnel.

[0179] As seen at S1510 and S1512, in step 1 of the procedure, a first (non-shared) CU 5c-X of a shared RAN node 5 (associated with a first PLMN (PLMN1)) communicates with a first AMF 10-1-X of the first PLMN (PLMN1) to establish a user plane (NG-U) tunnel with a user plane function in the core network 7 of the first PLMN (PLMN1).

[0180] The tunnel establishment procedure, in this example, includes the first AMF 10-1-X sending a broadcast session setup request message to the first CU 5c-X at S1510, the broadcast session setup request message including information for identifying the MBS service and / or MBS session to which the request relates. This information may be, for example, a TMGI associated with the first PLMN (e.g., "TMGI-X1"), an identifier (e.g., a service identifier as described above), a session ID (which need not be an MBS session ID as described above), etc. The broadcast session setup request message also includes information for identifying the user plane tunnel from the core network's perspective (e.g., a 5GC GTP-U tunnel ID) and an associated IP address.

[0181] As part of the tunnel establishment procedure, in this example the first CU 5c-X communicates with the shared DU 5b of the shared RAN node 5 to establish a (F1-U) user plane tunnel over the F1-U interface.

[0182] The tunnel establishment procedure also includes, in this example, the first CU 5c-X sending a broadcast session setup response message to the first AMF 10-1-X to complete the establishment procedure at S1512. The broadcast session setup response message includes information for identifying the MBS service and / or MBS session to which the request relates, and information for identifying the user plane tunnel from the RAN perspective (e.g., NG RAN GTP-U tunnel ID), and the associated IP address.

[0183] As seen in S1514, in step 2 of the procedure, the shared DU 5b determines which of one or more other operators / CUs 5c associated with one or more other PLMNs should be notified about the existing user plane (NG-U) tunnel.

[0184] As seen in S1516a, in step 3 of the procedure, the shared DU 5b sends a configuration update message (e.g., a gNB-CU configuration update message) to a second (non-shared) CU 5c-Y of the shared RAN node 5 associated with a second PLMN (PLMN2). The configuration update message, in this example, includes information for identifying the MBS service and / or MBS session to which the request relates. This information may be, for example, a TMGI associated with the second PLMN (e.g., "TMGI-X2"), an identifier (e.g., a service identifier as described above), a session ID (which need not be an MBS session ID as described above), etc. The configuration update message also includes the (shared) MBS session ID, a user plane tunnel identifier pair (e.g., an F1-U tunnel ID pair), and the associated IP addresses. It will be appreciated that this message to the second AMF 10-1-Y may be any suitable message (including a new message specifically for this purpose) for informing the second CU 5c-Y that an F1-U user plane tunnel pair with another CU 5c-X has already been established.

[0185] As seen in S1516b, in step 3b of the procedure, the second CU 5c-Y sends a configuration update message to the second AMF 10-1-Y of the second PLMN. The configuration update message, in this example, includes information for identifying the MBS service and / or MBS session to which the request relates. This information may be, for example, a TMGI associated with the second PLMN (e.g., "TMGI-X2"), an identifier (e.g., a service identifier as described above), a session ID (which does not necessarily have to be an MBS session ID as described above), etc. The configuration update message also includes a (shared) MBS session ID, a user plane tunnel identifier pair (e.g., an F1-U tunnel ID pair), and an associated IP address. It will be appreciated that this message to the second AMF 10-1-Y may also be any suitable message for informing the second AMF 10-1-Y that an F1-U user plane tunnel pair with another CU 5c-X has already been established.

[0186] As can be seen in S1518, in step 4 of the procedure, the second AMF 10-1-Y may decide to do one of the following: still attempting to establish a new user plane tunnel pair for the shared MBS service (i.e., one tunnel per MBS session per PLMN) over the F1-U interface by the following steps: attempting to establish a new user plane tunnel pair on the F1-U interface to provide a backup user plane tunnel for the shared MBS service by the following steps: The following steps are taken to reuse an existing tunnel pair on the F1-U interface to provide a shared MBS service.

[0187] If the second AMF 10-1-Y decides to attempt to establish a new user plane tunnel pair for a shared MBS service (i.e., for one tunnel per MBS session per PLMN) on the F1-U interface, in step 5a (as seen in S1520), the second AMF 10-1-Y sends a broadcast session setup request message to the second CU 5c-Y, in S1520, including information for identifying the MBS service and / or MBS session to which the request relates. This information may be, for example, a TMGI associated with the second PLMN (e.g., "TMGI-X2"), an identifier (e.g., a service identifier as described above), a session ID (which does not need to be an MBS session ID as described above), etc. The broadcast session setup request message also includes, in this case, information for identifying the new user plane tunnel from the perspective of the core network (e.g., a 5GC GTP-U tunnel ID) and an associated IP address.

[0188] If the second AMF 10-1-Y decides to attempt to establish a new user plane tunnel pair for a shared MBS service (i.e., for one tunnel per MBS session per PLMN), the second CU 5c-Y may respond in one of the following ways: The second CU5c-Y may establish a new tunnel, including the establishment of a new F1-U tunnel with the shared DU5b (as in one option of S1521), and proceed in step 5b by sending a broadcast session setup response including the newly established NG-RAN side (GTP-U) tunnel ID and IP address (as in one option of S1522); The second CU5c-Y may proceed by establishing a broadcast using the existing F1-U tunnel (as seen in one option of S1521) and sending in step 5b a broadcast session setup response including an indication of successful session setup, the (shared) MBS session ID, the previously established F1-U tunnel ID pair and IP address of the shared MBS service (as seen in another option of S1522), this response meaning that no new F1-U tunnel is being established; The second CU5c-Y may establish a broadcast using the existing F1-U tunnel (as seen in one option of S1521) and in step 5b send a broadcast session setup response containing an indication of successful session setup, the (shared) MBS session ID, but without any NG-RAN side (GTP-U) tunnel ID and IP address of the shared MBS service, which also means that no new F1-U tunnel is established; The second CU5c-Y may establish a broadcast using an existing F1-U tunnel (as in one option of S1521) and in step 5b send a Broadcast Session Setup Failure message indicating that it is unable to establish a new user plane (GTP-U) tunnel for the shared MBS service by using a new appropriate cause value (e.g., "existing F1-U tunnel of the same MBS service"), or The second CU5c-Y may establish a broadcast using an existing F1-U (as seen in one option of S1521) and send a broadcast session setup response in step 5b containing an indication of successful session setup but not including the (shared) MBS session ID, the NG-RAN side tunnel ID and IP address of the shared MBS service, which also means that a new F1-U tunnel has not been established.

[0189] If the second AMF 10-1-Y decides to attempt to establish a new user plane (GTP-U) tunnel pair to provide a backup user plane (GTP-U) tunnel for the shared MBS service, in step 5a (as seen in S1520), the second AMF 10-1-Y sends a broadcast session setup request message to the second CU 5c-Y, in S1520, including information for identifying the MBS service and / or MBS session to which the request relates. This information may be, for example, a TMGI associated with the second PLMN (e.g., "TMGI-X2"), an identifier (e.g., a service identifier as described above), a session ID (which does not necessarily have to be an MBS session ID as described above), etc. The broadcast session setup request message also includes, in this case, information for identifying the new user plane tunnel from the perspective of the core network (e.g., a 5GC GTP-U tunnel ID) and an associated IP address. However, in this case, the broadcast session setup request message also includes an explicit indication of the intention that a backup GTP-U tunnel pair is about to be established.

[0190] If the second AMF10-1-Y decides to attempt to establish a new user plane (GTP-U) tunnel pair to provide a backup user plane (GTP-U) tunnel for the shared MBS service, the second CU5c-Y can establish a new tunnel, including establishing a new F1-U tunnel with the shared DU5b (as seen in one option of S1521), and respond in step 5b by sending a broadcast session setup response including the newly established NG-RAN side (GTP-U) tunnel ID and IP address (as seen in one option of S1522).

[0191] If the second AMF 10-1-Y decides to reuse an existing GTP-U tunnel pair to provide a shared MBS service, the second AMF 10-1-Y can proceed in one of the following ways in step 5a: sending a broadcast session setup request message without user plane (F1-U) tunnel information; sending a broadcast session setup request message with a (shared) MBS session ID but without user plane (F1-U) tunnel information; and Sending a broadcast session setup request message with the F1-U tunnel ID pair and IP address of the existing user F1-U plane tunnel to indicate an explicit intent that the existing tunnel be reused (as seen in one option of S1520).

[0192] It will also be appreciated that the second AMF 10-1-Y may indicate its intention to reuse the existing user plane (F1-U) tunnel pair by another explicit indicator.

[0193] If the second AMF 10-1-Y decides to reuse the existing F1-U tunnel pair to provide the shared MBS service, the second CU 5c-Y may respond in step 5b by sending a broadcast session setup response to acknowledge the successful establishment of the broadcast session. This message may also include the F1-U tunnel ID pair and / or the (shared) MBS session ID received in the request message (as in one option of S1522).

[0194] The second CU5c-Y can also reject the request from the second AMF10-1-Y with an appropriate new cause value that instructs the second AMF10-1-Y to reuse the same user plane (F1-U) tunnel pair previously indicated by the second CU5c-Y (for example, if that tunnel pair has already been separated).

[0195] It will also be appreciated that although the procedure of Figure 15 is described in the context of setting up a broadcast session, the same principles apply and similar procedures can be used for setting up a multicast session.

[0196] <Modifications and Alternatives> Detailed embodiments have been described above. As those skilled in the art will appreciate, several modifications and alternatives can be made to the above embodiments while still benefiting from the present disclosure embodied therein.

[0197] For example, while novel and advantageous features of devices of a communication system are described with particular reference to 5G / NR communication technologies, it will be understood that the advantageous features may be implemented in devices of a communication system using other communication technologies, such as, for example, other communication technologies developed as part of 3GPP. For example, while the base stations and UEs are described as 5G base stations (gNBs) and corresponding UEs, it will be understood that the features described above may apply to RAN nodes (eNBs) and UEs implementing LTE / LTE-Advanced communication technologies, or RAN nodes and UEs implementing other communication technologies developed using 3GPP-derived communication technologies.

[0198] In the above description, the UE and base station are described for ease of understanding as having several separate functional components or modules. While these modules may be provided in this manner in certain applications, such as applications where an existing system is being modified to implement the present disclosure, in other applications, such as systems designed from the beginning with the features of the present invention, these modules may not be identified as separate entities because they may be incorporated into an overall operating system or code.

[0199] In the above embodiments, several software modules have been described. As will be understood by those skilled in the art, the software modules may be provided in compiled or uncompiled form and may be supplied to the base station, mobility management entity, or UE as a signal over a computer network or on a recording medium. Furthermore, the functions performed by some or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred because it facilitates updating the base station or UE to update its functionality.

[0200] Each controller may comprise any suitable form of processing circuitry, including (but not limited to), for example, one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuitry, internal memory / cache (program and / or data), processing registers, communication buses (e.g., such as a control bus, a data bus, and / or an address bus), direct memory access (DMA) facilities, hardware or software-implemented counters, pointers, and / or timers, etc. Various other modifications will be apparent to those skilled in the art and will not be described in further detail herein.

[0201] User equipment (or "User Equipment" (UE), "mobile station," "mobile device," or "wireless device") in this disclosure is an entity that connects to a network via a wireless interface.

[0202] It should be noted that the present disclosure is not limited to dedicated communication devices, but can be applied to any device having communication capabilities as described in the following paragraphs.

[0203] The terms "user equipment" or "User Equipment (UE)" (as this term is used by 3GPP), "mobile station," "mobile device," and "wireless device" are generally intended to be synonymous with each other and include standalone mobile stations such as terminals, cell phones, smartphones, tablets, cellular IoT devices, IoT devices, and machines. It will be understood that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for extended periods of time.

[0204] The UE may be, for example, an item of production or manufacturing equipment and / or an item of energy-related machinery (e.g., equipment or machinery such as boilers, engines, turbines, solar panels, wind turbines, hydroelectric generators, thermal generators, nuclear generators, batteries, nuclear systems and / or related equipment, heavy electrical machinery, pumps including vacuum pumps, compressors, fans, blowers, hydraulic equipment, pneumatic equipment, metalworking machinery, manipulators, robots and / or application systems thereof, tools, dies or molds, rolls, conveying equipment, elevators, material handling equipment, textile machinery, sewing machinery, printing and / or related machinery, paper converting machinery, chemical machinery, mining and / or construction machinery and / or related equipment, machinery and / or implements for the agricultural, forestry and / or fisheries industries, safety and / or environmental protection equipment, tractors, precision bearings, chains, gears, power transmission equipment, lubrication equipment, valves, pipe fittings, and / or application systems for any of the foregoing equipment or machinery, etc.).

[0205] A UE may be, for example, an item of transportation equipment (e.g., a rail car, an automobile, a motorcycle, a bicycle, a train, a bus, a cart, a rickshaw, a boat or other watercraft, an aircraft, a rocket, a satellite, a drone, a balloon, or other transportation equipment).

[0206] A UE may be, for example, an item of information and communications equipment (eg, information and communications equipment such as electronic computers and related equipment, communications and related equipment, electronic components, etc.).

[0207] The UE may be, for example, a refrigerator, a refrigerator application product, an item of trade and / or service industry equipment, a vending machine, an automated service machine, an office machine or equipment, a home appliance and electronic device (e.g., household appliances such as audio equipment, video equipment, loudspeakers, radios, televisions, microwave ovens, rice cookers, coffee machines, dishwashers, washing machines, dryers, electronic fans or related equipment, vacuum cleaners, etc.).

[0208] The UE may be, for example, an electrical application system or device (such as, for example, an electrical application system or device, such as an x-ray system, a particle accelerator, a radioisotope device, a sonic device, an electromagnetic application device, a power application device, etc.).

[0209] The UE may be, for example, an electronic lamp, lighting fixture, measuring instrument, analyzer, tester, or surveying or detecting equipment (e.g., surveying or detecting equipment such as a smoke alarm, human alarm sensor, motion sensor, radio tag, etc.), a watch or clock, laboratory equipment, optical device, medical equipment and / or system, weapon, cutlery, hand tool, etc.

[0210] The UE may be, for example, a wirelessly equipped personal digital assistant or related equipment (such as a wireless card or module designed to be attached to or inserted into another electronic device (e.g., a personal computer, an electrical measuring instrument)).

[0211] The UE may be part of a device or system that uses various wired and / or wireless communication technologies to provide the applications, services, and solutions described below with respect to the Internet of Things (IoT).

[0212] Internet of Things devices (or "Things") may be equipped with appropriate electronics, software, sensors, network connections, etc. that enable these devices to collect and exchange data with each other and other communicating devices. IoT devices may comprise automated equipment that follows software instructions stored in internal memory. IoT devices may operate without the need for human supervision or interaction. IoT devices may also remain stationary and / or inactive for extended periods of time. IoT devices may be implemented as part of (typically) stationary equipment. IoT devices may also be incorporated into non-stationary equipment (e.g., vehicles) or attached to animals or people being monitored / tracked.

[0213] It will be appreciated that IoT technologies may be implemented on any communication device that can be connected to a communication system to transmit / receive data, whether such communication device is controlled by human input or by software instructions stored in memory.

[0214] It will be appreciated that IoT devices may also be referred to as Machine-Type-Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed below in Table 1. This list is not exhaustive and is intended to illustrate some examples of machine-type communication applications.

[0215] Table 1: Some examples of MTC uses [Table 1]

[0216] Applications, services, and solutions include Mobile Virtual Network Operator (MVNO) services, emergency wireless communication systems, Private Branch eXchange (PBX) systems, PHS / digital cordless telecommunications systems, Point of Sale (POS) systems, incoming advertising systems, Multimedia Broadcast and Multicast Service (MBMS), Vehicle-to-Everything (V2X) systems, train radio systems, location-related services, disaster / emergency wireless communication services, community services, video streaming services, femtocell application services, Voice over LTE (VoLTE) services, billing services, wireless on-demand services, roaming services, activity monitoring services, telecommunications carrier / network selection services, function restriction services, Proof of Concept (PoC) services, personal information management services, and ad hoc / delay tolerant networks. It may be a Delay Tolerant Networking (DTN) service.

[0217] Furthermore, the above-mentioned UE categories are merely examples of applications of the technical concepts and embodiments described in this document. Needless to say, these technical concepts and embodiments are not limited to the above-mentioned UEs, and various modifications are possible.

[0218] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0219] This application is based on and claims the benefit of priority from UK Patent Application No. 2302230.4, filed February 16, 2023, the entire disclosure of which is incorporated herein by reference.

[0220] <Additional Notes> The exemplary embodiments disclosed above may be explained in whole or in part as follows, but are not limited to these.

[0221] (Appendix 1) 1. A method performed by an access network node, comprising: receiving a request for setup of a multicast or broadcast service identified by a second identifier for a Multicast and Broadcast Service (MBS) session from a second communication node of a second network of the plurality of networks sharing the access network node; determining whether resources of an MBS session for a multicast or broadcast service can be shared with at least one MBS session associated with a first identifier, the value of which corresponds to the value of the second identifier; Including, The method, wherein at least one MBS session is requested from a first network of a plurality of networks sharing an access network node using a first identifier. (Appendix 2) establishing a first user plane tunnel with a first communication node of a first network for a multicast or broadcast service identified by a first identifier; sending information to a second communication node to indicate that a first user plane tunnel has been established for a multicast or broadcast service, the information including a second identifier for the MBS session, the second identifier indicating the multicast or broadcast service; 2. The method of claim 1, further comprising: (Appendix 3) receiving the request includes, after transmitting the information, receiving a request to set up a second user plane tunnel for the multicast or broadcast service as a new tunnel; 3. The method of claim 1 or 2, wherein the method includes sending a message to the second communication node indicating that the second user plane tunnel has not been established. (Appendix 4) The messages include a session setup message, 4. The method of claim 3, wherein the message does not include a tunnel identifier and an Internet Protocol (IP) address for the second user plane tunnel. (Appendix 5) 5. The method of claim 3 or 4, wherein the message includes a tunnel identifier and an IP address for the first user plane tunnel. (Appendix 6) The message includes the session identifier of the MBS session, 6. The method of any one of appendixes 3 to 5, wherein the session identifier includes the first identifier. (Appendix 7) The message includes a session setup failure message, 4. The method of claim 3, wherein the message includes a cause value indicating that the second user plane tunnel cannot be established. (Appendix 8) receiving the request includes receiving a request to set up a second user plane tunnel for a multicast or broadcast service as a backup for the first user plane tunnel; 3. The method of claim 1 or 2, wherein the method includes sending a message to the second communication node indicating that the second user plane tunnel is established as a backup for the first user plane tunnel. (Appendix 9) 9. The method of claim 8, wherein the request includes an indication that the second communications node intends to establish a second user plane tunnel as a backup to the first user plane tunnel. (Appendix 10) 10. The method of claim 8 or 9, wherein the message includes a tunnel identifier and an Internet Protocol (IP) address for the second user plane tunnel. (Appendix 11) receiving the request includes receiving, by the second communication node, an indication from the second communication node to reuse the first user plane tunnel to provide the multicast or broadcast service; 3. The method of claim 2, wherein the method includes configuring, by the second communication node, the first user plane tunnel to reuse the first user plane tunnel to provide a multicast or broadcast service. (Appendix 12) the information includes a tunnel identifier and an Internet Protocol (IP) address for the first user plane tunnel, and a session identifier for the MBS session, the session identifier including the first identifier; The instructions are: a tunnel identifier for the first user plane tunnel; The IP address for the first user plane tunnel, or Session identifier for the MBS session 12. The method of claim 11, comprising at least one of: (Appendix 13) 13. The method of claim 11 or 12, further comprising: if the first user plane tunnel is no longer established, sending a rejection message including a cause value indicating that the request is rejected. (Appendix 14) receiving the request includes receiving a request to set up a second user plane tunnel for the multicast or broadcast service as a new tunnel before transmitting the information; 3. The method of claim 2, wherein the method includes sending a rejection message to the second communication node to reject the request. (Appendix 15) 15. The method of any one of Supplementary Notes 2 to 14, wherein the information indicates that a request to set up a new tunnel for a multicast or broadcast service is not permitted. (Appendix 16) 16. The method of any one of Supplementary Notes 1 to 15, wherein the access network node comprises a Central Unit (CU) of a distributed access network. (Appendix 17) the first communication node includes a first core network node of the first network; 17. The method of any one of appendixes 1 to 16, wherein the second communication node comprises a second core network node of the second network. (Appendix 18) 13. The method of claim 5, 10 or 12, wherein the tunnel identifier identifies a tunnel on an interface between an access network node and a core network node to provide user plane functionality. (Appendix 19) 16. The method according to any one of Supplementary Notes 1 to 15, wherein the access network node comprises a Distributed Unit (DU) of a distributed access network. (Appendix 20) The first communication node includes a first Central Unit (CU) of a distributed access network; 20. The method of claim 19, wherein the second communication node includes a second CU of the distributed access network. (Appendix 21) 13. The method of claim 5, 10 or 12, wherein the tunnel identifier identifies a tunnel on an interface between an access network node and a Central Unit (CU) of the distributed access network. (Appendix 22) Each of the first identifier and the second identifier is An Internet Protocol (IP) address corresponding to a multicast or broadcast service, or Each Temporary Mobile Group Identifier (TMGI) 22. The method according to any one of appendices 1 to 21, comprising: (Appendix 23) A method performed by a second communication node, comprising: receiving, from the access network node, information indicating that a first user plane tunnel has been established for a multicast or broadcast service, the information including a second identifier for a Multicast and Broadcast Service (MBS) session of the multicast or broadcast service; A method, wherein a first user plane tunnel is established by a first communication node of a first network among a plurality of networks sharing an access network node for multicast or broadcast services, and a second network including a second communication node is included in the plurality of networks sharing the access network node. (Appendix 24) 1. A method performed by a user equipment (UE), comprising: receiving, from an access network node, configuration information for a multicast or broadcast service including first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, each identifier of the plurality of different identifiers including information indicating the multicast or broadcast service and information indicating a different respective network of a plurality of networks sharing the access network node; Using an identifier from a plurality of different identifiers to initiate establishment of an MBS session for receiving multicast or broadcast services, the identifier corresponding to a network to which the UE belongs. A method comprising: (Appendix 25) From the access network node, Information indicating available multicast or broadcast services, and receiving a message including an identifier, the message including information regarding a first network of the plurality of networks; determining whether an identifier of an MBS session included in the message is one of a plurality of different identifiers of the MBS session; if the identifier of the MBS session included in the message is one of a plurality of different identifiers of the MBS session, communicating with a first access network node corresponding to the first network to receive the available multicast or broadcast service; 25. The method of claim 24, further comprising: (Appendix 26) 26. The method of claim 24 or 25, wherein the configuration information includes single-point to multipoint configuration information. (Appendix 27) Each identifier of the plurality of different identifiers is An Internet Protocol (IP) address corresponding to a multicast or broadcast service, or Each Temporary Mobile Group Identity (TMGI) 27. The method according to any one of appendices 24 to 26, comprising: (Appendix 28) The first information is Information for configuring radio bearers; Information for adding at least one Multicast and Broadcast Service (MBS) bearer Dedicated signaling, MBS Control Channel (MCCH), MBS configuration information, or Radio Resource Configuration (RRC) Message 28. The method according to any one of appendices 24 to 27, wherein at least one of the following is included: (Appendix 29) 26. The method of claim 25, wherein the message comprises a paging message. (Appendix 30) 30. The method of claim 29, wherein the UE and the access network node are configured for communication in a second network different from the first network. (Appendix 31) 30. The method of claim 29, wherein the UE and the access network node are configured for communication in a first network. (Appendix 32) 32. The method of any one of Supplementary Notes 29 to 31, wherein communicating with the first access network node includes communicating with the first access network node to enter a Radio Resource Control (RRC) connected state to receive available multicast or broadcast services. (Appendix 33) 1. A method performed by an access network node, comprising: transmitting, to a user equipment (UE), configuration information for a multicast or broadcast service including first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, wherein each identifier of the plurality of different identifiers includes information indicating the multicast or broadcast service and information indicating a different respective network of a plurality of networks sharing an access network node; receiving information from the UE to establish an MBS session for receiving multicast or broadcast services by the UE by using an identifier from a plurality of different identifiers, the identifier corresponding to a network to which the UE belongs; A method comprising: (Appendix 34) To UE, Information indicating available multicast or broadcast services, and transmitting a message including an identifier, the message including information regarding a first network of the plurality of networks; If the identifier of the MBS session included in the message is one of a plurality of different identifiers of the MBS session, communicating with the UE for receiving an available multicast or broadcast service by the UE. 34. A method performed in accordance with claim 33, further comprising: (Appendix 35) an access network node, means for receiving a request for setup of a multicast or broadcast service (MBS) session from a second communication node of a second network of the plurality of networks sharing the access network node, the request being identified by a second identifier for the multicast and broadcast service (MBS) session; means for determining whether resources of an MBS session for a multicast or broadcast service can be shared with at least one MBS session associated with a first identifier, the value of which corresponds to the value of the second identifier; Equipped with An access network node, wherein at least one MBS session is requested from a first network of a plurality of networks sharing the access network node using a first identifier. (Appendix 36) a second communication node, means for receiving, from an access network node, information indicating that a first user plane tunnel has been established for a multicast or broadcast service, the information including a second identifier for a Multicast and Broadcast Service (MBS) session of the multicast or broadcast service; The first user plane tunnel is established by a first communication node in a first network among a plurality of networks sharing an access network node for multicast or broadcast services, and the second network including a second communication node is included in the plurality of networks sharing the access network node. (Appendix 37) A user equipment (UE), means for receiving, from an access network node, configuration information for a multicast or broadcast service including first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, wherein each identifier of the plurality of different identifiers includes information indicating the multicast or broadcast service and information indicating a different respective network of a plurality of networks sharing the access network node; means for using an identifier from a plurality of different identifiers to initiate establishment of an MBS session for receiving multicast or broadcast services, the identifier corresponding to a network to which the UE belongs; A user equipment (UE) comprising: (Appendix 38) an access network node, means for transmitting, to a User Equipment (UE), configuration information for a multicast or broadcast service including first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, wherein each identifier of the plurality of different identifiers includes information indicating the multicast or broadcast service and information indicating a different respective network of a plurality of networks sharing an access network node; means for receiving information from the UE to establish an MBS session for receiving a multicast or broadcast service by the UE by using an identifier from a plurality of different identifiers, the identifier corresponding to a network to which the UE belongs; An access network node comprising: [Explanation of symbols]

[0222] 1. Communication Systems 3UE 5 RAN nodes, base stations 5b Distributed Unit 5c Central Unit 7 Core Network, Core Network Nodes 9 cells 10 CPF 10-1 AMF 10-2 SMF 11 UPF 20. Internet 31, 51, 51b, 51c, 71 Transceiver circuit 33, 53b, 53c Antenna 35 User Interface 53 Air Interface 55 Core Network Interface 55c,75 network interface 37,57,77 Controller 57b DU Controller 57c CU controller 39,59,79 memory 59b DU Memory 59c CU memory 41,61,81 Operating Systems 61b DU Operating System 61c CU operating system 43,63,83 Communication control module 63b DU communication control module 63c CU communication control module 45,65,85 MBS Management Module 65b MBS management module (DU part) 65c MBS management module (CU part)

Claims

1. 1. A method performed by an access network node, comprising: receiving a request for setup of a multicast or broadcast service identified by a second identifier for a Multicast and Broadcast Service (MBS) session from a second communication node of a second network of a plurality of networks sharing the access network node; determining whether resources of the MBS session for the multicast or broadcast service can be shared with at least one MBS session associated with a first identifier whose value corresponds to the value of the second identifier; Including, the at least one MBS session is requested from a first network of the plurality of networks sharing the access network node using the first identifier. method.

2. establishing a first user plane tunnel with the first communication node of the first network for the multicast or broadcast service identified by the first identifier; transmitting information to the second communication node to indicate that the first user plane tunnel has been established for the multicast or broadcast service, the information including a second identifier for an MBS session, the second identifier indicating the multicast or broadcast service; The method of claim 1 further comprising:

3. receiving the request includes receiving a request to set up a second user plane tunnel for the multicast or broadcast service as a new tunnel after the transmission of the information; the method including sending a message to the second communication node indicating that the second user plane tunnel is not established; 3. The method according to claim 1 or 2.

4. the message includes a session setup message; the message does not include a tunnel identifier and an Internet Protocol (IP) address for the second user plane tunnel. The method of claim 3.

5. the message includes a tunnel identifier and an IP address for the first user plane tunnel. The method according to claim 3 or 4.

6. the message includes a session identifier for the MBS session; the session identifier includes the first identifier; The method according to any one of claims 3 to 5.

7. the message includes a session setup failure message; the message includes a cause value indicating that the second user plane tunnel cannot be established. The method of claim 3.

8. receiving the request includes receiving a request to set up the second user plane tunnel for the multicast or broadcast service as a backup for the first user plane tunnel; the method including sending a message to the second communication node indicating that the second user plane tunnel is established as the backup for the first user plane tunnel; 3. The method according to claim 1 or 2.

9. the request includes an indication that the second communication node intends to establish the second user plane tunnel as the backup to the first user plane tunnel. The method of claim 8.

10. the message includes a tunnel identifier and an Internet Protocol (IP) address for the second user plane tunnel.

10. The method according to claim 8 or 9.

11. receiving the request includes receiving, by the second communication node, an indication from the second communication node to reuse the first user plane tunnel for providing the multicast or broadcast service; the method including configuring, by the second communication node, the first user plane tunnel to reuse the first user plane tunnel for providing the multicast or broadcast service; The method of claim 2.

12. the information includes a tunnel identifier and an Internet Protocol (IP) address for the first user plane tunnel, and a session identifier for the MBS session, the session identifier including the first identifier; The instructions are: the tunnel identifier for the first user plane tunnel; the IP address for the first user plane tunnel; or the session identifier of the MBS session at least one of: The method of claim 11.

13. sending a rejection message including a cause value indicating that the request is rejected if the first user plane tunnel is no longer established.

13. The method of claim 11 or 12, further comprising:

14. receiving the request includes receiving a request to set up the second user plane tunnel for the multicast or broadcast service as a new tunnel before the transmission of the information; the method including sending a rejection message to the second communication node to reject the request; The method of claim 2.

15. the information indicating that a request to set up a new tunnel for the multicast or broadcast service is not authorized. The method according to any one of claims 2 to 14.

16. The access network node includes a central unit (CU) of a distributed access network; The method according to any one of claims 1 to 15.

17. the first communication node comprises a first core network node of the first network; the second communication node comprises a second core network node of the second network; The method according to any one of claims 1 to 16.

18. the tunnel identifier identifies a tunnel on an interface between the access network node and a core network node to provide a user plane function; 13. The method of claim 5, 10 or 12.

19. The access network node includes a distributed unit (DU) of a distributed access network; The method according to any one of claims 1 to 15.

20. the first communication node includes a first Central Unit (CU) of the distributed access network; the second communication node includes a second CU of the distributed access network; 20. The method of claim 19.

21. the tunnel identifier identifies a tunnel on an interface between the access network node and a Central Unit (CU) of a distributed access network; 13. The method of claim 5, 10 or 12.

22. Each of the first identifier and the second identifier is an Internet Protocol (IP) address corresponding to the multicast or broadcast service; or Each Temporary Mobile Group Identity (TMGI) Including, 22. The method according to any one of claims 1 to 21.

23. A method performed by a second communication node, comprising: receiving, from an access network node, information indicating that a first user plane tunnel has been established for a multicast or broadcast service, the information including a second identifier for a Multicast and Broadcast Service (MBS) session of the multicast or broadcast service; the first user plane tunnel is established by a first communication node of a first network among a plurality of networks sharing the access network node for the multicast or broadcast service, and a second network including the second communication node is included in the plurality of networks sharing the access network node; method.

24. 1. A method performed by a User Equipment (UE), comprising: receiving, from an access network node, configuration information for a multicast or broadcast service including first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, each identifier of the plurality of different identifiers including information indicating the multicast or broadcast service and information indicating a different respective network of a plurality of networks sharing the access network node; using an identifier from the plurality of different identifiers to initiate establishment of an MBS session for receiving the multicast or broadcast service, the identifier corresponding to a network to which the UE belongs; A method comprising:

25. from the access network node: Information indicating available multicast or broadcast services, and receiving a message including an identifier, the message including information about a first network of the plurality of networks; determining whether the identifier of the MBS session included in the message is one of a plurality of different identifiers of the MBS session; if the identifier of the MBS session included in the message is one of the plurality of different identifiers of the MBS session, communicating with a first access network node corresponding to the first network to receive the available multicast or broadcast service; 25. The method of claim 24, further comprising:

26. the configuration information includes single-point to multipoint configuration information; 26. The method of claim 24 or 25.

27. Each of the plurality of different identifiers comprises: an Internet Protocol (IP) address corresponding to the multicast or broadcast service; or Each Temporary Mobile Group Identity (TMGI) Including, The method according to any one of claims 24 to 26.

28. The first information is Information for configuring radio bearers; Information for adding at least one Multicast and Broadcast Service (MBS) bearer Dedicated signaling, MBS Control Channel (MCCH), MBS configuration information, or Radio Resource Control (RRC) Messages Included in at least one of 28. The method according to any one of claims 24 to 27.

29. The message includes a paging message.

26. The method of claim 25.

30. the UE and the access network node are configured for communication in a second network different from the first network.

30. The method of claim 29.

31. the UE and the access network node are configured for communication in the first network; 30. The method of claim 29.

32. and wherein the communicating with the first access network node includes communicating with the first access network node to enter a Radio Resource Control (RRC) connected state to receive the available multicast or broadcast service.

32. The method according to any one of claims 29 to 31.

33. 1. A method performed by an access network node, comprising: transmitting, to a User Equipment (UE), configuration information for a multicast or broadcast service including first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, wherein each identifier of the plurality of different identifiers includes information indicating the multicast or broadcast service and information indicating a different respective network of a plurality of networks sharing the access network node; receiving information from the UE to establish an MBS session for receiving the multicast or broadcast service by the UE by using an identifier from the plurality of different identifiers, the identifier corresponding to a network to which the UE belongs; A method comprising:

34. The UE, Information indicating available multicast or broadcast services, and information about a first network of the plurality of networks; sending a message including an identifier, If the identifier of the MBS session included in the message is one of a plurality of different identifiers for the MBS session, communicating with the UE to receive the available multicast or broadcast service by the UE.

34. A method performed in accordance with claim 33, further comprising:

35. an access network node, means for receiving a request for setup of a multicast or broadcast service identified by a second identifier for a Multicast and Broadcast Service (MBS) session from a second communication node of a second network of a plurality of networks sharing the access network node; means for determining whether resources of the MBS session for the multicast or broadcast service can be shared with at least one MBS session associated with a first identifier, the value of which corresponds to the value of the second identifier; Equipped with the at least one MBS session is requested from a first network of the plurality of networks sharing the access network node using the first identifier. Access network node.

36. a second communication node, means for receiving, from an access network node, information indicating that a first user plane tunnel has been established for a multicast or broadcast service, the information including a second identifier for a Multicast and Broadcast Service (MBS) session of the multicast or broadcast service; the first user plane tunnel is established by a first communication node of a first network among a plurality of networks sharing the access network node for the multicast or broadcast service, and a second network including the second communication node is included in the plurality of networks sharing the access network node; A second communication node.

37. A User Equipment (UE), means for receiving, from an access network node, configuration information for a multicast or broadcast service, the first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, each identifier of the plurality of different identifiers including information indicating the multicast or broadcast service and information indicating a different respective one of a plurality of networks sharing the access network node; means for using an identifier from the plurality of different identifiers to initiate establishment of an MBS session for receiving the multicast or broadcast service, the identifier corresponding to a network to which the UE belongs; A user equipment (UE) comprising:

38. an access network node, means for transmitting, to a User Equipment (UE), configuration information for a multicast or broadcast service including first information including a plurality of different identifiers for a Multicast and Broadcast Service (MBS) session, wherein each identifier of the plurality of different identifiers includes information indicating the multicast or broadcast service and information indicating a different respective one of a plurality of networks sharing the access network node; means for receiving information from the UE to establish an MBS session for receiving the multicast or broadcast service by the UE by using an identifier from the plurality of different identifiers, the identifier corresponding to a network to which the UE belongs; and An access network node comprising:

Images