Field of the Invention

The present invention generally relates to configuring or setting up User Equipment, UE, of a wireless communication system for multicast reception and particularly to configuring or setting up a UE, operating in a non-connected RRC state (e.g.

RRC INACTIVE state), for multicast reception in response to receiving notification that a multicast session that the UE has joined has been activated.

Background

Wireless communication systems are largely deployed to address a wide range of applications, from mobile broadband, massive machine type communications to Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data content (e.g. video, voice, messaging...) over a radio access network (RAN) through one or more base stations.

Examples of such wireless multiple-access communication systems include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourth-generation (4G) Long Term Evolution (LTE) or recent fifth-generation (5G) New Radio (NR) systems, or systems based on IEEE 802.11 standards, such as Wi-Fi.

Among the requirements for 5G NR, there are service requirements related to multicast and broadcast service, abbreviated as MBS.

For broadcast communication service, the same service and the same specific content data are provided simultaneously to all UEs in a geographical area (i.e. all UEs in the broadcast service area are authorized to receive the data). A broadcast communication service is delivered to the UEs using a broadcast session. For multicast communication service, the same service and the same specific content data are provided simultaneously to a dedicated set of UEs (i.e., not all UEs in the multicast service area are authorized to receive the data). A multicast communication service is delivered to the UEs using a multicast session.

The support of multicast/broadcast techniques enable the network to operate in a more efficient manner than unicast. The identified use cases that could benefit from this MBS feature include public safety and mission critical, V2X applications, IPTV, live video, software delivery over wireless and loT applications. 3GPP started to build functional support of MBS in 5G NR with Release 17. In 5GNR, Radio Resource Control (RRC) protocol operates in the control plane between a UE and a base station (gNB), and provides 3 different states for a UE as defined in the 3 GPP specifications TS 38.331 : RRC CONNECTED, RRC INACTIVE, and RRC IDLE states. At power up, a UE is in RRC IDLE state, and the UE changes to RRC CONNECTED state upon an RRC connection establishment with a gNB. If the RRC connection is released then the UE changes back to RRC IDLE state. When in RRC CONNECTED state, the RRC connection can be suspended by the gNB, and the UE moves to RRC INACTIVE state. When the UE is in RRC INACTIVE state it cannot communicate with the 5G system, but both the gNB and the UE keep track of the RRC connection context. Thus, the transition back to the RRC CONNECTED state from the RRC INACTIVE state is faster than the RRC connection establishment from RRC IDLE to RRC CONNECTED state.

With the 3GPP Release 17, the reception of MBS broadcast by a UE is allowed when the UE is in RRC IDLE, RRC INACTIVE, or RRC CONNECTED state, and the reception of MBS multicast is allowed when the UE is in RRC CONNECTED state only. For the Release 18, the plan is to further allow the MBS multicast reception when the UE is in RRC INACTIVE state. See, for example, 3GPP RP-213568 entitled “New WID: Enhancements of NR Multicast and Broadcast Services” submitted by CATT and entitled (3GPP TSG RAN Meeting#94-e, source CATT), section 3. The objective is to enable a large density of UEs to be receiving multicast data from one cell. Indeed, having UEs in RRC INACTIVE state leads to a downsize in the control plane footprint of the overall UEs, and thus allows the gNB to handle more UEs. Besides, to always keep UEs in RRC CONNECTED state is not power efficient. As a result, the advantages of also supporting multicast for UEs in RRC INACTIVE state have been recognized.

In Release 17, the MBS multicast session follows state transitions as defined in 3 GPP TS 23.247 v 17.3.0, figure 4.3-1. The 5G nodes involved in MBS session management are described in clause 5.1 “General Architecture” of TS 23.247 vl7.3.0. In this document “session” always refers to “MBS session”.

The session management procedures include session creation (7.1.1.2 or 7.1.1.3 of TS 23.247), session activation (7.2.5.2 of TS 23.247), session establishment and join (7.2.1.3 of TS 23.247).

At start the session does not exist. The session is created on demand of the AF (Application Function). As part of the creation process, the MBS session identifier is allocated, a multicast service area is defined and the session is announced to UEs in the service area. The multicast service area is defined in 3GPP TS 22.146 version 17.0.0, clause 3 “Definitions”. The multicast service area is defined per multicast service. One multicast service can start multiple multicast sessions. A multicast service area can be as big as a PLMN (Public Land Mobile Network) coverage area or less.

Once the session is created, the first UE to send a join request to that session will trigger the session establishment toward the NG-RAN (gNB(s) included in the multicast service area). Subsequent join request from other UEs will not trigger the session establishment. The session establishment procedure includes PDU session establishment by the UE, session join request by the UE (associating the PDU session to the MBS session), resources reservation from the core to the NG-RAN for the delivery of MBS data for the first join request.

Also once the session is created, the MB-SMF (MBS Session Management Function) can be triggered to activate the session. The trigger condition reflects the availability of the multicast data from the application. The session activation procedure includes NG-RAN resource reservation.

It is only when both the session is activated and the MBS session is established that the NG-RAN will configure the UE for the reception of multicast data.

The launch of the processes of session activation and session establishment answers to different triggers: for session activation, the trigger is the availability of the multicast data from the application and for session establishment, the trigger is the presence of at least one UE in the service area that sends a join request to the multicast session.

The establishment of a MBS session in a UE is performed when the UE is in RRC CONNECTED state. It is possible that a gNB may then decide to switch the UE to RRC INACTIVE state before the MBS multicast data are available through the session activation. As a result, when the session is activated the NG-RAN (at least one gNB) will have to notify and configure the UEs that have joined the session but are in RRC INACTIVE state.

The current version of the specifications does not provide a procedure to notify or configure a UE in RRC INACTIVE state. UE in RRC INNACTIVE state is not supposed to receive any data from applications and have limited access to control plane.

In Release 17, some mechanism was proposed to handle the case of broadcast reception in RRC INACTIVE state. Document TS 38.300 version 17.0.0, in clause 16.10.6.2 explains the use of MCCH (MBS Control Channel) by the gNB to provide the configuration to UEs in any RCC state including the RRC INACTIVE state. Indeed the MCCH channel is accessible to UEs RRC INACTIVE state and it is well adapted to send notifications and configuration parameters. However, the MCCH is indeed accessible to all UEs without restriction which for MBS multicast services represents a security breach since the access to the multicast data is subject to prior authorization for each UE during the join procedure. The multicast configuration should be available only to UEs who have acquired the proper authorization during the join procedure.

As part of on-going discussions for Release 18, document S2-2200599 proposes to switch the UE back into the RRC CONNECTED state, perform the configuration and switch again the UE to RRC INACTIVE state. While this solution seems functional, the purpose of offloading the gNB in case of large density of UEs by having UEs in the RRC INACTIVE state may not be achieved due to the additional signalling and other resources required to switch to the RRC CONNECTED state in order to configure the UE and then switch back again to the RRC INACTIVE state.

Accordingly, it is desirable to provide at least one solution to enable a UE, which has previously joined a multicast session, to be configured to receive multicast data when the multicast session is activated whilst staying in RRC INACTIVE state.

Summary

In accordance with a first aspect of the present invention, there is provided a method at a base station controlling a cell, the method comprising: receiving MBS session information for a User Equipment, UE, as part of cell reselection from a serving cell to the cell, the UE operating in a non-connected RRC state, the MBS session information identifying one or more multicast sessions the UE has joined; in response to receiving notification that one of the one or more multicast sessions has been activated, sending, to the UE, a MBS configuration message including configuration information for configuring the UE for reception of multicast data corresponding to the one activated multicast session.

The method may further comprise receiving, as part of cell reselection, context information associated with the UE. The context information may include at least one of: identification information for identifying the UE (e.g. UE ID), authentication information for use in authenticating the UE, state information indicating an operating state of the UE (for example, indicating the UE is operating in a non-connected state (e.g. RRC INACTIVE state) in addition to or as an alternative to indicating the UE is requesting cell reselection), Access Stratum (AS) context (which is the local RAN context required by the target gNB).

In an example, the base station receives MBS session information from the UE or from a source base station of the serving cell. In an example, the method further comprises receiving, from a core network, a notification message for indicating the one of the one or more multicast session has been activated.

In accordance with a second aspect of the present invention, there is provided a method for configuring a User Equipment, UE, of a wireless communication system for multicast reception, with the UE operating in a non-connected Radio Resource Control, RRC, state and having joined one or more multicast session. The method at the UE comprises: initiating cell reselection and selecting a new cell for the UE; switching from a serving cell to the new cell controlled by a new base station; in response to one of the one or more multicast sessions being activated, receiving, from the new base station, a MBS configuration message including configuration information for configuring the UE for reception of multicast data corresponding to the one activated multicast session.

For both the first and second aspects, in an example, the non-connected RRC state is a RRC INACTIVE state. Furthermore, the UE remains in the RRC INACTIVE state throughout the process (e.g. cell reselection, switching cells, on activation of a multicast session, when receiving the MBS configuration message and configuring the UE for multicast reception). The configuration information may include configuration information of at least one Multicast Radio Bearer, MRB.

By configuring the UE in the RRC INACTIVE state in response to receiving notification that the multicast session has been activated, requiring the UE to switch to the RRC CONNECTED state at the activation of the multicast MBS session can be avoided which means the number of UEs in the RRC CONNECTED state can be reduced with a resulting reduction in congestion at the gNB. Furthermore, in view of the information received at the gNB for the UE operating in the RRC INACTIVE state as part of cell reselection (such as the MBS session information and where provided, context information associated with the UE), the gNBs have received information to enable them to keep track of the UEs in RRC INACTIVE state and the gNBs do not need to send a group paging notification to the UEs in response to which the UEs would normally perform a PRACH procedure. Thus, paging of a high density of UEs by a gNB and the high density of UEs performing PRACH procedures in response, all at the same time, can be avoided which helps to reduce congestion at the gNB. Thus the UE is kept in RRC INACTIVE state during the whole process and it is able to acquire the necessary configuration without being paged and without having to send a dedicated request for multicast data reception as soon as it is available. Group paging can be read by any UE, and although a UE not involved in the MBS session indicated in the group page should not process the page, some corrupted UEs might get access to the session information and try to illegally access the multicast data. Removing the group page step mitigates this risk.

In accordance with a third aspect of the present invention, there is provided apparatus for a base station as recited in claim 26 of the accompanying claims.

In accordance with a fourth aspect of the present invention, there is provided apparatus for a User Equipment, UE, as recited in claim 27 of the accompanying claims.

Further example features of the invention are described in other independent and dependent claims.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus/device/unit aspects, and vice versa.

Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other aspects of the invention, there are provided a computer program comprising instructions which, when the program is executed by a processing unit, cause the processing unit to carry out the method of any aspect or example described above and a computer readable storage medium carrying the computer program.

Brief Description of the Drawings

Different aspects of the invention will now be described, by way of example only, and with reference to the following drawings in which:

Figure l is a schematic diagram illustrating an example wireless communication system in which the present invention may be implemented according to one or more embodiments of the invention;

Figure 2 illustrates a block schematic diagram of an example configuration of a UE in which the present invention may be implemented according to one or more embodiments of the invention;

Figure 3 illustrates a block schematic diagram of an example configuration of a base station in which the present invention may be implemented according to one or more embodiments of the invention;

Figure 4 is a flowchart showing the RRC connection states and transitions for a UE in 5GNR systems; Figures 5a and 5b are schematic and simplified diagrams of example message flows and which together illustrate an example scenario of MBS session evolution from creation to activation;

Figure 6 is a schematic and simplified diagram of an example message flow in accordance with an embodiment of the invention;

Figure 7 is a flow chart illustrating an example method executed by a base station or gNB according to an example of an embodiment of the invention;

Figure 8 is a flow chart illustrating an example method executed by a UE according to an example of an embodiment of the invention;

Figure 9 is a schematic and simplified diagram of a message flow for an example cell reselection procedure for a UE in RRC IN ACTIVE state;

Figure 10 is a schematic and simplified diagram of a message flow for another example cell reselection procedure for a UE in RRC INACTIVE state.

Detailed Description

Figure 1 illustrates an example wireless communication system 100, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system supporting multicast and broadcast service (MBS). Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present invention is limited to 5GNR systems and may be used in any wireless communication systems supporting MBS or similar service.

The system 100 comprises a User Equipment (UE) 101 (or 151), which may be for instance in or part of a vehicle, served by a base station 110 to communicate with a core network, such as the 5G core network 102. The UE may be any wireless device, such as a wireless communication device or apparatus or terminal, loT device, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, user device (e.g. smart phone, laptop, mobile phone, tablet, camera, game console, wearable device), capable of wireless communication with one or more core networks via one or more Radio Access Networks. The base station 110 is a network node which provides an access point to the core network for a UE and is part of the Radio Access Network (RAN) composed of the base stations 110, and 111. In NR, base stations are referred to as next-generation Node Bs (gNBs), the RAN is a Next Generation (NG) RAN and the core network is referred to as the 5GC. In the following, the terms RAN node, base station and gNB will be used interchangeably. The base stations 110 and 111 are interconnected by means of the Xn interface (specified in the 3GPP document TS 38.423) implemented on the wired or wireless link 130. Each base station is connected to the core network 102 by means of the NG interface (specified in the 3GPP document TS 38.413) implemented on the wired or wireless links 140 and 141.

Each of these base stations controls one or multiple cells. For instance, the base station 110 controls the cell 120, and the base station 111 controls the cell 121. A cell is a geographical area of a radio network defined by the frequency used in the cell to transmit data. The cell can be uniquely identified by a UE from an identification that is broadcasted over a geographical area. Each base station 110, 111 can serve several UEs like the UE 101 or UE 151. Once a UE has established a RRC connection with a base station (as discussed below), the base station, to which the UE is connected, is referred to as the serving base station or source base station of the UE and the cell which is controlled by the serving base station, and on which the UE camps, is referred to as the serving cell. The interface between a gNB and a UE is the Uu interface using the protocol sublayers SDAP (Service Data Adaptation Protocol), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), PHY (Physical) in the user plane, and the protocol sublayers RRC (Radio Resource Control), PDCP, RLC, MAC, PHY in the control plane.

Figure 2 illustrates a block diagram of a UE device 205, like the UE 101 or UE 151 in the Figure 1, in which the present invention may be implemented according to one or more embodiments of the invention. The UE includes components for transmitting and receiving communications, including a UE communication manager 220, a I/O controller 255, a transceiver 235, a set of antennas 245, memory 225, and a processor (CPU: Central Processing Unit) 215. All these elements communicate with each other.

Memory 225 includes RAM (Random Access Memory), ROM (Read Only Memory), or combination of both or as a non-limiting example a mass storage device such as a disk or a Solid-State Drive. Basic Input Output System (BIOS) Instructions may be stored within the memory 225.

The processor 215 is configured to execute machine readable instructions. Execution of these machine-readable instructions causes the UE to perform various functions. These functions may be related to transmission or to interaction with peripheral devices like for instance a keyboard, a screen, a mouse, etc. (not shown in Figure 2). The processor may run an operating system like for instance, iOS, windows, Android, etc.. The processor 215 may be a single processor or may comprise two or more processors carrying out the processing required for the operation of the UE 205. The number of processors and the allocation of processing functions to the processors is a matter of design choice for a skilled person.

The I/O controller 255 allows these interactions with external peripherals by providing the hardware required and by managing input and output signals.

The transceiver 235 is configured to provide bi-directional wireless communication with other wireless devices. For example, it provides the necessary modems and frequency shifters necessary to connect to one or more wireless networks, such as Wi-Fi, Bluetooth, LTE, 5GNR, etc..

The radio communications use the antenna set 245 adapted to the spectrum of the frequency transposed signals, issued from the baseband modems. The antenna set 245 may be limited to one antenna, but preferably it contains several antennas, in order to provide beamforming capability.

UE communication manager 220 handles the communication establishment of the UE to a Radio Access Network, its control and its release. The UE regularly receives from the base station an indication of slots available for communication between the UE and base station. The UE then knows where in time and frequency it expects incoming data or must send its outgoing data, whether they belong to the control or data plane. In an example implementation, the UE communication manager 220 implements the Uu interface.

Figure 3 illustrates a block diagram of a base station device 305, like the base stations or gNBs 110 and 111 in the Figure 1, in which the present invention may be implemented according to one or more embodiments of the invention. The base station device 305 includes components for transmitting and receiving communications, including a Base Station communication manager 320, a Core Network communication manager 355, a transceiver 335, a set of antennas 345, memory 325, a processor (CPU) 315, and an Inter-Station communication manager 365. All these elements communicate with each other.

The Base Station communication manager 320 handles the communications with a plurality of UEs. It is responsible for the establishment, the control and the release of these communications. In an example implementation, the Base Station communication manager 320 implements the Uu interface. The Base Station communication manager 320 includes a scheduler that allocates time frequency slots to the different UE communications. Information regarding the schedule of these slots is regularly sent to the involved UEs.

The Core Network communication manager 355 manages communications of the base station with the core network. It may provide a standardized NG interface, as defined by the 3GPP standard, to support these communications. The transceiver 335 is configured to provide bi-directional wireless communication with other wireless devices. These devices may be UEs, or even other base stations. The transceiver 335 provides the necessary modems and frequency shifters in order to connect to a large number of UEs simultaneously, using different frequency carriers, in Time Division Duplex (TDD) or in Frequency Division Duplex (FDD). The transceiver 335 is connected to the antenna set 345, that may be limited to one antenna, but preferably it contains several antennas, in order to provide beamforming capability.

Memory 325 includes RAM, ROM, or combination of both or as a non-limiting example a mass storage device such as a disk or a Solid-State Drive. BIOS Instructions may be stored within the memory 325 to support an operating system.

The inter-station communication manager 365 manages communications with other base stations. The Inter-Station communication manager 365 may provide a standardized Xn interface, as defined by the 3 GPP standard, to support these communications.

Figure 4 is a flowchart 400 showing the RRC connection states and transitions for a UE in 5G NR. The RRC protocol operates between a UE and a base station (gNB) and is defined in 3GPP specifications TS 38.331 for 5GNR. The UE’s state names are prefixed with “NR” for New Radio. Other prefixes are used for other radio interfaces like LTE radio interface. For the sake of simplicity, the radio technology prefix is omitted in the rest of the description.

Radio Resource Control (RRC) is a layer within the 5G NR protocol stack. It exists only in the control plane, in the UE and in the gNB. The behavior and functions of a base station and a UE are governed by the current RRC state of the UE. In 5G NR, three distinct RRC states are specified for a UE: RRC IDLE state 401, RRC CONNECTED state 402 and RRC IN ACTIVE state 403.

At power-up the UE is in RRC IDLE state 401, it performs radio link quality measurements and executes the cell selection evaluation process (as defined in 3 GPP specifications TS 38.304) to identify a target gNB to connect to. The UE state changes to RRC CONNECTED state 402 upon an RRC connection establishment with the target gNB that becomes the source gNB serving the UE. In the following, the source base station (or source gNB) may also be referred to as the serving base station or serving gNB. If there is no radio activity for a while, the RRC connection can be released by the source gNB, then the UE’s RRC state changes back to RRC IDLE state 401.

While releasing an RRC connection is interesting for capacity utilization and power saving, it is not ideal from the latency perspective. The overhead in establishing an RRC connection requires extra signaling that introduces delay. To cope with this drawback, the RRC INACTIVE state 403 has been introduced for 5G NR. When the UE is in RRC INACTIVE state 403, the UE cannot communicate with the 5G system, but both the source gNB (e.g. last serving gNB) and the UE store the UE context or configuration. The stored UE context or configuration includes information to facilitate quick resumption of the connection. The information may include the security context (e.g. security parameters such as security key, UE security capabilities), measurement configuration, radio configuration (e.g. UE radio capability), information about bearers, PDU session context etc. Thus, when in RRC CONNECTED state 402, the RRC connection can be suspended by the source gNB (Release with suspend), and the UE moves to the RRC INACTIVE state 403. From the RRC INACTIVE state 403, the UE can be switched back to the RRC CONNECTED state 402 by the gNB (Resume) and the UE applies the stored UE context or configuration. The RRC resume message is sent by a gNB upon reception of a RRC resume request message from the UE.

From either the RRC CONNECTED state or RRC INNACTIVE state, the UE can transit to RRC IDLE state upon a RRC release command received from the gNB.

The mobility procedure to migrate a UE from one cell to another depends on the UE’ s RRC state. In RRC CONNECTED state, the mobility procedure, called handover, is controlled by the network, and the source gNB takes the decision to trigger the handover procedure based on the measurement reports provided by the UE. In RRC INACTIVE and in RRC IDLE states (e.g. non-connected states), the mobility procedure is called cell reselection, and it is managed by the UE itself.

In RRC INACTIVE state, the UE can be configured by the network with a RAN Notification Area (RNA). For example, the message that transitions the UE to the RRC INACTIVE state contains information indicating the RNA. The RNA is the area within which the UE can move without notifying the network. When the UE in the RRC INACTIVE state moves to a cell that is not part of its currently assigned RNA, the UE performs a location-update procedure that enables the RAN (e.g. serving gNB) to update the RNA assigned to the UE. In other words, the UE has the possibility to request an RNA update to be informed of a modification of the RNA. When, as part of the cell reselection process, the UE selects a cell managed by a target gNB out of the RNA, the UE sends a resume request to the target gNB, which has three options available: to keep the UE in RRC INACTIVE state, to set the UE in RRC IDLE state, or to set the UE in RRC CONNECTED state. In RRC IDLE state, the paging procedure to inform a UE that it has to resume the connection is initiated by the core network. In RRC INACTIVE state, the paging procedure is initiated by the NG RAN (i.e. the last gNB that had set the UE in RRC_INACTIVE state).

Back to the Figure 1, it is assumed that the UE 101 is in the RRC INACTIVE state and that it is receiving multicast data of one or more multicast MBS sessions generated by the multicast application server 103. The multicast data are provided to the base station 111, which is the base station controlling the cell 121 on which the UE 101 is camping, through the core network 102 and the transport bearer (also known as GTP-U tunnel) 106 over the link 141. Then, the multicast data are transmitted by the base station 111 to the UE 101 through the MBS Radio Bearer (MRB) 154. Figure 1 also shows the UE 151 receiving data through MRB 153. In a point-to-multipoint transmission of data from the base station 111, the MRB 154 is the same MRB as MRB 153. In a point-to-point transmission, the MRBs 154 and 153 are different. A radio bearer is a set of PHY (layer 1) and MAC (layer 2) parameters allowing higher layer data connection between a UE and a gNB. Multiple types of radio bearers are defined in 5G NR: the SRB (Signalling Radio Bearer) for the control plane, the DRB (Data Radio Bearer) allowing point-to-point communication with one UE in the user plane (unicast), and the MRB allowing point-to-point communication and point-to-multipoint communication with multiple UEs (multicast/broadcast), also in the user plane.

The MBS session join procedure, as specified in 3GPP TS 23.247, is used by UEs to inform the 5GC of an interest in joining a multicast MBS session. The first accepted UE join request triggers the multicast MBS session establishment towards the NG RAN and the UE. Before sending a join request for a multicast MBS session, the UE should have established a PDU session that can be associated with multicast session(s), using the procedures as specified in TS 23.502. Also, the UE should know at least the MBS Session id of a multicast group that the UE can join, via service announcement broadcasted by the network. To join the multicast group, the UE sends a PDU Session Modification Request for the associated PDU session which contains one or several MBS Session id(s) and a join request. The MBS Session id(s) indicates the multicast MBS session(s) that UE wants to join.

To join an MBS session, the UE has to be in the RRC CONNECTED state.

Figures 5a and 5b together illustrates example message flows for an example scenario of MBS session evolution from creation to activation. Figure 5a illustrates an example message flow for MBS session creation and establishment and Figure 5b illustrates an example message flow for MBS session activation. Referring first to Figure 5a, UE, for example UE 101 (or it could be UE 151), is powered up and enters the RRC IDLE state 500. During step 501, the UE connects to the closest gNB (for example, in the case of Figure 1, UE 101 connects to gNB 111) as a result of the cell selection process defined in TS 38.304 clause 5.2.3. Once connected to the gNB, the UE enters the RRC CONNECTED state 502. Then the UE executes the registration process or procedure 503 aiming at identifying the UE in the core network or 5GC 102, checking the UE subscriptions and enforcing the authorisations. The registration procedure is detailed in TS 23.502 clause 4.2.2.2.

After registration, the UE creates a first PDU session via a PDU session establishment procedure 504. The first PDU session is a default PDU session allowing access to 5G core services. This PDU session can be later associated to the MBS session. PDU session establishment procedure is defined in TS 23.502 clause 4.3.2.

The AF (Application function) 104, in the 5G core 102, creates a multicast session on demand of the application server 103. The MBS session creation procedure 505 for creating the multicast session is defined in TS 23.247 clause 7.1.1. The session creation is driven by the AF 104 (Application Function), and on completion, the result is a MBS session id (for example, TMGI for Temporary Mobile Group Identity) allocation for the multicast session and session creation.

Once the multicast session is created, the AF 104 performs a service announcement 506 towards the UEs, e.g. the AF 104 sends a service announcement message. The service announcement message includes multicast session information which includes, among other things, the multicast MBS session id, service area description (or information) and session description information. Service announcement is described in TS 23.247 clause 6.11. Some UEs may not need to receive the service announcement message: for example service information provided in the service announcement can be pre-configured at some UEs. Also, UEs that are not connected at the time of the service announcement can access the service information by soliciting directly the AF 104 (Application Function) or MBSF (MBS Service Function) in the core network 102.

There is no timing dependencies between UE connection/registration/PDU session establishment procedures (collectively identified by reference number 521) and MBS session creation/announcement procedures (collectively identified by reference number 522). Both 521 and 522 are performed independently from each other and can happen at any time.

Once the UE 101 is registered in the core network 102 and a default PDU session is established and multicast service information is known, then UE may send or perform a join request 507 to the core network 102 to enrol in the multicast session. The multicast session information (such as, multicast MBS session id, etc. as described above) is known by the UE either after receiving the service announcement message 506, or by pre-configuration, or by soliciting the information from the core network (message flow for pre-configuration of or soliciting session information is not shown in Figure 5a or 5b). To join a multicast session the UE may reuse the default PDU session created earlier (at 504), and send a PDU session modification request including the multicast session id (TMGI). The PDU session modification request is then considered as a join request (507). Another possibility is to establish a dedicated MBS PDU session including the multicast session id for join request 507.

When the core network 102 receives a join request 507, it performs the multicast session establishment procedure 508. During the session establishment procedure 508, the core network 102 verifies the UE’s subscriptions and authorization levels to check if the UE is allowed to access the multicast session (i.e. to check the UE is one of a particular multicast group of UEs authorised to receive the multicast session). Also, as part of the session establishment procedure 508 the core network 102 will setup necessary resources in the core network to covey the multicast data from the application server 103 to the concerned gNBs. The concerned gNBs are defined by the multicast service area information established at session creation step 505. The join procedure 507 and the multicast session establishment procedure 508 are defined in TS 23.247 clause 7.2.1.

In the example shown in Figure 5a, the gNB of the NG-RAN (e.g. gNB 111) decides to switch the UE 101 to RRC INACTIVE state 510 by sending a RRCRelease message 509 (TS 38.331 clause 6.2.2). The most common reason is load management, the gNB may decide to offload its control plane load by switching some UEs to RRC INACTIVE. Also, on-going discussions for Release 18 suggest that both UEs and core network provide additional information to the gNB to help the gNB take the decision to switch some UEs to RRC INACTIVE state. The additional information may include capacity information from both UE and Core network indicating the ability to send or receive multicast data in RRC INACTIVE state. Other information may also be provided by the UEs to express a preferred state for receiving the multicast data: i.e. RRC INACTIVE or RRC CONNECTED.

Referring now also to Figure 5b, with the UE in RRC INACTIVE state 510, UEs shall perform as a background task the cell reselection process 511. This process manages the UE mobility allowing “reselecting” a new gNB depending on the new UE location. Cell reselection is described in detail in TS 38.304 clause 5.2.4. In this example it is assumed that the NG-RAN node is either gNB 110 or gNB 111 depending on UE movement. Once the MBS session is created (505), the AF 104 (Application Function) in the core network 102 can be triggered to activate the multicast session (i.e. MBS session activation 512). The trigger to activate the multicast session is independent from the join and session establishment procedures (collectively identified by reference number 523). One possible trigger is the availability of data from the application server 103. Multicast session activation is described in TS 23.247 clause 7.2.5.2. The main result of this procedure is the RAN (Radio Access Network) resource reservation by the gNBs. These resources allow the communication of the multicast data to the UEs that has already joined the multicast session. The RAN resources allocation includes the MRB configuration (MBS Radio Bearer configuration). Each gNB will use a particular configuration for the MRB for the multicast session.

Once the multicast session is activated on completion of the MBS session activation 512, the core network 102 may need to page some UEs to notify them of the availability of the multicast data. RRC INACTIVE UEs need to be paged because as explained in 510, RRC INACTIVE UEs are still moving and may enter into the cell of another gNB, but neither the new gNB (target gNB) nor the first gNB (source gNB) are aware of the UE movement at this step (i.e. at the time the multicast session is activated 512). The core network 102 sends a group page request to the gNBs with the MBS session id (not shown in Figure 5b), then each gNB sends a group paging 513 request with the multicast session id. This sequence is described as step 5 in TS 23.247 clause 7.2.5.2.

Upon reception of the group page message 513, RRC INACTIVE UEs shall prepare to resume the RRC connection during the processing 515.

As part of the RRC connection resume preparation, the UE 101 performs a Random Access procedure toward the gNB (PRACH procedure 516, PRACH stands for Physical Random Access Channel). The PRACH procedure aims at updating the UE’s system information in case it has moved to another cell or in case the system information has not been updated for a while. Then the UE 101 performs and completes the connection resume procedure in 517, which includes sending a RRCResumeRequest message (not shown in Figure 5b). The connection resume procedure 517 follows the RRC connection procedure which is defined in detail in TS 38.331.

Once the RRC connection procedure is done, the UE is in RRC CONNECTED state 518.

It is only at that step when the UE 101 is in RRC CONNECTED state 518 that the gNB 111 may send the multicast configuration (including the MRB information) to the UE, step 519, which includes sending a RRCReconfiguration message (TS 38.331 clause 6.2.2) including the MRB information.

Once the UE applies the received multicast configuration, it can receive the multicast data in 520.

As discussed in the introduction, with the UE having to switch from the RRC INACTIVE state into the RRC CONNECTED state to perform the configuration for multicast reception, the additional signalling and other resources required to configure the UE in the RRC_CONNECTED state adds to the load issues at the NG-RAN node, gNB, (i.e. too many UEs in the RRC CONNECTED state), and so the benefits of having UEs switched to the RRC INACTIVE state to avoid congestion are lost or at least reduced. For example, the paging, PRACH, MBS configuration processes to resume to the RRC CONNECTED state, as discussed above, can cause link congestion and delay issues. For example, if a high density of UEs are paged (513) by a gNB and in response perform PRACH procedures (516) to switch to the RRC CONNECTED state all at the same time, congestion at the gNB can occur.

Referring now to Figure 6 which shows an example message flow in accordance with an example embodiment of the invention. The message flow is described with reference to the wireless communication system of Figure 1 where the UE is UE 101, the NG RAN is either gNB 110 or gNB 111 (depending on whether the UE 101 is camped on cell 120 or cell 121), 5GC is the core network 102 and app. server is the MBS application service 103.

In this example, procedures like the UE registration 521, the MBS session creation 522, the UE join 523 and the UE switch to RRC INACTIVE 509, as described above with reference to Figure 5a, have already happened.

The UE is in RRC INACTIVE state 600 and in this RRC -INACTIVE state 600 the UE performs as a background task the cell reselection process or procedure 601. This process manages the UE mobility allowing “reselecting” a new gNB depending on the new UE location. Examples of cell reselection are described in detail below with reference to Figures 9 and 10. During, or as part of, the whole cell reselection process the UE system information is kept updated by the different gNBs involved. For example, a UE reads Master Information Block (MIB) and System Information Block 1 (SIB 1 ) messages sent by the different gNBs within the vicinity of the UE to acquire system information. In addition, the UE can send a SystemlnformationRequest message to a gNB to request system information. For example, a UE can send a SystemlnformationRequest message after some timer expires indicating that the system information stored in the UE is “too old”. This is specified in TS 38.331 clause 5.2.2. See below for further discussion of system information and a system information request message (e.g. system information request message 1029 described with reference to Figure 10). In this example it is assumed that the NG-RAN node serving the cell on which the UE 101 is camping is either gNB 110 or gNB 111 depending on UE movement.

The AF 104 (Application Function) in the core network 102 can be triggered to activate one or more multicast sessions (MBS session activation 602). Multicast session activation is described in TS 23.247 clause 7.2.5.2. The main result of this procedure is the RAN (Radio Access Network) resource reservation by the gNBs. These resources allow the communication of the multicast data to the UEs that have already joined the activated multicast session. The RAN resources allocation includes the MRB configuration (MBS Radio Bearer) over which the multicast data is communicated.

Once a multicast session is activated, the core network 102 may need to page some UEs to notify them of the availability of the multicast data. RRC INACTIVE UEs need to be paged because as explained in 601, RRC INACTIVE UEs are still moving and may enter into the cell of another gNB, but neither the new gNB (target gNB) nor the first or last serving gNB (source gNB) are aware of the UE movement at this step and so do not know in which cell the UE is currently located. The core network 102 sends a group page request to the gNBs with the MBS session id (not shown in the figure). However, with the message flow in accordance with an example embodiment of the invention, the gNBs do not need to forward this page notification. In other words, the gNBs do not need to send a group paging message 513 as shown in Figure 5b. Based on information received as part of a cell reselection process which information is described in more detail below with reference to Figures 7 and 8 and to the cell reselection processes of Figures 9 and 10, the gNBs have kept track of all UEs in RRC INACTIVE state and all UEs in RRC INACTIVE state have an updated set of system information. In other words, as part of performing a cell reselection process (e.g. the process of Figure 9 or Figure 10), the UE has current/up-to-date system information (such as information associated with the base station that is controlling the cell on which the UE is currently camped) and the base station that is controlling the cell on which the UE is currently camped has information associated with the UE (e.g. an identifier for each of the one or more multicast sessions that the UE has joined, context information associated with the UE such as state information indicating the UE is in a RRC INACTIVE state, the UE is currently camped on the cell controlled by the base station, the identity of the UE).

Thus, after the gNBs are notified by the core network 102 that the multicast session has been activated (e.g. after receipt of the group page request with the MBS session id), the gNB 111 prepares a MBS configuration message 609 for each UE which is camped on the cell controlled by the gNB 111 and which has joined the multicast session that has been activated. The gNB 111 then sends the MBS configuration message 609 to each of the UEs. The MBS configuration message 609 includes configuration information for configuring the UE, in a non-connected RRC state, such as RRC INACTIVE state, for reception of multicast data corresponding to the activated multicast session. In an example, the configuration information includes configuration information of at least one MBS Radio Bearer, MRB (e.g. configuration of at least one MRB to be used by the gNB 110 and the UE 101 for communication of the multicast data for the activated multicast session). Thus, in the MBS configuration message 609 the UEs will find the MBS radio bearer configuration parameter(s) to apply in order to receive the multicast data corresponding to the activated MBS session. The details of the MBS radio bearer information element can be found in TS 38.331 clause 6.3.2. The MBS radio bearer configuration information element includes PDCP (Packet Data Convergence Protocol) and SDAP (Service DATA Adaptation Protocol) setup information as determined at radio resource reservation. The MBS configuration message 609 may also include a session identifier, such as a Temporary Mobile Group Identity, TMGI, or MBS session id, for identifying the activated multicast session. In response to receiving the MBS configuration message 609, the UE 101 configures the UE 101 for reception of multicast data in a non-connected RRC state (e.g. RRC INACTIVE state) based on the configuration information in the received MBS configuration message 609. In other words, the UE 101 performs radio bearer configuration and configures itself (e.g. sets up the user plane in the UE 101 according to the radio configuration of the base station) to receive multicast data of the activated multicast session from the base station (e.g. source gNB 111). Once the MBS radio bearer configuration is done at the UE side, multicast data 605 received at the gNB 111 can be sent to the UE 101. Thus, the multicast date 610 can be received by the UE 101 while staying in RRC INACTIVE mode.

In an example, prior to preparing and sending the MBS configuration message 609, the base station or gNB may determine whether the UEs are capable of receiving multicast in RRC INACTIVE state and if the AF 104 (Application Function) allows the reception of multicast data by UEs in RRC INACTIVE state. If the gNB determines the UEs are capable of receiving multicast in RRC INACTIVE state and the AF 104 (Application Function) allows the reception of multicast data by UEs in RRC INACTIVE state, then gNB 111 prepares a MBS configuration message 609 for each UE which has joined the multicast session that has been activated and then sends the MBS configuration message 609 to each of the UEs. Otherwise, if the gNB determines the UEs are not capable of receiving multicast in RRC INACTIVE state or the AF 104 (Application Function) does not allow the reception of multicast data by UEs in RRC INACTIVE state, the gNB sends the standard group paging message 513 as defined in Figure 5b. Both UE and AF capabilities are known at the gNB since the session establishment 523. The gNB might also take into account the UE preference to receive in connected or in non-connected mode (also known at session establishment).

Referring now also to Figure 7 which is a flow chart which shows steps of a method 700 performed at a base station controlling a cell on which one or more UEs are camped in accordance with an embodiment of the present invention. Method 700 is for use in configuring a UE of a wireless communication system to setup multicast reception in response to receiving notification that a multicast session has been activated. The wireless communication system may be, for example, the wireless communication system 100 of Figure 1. With respect to the example shown in Figure 1, the base station performing method 700 may be base station 111 (also referred to as gNB 111) which controls the cell 121 and the UE may be UE 101 or UE 151 camped on the cell 121 (having switched from previous serving cell 120 controlled by base station 110 (also referred to as gNB 110)). The base station may comprise the base station 305 of Figure 3 with the method 700 being performed by the processor 315. The UE 101 is operating in a non-connected Radio Resource Control (RRC) state (such as a RRC IN ACTIVE state) and has previously joined one or more multicast sessions as discussed below with respect to Figure 8. Thus, procedures like the UE registration 521, the MBS session creation 522, the UE join 523 and the UE switch to RRC INACTIVE 509, as described above with reference to Figure 5a, have already happened and as shown in Figure 6, UE 101 is in a RRC INACTIVE state 600.

Briefly, at step 702, the gNB 111 receives MBS session information for the UE 101 as part of or during cell reselection (cell reselection process or procedure 601 of Figure 6) from a serving cell to the cell controlled by gNB 111. Although not shown in Figure 1, the UE may have previously been camped on serving cell 120 controlled by gNB 110 and during cell reselection, the UE selects cell 121 (as a target cell) and requests cell reselection from serving cell 120 to cell 121. The MBS session information identifies one or more multicast sessions the UE has already joined. The MBS session information may include, for each of the one or more multicast sessions the UE has joined, an identifier for identifying the respective multicast session. The identifier may be a Temporary Mobile Group Identity (TMGI) or MBS session id. The gNB 111 may further receive, as part of cell reselection, context information (e.g. UE context information) associated with the UE. The context information may include at least one of: identification information for identifying the UE (e.g. UE ID), authentication information for use in authenticating the UE, state information indicating an operating state of the UE (for example, indicating the UE is operating in a non-connected state (e.g. RRC INACTIVE state) in addition to or as an alternative to indicating the UE is requesting cell reselection), Access Stratum (AS) context (which is the local RAN context required by the target gNB) as defined in 3GPP TS 38.331, section 11.2.2.

As discussed in more detail below with reference to Figure 9 or 10, the MBS session information may be received from the UE 101 or from the source base station/gNB 110 of the serving cell 120. The context information may be received from the source base station or gNB 110 (e.g. in reselection request message 932 of Figure 9 or in context message 1034 of Figure 10).

The MBS session information may be included in a reselection request message (e.g. reselection request message 932 of Figure 9, reselection request message 1032 of Figure 10) or in a context message (context message 1034 of Figure 10) received at the gNB 111. The reselection request message indicates the UE 101, operating in a non-connected RRC state, requests cell reselection from a serving cell (e.g. cell 120) to the cell (e.g. target cell 121). The reselection request message may be received from the UE 101, after the UE has switched from the serving cell 120 to the cell 121 (e.g. switching occurs in step 1022 of Figure 10) or may be received from the source base station or gNB 110 controlling the serving cell 120 before the UE 101 switches to the cell 121 (e.g. switching occurs in step 923 of Figure 9). In the former case when the reselection request message is received from the UE 101, the gNB 111 sends, in response to receiving the reselection request message, a context request message (e.g. context request message 1033 of Figure 10) to the source gNB 110 of the serving cell 120 and receives from the source gNB 110, a context message (e.g. context message 1034 of Figure 10) including context information associated with the UE. The MBS session information may be included in the reselection request message sent to the gNB 111 by the UE or may be included in the context message sent by the source gNB 110 to the gNB 111. In the latter case when the reselection request message is received from the source gNB 110, the reselection request message includes the MBS session information and further includes context information associated with the UE. As discussed above, the context information may include at least one of: identification information for identifying the UE (e.g. UE ID), authentication information for use in authenticating the UE, state information indicating the UE is operating in a non-connected state (e.g. RRC INACTIVE state) in addition to or as an alternative to indicating the UE is requesting cell reselection, AS context. During step 704, the gNB 111 receives notification that one of the one or more multicast sessions that the UE 101 has previously joined has been activated. The notification may be received from the core network 102 as part of the MBS session activation procedure: e.g. the MBS session activation procedure shown as 512 in Figure 5a and 602 in Figure 6. This step is further detailed in TS 23.247 clause 7.2.5. It includes radio resource reservation by the gNB to allow sending the multicast data on the radio network to reach the UEs.

For example, as part of the MBS session activation procedure 602, the core network 102 sends a MBS session activation message (e.g. group page request) to the base stations (e.g. gNBs 110, 111) serving the cells covering the MBS service area for the multicast session (e.g. as identified by the MBS session id), which message notifies the base stations of the activation of the multicast session and normally requests the gNBs (110, 111) to send paging messages to RRC INACTIVE UEs that have previously joined the multicast session. However, as described above with reference to the message flow of Figure 6, in view of the information received at the gNB for the UE operating in the RRC INACTIVE state (such as the MBS session information and where provided context information associated with the UE), the gNBs have received information to enable them to keep track of the UEs in RRC INACTIVE state and the gNBs do not need to forward this page notification. In other words, the gNBs do not need to send a group paging message 513 as shown in Figure 5b.

At step 706, in response to receiving notification that the multicast session has been activated, the gNB 111 sends, to the UE 101, a MBS configuration message 609 including configuration information for configuring the UE 101, operating in a RRC INACTIVE state, for reception of multicast data corresponding to the activated multicast session. In an example, the configuration information includes configuration information of at least one MBS Radio Bearer, MRB (e.g. configuration of at least one MRB to be used by the gNB 111 and the at least one UE 101 for communication of the multicast data for the activated multicast session). It is noted that one or more MRBs can be associated to one MBS session. For all UEs in RRC INACTIVE state, camped on the cell 121 controlled by the gNB 111 and that have joined the multicast session earlier, the gNB 111 may prepare a MBS configuration message 609. For example, the gNB 111 may gather or obtain the necessary information (including performing RAN radio resource reservation) to build, for each UE in RRC INACTIVE state, the UE configuration and send a MBS configuration message to each of the UEs so the respective UE can receive multicast data for the activated multicast session. In this MBS configuration message 609 sent to a respective UE, the UE will find the MBS radio bearer configuration parameter(s) to apply in order to receive the multicast data corresponding to the activated MBS session. The details of a MBS radio bearer information element can be found in TS 38.331 clause 6.3.2. It includes PDCP (Packet Data Convergence Protocol) and SDAP (Service DATA Adaptation Protocol) setup information as determined when performing the radio resource reservation. The MBS configuration message may also include the MBS session identifier. For example, other field of the MBS radio bearer information element like the session identifier are fetched from the memory 325, where they have been stored at session establishment 523 or at UE context fetching where the gNB 111 may request additional UE context information from neighbouring gNBs (e.g. as part of a PRACH procedure). In one example, the MBS configuration message 609 is implemented as a new RRC message sent by the gNB on the signalling radio bearer 1 (SRB1) on the CCCH (Common Control Channel). The message includes at least a RRC transaction identifier, and a MBS configuration information element as defined in TS 38.331 clause 6.3.2.

The gNB 111 may determine whether to accept or reject cell reselection to the cell 121 controlled by the gNB 111 (e.g. as part of the admission control procedure 922 and 1023 described below with reference to Figures 9 and 10 respectively). The gNB 111 may send a reselection reject message or a reselection accept message to the UE 101 directly (e.g. when the UE 101 has switched to the gNB 111 and has sent the reselection request directly to the gNB 111) as described below with reference to Figure 10 or to the UE 101 via the source gNB 110 as described below with reference to Figure 9. In an example, the gNB 111 sends the MBS configuration message 609 to the UE 101 in response to receiving notification that the multicast session has been activated and after accepting cell reselection to the cell 121 and with the UE 101 camped on the cell 121.

Referring now to Figure 8 which shows steps of a method 800 for configuring a UE of a wireless communication system to setup multicast reception in accordance with an embodiment of the present invention, which method is performed by the UE. The wireless communication system may be, for example, the wireless communication system 100 of Figure 1 and the UE may be UE 101 and may comprise the UE 205 of Figure 2 with the method 800 being performed by the processor 215.

The UE 101 is operating in a non-connected Radio Resource Control (RRC) state (such as a RRC INACTIVE state 600 as shown in Figure 6) and has previously joined one or more multicast sessions. For example, the UE 101 has performed a joining session procedure by sending to the core network 102 a join request 507 (such as a PDU session modification request including the multicast session id or by establishing a dedicated MBS PDU session) as discussed above with reference to Figure 5a. The multicast session for which the UE is to be configured is currently not activated and so the UE is in the non-connected state or RRC INACTIVE state. As discussed above with reference to Figure 4, in the non-connected RRC state (e.g. RRC INACTIVE state), the UE 101 cannot communicate with the core network 102 but the UE context or configuration is stored at the UE and the RAN (e.g. at the last serving gNB, which may be controlling the cell where the UE is currently camped if the UE has not moved or has not moved out of the cell controlled by the last serving gNB) which information helps to speed up the UE’s transition to the connected state. With reference to the wireless communication system shown in Figure 1, the UE 101 has moved from cell 120 to cell 121 which is controlled by the base station 111 or gNB 111. Cell 120 is the current serving cell controlled by source base station 110 or gNB 110. Thus, cell 121 is referred to as the new cell controlled by new gNB 111.

Briefly, in step 802, the UE 101 initiates cell reselection and selects cell 121 as a new cell for the UE 101. With reference to Figure 6, the UE initiates cell reselection and performs cell reselection process or procedure 601. Examples of cell reselection are described in detail below with reference to Figures 9 and 10. As part of the cell reselection, the UE 101 switches to the new cell 121 controlled by the new gNB 111, step 804. For example, switching may occur in step 1022 of Figure 10 or may occur in step 923 of Figure 9.

In an example, as part of the cell reselection, the UE 101 may send a reselection request message for requesting cell reselection to the new cell 121 (e.g. reselection request message 931 of Figure 9, reselection request message 1032 of Figure 10). The reselection request message may be sent by the UE 101 to the new gNB 111, after the UE has switched from the serving cell 120 to the cell 121 (e.g. switching occurs in step 1022 of Figure 10) or the reselection request message may be sent by the UE 101 to the source gNB 110 of the serving cell 120 before the UE 101 switches to the new cell 121 (e.g. switching occurs in step 923 of Figure 9). In the former case when the reselection request message is sent to the new gNB 111 after switching to the new cell 121, the reselection request message (e.g. reselection request message 1032 of Figure 10) may include MBS session information for identifying the one or more multicast sessions the UE has joined. In the latter case when the reselection request message is sent to the source gNB 110 before switching to the new cell 121, the reselection request message includes identification information identifying the selected new cell.

At step 806, in response to one of the multicast sessions the UE has previously joined being activated, the UE 101 receives from the new gNB 111, a MBS configuration message 609 including configuration information for configuring the UE for reception of multicast data corresponding to the one activated multicast session. The configuration information may include configuration information of at least one MBS Radio Bearer, MRB (e.g. configuration of at least one MRB to be used by the gNB 111 and the at least one UE 101 for communication of the multicast data for the activated multicast session). It is noted that one or more MRBs can be associated to one MBS session. In this MBS configuration message 609 the UE will find the MBS radio bearer configuration param eter(s) to apply in order to receive the multicast data corresponding to the activated MBS session. The details of a MBS radio bearer information element can be found in TS 38.331 clause 6.3.2. It includes PDCP (Packet Data Convergence Protocol) and SDAP (Service DATA Adaptation Protocol) setup information and allows the UE to receive the multicast data while staying in RRC INACTIVE state.

In one example, the MBS configuration message 609 is implemented as a new RRC message sent by the gNB on the signaling radio bearer 1 (SRB1) on the CCCH (Common Control Channel). The message includes at least a RRC transaction identifier, and a MBS configuration information element as defined in TS 38.331 clause 6.3.2.

Although not shown in Figure 8, method 800 may further comprise configuring (e.g. performing radio bearer configuration) the UE for reception of multicast data in a nonconnected RRC state (e.g. RRC INACTIVE state) based on the configuration information in the received MBS configuration message 609. Once the MBS radio bearer configuration is done, multicast data can be received for the activated multicast session while staying in RRC INACTIVE mode and the processing is ended.

By configuring the UE in the RRC INACTIVE state in response to receiving notification that the multicast session has been activated, requiring the UE to switch to the RRC CONNECTED state at the activation of the multicast MBS session can be avoided which means the number of UEs in the RRC CONNECTED state can be reduced with a resulting reduction in congestion at the gNB. Furthermore, in view of the information received at the gNB for the UE operating in the RRC INACTIVE state as part of cell reselection (such as the MBS session information and where provided, context information associated with the UE), the gNBs have received information to enable them to keep track of the UEs in RRC INACTIVE state and the gNBs do not need to send a group paging notification to the UEs in response to which the UEs would normally perform a PRACH procedure. Thus, paging of a high density of UEs by a gNB and performing PRACH procedures in response, all at the same time, can be avoided which helps to reduce congestion at the gNB. Group paging can be read by any UE, and although a UE not involved in the MBS session indicated in the group page should not process the page, some corrupted UEs might get access to the session information and try to illegally access the multicast data. Removing the group page step eliminates this risk.

Figure 9 illustrates a message flow 900 for an example cell reselection procedure for a UE in RRC INACTIVE according to an embodiment of the invention.

This figure shows a UE 901, like the UE 101 in Figure 1, in RRC INACTIVE state, a base station 910, like the base station 110, that is the source or serving base station/gNB in the sense that it controls the cell (e.g. serving cell such as cell 120) where the UE 901 is currently camping, a base station 911, like the base station 111 that is the new base station/gNB or target base station/gNB) controlling a candidate or target cell (e.g. target or new cell 121) where the UE 701 may move, and the core network (5GC) 902, like the core network 102.

In the RRC IN ACTIVE state and unlike the RRC CONNECTED state, the UE 901 has to find and select by itself the best cell to camp on, and the core network 902 is not involved in this process. The UE 901 regularly performs measurements (step 920) on signals received at the UE 901 from the serving cell and one or more candidate cells, such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the candidate cells (also called target cells). The candidate or target cells may be neighbouring candidate or target cells to the current serving or source cell.

Once the UE 901 discovers at least one SSB with a received power that exceeds the received power of its current SSB by a certain threshold, it executes a cell reselection evaluation process at step 921. The evaluation is performed based on criteria that may include: the priority of frequencies used in the candidate cells, the radio link quality, the availability of MBS services if the information is available and the load of each of the candidate cells if the information is available. Load information and/or MBS information may be provided to the UE 901 in system information messages (such as message 1030) as discussed below with reference to Figure 10. For the selection, input information related to the priority of frequencies may be provided by the source or serving gNB 910 through the system information message 930 which is regularly broadcasted or in response to a request message (not represented on the figure) sent by the UE 901. The availability of MBS services may have been received via service announcement as discussed above. Details of an example cell reselection evaluation process performed based on the priority of frequencies used in the candidate cells and the radio link quality are given in 3GPP TS 38.304, V16.7.0, section 5.2.4. System information is a name for all the common (non-device-specific) information that a UE needs in order to properly operate within the network. In general, the system information is carried within different System Information Blocks (SIBs), each comprising different types of system information. The various SIBs are specified in the 3GPP document TS 38.331.

Based on the received system information 930 and on the measurement performed at step 920, the UE 901 may select at least one candidate new serving cell at step 921. For example, the UE 901 selects or identifies at least one candidate new serving cell from one or more candidate cells based on the performed measurements (i.e. one or more cell(s) are identified where the measurement of signals received from the cell(s) exceed a threshold). When information concerning the priority of frequencies is provided to the UE 901 (e.g. in the received system information 930), this information may also be used to select at least one candidate new serving cell at step 921. Then, the UE 901 sends a reselection request message 931 to the source gNB 910 indicating the identifier(s) of the at least one candidate new serving cell(s) selected at step 921. The reselection request message sent by the UE 901 is for requesting cell reselection to a new serving cell: the new serving cell may be selected by the UE 901 prior to sending the reselection request message (and the reselection request message includes information identifying the selected new serving cell) or may be selected by the source gNB 910 based on information (identifying information for identifying a plurality of suitable cells for the new serving cell for the UE) included in the reselection request message. The identification information for each candidate new serving cell may include the cell ID and the base station (gNB) ID of the cell. 3GPP TS 38.413 sections 9.3.1.6 and 9.3.1.7 describes the gNB ID being included in the cell ID. The reselection request message 931 may also include MBS session information identifying one or more multicast sessions the UE has joined (e.g. MBS session identified s)) identifying the one or more MBS sessions that the UE has previously joined).

Upon reception of the reselection request message 931, the source gNB 910 uses the cell(s) identifier(s) to determine the associated target gNB(s). In a case where the UE 901 provided several cell identifiers for several suitable cells, the source gNB 910 has to select one target gNB according to predefined or certain criteria. For instance, the source gNB 910 may select the target gNB 911 providing the MBS service with the lowest load. Otherwise, the cell identifier provided in the reselection request message 931 may be the cell identifier of a suitable cell selected by the UE 901 as a new serving cell and the source gNB 910 uses the cell identifier of the selected cell to determine the associated gNB which is the target gNB 911. Then, the source gNB 910 sends a reselection request message 932 to the target gNB 911. If the source and target cells belong to the same gNB, there is no need for this message as the situation in the target cell is already known by the gNB. The reselection request message 932 includes the MBS session information identifying one or more multicast sessions the UE has joined and UE context information associated with the UE. The reselection request message 932 indicates the UE is requesting cell reselection to the target cell. In an example, the context information includes identification information for identifying the UE and state information for indicating the UE is requesting cell reselection having joined one or more MBS sessions. The state information may include information indicating the UE is operating in a non-connected state (e.g. RRC INACTIVE state) in addition to or as an alternative to indicating the UE is requesting cell reselection. The context information may include AS context.

Then, the target gNB 911 performs an admission control process (step 922) to decide whether to accept or reject the reselection request. It may reject the request, for instance if the load in the target cell is too high. The target gNB 911 may send a reselection acknowledgment message 933 to the source gNB 910. The acknowledgement message 933 may indicate the target gNB 911 has rejected or accepted the reselection request.

If the target gNB 911 has accepted the reselection request, the source gNB 910 informs the UE 901 to switch cell through a reselection accept message 934, containing the necessary information for the UE 901 to switch to the target gNB 911 (e.g. system information such as the frequency used by the target gNB, etc.)

If the target gNB 911 has rejected the reselection request, the source gNB 910 may inform the UE 901 of the decision in a reselection reject message 934. According to another example, the non-reception of the message 934 at the UE 901 at the expiration of a timer initialized at the transmission of the reselection request message 931, may indicate that the reselection request is rejected.

At step 923, the UE 901 switches to the new serving cell controlled by the target gNB 911 and thus, the UE 901 becomes camped on the new cell whilst still operating in a RRC INACTIVE state.

On completion of the cell reselection (e.g. cell reselection procedure 601) in which cell reselection to the new cell (served by the target or new gNB 911) has been accepted, the UE 901 is camped on the cell served by the target or new gNB 911 (which is now acting as the source gNB for the UE 901). When one of the multicast sessions is activated (e.g. MBS session activation 602 of Figure 6), the target or new gNB 911 then sends the MBS configuration message 609 to the UE 901 as discussed above with reference to Figures 6, 7, 8.

Figure 10 illustrates a message flow 1000 for an example cell reselection procedure for a UE in RRC INACTIVE according to an embodiment of the invention.

This figure shows a UE 1001, like the UE 101 of Figure 1, in RRC INACTIVE state, a base station 1010, like the base station 110, that is the source or serving base station/gNB in the sense that it controls the cell (i.e. serving cell such as cell 120) where the UE 1001 is currently camping, a base station 1011, like the base station 111, that is the new base station/gNB or target base station/gNB) controlling a candidate or target cell (e.g. target or new cell 121) where the UE 1001 may move, and the core network (5GC) 1002, like the core network 102.

In the RRC INACTIVE state and unlike the RRC CONNECTED state, the UE 1001 has to find and select by itself the best cell to camp on, and the core network 902 is not involved in this process. The UE 1001 regularly performs measurements (step 1020) on signals received at the UE 1001 from the serving cell and one or more candidate cells, such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the candidate cells (also called target cells). The candidate or target cells may be neighbouring candidate or target cells to the current serving or source cell.

The UE may receive load information from the base station operating as the source or serving base station. gNB for the UE. The load information indicates the load status of one or more candidate or target cells. For example, the one or more candidate cells may be neighbouring candidate cells to the serving cell or may be candidate cells identified by the UE 1001 as suitable cells (e.g. as part of the cell reselection evaluation process as discussed in more detail below). The load information may also indicate the load status of the serving cell. The load information indicates the load status of each one of the one or more candidate cells. The load status of a candidate cell indicates a level of a load associated with the candidate cell. The load associated with the candidate cell may be a processing load of the base station controlling the candidate cell (e.g. the load of processing resources of the base station) and/or it may be the load of the radio resources (e.g. occupied radio bandwidth) in the candidate cell. The load information for a candidate cell may indicate the level of current load associated with the respective candidate cell. The load information may be a single bit with the value ‘ 1’ indicating that the processing load of the gNB controlling the cell and/or the radio bandwidth in the cell is at an overloaded level, and the value ‘0’ indicating that the processing load of the gNB and/or the radio bandwidth in the cell is at a not overloaded level or the values reversed with ‘0’ indicating an overloaded level and ‘ 1 ’ indicating a nonoverloaded level. The load status may be a level coded on several bits (e.g. one of a plurality of levels coded on several bits).

The UE may additionally receive MBS information indicating whether the one or more candidate or target cells can provide or support MBS service for the UE. In other words, whether the one or more candidate cells can support one or more MBS sessions (e.g. one or more MBS multicast sessions) that the UE is interested in (such as one or more multicast sessions the UE has already joined). The UE may receive MBS information indicating whether the candidate cells can support MBS service for the UE for only one or more candidate cells in the neighbourhood of the serving cell (i.e. for only the neighbouring cells of the serving cell) or may receive MBS information listing all of the cells that can provide or support MBS service for the UE. Based on the received load information and the received MBS information, the UE can select one of the one or more candidate cells as a new serving cell for the UE. For example, when there are more than one candidate cells that can support MBS service for the UE as determined by the MBS information, the UE selects the candidate cell as the new serving cell with the lowest load as indicated by the load information. Thus, by using load information and MBS information to select the new serving cell, the UE can avoid selecting a cell that cannot support the MBS session(s) for the UE and/or is overloaded as the new serving cell.

The load information and/or the MBS information may be received in system information sent periodically by the serving base station or in information sent by the serving base station in response to a request (e.g. a system information request) sent by the UE to the serving base station. The load information and/or the MBS information may be sent periodically (for example by broadcast) in a System Information Block (SIB).

Once the UE 1001 discovers at least one SSB with a received power that exceeds the received power of its current SSB by a certain threshold, it executes a cell reselection evaluation process at step 1021. The cell reselection evaluation process is performed based on the load information and/or MBS information as discussed above and may be performed according to one or more additional criteria (i.e. criteria in addition to the availability of MBS services, and/or the load of the candidate cells) that may include: the priority of frequencies used in the candidate cells, the radio link quality. The input information for the selection (priority frequencies, MBS availability and the load) may be provided by the source gNB 1010 through system information provided in a system information message 1030. The measurements in step 1020 provide radio link quality information for the selection. Details of an example cell reselection evaluation process performed based on the priority of frequencies used in the candidate cells and the radio link quality are given in 3GPP TS 38.304, V16.7.0, section 5.2.4.

System information is a name for all the common (non-device-specific) information that a UE needs in order to properly operate within the network. In general, the system information is carried within different System Information Blocks (SIBs), each comprising different types of system information. The various SIBs are specified in the 3GPP document TS 38.331. Delivering the SIBs is done in different ways depending on whether the UE is connected to the network or not: if the device is connected to the network, dedicated RRC signalling is used, otherwise broadcast signalling is used. Among the different SIBs, SIB1 comprises system information that a device needs to know before it can access the system (i.e. for the initial random access). SIB1 is always periodically broadcasted, and also includes information about the mapping of the remaining SIBs to system information messages, information about the transmission periodicity of each SIB and whether or not it is broadcasted. Indeed, SIBs can be periodically broadcasted as SIB1, but alternatively, these SIBs can be transmitted on demand, avoiding periodic broadcast in cells where no device is currently camping (and thus saving power). In this case, a UE has to explicitly request some SIBs transmission by means of a system information request message 1029. For example, the UE sends a system information request including information for requesting load status of one or more candidate cells and/or for requesting MBS information indicating whether one or more candidate cells can support a MBS service for the UE. The system information request may include identification information (identified s)) for identifying each of the one or more candidate cells. The identification information for each candidate cell may include the cell ID and the base station (gNB) ID of the cell. 3GPP TS 38.413 sections 9.3.1.6 and 9.3.1.7 describes the gNB ID being included in the cell ID. The request may also include session identification information (e.g. MBS session identifier(s)) identifying the one or more MBS sessions that the UE has previously joined). When in RRC INACTIVE state, the UE transmits the request message 1029 through the random-access procedure. See for example, the description of a Random Access Procedure in clause 9.2.6 of 3GPP TS 38.300 (V16.8.0) and 3GPP TS 38.321, V16.7.0, section 5.1.

The other SIBs comprise system information that a device does not need to know before accessing the system. Thus, a system information message 1030 may contain a SIB with a list of cells supporting the MBS service(s) and/or with the load status of cells in the neighbourhood. The load status of the current serving cell may be included as well in the message 1030. The load status of a cell may indicate a level of a load associated with the cell as discussed above.

The system information request message 1029 may be a message requesting the transmission of the list of cells providing the MBS service(s). Alternatively, this request is not necessary as the information may be already known by the UE via the service announcement broadcasted by the network during the MBS session establishment procedure.

The system information request message 1029 may be a message requesting the transmission of load status for a particular cell or a list of cells. Therefore, such message shall include an identifier of the cell(s) the UE is requesting the load status.

The message 1029 may be the RRCSystemlnfoRequest message as specified in 3GPP document TS 38.331 (vl6.7.0), and including the request for system information related to the ability for one cell or a list of cells to provide MBS services, and/or including the request for system information related to the load of a cell or for a list of cells.

Based on the received system information 1030 and on the measurement performed at step 1020, the UE 1001 may select a suitable cell to move to as a new serving cell, at step 1021. At step 1022, the UE 1001 effectively switches to the new serving cell operating on the same frequency as the previous serving cell or on a different frequency. The UE 1001 can read the system information 1031 (e.g. SIB1) broadcasted by the gNB 1011 controlling the new serving cell to help the UE 1001 to switch to the new serving cell.

In an example scenario, the UE 1001 identifies two candidate cells or target cells as suitable cells to camp on, and both the first cell and second cell are able to provide the MBS multicast service the UE has previously joined based on the MBS information received from the source or serving gNB 1010 in system information message 1030. In addition, the source gNB 1010 has informed the UE 1001 in load information that the load in the first cell is much higher than the load in the second cell. If there is no big difference of radio signal quality between the two cells as determined by the measurements performed, the UE 1001 selects the second cell as the new serving cell. In this case, the UE 1001 has selected the new serving cell according to the following priority order: 1) MBS service availability, 2) load status, 3) signal quality, where 1) is given a higher priority compared to 2), compared to 3). The priority order may not always be in this order and could be, for example, with the signal quality and load status interchanged so that the priority becomes: 1) MBS service availability, 2) signal quality, 3) load status.

After switching to the new serving cell controlled by the target gNB 1011, the UE 1001 sends a reselection request message 1032 to the target gNB 1011 (e.g. by triggering a random-access process). The reselection request message 1032 sent by the UE 1001 is for requesting cell reselection to the target cell as the new serving cell. The reselection request message 1032 includes an identifier allowing the target gNB 1011 to identify the source gNB 1010. In other words, the reselection request message 1032 may include identification information (e.g. gNB ID or cell ID) for identifying the base station 1010 (source or serving gNB 1010) of the serving cell (i.e. the previous serving cell which is the last serving cell from which the UE is switched to the target cell 121 as the new serving cell). The reselection request message 1032 may include MBS session information identifying one or more multicast sessions the UE has joined.

Then, the target gNB 1011 sends a UE context request message 1033 (also referred to as a context request message) to the source gNB 1010 to retrieve the information related to the UE 1001 (e.g. the context request message 1033 is a request for context information). The context request message 1033 may include identification information for identifying the UE 1001 (such as UE ID). The context request message may further include information for requesting context information for the one or more multicast sessions the UE has already joined. In response, the source gNB 1010 sends a UE context message 1034 (also referred to as a context message) that includes UE context information associated with the UE and may also include MBS session information identifying the one or more multicast sessions the UE has previously joined (e.g. the UE context message 1034 may include the identifier(s) of the multicast sessions the UE 1001 has previously joined). According to one example, the UE context request message 1033 may be the RETRIEVE UE CONTEXT REQUEST message specified in the 3GPP document TS 38.423 (vl6.8.0), and UE context message 1034 may be the RETRIEVE UE CONTEXT RESPONSE message specified in the same 3 GPP document.

Then, the target gNB 1011 performs the admission control step 1023 to decide whether to accept or reject the cell reselection request. It may reject the request, for instance if the load in the target cell is too high.

If the target gNB 1011 has accepted the reselection request, as the UE 1001 is already camped on the new serving cell of the target gNB 1011, no further action need be taken. However, the gNB 1011 may inform the UE 1001 through a reselection accept message 1035 that the reselection request has been accepted. According to another example, the nonreception of the reselection accept message 1035 at the UE 1001 at the expiration of a timer initialized at the transmission of the reselection request message 1032, may indicate that the reselection request is accepted. If the target gNB 1011 has rejected the reselection request, the target gNB 1011 may inform the UE 1001 of the decision in a reselection reject message 1035.

On completion of the cell reselection (e.g. cell reselection procedure 601) in which cell reselection to the new cell (served by the target or new gNB 1011) has been accepted, the UE 1001 is camped on the cell served by the target or new gNB 1011 (which is now acting as the source gNB for the UE 1001). When one of the multicast sessions is activated (e.g. MBS session activation 602 of Figure 6), the target or new gNB 1011 then sends the MBS configuration message 609 to the UE 1001 as discussed above with reference to Figures 6, 7, 8.

For both the examples of Figures 9 and 10, it may happen that the UE 901/1001 cannot receive any more signals from the source gNB 910/1010 due to a radio link failure. In this case, the UE 901/1001 may perform the cell reselection evaluation process 921/1021 without recent system information. The UE 901/1001 may select and switch to a target cell, and then may read the system information from the target gNB 911/1011 to determine whether the target gNB supports the MBS service(s) (e.g. whether the target gNB 911/1011 supports the one or more multicast sessions which the UE has previously joined) and/or whether it is not overloaded. If the selected cell is suitable to provide the MBS service(s) and/or is not overloaded, the UE 901/1001 can camp in this selected cell, otherwise it may select another one. If such information is not provided through SIBs, the UE 901/1001 may send a RRCResumeRequest message or the RRCResum eRequest 1 message indicating a request for cell reselection.

The following provides details of an example procedure for configuring a UE for multicast reception with reference to sections and clauses of TS 38.331 version 17.0.0. The MBSConfiguration message corresponds to the MBS configuration message discussed above. 5.3.X.4 Reception o f the MBSConfiguration by the UE

The UE shall:

1> if the RRCResume includes the radioBearerConfig'.

2> perform the radio bearer configuration according to 5.3.5.6;

- MBSConfiguration e. MBSConfiguration message is used to setup the reception of multicast in RRC INACTIVE state.

Signalling radio bearer: SRB1

REC-SAP: AM Logical channel: DCCH

Direction: Network to UE

MBSConfisuration message

While the present invention has been described with reference to embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the invention, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

In the preceding embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit.

Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non- transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer- readable medium.

By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.