GB2620980A

GB2620980A - MBS multicast pre-configuration

Info

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

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 multicast pre-configuration information is received prior to the activation of the multicast session. At a base station, the requested multicast session is established. The pre-configuration is sent to the UE before the session starts. 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 G132211067.0 RTM Date:20 December 2022 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 session establishment by the UE, session join request by the UE (associating the PDU session to the MBS session), resources reservation from the core to the NG-RAN for the delivery of NIBS data for the first join request.

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

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

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

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

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

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

As part of on-going discussions for Release 18, document S2-2200599 proposes to switch 5 the UE back into the RRC CONNECTED state, perform the configuration and switch again the UE to RRC INACTIVE state. While this solution seems functional, the purpose of offloading the gNB in case of large density of UEs by having UEs in the RRC INACTIVE state may not be achieved due to the additional signalling and other resources required to switch to the RRC CONNEC lED state in order to configure the HE and then switch back again to 10 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 TIE according to the multicast pre-configuration information to receive multi cast 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 UE to be put in a non-connected RRC state.

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

The multicast pre-configuration information may be received while the HE is operating in a non-connected RRC state.

The multicast pre-configuration information may be received after a cell reselection process which causes the UP 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 UP, 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, PEACH, procedure performed with the base station in response to the notification indicating the multicast 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 multi cast 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 HE 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 multi cast 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.

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, 1\413S, session according to fifth generation (50) new radio (NR), for example as defined in Release 17 of 50 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 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 1 is a schematic diagram illustrating a first example wireless communication 5 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 5GNR systems; Figure 5 is a simplified flowchart illustrating NIBS session evolution from creation to activation; Figure 6 is a flowchart illustrating the sending of UE pre-configuration after join 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; Figure 10 is a flowchart 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 Ilowchait illustrating the use of the pre-conligurati on by the UE &lei 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 HE 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

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 (NIBS). Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 50 NR. system, it will be appreciated that it is not intended that the present invention is limited to 50 NR systems arid may be used in any wireless communication systems supporting NIBS 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 50 core network 102. The UE may be any wireless device, such as a wireless communication device or apparatus or terminal, IoT device, Machine Type Communication (NITC) device, Device to Device (D2D) terminal, user device (e.g. smart phone, laptop, mobile phone, tablet, camera, game console, wearable device), capable of wireless communication with one or more core networks via one or more Radio Access Networks. The base station 110 is a network node which provides an access point to the core network for a UE and is part of the Radio Access Network (RAN) composed of the base stations 110, and 111. In NR, base stations are referred to as next-generation Node Bs (gNBs), the RAN is a Next Generation (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 NO 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 LTE 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, PRY in the control plane. Figure 2 illustrates a block diagram of a UE device 205, like the UE 101 or UE 151 in 10 the Figure 1, in which the present invention may be implemented according to one or more embodiments of the invention. The UE includes components for transmitting and receiving communications, including a UE communication manager 220, a I/O controller 255, a transceiver 235, a set of antennas 245, memory 225, and a processor (CPU: Central Processing Unit) 215. All these elements communicate with each other.

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

The processor 215 is configured to execute machine readable instructions. Execution of these machine-readable instructions causes the UE to perform various functions. These functions may be related to transmission or to interaction with peripheral devices like for instance a keyboard, a screen, a mouse, etc. (not shown in Figure 2). The processor may run an operating system like for instance, 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.

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

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

The Base Station communication manager 320 handles the communications with a plurality of UEs. It is responsible for the establishment, the control and the release of these communications. In an example implementation, the Base Station communication manager 320 implements the Uu interface. The Base Station communication manager 320 includes a scheduler that allocates time frequency slots to the different UE communications. Information regarding the schedule of these slots is regularly sent to the involved 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 LTEs 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 56 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 HE 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 HE 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 sewing gNB. If there is no radio activity for a while, the RRC connection can be released by the source gNB, then the UE's RRC state changes back to RRC IDLE state 401.

While releasing an RRC connection is interesting for capacity utilization and power saving, it is not ideal from the latency perspective. The overhead in establishing an RRC connection requires extra signalling that introduces delay. To cope with this drawback, the 25 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 50 system, but both the source gNB (e.g. last sewing gNB) and the HE store the HE context or configuration. The stored HE context or configuration includes information to facilitate quick resumption of the connection. The information may include the security context (e.g. security parameters such as security key, UE security capabilities), measurement configuration, radio configuration (e.g. UE radio capability), information about bearers, PDU session context etc. Thus, when in RRC CONNECTED state 402, the RRC connection can be suspended by the source gNB (Release with suspend), and the HE 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 HE 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 HE can 5 transit to RRC_IDLE state upon a RRC release command received from the gNB.

The mobility procedure to migrate a UE from one cell to another depends on the UE's RRC state. In RRC CONNECTED state, the mobility procedure, called handover, is controlled by the network, and the source gNB takes the decision to trigger the handover procedure based on the measurement reports provided by the UE. In RRC INACTIVE and in RRC IDLE states (e.g. non-connected states), the mobility procedure is called cell reselection, and it is managed by the UE itself In RRC INACTIVE state, the UE can be configured by the network with a RAN Notification Area (RNA). For example, the message that transitions the UE to the RRC INACTIVE state contains information indicating the RNA. The RNA is the area within 15 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 HE 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 HE in RRC INACTIVE state, to set the HE in RRC IDLE state, or to set the HE in RRC CONNECTED state.

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

The MBS session join procedure, as specified in 3GPP TS 23.247, is used by UEs to inform the 5GC of an interest in joining a multicast 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 MBS session, the UE should have established a PDU session that can be associated with multicast session(s), using the procedures as specified in TS 23.502. Also, the UE should know at least the MBS Session id of a multicast group that the UE can join, via service announcement broadcasted by the network. To join the multicast group, the UE sends a PDU Session Modification Request for the associated PDU session which contains one or several NIBS Session id(s) and a join request. The MBS Session id(s) indicates the multicast MBS session(s) that UE wants to join.

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

Figures 5a and 5b together illustrates example message flows for an example scenario of MBS session evolution from creation to activation. Figure 5a illustrates an example message flow for MBS session creation and establishment and Figure 5b illustrates an example message flow for MBS session activation.

Referring first to Figure 5a, UE, for example UE 101 (or it could be UE 151), is powered up and enters the RRC_IDLE state 500. During step 501, the UE connects to the closest gNB (for example, in the case of Figure 1, UE 101 connects to gNB 111) as a result of the cell selection process defined in TS 38.304 clause 5.2.3. Once connected to the gNB, the UE enters the RAC CONNECTED state 502. Then the UE executes the registration process or procedure 503 aiming at identifying the UE in the core network or 5GC 102, checking the UE subscriptions and enforcing the authorisations. The registration procedure is detailed in TS 23.502 clause 4.2.2.2.

After registration, the UE creates a first PDU session via a PDU session establishment procedure 504. The first PDU session is a default PDU session allowing access to 5G core services. This PDU session can be later associated to the 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 a NIBS session id (for example, TNIGI 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 MBSF (NIBS Service Function) in the core network 102.

There is no timing dependencies between UE connection/registration/PDU session establishment procedures (collectively identified by reference number 521) and 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 TIE 101 is registered in the core network 102 and a default PDU session is established and multicast service information is known, then TIE 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 NIBS session id, etc. as described above) is known by the TIE 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 TIE 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 UE's subscriptions and authorization levels to check if the UE is allowed to access the multicast session (i.e. to check the UE is one of a particular multicast group of UEs authorised to receive the multicast session). Also, as part of the session establishment procedure 508 the core network 102 will setup necessary resources in the core network to covey the multicast data from the application server 103 to the concerned gNBs.

The concerned gNBs are defined by the multicast service area information established at session creation step 505. The join procedure 507 and the multicast session establishment procedure 508 are defined in TS 23.247 clause 7.2.1.

In the example shown in Figure 5a, the gNB of the NC-RAN (e.g. gNB 111) decides to switch the UE 101 to RRC INACTIVE state 510 by sending a RRCRelease message 509 (TS 38.331 clause 6.2.2). The most common reason is load management, the gNB may decide to offload its control plane load by switching some UEs to RRC INACTIVE. Also, on-going discussions for Release 18 suggest that both UEs and core network provide additional information to the gNB to help the gNB take the decision to switch some UEs to RRC INACTIVE state. The additional information may include capacity information from both UE and Core network indicating the ability to send or receive multicast data in RRC INACTIVE state. Other information may also be provided by the UEs to express a preferred state for receiving the multi cast 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 NIBS 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 sewer 103. Multicast session activation is described in TS 23.247 clause 7.2.5.2. The main result of this procedure is the RAN (Radio Access Network) resource reservation by the gNBs. These resources allow the communication of the multicast data to the UEs that has already joined the multicast session. The RAN resources allocation includes the NLRB configuration (NIBS 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 NIBS session activation 512, the core network 102 may need to page some UEs to notify them of the availability of the multicast data. RRC INACTIVE UEs need to be paged because as explained in 510, RRC INACTIVE UEs are still moving and may enter into the cell of another gNB, but neither the new gNB (target gNB) nor the first gNB (source gNB) are aware of the UE movement at this step (i.e. at the time the multicast session is activated 512). The core network 102 sends a group page request to the gNBs with the MB S session id (not shown in Figure 5b), then each gNB sends a group paging 513 request with the multicast session id. This sequence is described as step 5 in TS 23.247 clause 7.2.5.2.

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

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

Once the RRC connection procedure is done, the HE is in RRC CONNECTED state It is only at that step when the UP 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 RRCReconfiguration 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 UP having to switch from the RRC INACTIVE state into the RRC CONNECTED state to perform the configuration for multicast reception, the additional signalling and other resources required to configure the UE in the RRC CONNECTED state adds to the load issues at the NG-RAN node, gNB, (i.e. too many UEs in the RRC CONNECTED state), and so the benefits of having UEs switched to the RRC INACTIVE state to avoid congestion are lost or at least reduced. For example, the paging, PRACH, NIBS configuration processes to resume to the RRC CONNECTED state, 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 ARC INACTIVE state that simplifies the procedure of Figure 5 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 UE 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 HE acting as a relay.

Multicast 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 MBS 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 UE acting as a relay. The UE 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 TIE 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 MBS session establishment 508 described in connection with Figure 5 which establishes the NIBS session requested by a UE 101 between the UE 101, gNB 110, 1 1 1 and core network 102. Subsequently, at 1603, and prior to activation of the multi-cast session, multi-cast pre-configuration information is sent to the UE.

In this description, "multicast pre-configuration information" means configuration information (data) that is received before multicast (NIBS) session activation of the session to which the pre-configuration information relates. 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 configuring a HE prior to multicast (NIBS) session activation 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 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 LTEs after a joining request made by the UE, and upon arrival of first multicast data. Hence, when the network is ready to configure a UE, it 10 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 LTEs are suitable candidates for the multicast session (e.g. based on the UE's capabilities). Once the group of candidate LTEs 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 consider different information elements including but not limited to: Multicast Radio Bearer "IVIRB2" configuration dedicated to receive multicast data with low QoS for candidate UEs. The "NIRB1" configuration is mainly addressed for Lifis in RRC CONNECTED state with high QoS.

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 The multicast configuration or pre-configuration of an NIBS session may have common information elements used for all the NG-RAN nodes located within the NIBS service area and 5 thus, the HE has common configuration that could be applied wherever in the NIBS 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 UE 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 NIBS 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 (RRC CONNECTED, RRC INACTIVE) During the UE join request procedure the gNB has enough information to perform radio resource reservation for 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 CONNEC 1ED) 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 join 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 able to receive multicast data with low QoS as described previously. This UE 601 is in RRC CONNECTED 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 NIBS 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 informs NG-RAN node 602 and 56C 603 about its capability and/or preference to receive multicast (MBS) data with low QoS. 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 NG-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, MRB contexts refer either to MRB1 or NIRB2 contexts for UEs allowed to receive multicast data in RRC CONNEC lED 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 UE 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.

For instance, the multicast pre-configuration information can be added to the multicast 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 multicast 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 configuration 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 then MRB2 configuration as well as a list of information elements mentioned above. The network can choose the same multicast pre-configuration information for multiple UEs and thus, it is considered as a shared delivery of multicast data within the NG-RAN node in 602. Otherwise, the UE can be pre-configured for an individual delivery and thus, a dedicated multicast pre-configuration is designated.

When the MBS session is activated, and the HE 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 IVIES session establishment in 606 and thus, it triggers various multicast pre-configuration messages sent to the UE 601 depending upon its RRC state. The following scenarios depict other alternatives to configure/pre-configure the UE by receiving pre-configuration information under different timings and/or conditions.

Some LTEs are always moving, and it can happen that a LTE moves after receiving pre-configuration information from a gNB. So, when a gNB hands over a UE to another gNB because the UE 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 UE 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 N4BS session establishment 706 whereas the UE is in RRC CONNECTED state. The NG-RAN node 602 may include this context in the multicast pre-configuration message in 708. Other triggering conditions related to the candidate UE 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 the step 1306 of Figure 13 (described below) if handover is performed in RRC CONNECTED state.

In an example, the message in 708 may be sent in one or multiple RRC messages such as RRCReconfiguration message or dedicated System Information Blocks (S1113s) to the LTE in 601. The message may include various information elements and mainly the NIRB2 configuration.

A handover can occur in 707 before the multicast pre-configuration information is received, the candidate UE in 601 is not yet pre-configured. During the handover procedure, the source NC-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 target multi cast 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 performing the handover to the target NO-RAN node 700 applies 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 MBS 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 LTEs. 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 30 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 the offload step in 1307 of Figure 13 which will be described in more detail below. After a joining request 605 and NLBS 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 NG-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 and receive while in RRC INACTIVE state.

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 RRCRelease 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 LIE in 601 performs its transition to RRC INACTIVE state 808 and is aware that by then, it is pre-configured to receive multi cast data while remaining in RRC INACTIVE state.

The NC-RAN node 602 may choose to send the multicast pre-configuration context 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 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 HE 601 in RRC _INACTIVE state as in step 1303, the NO-RAN node may send a paging message in 910 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 multi cast pre-configuration context.

The HE 601 in RRC INACTIVE state may process the paging message in 911 and identifies the paging cause. If the HE 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 HE 601 with the NG-RAN node 602. In 912, the UE 601 communicate its HE identity with the NG-RAN node and requests uplink radio resources for L2/L3 messages and RRC connection messages. Next, the UE 601 sends a multi cast pre-configuration request in 913 to the NG-RAN node 602.

The NO-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 ITE 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.

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 NG-RAN node in 900. The target NO-RAN node may send a broadcast paging message in 910 including the TMGI of the MBS session and the paging cause indicating an available multicast pre-configuration at the target NG-RAN node. The HE 601 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 HE 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 multi cast data in RRC INACTIVE state, it may send a multicast pre-configuration request to the target NO-RAN node in 913. The target NO-RAN node verifies then that the UE has joined the MBS session and it is capable and suitable to receive multicast data in RRC INACTIVE state. Next, the target NO-RAN node may send a multicast pre-configuration response in 914 to the UE 601. The target NG-RAN node may reject the request while indicating the reject cause.

The multicast 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 Response with the dedicated multicast pre-configuration or RRCReconfiguration message can be used. 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 RRC INACTIVE state by sending the multicast pre-configuration message.

Figure 10 is a flowchart of an embodiment particularly applicable to the above mentioned fifth scenario, that shows the sending of UE pre-configuration as result of a special cell reselection process.

Figure 10 shows a UE in 601 attempting to join the multicast MBS session in 605 while in RRC CONNECTED state 604. Next, the multicast MBS session is established in 1006 between the TIE 601, the NG-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 multicast 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 UE applies a cell reselection process conforming to an enhanced cell reselection process with an additional reselection request message.

In a standard cell reselection procedure, the UE 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 HE 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 LIE, 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 LT sends the reselection request message to the target gNB after changing the cell. In this alternative embodiment the reselection request message includes the MBS session information. , As a result of the enhanced cell reselection process, the gNB knows the RRC INACTIVE UEs in the cell, these UEs have to 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 MRB2 contexts, 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 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 multi cast 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 RRCReconfiguration or RRCRelease 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 this figure wherein the UE (601) is in RRC INACTIVE state 1008. The procedure 1009 is slightly different than figure 9 where a simple cell reselection 909 is applied without informing the NG-RAN node 602. Subsequently, the TIE 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 UE 601 informs its arrival to the target NO-RAN node 900. Following this, LIE context may be exchanged by way of example between the source NO-RAN node and the target NO-RAN node 900 including the LIE capability and/or preference. The UE 601 can simply send its capability and/or preference to the target NO-RAN node in 1009 without exchanging UE context.

Target NO-RAN node 900 sends eventually the multicast pre-configuration to the TIE in 601 The contents and the container types are as specified earlier in this section Embodiments are now described which describe how the pre-configuration information received at a UE, according to any of the embodiments described herein, is used to configure a TIE after session activation.

In one such embodiment, a multicast reception request can be sent by the TIE upon the NIBS session activation, it triggers the gNB to send multicast data for UEs in RRC_INACT1VE state. Furthermore, the UE may send a multicast reception feedback request to the gNB when 10 receiving the first multicast data in RRC INACTVE.

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 NIBS session activation in 1104 and 1310, first multicast data arrive in 1105 to the NU-RAN node 602 and trigger a paging message in 1106 destined for the UE 601 in RRC INACTIVE state. The paging message 1106 may include the NIBS session ID and a paging cause indicating the NIBS session activation of the corresponding MBS session as in 1408.

The TIE 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 H08 is initiated by the UE 601 with the NC-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 UE 601 in 1107. The UE 601 may have been pre-configured previously by the NC-RAN node or may request pre-configuration or reception in RRC INACTIVE state. The example below state 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. Following this, multi cast 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 NO-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.

In a third example, the HE 601 is not yet pre-configured to receive an RRC INACTIVE state. Therefore, the paging message in 1106 indicates that as of now, the MBS session is activated. Next, the HE 601 processes the paging in 1107 and may ask to be configured to receive multicast data in RRC INACTIVE state. Thus, it sends a multicast request in 1109 after interacting with the NC-RAN node 602 in the PRACH procedure 1108. The message in 1109 may request multicast configuration to receive in RRC INACTIVE state. The network 602,603 processes the request in 1110 and responds with multicast configuration in 1113 sent back to the UE 601. The network may reject the request of the UP to be configured to receive while in RRC INACTIVE state.

At the session activation 1104, 1310, the gNB may have pre-configured its UEs and needs to notify them in 1112 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 RRC INACTIVE state as in 1113 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 and the paging cause indicating the multicast MBS session activation status. The HE in 601 is up to then transparent to the target NG-RAN node (900). While processing the paging message in 1107, UE 601 can apply the multicast 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 to the UE at the moment of the multicast pre-configuration.

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

In a first example, it is considered that the UP 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. After processing the request 1109 in the network in H 10, the target NG-RAN node 900 may redirect the multicast data in 1111 for the UE 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 KG-RAN node 900 is sending the multicast data 1112 through the NIRB2 radio bearer and earlier after the paging message H06, The UE 601 may interact with the target NO-RAN node in 900 (PRACH procedure in 1108) and may send a multicast reception confirmation to the target NO-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.

In a third example, the UE 601 may request multicast configuration to receive in RRC INACTIVE state in message 1109. The target NO-RAN node 900 processes the request in 1110 and 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 NO-RAN node sends the multicast data as in 1111. The target NO-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 1 1 1 3 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 - multicast 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 30 message such as RRCResume response or RRCRelease or RRCReconfiguration 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 5 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 NIBS activation message sent by the network to inform the UEs of the session activation. The UE applies the multicast pre-configuration and multicast data is then arrived.

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

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

The UE 601 receives the message in 1202 and applies its multicast pre-configuration in 1203 and 1409. Thus, the UE 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 NG-RAN nodes 602, 900 in UE context exchange. In 1201, the UE in 601 informs the target NG-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.

In case the source NO-RAN node has pre-configured the UE 601 to receive multicast data in RRC_INACTIVE for neighbour cells where it is located the target NC-RAN node 900.

Thus, the target NG-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 NG-RAN node 900 sends its proper multicast pre-configuration context within 1201 or later.

Upon the NIBS session activation in 1104, the multicast data in 1105 arrives to the (target) NO-RAN node 602 or 1100 issued by the application server in 1101. 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.

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 UEs To manage the UE configuration, the gNB maintains in its memory 325 a set of UE 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-configuredinactive_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 TIE 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 TIE 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: - Multi cast Radio Bearer "NERB2" configuration dedicated to receive multicast data with low QoS for candidate UEs. The "NIRB1" configuration is mainly addressed for UEs in RRC CONNECTED state with high QoS.

- DRX configuration used to receive multicast data for candidate UEs - Neighbour cells multicast configuration applied when candidate UEs perform handover or cell reselection 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 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 PEACH 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 includes information indicating which MBS sessions the UE is participating in], so the gNB knows the RRC INACTIVE UEs in the cell, these UEs have to up to date system information and page, PRACH and pre-configuration request can be skipped.

The UE identifiers are removed from the -unconfigured_inact ve 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 (or alternatively by the UE if the enhanced cell reselection is used) 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 '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 (SIBs) 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 multi cast pre-configuration information element is available, then during step 1309 the gNB sends the multi cast pre-configuration information element to the UE in the RRCRelease message 807. To this end, the NG-RAN node 602 may use RRCRelease message 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 BNB 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 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 UE 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 "MBS 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 PRACH procedure to update their system information, then the UEs will send a NIulticast NIBS configuration request message (NB3SConfigurationRequest or NIBSConfigurationRequestl) The NIBS 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 (TNIGI)). In other words, an identifier for indicating the NIBS session the configuration is requested for. In addition, the multicast NIBS configuration request message may include UE identity information for identifying the UE 101, such as IMSI, 'MEI, and/or Authentication information (ueNIAC-I), such as an authentication token, for use in authenticating the HE 101. Upon reception of the multicast NIBS configuration request message, the gNB will send an NIBS configuration message (Nfl3SConfiguration) with the multicast configuration information element to the UE. The multicast MBS configuration request message which may include gathering or obtaining the necessary information to build the UE configuration for the at least one UE so the at least one UE can receive multicast data for the activated multicast session. Once the UE configuration is known (including the step of Radio Access Network (RAN) resource reservation), the base station or gNB III sends a multicast MBS configuration message to the at least one UE. The multicast MBS configuration message includes configuration information for configuring the at least one UE 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 HE 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 MBS 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 HE by the base station (e.g. source or sewing base station) controlling the cell where the UE is camped and is sent in response to receiving the MBS configuration request message from the at least one UP.. 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 MBS 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 to up to date system information and the page, PRACH and pre-configuration request can be skipped.

Each time a HE sends a NIulticast 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 "pre-configured 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 UP 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 "NIBS 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 does not have 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 MBSConfigurationRequestO and the gNB will send a NIBS configuration message (N4BSConfiguration) 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 UP sends a Multicast Configuration Request Message the gNB adds the corresponding UP 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 ofFigure 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 HE 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. 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 RRCResume message or a modified RRCResum e 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 HE 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 HE 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 "NIBS session activation" paging cause.

If the "NIBS 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 "NIBS 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 "NIBS 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 MBSConfigurationRequestl) and the gNB will send a NIBS configuration message (NIBSConfiguration) 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, 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 NIBS 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 TIE 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.

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 AIRSTreC onfiguration corresponds to the multicast (MBS) 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 HE 1> for each afol included in pagingGroztpList, if any, included in the Paging message: 2>if the UE has joined an NIBS session indicated by the mu' included in the pagingGroupList: 3> forward the TAIGI to the upper layers; 1> if in RRC INACTIVE and the UE has joined one or more MBS session(s) indicated by the TARR included in the pagingGroicoList; and 1> if none of the we-Identify included in any of the PagingRecord, if included in the Paging message, matches the HE 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 reS11771eCallSe set as below: 3> if the UE is configured by upper layers with Access Identity 1: 4> resumeCause is set to nip.s*-PriornyAccess; 3> else if the UE is configured by upper layers with Access Identity 2: 4> resumeCause is set to mcs-PriornyAccess; 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 highPriornyAccess; 3> else: 4> resume Cause is set to nn-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 resent/a:cruse set as below: 3> if the HE is configured by upper layers with Access Identity 1: 4> restnneCan se is set to mps-PriornyAccess; 3> else if the UE is configured by upper layers with Access Identity 2: 4> resume(' wise is set to incs-PrioriO4ccess; 3> else if the HE is configured by upper layers with one or more Access Identities equal to 11-15: 4> resumeCause is set to highP orityAccess; 3> else: 4> resumeCause is set to mi-Access.

5.3.X Multicast pre-configuration request procedure 5.3.X I General Figure 5.1X. 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.X2 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 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 5. 3.X 3 Actions related to transmission of MBSPreConfigRequest or MKSTreConfigRequesil message The TIE shall set the contents ofil4BSPreCettest message.

5.3.X. 4 Reception of the MBSPreConfiguration by the UK The TIE shall: 1> if the RRCResume includes the radioBearerCot 2> perform the radio bearer configuration according to 5.3.5.6.

6.2.2 Message definitions MBSPreConiiRea_Atriest The MRSPreCon i,Rec tint messa e is used to re 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 MBSPreCoufigurationRequest message --A SN1START - TAG-MBSPreCONFIGURATIONREQUEST-START MB SPreConfi gurationRequest::= SEQUENCE mbsPreConfigurationRequest MBSPreCconfigurationRequest-IEs MBSPreConfigurationRequest-lEs::= SEQUENCE t ueIdentity Shord-RNTI-Value ueMAC-I BIT STRING (SIZE (16)) multicastSessionId MulticastSessionld spare BIT STRING (SIZE (1)) - TAG-N4B5PreCONFIGURATIONREQUE5T-5TOP --A SN1STOP

MBSPreConfigurationRequest-!Es field descriptions

multieustSessionId Indicates which MBS session the pre-configuration is requested for ueldentitv HE 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,313,3, AlBSPreConfiungS The MBSPreConfiguration message is used to setup the reception of multicast in 25 RRC INACTIVE state Siunalling radio bearer. SRB1 RLC-SAP: AM Logical channel: DCCH Direction: Network to TIE MBSPreConfiguration message - ASN1START --TAG-MB SPreCONFIGURE-START MB SPreConfiuure: = SEQUENCE { rrc-TransactionIdentifier RRC-TransactionIdentifier cri ti cal Exten si on s CHOICE { MBSPreConfigure M B SPreConfi gure-I Es criticalExtensionsFuture SEQUENCE (1 MB SPreConfi gure-I Es:= SEQUENCE ( radioBearerConfig RadioBearerConfig OPTIONAL, --Need M MB S-DRX-PreConfig MBS-DRX-Config

OPTIONAL

MB SPreConfi gurel-lEs SEQUENCE CellIndentity Cell Indentitv radioBearerConfig RadioBearerConfig OPTIONAL --Need M MBS-DRX-PreConfig IVIBS-DRX-Config

OPTIONAL

--TAG-MB SPreConfi uure-STOP - ASN1STOP

RRCResume-IEs field descriptions

radioBearerConfig Configuration of Radio Bearer2 (MRB2) Including SDAP/PDCP.

MBS-DRX-PreConfig DRX configuration to receive multicast data Cell Identit The neighbour cell identity MBSPreConfiguration message RRCRelease-v1650-IEs.:= SEQUENCE 1 mpsPrioritvIndication-r16 ENUMERATED I true} OPTIONAL Cond Redirection2 radioBearerConfig RadioBearerConfig OPTIONAL, --Need M MBS-DRX-PreConfig MBS-DRX-Config

OPTIONAL

MBSPreConfigurel -IEs = SEQUENCE I" Indentity, CellIndentity Cell radioBearerConfig RadioBearerConfig OPTIONAL --Need M MBS-DRX-PreConfig MBS-DRX-Config

OPTIONAL

I-

I

RRCRelease-lEs field descriptions

radioBearerConfig Configuration of Radio Bearer2 (MRB2) including SDAP/PDCP.

MBS-DRX-PreConfig DRX configuration to receive multicast data Cell Identity The neighbour cell identity 5.3.X Multicast reception procedure 5.3.X.1 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).

Mit/cairn/ The UE initiates the procedure when upper layers or AS (when responding to RAN 10 paging) requests the reception of Multicast in RRC INACTIVE state.

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 barred, the procedure ends; Actions related to transmission of AlBSConfigRequest or AlBSConfigRequest message The UE shall set the contents of A4BSCorifigRequest or AlBSConfigRequestl message as follows:

1> if field useFullResumell) is signalled in S181:

2> select AlBSconfigRequest/ as the message to use; 2> set the ueldentity to the storedfit/II-RAW value; 1> else: 2> select MBSCorifigkequest as the message to use; 2> set the ueldentity to the stored shortl-RNTI value; 1> re-establish PDCP entities for SRBI; 1> resume SRB I; 1> submit the selected message NIESConfigRequest or AIRSConfigRequest 1 for transmission to lower layers Reception of the MRS'Configuration by the LIE The HE shall: 1> if the RRCReslinte includes the radloBectrerConfig: 2> perform the radio bearer configuration according to 5.3.5.6; Message definitions MB SConRefigtest The All3SConfigRequest 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: HE to Network MBSConfigurationRequest message - ASN1START

- TAG-MBSCONFIGURATIONREQUEST-START

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

MBSConfigurattonReques -1Es field descriptions

mul wastSessionld ueIdentity HE identity to facilitate TIE context retrieval at gl\IB.

uellIAC-1 Authentication token to facilitate UE authentication at °NB. The 16 least sionifi cant bits of the MAC-I calculated usin* the AS security confi*uration as ssecified in 5.3.13.3.

- MBSConfigurcttionRequest] The All3SCortfigurationRequest I message is used to request the configuration for the reception of multicast in RRC INACTIVE state.

Signalling radio bearer: SRBO 20 25 30 RLC-SAP: TM Logical channel: CCCH1 Direction: UE to Network MBSConfizurationRequestl message - ASN1START - TAC-MBSCONFICURATIONREQUEST1-START MBSConfigrationRequestl::= SEQUENCE { mbsConfigurationRequestl MBSConfigurationRequestl-IEs MBSConfigurationRequestl-IEs::= SEQUENCE { ueIdentity I-RNTI-Value, ueMAC-I BIT STRING (SIZE (16)), multicastSessionId TMGI-R17, spare BIT STRING (SIZE (1)) - TAC-MBSCONFICURATIONREQUEST1-STOP - ASN1STOP

AlBSConfieurationRequestl-lEs field descriptions

multicastSessionId Indicates which MBS session the configuration is requested for.

ueIdentity UP identity to facilitate UP context retrieval at gNB.

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

114B,Sroirfiguration The /14BSCoqfiguration 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 UP MBSCon figuration message 10 15 20 - ASN1START

- TAG-MBSCONFIGURE-START

MBSConfigure::= SEQUENCE { rrc-TransactionIdentifier RRC-TransactionIdentifier, criticalExtensions CHOICE { MBSConfigure MBSConfigure-IEs, criticalExtensionsFutuse SEQUENCE {1 MBSConfigore-IEs::= SEQUENCE { radioBearerConfig RadioBearerConfig OPTIONAL, --Need M - TAC-MBSConfigure-STOP

- ASNISTOP

RRCResuene-lEs field descriptions

radioBearerConfig Configuration of Radio Bearer (NIRB) including SDAP/PDCP.

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

5.3.X2 Initiation The UE initiates the procedure when upper layers or AS (when responding to RAN pag nu) requests the reception of Multicast in RRC INNACTIVE state.

Upon initiation of the procedure, the TIE shall: 1> if the resumption of the RRC connection is triggered by response to NO-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.

114B,SiReceptionRequest The MBSReceptionRequest 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 MBSReceptionRequest message - ASN1START - TAG-MBSRECEPTIONREQUEST-START 10 MBSReceptionRequest::= SEQUENCE { mbsReceptionRequest MBSReceptionRequest-IEs MBSReceptionRequest-lEs::= SEQUENCE { ueIdentity ShortI-RNTI-Value ueMAC-I BIT STRING (SIZE (16)) multicastSessionId MulticastSessionId spare BIT STRING (SIZE (1))

- TAG-MBSRECEPTIONREQUEST-STOP

- ASN1STOP

MBSReceptionRequest -IEs field descriptions

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

ueMAC-I Authentication token to facilitate UE authentication at uNB. The 16 least significant bits of the MAC-I calculated using the AS security configuration as specified in 5.3.13.3. 5'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 (I) 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, EEPROIVI, 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.

Claims

CLAIMS1. 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, 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 2. A method according to claim 1, 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 and a system information block, SIB.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, discontinuous reception, DRX, configuration information, and neighbour cell multicast configuration information 6. 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 upon or after establishment of the multicast session.9. 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.10. A method according to claim 9, wherein the multicast pre-configuration information is received in an RRC release message.11. A method according to any of claims 1 to 7, wherein the multicast pre-configuration information is received while the UE is operating in a non-connected RRC state.12. A method according to claim ii, wherein the multi cast pre-configuration information is received after a cell reselection process which causes the UE to camp in a base station.13. A method according to claim 12, 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.14. A method according to claim 13, 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 available.15. A method according to claim 12, 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 16. A method according to claim 15, 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.17. A method according to claim 15, 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 18. A method according to any preceding claim, further comprising receiving a notification of activation of the multicast session after receiving the multicast pre-configuration information.19. A method according to claim 18, wherein the UE is configured according to the multicast pre-configuration information in response to receiving the notification 20. A method according to claims 18 or 19, wherein said notification of activation is any one of a paging message, an RRC message and a system information block, SIB.21. A method according to any of claims 18 to 20, wherein the UE 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 UE to camp in a base station.22. A method according to claim 21, 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 UP.23. A method according to claim 21, 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 24. A method at a base station controlling a cell serving User Equipment, UE, the method 25 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 25. A method according to claim 24, 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 26. A method according to claim 24 or 25, wherein the multicast session is established between the HE, the base station and a core network 27. A method according to any of claims 25 to 26, 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.28. A method according to any of claims 24 to 27, 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, discontinuous reception, DRX, configuration information, and neighbour cell multicast configuration information 29. A method according to any of claims 24 to 28, wherein the multicast pre-configuration information includes an update of existing configuration information for receiving multicast data via the multicast session.30. A method according to any of claims 24 to 29, further comprising sending data for the multicast session to the HE, according to the multicast pre-configuration information.31 A method according to any of claims 24 to 30, wherein the multicast pre-configuration information is sent upon or after establishment of the multicast session.32. A method according to any of claims 24 to 30, wherein the multicast pre-configuration information is sent to the HE in a message for causing the HE to be put in a 25 non-connected RRC state 33 A method according to claim 32 wherein the multicast pre-configuration information is sent in an RRC release message.34. A method according to any of claims 24 to 30, wherein the multicast pre-configuration information is sent to the UE when the UE is operating in a non-connected RRC state.35. A method according to claim 30, wherein the multicast pre-configuration information is sent after a cell reselection process which causes the UE to camp in a base station.36. A method according to claim 35, 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.37. A method according to claim 36, wherein the multicast pre-configuration request is received after performing a physical random access channel, PRACH, process with the UE.38 A method according to claim 33, wherein said cell re-selection process comprises sending information from the HE to a base station in a case where a new cell has been selected as a result of the cell reselection process 39 A method according to claim 38, comprising receiving, as a source base station, a target base station identifier identifying a target base station associated with the new cell.40. A method according to claim 38, comprising 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 41. A method according to any of claims 24 to 40, further comprising: sending a notification of the activation of the multicast session to the UE 42. A method according to claim 41 wherein said notification of activation comprises at least one of a paging message, an RRC message and an SIB.43. A method according to claim 41 or 42, 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 44. A method according to claim 43, 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.45. A method according to claim 43 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.46. A device comprising user equipment configured to perform a method according to any of claims 1 to 23.47. A device comprising a base station configured to perform a method according to any of claims 24 to 45.48. 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 1 to 45.49. A computer-readable medium carrying a computer program according to claim 48.