Patent Description:
The 3rd Generation Partnership Project (3GPP) is currently working on introducing support for <NUM> MBS (5MBS).

The documents "<NPL>) are related to support for MBS.

In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or UEs, communicate via a Wide Area Network or a Local Area Network such as a Wi-Fi network or a cellular network comprising a Radio Access Network (RAN) part and a Core Network (CN) part. The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each service area or cell area being served by a radio network node such as a radio access node e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a NodeB, eNodeB (eNB), or gNB as denoted in Fifth Generation (<NUM>) telecommunications. A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the wireless device within range of the radio network node.

3GPP is the standardization body for specify the standards for the cellular system evolution, e.g., including <NUM>, <NUM>, <NUM> and the future evolutions. Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (<NUM>) network, have been completed within the 3rd Generation Partnership Project (3GPP). As a continued network evolution, the new releases of 3GPP specifies a <NUM> network also referred to as <NUM> New Radio (NR).

Multi-antenna techniques can significantly increase the data rates and reliability of a wireless communication system. The performance is in particular improved if both the transmitter and the receiver are equipped with multiple antennas, which results in a Multiple-Input Multiple-Output (MIMO) communication channel. Such systems and/or related techniques are commonly referred to as MIMO.

In addition to faster peak Internet connection speeds, <NUM> planning aims at higher capacity than current <NUM>, allowing higher number of mobile broadband users per area unit, and allowing consumption of higher or unlimited data quantities in gigabyte per month and user. This would make it feasible for a large portion of the population to stream high-definition media many hours per day with their mobile devices, when out of reach of Wi-Fi hotspots. <NUM> research and development also aims at improved support of machine to machine communication, also known as the Internet of things, aiming at lower cost, lower battery consumption and lower latency than <NUM> equipment.

Certain challenges presently exist. For instance, a scalability aspect appears if MBS Session resources, e.g., Packet Data Unit (PDU) Session resources, at a non-MBS supporting <NUM> base station, denoted "gNB", have to be established for UEs that are currently not in the RRC_CONNECTED state. Also, if the registration area of UEs spans supporting and non-supporting gNBs, then the effort in terms of paging resources is evident - especially for large Multicast (MC) groups.

The solution is specified by the independent claims.

An advantage of the embodiments is that they provide a scalable paging solution for MBS in non-MBS supporting RAN, e.g., NG-RAN, since the UE is required to monitor for paging occasions and to react on paging for a group ID provided to the UE. The group ID is allocated by a core network function for the MBS session. The UE determines whether a received paging message comprises the group ID.

<FIG> illustrates a system <NUM> according to an embodiment. When a UE, e.g., a UE <NUM>, moves from a RAN node that supports 5MBS to a RAN node that does not support 5MBS, the network and the UE <NUM> shall support switch from 5GC Shared MBS traffic delivery method to 5GC Individual MBS traffic delivery method, e.g., unicast delivery. As noted above, however, a scalability aspect appears if MBS Session resources, e.g., PDU Session resources, at a non-MBS gNB have to be established for UEs that are currently not in the RRC_CONNECTED state. Also, if the registration area of UEs spans supporting and non-supporting gNBs, then the effort in terms of paging resources is evident - especially for large MC groups.

Accordingly, in one embodiment, this disclosure provides that the UE <NUM> is required to monitor for paging occasions and react on paging for a group ID, e.g., "group <NUM>-S-Temporary Mobile Subscriber Identity (TMSI)", allocated by a core network function, e.g., an MB-SMF <NUM>, an AMF <NUM>, an SMF <NUM>, for the MBS session and provided via NAS to the UE at MBS Session joining procedure.

<FIG> is a message flow diagram illustrating a process according to an embodiment, which is described below.

In the example described above, the MB-SMF <NUM> allocates the group ID associated with the MBS Session and this group ID is sent to the UE <NUM> in NAS during joining. The UE <NUM> may use the group ID to monitor for paging occasions and react on paging for the group ID when camping on a non-MBS supporting NG-RAN, e.g., RAN node <NUM>, after it joined an MBS Session. MBS supporting RAN nodes may use this group ID as well. In another embodiments, the group ID can be allocated by the SMF <NUM> or the AMF <NUM>. To avoid collisions due to re-use of same <NUM>-S-TMSI for different UEs or MBS Sessions, the involved entities can be configured with <NUM>-S-TMSI ranges being reserved.

The AMF <NUM> may also forward the MBS Session Start information to the MBS supporting RAN nodes within the MBS Session Setup Request message to allocated shared MBS resources. UEs in the MBS Supporting RAN in RRC_INACTIVE are paged via RAN paging with the same group ID, e.g., Group-<NUM>-S-TMSI or another associated paging identifier. When the UEs of the multicast group are in RRC_CONNECTED they are configured with the shared MBS resources.

<FIG> is a block diagram of a network node QQ100, according to some embodiments, that can be used to implement any one of the core network functions described herein, e.g., MB-SMF <NUM>, AMF <NUM>, SMF <NUM>. As shown in <FIG>, network node Q100 may comprise: processing circuitry (PC) QQ102, which may include one or more processors (P) QQ155, e.g., one or more general purpose microprocessors and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like, which processors may be co-located in a single housing or in a single data center or may be geographically distributed, i.e., network node QQ100 may be a distributed computing apparatus; at least one network interface QQ148, e.g., a physical interface or air interface, comprising a transmitter (Tx) QQ145 and a receiver (Rx) QQ147 for enabling network node QQ100 to transmit data to and receive data from other nodes connected to a network <NUM>, e.g., an Internet Protocol (IP) network, to which network interface QQ148 is connected, physically or wirelessly, e.g., network interface QQ148 may be coupled to an antenna arrangement comprising one or more antennas for enabling network node Q100 to wirelessly transmit/receive data; and a local storage unit, a. , "data storage system", QQ108, which may include one or more non-volatile storage devices and/or one or more volatile storage devices. In embodiments where PC QQ102 includes a programmable processor, a computer program product (CPP) QQ141 may be provided. CPP QQ141 includes a computer readable medium (CRM) QQ142 storing a computer program (CP) QQ143 comprising computer readable instructions (CRI) QQ144. CRM QQ142 may be a non-transitory computer readable medium, such as, magnetic media, e.g., a hard disk, optical media, memory devices, e.g., random access memory, flash memory, and the like. In some embodiments, the CRI QQ144 of computer program QQ143 is configured such that when executed by PC QQ102, the CRI causes the network node Q100 to perform steps described herein, e.g., steps described herein with reference to the flow charts. In other embodiments, the network node QQ100 may be configured to perform steps described herein without the need for code. That is, for example, the PC QQ102 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

<FIG> is a block diagram of the UE <NUM>, according to some embodiments. As shown in <FIG>, the UE <NUM> may comprise: a PC QQ202, which may include one or more P QQ255, e.g., one or more general purpose microprocessors and/or one or more other processors, such as an ASIC, FPGAs, and the like; communication circuitry QQ248, which is coupled to an antenna arrangement QQ249 comprising one or more antennas and which comprises a Tx QQ245 and a Rx QQ247 for enabling the UE <NUM> to transmit data and receive data, e.g., wirelessly transmit/receive data; and a local storage unit, a. , "data storage system" QQ208, which may include one or more non-volatile storage devices and/or one or more volatile storage devices. In embodiments where the PC QQ202 includes a programmable processor, a CPP QQ241 may be provided. The CPP QQ241 includes a CRM QQ242 storing a CP QQ243 comprising CRI QQ244. The CRM QQ242 may be a non-transitory computer readable medium, such as, magnetic media, e.g., a hard disk, optical media, memory devices, e.g., random access memory, flash memory, and the like. In some embodiments, the CRI QQ244 of the computer program QQ243 is configured such that when executed by the PC QQ202, the CRI causes the UE <NUM> to perform actions described herein, e.g., actions described herein with reference to the flow charts. In other embodiments, the UE <NUM> may be configured to perform actions described herein without the need for code. That is, for example, the PC QQ202 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

A method according to embodiments herein will now be described from the view of the UE <NUM> together with <FIG>.

Example embodiments of a method performed by the UE <NUM>, will now be described with reference to a flowchart depicted in <FIG>. The method comprises the following actions which may be taken in any suitable order.

Action s302. The UE <NUM> receives a first message comprising the group ID allocated for a particular MBS session. The first message may e.g. be a NAS message and/or comprising a NAS container, such as e.g. an SMF NAS container. The group ID may be comprised in the NAS container. The MBS session may be identified by the MBS session ID. The group ID may be a group <NUM>-S-TMSI. The UE <NUM> may be configured to listen to the paging occasions with the group ID. For example, the UE <NUM> sends a "join message" when joining an MBS session, then the UE <NUM> receives a response, such as e.g. the first message, to the message. In other words, the message may be response to message sent by the UE <NUM> when joining the MBS session. The "join message" may e.g. be PDU Session Modification Request message sent to an AMF, such as the AMF <NUM>. In some embodiments, prior to receiving the first message, the UE <NUM> transmits a request to join the MBS session. This may be the "join message" mentioned above. The request may comprise the MBS session ID identifying the MDS session.

Action s304. While camping on a RAN node, such as e.g. the RAN node <NUM>, that does not support MBS services and while being in a RRC state other than RRC_CONNECTED, the UE <NUM> receives a paging message from the RAN node, e.g. the RAN node <NUM>. In some embodiments, the paging message comprises the group ID. The AMF <NUM> may trigger RAN node <NUM> to transmit the page with the group ID, which e.g. may be a Group-<NUM>-S-TMSI, associated to the MBS Session. The UE may have been configured to listen to the paging occasions with that group ID.

Action s306. The UE <NUM> determines whether the paging message comprises the group ID. In some embodiments, in response to determining that the paging message comprises the group ID, the UE <NUM> establishes a connection with the RAN node <NUM>. This may mean that the UE <NUM> moves to a connected state. the UE <NUM> performs the conventional legacy random access procedure and sends a service request comprising the MBS identifier, such as e.g. the MBS Session ID, to the network. After establishing the connection with the RAN node <NUM>, the UE <NUM> may receive data for the MBS session via a unicast transmission from the RAN node <NUM>. The data for the MBS session may be MBS data.

The UE <NUM> may comprise processing circuitry and a memory containing instructions executable by the processing circuitry. The UE may be configured to perform the above discussed method.

A method according to embodiments herein will now be described from the view of the network node QQ100 together with <FIG>.

Example embodiments of a method performed by the network node QQ100 implementing a core network function, will now be described with reference to a flowchart depicted in <FIG>. The network node QQ100 may e.g., be any one out of: The MB-SMF <NUM>, AMF <NUM> or SMF <NUM>. The method comprises the following actions which may be taken in any suitable order.

Action s402. The network node QQ100 allocates the group ID for a particular MBS session. The group ID may be a group <NUM>-S-TMSI.

Action s404. The network node QQ100 transmits a message comprising the group ID toward the UE <NUM>. The message may e.g. be the first message referred to above. In some embodiments, transmitting the message toward the UE <NUM> comprises transmitting the message to an SMF, e.g. the SMF <NUM>. In some embodiments, the network node QQ100 transmits a session start request message indicating the group ID to an AMF, e.g. the AMF <NUM>. The start request message may e.g., comprise the group ID and/or the MBS session ID. The message may also contain among items QoS information for the QoS flows associated with the MBS Session. The session start request message may trigger the AMF, e.g. the AMF <NUM>, to initiate a paging procedure if the AMF is serving a UE that has joined the MBS session and that is in a non-connected state. Initiating the paging procedure may comprise triggering the RAN node <NUM> to transmit a page with the group ID, such as e.g., Group-<NUM>-S-TMSI, associated to the MBS Session.

The network node QQ100 may comprise processing circuitry; and a memory. The memory may contain instructions executable by the processing circuitry, whereby the network node QQ100 is configured to perform the above discussed method.

Action s412. The network node QQ100 transmits to an AMF, e.g. the AMF <NUM>, a session start request message indicating a group ID allocated for a particular MBS session. In some embodiments, the session start request message triggers the AMF to initiate a paging procedure if the AMF is serving a UE that has joined the MBS session and that is in a non-connected state. The group ID may be a group <NUM>-S-TMSI.

As demonstrated above, group paging for MBS over non-MBS supporting RAN is introduced. A core network function, e.g., MB-SMF, SMF, etc., such as e.g. the network node QQ100, allocates a group ID, e.g., Group-<NUM>-S-TMSI, for a specific MBS session and this identifier allows grouping of UE that are interested to participate in the specific MBS Session based on knowledge that there is non-homogenous MBS support in RAN and the core network function provides that identifier to relevant UEs, such as e.g. the UE <NUM>, over NAS.

While various embodiments are described herein, an in any appendix, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration.

The overall NG-RAN architecture specified in section <NUM> applies for NR MBS. <NUM> Session Management.

Session Management for NR MBS comprises NG-RAN functions.

NG-RAN functions for NR MBS Session Management are defined to cover the following scenarios:.

<FIG> depicts an example scenario for a UE joining a deactivated multicast MBS Session and subsequent activation of the MBS Session.

Editor's Note: Only control plane entities are shown. <NUM> Transmission.

Editor's Note: covers layer <NUM> and layer <NUM> description of NR MBS transmission. y Point-to-point (PTP)-Point-to multipoint (PTM) Switching.

Editor's Note: covers both PTP to PTM switching and PTM to PTP switching.

The PTP-PTM Switching function is only applicable for a Multicast session and resides in NG-RAN node. It enables the NG-RAN node to decide for which UEs to use PTP or PTM (PTP, PTM to be defined with RAN2) for the MBS session. The NG-RAN node takes its decision based on information such as MBS Session QoS requirements, number of joined UEs, UE individual feedback on reception quality, and other criteria. The same QoS requirements apply regardless of the decision.

PTP and PTM modes can be used simultaneously in the same cell. For Broadcast session only PTM is applicable. For Multicast session both PTP and PTM are applicable. <NUM> Mobility
<NUM>. <NUM> General.

Mobility principles builds on existing functionality including functions described in section <NUM>. <NUM> Multicast Mobility from MBS supporting cell to MBS supporting cell.

During handover preparation phase, the source NG-RAN node transfers to the target NG-RAN node in the UE context information about the MBS sessions the UE has joined. For each Multicast session with ongoing user data transmission for which no MBS Session Resources exist at the target NG-RAN node, the target NG-RAN node triggers the setup of MBS user plane resources towards the 5GC. Which procedures to use is For further study (FFS).

During handover execution, the MBS configuration decided at target NG-RAN node is sent to the UE via the source NG-RAN node within an RRC container, FFS, as specified in TS <NUM> [<NUM>].

This chapter collects observations on basic Session Management related RAN functions starting with discussions on the MBS Session model and "converged" architecture as of TR <NUM> [<NUM>] TR <NUM> [<NUM>] contains the MBMS session model captured in the conclusion section, which was used as a basis for discussions along with what SA2 called the "SMF based" solution.

The model itself needs further work and translation for its application for the various system entities, as captured in NOTE 1a in §<NUM>. <NUM> in [<NUM>]: The model as depicted in <FIG> needs clarification for its application on UE, 5GC and RAN side, this will be part of normative work.

This MBMS session model needs to be put into relation to the "converged" architecture, agreed as of §<NUM> in [<NUM>], with the understanding that adaptations to that architecture are still possible and needed. The "converged" architecture is captured in Annex A of [<NUM>]. A version of that architecture w/o the service layer entities is depicted in <FIG>.

So, let's try to work out how the "Merged MBMS session model", as depicted in <FIG>, translates into NG interface functions.

The conclusions in section §<NUM> and §A. <NUM> of [<NUM>] can be interpreted to define two sets of NG interface functions:.

The concluded relation between these two set of functions, Control of MBS transport and Control for joining an MBS Session can be deduced from the following statements in §<NUM>. <NUM> of TR <NUM> [<NUM>]:.

NOTE <NUM>: Whether the terms "stop/deactivated" or "start/activation" denote the same actions needs to be further clarified.

NOTE <NUM>: Whether the MBS QoS flow need be removed from the MBS Session context is to be decided in normative phase.

From the statements quoted above, UEs rejected from joining,
"deactivating/stopping"/"activating/starting" MBS Sessions, it can be seen, that the message flow in Figure <NUM>. <NUM>-<NUM> of TR <NUM> [<NUM>] represents only one specific scenario possible: the UE joins an MBS Session for which MBS traffic delivery is already ongoing. However, there exists also the possibility, that the UE joins an MBS Session for which MBS traffic delivery is not ongoing yet. This might be either due to pauses in between MBS traffic delivery, deactivation/activation of MBS traffic delivery upon MB-UPF or AF request or due to a pause between the Service/Session Announcement and the actual start of MBS traffic delivery.

Observation <NUM>: NGAP shall support the following scenarios for MBS capable gNBs:.

TR <NUM> [<NUM>] already provides indications of the set of NGAP functions necessary to support those scenarios:
Observation <NUM>: NGAP shall support the following functions towards MBS capable gNBs:.

When it comes to details for support of the 5GC individual MBS traffic delivery, let's have another look at relevant statements in the conclusion section §<NUM>. <NUM> of TR <NUM> [<NUM>].

It appears that <NUM> [<NUM>] focusses on the to support UE mobility to/from non MBS-capable NG-RAN nodes and to prepare the execution of such mobility by establishing an associated PDU session with associated QoS flows when the UE joins the MBS Session, in fact, as quoted earlier the very same PDU Session is also used to send the join to the 5GC and the associated PDU Session with the associated QoS flows shall be able to be established as early as the joining the MBS Session by the UE happens. Although there is a Editor's Note in [<NUM>] keeping it FFS when and whether to establish or update the associated PDU session for 5GC individual MBS traffic delivery, the timing of when associated QoS flow information is provided for the associated PDU session is clearly defined to be between joining the MBS session and right before mobility to a non supporting NG-RAN node happens. In case of Xn based handover, tying the provision of associated QoS flow information to HO would result in NG signalling as part of Xn HO preparation and therefore delaying execution of Xn HO, while one possibility would be to allow only NG based HO in between supporting and non-supporting gNBs, which would clearly limit mobility performance.

In case of homogenous support of MBS (at least within a certain area), associated QoS flow information does not need to be provided at all.

Further, it can be also concluded, that design of NGAP signalling for provision of associated QoS flow information and joining information has to use existing NGAP PDU Session Resource control, as providing 5GC individual MBS traffic delivery in non-supporting gNBs has to work based on pre-Release <NUM> NGAP PDU Session resource management, and such would not work along with existing functional principles for Xn/NG handover that does not foresee to establish a PDU Session at the target gNB in the course of an Xn/NG handover.

Observation <NUM>: NGAP shall support the following functions towards MBS capable gNBs:.

Like for MBS capable gNBs observation <NUM> summarises the establishment of RAN resources for 5GC shared MBS traffic delivery and observation <NUM> summarises the time-wise interaction between joining and establishment of RAN resources for 5GC shared MBS traffic delivery, TR <NUM> [<NUM>] does not contain explicit statements w. non-MBS capable gNBs.

Joining an MBS service for a UE currently served by a non-MBS capable gNB may be seen as being out of scope for discussions in RAN. It can be assumed, that at least the 5GC would need to support MBS homogeneously in order to maintain the joining state of UEs on Session Management level while the UE moves across areas served by MBS supporting gNBs and non-MBS supporting gNBs, and, moreover, support switching between 5GC shared MBS traffic delivery in MBS supporting gNBs and 5GC individual MBS traffic delivery in non-MBS supporting gNBs. It should be discussed whether joining shall be supported via non-MBS supporting gNBs. Joining is triggered and handled at NAS level and, dependent on further SA2 discussions, it might be possible that even w/o RAN support of MBS the UE is allowed to successfully perform joining.

However, one might also argue that 5GS should be able to restrict joining MBS sessions outside the RAN support area of MBS, which would require capability indications to be provide in SIB, and, if such support should be controllable by the 5GS, respective indication on NAS. In any case, SA2 and RAN2 should be consulted.

Another aspect is the fact that keeping the transparency of AMF for Session Management signalling does not allow the AMF to be aware of UEs that have joined an MBS Session. An MB-SMF, in general not keeping UE contexts, may fail at Session Start to contact the AMF serving a UE in CM-IDLE which has joined the MBS Session and has not yet moved to a gNB supporting MBS.

Observation <NUM>: There are no NGAP functions involved for a UE joining an MBS Session within the serving area of a non-MBS supporting gNB, provided NAS functions support such scenario. However, TR <NUM> is not explicit on that possibility. Further, there are scenarios conceivable where an MB-SMF fails to contact the AMF at Session Start if the UE has not yet moved to a gNB supporting MBS. If deemed necessary, SA2 and RAN2, maybe CT1, should be consulted whether, and if, how, such functionality shall be allowed and/or controlled.

TR <NUM> [<NUM>] is also not explicit on whether the scenario of establishing RAN resources in a non-MBS supporting gNB shall be supported w/o the UE receiving MBS traffic via 5GC shared MBS traffic delivery from a MBS supporting gNB before. This aspect is related to discussion on observation <NUM>, where the NGAP support of establishing MBS Session resources at an MBS supporting gNB for UEs in any CM/RRC state would also include some kind of paging of UEs not in RRC_CONNECTED. While individual paging of UE is for sure a theoretical option, it would not scale at all for large MC groups. A scalability aspect of the same nature would also appear if "individual" MBS Session resources (in fact PDU Session resources) at a non-MBS supporting gNB have to be established for UEs currently not in RRC_CONNECTED.

Such function would also require interaction between the MB-SMF and the SMFs holding the, e.g. associated, PDU Session Contexts, to establish or modify PDU Session Resources with associated QoS Flow(s) for establishing resources for 5GC individual MBS traffic delivery. This aspect is left for SA2 to further discuss, but we should establish certain assumptions if we continue that road.

Also, if the registration area of UEs span over supporting and non-supporting gNBs, the effort in terms of paging resources is evident - especially for large MC groups.

One solution for this scalability issue could be requiring the UE to listing to paging occasions and react on paging for a kind of "group <NUM>-S-TMSI" allocated by the MB-SMF for the MBS Session and provided via NAS to the UE at joining. While naming and highlighting the scaling issue is a RAN3 topic, the hinted solution is obviously not.

Observation <NUM>: TR <NUM> is not explicit on whether establishment of RAN resources for 5GC individual MBS traffic delivery shall be supported w/o the UE being provided with MBS content via 5GC shared MBS traffic delivery for the same ongoing session before via an MBS supporting gNB. UEs not in RRC_CONNECTED would need to be paged individually and, dependent on the registration area of UEs, indication of the MBS Session start and successful establishment of RAN resources would need to be coordinated among supporting and non-supporting gNBs. It is also assumed that SMF is able to establish or to modify the (associated) PDU Session with (associated) QoS flow at establishment of 5GC individual MBS traffic delivery towards a non-MBS supporting gNB. For large MC groups there is an evident scaling issue. While identifying the scalability issue is clearly a RAN3 topic, designing a potential solution via e.g. a kind of "group paging" mechanism utilising a "MC group <NUM>-S-TMSI" is clearly not. Respective TSGs/WGs should be contacted.

A similar scalability aspect arises when looking at Session Management signalling aspects during mobility towards non-supporting gNBs. It is expected, that the associated QoS flow information is only provided to the non-supporting gNB during an ongoing session, in order to enable continuous reception MBS traffic at the non-supporting gNB, while during a "deactivated" MBS session, the associated QoS flow would be released, including RAN and NG-U resources, as concluded in TR <NUM> [<NUM>] §<NUM>. That means, that every subsequent (re)activation of the MBS Session would not only cause a potential scaling problem due to paging but also but also due to necessary signalling for the modification of the (associated) PDU Session by which resources for the associated QoS flows are established for 5GC individual MBS traffic delivery. All those functions would work in principle, and are available as well, but do not scale well for large MC groups. We do not see any possibility to solve this issue for PDU Session modification with legacy, pre-Rel-<NUM>, means but propose to highlight the issue to SA2 and RAN2.

Observation <NUM>: Activation of an MBS Session and establishment of RAN resources in non-MBS supporting gNBs cause scalability issues for large MC groups due to the expected amount of signalling induced by, UE individual, modification of the associated PDU Session to establish the associated QoS flows for the MBS Session. SA2 and RAN2 should be contacted.

As discussed in section <NUM>, the message flow in figure <NUM>. <NUM>-<NUM> in TR <NUM> [<NUM>] only shows on scenario of when MBS Session resources in an MBS supporting gNB are established. The UE may very well join while no MBS traffic delivery is ongoing, an MBS session may be deactivated and re-activated thereafter.

We would like to see a single set of functions covering all the possible scenarios.

For this reason, the following is proposed:
Proposal <NUM>: Introduce a set of 5GC triggered class-<NUM> NGAP procedures for establishing, modifying and releasing MBS Session resources in RAN in analogy to the already existing NGAP procedures for PDU Session control. These new set of procedures shall be "connection oriented" in analogy to UE-associated signalling, terminology and the range of "connection" identifiers are suggested in Annex A.

In order to build up the distribution tree along the UEs that have joined an MBS Session, supporting joining during an inactive MBS Session, the AMF would need to know the joining status of UEs, which is not the case along current TR <NUM>, which follows an approach to hide this information from AMF, due to direct communication between SMF and NG-RAN. However, as the SMF is unaware, and should be kept unaware, of the RAN nodes that have to be contacted in case of Session Start, the AMF needs to act as intermediate node of the distribution tree and keep the distribution tree up-to-date along information of joined MBS Sessions per UE. One way to realise this requirement is to inform the AMF about the MBS Session the UE has joined within PDU Session signalling, i.e. via NGAP in the response message of the NGAP PDU Session procedure outside the SMF container.

Proposal <NUM>: Introduce the possibility to inform the AMF about the MBS Sessions joined in order to allow the AMF to update the distribution tree towards the MB-SMF and to keep track of NG-RAN nodes to be contacted at Session Start along the Registration Area of UEs in CM-IDLE.

Proposal <NUM>: Liaise SA2 about those changes in the overall message flow in Figure <NUM>. <NUM>-<NUM> following proposal <NUM> and <NUM>.

As can be seen the set of class <NUM> procedures proposed in Proposal <NUM> can be very well used for setting up RAN resources for a broadcast MBS Session. Not only for broadcast, but also for (local) multicast MBS Sessions, area information would need to be included in this set of class <NUM> procedures.

Proposal <NUM>: Define the set of class <NUM> procedures proposed in Proposal <NUM> to be used also for setting up RAN resources for a broadcast MBS Session. Introduce optional area information, which can be also used for local multicast MBS traffic delivery.

As discussed above in the "observing" section, NGAP needs functions to support provision of joining information and associated QoS flow information within a PDU Session to a supporting gNB. Provision of associated QoS flow information may be provided at joining or later or not at all, in case of homogenous support of MBS.

Further, design of NGAP needs to be backwards-compatible with pre-Release <NUM> NGAP PDU Session resource control.

There would be the possibility to develop <NUM> solutions, one for homogenous support of MBS, one for interworking with non-supporting gNBs, however, we believe that would not be necessary and we would like to show how a (unified) solution could look like:.

Finally, there also needs to be an explicit indication to the SMF holding the, e.g. associated, PDU Session context for the UE to know whether another session anchor needs to be established for 5GC individual MBS traffic delivery as the w/o this information the 5GC has to assume that the RAN was not able to understand and store MBS related information in the UE context. Such explicit indication is necessary at, e.g. associated, PDU Session Setup with MBS Session related information, at HO Resource Allocation, at Path Switch and potential subsequent PDU Session Modification.

Proposal <NUM>: In NGAP and XnAP, within PDU Session related messages, add to the PDU Session List Item, MBS Session Information for the MBS Sessions the UE joined and are supported by the slice the PDU Session is associated with. Foresee the possibility to include to the MBS Session Information associated QoS flow information, which will be also added to legacy QoS Flows List during if the MBS Session is currently ongoing. A supporting gNB will ignore the QoS Flows in the QoS Flows List associated to the ongoing MBS Session, a non-supporting gNB will establish resources for 5GC individual MBS traffic delivery.

And don't forget to provide an explicit indication to the SMF holding the, e.g. associated, PDU Session context for the UE whether the provided MBS Session Information is actually stored in the gNB. RAN node supports MBS.

We have analysed the SA2 conclusions captured in TR <NUM> [<NUM>] and have observed the following:.

Claim 1:
A method (<NUM>) performed by a User Equipment, UE, (<NUM>), the method comprising:
transmitting a request to join a particular multicast-broadcast services, MBS, session, the request comprising an MBS session identifier, ID identifying the particular MBS session,
in response to the request to join the particular MBS session, receiving (s302) a first message comprising a group ID allocated for the particular MBS session, the group ID being a group <NUM>-S-Temporary Mobile Subscriber Identity, <NUM>-S-TMSI; and
while camping on radio access network, RAN, node (<NUM>) that does not support MBS services and while being in a radio resource control, RRC, state other than RRC_CONNECTED, receiving (s304) from the RAN node (<NUM>) a paging message; and
determining (s306) whether the paging message comprises the group ID.