GB2620995A

GB2620995A - MBS Multicast pre-configuration

Info

Publication number: GB2620995A
Application number: GB2214308.5A
Authority: GB
Inventors: Sahyoun Walaa; Visa Pierre; El Kolli Yacine
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2022-07-28
Filing date: 2022-09-29
Publication date: 2024-01-31
Also published as: GB202214308D0; GB202211067D0; GB2620980A

Abstract

Method performed at a User Equipment (UE) of a wireless communication system. The UE receives multicast (MBS) pre-configuration information for a multicast session, which the UE has requested to join. The UE is then configured according to the multicast pre-configuration information to receive multicast data from the multicast session. Also disclosed is a method performed at a base station involving the requested multicast session being established. The pre-configuration information may be included in at least one of a Radio Resource Control (RRC) message and a system information block (SIB). The pre-configuration information may include at least one of a radio bearer configuration information associated with low or high QoS transmission, discontinuous reception (DRX) configuration information, and neighbour cell multicast configuration information. The pre-configuration may comprise an update of existing configurations for receiving data via the multicast session. The multicast pre-configuration information may be received in a message for causing the UE to be put in a non-connected RRC state, such as RRC_IDLE and RRC_INACTIVE. The pre-configuration information may be received after a cell reselection process. The pre-configuration request may be sent after performing a PRACH procedure.

Description

Intellectual Property Office Application No G132214308.5 RTM Date:17 March 2023 The following terms are registered trade marks and should be read as such wherever they occur in this document: 3GPP DVD

IEEE Wi-Fi

Bluetooth iOS Android

LTE

Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo

MBS MULTICAST PRE-CONFIGURATION

Field of the Invention

The present invention generally relates to providing MBS multicast data reception configuration parameters to a UE (User Equipment), and particularly, but not exclusively, to configuring a UE to receive the NIBS multicast data when the UE is in either one of a RRC_CONNECTED or RACJNACTIVE state.

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 uni cast. The identified use cases that could benefit from this NIBS feature include public safety and mission critical, V2X applications, 1PTV, live video, software delivery over wireless and IoT applications. 3GPP started to build functional support of NIBS in 50 NR. with Release 17.

In 50 NR, Radio Resource Control (RAC) protocol operates in the control plane between a LIE and a base station (gNB), and provides 3 different states for a LIE as defined in the 3GPP specifications TS 38.331: RRC CONNECTED, RRC INACTIVE, and RRC IDLE states. At power up, a UE is in RAC IDLE state, and the UE changes to RAC CONNECTED state upon an RRC connection establishment with a gNB. If the RRC connection is released then the UE changes back to RAC IDLE state. When in RRC CONNECTED state, the RAC connection can be suspended by the gNB, and the UE moves to ARC 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 ARC connection establishment from RRC IDLE to RRC CONNECTED state.

With the 3GPP Release 17, the reception of NIBS broadcast by a UE is allowed when the UE is in RAC IDLE, RRC INACTIVE, or RRC CONNECTED state, and the reception of NIBS multicast is allowed when the UE is in RRC CONNECTED state only. For the Release 18, the plan is to further allow the NIBS 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 ARC_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 efEcient. As a result, the advantages of also supporting multicast for UEs in RRC INACTIVE state have been recognized.

In Release 17, the NIBS multicast session follows state transitions as defined in 3GPP TS 23.247 v17.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 v17.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 NIBS 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 NC-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 (Protocol Data Unit) session establishment by the UE, session join request by the UP (associating the PDU session to the MBS session), resources reservation from the core to the NO-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 NO-RAN resource reservation.

It is only when both the session is activated and the MBS session is established that the NO-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 UP in the service area that sends a join request to the multicast session.

The establishment of a MBS session in a UP is performed when the UP 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 NO-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 UP in RRC INACTIVE state. UP 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 IS 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. Furthermore, the MCCH content may need to be transmitted periodically and thus, it is not efficient in terms of bandwidth.

As part of on-going discussions for Release 18, document S2-2200599 proposes to switch the HE back into the RRC CONNEC1ED state, perform the configuration and switch again the HE 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 CONNEC lED state in order to configure the TIE 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

According to an aspect of the invention there is provided a multicast pre-configuration information for the multicast session, wherein the multicast pre-configuration information is received prior to activation of the multicast session, and configuring the UE according to the multicast pre-configuration information to receive multicast data via the multicast session. The method may comprise sending a request to join a multicast session to a core network via a base station. The multicast pre-configuration information may be received from a base station.

The multi cast pre-configuration information may be included in at least one of a Radio Resource Control, RRC, message and a system information block, SIB. The pre-configuration information may include at least one of: radio bearer configuration information associated with low quality of service, QoS, transmission, radio bearer configuration information associated with high quality of service, QoS, transmission, discontinuous reception, DRX, configuration information, and neighbour cell multicast configuration information.

The pre-configuration information comprising radio bearer configuration information associated with low quality of service, QoS, transmission, may be for configuring the UE when it is operating in a non-connected (RRC) state. The pre-configuration information comprising radio bearer configuration information associated with high quality of service, QoS, transmission, may be for configuring the UP when it is in a connected RRC state.

The multicast pre-configuration information may comprise an update of existing configuration information for receiving multicast data via the multicast session, and the configuring may comprise using the pre-configuration information to update the configuration of the UP to receive the multi cast data via the multi cast session.

The method may further comprise receiving data for the multicast session after performing the configuration according to the multicast pre-configuration information.

The multicast pre-configuration information may be received upon or after establishment of the multicast session.

The multicast pre-configuration information may be received in a message for causing 15 the HE to be put in a non-connected RRC state. A non-connected RRC state may be an RRC INACTIVE state.

The multicast pre-configuration information may be received with (e together with or as part of) an RRC release message.

The multi cast pre-configuration information may be received while the UP is operating in a non-connected RRC state.

The multicast pre-configuration information may be received after a cell reselection process which causes the DIE to camp in a base station The method may comprise, after the cell reselection process, receiving a notification indicating multicast pre-configuration is available for the multicast session; and sending, by the DIE, a multicast pre-configuration request to the base station, wherein the multicast pre-configuration information is received from the base station in response to the sent request The multicast-pre-configuration request may be sent after performing a physical random access channel, PRACH, procedure performed with the base station in response to the notification indicating the multi cast pre-configuration information is available.

The cell reselection process comprises sending information from the UE to a base station in a case where a new cell has been selected as a result of the cell reselection process The method may comprise sending a target base station identifier to the base station, the target base station identifier identifying a target base station associated with the new cell.

Additionally or alternatively, the method may comprise sending to a target base station associated with the new cell, multicast session identification information for identifying one or more multicast sessions joined by the UE.

The method may further comprise receiving a notification of activation of the multicast session after receiving the multicast pre-configuration information.

The UE may be configured according to the multicast pre-configuration information in response to receiving the notification.

The notification of activation may be any one of a paging message, an RRC message and a system information block, SIB.

The UE may be operating in a non-connected RRC state when receiving a notification of activation of the multicast session, and the notification of activation is received after a cell reselection process which causes the UE to camp in a base station.

A request may be sent for multicast reception and/or multicast feedback information after receiving multicast data, and, in response, further multicast configuration data may be received at the LTE.

The cell re-selection process may comprise sending information from the UE to base station that indicates multicast session identification information of multicast sessions joined by the UE.

In a further aspect according to the present invention, there is provided a method at a base station controlling a cell serving User Equipment, UE, the method comprising performing establishment of a multicast session requested by a UE, and sending, to the UE, multicast pre-configuration information for the multicast session prior to activation of the multicast session.

The base station may receive a request to join the multicast session from the UE and send the request to join the multicast session to a core network. The base station may receive from the core network information for establishing the multicast session. Establishment of the multicast session may be between the UE, the base station and a core network.

The multicast pre-configuration information may be included in at least one of a Radio Resource Control, RRC, message and a system information block, SIB The pre-configuration information may include one or more of: radio bearer configuration information dedicated for low quality of service, QoS, transmission, radio bearer configuration information dedicated for high quality of service, QoS, transmission, discontinuous reception, DRX, configuration information, and neighbour cell multicast configuration information.

The pre-configuration information comprising radio bearer configuration information associated with low quality of service, QoS, transmission, may be for configuring a UE when it is operating in a non-connected RRC state. The pre-configuration information comprising radio bearer configuration information associated with high quality of service, QoS, transmission, may be for configuring a HE when it is in a connected RRC state.

The multicast pre-configuration information may include an update of existing configuration information for receiving multicast data via the multicast session.

The method may comprise sending data for the multicast session to the UE, according to the multicast pre-configuration information.

The multicast pre-configuration information may be sent upon or after establishment of the multicast session.

The multicast pre-configuration information may be sent to the TIE in a message for causing the UE to being put in a non-connected RRC state.

The multicast pre-configuration information may be sent with (together with or as part of) an RRC release message.

The multicast pre-configuration information may be sent to the UE when the UE is operating in a non-connected RRC state.

The multicast pre-configuration information may be sent after a cell reselection process which causes the UE to camp in a base station.

After the cell reselection process, a notification may be sent indicating multicast pre-configuration; and a multicast pre-configuration request may be received from the UE, wherein the multicast pre-configuration data is sent in response to receiving the request.

The multicast pre-configuration request may be received after performing a physical 5 random access channel, PRACH, process with the UE.

The cell re-selection process may comprise sending information from the UE to a base station in a case where a new cell has been selected as a result of the cell reselection process. The method may comprise receiving, as a source base station, a target base station identifier identifying a target base station associated with the new cell. The method may alternatively or additionally comprise receiving, as a target base station associated with the new cell, multicast session identification information for identifying one or more multicast sessions joined by the UE.

that indicates multicast session identification information of multicast sessions joined by the UE.

A notification of the activation of the multicast session may be sent to the UE.

The notification of activation may comprise at least one of a paging message, an RRC message and an SIB.

Optionally, the UE is operating a non-connected RRC state when the notification of activation of the multicast session is sent and the notification of activation is sent by the base station to the UE after a cell reselection process which causes the UE to camp in a base station.

The method may further comprise receiving, from the UE, a request for multicast reception and/or multicast feedback information after sending multicast data to the UE, and sending, in response, further multicast configuration data for the multicast session to the UE The cell re-selection process may comprise sending information from the UE to base station that indicates multicast session identification information of one or more multicast sessions joined by the UE.

According to another aspect of the invention there is provided a method at a User Equipment, UE, of a wireless communication system, the method comprising receiving, for a multicast session for which the UE has requested to join, multicast pre-configuration information for the multicast session; and configuring the UE according to the multicast pre-configuration information to receive multicast data via the multicast session The multicast pre-configuration information may be configuration information (data) that is received and stored, to be applied later in an appropriate (or predetermined) situation For example, according to one or more embodiments it is received before multicast (MBS) session activation of the session to which the pre-configuration information relates. Alternatively, or additionally, a UE may receive multicast data after multicast (NIBS) session activation, and the network provides pre-configuration data to pre-configure the UE to receive multicast data after cell switching as a result of a cell reselection process. Depending on the implementation, it can be used to configure the UE before and/or after the multicast (MBS) session activation The method may include sending a request to join a multicast session to a core network via a base station.

The multicast pre-configuration information may be received from a base station (e.g. 15 a gNB or NO-RAN node).

The multicast pre-configuration information is included in at least one of a Radio Resource Control, RRC, message, a system information block, SIB, and an MBS Control Channel (N1CCH) message.

According to one or more embodiments, the pre-configuration information includes at least 20 one of radio bearer configuration information associated with low quality of service, QoS, transmission (e.g. Multicast Radio Bearer "NIRB21' configuration dedicated to receive multicast data with low QoS for candidate UEs), radio bearer configuration information associated with high quality of service, QoS, transmission (e.g Multcast Radio Bearer "MRB1" configuration mainly addressed for UEs in RRC CONNECTED state with high QoS), an inactive reception indicator that indicates to a UE if it is enabled to receive multicast data in a non-connected RRC state (e.g. an RRC INACTIVE reception indication where the gNB indicates to the UEs if they are enabled to receive multicast data in RRC INACTIVE state), information identifying a group of UEs within the same cell interested in receiving multicast data (e.g. G-RNTI identifying a group of UEs within the same cell interested in receiving multicast data), a multicast pre-configuration ID identifying a configuration applied by UEs and associated with a multicast (MBS) session ID (e.g. a Temporary Mobile Group Identity, TIVIGI), discontinuous reception, DRX, configuration information, neighbour cell multicast configuration information (e.g. applied when candidate UEs perform handover or cell reselection), and cell identification information for identifying one or more cells for which the pre-configuration shall be applied (e.g. Cell LD(s)).

The multicast pre-configuration information may comprise an update of existing configuration information for receiving multicast data via the multicast session, and the configuring may comprise using the pre-configuration information to update the configuration of the UE to receive the multicast data via the multicast session.

The method may further comprise receiving data for the multicast session after performing the configuration according to the multicast pre-configuration information The multicast pre-configuration information may be received prior to activation of the multicast session.

A notification of activation of the multicast session may be received after receiving the multicast pre-configuration information.

The UE may be configured according to the multicast pre-configuration information in response to receiving the notification The notification of activation is any one of a paging message, an RRC message, a system information block, SIB, and an MBS Control Chanel (MCCH) message.

The UE may be operating in a non-connected RRC state (e.g. an RRC INACTIVE state) when receiving a notification of activation of the multicast session, and the notification of activation is received after a cell reselection process which causes the HE to camp in a base station A request for multicast reception and/or multicast feedback information may be sent after receiving multicast data, and receiving, in response, further multicast configuration data at the UE.

The cell re-selection process may comprise sending information from the UE to base station that indicates multicast session identification information of one or more multicast sessions joined by the UE.

The multicast pre-configuration information may be received after the activation of the multicast session.

The multicast pre-configuration information may be received in a message for causing the UE to be put in a non-connected RRC state (e.g. an RRC INACTIVE state).

The multicast pre-configuration information may be received in an RRC release message (e.g. an RRC Release with SuspendConfig message).

The multi cast pre-configuration information may be received while the UP is operating in a non-connected RRC state (e.g. an RRC_INACTIVE state).

The multicast pre-configuration information may be received after a cell reselection process which causes the HE to camp in a base station.

The method may further comprise: after the cell reselection process, receiving a notification indicating multicast pre-configuration is available for the multicast session; and sending, by the UE, a multicast pre-configuration request to the base station, wherein the multicast pre-configuration information is received from the base station in response to the sent request The multicast-pre-configuration request may be sent after performing a physical random access channel, PRACH, procedure with the base station in response to the notification indicating the multicast pre-configuration information is available.

The cell reselection process may comprise sending information from the UE to a base station in a case where a new cell has been selected as a result of the cell reselection process.

The method may comprise sending a target base station identifier to the base station, the target base station identifier identifying a target base station associated with the new cell The method may comprise sending to a target base station associated with the new cell, multicast session identification information for identifying one or more multicast sessions joined by the UE.

The method may further comprise, while the UE is operating in a non-connected RRC state: prior to the cell reselection process, receiving multicast data for an active multicast session according to a configuration for a base station in which the UE is camped before cell reselection, and wherein the pre-configuration information is for configuring the HE to receive multicast data from the multicast session from the base station in which the UE is to be camped following cell-reselection The cell reselection process may comprise detecting by the UE if the cell is in the multicast service area for which the UE does not have a corresponding multicast configuration The request for the multicast pre-configuration information may comprise at least one of G-RNTI information and multicast session identification information, wherein said GRNTI information is used by the UE to decode the received multicast data According to a further aspect of the invention there is provided a method at a base 20 station (e.g. a gNB or NG-RAN node) controlling a cell serving User Equipment, UE, the method comprising performing establishment of a multicast session requested by a UE; and sending, to the UE, multicast pre-configuration information for the multicast session The method may comprise receiving a request to join the multicast session from the UE and sending the request to join the multicast session to a core network.

The multicast session may be established between the UE, the base station (NG-RAN node) and a core network (e.g. 5G core network).

The multicast pre-configuration information may be included in at least one of a Radio Resource Control, RRC, message and a system information block, SB3 The pre-configuration information may include one or more of: radio bearer configuration information dedicated for low quality of service, QoS, transmission (e.g. IVIulticast Radio Bearer -N1RB2" configuration dedicated to receive multicast data with low QoS for candidate UEs), radio bearer configuration information dedicated for high quality of service, QoS, transmission (e.g. Multcast Radio Bearer "NIRB1" configuration mainly addressed for UEs in RRC CONNECTED state with high QoS), an inactive reception indication that indicates to a UE(s) if they are enabled to receive multicast data in a non-connected RRC state (e.g. an RRC_INACTIVE reception indication where the gNB indicates to the UEs if they are enabled to receive multicast data in RRC INACTIVE state); information identifying a group of UEs within the same cell interested in receiving multicast data (e.g. an RRC INACTIVE reception indication where the gNB indicates to the UEs if they are enabled to receive multicast data in RRC INACTIVE state), a multicast pre-configuration ID identifying a configuration applied by UEs and associated with a multicast session ID (e.g. a Temporary Mobile Group Identity, TMGI), discontinuous reception, DRX, configuration information, and neighbour cell multicast configuration information (e.g. applied when candidate UEs perform handover or cell reselection) cell identification information for identifying one or more cells for which the pre-configuration shall be applied (e.g. Cell ID(s)).

The method may further comprise sending data for the multicast session to the UE, according to the multicast pre-configuration information.

The multicast pre-configuration information may be sent prior to activation of the multicast session.

The multicast pre-configuration information may be sent upon or after establishment of the multicast session The method may further comprise sending a notification of the activation of the multicast session to the UE.

The notification of activation may comprise at least one of a paging message, an RRC message and an SIB In one or more embodiments, the LIE is operating in a non-connected RRC state (e g RRC INACTIVE state) when the notification of activation of the multicast session is sent, and the notification of activation is sent by the base station to the UE after a cell reselection 10 process.

The method may further comprise receiving from the UE, a request for multicast reception and/or multicast feedback information after sending multicast data to the UE, and sending, in response, further multicast configuration data for the multicast session to the UE The cell re-selection process may comprise sending information from the UE to base station that indicates multicast session identification information of one or more multicast sessions joined by the UE.

In one or more embodiments the multicast pre-configuration information is sent after the activation of the multicast session.

The multicast pre-configuration information may be sent to the UE in a message for 20 causing the TIE to be put in a non-connected RRC state (e.g. RRC INACTIVE state) The multicast pre-configuration information may be sent in an RRC release message.

The method may further comprise: after the cell reselection process, sending a notification indicating multicast pre-configuration information is available for the multicast session, and receiving, from the UE, a multicast pre-configuration request, wherein the multicast pre-configuration information is sent in response to receiving the request The multicast pre-configuration request may be received after performing a physical random access channel, PRACH, process with the UE.

The cell re-selection process may comprise receiving information from the UE at a base station in a case where a new cell has been selected as a result of the cell reselection process.

The method may comprise receiving, as a source base station, a target base station identifier identifying a target base station associated with the new cell.

The method may comprise receiving, as a target base station associated with the new cell, multicast session identification information for identifying one or more multicast sessions joined by the UE.

The UE may be in a non-connected RRC state (e.g. RRC INACTIVE state), the base station is controlling a cell in which the UE is to be camped following a cell re-selection process, and the method may further comprise: receiving a request, from the UE, for multicast pre-configuration information corresponding to the base station.

The method may further comprise sending, to the UE, a notification that multicast pre-configuration information is available.

According to one or more embodiments, the notification is sent if the base station detects that a modification of the multicast configuration is necessary for the UE to receive multicast data in the one or more cells it controls, According to one or more embodiments, the notification is sent if the base station has been notified of a modification of the multicast configuration in one or more cells controlled by another base station.

The method may further comprise, before sending the updated multicast configuration information for the multicast session, checking that the LIE has a context that allows it to receive multicast data for the multicast session.

In a yet further aspect according to the present invention, there is provided a device comprising user equipment configured to perform a method according to any of the method aspects outlined above in respect of methods performed by UE.

In yet another aspect according to the present invention, there is provided a device comprising a base station configured to perform a method according to any of the method aspects set out above in respect of methods performed by a base station.

There is also provided a (computer) program comprising instructions which, when the program is executed by a computer, cause the computer to carry out a method according to any of the method aspects mentioned above.

The program may be provided on its own or may be carried on, by or in a (computer-readable) carrier medium. The carrier medium may be non-transitory, for example a storage medium, in particular a computer-readable storage medium. The carrier medium may also be transitory, for example a signal or other transmission medium. The signal may be transmitted via any suitable network, including the Internet. Further features of the invention are characterised by the independent and dependent claims In any of the above aspects a multicast session may comprise a session where data is sent from a network to one or more UEs, the participating UEs having specified properties or a particular profile/configuration that qualifies them to receive data via the multicast session. The multicast session may be a multicast and broadcast, MBS, session according to fifth generation (5G) new radio (NR), for example as defined in Release 17 of 5G NR.

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 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 Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated 30 memory.

It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.

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 I is a schematic diagram illustrating a first example wireless communication system in which the present invention may be implemented according to one or more embodiments; 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; 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; Figure 4 is a flowchart showing the RRC connection states and transitions for a UE in 5G NR systems; Figure 5 is a simplified flowchart illustrating MBS session evolution from creation to activation; Figure 6 is a flowchart illustrating the sending of UE pre-configuration after join 20 request according to an embodiment, Figure 7 is a flowchart illustrating the sending of UE pre-configuration after handover according to an embodiment Figure 8 is a flowchart illustrating the sending of UE pre-configuration as part of RRC Release procedure according to an embodiment, Figure 9 is a flowchart illustrating the sending of UE pre-configuration triggered by a paging message; Figures 10a and 10b are flowcharts illustrating the sending of UE pre-configuration as result of a special cell reselection process according to an embodiment; Figure 11 is a flowchart illustrating the use of the pre-configuration by the UE after the session is activated according to an embodiment; Figure 12 is a flowchart illustrating the use of the pre-configuration by the UE after the session is activated according to an embodiment; Figure 13 is a flow chart of a method executed by the gNB according to an embodiment, Figure 14 is a flow chart of a method executed by the UE according to an embodiment; Figure 15 is a flow chart showing a process whereby pre-configuration information is received at a TIE according to an embodiment; and Figure 16 is a flow chart showing a process whereby pre-configuration information is sent by a base station according to an embodiment.

Figure 17 is a flow chart showing illustrating the update of configuration initiated by the network for UEs in RRC INACTIVE state according to an embodiment; and Figure 18 is a flow chart showing illustrating the sending of configuration requested by a UE in RRC INACTIVE state according to an embodiment.

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 (1\41BS). 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 5G NR 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, sewed by a base station 110 to communicate with a core network, such as the 5G core network 102. The TIE may be any wireless device, such as a wireless communication device or apparatus or terminal, IoT 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 TIE 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 (NO) RAN and the core network is referred to as the SOC. 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 NC 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 HE 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 sewing 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) Instnictions may be stored within the 25 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, i0S, 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, 5G NR, 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.

UP communication manager 220 handles the communication establishment of the UP to a Radio Access Network, its control and its release. The UP regularly receives from the base station an indication of slots available for communication between the HE 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 HE 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 III 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 HE communications. Information regarding the schedule of these slots is regularly sent to the involved LTEs.

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 3GPP 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 5G NR. 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 HE and in the gNB. The behaviour 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 INACTIVE 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 3GPP 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 RAC 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 signalling that introduces delay. To cope with this drawback, the RRC INACTIVE state 403 has been introduced for 50 NR. When the UE is in RRC INNACTIVE 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 HE 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 (Protocol Data Unit) 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 HE 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 LTE'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 HE that it has to resume the connection is initiated by the core network. In RRC INACTIVE state, the paging procedure is initiated by the NO 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 HE 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 HE 101 through the MBS Radio Bearer (M1213) 154. Figure 1 also shows the UE 151 receiving data through NLRB 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 50 NR: the SRB (Signalling Radio Bearer) for the control plane, the DRB (Data Radio Bearer) allowing point-to-point communication with one LTE 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 NIBS 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 NIBS session. The first accepted UE join request triggers the multicast MBS session establishment towards the NO RAN and the UE. Before sending a join request for a multicast NIBS 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 HE 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 NIBS Session id(s) and a join request. The NIBS Session id(s) indicates the multicast NIBS 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 NIBS 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 NIBS session activation.

Referring first to Figure 5a, UE, for example UE 101 (or it could be HE 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 RAC CONNECTED state 502. Then the LIE executes the registration process or procedure 503 aiming at identifying the UE in the core network or 56 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 UP 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 NIBS session. PDU session establishment procedure is defined in TS 23.502 clause 4.3.2.

The AF (Application function) 104, in the 50 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 an 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 NIBS 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 N4BSF (MBS Service Function) in the core network 102.

There are no timing dependencies between UE connection/registration/PDU session establishment procedures (collectively identified by reference number 521) and NIBS 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 UP 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 LIE 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 NIBS 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 UP'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 LTEs to express a 25 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. NIBS 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 IS 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 (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, 10 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 paging message to the gNBs with the MBS session id (not shown in Figure 5b), then each gNB sends a group paging 513 message with the multicast session id. This sequence is described as step 5 in IS 23.247 clause 7.2.5.2.

Upon reception of the group paging 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 20 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 HE 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 IS 38.331.

Once the RRC connection procedure is done, the UE is in RRC CONNECTED state 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 HE, step 519, which includes sending a RRCReconfigurati on message (TS 38.331 clause 6.2.2) including the MRB information.

Once the HE 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 CONNEC 1ED 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 NO-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, processes to resume to the RRC CONNECTED state then MBS configuration, as discussed above, can cause link congestion and delay issues.

The following embodiments provide a method for configuring UEs to receive multicast data while in RRC INACTIVE state that simplifies the procedure of Figure 5b. This is because the RRC resume procedure followed by the NIBS configuration can be skipped if the UE is pre-configured to receive in such conditions.

An embodiment of the invention is shown in Figure 15 which is method 1500 performed at a UE. At 1501, the TIE may send a request to join a multicast session. In 5G NR the request is typically sent to the core network via a base station such as a gNB 110, 1 1 1 but it is envisaged that, in alternative implementations, it may be sent to or via another network entity, for example a UE acting as a relay.

NIulticast pre-configuration information is received by the UE at 1502 prior to activation of the multicast session which the UE has requested to join. Session activation may be NIBS session activation, for example, as described above with respect to 512 of Figure 5. The pre-configuration information may be received from a base station or another entity in the network such as a TIE acting as a relay. The HE may then perform configuration according to the multicast pre-configuration information so as to receive multicast data via the multicast session (1503).

Figure 16 shows a flow chart 1600 having steps performed at a base station according to an embodiment. At 1601, a request made by a UE to join a multicast session may be received by the base station. The request is for the core network and accordingly such a request may then be forwarded (sent) by the base station to the core network 102. At 1602, a multicast session is established. In other words, the base station participates in the multicast session establishment process to establish the session between a UE and a core network. This will include receiving information from the core network in response to the join request as part of an establishment process. The multicast session establishment may comprise the NIBS session establishment 508 described in connection with Figure 5 which establishes the MBS session requested by a UE 101 between the UE 101, gNB 110, 111 and core network 102 Subsequently, at 1603, and prior to activation of the multicast session, multicast pre-configuration information is sent to the UE.

In this description, "multicast pre-configuration information means configuration information (data) that is received and stored, to be applied later in the appropriate situation.

According to some embodiments it is received before multicast (IVIES) session activation of the session to which the pre-configuration information relates In other embodiments, a UE may receive multicast data after multicast (NIBS) session activation, and the network provides pre-configuration data to pre-configure the UE to receive multicast data after cell switching as a result of a cell reselection process. Depending on the implementation, it can be used to configure the UE before and/or after the multicast (NIBS) session activation Where we specifically refer in the description to multicast (NIBS) pre-configuration' of a UE this refers to the act of applying received multicast pre-configuration information in the appropriate situation to receive multicast (MBS) session information.

Sending and receiving the pre-configuration information prior to activation enables the network to alleviate the configuration load and the signalling overhead when receiving the first multicast data. This mitigates the risk of overloading the cell (i.e. the radio resources in the cell) and/or the gNB (i.e. the processing resources at the gNB) when configuring all involved UEs with the radio resources they require when the session becomes activated.

According to embodiments, a UE can be configured at different stages. In an embodiment, a network can configure the UEs after a join request made by the UE, and upon arrival of first multicast data. Hence, when the network is ready to configure a UE, it generates a triggered Information Element or message which is sent to the UE.

Different scenarios are described in the sections below and, depending upon the triggering event(s), different possibilities exist for sending the multicast pre-configuration information. For instance, the triggering event may be the multicast establishment at the network side i.e., once the multicast configuration context is available at the network side, a multicast pre-configuration message is sent (e.g. by a base station) to one or more (candidate) UEs.

Other triggering aspects may be evaluated by the network e.g., the decision of which UEs are suitable candidates for the multicast session (e.g. based on the UE's capabilities). Once the group of candidate UEs is determined, the network may then trigger a multicast pre-configuration message to the identified group of UEs For example, candidate UEs may be those with the capabilities listed below: - Able or preferring to receive multicast data in RRC_INACTIVE state Receiving multicast data in RRC_CONNECTED state with low QoS In some scenarios, the UE may request the pre-configuration and hence, triggering a multicast pre-configuration message sent by the network side (i.e. from a base station).

The multicast pre-configuration information may include one or several pre-configurations, each pre-configuration may consider different information elements including but not limited to: - Multicast Radio Bearer "TVIRB2" configuration dedicated to receive multicast data with low QoS for candidate UEs, or "NIRB1" configuration mainly addressed for UEs in RRC CONNECTED state with high QoS, - An RRC INACTIVE reception indication where the gNB indicates to the UEs if they are enabled to receive multicast data in RRC INACTIVE state,. The absence of this indicator means that UP can receive by default multicast data in RRC INACTIVE state.

- G-RNTI identifying a group of UEs within the same cell interested in receiving multicast data -Multicast pre-configuration ID referring to the configuration applied for UEs and associated with the NIBS session ID (e.g., TMGI), - Discontinuous reception (DRX) configuration used to receive multicast data for candidate UEs - Neighbour cells multicast configuration applied when candidate UEs perform handover or cell reselection Cell ID(s) identifying the cell(s) in which the pre-configuration shall be applied. The multicast configuration or pre-configuration of an MBS session may have common information elements used for all the NO-RAN nodes located within the NIBS service area and thus, the UE has common configuration that could be applied wherever in the MBS service area. Thus, cell (re)selection or handover becomes transparent to the mobile UE.

The following description sets out different embodiments of sending multicast pre-configuration information at different stages with different possible triggering events. These include: - at MBS session establishment (or after) in an RRC CONNECTED state (figure 6) - When a HE switches to RRC INACTIVE state - When a UE is in RRC INACTIVE state Most of the scenarios cover possible handover in RRC CONNECTED state or cell (re)selection in RRC INACTIVE state.

In a first scenario, to send an MBS multicast configuration to a UE, the NG-RAN node must have performed radio resources reservation corresponding to the MBS session requirement like the QoS flow information or the RRC state of reception 10 (RRC CONNECTED, RRC INACTIVE) During the UE join request procedure the gNB has enough information to perform radio resource reservation for UE reception in both RRC INACTIVE and RRC CONNECTED states. According to an embodiment, based on this knowledge the pre-configuration information (corresponding to RRC INACTIVE and RRC CONNECTED) are sent by the gNB to the core network, then the core network sends it to the UEs. Thus, the UEs configuration is distributed in time ahead of the session activation.

Figure 6 is a flowchart illustrating the sending of multicast pre-configuration information after a] oin request by a UE, according to an embodiment based on the first scenario. The UE in 601 belongs to a group of candidate User Equipment UEs able to receive 20 multicast data with low QoS as described previously. This LIE 601 is in RACCONNECTED state 604 and attempting to join the NIBS session. After an announcing message 506 from the 5GC in 603 informing about an MBS session creation with the associated TMGI (i.e., Temporary Mobile Group Identity used as valid MBS session ID), the UE 601 will proceed with the session joining step 605 (or alternatively a session update) and then the session establishment in 606. In an embodiment, these steps correspond to step 1300 described below with respect to Figure 13. The UE in 601 may inform NC-RAN node 602 and 5GC 603 about its capability and/or preference to receive multicast (MBS) data with low QoS or to receive multicast (MBS) data in RRC INACTIVE state. This information can be sent earlier at the registration stage or during the join request.

After accepting the join request, an MBS session establishment procedure is performed in 606 between the UE in 601, the NO-RAN node in 602 and the 5GC in 603. In 606, a multicast session context is created and associated to the UE in 601. In Release 17, MRB contexts could be configured and included in the multicast session context and radio resources can be reserved as in 1301. At this stage, IVIRB contexts refer either to MRB1 or MRB2 contexts for UEs allowed to receive multicast data in RRC CONNEC 1ED state (TS 38.401 clause 6.4 and TS 23.247 clause 7.2.1.3) whereas no MRB context is available to receive in RRC INACTIVE state.

In this embodiment, a pre-configuration may be added to the MBS session establishment procedure 606 and radio resources can be reserved as in step 1301. In other words, the multicast pre-configuration information is sent to the HE upon multicast session establishment. Thereafter, UEs pre-configured at this stage using the received multicast pre-configuration information can receive multicast data in RRC INACTIVE state.

The multicast (pre)-configuration may refer to a multicast Point-to-Multipoint (PTM) configuration in the description below, allowing a shared delivery of multi cast data over radio to one or multiple UEs. The multi cast PTM configuration is applied to a UP receiving multicast data in the RRC _INACTIVE state.

For instance, the multicast pre-configuration information can be added to the multi cast session context already existing in the MBS session establishment procedure 606. Another implementation consists of creating new multicast pre-configuration session context separately and then added to the procedure in 606. The multi cast pre-configuration session context is then added to the information elements to be exchanged with the UE at the MBS session establishment stage and sent through RRC Reconfiguration message The multicast pre-configuration context should be established by the network earlier or at the moment of the MBS session establishment 606 and therefore, it can trigger a multicast session context modification and/or creation in 606. Another condition could be added to the triggering event such as the candidate UE portfolio.

Multicast pre-configuration information includes the MRB 1 /IVIRB2 configuration(s) as well as a list of information elements mentioned above. The network can choose a shared delivery of multicast data to multiple UEs through a multicast PTM pre-configuration. Otherwise, the UE can be pre-configured for an individual delivery and thus, a dedicated multi cast pre-configuration is designated.

When the MBS session is activated, and the UE 601 is in RRC INACTIVE state, it can then apply its multicast pre-configuration to receive multicast data. It is not necessary to resume the RRC CONNECTED state.

The multicast pre-configuration context may be established after the MBS session establishment in 606 and thus, it triggers various multicast pre-configuration messages sent to the HE 601 depending upon its RAC state. The following scenarios depict other alternatives to configure/pre-configure the LIE by receiving pre-configuration information under different timings and/or conditions.

Some UEs are always moving, and it can happen that a UE moves after receiving pre-configuration information from a gNB. So, when a gNB hands over a HE in an RRC CONNECTED state to another gNB because the HE has moved, it is important that the new gNB changes the UE pre-configuration information to match its resources. Thus, in this second scenario, the pre-configuration information is always accurate in case of HE moving to other cells.

Figure 7 is a flowchart illustrating the sending of UE pre-configuration after handover according to an embodiment applicable in the second scenario.

The network can choose to pre-configure the HE in 601 independently from the NIBS session establishment procedure in 706. Furthermore, the multicast pre-configuration context may be setup by the network after the NIBS session establishment 706 and then, it may trigger a message in 708 to send pre-configuration information to the UE 601 which can be used to pre-configure or configure the UE. The scenario in figure 7 considers that the multicast preconfiguration/configuration context is available after the MBS session establishment 706 whereas the UE is in RRC CONNECTED state. The NO-RAN node 602 may include this context in the multicast pre-configuration message in 708. Other triggering conditions related to the candidate HE portfolio may be required to send the multicast pre-configuration message in 708.

The message in 708 corresponds to the step 1302 if the UE is in RRC CONNECTED state wherein the pre-configuration message is sent. The message 708 could also be equated to 25 the step 1306 of Figure 13 (described below) if handover is performed in RAC CONNECTED state.

In an example, the message in 708 may be sent in one or multiple RRC messages such as RACReconfiguration message, RRCRelease message with, for example, SuspendConfig-or dedicated System Information Block (SIB) to the UE in 601. The message may include various 30 information elements and mainly the NIRB2 configuration.

A handover can occur in 707 before the multicast pre-configuration information is received, the candidate HE in 601 is not yet pre-configured. During the handover procedure, the source NO-RAN node 602 may exchange the UE capability and preferences (i.e., RRC INACTIVE/CONNECTED multicast reception with low QoS) with the target NO-RAN node in 700 Therefore, the target NO-RAN node 700 may choose to pre-configure this UE by sending the multicast pre-configuration message.

For instance, the handover 707, 1304 may occur after the source multicast pre-configuration message in 708, the target NO-RAN node 700 should send then the target multicast pre-configuration message. Another alternative consists of including in the source multicast pre-configuration message 708, the list of neighbour cells with the corresponding multicast pre-configurations/configurations. In this case, the UE in 601 being handed over the target NO-RAN node 700 will be able to apply the target multicast pre-configuration without the need to be pre-configured again.

In a particular case where the source 602 and the target NO-RAN 700 nodes are within the same MBS service area, and a common multicast pre-configuration/configuration context is shared within the IVIBS service area, the UE 601 can be pre-configured/configured once within the NIBS service area We can consider a third scenario in which, when a UE performs a join request procedure, it may indicate its capability and preferences in term of RRC state for reception. As part of session establishment, the gNB knows also the capability/preference of the application regarding the RRC state for reception by the UEs. At any time for the need of load management the gNB may decide to switch some UEs to RRC_INACTIVE state using the RRC release procedure. As part of the RRC release procedure the gNB may send or update the pre-configuration to UEs to be switched. Thus, it is possible to update the resource reservation as a response to a load stress in the gNB ahead of the session activation.

Figure 8 is a flowchart illustrating the sending of UE pre-configuration as part of RRC Release procedure according to an embodiment that is particularly useful in the above mentioned third scenario.

In particular, Figure 8 shows another alternative for pre-configuring one or more UEs capable and/or preferring to receive multicast data with low QoS in RRC INACTIVE or RRC CONNECTED states. The process shown in this figure corresponds to the offload step in 1307 of Figure 13 which will be described in more detail below. After a join request 605 and NIBS session establishment 806, a UE 601 can receive multicast data in RRC_CONNECTED state as in Release 17. The UE 601 is considered as a candidate UE by the NO-RAN node in 602.

NO-RAN node 602 may choose to switch a group of UEs to RRC_INACTIVE state to control the signalling overhead and to reduce the power consumption. NO-RAN node (602) may decide to pre-configure the candidate UEs of the group to remain in an RRC_INACTIVE state and receive multicast data.

In an example, the network 602,603 decision in 809 may trigger the multicast pre-configuration message sent in 807 and referred in 1309. The triggering event may be correlated with the availability of the multicast pre-configuration context at the network and the portfolio of the switched UE.

To this end, the NO-RAN node 602 may use a RRCRelease with SuspendConfig message in 807 and 1309 with an amendment of its content. Additional fields related to the multicast pre-configuration context can be included and thus, the candidate UE in 601 performs its transition to RRC INACTIVE state 808 and is aware that by then, it is pre-configured to receive multicast data while remaining in RRC_INACTIVE state. An RRC_INACTIVE reception indicator may be added to the multicast pre-configuration message to inform the pre-configured UE that it is allowed to receive while in RRC INACTIVE state. This field is optional and its absence enables the UE to receive multicast data by default when in RRC_IN ACTIVE state, upon arrival of multi cast data at the UE.

The NO-RAN node 602 may choose to send the multicast pre-configuration information in a separate multicast pre-configuration message before the RRCRelease message.

The separate message may be sent in RRC or dedicated SIB container types by a way of example. In this description we use the term SIB as a simplification of SIB + NICCH, meaning using System Information Block and/or MBS Control Channel message. For example, MCCH scheduling information can be provided via SIB, or alternatively the whole information can be contained in the SIB.

In a fourth scenario, the gNB may process to the release of the UEs and their transitions to RRC_INACTIVE state with no modification to the RRCRelease procedure. A paging message issued by the gNB may indicate to the interested UEs of possible multicast pre-configurations in RRC INACTIVE state.

An embodiment related to the fourth scenario, is shown in Figure 9 which is a flowchart illustrating the sending of UE pre-configuration triggered by a paging message.

The UE in 601 is a candidate UE that may receive multicast data in RRC_INACTIVE state. It sends a join request in 605 and an NIBS session is then established in 906 between the UE 601, the NO-RAN node in 602 and the 5GC in 603.

The NO-RAN node 602 may decide to alleviate the signalling load and to switch a group of UEs to RRC INACTIVE state in 908 by sending an RRCRelease message in 907 In order to pre-configure the UE 601 in RRC INACTIVE state as in step 1303, the NGRAN node may send a notification message in 910. The notification of multicast pre-configuration availability may be any one of a paging message, an RRC message or a system information block, SIB.

The notification of multicast pre-configuration update may be any one of a paging message, an RRC message or a system information block, SIB.

In figure 9, the message 910 is illustrated as a paging message for instance including the TMGI of the MBS session and the paging cause indicating that the paging is for multicast pre-configuration as in 1405 of Figure 14 described below. The paging may be triggered by the network after the setup or an update of the multicast pre-configuration context.

The UE 601 in RRC INACTIVE state may process the paging message in 911 and identifies the paging cause. If the UE in 601 is subscribed to the MBS multicast session and interested in receiving multicast data while remaining in RRC_INACTIVE state, a PRACH exchange procedure in 912 is initiated by the UE 601 with the NG-RAN node 602. In 912, the UE 601 requests uplink radio resources for L2/L3 messages. Next, the UE 601 sends a multi cast pre-configuration request in 913 to the NG-RAN node 602, including its UE identity in RRC INACTIVE state (e.g. the I-RNTI) The NG-RAN node may send in response the multicast pre-configuration information in 914 (corresponding to 1406 of Figure 14 which is described below) if the UE is suitable to receive multicast data. A reject message can be sent to the UE 601 with the reject cause. In an example, the UE in 601 may not be suitable to receive an RRC_INACTIVE state according to the network and thus, the RRC INACTIVE reception indicator can be disabled and sent as the rejection cause.

A cell (re)selection in 909 may occur after switching the UE to RRC INACTIVE state in 908. In this case, the steps 910-914 will be the subject of message exchange with the new target NO-RAN node in 900. The target NG-RAN node may send a notification message in 910. The notification message can be a paging message, a SIB or a dedicated RRC message.

In a way of example, the 910 message may be a group paging message including the TINIGI of the NIBS session and the paging cause indicating an available multicast pre-configuration at the target NG-RAN node. The UE 601 after a cell reselecti on in 909 is not yet identified by the target NO-RAN node in 900. After processing the paging by the UE 601, PRACH exchange procedure in 912 is then initiated by the UE 601 with the target NO-RAN node (602) to indicate its presence in the target cell and to request radio resources for uplink signalling message exchange. If the UE 601 has already joined the MBS session and it is interested in receiving multicast data in RRC INACTIVE state, it may send a multicast pre-configuration request to the target NG-RAN node in 913. The target NG-RAN node verifies then that the HE has joined the MBS session and it is capable and suitable to receive multicast data in RRC INACTIVE state. Next, the target NG-RAN node may send a multicast pre-configuration response in 914 to the UE 601. The target NC-RAN node may reject the request while indicating the reject cause. The rejection cause may be a disabled RRC INACTIVE reception indicator informing the UE that no multicast reception is allowed in RRC INACTIVE state The multi cast pre-configuration request in 913 can be sent in different container types. In an example, an RRC message such as RRCResume Request with additional fields for pre-configuration purpose can be employed. A SIB on demand could be used also by the UE to request the multicast pre-configuration.

The multicast pre-configuration information in 914 can be sent by the network using different container types. RRC messages such as RRCResume with the dedicated multicast pre-configuration, a RRCRelease with SuspendConfig or RRCReconfiguration message, then the UE remains in RRC INACTIVE state. Otherwise, a SIB on demand sent by the UE in 913 may trigger a dedicated SIB in 914 sent by the network with the required multicast pre-configuration. In case of reject message in 914, it can be sent by RRC messages, dedicated SIB or other container types.

In a fifth scenario, the gNB may pre-configure the UEs that have switched to 25 RRC INACTIVE state by sending the multicast pre-configuration message.

Figures 10a and 10b are flowcharts showing an embodiment particularly applicable to the above mentioned fifth scenario, that shows the sending of UE pre-configuration to a UE in RRC INACTIVE state and applying an enhanced cell reselection process.

Figure 10a shows a UE in 601 attempting to join the multicast MBS session in 605 30 while in RRC CONNECTED state 604. Next, the multicast NIBS session is established in 1006 between the HE 601, the NO-RAN node 602 and the 5GC 603 The UE in 601 is a candidate UE that may be capable and/or prefer to receive multicast data with low QoS whether in RRC INACTIVE or RRC CONNECTED state.

As with the embodiment of Figure 9, the NO-RAN node 602 may choose to switch a group of UEs to RRC INACTIVE state in order to relieve signalling load and reduce power consumption. Next, an RRCRelease message is sent in 1007 and the UE switches to RRC INACTIVE state in 1008 The network may trigger a multi cast pre-configuration message in 1010 (corresponding to later referred to step 1303 of Figure 13) where it includes the pre-configuration information elements needed to receive multicast data while in RRC INACTIVE state. The HE applies a cell reselection process in 1009 conforming to an enhanced cell reselection process with an additional reselection request message.

In a standard cell reselection procedure, the LIE performs measurement of signals from all neighbouring cells (gNBs). Then, based on the measurements and evaluation criteria, the UE selects the best candidate cell (gNB). If the selected cell (gNB) is not the current one (the cell the UE is camping in i.e. a source cell) then the UE changes to the new cell (a target cell).

In the enhanced cell reselection procedure, when a new cell is selected as best candidate by the UE, a reselection request message is sent by the UE to the source gNB (old cell) prior to changing cell. The reselection request message includes the target cell identification. On reception of the request message, the source gNB informs the target gNB that the UE will camp on the target cell (new cell) and is participating to a MBS session.

In an alternative embodiment the UE sends the reselection request message to the target gNB after changing the cell. In this alternative embodiment the reselection request message includes the NIBS session information.

As a result of the enhanced cell reselection process, the gNB knows the RRC INACTIVE UEs in the cell, these UEs have up to date system information and, as a result, the page, PRACH and (pre)-configuration request steps can be skipped. Further details of said enhanced cell reselection process can be found in UK patent application no. GB2205138.7.

For instance, the multicast pre-configuration context may include VIRB2 contexts, multicast configuration ID, associated G-RNTI, DRX configuration and neighbour cells multicast pre-configuration. The triggering event may depend upon the network establishment of the multicast pre-configuration context or the UE (601) portfolio. In a way of example, the 30 network may select the group of UEs candidate to receive while in RRC_INACTIVE state and thus, the selection triggers the multicast pre-configuration message. The multicast pre-configuration information in 1010 can use different container types. For example, RRC messages can be suitable to carry the multicast pre-configuration information in particular, the RRCRecontiguration or RRCRelease with SuspendConfig messages can be employed with additional fields locating the multicast pre-configuration context. The network can employ other alternatives, by a way of example, the multicast pre-configuration context can be sent in dedicated SIBs to pre-configure the UE 601 or a group of UEs for shared delivery.

The enhanced cell (re)selection is considered in Figure 10b wherein the HE (601) is in RRC_IN ACTIVE state 1008. The procedure 1009 is slightly different than for Figure 9 where a simple cell reselection 909 is applied without informing the NO-RAN node 602. Subsequently, the UE 601 has to request the multicast pre-configuration in 913 once it receives a notification (paging in 910) from the network.

In the enhanced cell reselection procedure in 1009, the HE 601 informs its arrival to the target NO-RAN node 900. Following this, UE context may be exchanged by way of example between the source NO-RAN node and the target NO-RAN node 900 including the UE capability and/or preference. The UE 601 can simply send its capability and/or preference and the relative G-RNTI of the target NG-RAN node in 1009. Thus, the target NG-RAN node may not need a prior exchange of HE context.

Target NO-RAN node 900 sends eventually the multicast pre-configuration to the UE in 601. The contents and the container types are as specified earlier in this section.

Other aspects of enhanced cell reselection may be considered in this embodiment. The UE 601 may send a reselection notification message in 1012 to the target gNB after a cell selection in 1011. The reselection notification may indicate the presence of UE (601) in the target cell and/or request a multi cast configuration from the target gNB (900). The 1012 notification message may include an NB3S session ID (e.g. TMGD. The notification message in 1012 may be sent in RRCResume Request message.

The target gNB in 900 receiving the 1012 message may proceed to UE context exchange 1013 with the source gNB 602 and then the admission control 1014 as described in the UK patent application no. GB2205138.7. The steps in 1013 and 1014 may be skipped if the pre-configured UE provides a proof of authorization in the 1012 message. The proof can be the G-RNTI of the target cell corresponding to the group of UEs receiving multicast data for an NIBS session ID. The target gNB 900 may then skip steps 1013 and 1014 and may send a reselection feedback in step 1015. The G-RNTI information may be associated to the MRS session ID, the multi cast configuration ID and/or to the cell ID in 1012 message. It may inform the target gNB if the HE (601) is allowed to receive multicast data. Furthermore, it may indicate if the UE has the authorization to receive multicast data for the corresponding NIBS session in RRC INACTIVE state.

The message 1015 may include a multicast (pre-)configuration to the HE or a simple rejection in case of no available authorization. The message container 1015 could be a RRCRelease with Suspendconfig including the configuration. A SIB message can be also employed.

Embodiments are now described which describe how the pre-configuration information received at a HE, according to any of the embodiments described herein, is used to configure a UP after session activation.

In one such embodiment, a multicast reception request can be sent by the UE upon the 10 MBS session activation, it triggers the gNB to send multicast data for UEs in RRC INACTIVE state. Furthermore, the UP may send a multicast reception feedback request to the gNB when receiving the first multi cast data in RRC IN ACTVE.

Figure 11 is a flowchart illustrating the use of the pre-configuration by the UE after the session is activated, according to an embodiment.

The UE in 601 is in RRC INACTIVE state 1102. Upon MBS session activation in 1104 and 1310, first multicast data arrive in 1105 to the NG-RAN node 602 and trigger a notification message. The notification message in 1106 can be a group paging message, a SIB or a dedicated RRC message. In this embodiment, and in a way of example the message in 1106 is a group paging message destined for the UP 601 in RRC INACTIVE state. The paging message 1106 may include the MBS session ID (e.g., TMGI), and a paging cause indicating the MBS session activation of the corresponding NIBS session as in 1408.

The UE 601 processes the paging message in 1107 (and 1409) and it may apply the multicast pre-configuration already sent previously by the network 602,603. A PRACH exchange procedure in 1108 is initiated by the HE 601 with the NO-RAN node 602, it allows to request uplink radio resources for future signalling message exchange with the NG-RAN node The steps in 1109 and 1113 depend upon the status of the HE 601 in 1107. The HE 601 may have been pre-configured previously by the NG-RAN node or may request pre-configuration or reception in RRC INACTIVE state. The example below states the possible messages to be carried in step 1109 and 1113 according to an embodiment In a first example, UE 601 may send a multicast reception request 1109 to the network. It aims at notifying the network of its presence and its willing to receive multicast data in RRC INACTIVE state. The network 602,603 processes the request 1109 in 1110 in order to send multicast data using MRB2 radio bearer. The request in 1109 may include the MBS session ID, the multicast pre-configuration ID and the G-RNTI, the network may then verify whether the UE in 601 has the authorization to receive multicast data and/or in RRC INACTIVE state. Following this, multicast data sent in 1111 may be sent to the UE (601) or to the group of candidate UEs in RRC INACTIVE state.

In a second example, the NG-RAN node in 602 may send multicast data using the multicast pre-configuration exchanged previously with the UE 601. The multicast data in 1112 is then received upon process paging stage in 1107. Later on, the feedback message in 1109 may be sent to inform the NC-RAN node that it is receiving in RRC INACTIVE state and thus, the NG-RAN node is informed and can continuously multicast the data in RRC INACTIVE state. The feedback message in 1109 may allow the gNB in 602 to estimate the number of UEs receiving in RRC INACTIVE state.

In a third example, the UE 601 is not yet pre-configured to receive an RRC INACTIVE state. Therefore, the paging message in 1106 indicates that as of now, the NIBS session is activated. Next, the UE 601 processes the paging in 1107 and may ask to be configured to receive multicast data in RAC INACTIVE state. Thus, it sends a multicast request in 1109 after interacting with the NO-RAN node 602 in the PRACH procedure 1108. The message in 1109 may request multicast configuration to receive in RRC INACTIVE state. The request in 1109 may include the MBS session ID, the multicast pre-configuration ID and the G-RNTI, the network may then verify whether the UE in 601 has the authorization to receive multi cast data and/or in RRC INACTIVE state. The network 602,603 processes the request in 1110 and responds with multicast configuration in 1113 sent back to the HE 601. The network may reject the request of the UE if no authorization is provided.

At the session activation 1104, 1310, the gNB may have pre-configured its UEs and needs to notify them in 1106 and 1315 of the session activation. It may send the configuration to unconfigured UEs in RRC INACTIVE state as in 1317 and 1113. The gNB may need to update or build the configuration in 1312. The configuration is then sent to the UEs in RRCTNACTIVE state as in 1 113 and 1314.

The HE in 601 may perform a simple cell (re)selection 1103 when in an RRC INACTIVE state. After the multicast MBS session activation 1104 and upon arrival of multicast data 1105, the target NG-RAN node in 900 may send a paging message 1106 with the corresponding multicast NIBS session ID (e.g., TMGI), and the paging cause indicating the multicast NIBS session activation status. The HE in 601 is then transparent to the target NGRAN node (900). While processing the paging message in 1107, UE 601 can apply the multi cast pre-configuration of the target NO-RAN node 900 if available, i.e., this information element figures in the neighbour cell multicast pre-configuration that could be communicated by the source NG-RAN node in 602 to the UE (601) at the moment of the multicast pre-configuration.

Thereafter, the UE 601 interacts with the target NG-R_AN node 900 in the PRACH procedure in 1108. After the PRACH procedure, different scenarios can be envisaged, including but not limited to the examples below.

In a first example, it is considered that the UE 601 has been pre-configured to receive multicast data in the target cell in 1107. Following the PRACH procedure in 1108, the UE 601 may send a multicast reception request in 1109 to activate the multicast reception in RRC INACTIVE state at the target NG-RAN node 900 if not yet done. The request in 1109 may include the MB S session ID, the multicast configuration ID and the G-RNTI, the network may then verify whether the UE in 601 has the authorization to receive multicast data and/or in RRC INACTIVE state. After processing the request 1109 in the network in 1110, the target NU-RAN node 900 may redirect the multicast data in 1111 for the HE 601 or the group of candidate UEs able to receive multicast data in RRC INACTIVE state.

In a second example, it is considered again that the UE 601 has applied a multicast pre-configuration in step 1107 and that the target NC-RAN node 900 is sending the multicast data 1112 through the MR132 radio bearer and earlier after the paging message 1106. The UE 601 may interact with the target NC-RAN node in 900 (PRACH procedure in 1108) and may send a multicast reception confirmation to the target NC-RAN node 900 as feedback in 1109. The target NG-RAN node processes the confirmation in 1110 and is aware of the presence of UEs receiving in RRC INACTIVE state. The feedback in 1109 may allow the gNB in 602 to estimate the number of UEs receiving in RRC INACTIVE state.

In a third example, the UE 601 may request multicast configuration to receive in RRC INACTIVE state in message 1109. The message in 1109 may include the MBS session ID, the multicast configuration ID and the G-RNTI, the network may then verify whether the HE in 601 has the authorization to receive multicast data and/or in RRC INACTIVE state. The target NG-RAN node 900 may process the request in 1110 and then, it may send the multicast configuration information 1113 dedicated for RRC INACTIVE multicast reception if available. After configuring the UE 601 to receive in RRC INACTIVE state, the target NC-RAN node sends the multicast data as in 1111. The target NG-RAN node 900 may send a reject response to the UE 601 and thus, no possible reception could occur in RRC INACTIVE state. The messages in 1109 and 1113 can use the RRC container message or a dedicated SIB message. The container type may not be limited to the RRC or SIB types.

In 1109, the RRC message can be RRCResume Request wherein the message includes additional field depending upon the different scenarios detailed above. The additional field may indicate different reasons as followed: - a multicast reception request to activate the multicast data transmission in RRC INACTIVE state - multicast feedback reception to confirm the presence of UEs receiving multicast data reception in RRC INACTIVE state - multi cast configuration request can be inserted in the additional field.

A SIB on demand can be employed also and may take different aspects according to the UE (601) request as listed here.

The message in 1113 is provided by the network 602, 603 and may be sent by RRC message such as RRCResume response or RRCRelease with SuspendConfig or RRCReconfigurati on messages. A dedicated SIB can be possible to carry the network response. Other container types not cited here may be used.

The additional field carried in the 1113 message can include the multicast configuration information to receive in RRC INACTIVE state as a response on multicast configuration request in 1109. It may include a rejection of the configuration request.

The different container types including RRC or SIB messages are exchanged in the context of RRC INACTIVE state with no required transition to RRC_CONNECTED state.

The additional fields type may identify the reason of the message and then, processes accordingly while remaining in RRC_INACTIVE state.

In another implementation, upon the NIBS session activation, the first multicast data arriving from the application server to the network may trigger MBS activation message sent 25 by the network to inform the UEs of the session activation. The UE may apply the multicast pre-configuration and multicast data is then received.

Figure 12 is a flowchart illustrating the use of the multicast pre-configuration information by the TIE after the session is activated, according to an embodiment.

The UE in 601 is in RRC INACTIVE state 1102. It is assumed that the TIE is pre-configured to receive multicast data in RRC INACTIVE state hereafter. Upon the MBS session activation in 1104, the multicast data in 1105 triggers an MBS activation message 1202, 1408 sent to the candidate UEs capable and pre-configured to receive multicast data in RRC INACTIVE state. The MBS activation message 1202 may use RRC container as for instance, a paging message with paging cause indicating the session activation or a SIB. The message in 1202 can be associated with a multicast configuration update. Thus, the 1202 message may include an update multicast configuration for the UE in 601 to receive in RRC INACTIVE state. The multicast configuration update in 1202 is sent via an RRC message.

The UE 601 receives the message in 1202 and applies its multicast pre-configuration in 1203 and 1409. If a configuration change is sent by the network, the UE in 601 may then apply the updated configuration. Thus, the TIE receives its first multicast data in 1204 while in RRC INACTIVE state.

At the multicast session activation 1104, 1310, the gNB may have pre-configured its UEs and need to notify them as in 1202 and 1315 of the multicast session activation. It may send the configuration to unconfigured UEs in RRC INACTIVE state as in 1317 and 1204. The gNB may need to update or build the configuration as in 1312, which will be described in more detail below with respect to Figure 13. The configuration is then sent to the UEs in RRC INACTIVE state as in 1204 of Figure 12 and 1314 of Figure 13.

The UE in 601 may perform an enhanced cell (re)selection in 1201 as illustrated in this scenario. In 1201, the enhanced cell (re)selection may involve the NO-RAN nodes 602, 900 in UE context exchange. In 1201, the UE in 601 informs the target NC-RAN node in 900 of its presence. As detailed before, the target NG-RAN node may exchange the UE context with the source NG-RAN node including the UE capability and/or preference to receive in RRC INACTIVE state by way of example. In another example, the UE may inform the target NO-RAN node 900 of its presence as well as its capability and/or preference without HE context exchange between NO-RAN nodes.

Furthermore, the UE 601 may send additional information related to the multicast configuration lD and/or the G-RNTI to the target gNB 900 during the enhanced cell reselection procedure 1201. The network may then verify the UE authorization regarding the reception of multicast data and/or in RRC INACTIVE state.

In case the source NC-RAN node has pre-configured the HE 601 to receive multicast data in RRC INACTIVE for neighbour cells, the target NO-RAN node is aware of the pre-configuration and will not proceed to pre-configure the UE 601.

In case the UE has to be pre-configured in the target cell, the target NC-RAN node 900 sends its proper multicast pre-configuration information within 1201 or later.

Upon the MBS session activation in 1104, the multicast data in 1105 issued by the application server in 1101 arrive in 1105 to the (target) NO-RAN node 602 or 900. Thereafter, the (target) NO-RAN node sends MBS activation notification in 1202 to the UE 601 before redirecting the multicast data in 1105. In 1203, the UE 601 may apply the multicast pre-configuration received earlier and may begin to receive multicast data 1204 in RRC INACTIVE state.

The reception of multicast data in the RRC INACTIVE state may offload the gNB (in other words the gNB will have less load to handle due to the UE being in the RRC INACTIVE state) and may promote additional UEs joining the MBS session. Thus, it is beneficial to consider the following = for a multicast session, according to an embodiment. The UE may stay in RRC INACTIVE state when: -At NIBS session activation. The UE may apply its (pre) configuration to receive data while staying in the RRC INACTIVE state - At NIBS deactivation. The UE may stop receiving multicast data, however, the session could be reactivated and later multicast data can be received.

When the 1\4BS session is released, no multicast data will be sent by the network and thus, the UE should return to the RRC CONNECTED state in order to release the radio resources used for receiving multicast data.

Figure 13 is a flow chart showing a process executed by a gNB 110 or 111 according to an embodiment. The process of Figure 13 is applicable to each of the embodiments already describe above. For example, the embodiments described in connection with Figures 6 to 12.

The execution may be performed by the CPU 315 of the base station shown in Figure 3, for example.

At step 1300, the gNB receives a UE join request 507, 605 such as that described with respect to previously described figures 5 and 6. Multicast session establishment 523, 606 is triggered by the first join request from a UE. The UE provides PDU session information, the core network provides multicast session information including QoS flow information. Subsequent join requests from UEs to the same multicast session will not trigger new multicast session establishment 523, 606 procedure, however the core network might update the multicast session QoS requirements, for example to manage the load globally in the system.

Then in step 1301 the gNB may decide to perform a radio resources reservation to reserve resources for sending the multicast data to UEs belonging to its cell. It is not mandatory to perform the resource reservation at this step because the multicast data is not yet available, it becomes available later at session activation step 524. Some gNBs might decide to wait on resources reservation until multicast data is available in order to leave radio resources available for other applications while the multicast session is inactive. As stated earlier, there is a risk of overloading the gNB is possible when needing to configure all involved UEs with the radio resources allocated simultaneously. Another risk is to fail the resource allocation because another application would have taken them earlier.

Therefore, in accordance with the embodiments, the gNB will not wait the session activation 524 to perform radio resource reservation, it will perform resource reservation when the number of involved UEs (for example the sum of two lists "unconfigured connected ue" plus "unconfigured inactive ue-) reached a configurable threshold "max number ue for simultaneous configuration". The threshold is representative of each gNB capacity to handle simultaneous configuration of a large group of -CIEs.

To manage the UE configuration, the gNB maintains in its memory 325 a set of UP identifier lists per multicast session: - "unconfigured_connected_ue: UEs in RRC_CONNECTED state that performed the join request - unconfigured_inactive_ue" UEs in RRC INACTIVE state that performed the join request - "pre-configured_connected ue": UEs in RRC CONNECTED state that performed the join request that received the pre-configuration information element.

-"pre-configured inactive ue": UEs in RRC INACTIVE state that performed the join request that received the pre-configuration information element - "configured connected ue" UEs in RRC CONNECTED state that performed the join request that received the configuration information element.

- "configured inactive ue": UEs in RRC INACTIVE state that performed the join request that received the configuration information element.

The identifier of each I_TE that performed a join request is stored in the list unconfigured connected ue".

If the core network sends an updated QoS requirement the gNB will update the UE lists as all previously pre-configured or configured UEs needs updated configuration information: - All UE identifiers in "pre-configured_connected_ue" and configured_connected_ue-are removed from list and added to "unconfigured connected ue" - All UE identifiers in "pre-configured_inactive_ue and "configured_inactive ue" are removed from list and added to "unconfigured inactive ue".

From radio resource reservation, the gNB is able to build a multicast pre-configuration information element The multicast (pre)-configuration information element may consider different information elements including but not limited to: - Multicast Radio Bearer "TVIRB2" configuration dedicated to receive multicast data with low QoS for candidate UEs, or "IVIRB1" configuration mainly addressed for UEs in RRC CONNECTED state with high QoS, - An RRC INACTIVE reception indication where the gNB indicates to the LTEs if they are enabled to receive multicast data in RRC INACTIVE state,. The absence of this indicator means that UE can receive by default multicast data in RRC INACTIVE state.

-G-RNTI identifying a group of LTEs within the same cell interested in receiving multicast data - Multicast pre-configuration ID referring to the configuration applied for UEs and associated with the MBS session ID (e.g., TMG1), - Discontinuous reception (DRX) configuration used to receive multicast data for candidate UEs - Neighbour cells multicast configuration applied when candidate UEs perform handover or cell resel ecti on - Cell ID(s) identifying the cell(s) in which the pre-configuration shall be applied.

At step 1302, the gNB sends sequentially the pre-configuration information elements to all UEs "unconfigured connected ue" list. The multicast pre-configuration information element can be sent in a RRC configuration message (e.g. Figure 6). The UE identifiers are removed from the "unconfigured connected ue" list and added to the "pre-configured connected ue" list.

At step 1303 the gNB will send the pre-configuration information element to UEs in 30 RRC INACTIVE state (e.g. Figure 9). The gNB sends a page message 910 to all UEs in the unconfigured_innactive_ue" and wait for a PRACH procedure 912 from UEs from the list that are still in the gNB's cell (some RRC IACTIVE UEs may have moved to another cell).

Once the PRACH procedure is done, the gNB receives Multicast pre-configuration request messages 913 from the UEs that performed the PRACH procedure. To these UEs the gNB sends a Multicast pre-configuration response message 914 with the multicast pre-configuration information element. In an alternative embodiment (e.g. Figure 10), UEs apply an enhanced cell reselection process, like that already described previously, that includes sending a notification to a base station associated with a new cell that may include information indicating which MB S sessions the UE is participating in/ so the gNB knows the RRC INACTIVE UEs in the cell. These UEs have up to date system information and page, PRACH and pre-configuration request can be skipped.

The UE identifiers are removed from the "unconfigured inactive ue" list and added to the pre-configured_inactive_ue list.

At step 1304 the gNB checks its requests to be a target gNB from a source gNB for the handover of a UE. In handover procedure a source gNB requests to handover the management of a UE to a target gNB. An example of handover is described in figure 7. The target gNB knows if the UE had joined the multicast session earlier, this information is part of the hand over information provided by the source gNB.

In step 1305 the target gNB checks if it has already reserved radio resources for the multicast session. If not, then the multicast pre-configuration information element is not ready and the UE identifier corresponding to the handed-over UE is added to the 6, unconfigured connected ue" list If multicast pre-configuration information element is available, then during step 1306 the target gNB will send the multicast pre-configuration information element to the handed over UE in a message 708. For example, the message in 708 may be sent in one or multiple RRC messages such as RRCReconfiguration message or dedicated System Information Blocks (SIB s) to the UE in 601.

During step 1307, the gNB may decide to switch some UEs from RRC CONNECTED state to RRC INACTIVE state. The goal is to lighten the load of the gNB as described in RP-213568 This is an example implementation of the embodiment described in Figure 8 During step 1308 the gNB checks if it has already reserved radio resources for the multicast session. If not, then the multicast pre-configuration information element is not ready and the UE identifiers corresponding to UEs going to change RRC state and that had joined the multicast session are removed from the "unconfigured_connected_ue" list and added to the unconfigured inactive ue" If a multicast pre-configuration information element is available, then during step 1309 the gNB sends the multicast pre-configuration information element to the UE in the RRCRelease with SuspendConfig message 807. To this end, the NG-RAN node 602 may use RRCRelease messagewith SuspendConfig in 807 with an amendment of its content. Additional fields related to the multicast pre-configuration context (information element) can be included and thus, the candidate UE in 601 performs its transition to RRC INACTIVE state 808 and is aware that by then, it is pre-configured to receive multicast data while remaining in RRC INACTIVE state.

The gNB cycles back to step 1300 until the multicast session is activated. Then it moves to step 1310.

During step 1310 the gNB receives multicast session activation information 512.

Then during step 1311 the gNB checks whether multicast pre-configuration information element is ready.

If the multicast pre-configuration element is not ready or if the QoS flow information is updated, then in step 1312 the gNB updates or performs the radio resource reservation, the gNB creates or updates the pre-configuration information element. Then the gNB converts the multicast pre-configuration information element in a multicast configuration information element (as described TS 38.331).

Then during step 1313 the gNB will send the multicast configuration information element to all UEs in "unconfigured_connected_ue" and "pre-configured_connected_ue" and "configured connected ue" lists. Similar to step 1302, the multicast configuration information element is sent in an RRCReconfiguration message. All LIE identifiers of unconfigured_connected_ue" and "pre-configured_connected_ue" are moved to configured connected ue" list.

Then during step 1314 (e.g. Figure 11), the gNB sends a page message with paging cause set to "NIBS session activation" (like suggested in TR23.700-47). Then UEs that are present in the cell, that are in RRC INACTIVE state and that had joined the multicast session will perform a PEACH procedure to update their system information, then the UEs will send a Multicast MBS configuration request message (MBSConfigurationRequest or MBSConfigurationRequestl). The MBS configuration request message may be a new RRC message or a RRCResumeRequest message or a System Information Block (SIB) reception request. The multicast NIBS configuration request message may include an identifier for identifying the activated multicast session (e.g. MBS session id and/or Temporary Mobile Group Identity (TMGI)). In other words, an identifier for indicating the MISS session the configuration is requested for. In addition, the multicast NIBS configuration request message may include TIE identity information for identifying the TIE 101, such as IMSI IMIEI, and/or Authentication information (ueMAC-I), such as an authentication token, for use in authenticating the UP 101. Upon reception of the multicast NIBS configuration request message, the gNB will send an NIBS configuration message (MBSConfiguration) with the multicast configuration information element to the TIE. The multicast MBS configuration request message which may include gathering or obtaining the necessary information to build the UP configuration for the at least one UP so the at least one UP can receive multicast data for the activated multicast session. Once the TIE configuration is known (including the step of Radio Access Network (RAN) resource reservation), the base station or gNB 111 sends a multicast NIBS configuration message to the at least one UE. The multicast NIBS configuration message includes configuration information for configuring the at least one TIE for reception of multicast data in a non-connected RRC state, such as RRC INACTIVE state, for the activated multicast session. In an example, the configuration information includes configuration information of at least one Multicast Radio Bearer, MRB (e.g. configuration of at least one MRB to be used by the gNB 111 and the at least one UP 101 for communication of the multicast data for the activated multicast session). It is noted that one or more NIRBs can be associated to one NIBS session. The MRB configuration information may include Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP) setup information.

The MBS configuration message is sent to the at least one UE by the base station (e.g. source or serving base station) controlling the cell where the UP is camped and is sent in response to receiving the MBS configuration request message from the at least one TIE. The NIBS configuration message may be a RRCReconfiguration message or a RRCRelease with suspend configuration message or a RRCResume message or a SIB message.

Further details of the multicast configuration request message and multicast NABS configuration message can be found in United Kingdom patent application number GB2210307.1. In an alternative embodiment, UEs apply the enhanced cell reselection process as previously described, so the gNB knows the RRC INACTIVE UEs in the cell, these UEs have up to date system information and the page, PRACH and pre-configuration request can be skipped Each time a UE sends a Multicast Configuration Request Message the gNB adds the corresponding UE identifier to the "configured inactive ue" list and removes it from "unconfigured inactive ue" and "pre-configured inactive ue" list if it is present.

Back to step 1311, if the multicast configuration information element is ready and the QoS flow information is not changed, then during step 1315 the gNB sends a page message with paging cause set to "apply pre-configuration" to all TIE identifier present in "preconfigured_connected_ue" and "pre-configured_inactive_ue" lists. So, all UEs that had previously received the multicast pre-configuration information element will be able to apply this configuration and receive the multicast data. Then all UE identifiers are removed from "pre-configured_connected_ue" and added to "configured_connected_ue-. Similarly, all UE identifiers are removed from "pre-configured_inactive ue and added to "configured inactive ue".

Then the gNB will configure the UEs that had remained unconfigured as reflected in unconfigured_inactive_ue" and "unconfigured_connected_ue". The gNB converts the Multicast pre-configuration information element to a multicast configuration information element.

During step 1316 the gNB will send the multicast configuration information element to all UEs in "unconfigured_connected_ue. Similar to step 1302, the multicast configuration information element is sent in an RRCReconfiguration message. All UE identifiers of unconfigured connected ue are moved to "configured connected ue" list.

Then during step 1317, the gNB sends a page message with paging cause set to "MBS session activation" (as suggested in TR23.700-47). Then UEs that are present in the cell, that are in RRC INACTIVE state and that had joined the multicast session and have not a pre-configuration information element will perform a PRACH procedure to update their system information, then the UEs will send a Multicast configuration request message (MBSConfigurationRequest or MBSConfigurationRequestl) and the gNB will send a MBS configuration message (MBSConfiguration) with the multicast configuration information element. Further details of the multicast configuration request message and NIBS configuration message can be found as described previously herein and in United Kingdom patent application number GB2210307.1. In an alternative embodiment, UEs apply cell reselection process conform to the enhanced cell reselection process already described above, so the gNB knows the RRC INACTIVE UEs in the cell, these UEs have up to date system information and page, PRACH and pre-configuration request can be skipped.

Each time a UE sends a Multicast Configuration Request Message the gNB adds the corresponding UE identifier to the "configured inactive ue" list and removes it from unconfigured inactive ue" list if it is present.

Once the multicast session is activated the gNB behaves as described in TS 23.247.

Figure 14 is a flow chart showing a process performed by a UE 101 according to an embodiment. Similar to Figure 13, the process shown in the flowchart of Figure 14 is applicable to each of the embodiments already described above. For example, the embodiments described in connection with Figures 6 to 12. The execution may be performed by the CPU 215, for example.

First at step 1400 the UE is in RRC CONNECTED state, it performs a join procedure 523,605 to join a multicast session.

Next during step 1401, the UE waits a multicast pre-configuration message (including multicast pre-configuration information) from the gNB. The multicast pre-configuration message can be sent by the gNB as a modified RRCReconfiguration message at step 1302 (e.g Figure 6), or at step 1306 after a handover procedure (e.g. Figure 7), or a step 1309 as part a modified RRCRelease message with SuspendConfig. If a multicast pre-configuration information element is received, then the UE stores it in the memory 225 If the UE is still in RRC CONNECTED state then test 1402 indicates no offload.

If the UE is now in RRC INACTIVE state after having received either a standard RRCRelease message or a modified RRCRelease message, the test 1402 indicated offload.

If the UE is in RRC INACTIVE state (1402 indicates yes), then during step 1403, the UE waits the reception of a multicast pre-configuration message from the gNB. The multicast pre-configuration message can be sent by the gNB at step 1303 (e.g. Figure 9). At step 1303 the gNB sends a page message 910 with multicast pre-configuration cause, then UE initiates a PRACH procedure and send a Multicast pre-configuration request messages 913 to the gNB.

Then the gNB sends back a Multicast pre-configuration response message 914 with the multicast pre-configuration information element. In an alternative embodiment (e.g. Figure 10), UEs apply cell reselection process conforming to the enhanced cell reselection process already described above, so the gNB knows the RRC INACTIVE UEs in the cell, these UEs have up to date system information and page, PRACH and pre-configuration request can be skipped. When the UE is in RRC INACTIVE state it cycles back to step 1403 until the multicast (MBS) session is activated at step 1404. When the multicast session is activated in 1404, the UE may have or may not have a multicast session pre-configuration information element stored in the memory 225.

In step 1405, the UE waits for a page message from the gNB (step 1315) with "apply pre-configuration" paging cause. If the page is received then during test 1406, the UE checks if it got a multicast pre-configuration information element stored in memory 225. If yes, then during step 1407 the UE applies the relevant configuration from the pre-configuration information and is now able to receive the multicast data.

If the UE does not have a stored pre-configuration then it cycles back to step 1405. Back to step 1405, if the received page message does not include the "apply pre-configuration" paging cause, then during test 1408, the UE checks for the -MBS session activation" paging cause.

If the "MBS session activation" paging cause is not included in the page message then the UE cycles back to step 1405, waiting for a new page message.

If the "MBS session activation" paging cause is included, then during step 1409, the UE will request the multicast configuration information element from the gNB even if it already got a stored pre-configuration (the configuration have been updated at gNB side, the UE stored pre-configuration is obsolete).

The gNB sends the "MBS session activation" paging cause at step 1314 or 1317 (corresponding to figure 11), the gNB sends a page message with paging cause set to "NIBS session activation" (like suggested in TR23.700-47). Then UE performs a PRACH procedure to update its system information, then the UE will send a Multicast configuration request message (MB SConfigurationRequest or MBSConfigurati onRequest I) and the gNB will send a MBS configuration message (IVIBSConfiguration) with the multicast configuration information element. Further details of the multicast configuration request message and MISS configuration message can be found as described previously herein and in United Kingdom patent application number GB2210307.1. In an alternative embodiment, UE apply cell reselection process conform to the enhanced cell reselection process already described above, so the gNB knows the RRC INACTIVE UEs in the cell, these UEs have up to date system information and page, PRACH and pre-configuration request can be skipped.

Once it receives the MB S configuration message, the UE applies the configuration and it is ready to receive the multicast data.

That concludes the RRC INACTIVE part. Back to the RRC CONNECTED part ('no' to condition tested in 1402), When the UE is in RRC_CONNECTED state it cycles back to step 1401 until the MBS session is activated at step 1410. When the multicast session is activated in 1410, the UE may have or may not have a multicast session pre-configuration information element stored in the memory 225.

In step 1411, the UE waits a page message from the gNB (step 1315) with "apply pre-configuration" paging cause. If the page is received then during test 1412, the UE checks if it got a multicast pre-configuration information element stored in memory 225. If yes, then during step 1413 the UE applies the relevant configuration from the pre-configuration information and is now able to receive the multicast data.

If the UE does not have a stored pre-configuration then it cycles back to 1411.

At 1411, if the received page does not include the "apply pre-configuration" paging cause, then during test 1414, the UE checks for the reception of a standard RRCReconfiguration message from the gNB.

If the RRCReconfiguration message is not received then the UE cycles back to step 1411, waiting for a new page or RRC message.

If the RRCReconfiguration message is received, then during step 1415, the UE will apply the configuration as received even if it already got a stored pre-configuration (the configuration has been updated at gNB side, the UE stored pre-configuration is obsolete). The gNB sends the RRCReconfiguration message at step 1316 or 1313.

Figure 17 is a flow chart illustrating the update of configuration initiated by the network for UEs in RRC INACTIVE state according to an embodiment.

Figure 17 shows a HE in 601 having joined the multicast MBS session in 605 while in RRC CONNECTED state 604, and that has been switched by the network to the RRC INACTIVE state at step 1701.

The UE 601 continuously performs the cell reselection process 1702 to search for the best cell to camp. While moving the UE may have switched cell several times since it is in RRC INACTIVE state.

At the same time, the multicast MBS session has been activated and the NO-RAN node 1700 is transmitting the multicast data 1704 in the cell where the UE 601 is now camping. It is assumed that the UE 601 has obtained the multicast configuration to be able to receive the multicast data in this cell, for instance, before the NIBS session activation using the method of Figure 9 or according to any of the other preceding embodiments where (pre-)configuration information is received before MBS session activation. The NO-RN node 1700 controlling the cell where the UE 601 is camping may not be aware of the presence of the UE 601 in the cell controlled by the NO-RAN node 1700.

In a case where the NG-RAN node 1700 has detected that a modification of the multicast configuration is necessary to receive multicast data in the cell(s) it controls in the NIBS service area, or if the NG-RAN node 1700 has been notified of a modification of the multicast configuration in cell(s) controlled by another NO-RAN node, then the NO-RAN node 1700 may initiate an update of the multicast configuration for the UEs interested in receiving the corresponding MBS session. For the UEs in RRC CONNECTED state, the NO-RAN 1700 will use a RRCReconfiguration message to provide the update. For the UEs in RRC INACTIVE state, the NO-RAN node 1700 may first send a notification 1705 in the cell(s) it controls in the MBS service area. This notification may be a group paging message indicating the multicast session id and indicating that the purpose is the availability of multicast configuration(s).

The UE 601 receiving the notification 1705 will process the provided information at step 1703. If the multicast session ID corresponds to the session the UE 601 is interested in, the UE 601 executes a PRACH exchange procedure 1706 with the NG-RAN node 1700. In 1706, the UE 601 communicates its TIE identity with the NO-RAN node and requests uplink radio resources for L2/L3 messages and RRC connection messages. Next, the UE 601 sends a multicast configuration request message 1707 to the NO-RAN node 1700. The message 1707 may be a ARC Resume Request (specified in TS 38.331) including the multicast session ID and indicating that the request for reception of multicast configuration(s). This message also includes the identification of the UE in RRC INACTIVE state (i.e. I-RNTO and the identification of the NC-RAN node that set the UE 601 in RRC INACTIVE state and allocated the I-RNTI to the UE 601.

The NO-RAN node 1700 verifies that the LIE has joined the MBS session and it is authorized to receive the associated multi cast data. For this purpose, the NC-RAN node 1700 will perform the UE context exchange procedure 1711 with the NO-RAN that set the HE 601 in RRC INACTIVE state, to retrieve the context of the UE 601. Then, the NO-RAN node 1700 executes the admission control step 1712 to verify that the UE 601 is allowed to receive the multi cast data according to the received UE context. If the request of UE 601 is accepted, the NO-RAN node sends multicast configuration(s) within the message 1708 to the UE 601. The target NG-RAN node may reject the request while indicating the reject cause.

The multicast configuration message 1708 may be the RRC Release with SuspendConfig message (specified in TS 38.331) and containing one or several multicast configurations to be used in one or several cells in the neighborhood. A multicast configuration may be identified by a multicast configuration ID. A mapping between the multicast configuration ID and the cell identity where the multicast configuration can be applied shall be provided to the UE.

In order to avoid the steps 1711 and 1712, the UE may include in the request message 1707 the G-RNTI it is using to decode the received multicast data. By providing this G-RNTI the NG-RAN node 1700 can assess that the UE 601 is an authorized UE and the NG-RAN 1700 can provide the multicast configurations.

During all the procedure described at the figure 17, the UE 601 can remain in RRC INACTIVE state and can continue receiving the multicast data.

Figure 18 is a flow chart showing illustrating the sending of configuration requested by a UE in RRC INACTIVE state according to an embodiment.

Figure 18 shows a UE in 601 having joined the multicast MBS session in 605 while in RRC CONNECTED state 604, and that has been switched by the network to the RRC INACTIVE state at step 1801.

The UE 601 continuously performs the cell reselection process 1802 to search for the best cell to camp. While moving the HE may have switched cell several times since it is in RRC INACTIVE state.

At the same time, the multicast NIBS session has been activated and the NO-RAN node 1800 is transmitting the multicast data 1804 in the cell where the UE 601 is now camping. It is assumed that the UE 601 has obtained the multicast configuration to be able to receive the multicast data in this cell, for instance, before the MBS session activation using the method off igure 9 or according to any of the other preceding embodiments where (pre-configuration information is received before MBS session activation. The NO-RN node 1800 controlling the cell where the UE 601 is camping may not be aware of the presence of the UE 601 in the cell controlled by the NO-RAN node 1800.

When performing the cell reselection process 1802, the HE 601 may detect one or several cells in the MBS service area for which the UE 601 does not have the multicast configuration to receive the multicast data in RRC INACTIVE state.

The UE 601 may then request the missing multicast configuration(s) to the NO-RAN node 1800. For this purpose, the UE 601 executes a PRACH exchange procedure 1806 with the NO-RAN node 1800. In 1806, the UE 601 communicate its UE identity with the NO-RAN node and requests uplink radio resources for L2/L3 messages and RRC connection messages.

Next, the UE 601 sends a multicast configuration request message 1807 to the NO-RAN node 1800. The message 1807 may be a RRC Resume Request (specified in TS 38.331) including the multicast session ID and indicating that the request for reception of multicast configuration(s), and indicating the identity of the cell(s) for which the multicast configuration(s) is/are requested. This message also includes the identification of the UE in RRC INACTIVE state (i.e. I-RNTI) and the identification of the NO-RAN node that set the UE 601 in RRC INACTIVE state and allocated the I-RNTI to the UE 601.

The NO-RAN node 1800 verifies that the UE has joined the MBS session and it is authorized to receive the associated multicast data. For this purpose, the NO-RAN node 1800 will perform the UE context exchange procedure 1811 with the NO-RAN that set the UE 601 in RRC INACTIVE state, to retrieve the context of the UE 601. Then, the NO-RAN node 1800 executes the admission control step 1812 to verify that the UE 601 is allowed to receive the multicast data according to the received UE context. If the request of UE 601 is accepted, the NO-RAN node sends the requested multicast configuration(s) within the message 1808 to the UE 601. The target NO-RAN node may reject the request while indicating the reject cause.

If the NO-RAN node 1800 does not have a multicast configuration, it may request them to the NO-RAN node(s) controlling the cell(s) for which the UE 601 requested the multicast configuration. Such information may be performed through the exchange Xn protocol messages.

The multicast configuration message 1808 may be the RRC Release with SuspendConfig message (specified in TS 38.331) and containing the requested multicast configuration(s), at least for the multicast configuration known at the NO-RAN node 1800. In order to avoid the steps 1811 and 1812, the UE 601 may include in the request message 1807 the G-RNTI it is using to decode the received multicast data. By providing this G-RNTI the NO-RAN node 1800 can assess that the UE 601 is an authorized UE and the NG-RAN 1800 can provide the multicast configurations.

During all the procedure described at the figure 18, the UE 601 can remain in RRC INACTIVE state and can continue receiving the multicast data.

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 MBSPreCoqfiguration corresponds to the multicast (NIBS) pre-configuration information discussed above.

The purpose of this procedure is to allow for sending of pre-configuration data to a UE prior to session activation which can be used to subsequently configure the UE to receive multicast data from a base station in a network. The pre-configuration, multicast reception procedure, and multicast reception request procedure is described below and shall have a definitive numbering later, for the moment they are each referred to by the numbering 5.3.X.

An implementation of the MBSConfigurationRequest, MBSConfigurationRequestl and MBSConfiguration request messages, referred to in certain embodiments above, is described in detail below.

5.3.2.3 Reception of the Paging message by the UE 1> for each IMG/ included in pagingGroitpList, if any, included in the Paging message: 2>if the UE has joined an MBS session indicated by the 1A1G1 included in the pagingGroupList: 3> forward the TAIGI to the upper layers; 1> if in RAC INACTIVE and the UE has joined one or more NIBS session(s) indicated by the MCI included in the page ngGroupList; and 1> if none of the tie-Identity included in any of the PagingReconi, if included in the Paging message, matches the UE identity allocated by upper layers: 2> If MBS session activation is included in the paging cause 3> Initiate the RRC INACTIVE multicast reception procedure according to 5.3.X (e.g. as discussed with reference to Figures 6-10 and/or discussed below in the discussion 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) 2> Else initiate the RRC connection resumption procedure according to 5.3.13 with resumeGartse set as below: 3> if the UE is configured by upper layers with Access Identity 1: 4> resumeemise is set to mps-PriornyAccess; 3> else if the UE is configured by upper layers with Access Identity 2: 4>resumeCause is set to mcs-PriorilyAccesks; 3> else if the UE is configured by upper layers with one or more Access Identities equal to 11-15: 4> resumeCause is set to highPriorilyAccess; 3> else 4> resumeCause is set to int-Access.

2> If multicast pre-configuration is included in the paging cause 3> Initiate the RRC INACTIVE pre-configuration request 2> Else initiate the RRC connection resumption procedure according to 5.3.13 with resznneCause set as below: 3> if the UE is configured by upper layers with Access Identity 1: 4> re.smneCause is set to mps-Prior tyAccess; else if the UE is configured by upper layers with Access Identity 2: 4> restnneCause is set to incs-PriorityAccess; 3> else if the UE is configured by upper layers with one or more Access Identities equal to 11-15 4> re.smneCause is set to highPriorityAccess; 3> else: 4> re.smneCanse is set to nn-Access.

5.3.X Multicast pre-configuration request procedure 5.3.X I General Figure 5.3.X.1-1 Multicast pre-configuration request The purpose of this procedure is to setup multicast reception in RRC INACTIVE state including multicast MRB(s).

5. 3.X 2 Initiation The UE initiates the procedure when upper layers or AS (when responding to RAN paging) requests the reception of Multicast in RRC INNACTIVE state.

The UE shall ensure having valid and up to date essential system information as specified in clause 5.2.2.2 before initiating this procedure.

Upon initiation of the procedure, the UE shall: 1> if the resumption of the RRC connection is triggered by response to NC-RAN paging: 2> select '0' as the Access Category.

2> perform the unified access control procedure as specified in 5.3.14 using the selected Access Category and one or more Access Identities provided by upper layers 3> if the access attempt is barred, the procedure ends.

5.3.X 3 Actions related to transmission of MRSPreConfigRequest or MBSPimessage guest] The UE shall set the contents of IlitaST reCont igReque,s1 message. 5.3.X 4 Reception of the MRSPreConfiguration by the 111-E, The UE shall: 1> if the RRCRe.sitine includes the radioBearerCotifigi 2> perform the radio bearer configuration according to 5.3.5.6.

6.2.2 Message definitions MRSTreConfigRequest The MESPreCon i Re test messa e is used t uest the re-confi ration for the reception of multicast in RRC INACTIVE state.

Signalling radio bearer: SRBO RLC-SAP: TM Logical channel: CCCH Direction: UE to Network MRS PreConfigurationRequest message - ASN1START - TAG-MBSPreCONFIGURATIONREQUEST-START MB SPreContigurationRequest::= SEQUENCE mbsPreConfigurationRequest MBSPreCconfigurationRequest-IEs NB3SPreConfigurationRequest-lEs::= SEQUENCE ueIdentity ShortI-RNTI-Value uelMAC-I BIT STRING (SIZE (16)), multicastSessionId MulticastSessionId G-RNTI-r17 RNTI-value OPTIONAL spare BIT STRING (SIZE (1)) o re

TU

- TAG-MBSPreCONFIGURATIONREQUEST-STOP

- ASN I STOP

MBSPreConfimurafionRequest-IEs field descriptions

nuilticastSessionM Indicates which MBS session the pre-configuration is requested for ueldentitE UE identity to facilitate UE context retrieval at gNB.

ueMAC-I Authentication token to facilitate UE authentication at gNB. The 16 least significant bits of the MAC-I calculated using the AS security configuration as specified in 5.3.13.3.

G-RNTI

The group ID of multiple UEs receiving in PTM mode AIBSPreConfiguralion The A413SPreConfiguration messaoe is used to setup the reception of multicast in RRC INACTIVE state.

Signalling radio bearer: SRB1 RLC-SAP: AM Logical channel: DCCH Direction: Network to UE MBSPreConfiguration message --A SN1START TAG-MBSPreCONFIGURE-START MBSPreConfigure::= SEQUENCE 1 rrc-TransactionIdentifier RRC-TransactionIdentifier criticalExtensions CHOICE 1 MBSPreConfigure MB SPreC onfi gure-IEs criticalExtensionsFuture SEQUENCE {} MB SPreConfigure-lEs:= radioBearerConfig MBS-DRX-PreConfig OPTIONAL, SEQUENCE RadioBearerConfig OPTIONAL, --Need M MBS-DRX-Config Multicast pre-configuration identity OPTIONAL G-RNT1-117 RNT1-value Multicast pre-configuration identity

OPTIONAL

RRC INACTIVE-reception-Indicator Boolean OPTIONAL

SEQUENCE

Cell Indentity RadioBearerConfig OPTIONAL, --Need M MBS-DRX-Config Multicast pre-configuration identity RNT1-value OPTIONAL Boolean - TAG-N/BSPreConfiaure-STOP - ASN1STOP

RRCResurne-IEs field descriptions

radioBearerConfle Configuration of Radio Bearer2 (MRB2) including SDAP/PDCP MBS-DRX-PreConfle DRX configuration to receive multi cast data Cell Identity The neighbour cell identity Multicast preeon figuration identity MB SPreConfi aure1-1 Es * = CellIndentity radioBearerConfig MBS-DRX-PreConfig ;OPTIONAL ;Multi cast pre-configuration identity OPTIONAL G-RNT1-117 RRC INACTIVE-reception-Indicator ;OPTIONAL ;The multicast pre-configuration identity associated to an NIBS session identity ;G-RNTI ;The group ID of multiple UEs receiving in PTM mode RRC INACTIVE reception indicator-optional RRC IN ACTIVE multi cast reception -Boolean MBSPreConfiguration message RRCRelease-v1650-IEs::= SEQUENCE mpsPrioritvIndication-r16 ENUMERATED I true} OPTIONAL Cond Redirection2 radioBearerConfig RadioBearerConfig OPTIONAL, --Need M MBS-DRX-PreConfig MBS-DRX-Config ;OPTIONAL ;MB SPreConfigurel-IE s * = SEQUENCE ( Indentity, CellIndentity Cell rad oBearerConfig RadioBearerConfig OPTIONAL --Need NI MBS-DRX-PreConfig MBS-DRX-Config

OPTIONAL

NIulticast pre-configuration identity NIulticast pre-configuration identity

OPTIONAL

G-RNTI-ii 7 RNTI-value OPTIONAL RRC INACTIVE-reception-Indicator Boolean OPTIONAL

RRCRelease-IEs field descriptions

With Suspend Config: radioBearerCon fig Configuration of Radio Bearer2 (MRB2) including SDAP/PDCP.

MBS-DRX-PreConfig DRX configuration to receive multicast data Cell Identity The neighbour cell identity Illulticast precon figuration identity The multicast pre-configuration identity associated to an NIBS session identity

G-RNTI

The group ID of multiple UEs receiving in PTM mode RRC INACTIVE reception indicator-optional RRC INACTIVE multicast reception -Boolean 5.3.X Multi cast reception procedure 5.3.X. I General Figure 5.3.X.1-1 Multicast reception request The purpose of this procedure is to setup multicast reception in RRC INACTIVE state, including multicast MRB(s).

/nit/at/on The UE initiates the procedure when upper layers or AS (when responding to RAN paging) requests the reception of NIulticast in RRCUNACTIVE state.

The TIE shall ensure having valid and up to date essential system information as specified in clause 5.2.2.2 before initiating this procedure.

Upon initiation of the procedure, the UE shall: 1> if the resumption of the RRC connection is triggered by response to NG-RAN paging: 2> select '0' as the Access Category; 2> perform the unified access control procedure as specified in 5.3.14 using the selected Access Category and one or more Access Identities provided by upper layers; 3> if the access attempt is bared, the procedure ends; Actions related to transmission of 11,113SConfigRequest or AIKS'ConfigRequestl message The LIE shall set the contents of A4BSC:coulgRequest or MBSConfigRequest 1 message as 25 follows: 1> if field iiseFullResitmeID is signalled in SIB]: 2> select MBSCoiy?gRequestl as the message to use; 2> set the ueldentity to the storedfullTRATI value; 1> else: 2> select AlBSCotiligRequest as the message to use; 2> set the iteldentity to the stored shortl-RNTI value; 1> re-establish PDCP entities for SRBI; 1> resume SRB I; 1> submit the selected message MBSConfigRequest or AIBSConfigReguest 1 for transmission to lower layers.

Reception of MBSCon by the UE The UE shall: 1> if the RRCResume includes the radioBearerCotrfig: 2> perform the radio bearer configuration according to 5.3.5.6; Message definitions AlBSConf igRequest The AIBSCoqfigRequest message is used to request the configuration for the reception of multicast in RRC INACTIVE state.

Signalling radio bearer: SRBO RLC-SAP: TM Logical channel: CCCH Direction: TIE to Network MBSConfigurationRequest message

- ASNISTART

- TAG-MBSCONFICURATIONREQUEST-START

MBSConfigurationRequest::= SEQUENCE { mbsRConfigurationRequest MBSCconfigurationReguest-IEs MBSConfigurationRequest-IEs::= SEQUENCE { ueIdentity ShortI-RNTI-Value, ueMAC-I BIT STRING (SIZE (16)), multicastSessionId MulticastSessionId, spare BIT STRING (SIZE (1)) - TAG-MBSCONFIGURATIONREQUEST-STOP - ASN1STOP

MBSConfikurationRequest-!Es field descriptions

multicastSessionId ueldentitv UE identity to facilitate LTE context retrieval at gNB.

ueMAC-I Authentication token to facilitate HE authentication at gNB. The 16 least significant bits of the MAC-I calculated using the AS security configuration as specified in 5.3.13.3.

- MBSConfigurationRequest The AlBSConfigurationRequest I message is used to request the configuration for the reception of multicast in RRC INACTIVE state.

Signalling radio bearer: SRBO RLC-SAP: TM Logical channel: CCCH1 Direction: HE to Network MBSConfigurationRequestl message

MRSCnnfigurationRequestl-IEs field descriptions

multicastSessionId Indicates which MBS session the configuration is requested for.

ueIdentity UP identity to facilitate UP context retrieval at gNB.

ueMAC-1 Authentication token to facilitate UP authentication at gNB. The 16 least significant bits of the MAC-I calculated using the AS security configuration as specified in 5.3.13.3.

- ASN1START - TAG-MBSCONFIGURATIONREQUEST1-START MBSConfigrationRequestl mbsConfigurationReque s tl SEQUENCE { MBSConfigurationRequestl-IEs MBSConfigurationRequestl-IEs ueIdentity ueMAC-I multicastSessionId spare : SEQUENCE { I-RNTI-Value, BIT STRING (SIZE (16)), TMGI-R17, BIT STRING (SIZE (1)) - TAG-MBSCONFIGURATIONREQUEST1-STOP - ASN1STOP 15 20 25 MRSIConfiguration The AIB,Sronfiguration message is used to setup the reception of multicast in RRC INACTIVE state.

Signalling radio bearer: SRB1 RLC-SAP: AM Logical channel: DCCH Direction: Network to UE MBSConfieuration message 5.3.X Multicast reception request procedure 5.3.X I General Figure 5.3.X.1-1 Multicast reception request The purpose of this procedure is to setup multicast reception request in RRC INACTIVE state including multicast NIRB(s).

5.3.X 2/nit/at/on The HE initiates the procedure when upper layers or AS (when responding to RAN paging) requests the reception of Multicast in RRC INNACTIVE state.

SEQUENCE { - ASN1START

- TAG-MBSCONFIGURE-START

MBSConfigure SEQUENCE { RadioBearerConfig MBSConrigure-IEs radioBearerConfig OPTIONAL, --Need M - TAG-MBSConfigure-STOP

- ASNISTOP

radioBearerConfig Configuration of Radio Bearer (N1RB) ncluding SDAP/PDCP.

rro-TransactionIdentifier criticalExtensions MBSConfigure criticalExtensionsFutore RRC-TransactionIdentifier, CHOICE { MBSConfigure-IEs, SEQUENCE {)

RRCResume-lEs field descriptions

15 20 25 The UE shall ensure having valid and up to date essential system information as specified in clause 5.2.2.2 before initiating this procedure. Upon initiation of the procedure, the UE shall: 1> if the resumption of the RAC connection is triggered by response to NG-RAN paging: 2> select '0' as the Access Category 2> perform the unified access control procedure as specified in 5.3.14 using the selected Access Category and one or more Access Identities provided by upper layers; 3> if the access attempt is barred, the procedure ends ATBSReceptionRequest The All3SReceptionRequest message is used to request the reception of multicast data in RRC INACTIVE state.

Signalling radio bearer: SRBO RLC-SAP: TM Logical channel: CCCH Direction: UE to Network MRS'ReceptionRequest message - ASN1START TAG-N4BSRECEPTIONREQUEST-START MBSReceptionRequest::= SEQUENCE I mbsReceptionRequest MBSReceptionRequest-IEs MBSReceptionRequest-lEs::= SEQUENCE ueidentity ShortI-RNTI-Value ueMAC-I BIT STRING (SIZE (16)) multicastSessionId MulticastSessionId spare BIT STRING (SIZE (0)

- TAG-MBSRECEPTIONREQUEST-STOP

- ASN1STOP

MBSReceptionRequest -IEs field descriptions

nudticastSessionM Indicates which MBS session the reception is requested for ueldentitv UE identity to facilitate UE context retrieval at gNB.

ueMAC-I Authentication token to facilitate TIE authentication at gNB. The 16 least significant bits of the MAC-I calculated using the AS security configuration as specified in 5.3.13.3.

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, EEPRON4, 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.

The present invention provides a multicast pre-configuration information for the multicast session according to some aspects hereafter described.

In Release 17, the NIBS multicast session follows state transitions as defined in 3GPP TS 23.247 v17.3.0, figure 4.3-1. The session management procedures include session creation (7.1.1.2 or 7.11.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). It is only when the NIBS session is established that the network will configure the UE for the reception of multicast data.

The establishment of an NIBS session in a UE is performed when the UE is in RRC CONNECTED state. Then, the network may decide to switch the UE to RRC INACTIVE state before the MBS multicast data are available through the session activation. When the session is activated the network will have to notify the UEs that have joined the session, and the network will have to switch the UEs that are in ARC INACTIVE state to ARC CONNECTED state to configure them.

As a first observation, the Release 17 specifications do not provide a procedure to configure a 15 UE in RRC INACTIVE state. A HE in RRC INACTIVE state shall be resumed to RRC CONNECTED state when an MBS session is activated Based on Release 17, at MBS session activation, all UEs belonging to the multicast group shall be configured at the same time.

As a second observation, for a large number of UEs, the delivery of MBS configuration at MBS multicast session activation may lead to link congestion and delay.

NB3S pre-configuration To avoid a massive NIBS configuration at NB3S session activation, it is proposed to pre-configure the UEs before the NIBS session activation.

NIBS configuration may be delivered at different stages: - At NIBS session establishment (or after) when the HE is in RRC CONNECTED state, - When a UE is switched to RRC_INACTIVE state to provide PTN4 configuration to receive the multicast data in RRC INACTIVE state, - When a UE is already in RRC INACTIVE state, e.g. for PTM configuration update. 30 Then, at NIBS multicast session activation, the UEs are notified by the network and they can apply the stored MBS configuration to start receiving the multicast data.

The UEs being pre-configured at different moments (before the session activation), the network load may be alleviated at the MBS session activation.

It is preferred that the network provides NIBS multicast configuration to the UEs in the multicast group before NIBS session activationFor the UEs that can receive NIBS multicast data in RRC INACTIVE state, the network may provide the PTM configuration(s) for some cells (e.g. neighbor cells) or for all cells in the NIBS service area. The advantage for a UE in RRC_INACTIVE state receiving NIBS multicast data is to be able to switch to a new cell without notifying the network to request a configuration. After performing the cell reselection process and switching to a new cell, the HE can apply the stored PTM configuration corresponding to the new cell.

It is proposed that when a HE can receive NIBS multicast data in RRC INACTIVE state, the network may provide to the HE the PTM configuration(s) for several cells in the neighborhood.

Notification of NIBS Session Activation At MBS session activation, the network may perform group paging indicating the activation of an NIBS multicast session. A HE in RAC INACTIVE state that has been pre-configured may directly apply the stored PIM configuration without notification to the network.

The UE may however notify the network to indicate its presence. For this purpose, the HE may send a RRC Resume Request message and the network may respond with a RRC Release with suspendConfig message to maintain the UE in RRC_INACTIVE state. Besides, this notification from UEs enables a gNB to estimate the number of UEs effectively receiving in RRC INACTIVE state.

As an alternative method to group paging, the network may indicate the activation of NIBS session activation through SIB.

It is proposed that LTEs in RRC_INACTIVE state may receive the notification of NIBS session activation through group paging or SIB It can be noted that whether the multicast session can be received in RRC INACTIVE state is implicitly indicated to the HE by receiving from the network a PTM configuration applicable in RRC INACTIVE state. The explicit indication whether multicast can be received in RRC INACTIVE state through paging may not be necessary.

PTM configuration delivery in RRC INACTIVE state Two options are considered for PTM configuration delivery in RRC INACTIVE state: using a dedicated signaling or based on SIB plus MCCH. However, providing PTM configurations using MCCH channel presents some drawbacks related to security (about the authorization to receive the multicast data). Furthermore, the NICCH content may be transmitted periodically and thus, it is not efficient in terms of bandwidth.

It is proposed that PTM configuration should be provided to a UE in RRC INACTIVE state via a dedicated RRC signaling.

When a UE is switched to RRC INACTIVE state, the network may provide PTM configuration through the RRC Release with SuspendConfig message. Such PTM configuration delivery can be performed before NIBS session activation (i.e. pre-configuration) or after NIBS session activation. This message may include the PTM configuration for one or several cells in the NIBS service area.

The process shown in figure 8 illustrates the PTM configuration delivery when switching to RRC INACTIVE state.

After MBS session establishment, the gNB may decide to switch a UE to RRC INACTIVE state (it may be decided with assistance information from the core network).

At this stage, the gNB may decide to pre-configure the UE to be able to receive the multicast data while in RRC INACTIVE state, by sending a RRCRelease message with SuspendConfig including the suitable PTM configuration. The UE is then aware that it is enabled to receive multicast data in RRC INACTIVE state In the same way, when the network has to configure a UE already in RRC_INACTIVE 20 state, the RRC Release with SuspendConfig message may also be used to provide PTM configuration(s) while maintaining the UE in RRC INACTIVE state. This may concern the following cases: I) when the configuration is triggered by the UE, e.g. at cell reselection when the UE is receiving multicast data and does not have the PTM configuration for a target cell, 2) when the configuration is at the initiative of the network.

In the first case (configuration triggered by the UE), the UE may send a RRC Resume request to the network (before or after cell switching) indicating the need for one or several PTM configuration(s) for a given MBS multicast session. Then, the network may respond with the RRC Release with SuspendConfig message including the requested PTM configuration(s).

In the second case (initiated by the network), the network may perform group paging announcing the availability of PTM configuration(s) for a NIBS multicast session. Then, a UE interested in the NIBS session may send a RRC Resume Request message to notify its presence and its interest in the NIBS session. Finally, the network may send a RRC Release with SuspendConfig message including PTNI configuration(s). This procedure may be performed at any time, before or after the MBS session activation (e.g for an update) It may also be performed at the NIBS session activation, meaning that the group paging would contain both the notification of MBS session activation and the notification of PTNI configuration.

As a proposal, PTN4 configuration(s) may be provided to a UE being switched to RRC INACTIVE state or already in RRC INACTIVE state using RRC Release with SuspendConfig message.

In both cases, the network may provide the PTM configuration(s) for some cells (e.g. neighbor cells) or for all cells in the MBS service area.

Also, in both cases, the UEs may be maintained in RRC INACTIVE state (without switching to RRC CONNECTED state).

It is proposed that a UE in RRC INACTIVE state may receive PTN4 configuration(s) without being switched to RRC_CONNEC FED state Before sending PTNI configuration(s) to a UE, the network should check that the UE belongs to the multicast group (i.e that it has joined the NIBS session and is authorized to receive the multicast data).

As an alternative method to group paging, the network may indicate the activation of MBS session activation through SIB.

It is proposed that group paging or SIB may be used to notify UEs in RRC_INACTIVE state about the availability of PTN4 configuration(s).

Claims

A method at a User Equipment, UE, of a wireless communication system, the method comprising: receiving, for a multicast session for which the UE has requested to join, multicast pre-configuration information for the multicast session, and configuring the UE according to the multicast pre-configuration information to receive multicast data via the multicast session 2. A method according to claim I, further comprising sending a request to join a multicast session to a core network via a base station.
3. A method according to any preceding claim, wherein the multicast pre-configuration information is received from a base station.
4. A method according to any preceding claim, wherein the multicast pre-configuration information is included in at least one of a Radio Resource Control, RRC, message, a system 15 information block, SIB, and an MBS Control Channel (MCCH) message.
5. A method according to any preceding claim wherein the pre-configuration information includes at least one of radio bearer configuration information associated with low quality of service, QoS, transmission, radio bearer configuration information associated with high quality of service, QoS, transmission, an inactive reception indicator that indicates to a UE if it is enabled to receive multicast data in an non-connected RRC state, information identifying a group of UEs within the same cell interested in receiving multicast data, a multicast pre-configuration ID identifying a configuration applied by UEs and associated with a multicast session ID, discontinuous reception, DRX, configuration information, neighbour cell multicast configuration information, and cell identification information for identifying one or more cells for which the pre-configuration shall be applied.
A method according to any preceding claim, wherein the multicast pre-configuration information comprises an update of existing configuration information for receiving multicast data via the multicast session, and wherein the configuring comprises using the pre-configuration information to update the configuration of the HE to receive the multicast data via the multicast session.
7. A method according to any preceding claim further comprising receiving data for the multicast session after performing the configuration according to the multicast pre-configuration information.
8. A method according to any preceding claim, wherein the multicast pre-configuration information is received prior to activation of the multicast session
9. A method according to claim 8, wherein the multicast pre-configuration information is received upon or after establishment of the multicast session
10. A method according to claim 8 or 9, further comprising receiving a notification of activation of the multicast session after receiving the multicast pre-configuration information.
11. A method according to claim 10, wherein the HE is configured according to the multicast pre-configuration information in response to receiving the notification
12 A method according to claims 10 or 11, wherein said notification of activation is any one of a paging message, an RAC message, a system information block, SIB, and an MBS Control Chanel (MCCH) message.
13. A method according to any of claims 9 to 12, wherein the HE is operating in a non-connected RRC state when receiving a notification of activation of the multicast session, and the notification of activation is received after a cell reselection process which causes the TIE to camp in a base station.
14. A method according to claim 13, further comprising sending a request for multicast reception and/or multicast feedback information after receiving multicast data, and receiving, in response, further multicast configuration data at the UE.
15. A method according to claim 13, wherein the cell re-selection process comprises sending information from the UE to base station that indicates multicast session identification information of one or more multicast sessions joined by the UE.
16. A method according to any of claims 1 to 7, wherein the multicast pre-configuration information is received after the activation of the multicast session.
17. A method according to any preceding claim, wherein the multicast pre-configuration information is received in a message for causing the UE to be put in a non-connected RRC state.
18. A method according to claim 17, wherein the multicast pre-configuration information is received in an RRC release message.
19. A method according to any of claims 1 to 9 or claim 16, wherein the multicast pre-configuration information is received while the UE is operating in a non-connected RRC state.
A method according to claim 19, wherein the multicast pre-configuration information is received after a cell reselection process which causes the UE to camp in a base station
21. A method according to claim 20, further comprising: after the cell reselection process, receiving a notification indicating multicast pre-configuration is available for the multicast session; and sending, by the UE, a multicast pre-configuration request to the base station, wherein the multicast pre-configuration information is received from the base station in response to the sent request.
22. A method according to claim 21, wherein the multicast-pre-configuration request is sent after performing a physical random access channel, PRACH, procedure with the base station in response to the notification indicating the multicast pre-configuration information is 25 available.
23. A method according to claim 20, wherein said cell reselection process comprises sending information from the UE to a base station in a case where a new cell has been selected as a result of the cell reselection process
24. A method according to claim 23, comprising sending a target base station identifier to the base station, the target base station identifier identifying a target base station associated with the new cell.
25. A method according to claim 23, comprising sending to a target base station associated with the new cell, multicast session identification information for identifying one or more multicast sessions joined by the UE.
26. A method according to any of claims 20 to 25, further comprising while the UE is operating in a non-connected RRC state: prior to the cell reselection process, receiving multicast data for an active multicast session according to a configuration for a base station in which the UE is camped before cell reselection, and wherein the pre-configuration information is for configuring the UE to receive multicast data from the multicast session from the base station in which the UE is to be camped following cell-reselection.
27. A method according to claim 26, wherein the cell reselection process comprises detecting by the UE if the cell is in the multicast service area for which the UE does not have a corresponding multicast configuration.
28. A method according to any of claims 26 or 27, wherein the request for the multicast pre-configuration information comprises at least one of G-RNTI information and multicast session identification information, wherein said G-RNTI information is used by the HE to decode the received multicast data.
29. A method at a base station controlling a cell serving User Equipment, UE, the method comprising: performing establishment of a multicast session requested by a UE; and sending, to the UE, multicast pre-configuration information for the multicast session.
30. A method according to claim 29, comprising receiving a request to join the multicast session from the UE and sending the request to join the multicast session to a core network.
31. A method according to claim 29 or 30, wherein the multicast session is established between the UE, the base station and a core network.
32. A method according to any of claims 29 to 31, wherein the multicast pre-configuration information is included in at least one of a Radio Resource Control, RRC, message and a system information block, SIB.
33. A method according to any of claims 29 to 32, wherein the pre-configuration information includes one or more of: radio bearer configuration information dedicated for low quality of service, QoS, transmission, radio bearer configuration information dedicated for high quality of service, QoS, transmission, an inactive reception indication that indicates to a UE(s) if they are enabled to receive multicast data in a non-connected RRC state; information identifying a group of UEs within the same cell interested in receiving multicast data, a multicast pre-configuration 1D identifying a configuration applied by UEs and associated with a multicast session ID, discontinuous reception, DRX, configuration information, and neighbour cell multicast configuration information cell identification information for identifying one or more cells for which the pre-configuration shall be applied.
34. A method according to any of claims 29 to 33, wherein the multicast pre-configuration information includes an update of existing configuration information for receiving multicast data via the multicast session.
35. A method according to any of claims 29 to 34, further comprising sending data for the multicast session to the HE, according to the multicast pre-configuration information.
36 A method according to any preceding claim, where the multicast pre-configuration information is sent prior to activation of the multicast session.
37. A method according to claim 36, wherein the multicast pre-configuration information is sent upon or after establishment of the multicast session.
38. A method according to claims 36 or 37, further comprising sending a notification of the activation of the multicast session to the UE
39 A method according to claim 38 wherein said notification of activation comprises at least one of a paging message, an RRC message and an SIB.
40. A method according to claim 38 or 39, wherein the UE is operating in a non-connected RRC state when the notification of activation of the multicast session is sent, and the notification of activation is sent by the base station to the UE after a cell reselection process
41. A method according to claim 40, further comprising receiving, from the UE, a request for multicast reception and/or multicast feedback information after sending multicast data to the UE, and sending, in response, further multicast configuration data for the multicast session to the UE
42. A method according to claim 40 wherein the cell re-selection process comprises sending information from the UE to base station that indicates multicast session identification information of one or more multicast sessions joined by the UE.
43. A method according to any of claims 29 to 35, wherein the multicast pre-configuration information is sent after the activation of the multicast session.
44. A method according to any of claims 29 to 43, wherein the multicast pre-configuration information is sent to the UE in a message for causing the UE to be put in a non-connected RRC state.
A method according to claim 44 wherein the multicast pre-configuration information is sent in an RRC release message
46. A method according to any of claims 29 to 35 or claim 43, wherein the multicast pre-configuration information is sent to the HE when the HE is operating in a non-connected RRC state.
47. A method according to claim 46, wherein the multicast pre-configuration information is sent after a cell reselection process which causes the UE to camp in a base station.
48 A method according to claim 47, further comprising: after the cell reselection process, sending a notification indicating multicast pre-configuration information is available for the multicast session; and receiving, from the UE, a multicast pre-configuration request, wherein the multicast pre-configuration information is sent in response to receiving the request.
49. A method according to claim 48, wherein the multicast pre-configuration request is received after performing a physical random access channel, PEACH, process with the UE.
A method according to claim 47, wherein said cell re-selection process comprises receiving information from the UE at a base station in a case where a new cell has been selected as a result of the cell reselection process.
51. A method according to claim 50, comprising receiving, as a source base station, a target base station identifier identifying a target base station associated with the new cell.
52. A method according to claim St, comprising receiving, as a target base station associated with the new cell, multicast session identification information for identifSring one or more multicast sessions joined by the UE.
53 A method according to any of claims 31 to 52, wherein, the UP is in a non-connected RRC state, and the base station is controlling a cell in which the UE is to be camped following a cell re-selection process, the method further comprising: receiving a request, from the UE, for multicast pre-configuration information corresponding to the base station.
54 A method according to claim 53, further comprising sending, to the UE, a notification that multicast pre-configuration information is available
55. A method according to claim 54, wherein the notification is sent if the base station detects that a modification of the multicast configuration is necessary for the HE to receive multicast data in the one or more cells it controls,
56. A method according to claim 54, wherein the notification is sent if the base station has been notified of a modification of the multicast configuration in one or more cells controlled by another base station.
57. A method according to any of claims 53 to 56 further comprising, before sending the updated multicast configuration information for the multicast session, checking that the HE has a context that allows it to receive multicast data for the multicast session.
58. A device comprising user equipment configured to perform a method according to any of claims Ito 28.
59. A device comprising a base station configured to perform a method according to any of claims 29 to 57.
60. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out a method according to any of claims Ito 57.
61. A computer-readable medium carrying a computer program according to claim 60.