WO2024172040A1

WO2024172040A1 - Access network node, second communication node, user equipment, and methods of them

Info

Publication number: WO2024172040A1
Application number: PCT/JP2024/004883
Authority: WO
Inventors: Zhe Chen; Xuelong Wang; Yuhua Chen; Neeraj Gupta
Original assignee: Nec Corporation
Priority date: 2023-02-16
Filing date: 2024-02-13
Publication date: 2024-08-22
Also published as: GB2627245A; GB202302230D0

Abstract

A method is disclosed in which a user equipment (UE) receives, form an access network node, configuration information for a multicast or broadcast service, and information including a plurality of different identifiers for multicast and broadcast services (MBS) sessions. Each identifier of the plurality of different identifiers is associated with the multicast or broadcast service but is associated with a different respective network of a plurality of networks that share the access network node.

Description

ACCESS NETWORK NODE, SECOND COMMUNICATION NODE, USER EQUIPMENT, AND METHODS OF THEM

　　The present disclosure relates to a communication system.

　　The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including LTE-Advanced, Next Generation or 5G networks, future generations, and beyond). The disclosure also has particular, although not necessarily exclusive, relevance to the provision of multimedia broadcast sessions in shared access networks operating according to the so-called '5G' (or 'Next Generation') systems or similar.

　　Previous developments of the 3GPP standards include those referred to as the Long Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) has been used to refer to an evolving communication technology that is expected to support a variety of applications and services such as MTC / IoT communications, vehicular communications and autonomous cars, high resolution video streaming, smart city services, and/or the like. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https://www.ngmn.org/5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

　　Under the 3GPP standards, a NodeB (or an eNB in LTE, gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node', or 'base station') via which communication devices (user equipment or 'UE') connect to a core network and communicate to other communication devices or remote servers. Communication between the UEs and the base station is controlled using the so-called Radio Resource Control (RRC) protocol. For simplicity, the present application will use the term (R)AN node or base station to refer to any such access nodes.

　　In the current 5G architecture, for example, the RAN node structure may be split into two parts known as the Central Unit (CU) and the Distributed Unit (DU), connected by an F1 interface. This enables the use of a 'split' architecture, whereby the, typically 'higher', CU layers (for example, but not necessarily or exclusively), the packet data convergence protocol (PDCP) layer and the, typically 'lower', DU layers (for example, but not necessarily or exclusively, radio link control (RLC), medium / media access control (MAC), and/or physical (PHY) sublayers) to be implemented separately. Thus, for example, the higher layer CU functionality for a number of RAN nodes may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally, in each of the RAN nodes.

　　For simplicity, the present application will use the term mobile device, user device, or UE to refer to any communication device that is able to connect to the core network via one or more base stations. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and/or generally stationary) that can connect to a communication system for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory. For example, such a communication device may be operable by a human or may be a partially or fully automated (e.g., machine-type-communication (MTC) / Internet of Things (IoT)) device.

　　One of the more recent technologies being developed within the existing 5G framework is referred to as Multicast and Broadcast Services (MBS - or 'NR MBS' in 5G) which aims to reuse cellular infrastructure such as the so-called Low Power Low Tower (LPLT) infrastructure. This technology aims to enhance 5G New Radio and 5G core network (5GC) capabilities for a reliable, low latency, resource efficient, and massive deployment of a wide array of multicast and broadcast services. Although MBS is designed to use existing (or already specified) 3GPP infrastructure, it can provide a more efficient delivery of multicast/broadcast traffic than unicast communication using the same infrastructure. Among the many use cases that could benefit from resource-efficient delivery of multicast/broadcast services in the context of general MBS services over the 5G system, are: public safety and mission critical applications; vehicle-to-everything (V2X) applications; internet protocol television (IPTV); live video; software delivery over wireless and IoT applications; and/or the like. Two delivery modes were agreed in an earlier 3GPP release: MBS with delivery mode 1 (only for multicast) that is capable of addressing higher quality-of-service (QoS) services; and delivery mode 2 (only for broadcast) focusing on lower QoS services. Whilst the earlier 3GPP release version of MBS provided the basic functionality required to support MBS services there is, nevertheless, an ongoing need to refine the functionality to enable better deployment of MBS (for example improvements in resource efficiency and/or capacity).

　　3GPP is working on enhancements to improve the resource efficiency for MBS reception in scenarios when a RAN is shared among multiple Public Land Mobile Networks (PLMNs). Such RAN sharing is becoming increasingly common as operators seek to reduce their capital expenditure (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., the physical antenna, tower, site, power etc.) is shared between two or more operators, but the communication spectrum is not. In contrast, MOCN involves two or more core networks sharing the same physical RAN including the communication spectrum. The existing core networks may, nevertheless, remain separate. MOCN is generally more resource efficient as it gives the operators the opportunity to pool their respective spectrum allocations, resulting in improved efficiency.

　　RAN sharing does not require broadcast/multicast of the same content via multiple PLMNs, which may be useful, for example, for connected vehicles, TV streaming, amongst other things. With RAN sharing, UEs (e.g., vehicles) of multiple operators can receive an MBS session from the same PLMN (e.g., a V2X MBS session). In the case of TV streaming, RAN sharing would allow multicasting/broadcasting TV content by one operator. It will be appreciated that in other generations (earlier or later) of communication technology, functionality broadly corresponding to the Multicast and Broadcast Services (MBS) in 5G 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 Services (MBMS).

　　When addressing the issue of introducing MBS in the context of RAN sharing, it has been agreed that procedures that are based on the assumption that MOCN RAN nodes will be able to 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 from the core network, the following principles should be taken into account:

　　from the core network, the following principles should be taken into account:
Any procedure provided for RAN sharing should have no (or minimal) impact on a UE or base station technology operating in accordance with the previous standards release;
Any identity for providing a reference to the same MBS service should not be dependent on sharing operators that participate temporarily (e.g., sharing operators that leave or enter a common ongoing MBS session from time to time). Specifically, any new procedure should be robust enough to cover the possibility that the shared PLMNs start and stop the MBS session at the same time and start and stop the MBS session at a different time.

　　Any new procedure should not be based on an assumption that the multicast/broadcast session management function (MB-SMF), application function (AF), and/or multicast/broadcast service function (MBSF) will be aware of which NG-RAN node (or which cell of an NG-RAN node) is shared because currently the NG-RAN node only informs the access and mobility management function (AMF) of the supported PLMN, and there is no coordination with the MB-SMF/AF/MBSF.

　　MBS is allowed for UEs operating in RRC idle mode (i.e., for UEs without an active UE /specific data connection with the network). Each UE interested in MBS monitors the system information broadcast by nearby base stations and determines the resources used for the relevant MBS control channel (MCCH) and MBS data channel (MTCH). The base stations also broadcast the respective identifier (such as MBS session identifiers or Temporary Mobile Group Identities (TMGIs)) for each MBS session provided in their cell. The TMGI is the MBS session identifier that uniquely identifies a particular MBS service or 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. Effectively, therefore, the TMGI includes a specific PLMN ID (PLMN ID = MCC plus MNC) of a single PLMN (e.g., associated with a particular mobile network operator (MNO) and/or a mobile virtual network operators (MVNOs)).

　　The TMGI effectively prevents a UE that is not allowed to from using the service. If the PLMN ID of a PLMN that a UE is allowed to use (e.g., because the UE is served by an MNO/MVNO that provides - or has an agreement to use - that PLMN) is part of the TMGI, then that UE can receive the associated MBS service in that MBS session. However, UEs that are not authorised to use that PLMN (e.g., because they are provided by an MNO/MVNO that does not have an agreement to do so) cannot receive an MBS service in that MBS session. Where a RAN that is shared between different operators providing different PLMNs the RAN is effectively part of more than one PLMN. In this case, therefore, a UE may be able to access a cell of the shared RAN (because it is allowed to use one of the PLMNs). Nevertheless, the UE may not be able to use a particular MBS service provided in that cell (that the UE would otherwise be able to access) because that 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 allowed to use.

　　An MBS session will have 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 to ('mtch-SchedulingInfo'); an associated physical downlink shared channel (PDSCH) configuration ('pdsch-Config'); and/or the like. A respective PTM configuration may be configured for each TMGI value of a list of TMGIs meaning that a PTM configuration associated with one TMGI may be a duplicate of a PTM configuration associated with another TMGI. Hence each TMGI of multiple TMGIs may be respectively associated with essentially a copy of the same PTM configuration.

　　Accordingly, for a scenario in which the RAN is shared between of two (or more) operators / virtual operators, the same MBS service could be provided by each operator separately using a different respective TMGI (associated with that operator's PLMN) with each different TMGI being associated with the same PTM configuration. This would, however, effectively result in duplicated PTM radio resource consumption in the same cell for transmission of the same content. Moreover, as each 5G core operator's core network may be shared by multiple virtual operators, the number of separate PLMN IDs - and hence TMGIs allocated for the same MBS session - has the potential to increase significantly over time. Hence the issue of duplicated resource usage will likely become even more important.

　　Moreover, an MBS broadcast session may include an MCCH. For a particular MCCH configuration, however, there can be a maximum number (currently 1024) of PTM configurations. Accordingly, if a base station of a shared RAN configures multiple duplicated PTM configurations, each with a different respective TMGI, it has the potential to use up too many of maximum number of PTM configurations. Similarly, there is a maximum number (currently 32) of MRB configurations that can be added (e.g., by means of the MRB-ToAddModList-r17 IE in the 5G standards) for an MBS multicast session. If a base station of a shared RAN configures multiple duplicated PTM configurations with the same TMGI, therefore, it will take too many of it has the potential to use up too many of the maximum number of MRB configurations.

　　While the possibility of using a unified TMGI for all PLMNs has been considered (e.g., a so called 'foreign' TMGI that is coordinated by the service layer), the general consensus has been that a 'native' TMGI (i.e., a PLMN specific TMGI) should be supported.

　　In 5G, user plane transport for a UE is via a radio bearer RB between the UE and the RAN and via one or more general packet radio services (GPRS) tunnelling protocol (GTP) / internet protocol (IP) transport tunnels between the RAN and the core network. One such transport tunnel is a next generation user-plane (NG-U) tunnel over the so-called 'N3' or 'user plane' interface/reference point between the RAN and a user plane function (UPF) in the core network and, in the case of a distributed RAN. In the case of a distributed RAN there is another such tunnel - an F1 user plane (F1-U) tunnel - over the F1 interface / reference point between a DU and the CU of the distributed base station.

　　For the provision of MBS services, one or more shared NG-U tunnels may be established to provide transport for shared MBS traffic delivery towards the base station. In the context of RAN sharing, however, the question arises as to how best to establish one or more NG-U tunnels per session and/or per PLMN. Three distinct options for this have been considered:

　　Option 1: establish a different respective NG-U tunnel for each session, for different PLMNs;

　　Option 2: establish a single shared NG-U tunnel for multiple MBS sessions from different PLMNs; and

　　Option 3: establish one primary NG-U shared tunnel, and one secondary ('backup') NG-U, tunnel for multiple sessions from different PLMNs.

　　A fourth option is to provide support for all three of the above options to support flexible implementation with the RAN node deciding which option is adopted (i.e., one NG-U tunnel or multiple NG-U tunnels) by implementation. This may be summarised as follows:

　　Option 4: NG-RAN node implementation decides on how many NG-U tunnels to be set up.

　　No clear conclusion has been arrived at, but the common understanding is that the NG-RAN should decide how many NG-U tunnel should be established (i.e., Option 4) because there is no coordination between the different PLMN core networks. If an AMF decides whether it can establish an additional tunnel with the NG-RAN for an MBS service, then the AMF needs to know if another PLMN already has an existing NG-U tunnel for that MBS service.

　　It will be appreciated that that a similar question arises in respect of F1-U tunnels - i.e., how many (shared) F1-U tunnels should be established.

　　It can be seen, therefore, that in the case of RAN sharing, as there may be multiple 5GCs connected to the same RAN node, if there is already one NG-U tunnel (and F1-U tunnel for a distributed RAN) established between one of these 5GCs and the RAN node, the NG-RAN node may decide to share this NG-U tunnel (and F1-U tunnel) with the 5GC of another operator in order to save transport network resources (this is effectively option 2 indicated above). Alternatively, the NG-RAN node may decide that multiple NG-U/F1-U tunnels are to be established - e.g., one NG-U/F1-U tunnel for each MBS session for different PLMNs (this is effectively option 1 indicated above).

　　However, as there is no coordination between PLMNs of the different 5GCs, the RAN node is the only node that knows whether a shared NG-U/F1-U tunnel is to be established for MBS services or whether multiple such tunnels are to be established. This raises the issue of how to handle tunnel establishment for the different 5GCs/PLMNs sharing the RAN efficiently while minimizing unnecessary signalling (e.g., from an AMF of one PLMN to request establishment of an additional tunnel, when a tunnel has already been established by another AMF of another PLMN, and the shared RAN has decided this tunnel is to be a shared).

　　Moreover, when sharing a distributed RAN, however, while in one case both the DU and CU may be shared, in another case only the DU is shared and there is a different respective CU for each operator/PLMN. In the case that both the DU and CU are shared, when an F1-U tunnel has been established by a first operator for an MBS service the CU will know that this tunnel has been set up, and will have the related MBS related information, when coordinating with the 5GC (e.g., an AMF of another operator). However, if only the DU is shared, then this raises the issue of how to handle a situation in which the CU of one operator has already established an F1-U tunnel to the DU.

　　When there is no active service for a multicast MBS service, a UE is supposed to be released to an inactive state (e.g., RRC_INACTIVE). In order to reach UEs that are in the RRC inactive state to notify them about the activation of the MBS service, therefore, some form of paging/notification mechanism is required. To facilitate this a group-based paging mechanism has been developed for notifying one or more UEs of the activation of a multicast service. As part of this, in order to notify the activation of the multicast service to one or more UEs, the TMGI of the multicast service is included within a paging message. A recipient UE can thus check if it is interested in receiving that service and, if the service is of interest, then the UE can go into a connected state (e.g., RRC_CONNECTED) to receive the activated multicast service.

PTL 1: WO 2023/286784A1
PTL 2: EP 3061293A1
PTL 3: WO 2016/124983A1
PTL 4: EP 3449680A1
PTL 5: WO 2022/262589A1

NPL 1: The 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, available from https://www.ngmn.org/5g-white-paper.html.

　　However, a similar mechanism to notify the UE of the activation of a multicast service in the case of a RAN sharing scenario, in which the multicast service may have multiple native TMGIs for different PLMNs, is challenging. For example, the inclusion of multiple TMGIs for the same multicast service in a single paging message can result in an undesirably large paging message, which increases signalling overhead over air interface, and thus reduce efficiency.

　　Another issue to be considered in the context of MBS RAN sharing scenarios is, therefore, how paging, to notify a group of UEs of the activation of a multicast/broadcast service, should be carried out.

　　There is, therefore, significant room for further development and improvement in relation to the delivery of MBS related functionality, in the context both of the RAN sharing scenario, and of the need to ensure efficient resource usage.

　　Accordingly, the present disclosure seeks to provide methods and associated apparatus that address or at least alleviate (one or more of) the above-described issues.

　　Aspects of the disclosure are set out in the appended independent claims. Beneficial but optional features are set out in the appended dependent claims.

　　In one aspect there is provided a method performed by an access network node, the method comprising:
　　receiving, from a second communication node of a second network of a plurality of networks that share the access network node, a request for setup for a multicast or broadcast service identified by a second identifier f or a multicast and broadcast service (MBS) session; and
　　determining whether a resource 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 a value of the second identifier,
　　wherein the at least one MBS session being requested from a first network of the plurality of networks that share the access network node, using the first identifier.

　　In one aspect there is provided a method performed by a second communication node, the method comprising:
　　receiving, from an access network node, information for 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 for the multicast or broadcast service,
　　wherein the first user plane tunnel has been established by a first communication node of a first network of a plurality of networks that share 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 that share the access network node.

　　In one aspect there is provided a method performed by a user equipment (UE), the method comprising:
　　receiving, form 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) sessions, 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 that share the access network node; and
　　using an identifier of the plurality of different identifiers for initiating an establishment a MBS session to receive the multicast or broadcast service, wherein the identifier corresponds to a network which the UE belongs to.

　　In one aspect there is provided a method performed by an access network node, the method 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) sessions, 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 that share the access network node; and
　　receiving, from the UE, information for establishing a MBS session to receive, by the UE, the multicast or broadcast service by using, by the UE, an identifier of the plurality of different identifiers, wherein the identifier corresponds to a network which the UE belongs to.

　　In one aspect there is provided an access network node comprising:
　　means for receiving, from a second communication node of a second network of a plurality of networks that share the access network node, a request for setup for a multicast or broadcast service identified by a second identifier for a multicast and broadcast service (MBS) session; and
　　means for determining whether a resource 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 a value of the second identifier,
　　wherein the at least one MBS session being requested from a first network of the plurality of networks that share the access network node, using the first identifier.

　　In one aspect there is provided a second communication node comprising:
　　means for receiving, from an access network node, information for 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 for the multicast or broadcast service,
　　wherein the first user plane tunnel has been established by a first communication node of a first network of a plurality of networks that share 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 that share the access network node.

　　In one aspect there is provided a user equipment (UE) comprising:
　　means for receiving, form 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) sessions, 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 that share the access network node; and
　　means for using an identifier of the plurality of different identifiers for initiating an establishment a MBS session to receive the multicast or broadcast service, wherein the identifier corresponds to a network which the UE belongs to.

　　In one aspect there is provided 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) sessions, 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 that share the access network node; and
　　means for receiving, from the UE, information for establishing a MBS session to receive, by the UE, the multicast or broadcast service by using, by the UE, an identifier of the plurality of different identifiers, wherein the identifier corresponds to a network which the UE belongs to.

　　Aspects of the disclosure extend to corresponding systems, apparatus, and computer program products such as computer readable storage media having instructions stored thereon which are operable to program a programmable processor to carry out a method as described in the aspects and possibilities set out above or recited in the claims and/or to program a suitably adapted computer to provide the apparatus recited in any of the claims.

　　Each feature disclosed in this specification (which term includes the claims) and/or shown in the drawings may be incorporated in the disclosure independently of (or in combination with) any other disclosed and/or illustrated features. In particular but without limitation the features of any of the claims dependent from a particular independent claim may be introduced into that independent claim in any combination or individually.

　　According to the present disclosure, 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 are provided.

　　The foregoing and further objects, features and advantages of the present subject matter will become apparent from the following description of example embodiments with reference to the accompanying drawings, wherein like numerals are used to represent like elements.

　　It is to be noted, however, that the appended drawings along with the reference numerals illustrate only typical example embodiments of the present subject matter, and are therefore, not to be considered for limiting of its scope, for the subject matter may admit to other equally effective example embodiments.

　　Example embodiments of the disclosure will now be described, by way of example, with reference to the accompanying drawings in which:

Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system; Fig. 2A illustrates different types of shared RAN that may be used in the communication system of Fig. 1; Fig. 2B illustrates different types of shared RAN that may be used in the communication system of Fig. 1; Fig. 3A illustrates the structure of a TMGI and a definition of an MBS session ID that may be used in the communication system of Fig. 1; Fig. 3B illustrates the structure of a TMGI and a definition of an MBS session ID that may be used in the communication system of Fig. 1; Fig. 4 is a simplified illustration of part of an ASN.1 definition of a data structure for a paging message that may be used in the communication system of Fig. 1; Fig. 5 is a schematic block diagram illustrating the main components of a UE for the communication system of Fig. 1; Fig. 6 is a simplified block schematic illustrating the main components of a distributed RAN node which may be used as shared RAN node in the communication system of Fig. 1; Fig. 7 is a schematic block diagram illustrating the main components of a non-distributed RAN node which may be used as shared RAN node in the communication system of Fig. 1; Fig. 8 a schematic block diagram illustrating the main components of a core network node which may be used in the communication system of Fig. 1; Fig. 9 illustrates one way in which a list of TMGIs for an MBS service may be notified to a UE in the communication system of Fig. 1; Fig. 10 is a simplified illustration of part of an ASN.1 definition of a data structure for a radio bearer configuration information element that may be used in the communication system of Fig. 1; Fig. 11 illustrates another way in which a list of TMGIs for an MBS service may be notified to a UE in the communication system of Fig. 1; Fig. 12 is a simplified illustration of part of ASN.1 definition of a data structure for an MBS broadcast configuration message that may be used in the communication system of Fig. 1; Fig. 13A shows simplified message sequence diagrams for two different paging scenarios that may occur in the communication system of Fig. 1; Fig. 13B shows simplified message sequence diagrams for two different paging scenarios that may occur in the communication system of Fig. 1; Fig. 14 is a simplified sequence diagram of a procedure for notifying a core network node of the presence of an existing user plane tunnel in the communication system of Fig. 1; and Fig. 15 is a simplified sequence diagram of another procedure for notifying a core network node of the presence of an existing user plane tunnel in the communication system of Fig. 1.

Description of Example Embodiments

< Overview >
　　An exemplary communication system will now be described, by way of example only, with reference to Figs. 1 to 4.

　　Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system 1 to which example embodiments of the present disclosures are applicable.

　　In the communication system 1 user equipment (UEs) 3-1, 3-2, 3-3 (e.g. mobile telephones and/or other mobile devices) can communicate with each other via a (radio) access network ((R)AN) node 5 (RAN node 5, base station 5) that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN node 5 comprises a distributed NR/5G base station or 'gNB' operating one or more associated cells 9. Communication via the RAN node 5 is typically routed through one of associated core networks 7-X, 7-Y (e.g. a 5G core network or evolved packet core network (EPC)).

　　As those skilled in the art will appreciate, whilst three UEs 3, one RAN node 5 and two core networks 7-X, 7-Y are shown in Fig. 1 for illustration purposes, the communication system 1, when implemented, will typically include other core networks 7, other RAN nodes 5 and UEs 3.

　　Each RAN node 5 controls one or more associated cells 9 either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and/or the like). It will be appreciated that the RAN node 5 may be configured to support both 4G and 5G, and/or any other 3GPP or non-3GPP communication protocols.

　　In this example the illustrated RAN node 5 comprises a distributed base station comprising a distributed unit (DU) 5b, and a central unit (CU) 5c. The CU 5c employs a separated control plane and user plane and so is, itself, split between a control plane function (CU-CP) and a user plane function (CU-UP) which respectively 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')), and with one another via an E1 logical interface. It will be appreciated that while, in this example, the DU 5b includes the physical and virtual elements required to provide the functionality of the lower parts of the PHY layer and hence communicate with the one or more UEs 3 over the air interface, the RAN node 5 may alternatively (or additionally) include one or more separate radio units (RUs) (e.g., providing this functionality of the lower parts of the PHY layer).

　　It will be appreciated that whilst distributed RAN node 5 is shown and described, the RAN node 5 may be provided in a non-distributed form, for example as an integrated gNB or eNB.

　　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) in which the RAN node 5 is shared by the operators of the 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) having its own PLMN identity.

　　Fig. 2A and Fig. 2B illustrate different types of shared RAN node 5 that may be used in the communication system 1. As described in the introduction, the DU 5b and CU 5c may of a shared RAN node 5 may be shared as illustrated at (a) in Fig. 2A and Fig. 2B. Alternatively, only the DU 5b may be shared and there may be a different respective CU 5c-X, 5c-Y, and 5c-Z for each respective core network 7-X, 7-Y, 7-Z, of an associated operator/PLMN as illustrated at (b) in Fig. 2A and Fig. 2B.

　　Referring to the communication system 1 of Fig. 1, therefore, it will be appreciated that, whilst 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 at (a) in Fig. 2A and Fig. 2B), the shared RAN node 5 may be in a configuration in which only the DU 5b is shared and there is a different respective dedicated CU 5c for each core network 7-X and 7-Y (e.g., as seen at (b) in Fig. 2A and Fig. 2B).

　　It will also be appreciated that, the communication system 1 may also include RAN node 5 that is not shared operating cells 9 that are not shared.

　　The one or more UEs 3 and their serving RAN node 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and/or the like). Equipment of neighbouring one or more RAN nodes 5 may be connected to each other via an appropriate base station to base station interface (such as the so-called 'X2' interface, 'Xn' interface and/or the like).

　　Each core network 7-X, 7-Y includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. It can be seen that, in this example, core network 7-X comprises a number of 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 a number of other functions 10-n-X (such as, for example, an Authentication Server Function (AUSF) which facilitates 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), and/or the like). It will be appreciated that the nodes or functions may have different names in different systems.

　　Whilst not illustrated, for reasons of clarity, those skilled in the art will understand that the core network 7-Y (and any other core network sharing the RAN node 5) will include corresponding logical nodes / functions. Each core network 7-X, 7-Y may also be coupled to an Operations and Maintenance (OAM) function (not shown). In the interests of clarity, to help distinguish between such nodes/functions of core network 7-X and such nodes/functions of core network 7-Y, the suffixes '-X' and '-Y' are respectively used herein. Where such nodes/functions are referred to in a more general sense applicable to either core network 7-X, 7-Y, the suffix ('-X', '-Y') may be omitted.

　　The RAN node 5 is connected to the nodes of each core network 7-X, 7-Y via appropriate interfaces (or 'reference points') such as an N2 reference point between the RAN node 5 and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the RAN node 5 and each UPF 11 for the communication of user data. The one or more UEs 3 are each connected to the AMF 10-1 via a logical non-access stratum (NAS) connection over an N1 reference point (analogous to the S1 reference point in LTE). It will be appreciated, that N1 communications are routed transparently via the RAN node 5.

　　One or more UPFs 11 are connected to an external data network (e.g., an IP network such as the internet) via reference point N6 for communication of the user data.

　　The AMF 10-1 performs mobility management related functions, maintains the NAS signalling connection 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 an N11 reference point. The AMF 10-1 and the RAN node 5 are mutually configured for communication with one another to set up appropriate user plane transport tunnels (e.g., GTP-U tunnels) over the N3 interface between the RAN node 5 and a UPF 11 (e.g., NG-U tunnels) and over the F1-U interface, within the RAN node 5, between the CU 5c and the DU 5b (e.g., F1-U tunnels). These tunnels will typically comprise a tunnel pair (GTP-U pair) comprising a corresponding tunnel for uplink communication and for downlink communication. The user plane tunnels may, for example, include 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.

　　The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally 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 what session manager would be best assigned to the user. The SMF 10-2 may be considered effectively to be a gateway from the user plane to the control plane of the network. 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.

　　The RAN node 5 is configured for transmission of, and the one or more UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

　　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 sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data 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) for supporting a number of functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on the physical uplink shared channel PUSCH. The PBCH provides one or more UEs 3 with the Master Information Block, MIB. It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection.

　　The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the RAN node 5. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), positioning reference signal (PRS) as described earlier, and channel state information reference signal (CSI-RS).

　　In the communication system 1, Multicast and Broadcast Services (MBS) functionality may be provided to the one or more UEs 3 via the shared RAN node 5 and associated one or more core network nodes 7 such as the UPF 11 and the SMF 10-2. Specifically the MBS functionality may be provided, via the shared RAN node 5, to the one or more UEs 3 of subscribers of each PLMN that shares the RAN node 5 (and that are allowed 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 the MB-UPF 11 (e.g. dedicated to the provision of MBS functionality). Similarly, the SMF 10-2 may be an MBS specific SMF in which case it may be referred to as the MB-SMF 10-2. However, it will be appreciated that any suitable UPF 11 / SMF 10-2 may be used for MBS. By using a shared RAN node 5 / base station 5 it is possible to avoid or minimise redundant MBS transmissions via multiple networks thereby improving the overall efficiency of multicast/broadcast traffic delivery.

　　As explained above, MBS is a PLMN specific service. Each UE 3 interested in an MBS service monitors the system information broadcast by the shared RAN node 5 in order to determine the resources used for the relevant MBS control channel (MCCH) and/or MBS data channel (MTCH). The shared RAN node 5 also broadcast the respective identifiers (such as an MBS session identifier or Temporary Mobile Group Identity (TMGI)) for each MBS session provided in a cell 9 that it operates.

　　Fig. 3A and Fig. 3B illustrate the structure of the TMGI and a definition of the MBS session ID.

　　As seen at (a) in Fig. 3A and Fig. 3B, the TMGI is the MBS session identifier that uniquely identifies a particular MBS service or 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. Effectively, therefore, the TMGI includes a specific PLMN ID (PLMN ID = MCC plus MNC) of a single PLMN (e.g., associated with a particular mobile network operator (MNO) and/or a mobile virtual network operators (MVNOs)).

　　The MCC consists of three digits (octets) and identifies uniquely the country of domicile of the mobile subscription. The MNC consists of two or three digits (octets) for 3GPP network applications (depending on the assignment to the PLMN by its national numbering plan administrator). The MNC identifies the home PLMN of the mobile subscription within its country of domicile, or it identifies together with MCC and a Network Identifier (NID,) the mobile subscription's Stand-alone Non-Public Network (SNPN). 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 an MBMS bearer service within a PLMN (represented by the MCC and MNC). As the TMGI illustrated at (a) in Fig. 3A and Fig. 3B are a PLMN specific TMGI it may be considered to be a 'native' TMGI.

　　As seen at (b) in Fig. 3A and Fig. 3B an MBS Session ID corresponds to the TMGI, possibly in conjunction with an optional NID.

　　In order to reach one or more UEs 3 that are in a RRC idle/inactive state to notify them about the activation of an MBS service the communication system 1 implements a paging/notification mechanism. Specifically, to facilitate this a group-based paging mechanism is implemented for notifying one or more UEs 3 of the activation of a multicast service. As part of this, in order to notify the activation of the multicast service to one or more UEs 3, the TMGI of the multicast service is included within a paging message from the shared RAN node 5. A recipient UE 3 can thus check if it is interested in receiving that service and, if the service is of interest, then the UE 3 can go into a connected state (e.g., RRC_CONNECTED) to receive the activated multicast service.

　　Fig. 4 is a simplified illustration of part of an abstract syntax notation one (ASN.1) definition of a data structure for a paging message. The illustrated paging message may be used by the RAN node 5 for notifying a group of one or more UEs 3 about one or more MBS sessions for one or more corresponding multicast services. The message may be sent from the RAN node 5 to the UE 3 following an associated paging request from an AMF 10-1. The message may be sent, for example, on a logical Paging Control Channel (PCCH) that maps to a paging transport channel (paging channel (PCH)) and then on to an associated physical downlink shared channel (PDSCH). As seen in Fig. 4, the message includes a "paging group list" ('pagingGroupList') of one or more TMGIs (i.e., representing an associated MBS session ID), each identifying a respective MBS multicast service and an associated PLMN. It will be appreciated that Fig. 4 is included purely for illustrative purposes and, as those skilled in the art will understand, it is not essential to the paging to use the specific data structure shown or to use any of the specific information elements illustrated therein.

　　In the communication system 1, the shared RAN node 5 is beneficially able to identify an association between the AMFs 10-1 and associated TMGIs (for the same MBS service), for example by determining the different native TMGIs (and/or foreign TMGI) associated with essentially the same MBS service / content provided via different PLMNs or in another way. There are a number of ways in which this can be achieved.

　　In a first option, the shared RAN node 5 is configured with one or more TMGIs (or other information from which an association between the AMFs 10-1 and associated TMGIs for the same MBS service can be determined) via an operations administration and maintenance (OAM) function.

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

　　For example, an application function of one core network 7 associated with a first PLMN may allocate an identifier of a broadcast MBS service which is non-PLMN specific, the identifier is then sent to the shared RAN node 5 during an MBS session create procedure. The shared RAN node 5 will be aware of the respective PLMN ID of each operator taking part in MBS RAN sharing via the shared RAN node 5 and can thus determine the corresponding TMGIs / association between the AMFs 10-1 and associated TMGIs for the same MBS service. 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. Accordingly, the shared RAN node 5 can notify the identifier to one or more AMFs 10-1 associated with other PLMNs that are taking part in MBS RAN sharing. Moreover, when another AMF 10-1 has received this identifier from the shared RAN node 5, it is able to know that there is another existing user plane (e.g., NG-U) tunnel with the AMF 10-1 of another operator for that service.

　　Another option uses a common session identifier (e.g. a source specific IP multicast (SSM) address), which is not an MBS session ID, to be the identifier to associate broadcast MBS sessions from different core networks 7-X, 7-Y which transmitting the same content.

　　Specifically, an application function of one core network 7 associated with a first PLMN may provide the associated session identifier (not an MBS session ID) when creating broadcast MBS sessions with the same broadcast content. For all core networks 7-X, 7-Y sharing the shared RAN node 5, MB-SMFs 10-2-X, 10-2-Y may provide the associated session ID to the shared RAN node 5 via one of associated AMFs 10-1-X, 10-1-Y. And then, the shared RAN node 5 can utilise the associated session ID to associate those broadcast MBS sessions with one another and hence one or more associated TMGIs / AMFs 10-1-X, 10-1-Y.

　　The shared RAN node 5 can establish one or more user planes for the first broadcast MBS session it receives. The shared RAN node 5 can thus deliver the packets received from the established user plane over the air. For another broadcast MBS session which is associated with the broadcast MBS session, the shared RAN node 5 can 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 can determine if there is already established user plane of another broadcast MBS session which is associated with the session identifier and skip user plane establishment of a further broadcast MBS session associated with the same session identifier.

　　Accordingly, in this option an application function firstly provides the same session ID to the shared RAN node 5 through a 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 an AMF 10-1 of another core network's PLMN. When the other AMF 10-1 has received the session ID from the shared RAN node 5 it will therefore know that there is another existing user plane (NG-U) tunnel established with the AMF 10-1 of another operator.

　　Another option relies on configuration of the shared RAN node 5 and does not need any new parameter. Instead, the respective service ID part of the TMGI for each RAN node 5 sharing partner (core network 7-X, 7-Y) that corresponds to the same content is configured in the shared RAN node 5.

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

　　Thus the shared the RAN node 5 understands one or more TMGIs for different PLMNs, since the service IDs / service ID range is configured in the RAN node 5. Thus the shared RAN node 5 can notify the TMGI for one PLMN to the AMF 10-1 of another PLMN. When the other AMF 10-1 has received the TMGI from the NG-RAN, it will know that there is another existing user plane (NG-U) tunnel established with the AMF 10-1 of another operator.

　　Whilst another option is to use a single foreign TMGI in an effort to minimise required updates, and to avoid multiple native TMGIs, for the same multicast data broadcast. This is a 'foreign' TMGI solution and as explained in the introduction a general consensus is that 'native' TMGI (i.e., a PLMN specific TMGI) solutions should be supported.

　　Beneficially, as described in more detail below, in the communication system 1, for each UE 3 that may be interested in receiving an MBS service, the shared RAN node 5 is able to configure a respective list of PLMN specific TMGI's (i.e., a Native TMGI list) for that MBS service, to the UE 3. This beneficially avoids the need to provide a respective duplicated point-to-multipoint (PTM) configuration with a different TMGI to the one or more UEs 3 for each PLMN.

　　More specifically, in the case of multicast, the shared RAN node 5 is advantageously able to transmit the respective list of PLMN specific TMGI's (i.e., a Native TMGI list) for one or more multicast MBS services, to the UE 3 via dedicated (e.g., RRC) signalling and the UE 3 is able to retain each TMGI list, in association with a corresponding PTM configuration for a corresponding MBS session / service.

　　Similarly, in the case of broadcast, the shared RAN node 5 is advantageously able to transmit the respective list of PLMN specific TMGI's (i.e., a Native TMGI list) for one or more broadcast MBS services, to the UE 3 via other dedicated (e.g., RRC) signalling and the UE 3 is able to retain each TMGI list, in association with a corresponding PTM configuration for a corresponding MBS session / service.

　　It can be seen, therefore, that the UE 3 is beneficially able to identify a PTM configuration for an MBS service that it is interested to receive, based on a TMGI broadcast by a shared RAN node 5, even if the broadcast TMGI contains a PLMN ID of a PLMN that the UE 3 is not authorised to use. Specifically, the UE 3 is able to 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 being provided via a single PLMN that is not the PLMN of that UE 3.

　　Beneficially, as described in more detail below, when paging the UE 3 about 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 (form a TMGI list associated with the MBS service) in the paging message even if the shared RAN node 5 has received multiple paging requests from AMFs 10-1-X, 10-1-Y of different PLMNs/core networks 7-X, 7-Y. The UE 3 is beneficially able to recognise the TMGI in the paging message, even if it is a TMGI of a PLMN that the UE 3 is not authorised to access, because the UE 3 previously stored the TMGI list for the associated PTM configuration of the MBS service to which the paging message relates. Accordingly, the UE 3 can go to a connected state (e.g., RRC_CONNECTED state) as a response to the paging message to receive the MBS service.

　　In the communication system 1, the shared RAN node 5 can decide the number of (NG-U / F1-U) user plane tunnels to establish. Specifically, if there is already one NG-U tunnel (and F1-U tunnel for a distributed RAN) established between one of the core networks 7-X, 7-Y and the shared RAN node 5, the shared RAN node 5 may decide to share this NG-U tunnel (and 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 may decide that multiple NG-U/F1-U tunnels are to be established - e.g., one NG-U/F1-U tunnel for each MBS session for different PLMNs.

　　Beneficially, if the shared RAN node 5 decides to establish only one NG-U/F1-U tunnel with a first PLMN/core network 7-X, as described in more detail later, the shared RAN node 5 is able to notify an AMF 10-1-Y, of a second PLMN/core network 7-Y that there is already an existing NG-U/F1-U tunnel with the TMGI allocated by the first core network 7-X (e.g., via a first AMF 10-1-X, of the first PLMN/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 associate request and, if the second AMF 10-1-Y has already sent a request to establish an additional NG-U tunnel, the shared RAN node 5 may reject that request.

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

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

< User Equipment (UE) >
　　Fig. 5 is a schematic block diagram illustrating the main components of a UE 3 for the communication system 1 shown in Fig. 1. In this example the UE 3 is a UE that is capable of receiving MBS communication and related configuration signalling as described herein.

　　As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a RAN node 5 via one or more antennas 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE 3 (e.g. a user interface 35, such as a touch screen / keypad / microphone / speaker and/or the like for, allowing direct control by and interaction with a user) and this 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 may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

　　The controller 37 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within 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.

　　The communications control module 43 is operable to control the communication between the UE 3 and its one or more serving RAN nodes 5 (and other communication devices connected to the RAN node 5, such as further one or more UEs 3 and/or one or more core network nodes 7). The communications control module 43 is configured for the overall handling uplink communications via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), random access channel (RACH), and/or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communications control module 43 is also configured for the overall handling receipt of downlink communications via associated downlink channels (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)). The downlink communication may include, for example, both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.), paging communications, dedicated (radio resource control (RRC)) communication, multicast communication (including on the MCCH and/or MTCH), broadcast communications and/or the like. The communications control module 43 is responsible, for example, for determining the resources to be used by the UE 3, for determining how slots/symbols are configured (e.g., for UL, DL, flexible, full duplex communication, or the like), for determining which one or more bandwidth parts are configured for the UE 3, for determining how uplink transmissions should be encoded, etc.

　　It will be appreciated that the communications control module 43 includes a number of sub-modules to support the corresponding functionalities of the different layers described above. For example, the communications control module 43 will typically include 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 functionality.

　　The MBS management module 45 is responsible for the overall handling of MBS and signalling relating to MBS. The signalling may include, for example, signalling for configuring the UE 3 for receiving one or more MBS sessions via a shared RAN node 5 / shared base station 5.

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

　　As shown, the RAN node 5 includes a distributed unit 5b and a central unit 5c. Each

unit

5b, 5c includes

respective transceiver circuitry

51b, 51c. The distributed unit 5b transceiver circuitry 51b is operable to transmit signals to and to receive signals from one or more UEs 3 over the air interface via one or more antennas 53b (e.g. a single or multi-panel antenna array / massive antenna) and is also operable to transmit signals to and to receive signals from the central unit 5c via an interface, for example the distributed unit side of an F1 interface.

　　The central unit 5c transceiver circuitry 51c is operable to transmit signals to and to 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. comprising the N2, N3 and other reference points/interfaces) for communicating with one or more core networks 7-X, 7-Y, 7-Z and a RAN to RAN interface for communicating with other RAN nodes 5 (e.g. the so-called 'Xn' interface in NR). The central unit 5c transceiver circuitry 51c is also operable to transmit signals to and to receive signals from one or more distributed units 5b, for example the central unit side of the F1 interface.

　　Each

unit

5b, 5c includes a

respective controller

57b, 57c which controls the operation of the corresponding

transceiver circuitry

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 of each unit may be pre-installed in the

memory

59b, 59c and/or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

　　As shown, the software of 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. It will be appreciated that while the CU 5c and the DU 5b are each described as having corresponding units this may not be the case. For example, depending on the specific functionalities distributed between the CU 5c and the DU 5b any of these modules may only be present on one of the CU 5c and the DU 5b if the other unit does not contribute to that module's functions.

　　Each

communications control module

63b, 63c is operable to control the communication of its

corresponding unit

5b, 5c including the communication from one unit to the other. The communications control module 63b of the distributed unit 5b controls communication between the distributed unit 5b and the one or more UEs 3, and the communications control module 63c of the central unit 5c controls communication between the central unit 5c and other network entities that are connected to the distributed type of base station 5.

　　The

communications control modules

63b, 63c also respectively control the part played by the distributed unit 5b and central unit 5c in the communication between the base station 5 and one or more UEs 3 and other network entities that are connected to the RAN node 5.

　　Each

communications control module

63b, 63c is responsible, for example, for controlling the respective part played by the distributed unit 5b and central unit 5c in reception and decoding of uplink communications, via associated uplink channels (e.g. via 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 signalling (e.g., SRS). Each

communications control module

63b, 63c is also responsible, for example, for controlling the respective part played by the distributed unit 5b and central unit 5c in the overall handling of the transmission of downlink communications via associated downlink channels (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)). The downlink communication may include, for example, both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.), paging communications, dedicated (radio resource control (RRC)) communication, multicast communication (including on the MCCH and/or MTCH), broadcast communications and/or the like. Each

communications control module

63b, 63c is also responsible, for example, for controlling the respective part played by the distributed unit 5b and central unit 5c in the overall control handling of communications to and from different core networks 7-X, 7-Y, 7-Z that share the RAN node 5 including communications related to the setting up of user plane tunnels (e.g., GTP-U tunnels) for MBS services and other communications, paging requests from an AMF 10-1 etc. Each

communications control module

63b, 63c is also responsible, for example, for controlling the respective part played by the distributed unit 5b and central unit 5c in determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots/symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

　　It will be appreciated that the

communications control modules

63b, 63c may also include a number of sub-modules (or 'layers') to support specific functionalities for the

corresponding unit

5b, 5c. The modules included will depend on how the corresponding

unit

5b, 5c is configured (e.g., the precise CU-DU split). For example, the communications control module 63b of the distributed unit 5b may include a PHY sub-module, a MAC sub-module, and an RLC sub-module, whereas the communications control module 63c of the central unit 5c may include a PDCP sub-module, an IP sub-module, an RRC sub-module, etc.

　　Each

MBS management module

65b, 65c is responsible, for example, for controlling the respective part played by the distributed unit 5b and central unit 5c in the overall handling of MBS and signalling relating to MBS. The signalling may include signalling for configuring the UE 3 for receiving an MBS session via a shared RAN node 5 / shared base station 5, MBS related signalling from the core networks 7-X, 7-Y, 7-Z (e.g., from associated AMFs 10-1-X, 10-1-Y, 10-1-Z), and signalling for configuring other nodes for providing the MBS session via the shared RAN node 5 / shared base station 5.

　　It will be understood by a person 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 at a remote location, as a single physical element or as a cloud-based or virtualised system. It will also be understood that a single central unit 5c may serve multiple distributed units 5b and vice versa.

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

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

　　The RAN node 5 has a controller 57 to control 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 via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the RAN node 5 by, in this example, program instructions or software instructions stored within memory 59.

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

　　The communications control module 63 is operable to control the communication between the base station 5 and one or more UEs 3 and other network entities that are connected to the RAN node 5. The communications control module 63 is configured for the overall control of the reception and decoding of uplink communications, via associated uplink channels (e.g. via 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 signalling (e.g., SRS). The communications control module 63 is also configured for the overall handling of the transmission of downlink communications via associated downlink channels (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)). The downlink communication may include, for example, both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.), paging communications, dedicated (radio resource control (RRC)) communication, multicast communication (including on the MCCH and/or MTCH), broadcast communications and/or the like. The communications control module 63 is configured for the overall control handling of communications to and from different core networks 7-X, 7-Y, 7-Z that share the RAN node 5 including communications related to the setting up of user plane tunnels (e.g., GTP-U tunnels) for MBS services and other communications, paging requests from an AMF 10-1 etc. The communications control module 63 is also responsible, for example, for determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots/symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

　　It will be appreciated that the communications control module 63 includes a number of sub-modules to support the corresponding functionalities of the different layers described above. For example, the communications control module 63 will typically include 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 functionality. The MBS management module 65 is responsible for the overall handling of MBS and signalling relating to MBS. The signalling may include signalling for configuring the UE 3 for receiving an MBS session via a shared RAN node 5 / shared base station 5, MBS related signalling from the core networks 7-X, 7-Y, 7-Z (e.g., from associated AMFs 10-1-X, 10-1-Y, 10-1-Z), and signalling for configuring other nodes for providing the MBS session via the shared RAN node 5 / shared base station 5.

< Core network node >
　　Fig. 8 a schematic block diagram illustrating the main components of a core network node 7 which may be used in the communication system 1 shown in Fig. 1 (e.g. the AMF 10-1, the UPF 11, or the SMF 10-2).

　　As shown, the core network node 7 includes a transceiver circuit 71 which is operable to transmit signals to and to receive signals from other communication entities as appropriate 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, a core network node 7 configured as an AMF 10-1 may communicate with a UE 3 (e.g., via an N1 interface), the RAN node 5 (e.g., via an N2 interface), an SMF 10-2 (e.g., via an N11 interface), and/or other core network nodes 7 via other interfaces as appropriate. A core network node 7 configured as an SMF 10-2 may communicate with an AMF 10-1 (e.g., via an N11 interface), a UPF 11 (e.g., via an N4 interface), and other core network nodes 7 via other interfaces as appropriate.

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

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

　　If present, the MBS management module 85 (where present) is responsible for handling signalling relating to multimedia broadcast services (control signalling and/or MBS traffic). The signalling may comprise signalling relating to the provision of MBS sessions via a shared RAN node 5 / shared base station 5 (including paging requests, signalling for setting up user plane tunnels etc., where appropriate), and signalling for configuring other nodes for providing the MBS session via the shared RAN node 5 / shared base station 5.

< Multiple TMGIs configured at UE via RRC dedicated signalling (multicast) >
　　As mentioned above, in the communication system 1, for each UE 3 that may be interested in receiving an MBS service, the shared RAN node 5 is able to configure a list of PLMN specific TMGI's (i.e., a Native TMGI list) for that MBS service, to the UE 3. One possible way in which this may be achieved will now be described in more detail, by way of example only, with reference to Figs. 9 and 10.

　　Fig. 9 illustrates one way in which a list of TMGIs for an MBS service may be notified to a UE 3 in the communication system 1 of Fig. 1.

　　As seen at S910 in Fig. 9, in this example RRC dedicated signalling is used to configure the native TMGI list associated with a particular PTM configuration for a multicast MBS service to the UE 3. As seen in Fig. 9, in this example an information element (IE) of an RRC reconfiguration ('RRCReconfiguration') message is used to transfer the TMGI list to the UE 3. Specifically, an IE for informing the UE 3 of MBS radio bearers (MRBs) to add at the UE 3 is used ('MRB-ToAddMod').

　　It will be appreciated that the message illustrated in Fig. 9 is simplified for clarity and that, in reality, the data structure will be more complex. For example, although not shown in the simplified illustration of Fig. 9, the IE for informing the UE 3 of MBS radio bearers (MRBs) to add at the UE 3 may form part of a radio bearer configuration IE (e.g., 'RadioBearerConfig') that is included in the RRC reconfiguration message along with other information. The radio bearer configuration IE is used to add, modify, and release signalling, multicast MRBs and/or data radio bearers. Specifically, this IE carries the parameters for PDCP and, if applicable, Service Data Adaption Protocol (SDAP) entities for the radio bearers.

　　Accordingly, on receipt of the RRC reconfiguration ('RRCReconfiguration') message, if a TMGI (e.g. TMGI-X as allocated via the core network 7-X of a home operator) corresponding to a multicast service that the UE 3 is interested to receive, is within the TMGI list for the associated PTM configuration, the UE 3 is able to establish an MRB to receive that multicast service.

　　Fig. 10 is a simplified illustration of part 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 transferring the list of TMGIs as a sequence of TMGIs. It will be appreciated that the term used for identifying such an a TMGI list IE ('tmgi-list-multicast') is illustrative and different terminology may be used.

　　It will also be appreciated that other RRC messages may include the TMGI list (either as part of a radio bearer configuration IE or another IE). For example, an RRC resume message may include the radio bearer configuration IE incorporating the TMGI list.

　　Beneficially, therefore, each PTM configuration is associated with a TMGI list of the same MBS session, rather than each PTM configuration being associated with a single TMGI even if the PTM configuration is duplicated for multiple TMGIs.

　　In this manner, therefore, the network is able to configure a native TMGI list of the UE 3, rather than providing duplicated PTM configurations with different TMGIs to the UE 3.

< Multiple TMGIs configured at UE via MCCH (broadcast) >
　　As mentioned above, in the communication system 1, for each UE 3 that may be interested in receiving an MBS service, the shared RAN node 5 is able to configure a list of PLMN specific TMGI's (i.e., a Native TMGI list) for that MBS service, to the UE 3. Another possible way in which this may be achieved will now be described in more detail, by way of example only, with reference to Figs. 11 and 12.

　　Fig. 11 illustrates another way in which a list of TMGIs for an MBS service may be notified to a UE 3 in the communication system 1 of Fig. 1.

　　As seen at S1110 in Fig. 11, in this example a message is sent via the MBS control channel (MCCH) to configure the native TMGI list associated with a particular PTM configuration for an MBS broadcast service to the UE 3. As seen in Fig. 11, in this example an information element (IE) of an MBS broadcast configuration ('MBSBroadcastConfiguration') message is used to transfer the TMGI list to the UE 3. Specifically, an IE for providing MBS session information to the UE 3 is used ('MBSsessioninfo'). It will be understood, that such an MCCH message is an RRC message that may be sent from the network to the UE 3 on the MCCH logical channel.

　　It will be appreciated that the message illustrated in Fig. 11 is simplified for clarity and that, in reality, the data structure will be more complex. For example, although not shown in the simplified illustration of Fig. 11, the MBS broadcast configuration message contains control information applicable for MBS broadcast services transmitted via broadcast MRB. The MBS broadcast configuration information, provided on the MCCH logical channel, via the MBS broadcast configuration message indicates the MBS broadcast sessions that are provided in the cell as well as the corresponding scheduling related information for these sessions.

　　Fig. 12 is a simplified illustration of part of an abstract syntax notation one (ASN.1) definition of a data structure for an MBS broadcast configuration ('MBSBroadcastConfiguration') message incorporating MBS session information for transferring the list of TMGIs as a sequence of TMGIs. In this example the information is shown as being provided in a TMGI list ('TMGI-list-broadcast') IE comprising a list of MBS session information ('MBMS-SessionInfo') IEs. Here it will be understood that the MBS session information ('MBMS-SessionInfo') IEs each correspond to a single TMGI as shown in Fig. 3A and Fig. 3B. It will be appreciated that the term used for identifying such a TMGI list IE ('tmgi-list-broadcast') is illustrative and different terminology may be used.

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

< Native TMGI paging handling >
　　As mentioned above, when paging the UE 3 about 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 (form a TMGI list associated with the MBS service) in the paging message even if the shared RAN node 5 has received multiple paging requests from AMFs 10-1-X, 10-1-Y of different PLMNs/core networks 7-X, 7-Y. Associated panging procedures will now be described in more detail, by way of example only, with reference to Fig. 13A and Fig. 13B.

　　Fig. 13A and Fig. 13B show simplified message sequence diagrams for two different paging scenarios that may occur in the communication system 1 of Fig. 1.

　　It will be appreciated that in the example of Fig. 13A and Fig. 13B it is assumed that the UE 3 has stored the native TMGI list (as allocated by different PLMNs) corresponding to the same shared MBS service. This may, for example, be based on the received PTM configurations described with reference to Figs. 9 and 10 or Figs. 11 and 12. It will be appreciated, however, that the manner in which the TMGI list may be configured at the UE 3 is not essential in the procedure of Fig. 13A and Fig. 13B.

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

　　As seen at (a) in Fig. 13A and Fig. 13B, when the shared RAN node 5 receives a paging (or activation) request sent, at S1310a, from one AMF 10-1-X of a 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, the paging message over the air interface indicating that TMGI (e.g. TMGI1).

　　As seen at S1320a, after receiving the paging message including the TMGI (TMGI1) for PLMN1, a UE 3 associated with PLMN 2 can, nevertheless find the TMGI (TMGI1) sent in the paging message in the TMGI list stored at that UE 3 for the corresponding PTM configuration / MBS service, because the UE 3 previously stored that TMGI list in association with the PTM configuration for the MBS service. Accordingly, when the UE 3 finds the TMGI (TMGI1) sent in the paging message in the TMGI list it can enter a connected (RRC_CONNECTED) state as a response to the paging message.

　　It will nevertheless be appreciated that for a UE 3 associated with PLMN1, as PLMN1 allocated the TMGI (TMGI1) for the MBS service then, when the UE 3 of PLMN1 finds that TMGI in the paging message, it can go to the connected (RRC_CONNECTED) state as a response to the paging message to receive the MBS service without necessarily referring to the TMGI list.

　　As seen at (b) in Fig. 13A and Fig. 13B, when the shared RAN node 5 receives plural paging (or activation) requests sent, at S1310b-1 and S1310b-2, 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 indicating a different one of the TMGIs in the TMGI list (e.g. TMGI1 and TMGI2 respectively in the illustrated example), then the shared RAN node 5 can forward, at S1312b, the paging message over the air interface indicating only one of the TMGIs (e.g. TMGI1 or TMGI2).

　　As seen at S1320b, after receiving the paging message including the TMGI (TMGI1 or TMGI2), a UE 3 associated with PLMN 2 can, find that TMGI in the TMGI list stored at that UE 3 for the corresponding PTM configuration / MBS service even if it is a TMGI (e.g., TMGI1) for a different PLMN (e.g., PLMN1), because the UE 3 previously stored that TMGI list in association with the PTM configuration for the MBS service. Accordingly, when the UE 3 finds the TMGI sent in the paging message in the TMGI list it can enter a connected (RRC_CONNECTED) state as a response to the paging message.

　　It will nevertheless be appreciated that if the TMGI in the paging message is a TMGI (e.g., TMGI2) of a PLMN (e.g., PLMN2) that the UE 3 is associated with then, when the UE 3 of that PLMN (e.g., PLMN2) finds that TMGI in the paging message, it can go to the connected (RRC_CONNECTED) state as a response to the paging message to receive the MBS service without necessarily referring to the TMGI list.

< Establishment of user plane (NG-U/F1-U) tunnels - shared DU and CU / non-distributed RAN >
　　As mentioned above, the shared RAN node 5 can decide the number of (NG-U / F1-U) user plane tunnels to establish. Specifically, if there is already one NG-U tunnel (and F1-U tunnel for a distributed RAN) established between one of the core networks 7-X, 7-Y and the shared RAN node 5, the shared RAN node 5 may decide to share this NG-U tunnel (and 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 may decide that multiple NG-U/F1-U tunnels are to be established - e.g., one NG-U/F1-U tunnel for each MBS session for different PLMNs. Moreover, if the shared RAN node 5 decides to establish only one NG-U/F1-U tunnel with a first PLMN/core network 7-X then the shared RAN node 5 is able to notify an AMF 10-1-Y of a second PLMN/core network 7-Y that there is already an existing NG-U/F1-U tunnel with the TMGI allocated by the first core network 7-X (e.g., via a first AMF 10-1-X of the first PLMN/core network 7-X).

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

　　Fig. 14 is a simplified sequence diagram of a procedure for notifying a core network node 7 of the presence of an existing user plane tunnel.

　　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).

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

　　The tunnel establishment procedure also includes, in this example, the shared RAN node 5 sending, at S1412, to the first AMF 10-1-X, a broadcast session setup response message to complete the establishment procedure. The broadcast session setup response message includes the 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. an NG RAN GTP-U tunnel ID) and an associated IP address.

　　As seen at S1414, in step 2 of the procedure, the shared RAN node 5 decides which one or more other operators/AMFs 10-1 associated with one or more other PLMNs to notify about the existing user plane (NG-U) tunnel.

　　As seen at S1416, in step 3 of the procedure, the shared RAN node 5 (specifically the shared RAN's CU) sends a configuration update message to a second AMF 10-1-Y of a 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, for example, be a TMGI associated with the second PLMN (e.g., 'TMGI-X2'), an identifier (e.g., a service identifier as described earlier), a session ID (which need not be an MBS session ID as described earlier), or the like. The configuration update message also includes a (shared) MBS session ID, the 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 for notifying 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 (including a new message for the purpose).

　　As seen at S1418, in step 4 of the procedure, the second AMF 10-1-Y may decide to do one of the following:
　　still attempt to establish a new user plane (GTP-U) tunnel pair for the shared MBS service (i.e., for a one tunnel per MBS session per PLMN basis) in the following procedure;
　　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 the following procedure;
　　to reuse the existing GTP-U tunnel pair to serve the shared MBS service in the following procedure.

　　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 a one tunnel per MBS session per PLMN basis) then, in step 5a (as seen at S1420), the second AMF 10-1-Y will send at S1420, to the shared RAN node 5, a broadcast session setup request message including information for identifying the MBS service and/or MBS session to which the request relates. This information may, for example, be a TMGI associated with the second PLMN (e.g., 'TMGI-X2'), an identifier (e.g., a service identifier as described earlier), a session ID (which need not be an MBS session ID as described earlier), or the like. The broadcast session setup request message also includes, in this case, information for identifying a new user plane tunnel from a core network perspective (e.g. a 5GC GTP-U tunnel ID) and an associated IP address.

　　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 a one tunnel per MBS session per PLMN basis), then 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 including the newly established NG-RAN side (GTP-U) tunnel ID and IP address in step 5b (as seen for one option in S1422);
　　the shared RAN node 5 may send, in step 5b, a broadcast session setup response including an indication of successful session setup, a (shared) MBS session ID, the previously established GTP-U tunnel ID pair and IP address for the shared MBS service in step 5b (as seen for another option in S1422) - this response would mean that a new NG-RAN side GTP-U tunnel has not been established;
　　the shared RAN node 5 may send, in step 5b, a broadcast session setup response including an indication of successful session setup, a (shared) MBS session ID, but that does not include any NG-RAN side (GTP-U) tunnel ID and IP address for the shared MBS service - this response would also mean that a new NG-RAN side GTP-U tunnel has not been established;
　　the shared RAN node 5 may send, in step 5b, a broadcast session setup failure message indicating that for the shared MBS service new user plane (GTP-U) tunnel cannot be established by use of a new proper cause value (e.g., 'Existing NG-U tunnel of the same MBS service' or the like); or
　　the shared RAN node 5 may send in step 5b, a broadcast session setup response including an indication of successful session setup, but that does not include, the (shared) MBS session ID, the NG-RAN side tunnel ID and IP address for the shared MBS service - this response would also mean that a new NG-RAN side GTP-U tunnel has not been established.

　　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 5a (as seen at S1420), the second AMF 10-1-Y will send at S1420, to the shared RAN node 5, a broadcast session setup request message including information for identifying the MBS service and/or MBS session to which the request relates. This information may, for example, be a TMGI associated with the second PLMN (e.g., 'TMGI-X2'), an identifier (e.g., a service identifier as described earlier), a session ID (which need not be an MBS session ID as described earlier), or the like. The broadcast session setup request message also includes, in this case, information for identifying a new user plane tunnel from a core network perspective (e.g. a 5GC GTP-U tunnel ID) and an associated IP address. In this case, however, the broadcast session setup request message also includes an explicit indication to indicate the intention that a backup GTP-U tunnel pair is being established.

　　If the second AMF 10-1-Y decides 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 at 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 for one option in S1422).

　　If the second AMF 10-1-Y decides to reuse the existing GTP-U tunnel pair to serve the shared MBS service then the second AMF 10-1-Y may proceed, at step 5a, in one of the following ways:
　　send a broadcast session setup request message with no core network side user plane (GTU-U) tunnel information for the first AMF 10-1-X;
　　send a broadcast session setup request message with a (shared) MBS session ID, but no user plane (GTU-U) tunnel information;
　　send a broadcast session setup request message with the GTP-U tunnel ID pair and IP address for the existing user plane tunnel to show an explicit the intention for the existing tunnel to be reused (as seen in one option at S1420).

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

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

　　It will be appreciated that the shared RAN node 5 may also reject the request from the second AMF 10-1-Y, with a proper new cause value to indicate the second AMF 10-1-Y to reuse the same user plane (GTP-U) tunnel pair as previously indicated by the shared RAN node 5 (e.g., if that tunnel pair has already been torn down).

　　It will be appreciated that while the procedure of Fig. 14 has been described in the context of setting up of a broadcast session, the same principles apply in respect of setting up a multicast session and a similar procedure could be used.

< Establishment of user plane (NG-U/F1-U) tunnels - shared DU / unshared CU >
　　As mentioned above, the shared RAN node 5 can decide the number of (NG-U / F1-U) user plane tunnels to establish. Specifically, if there is already one NG-U tunnel (and F1-U tunnel for a distributed RAN) established between one of the core networks 7-X, 7-Y and the shared RAN node 5, the shared RAN node 5 may decide to share this NG-U tunnel (and 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 may decide that multiple NG-U/F1-U tunnels are to be established - e.g., one NG-U/F1-U tunnel for each MBS session for different PLMNs. Moreover, if the shared RAN node 5 decides to establish only one NG-U/F1-U tunnel with a first PLMN/core network 7-X, then the shared RAN node 5 is able to notify an AMF 10-1-Y of a second PLMN/core network 7-Y that there is already an existing NG-U/F1-U tunnel with the TMGI allocated by the first core network 7-X (e.g., via a first AMF 10-1-X of the first PLMN/core network 7-X).

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

　　Fig. 15 is a simplified sequence diagram of another procedure for notifying a core network node 7 of the presence of an existing user plane tunnel.

　　As seen at S1510 and S1512, in step 1 of the procedure, a first (unshared) CU 5c-X of the shared RAN node 5 (that is 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).

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

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

　　The tunnel establishment procedure also includes, in this example, the first CU 5c-X sending, at S1512, to the first AMF 10-1-X, a broadcast session setup response message to complete the establishment procedure. The broadcast session setup response message includes the 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. an NG RAN GTP-U tunnel ID) and an associated IP address.

　　As seen at S1514, in step 2 of the procedure, the shared DU 5b decides which one or more other operators/CUs 5c associated with one or more other PLMNs to notify about the existing user plane (NG-U) tunnel.

　　As seen at 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 (unshared) CU 5c-Y of the shared RAN node 5 that is associated with a 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, for example, be a TMGI associated with the second PLMN (e.g., 'TMGI-X2'), an identifier (e.g., a service identifier as described earlier), a session ID (which need not be an MBS session ID as described earlier), or the like. The configuration update message also includes a (shared) MBS session ID, the pair of user plane tunnel identifiers (e.g. a 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 be any suitable message for notifying the second CU 5c-Y that an F1-U user plane tunnel pair has already been established with another CU 5c-X (including a new message specifically for the purpose).

　　As seen at S1516b, in step 3b of the procedure, the second CU 5c-Y sends a configuration update message to a second AMF 10-1-Y of the second PLMN. The configuration update message includes, in this example, the information for identifying the MBS service and/or MBS session to which the request relates. This information may, for example, be a TMGI associated with the second PLMN (e.g., 'TMGI-X2'), an identifier (e.g., a service identifier as described earlier), a session ID (which need not be an MBS session ID as described earlier), or the like. The configuration update message also includes the (shared) MBS session ID, the pair of user plane tunnel identifiers (e.g. the 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 notifying the second AMF 10-1-Y that an F1-U user plane tunnel pair has already been established with another CU 5c-X.

　　As seen at S1518, in step 4 of the procedure, the second AMF 10-1-Y may decide to do one of the following:
　　still attempt to establish a new user plane tunnel pair over the F1-U interface for the shared MBS service (i.e., for a one tunnel per MBS session per PLMN basis) in the following procedure;
　　attempt to establish a new user plane tunnel pair over the F1-U interface to provide a backup user plane tunnel over the F1-U for the shared MBS service in the following procedure; and
　　to reuse the existing tunnel pair over the F1-U interface to serve the shared MBS service in the following procedure.

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

　　If the second AMF 10-1-Y decides to attempt to establish a new user plane tunnel pair over the F1-U interface for the shared MBS service (i.e., for a one tunnel per MBS session per PLMN basis) then the second CU 5c-Y may respond in one of the following ways:
　　the second CU 5c-Y may proceed by establishing the new tunnel including establishment of a new F1-U tunnel with the shared DU 5b (as seen for one option in S1521), and sending, in step 5b, a broadcast session setup response including the newly established NG-RAN side (GTP-U) tunnel ID and IP address (as seen for one option in S1522);
　　the second CU 5c-Y may proceed by establishing the broadcast using the existing F1-U tunnel (as seen for one option in S1521), and sending, in step 5b, a broadcast session setup response including an indication of successful session setup, a (shared) MBS session ID, the previously established F1-U tunnel ID pair and IP address for the shared MBS service (as seen for another option in S1522) - this response would mean that a new F1-U tunnel has not been established;
　　the second CU 5c-Y may proceed by establishing the broadcast using the existing F1-U tunnel (as seen for one option in S1521), and sending, in step 5b, a broadcast session setup response including an indication of successful session setup, a (shared) MBS session ID, but that does not include any NG-RAN side (GTP-U) tunnel ID and IP address for the shared MBS service - this response would also mean that a new F1-U tunnel has not been established;
　　the second CU 5c-Y may proceed by establishing the broadcast using the existing F1-U tunnel (as seen for one option in S1521), and sending, in step 5b, a broadcast session setup failure message, indicating that for the shared MBS service new user plane (GTP-U) tunnel cannot be established by use of a new proper cause value (e.g., 'Existing F1-U tunnel of the same MBS service' or the like); or
　　the second CU 5c-Y may proceed by establishing the broadcast using the existing F1-U tunnel (as seen for one option in S1521), and sending, in step 5b, a broadcast session setup response including an indication of successful session setup, but that does not include, the (shared) MBS session ID, the NG-RAN side tunnel ID and IP address for the shared MBS service - this response would also mean that a new F1-U tunnel has not been established.

　　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 5a (as seen at S1520), the second AMF 10-1-Y will send at S1520, to the second CU 5c-Y, a broadcast session setup request message including information for identifying the MBS service and/or MBS session to which the request relates. This information may, for example, be a TMGI associated with the second PLMN (e.g., 'TMGI-X2'), an identifier (e.g., a service identifier as described earlier), a session ID (which need not be an MBS session ID as described earlier), or the like. The broadcast session setup request message also includes, in this case, information for identifying a new user plane tunnel from a core network perspective (e.g. a 5GC GTP-U tunnel ID) and an associated IP address. In this case, however, the broadcast session setup request message also includes an explicit indication to indicate the intention that a backup GTP-U tunnel pair is being established.

　　If the second AMF 10-1-Y decides 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 the second CU 5c-Y may respond by establishing the new tunnel including establishment of a new F1-U tunnel with the shared DU 5b (as seen for one option in S1521), and sending, in step 5b, a broadcast session setup response including the newly established NG-RAN side (GTP-U) tunnel ID and IP address (as seen for one option in S1522).

　　If the second AMF 10-1-Y decides to reuse the existing GTP-U tunnel pair to serve the shared MBS service then the second AMF 10-1-Y may proceed, at step 5a, in one of the following ways:
　　send a broadcast session setup request message with no user plane (F1-U) tunnel information;
　　send a broadcast session setup request message with a (shared) MBS session ID, but no user plane (F1-U) tunnel information; and
　　send 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 show an explicit the intention for the existing tunnel to be reused (as seen in one option at S1520).

　　It will also be appreciated that the second AMF 10-1-Y can indicate an intention to reuse an existing user plane (F1-U) tunnel pair by means of another explicit indicator.

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

　　It will be appreciated that the second CU 5c-Y may also reject the request from the second AMF 10-1-Y, with a proper new cause value to indicate the second AMF 10-1-Y to reuse the same user plane (F1-U) tunnel pair as previously indicated by the second CU 5c-Y (e.g., if that tunnel pair has already been torn down).

　　It will also be appreciated that while the procedure of Fig. 15 has been described in the context of setting up of a broadcast session, the same principles apply in respect of setting up a multicast session and a similar procedure could be used.

< Modifications and Alternatives >
　　Detailed example embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above example embodiments whilst still benefiting from the disclosures embodied therein.

　　For example, it will be appreciated that, whilst the new and beneficial features of the devices of the communication system have been described, in particular, with reference to 5G / NR communication technology, the beneficial features may be implemented in the devices of a communication system that uses other communication technologies such as, for example, other communication technologies developed as part of the 3GPP. For example, whilst the base station and UEs have been described as a 5G base station (gNB) and corresponding UEs it will be appreciated that the features described above may be applied to the RAN nodes (eNBs) and UEs that implement LTE/LTE-Advanced communication technology, or RAN nodes and UEs that implement other communications technologies developed using 3GPP derived communication technologies.

　　In the above description, the UEs and the base station are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosure, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

　　In the above example embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the base station, to the mobility management entity, or to the UE as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the base station or the UE in order to update their functionalities.

　　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) circuits; internal memories / caches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and/or timers; and/or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

　　The User Equipment (or "UE", "mobile station", "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

　　It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

　　The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for a long period of time.

　　A UE may, for example, be an item of equipment for production or manufacture and/or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and/or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and/or their application systems; tools; molds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and/or related machinery; paper converting machinery; chemical machinery; mining and/or construction machinery and/or related equipment; machinery and/or implements for agriculture, forestry and/or fisheries; safety and/or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and/or application systems for any of the previously mentioned equipment or machinery etc.).

　　A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).

　　A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

　　A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and/or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

　　A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

　　A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and/or system, a weapon, an item of cutlery, a hand tool, or the like.

　　A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

　　A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)", using a variety of wired and/or wireless communication technologies.

　　Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and/or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and/or inactive for a long period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored/tracked.

　　It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communication system for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

　　It will be appreciated that IoT devices are sometimes also 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 in the following table 1. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

Table 1: Some examples of MTC applications

　　Applications, services, and solutions may be an MVNO (Mobile Virtual Network Operator) service, an emergency radio communication system, a PBX (Private Branch eXchange) system, a PHS/Digital Cordless Telecommunications system, a POS (Point of sale) system, an advertise calling system, an MBMS (Multimedia Broadcast and Multicast Service), a V2X (Vehicle to Everything) system, a train radio system, a location related service, a Disaster/Emergency Wireless Communication Service, a community service, a video streaming service, a femto cell application service, a VoLTE (Voice over LTE) service, a charging service, a radio on demand service, a roaming service, an activity monitoring service, a telecom carrier/communication NW selection service, a functional restriction service, a PoC (Proof of Concept) service, a personal information management service, an ad-hoc network/DTN (Delay Tolerant Networking) service, etc.

　　Further, the above-described UE categories are merely examples of applications of the technical ideas and example embodiments described in the present document. Needless to say, these technical ideas and example embodiments are not limited to the above-described UE and various modifications can be made thereto.

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

　　This application is based upon and claims the benefit of priority from UK patent application No. 2302230.4, filed on February 16, 2023, the disclosure of which is incorporated herein in its entirety by reference.

< Supplementary notes >
　　The whole or part of the example Aspects disclosed above can be described as, but not limited to, the following supplementary notes.

(Supplementary note 1)
　　A method performed by an access network node, the method comprising:
　　receiving, from a second communication node of a second network of a plurality of networks that share the access network node, a request for setup for a multicast or broadcast service identified by a second identifier f or a multicast and broadcast service (MBS) session; and
　　determining whether a resource 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 a value of the second identifier,
　　wherein the at least one MBS session being requested from a first network of the plurality of networks that share the access network node, using the first identifier.

(Supplementary note 2)
　　The method according to supplementary note 1, further comprising:
　　establishing, with the first communication node of the first network a first user plane tunnel for the multicast or broadcast service identified by the first identifier; and
　　transmitting, to the second communication node, information for indicating 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, wherein the second identifier indicates the multicast or broadcast service.

(Supplementary note 3)
　　The method according to

supplementary note

1 or 2, wherein
　　the receiving the request includes receiving a request for setup of a second user plane tunnel for the multicast or broadcast service as a new tunnel, after the transmitting the information; and
　　the method comprises transmitting, to the second communication node, a message indicating the second user plane tunnel is not established.

(Supplementary note 4)
　　The method according to supplementary note 3, wherein
　　the message includes a session setup message, and
　　the message does not include a tunnel identifier and an Internet Protocol (IP) address for the second user plane tunnel.

(Supplementary note 5)
　　The method according to supplementary note 3 or 4, wherein
　　the message includes a tunnel identifier and an IP address for the first user plane tunnel.

(Supplementary note 6)
　　The method according to any one of supplementary notes 3 to 5, wherein
　　the message includes a session identifier of the MBS session, and
　　the session identifier includes the first identifier.

(Supplementary note 7)
　　The method according to supplementary note 3, wherein
　　the message includes a session setup failure message, and
　　the message includes a cause value indicating the second user plane tunnel cannot be not established.

(Supplementary note 8)
　　The method according to

supplementary note

1 or 2, wherein
　　the receiving the request includes receiving a request for setup of the second user plane tunnel for the multicast or broadcast service as a backup for the first user plane tunnel; and
　　the method comprises transmitting, to the second communication node, a message indicating the second user plane tunnel is established as the backup for the first user plane tunnel.

(Supplementary note 9)
　　The method according to supplementary note 8, wherein
　　the request includes an indication that the second communication node intends to establish the second user plane tunnel as the backup the first user plane tunnel.

(Supplementary note 10)
　　The method according to supplementary note 8 or 9, wherein
　　the message includes a tunnel identifier and an Internet Protocol (IP) address for the second user plane tunnel.

(Supplementary note 11)
　　The method according to supplementary note 2, wherein
　　the receiving the request includes receiving, from the second communication node, an indication to reuse, by the second communication node, the first user plane tunnel to serve the multicast or broadcast service; and
　　the method comprises configuring the first user plane tunnel to reuse, by the second communication node, the first user plane tunnel to serve the multicast or broadcast service.

(Supplementary note 12)
　　The method according to supplementary note 11, wherein
　　the information includes a tunnel identifier and an Internet Protocol (IP) address for the first user plane tunnel, and a session identifier of the MBS session, the session identifier including the first identifier, and
　　the indication includes at least one of:
　　　　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.

(Supplementary note 13)
　　The method according to supplementary note 11 or 12, further comprising:
　　transmitting, in a case where the first user plane tunnel is no longer established, a reject message including a cause value indicating the request has been rejected.

(Supplementary note 14)
　　The method according to supplementary note 2, wherein
　　the receiving the request includes receiving a request for setup of the second user plane tunnel for the multicast or broadcast service as a new tunnel, before the transmitting the information; and
　　the method comprises transmitting, to the second communication node, a reject message for rejecting the request.

(Supplementary note 15)
　　The method according to any one of supplementary notes 2 to 14, wherein
　　the information indicates that the request for setting up a new tunnel for the multicast or broadcast service is not allowed.

(Supplementary note 16)
　　The method according to any one of supplementary notes 1 to 15, wherein
　　the access network node comprises a central unit (CU) of a distributed access network.

(Supplementary note 17)
　　The method according to any one of supplementary notes 1 to 16, wherein
　　the first communication node comprises a first core network node of the first network, and
　　the second communication node comprises a second core network node of the second network.

(Supplementary note 18)
　　The method according to

supplementary note

5, 10 or 12, wherein
　　the tunnel identifier identifies a tunnel over an interface between the access network node and a core network node for providing a user plane function.

(Supplementary note 19)
　　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.

(Supplementary note 20)
　　The method according to supplementary note 19, wherein
　　the first communication node comprises a first central unit (CU) of the distributed access network, and
　　the second communication node comprises a second CU of the distributed access network.

(Supplementary note 21)
　　The method according to

supplementary note

5, 10 or 12, wherein
　　the tunnel identifier identifies a tunnel over an interface between the access network node and a central unit (CU) of a distributed access network.

(Supplementary note 22)
　　The method according to any one of supplementary notes 1 to 21, wherein
　　each of the first identifier and the second identifier comprises:
　　　　an Internet Protocol (IP) address corresponding to the multicast or broadcast service, or
　　　　a respective temporary mobile group identifier (TMGI).

(Supplementary note 23)
　　A method performed by a second communication node, the method comprising:
　　receiving, from an access network node, information for 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 for the multicast or broadcast service,
　　wherein the first user plane tunnel has been established by a first communication node of a first network of a plurality of networks that share 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 that share the access network node.

(Supplementary note 24)
　　A method performed by a user equipment (UE), the method comprising:
　　receiving, form 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) sessions, 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 that share the access network node; and
　　using an identifier of the plurality of different identifiers for initiating an establishment a MBS session to receive the multicast or broadcast service, wherein the identifier corresponds to a network which the UE belongs to.

(Supplementary note 25)
　　The method according to supplementary note 24, further comprising:
　　receiving, from the access network node, a message including an identifier including:
　　　　information indicating a multicast or broadcast service which is available, and
　　　　information a first network of the plurality of the networks;
　　determining whether the identifier for MBS session included in the message is one of the plurality of different identifiers for MBS sessions; and
　　in a case where the identifier for the MBS session included in the message is the one of the plurality of different identifiers for MBS sessions, communicating with a first access network node corresponding to the first network to receive the multicast or broadcast service which is available.

(Supplementary note 26)
　　The method according to supplementary note 24 or 25, wherein
　　the configuration information includes single point-to-multipoint configuration information.

(Supplementary note 27)
　　The method according to any one of supplementary notes 24 to 26, wherein
　　the each identifier of the plurality of different identifiers comprises:
　　　　an Internet Protocol (IP) address corresponding to the multicast or broadcast service, or
　　　　a respective temporary mobile group identifier (TMGI).

(Supplementary note 28)
　　The method according to any one of supplementary notes 24 to 27, wherein
　　the first information is included in at least one of:
　　　　information for configuring a radio bearer,
　　　　information for adding at least one multicast and broadcast services (MBS) bearer,
　　　　dedicated signalling,
　　　　an MBS control channel (MCCH),
　　　　MBS configuration information, or
　　　　a radio resource configuration (RRC) message.

(Supplementary note 29)
　　The method according to supplementary note 25, wherein
　　the message includes a paging message.

(Supplementary note 30)
　　The method according to supplementary note 29, wherein
　　the UE and the access network node are configured for communication in a second network which is different from the first network.

(Supplementary note 31)
　　The method according to supplementary note 29, wherein
　　the UE and the access network node are configured for communication in the first network.

(Supplementary note 32)
　　The method according to any one of supplementary notes 29 to 31, 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 multicast or broadcast service which is available.

(Supplementary note 33)
　　A method performed by an access network node, the method 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) sessions, 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 that share the access network node; and
　　receiving, from the UE, information for establishing a MBS session to receive, by the UE, the multicast or broadcast service by using, by the UE, an identifier of the plurality of different identifiers, wherein the identifier corresponds to a network which the UE belongs to.

(Supplementary note 34)
　　The method performed according to supplementary note 33, further comprising:
　　transmitting, to the UE, a message including an identifier including:
　　　　information indicating a multicast or broadcast service which is available, and
　　　　information a first network of the plurality of the networks; and
　　in a case where the identifier for the MBS session included in the message is one of the plurality of different identifiers for MBS sessions, communicating with the UE to receive, by the UE, the multicast or broadcast service which is available.

(Supplementary note 35)
　　An access network node comprising:
　　means for receiving, from a second communication node of a second network of a plurality of networks that share the access network node, a request for setup for a multicast or broadcast service identified by a second identifier for a multicast and broadcast service (MBS) session; and
　　means for determining whether a resource 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 a value of the second identifier,
　　wherein the at least one MBS session being requested from a first network of the plurality of networks that share the access network node, using the first identifier.

(Supplementary note 36)
　　A second communication node comprising:
　　means for receiving, from an access network node, information for 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 for the multicast or broadcast service,
　　wherein the first user plane tunnel has been established by a first communication node of a first network of a plurality of networks that share 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 that share the access network node.

(Supplementary note 37)
　　A user equipment (UE) comprising:
　　means for receiving, form 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) sessions, 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 that share the access network node; and
　　means for using an identifier of the plurality of different identifiers for initiating an establishment a MBS session to receive the multicast or broadcast service, wherein the identifier corresponds to a network which the UE belongs to.

(Supplementary note 38)
　　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) sessions, 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 that share the access network node; and
　　means for receiving, from the UE, information for establishing a MBS session to receive, by the UE, the multicast or broadcast service by using, by the UE, an identifier of the plurality of different identifiers, wherein the identifier corresponds to a network which the UE belongs to.

1 communication system
3 UE
5 RAN node, base station
5b distributed unit
5c central unit
7 core network, core network node
9 cell
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 system
61b DU operating system
61c CU operating system
43, 63, 83 communications control module
63b DU communications control module
63c CU communications control module
45, 65, 85 MBS management module
65b MBS management module (DU PART)
65c MBS management module (CU PART)

Claims

　　A method performed by an access network node, the method comprising:
　　receiving, from a second communication node of a second network of a plurality of networks that share the access network node, a request for setup for a multicast or broadcast service identified by a second identifier f or a multicast and broadcast service (MBS) session; and
　　determining whether a resource 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 a value of the second identifier,
　　wherein the at least one MBS session being requested from a first network of the plurality of networks that share the access network node, using the first identifier.
　　The method according to claim 1, further comprising:
　　establishing, with the first communication node of the first network a first user plane tunnel for the multicast or broadcast service identified by the first identifier; and
　　transmitting, to the second communication node, information for indicating 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, wherein the second identifier indicates the multicast or broadcast service.
　　The method according to claim 1 or 2, wherein
　　the receiving the request includes receiving a request for setup of a second user plane tunnel for the multicast or broadcast service as a new tunnel, after the transmitting the information; and
　　the method comprises transmitting, to the second communication node, a message indicating the second user plane tunnel is not established.
　　The method according to claim 3, wherein
　　the message includes a session setup message, and
　　the message does not include a tunnel identifier and an Internet Protocol (IP) address for the second user plane tunnel.
　　The method according to claim 3 or 4, wherein
　　the message includes a tunnel identifier and an IP address for the first user plane tunnel.
　　The method according to any one of claims 3 to 5, wherein
　　the message includes a session identifier of the MBS session, and
　　the session identifier includes the first identifier.
　　The method according to claim 3, wherein
　　the message includes a session setup failure message, and
　　the message includes a cause value indicating the second user plane tunnel cannot be not established.
　　The method according to claim 1 or 2, wherein
　　the receiving the request includes receiving a request for setup of the second user plane tunnel for the multicast or broadcast service as a backup for the first user plane tunnel; and
　　the method comprises transmitting, to the second communication node, a message indicating the second user plane tunnel is established as the backup for the first user plane tunnel.
　　The method according to claim 8, wherein
　　the request includes an indication that the second communication node intends to establish the second user plane tunnel as the backup the first user plane tunnel.
　　The method according to claim 8 or 9, wherein
　　the message includes a tunnel identifier and an Internet Protocol (IP) address for the second user plane tunnel.
　　The method according to claim 2, wherein
　　the receiving the request includes receiving, from the second communication node, an indication to reuse, by the second communication node, the first user plane tunnel to serve the multicast or broadcast service; and
　　the method comprises configuring the first user plane tunnel to reuse, by the second communication node, the first user plane tunnel to serve the multicast or broadcast service.
　　The method according to claim 11, wherein
　　the information includes a tunnel identifier and an Internet Protocol (IP) address for the first user plane tunnel, and a session identifier of the MBS session, the session identifier including the first identifier, and
　　the indication includes at least one of:
　　　　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.
　　The method according to claim 11 or 12, further comprising:
　　transmitting, in a case where the first user plane tunnel is no longer established, a reject message including a cause value indicating the request has been rejected.
　　The method according to claim 2, wherein
　　the receiving the request includes receiving a request for setup of the second user plane tunnel for the multicast or broadcast service as a new tunnel, before the transmitting the information; and
　　the method comprises transmitting, to the second communication node, a reject message for rejecting the request.
　　The method according to any one of claims 2 to 14, wherein
　　the information indicates that the request for setting up a new tunnel for the multicast or broadcast service is not allowed.
　　The method according to any one of claims 1 to 15, wherein
　　the access network node comprises a central unit (CU) of a distributed access network.
　　The method according to any one of claims 1 to 16, wherein
　　the first communication node comprises a first core network node of the first network, and
　　the second communication node comprises a second core network node of the second network.
　　The method according to claim 5, 10 or 12, wherein
　　the tunnel identifier identifies a tunnel over an interface between the access network node and a core network node for providing a user plane function.
　　The method according to any one of claims 1 to 15, wherein
　　the access network node comprises a distributed unit (DU) of a distributed access network.
　　The method according to claim 19, wherein
　　the first communication node comprises a first central unit (CU) of the distributed access network, and
　　the second communication node comprises a second CU of the distributed access network.
　　The method according to claim 5, 10 or 12, wherein
　　the tunnel identifier identifies a tunnel over an interface between the access network node and a central unit (CU) of a distributed access network.
　　The method according to any one of claims 1 to 21, wherein
　　each of the first identifier and the second identifier comprises:
　　　　an Internet Protocol (IP) address corresponding to the multicast or broadcast service, or
　　　　a respective temporary mobile group identifier (TMGI).
　　A method performed by a second communication node, the method comprising:
　　receiving, from an access network node, information for 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 for the multicast or broadcast service,
　　wherein the first user plane tunnel has been established by a first communication node of a first network of a plurality of networks that share 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 that share the access network node.
　　A method performed by a user equipment (UE), the method comprising:
　　receiving, form 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) sessions, 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 that share the access network node; and
　　using an identifier of the plurality of different identifiers for initiating an establishment a MBS session to receive the multicast or broadcast service, wherein the identifier corresponds to a network which the UE belongs to.
　　The method according to claim 24, further comprising:
　　receiving, from the access network node, a message including an identifier including:
　　　　information indicating a multicast or broadcast service which is available, and
　　　　information a first network of the plurality of the networks;
　　determining whether the identifier for MBS session included in the message is one of the plurality of different identifiers for MBS sessions; and
　　in a case where the identifier for the MBS session included in the message is the one of the plurality of different identifiers for MBS sessions, communicating with a first access network node corresponding to the first network to receive the multicast or broadcast service which is available.
　　The method according to claim 24 or 25, wherein
　　the configuration information includes single point-to-multipoint configuration information.
　　The method according to any one of claims 24 to 26, wherein
　　the each identifier of the plurality of different identifiers comprises:
　　　　an Internet Protocol (IP) address corresponding to the multicast or broadcast service, or
　　　　a respective temporary mobile group identifier (TMGI).
　　The method according to any one of claims 24 to 27, wherein
　　the first information is included in at least one of:
　　　　information for configuring a radio bearer,
　　　　information for adding at least one multicast and broadcast services (MBS) bearer,
　　　　dedicated signalling,
　　　　an MBS control channel (MCCH),
　　　　MBS configuration information, or
　　　　a radio resource configuration (RRC) message.
　　The method according to claim 25, wherein
　　the message includes a paging message.
　　The method according to claim 29, wherein
　　the UE and the access network node are configured for communication in a second network which is different from the first network.
　　The method according to claim 29, wherein
　　the UE and the access network node are configured for communication in the first network.
　　The method according to any one of claims 29 to 31, 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 multicast or broadcast service which is available.
　　A method performed by an access network node, the method 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) sessions, 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 that share the access network node; and
　　receiving, from the UE, information for establishing a MBS session to receive, by the UE, the multicast or broadcast service by using, by the UE, an identifier of the plurality of different identifiers, wherein the identifier corresponds to a network which the UE belongs to.
　　The method performed according to claim 33, further comprising:
　　transmitting, to the UE, a message including an identifier including:
　　　　information indicating a multicast or broadcast service which is available, and
　　　　information a first network of the plurality of the networks; and
　　in a case where the identifier for the MBS session included in the message is one of the plurality of different identifiers for MBS sessions, communicating with the UE to receive, by the UE, the multicast or broadcast service which is available.
　　An access network node comprising:
　　means for receiving, from a second communication node of a second network of a plurality of networks that share the access network node, a request for setup for a multicast or broadcast service identified by a second identifier for a multicast and broadcast service (MBS) session; and
　　means for determining whether a resource 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 a value of the second identifier,
　　wherein the at least one MBS session being requested from a first network of the plurality of networks that share the access network node, using the first identifier.
　　A second communication node comprising:
　　means for receiving, from an access network node, information for 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 for the multicast or broadcast service,
　　wherein the first user plane tunnel has been established by a first communication node of a first network of a plurality of networks that share 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 that share the access network node.
　　A user equipment (UE) comprising:
　　means for receiving, form 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) sessions, 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 that share the access network node; and
　　means for using an identifier of the plurality of different identifiers for initiating an establishment a MBS session to receive the multicast or broadcast service, wherein the identifier corresponds to a network which the UE belongs to.
　　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) sessions, 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 that share the access network node; and
　　means for receiving, from the UE, information for establishing a MBS session to receive, by the UE, the multicast or broadcast service by using, by the UE, an identifier of the plurality of different identifiers, wherein the identifier corresponds to a network which the UE belongs to.