Configuring UEs for multicast reception

Abstract

A method is disclosed for configuring a user equipment (UE) of a wireless communication system for multicast reception, wherein the UE has previously joined a multicast session. The method includes, at a UE operating in a non-connected radio resource control (RRC) state, such as an RRCINACTIVE state, receiving a notification indicating that a multicast session has been activated; transmitting an MBS configuration request message for requesting configuration information for receiving multicast data; and receiving an MBS configuration message, wherein the MBS configuration message comprises configuration information used for configuring the UE to receive multicast data. A method at a base station is also disclosed.

Description

Technical Field

[0001] The present invention generally relates to configuring or setting a user equipment (UE) of a wireless communication system for multicast reception, and in particular to configuring or setting multicast reception in a non-connected RRC state (e.g., RRC_INACTIVE state), including (one or more than one) multicast MBS (Multicast / Broadcast Service) radio bearer MRB. Background Art

[0002] Wireless communication systems are widely 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 multiple user equipments (UEs) or mobile terminals to share the wireless medium to exchange several types of data content (e.g., video, voice, messaging, etc.) over a radio access network (RAN) through one or more base stations.

[0003] Examples of such wireless multiple-access communication systems include systems based on the 3rd Generation Partnership Project (3GPP-RTM) standards (such as the 4th-Generation (4G) Long Term Evolution (LTE) or the more recent 5th-Generation (5G) New Radio (NR) systems), or systems based on the IEEE 802.11 standards (such as Wi-Fi).

[0004] Among the requirements for 5G NR, there are service requirements related to multicast and broadcast services (abbreviated as MBS).

[0005] For broadcast communication services, the same service and the same specific content data are provided to all UEs in a geographic area at the same time (i.e., all UEs in the broadcast service area are authorized to receive data). Broadcast communication services are delivered to UEs using broadcast sessions. For multicast communication services, the same service and the same specific content data are provided to a dedicated set of UEs at the same time (i.e., not all UEs in the multicast service area are authorized to receive data). Multicast communication services are delivered to UEs using multicast sessions.

[0006] Support for multicast / broadcast technology enables the network to operate in a more efficient manner than unicast. Use cases identified that can benefit from this MBS feature include public safety and mission-critical, V2X applications, IPTV, real-time video, software delivery over wireless, and IoT applications. 3GPP began building functional support for MBS in 5G NR from Release 17.

[0007] In 5G NR, the Radio Resource Control (RRC) protocol operates in the control plane between the UE and the base station (gNB), and provides 3 different states for the UE as defined in the 3GPP specification TS 38.331: RRC_CONNECTED, RRC_INACTIVE, and RRC_IDLE states. At power-on, the UE is in the RRC_IDLE state, and the UE changes to the RRC_CONNECTED state when the RRC connection with the gNB is established. If the RRC connection is released, the UE changes back to the RRC_IDLE state. When in the RRC_CONNECTED state, the RRC connection can be suspended by the gNB, and the UE moves to the RRC_INACTIVE state. When the UE is in the RRC_INACTIVE state, the UE cannot communicate with the 5G system, but both the gNB and the UE keep track of the RRC connection context. Therefore, the transition from the RRC_INACTIVE state back to the RRC_CONNECTED state is faster than the RRC connection establishment from the RRC_IDLE to the RRC_CONNECTED state.

[0008] In the case of 3GPP Release 17, the reception of MBS broadcast by the UE is allowed when the UE is in RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED state, and the reception of MBS multicast is allowed only when the UE is in RRC_CONNECTED state. For Release 18, the plan is to allow MBS multicast reception also when the UE is in RRC_INACTIVE state. For example, see 3GPP RP-213568 entitled "New WID: Enhancements of NR Multicast and Broadcast Services" submitted by CATT (title: 3GPP TSG RAN Meeting #94-e, source CATT) (Section 3). The purpose is to enable a large number of UEs to receive multicast data from one cell. In fact, putting the UE in the RRC_INACTIVE state reduces the control plane footprint of the entire UE, allowing the gNB to handle more UEs. In addition, it is not energy-efficient to always keep the UE in the RRC_CONNECTED state. Therefore, the advantages of also supporting multicast for UEs in the RRC_INACTIVE state have been recognized.

[0009] In Release 17, MBS multicast sessions follow 3GPP TS23.247v17.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".

[0010] The session management process includes session creation (7.1.1.2 or 7.1.1.3 of TS23.247), session activation (7.2.5.2 of TS23.247), session establishment and joining (7.2.1.3 of TS23.247).

[0011] At the beginning, the session does not exist. The session is created at the request of the AF (Application Function). As part of the creation process, an MBS session identifier is allocated, a multicast service area is defined, and the session is announced to the UEs in the service area. The multicast service area is defined in 3GPP TS22.146 version 17.0.0, clause 3 "Definitions". A multicast service area is defined for each multicast service. One multicast service can start multiple multicast sessions. The multicast service area can be as large or smaller than the PLMN (Public Land Mobile Network) coverage area.

[0012] Once a session is created, the first UE that sends a join request to the session will trigger session establishment towards the NG-RAN (including (one or more) gNBs in the multicast service area). Subsequent join requests from other UEs will not trigger session establishment. The session establishment process includes the UE's PDU session establishment, the UE's session join request (associating the PDU session to the MBS session), and resource reservation from the core to the NG-RAN for the delivery of MBS data for the first join request.

[0013] In addition, once the session is created, the MB-SMF (MBS Session Management Function) can be triggered to activate the session. The triggering condition reflects the availability of multicast data from the application. The session activation process includes NG-RAN resource reservation.

[0014] The NG-RAN configures the UE to receive multicast data only when both the session is activated and the MBS session is established.

[0015] The initiation of the process of session activation and session establishment answers to different triggers: for session activation the trigger is the availability of multicast data from the application and for session establishment the trigger is the presence of at least one UE in the service area sending a join request to the multicast session.

[0016] The establishment of an MBS session in the UE is performed while the UE is in RRC_CONNECTED state. Possibly, the gNB may then decide to switch the UE to RRC_INACTIVE state before MBS multicast data is available through session activation. As a result, the NG-RAN (at least one gNB) will have to inform and configure UEs that have joined the session but are in RRC_INACTIVE state when the session is activated.

[0017] The current version of the specification does not provide a procedure for notifying or configuring a UE in RRC_INACTIVE state.A UE in RRC_INNACTIVE state should not receive any data from applications and has limited access to the control plane.

[0018] In Release 17, some mechanisms are proposed to handle the case of broadcast reception in RRC_INACTIVE state. Document TS 38.300 Version 17.0.0 states in clause 16.10.6.2 that the gNB uses MCCH (MBS Control Channel) to provide configuration to UEs in any RRC state including RRC_INACTIVE state. In fact, the MCCH channel is accessible to UEs in RRC_INACTIVE state and is well suited for sending notifications and configuration parameters. However, the fact that the MCCH is in fact accessible to all UEs without restriction represents a security violation for MBS multicast services, since access to multicast data is subject to prior authorization of each UE during the joining process. Multicast configuration should only be available to UEs that have obtained appropriate authorization during the joining process.

[0019] As part of the ongoing discussion for Release 18, document S2-2200599 proposes switching the UE back to RRC_CONNECTED state, configuring and switching the UE to RRC_INACTIVE state again. While this solution appears to work, the purpose of offloading the gNB by keeping the UE in RRC_INACTIVE state may not be achieved in cases where the density of UEs is high due to the additional signaling and other resources required to switch to RRC_CONNECTED state to configure the UE and then switch back to RRC_INACTIVE state again.

[0020] It is therefore desirable to provide at least one solution to enable a UE that has previously joined a multicast session to be configured to receive multicast data if the multicast session is activated while remaining in the RRC_INACTIVE state. Summary of the invention

[0021] According to a first aspect of the present invention, a method for configuring a user equipment (UE) of a wireless communication system for multicast reception is provided, wherein the UE has previously joined a multicast session, the method comprising, at a UE operating in a non-connected radio resource control (RRC) state: receiving a notification indicating that the multicast session has been activated; sending an MBS configuration request message for requesting configuration information for receiving multicast data; and receiving an MBS configuration message, wherein the MBS configuration message includes configuration information for configuring the UE to receive multicast data.

[0022] In an example, the non-connected RRC state is the RRC_INACTIVE state.

[0023] The notification may be a paging message (eg, a group paging message) sent by the base station, and may include an MBS session ID identifying the activated multicast session and an MBS session activation cause indicating that the multicast session has been activated (eg, by the core network).

[0024] In an example, the MBS Configuration Request message includes an identifier for identifying the activated multicast session, such as a Temporary Mobile Group Identity (TMGI) or an MBS session ID.

[0025] The configuration information may include configuration information of at least one MBS Radio Bearer (MRB).

[0026] According to a second aspect of the present invention, there is provided a method at a base station for controlling a cell in which one or more than one user equipment (UE) is camping as claimed in claim 13 of the accompanying claims.

[0027] Therefore, the UE remains in a non-connected RRC state (eg, RRC_INACTIVE state) during the entire process and is able to immediately acquire necessary configuration for multicast data reception when multicast data reception is available.

[0028] By sending a notification indicating that a multicast session has been activated when the MBS session is activated, the UE can determine that the notification relates to the MBS session activation, and this helps prevent the UE from automatically initiating an RRC recovery procedure and switching to the RRC_CONNECTED state. In addition, by configuring the UE in the RRC_INACTIVE state after being notified that the multicast session has been activated, it is possible to avoid requiring the UE to switch to the RRC_CONNECTED state when the multicast MBS session is activated, which means that the number of UEs in the RRC_CONNECTED state can be reduced, thereby reducing congestion at the gNB. In addition, in the example where the notification sent by the base station is a group paging message, using the group paging message is simpler than having to page all UEs individually, but a corrupted UE may pretend to have joined the session earlier to tamper with the multicast session. By having the UE run the MBS Configuration Request / Response protocol to request MBS configuration, the gNB is able to perform an access authorization check and can deny configuration to the corrupted UE (e.g., by not responding to an MBS Configuration Request message sent by the corrupted UE).

[0029] The notification may be a group paging message sent by the base station and received at the UE, and the group paging message may include an identifier for identifying the activated multicast session and / or information indicating that the multicast session has been activated. The information indicating that the multicast session has been activated may include an MBS session activation cause. In an example, the MBS configuration request message is an RRCResumeRequest message, and the MBS configuration message is an RRCRelease message with a suspended configuration. Sending an RRCRelease message with a suspended configuration after receiving an MBS configuration request message from a UE in a non-connected RRC state (e.g., RRC_INACTIVE) helps prevent the UE from initiating an RRC recovery process and switching to an RRC_CONNECTED state, and thus keeping the UE in a non-connected RRC state using a simple process (i.e., without requiring a large amount of signaling) while still configuring the UE for the activated MBS session.

[0030] According to a third aspect of the present invention, there is provided an apparatus for a User Equipment (UE) device / equipment as claimed in claim 25 of the accompanying claims.

[0031] According to a fourth aspect of the present invention, there is provided an apparatus for a base station as claimed in claim 26 of the accompanying claims.

[0032] Further exemplary features of the invention are described in other independent and dependent claims.

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

[0034] Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any references herein to software and hardware features should be interpreted accordingly. For example, according to other aspects of the present invention, there is provided a computer program comprising instructions that, when executed by a processing unit, cause the processing unit to perform any of the above aspects or examples of the method; and a computer-readable storage medium carrying the computer program. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0036] Figure 1 is a schematic diagram illustrating a first exemplary wireless communication system in which the present invention may be implemented according to one or more embodiments of the present invention;

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

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

[0039] Figure 4 is a flow chart showing RRC connection states and transitions of a UE in a 5G NR system;

[0040] Figure 5a and Figure 5b are schematic and simplified diagrams of example message flows, and together they illustrate an example scenario of MBS session evolution from creation to activation;

[0041] Figure 6 is a schematic and simplified diagram of an example message flow according to an embodiment of the present invention;

[0042] Figure 7 is a flowchart illustrating an example method performed by a UE according to an example of an embodiment of the present invention;

[0043] Figure 8 is a flow chart illustrating an example method performed by a gNB according to an example of an embodiment of the present invention;

[0044] Fig. 9 is a flowchart illustrating an example method performed by a UE according to an embodiment of the present invention;

[0045] Fig.10 is a flowchart illustrating an example method performed by a gNB according to an embodiment of the present invention. DETAILED DESCRIPTION

[0046] Figure 1 An example wireless communication system 100 is illustrated, in particular a mobile radio communication system such as a fifth generation (5G) new radio (NR) system supporting multicast and broadcast services (MBS). Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR system, it should be understood that the present invention is not intended to be limited to a 5G NR system, and the present invention may be used in any wireless communication system supporting MBS or similar services.

[0047] The system 100 includes a user equipment (UE) 101 (or 151) served by a base station 110 to communicate with a core network (such as a 5G core network 102), which UE may be, for example, in a vehicle or as part of a vehicle. A UE may be any wireless device capable of wirelessly communicating with one or more core networks via one or more radio access networks, such as a wireless communication device or equipment or terminal, an IoT device, a machine type communication (MTC) device, a device to device (D2D) terminal, a user device (e.g., a smart phone, a laptop, a mobile phone, a tablet, a camera, a game console, a wearable device). The base station 110 is a network node that provides an access point to the core network for the UE and is part of a radio access network (RAN) composed of base stations 110 and 111. In NR, a base station is called a Next-Generation Node B (gNB), the RAN is a Next Generation (NG) RAN, and the core network is called a 5GC. Below, the terms RAN node, base station, and gNB will be used interchangeably. Base stations 110 and 111 are interconnected via an Xn interface (specified in 3GPP document TS 38.423) implemented over wired or wireless links 130. Each base station is connected to core network 102 via an NG interface (specified in 3GPP document TS 38.413) implemented over wired or wireless links 140 and 141.

[0048] Each of these base stations controls one or more cells. For example, base station 110 controls cell 120, and base station 111 controls cell 121. A cell is a geographical area of ​​a radio network defined by the frequencies used in the cell for transmitting data. A UE can uniquely identify a cell based on an identification broadcast over the geographical area. Each base station 110, 111 can serve several UEs such as UE 101 or UE 151. (as discussed below) Once a UE has established an RRC connection with a base station, the base station to which the UE is connected is referred to as the serving base station or source base station of the UE, and the cell controlled by the serving base station and in which the UE resides is referred to as a serving cell. The interface between gNB and UE is the Uu interface, which uses: protocol sublayers SDAP (Service Data Application Protocol), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), PHY (Physical) in the user plane; and protocol sublayers RRC (Radio Resource Control), PDCP, RLC, MAC, PHY in the control plane.

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

[0050] The memory 225 includes RAM (Random Access Memory), ROM (Read Only Memory), or a combination of the two, or a mass storage device such as a disk or solid state drive as a non-limiting example. Basic Input Output System (BIOS) instructions may be stored in the memory 225.

[0051] The processor 215 is configured to execute machine-readable instructions. The execution of these machine-readable instructions causes the UE to perform various functions. These functions may involve transmission or communication with peripheral devices (such as keyboard, screen, mouse, etc.) Figure 2The processor may run an operating system such as iOS, Windows, Android, etc. The processor 215 may be a single processor, or may include two or more processors that perform the processing required for the operation of the UE 205. The number of processors and the allocation of processing functions to the processors are a matter of design choice for the skilled person.

[0052] I / O controller 255 enables these interactions with external peripheral devices by providing the required hardware and by managing input and output signals.

[0053] The transceiver 235 is configured to provide two-way wireless communications with other wireless devices. For example, it provides the necessary modem and frequency shifter required to connect to one or more wireless networks (such as Wi-Fi, Bluetooth, LTE, 5G NR, etc.).

[0054] The radio communication uses an antenna set 245 adapted to the frequency spectrum of the frequency transposed signal sent from the baseband modem. The antenna set 245 may be limited to one antenna, but preferably contains several antennas to provide beamforming capabilities.

[0055] The UE communication manager 220 handles the establishment of the UE's communication to the radio access network, its control and its release. The UE regularly receives from the base station an indication of the time slots available for communication between the UE and the base station. The UE then knows when and how often it expects incoming data or must send its outgoing data, whether the data belongs to the control plane or the data plane. In an example implementation, the UE communication manager 220 implements the Uu interface.

[0056] Figure 3 The base station device 305 (eg, Figure 1 1 and 111). 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, an antenna set 345, a memory 325, a processor (CPU) 315, and an inter-station communication manager 365. All of these components communicate with each other.

[0057] The base station communication manager 320 handles communications with multiple UEs. The base station communication manager 320 is responsible for the establishment, control and 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 different UE communications. Information about the scheduling of these time slots is regularly sent to the UEs involved.

[0058] The core network communication manager 355 manages the communication between the base station and the core network. The core network communication manager 355 may provide a standardized NG interface defined by the 3GPP standard to support these communications.

[0059] The transceiver 335 is configured to provide two-way wireless communication with other wireless devices. These devices can be UEs or even other base stations. The transceiver 335 provides the necessary modems and frequency shifters to connect to a large number of UEs simultaneously using different frequency carriers in time division duplex (TDD) or frequency division duplex (FDD). The transceiver 335 is connected to an antenna set 345, which can be limited to one antenna, but preferably includes several antennas to provide beamforming capabilities.

[0060] Memory 325 includes RAM, ROM, or a combination of both, or as non-limiting examples, a mass storage device such as a disk or solid state drive.BIOS instructions may be stored within memory 325 to support the operating system.

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

[0062] Figure 4 4 is a flow chart 400 showing RRC connection states and transitions of a UE in 5G NR. The RRC protocol operates between the UE and the base station (gNB) and is defined in the 3GPP specification TS 38.331 for 5G NR. For the new air interface, the state names of the UE are prefixed with "NR". For other radio interfaces such as the LTE radio interface, other prefixes are used. For simplicity, the radio technology prefixes are omitted in the rest of the description.

[0063] Radio Resource Control (RRC) is a layer within the 5G NR protocol stack. RRC only exists in the control plane, UE, and gNB. The behavior and functionality of the base station and UE are governed by the current RRC state of the UE. In 5G NR, three different RRC states are specified for the UE: RRC_IDLE state 401, RRC_CONNECTED state 402, and RRC_INACTIVE state 403.

[0064] At power-up, the UE is in RRC_IDLE state 401, the UE makes radio link quality measurements and performs a cell selection evaluation process (as defined in 3GPP specification TS 38.304) to identify a target gNB to connect to. When an RRC connection is established with the target gNB that becomes the source gNB serving the UE, the UE state changes to RRC_CONNECTED state 402. In the following, the source base station (or source gNB) may also be referred to as a serving base station or serving gNB. If there is no radio activity for a period of time, the RRC connection may be released by the source gNB and the UE's RRC state then changes back to RRC_IDLE state 401.

[0065] While releasing the RRC connection is interesting for capacity utilization and energy saving, it is not ideal from a latency perspective. The overhead of establishing an RRC connection requires additional signaling that introduces latency. To address this disadvantage, the RRC_INACTIVE state 403 has been introduced for 5G NR. When the UE is in the RRC_INNACTIVE state 403, the UE cannot communicate with the 5G system, but both the source gNB (e.g., the last serving gNB) and the UE store the UE context or configuration. The stored UE context or configuration includes information that facilitates fast recovery of the connection. The information may include security context (e.g., security parameters such as security keys, UE security capabilities), measurement configuration, radio configuration (e.g., UE radio capabilities), information about bearers, PDU session context, etc. Therefore, when in the RRC_CONNECTED state 402, the RRC connection may be suspended by the source gNB (with a pending release) and the UE moves to the RRC_INACTIVE state 403. From the RRC_INACTIVE state 403, the UE may be switched back to the RRC_CONNECTED state 402 (Resume) by the gNB and the UE applies the stored UE context or configuration. Upon receiving the RRC Resume Request message from the UE, the gNB sends the RRC Resume message.

[0066] From the RRC_CONNECTED state or the RRC_INNACTIVE state, the UE may transition to the RRC_IDLE state upon receiving an RRC release command from the gNB.

[0067] The mobility procedure to migrate a UE from one cell to another depends on the RRC state of the UE. In the RRC_CONNECTED state, the mobility procedure called handover is controlled by the network and the source gNB decides to trigger the handover procedure based on the measurement reports provided by the UE. In the RRC_INACTIVE and RRC_IDLE states (e.g., non-connected states), the mobility procedure is called cell reselection and is managed by the UE itself.

[0068] In the RRC_INACTIVE state, the UE may be configured with a RAN Notification Area (RNA) by the network. For example, the message that transitions the UE to the RRC_INACTIVE state contains information indicating the RNA. The RNA is an area in which the UE can move without notifying the network. When a UE in the RRC_INACTIVE state moves to a cell that is not part of its currently assigned RNA, the UE performs a location update procedure that enables the RAN (e.g., serving gNB) to update the RNA assigned to the UE. In other words, the UE has the possibility to request an RNA update to be informed of modifications to the RNA. When the UE selects a cell managed by a target gNB from the RNA as part of the cell reselection process, the UE sends a recovery request to the target gNB with three available options: keeping the UE in the RRC_INACTIVE state, setting the UE in the RRC_IDLE state, or setting the UE in the RRC_CONNECTED state.

[0069] In the RRC_IDLE state, the paging procedure is initiated by the core network to inform the UE that it must resume the connection. In the RRC_INACTIVE state, the paging procedure is initiated by the NG RAN (i.e., the last gNB that has set the UE in the RRC_INACTIVE state).

[0070] Return to Figure 1 , assuming that UE 101 is in RRC_INACTIVE state and it is receiving multicast data for one or more multicast MBS sessions generated by multicast application server 103. The multicast data is provided to base station 111, which is the base station for controlling cell 121 in which UE 101 is camping, via core network 102 and transport bearer (also known as GTP-U tunnel) 106 on link 141. The multicast data is then transmitted by base station 111 to UE 111 via MBS radio bearer (MRB) 154. Figure 1Also shown is UE 151 receiving data via MRB 153. In point-to-multipoint transmission of data from base station 111, MRB 154 is the same MRB as MRB 153. In point-to-point transmission, MRBs 154 and 153 are different. A radio bearer is a collection of PHY (layer 1) and MAC (layer 2) parameters that allow a higher layer data connection between a UE and a gNB. In 5G NR, multiple types of radio bearers are defined: SRBs (Signalling Radio Bearers) for the control plane, DRBs (Data Radio Bearers) that allow point-to-point communication with one UE in the user plane (unicast), and MRBs that allow point-to-point and point-to-multipoint communication with multiple UEs also in the user plane (multicast / broadcast).

[0071] The MBS Session Join procedure as specified in 3GPP TS23.247 is used by the UE to inform the 5GC of its interest in joining a multicast MBS session. The first accepted UE join request triggers the establishment of a multicast MBS session towards the NG RAN and the UE. Before sending a join request for a multicast MBS session, the UE should have established a PDU session that can be associated with (one or more) multicast sessions using the procedure as specified in TS23.502. In addition, the UE should know at least the MBS session ID of the multicast group that the UE can join via the service announcement broadcast by the network. In order to join the multicast group, the UE sends a PDU session modification request for the associated PDU session, which contains one or several MBS session IDs and a join request. The (one or more) MBS session IDs indicate the (one or more) multicast MBS session that the UE wants to join.

[0072] In order to join an MBS session, the UE must be in RRC_CONNECTED state.

[0073] Figure 5a and Figure 5b Together, example message flows for an example scenario of MBS session evolution from creation to activation are illustrated. Figure 5a illustrates an example message flow for MBS session creation and establishment, and Figure 5b An example message flow for MBS session activation is illustrated.

[0074] First reference Figure 5a , a UE (e.g., UE 101 (or it may be UE 151)) is powered on and enters RRC_IDLE state 500. During step 501, as a result of the cell selection process defined in TS 38.304 clause 5.2.3, the UE connects to the nearest gNB (e.g., at Figure 1 111). Once connected to the gNB, the UE enters the RRC_CONNECTED state 502. The UE then performs a registration process or procedure 503, which aims to identify the UE in the core network or 5GC 102, check the UE subscription and perform authorization. The registration process is detailed in TS 23.502 clause 4.2.2.2.

[0075] 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 that allows access to 5G core services. This PDU session can then be associated with an MBS session. The PDU session establishment procedure is defined in TS23.502 clause 4.3.2.

[0076] The AF (Application Function) 104 in the 5G Core 102 creates a multicast session based on the requirements of the Application Server 103. The MBS Session Creation Procedure 505 for creating a multicast session is defined in TS 23.247 clause 7.1.1. The session creation is driven by the AF 104 (Application Function) and when completed, the result is the allocation of an MBS Session ID (e.g., TMGI for a Temporary Mobile Group Identity) for the multicast session and session creation.

[0077] Once the multicast session is created, the AF 104 performs a service announcement 506 to the UE, for example, the AF 104 sends a service announcement message. The service announcement message includes multicast session information, which includes multicast MBS session ID, service area description (or information) and session description information, etc. Service announcements are described in TS23.247 clause 6.11. Some UEs may not need to receive service announcement messages: for example, the service information provided in the service announcement may be pre-configured at some UEs. In addition, UEs that are not connected at the time of the service announcement can access the service information by directly soliciting the AF 104 (application function) or MBSF (MBS service function) in the core network 102.

[0078] There is no timing dependency between the UE connection / registration / PDU session establishment process (collectively identified by reference numeral 521) and the MBS session creation / notification process (collectively identified by reference numeral 522). Both 521 and 522 are performed independently of each other and can occur at any time.

[0079] Once the UE 101 is registered in the core network 102 and a default PDU session is established and the multicast service information is known, the UE may send or make a join request 507 to the core network 102 to log in to the multicast session. The UE may request the service announcement message 506, or by pre-configuration, or by soliciting information from the core network. Figure 5a or Figure 5b The UE may also use a PDU session modification request to modify the multicast session information (e.g., the message flow for pre-configuring or requesting session information is not shown in the figure), know the multicast session information (such as the multicast MBS session ID as described above, etc.). In order to join the multicast session, the UE may reuse the default PDU session created earlier (at 504) and send a PDU session modification request including the multicast session ID (TMGI). The PDU session modification request is then considered a join request (507). Another possibility is to establish a dedicated MBS PDU session including the multicast session ID for the join request 507.

[0080] When the core network 102 receives the join request 507, the core network 102 performs a multicast session establishment procedure 508. During the session establishment procedure 508, the core network 102 verifies the subscription and authorization level of the UE to check whether the UE is allowed to access the multicast session (i.e., check whether the UE is one of the UEs of the specific multicast group that is authorized to receive the multicast session). In addition, as part of the session establishment procedure 508, the core network 102 will set up the necessary resources in the core network to transmit the multicast data from the application server 103 to the relevant gNB. The relevant gNB is defined by the multicast service area information established in the 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.

[0081] exist Figure 5a In the example shown, the gNB of the NG-RAN (e.g., gNB 111) decides to switch UE 101 to the RRC_INACTIVE state 510 by sending an RRCRelease message 509 (TS 38.331 clause 6.2.2). The most common reason is load management, and the gNB may decide to offload its control plane load by switching some UEs to RRC_INACTIVE. In addition, ongoing discussions for Release 18 suggest that both the UE and the core network provide additional information to the gNB to assist the gNB in ​​making the decision to switch some UEs to the RRC_INACTIVE state. The additional information may include capability information from both the UE and the core network indicating the ability to send or receive multicast data in the RRC_INACTIVE state. Other information may also be provided by the UE to indicate the preferred state for receiving multicast data: i.e., RRC_INACTIVE or RRC_CONNECTED.

[0082] Now also refer to Figure 5b, while the UE is in RRC_INACTIVE state 510, the UE will perform a cell reselection process 511 as a background task. This process manages the UE mobility which allows "reselecting" a new gNB based 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 gNB 110 or gNB 111 based on UE mobility.

[0083] Once the MBS session is created (505), the AF 104 (Application Function) in the core network 102 can be triggered to activate the multicast session (i.e., MBS session activation 512). The trigger for activating the multicast session is independent of the joining and session establishment procedures (identified collectively by reference numeral 523). One possible trigger is the availability of data from the application server 103. Multicast session activation is described in TS23.247 clause 7.2.5.2. The main result of this process is the reservation of RAN (Radio Access Network) resources for the gNB. These resources allow the communication of multicast data to UEs that have joined the multicast session. The RAN resource allocation includes MRB configuration (MBS Radio Bearer Configuration). Each gNB will use a specific configuration for the MRB for the multicast session.

[0084] Once the multicast session is activated upon completion of MBS session activation 512, the core network 102 may need to page some UEs to inform them of the availability of multicast data. The RRC_INACTIVE UEs need to be paged because, as illustrated in 510, the RRC_INACTIVE UEs are still moving and may enter the cell of another gNB, but neither the new gNB (target gNB) nor the first gNB (source gNB) is aware of the UE movement at this step (i.e., upon activation of the multicast session 512). The core network 102 sends a group paging request with the MBS session ID ( Figure 5b The 513 group paging request is sent to the gNB together with the multicast session ID (not shown). This sequence is described as step 5 in TS 23.247 clause 7.2.5.2.

[0085] Upon receiving the group paging message 513 , the RRC_INACTIVE UE shall prepare to resume the RRC connection during process 515 .

[0086] As part of the RRC connection recovery preparation, UE 101 performs a random access procedure to the gNB (PRACH procedure 516, PRACH stands for Physical Random Access Channel). The PRACH procedure is intended to update the UE's system information in the event that the UE has moved to another cell or if the system information has not been updated for a period of time. UE 101 then performs and completes the connection recovery procedure in 517, which includes sending an RRCResumeRequest message ( Figure 5b The connection recovery process 517 follows the RRC connection process defined in detail in TS 38.331.

[0087] Once the RRC connection procedure is completed, the UE is in RRC_CONNECTED state 518.

[0088] Only in this step, when UE 101 is in RRC_CONNECTED state 518, gNB 111 can send multicast configuration (including MRB information) to the UE (step 519), which includes sending an RRCReconfiguration message including MRB information (TS38.331 clause 6.2.2).

[0089] Once the UE applies the received multicast configuration, the UE may receive the multicast data in 520 .

[0090] As discussed in the introduction, in the case where the UE must switch from the RRC_INACTIVE state to the RRC_CONNECTED state to be configured for multicast reception, the additional signaling and other resources required to configure the UE in the RRC_CONNECTED state increase the load problem at the NG-RAN node (gNB) (i.e., too many UEs are in the RRC_CONNECTED state), and thus the benefit of switching the UE to the RRC_INACTIVE state to avoid congestion is lost or at least reduced. For example, as discussed above, the paging, PRACH, MBS configuration process that reverts to the RRC_CONNECTED state may lead to link congestion and latency issues.

[0091] Reference now Fig. 9 , which shows the steps of a method 900 for configuring a UE of a wireless communication system to set up multicast reception according to an embodiment of the present invention, the method being performed by the UE. The wireless communication system may be, for example, Figure 1 The wireless communication system 100 of FIG. 1 , and the UE may be UE 101 and may include Figure 2 UE 205 , wherein method 900 is performed by processor 215 .

[0092] UE 101 is operating in a non-connected radio resource control (RRC) state (such as RRC_INACTIVE state) and has previously joined one or more multicast sessions. For example, as discussed above, UE 101 has performed a join session procedure by sending a join request 507 (such as a PDU session modification request including a multicast session ID or by establishing a dedicated MBSPDU session) to core network 102. The multicast session to be configured for the UE is not currently activated, so the UE is in a non-connected state or RRC_INACTIVE state. As discussed above with reference to Figure 4 As discussed, in the non-connected RRC state (e.g., RRC_INACTIVE state), the UE 101 cannot communicate with the core network 102, but the UE context or configuration is stored at the UE and the RAN (e.g., if the UE has not moved or has not moved out of the cell controlled by the last serving gNB, then at the last serving gNB, which may be controlling the cell in which the UE is currently residing), and this information helps to accelerate the transition of the UE to the connected state. Figure 1 In the example shown, UE 101 resides in cell 121 controlled by base station 111 or gNB 111.

[0093] Briefly, at step 901, a UE (eg, UE 101) receives a notification indicating that a multicast session that the UE has previously joined has been activated. In the example and as described below with reference to Figure 6 and Figure 7 Discussed in more detail, the core network 102 activates a multicast session (e.g., when there is multicast data to be sent), and in response to the MBS session activation, a notification is sent from the core network 102 to the UE via a base station (e.g., a gNB serving a cell covering an MBS service area for the multicast session). The notification (e.g., Figure 6 and Figure 7The group paging message 603 may include an identifier for identifying the activated multicast session (e.g., MBS session ID and / or TMGI), and may include information indicating that the multicast session has been activated (e.g., MBS session activation cause information (which indicates that the reason for the notification is the activation of the multicast MBS session)). The notification may be a paging message (such as group paging), which may include a field that may be set to "mbs session activated" when the multicast session is activated. As described above, the paging message is sent by all gNBs covering the multicast service area, so the UE 101 may receive the paging message from at least one of the gNBs covering the multicast service area (such as gNB 111) at step 901. In the case where the UE is in the RRC inactive state, when the multicast session is activated, the network does not know where the UE is located (e.g., the UE may have changed cells), so sending the notification (e.g., paging message) helps to notify the UE (and other UEs in various cells of the MBS service area that have previously joined the multicast session) of the multicast session activation.

[0094] After receiving the notification of the multicast session activation, the UE may determine, based on information included in the notification (e.g., based on an identifier for identifying the activated multicast session and / or based on the presence of information indicating that the multicast session has been activated (if included in the notification)), whether the notification indicates that a multicast session that the UE has previously joined has been activated. If the identifier for identifying the activated multicast session included in the notification matches an identifier of a multicast session that the UE has previously joined (which is stored in the UE when the joining process is completed) and / or the information indicates that the multicast session has been activated, the UE determines that the notification does indicate that the multicast session that the UE has previously joined has been activated.

[0095] In an example, after receiving the notification of the multicast session activation, and, for example, in response to determining that the notification indicates that a multicast session that the UE had previously joined has been activated, UE 101 may perform a random access procedure to a base station that is controlling the cell in which UE 101 is currently camped (e.g., referred to as a source base station or a serving base station). Figure 1 In the example shown, the source base station for UE 101 camping in cell 121 is gNB 111. The random access procedure may be a PRACH (Physical Random Access Channel) procedure as defined in TS 38.311 clause 5.2.2.3.3 to update the system information of the UE when needed. For example, the system information of the UE (e.g., the context information of the UE) may need to be updated when the system information is out of date, which may occur when certain conditions are met (such as when the UE has moved to another cell or when the system information has not been updated for a period of time).

[0096] After receiving the notification of the multicast session activation, and, for example, in response to determining that the notification indicates that a multicast session that the UE has previously joined has been activated, the UE then sends or transmits an MBS configuration request message at step 902, the MBS configuration request message being used to request configuration information for receiving multicast data in a non-connected RRC state (such as an RRC_INACTIVE state) for the activated multicast session. In response to receiving the notification, the MBS configuration request message is sent to a base station (e.g., a source base station or a serving base station) for controlling a cell in which the UE resides. For example, for Figure 1 In the embodiment of the present invention, UE 101 sends an MBS configuration request message to source gNB 111, the MBS configuration request message being used to request configuration information for receiving multicast data in a non-connected RRC state (such as RRC_INACTIVE state) for an activated multicast session. As discussed in more detail below, the MBS configuration request message may be a new RRC message or a RRCResumeRequest message or a system information block (SIB) reception request.

[0097] MBS configuration request message (eg, Figure 6 and Figure 7 The MBS configuration request message 607 may include an identifier for identifying the activated multicast session (e.g., an MBS session ID and / or a temporary mobile group identity (TMGI)). In other words, an identifier for indicating the MBS session for which configuration is requested. In addition, the MBS configuration request message may include UE identification information (such as IMSI, IMEI) for identifying the UE 101 and / or authentication information (ueMAC-I) (such as an authentication token) for authenticating the UE 101.

[0098] At step 903, UE 101 receives an MBS configuration message including configuration information for configuring the UE to receive multicast data in a non-connected RRC state (such as an RRC_INACTIVE state) for an activated multicast session. In response to receiving the MBS configuration request message, the MBS configuration message is sent by a base station (e.g., a source base station or a serving base station) for controlling the cell in which the UE resides. For example, Figure 1 In an arrangement of , UE 101 receives an MBS configuration message from gNB 111 for configuring the UE to receive multicast data in a non-connected RRC state (such as RRC_INACTIVE state) for an activated multicast session. As discussed in more detail below, the MBS configuration message (e.g., Figure 6 and Figure 7The MBS configuration message 609) may be an RRCReconfiguration message or an RRCRelease message with a suspended configuration or an RRCRecume message or an SIB message.

[0099] 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 gNB 111 for an activated multicast session). Note that one or more MRBs may be associated with one MBS session. The MRB configuration information may include Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP) setup information.

[0100] In response to receiving the MBS configuration message, UE 101 configures UE 101 to receive multicast data in a non-connected RRC state (e.g., RRC_INACTIVE state) based on the configuration information in the received MBS configuration message. In other words, UE 101 performs radio bearer configuration and configures itself (e.g., sets the user plane in UE 101 according to the radio configuration of the base station) to receive multicast data of the activated multicast session from the base station (e.g., source gNB 111).

[0101] Once UE 101 is configured, UE 101 can receive data from gNB 111 for the multicast session.

[0102] Steps 901, 902, and 903 are performed while UE 101 is operating in a non-connected RRC state (e.g., RRC_INACTIVE state). In addition, configuration of UE 101 and reception of multicast data by the UE are also performed while UE 101 is operating in a non-connected RRC state (e.g., RRC_INACTIVE state). Therefore, UE 101 remains in the RRC_INACTIVE state during the entire process and is able to obtain necessary configuration for multicast data reception from the network (e.g., gNB 111 or core network 102) as soon as the network is available.

[0103] Now also refer to Fig.10 , which illustrates steps of a method 1000 for configuring a UE of a wireless communication system to set up multicast reception according to an embodiment of the present invention. The method 1000 is performed at a base station (e.g., a source base station or a serving base station) that controls a cell in which one or more UEs are camping. The wireless communication system may be, for example, Figure 1 A wireless communication system 100. Figure 1 In the example shown in , the base station performing method 1000 may be base station 111 or gNB 111 controlling cell 121, and one or more UEs include UEs 101 and 151 currently residing in cell 121 (current serving cell). The base station may include Figure 3 Base station 305, wherein method 1000 is performed by processor 315. As mentioned above Fig. 9 As discussed, UE 101 is operating in a non-connected radio resource control (RRC) state, such as the RRC_INACTIVE state, and has previously joined one or more multicast sessions.

[0104] Briefly, at step 1001, a base station (e.g., gNB 111) sends a notification indicating that a multicast session has been activated. In the example and as described below with reference to Figure 6 and Figure 7 As discussed in more detail, as part of the MBS session activation process (e.g., Figure 5a 512 and Figure 6 In the MBS session activation process shown as 602 in TS 23.247, which is described in further detail in clause 7.2.5, the core network 102 activates a multicast session (e.g., when there is multicast data to be sent) and sends an MBS session activation message (e.g., a group paging request) to a base station (e.g., a gNB) serving a cell covering an MBS service area for the multicast session (e.g., identified by an MBS session ID), which informs the base station of the MBS session activation and requests the base station to notify RRC_INNACTIVE UEs that have previously joined the multicast session of the MBS session activation. In response to the message from the core network 102, the base station 111 (together with other base stations covering the MBS service area) sends a notification indicating that the multicast session that the UE has previously joined has been activated. The notification sent by the base station may include an identifier for identifying the activated multicast session (e.g., an MBS session ID and / or a TMGI), and may include information indicating that the multicast session has been activated (e.g., MBS session activation cause information (which indicates that the reason for the notification is the activation of a multicast MBS session)). The notification may be a paging message (such as a group paging) which may include a field that may be set to "mbs session activated" when a multicast session is activated. Figure 1 In the example, the base station or gNB 111 sends a paging message at step 1001, which should be received by at least the UE located in the cell 121 served by gNB111.

[0105] In an example, a base station or gNB may determine whether a UE is capable of receiving multicast in an RRC_INACTIVE state and whether AF 104 (application function) allows the UE in the RRC_INACTIVE state to receive multicast data. If the gNB determines that the UE is capable of receiving multicast in an RRC_INACTIVE state and AF 104 (application function) allows the UE in the RRC_INACTIVE state to receive multicast data, the gNB may send a group paging message including an identifier for identifying an activated multicast session (e.g., MBS session ID and / or TMGI) and information indicating that the multicast session has been activated (e.g., MBS session activation cause information (which indicates that the cause of the notification is the activation of a multicast MBS session)) (i.e., an enhanced group paging message). Otherwise, if the gNB determines that the UE is not capable of receiving multicast in an RRC_INACTIVE state or AF 104 (application function) does not allow the UE in the RRC_INACTIVE state to receive multicast data, the gNB sends a group paging message including an identifier for identifying an activated multicast session (e.g., MBS session ID and / or TMGI) and information indicating that the multicast session has been activated (e.g., MBS session activation cause information (which indicates that the cause of the notification is the activation of a multicast MBS session)). Figure 5b The gNB uses the standard group paging message 513 defined in . Since session establishment 523, both UE and AF capabilities are known at the gNB. The gNB may also take into account the UE preference (also known at session establishment) to receive in connected mode or non-connected mode.

[0106] Upon receiving the notification, each UE may determine, based on the identifier for the activated multicast session and the presence of information indicating that the multicast session has been activated, whether the notification indicates that a multicast session that the UE has previously joined has been activated.

[0107] At step 1002, the base station 111 receives an MBS configuration request message for requesting configuration information for receiving multicast data in a non-connected RRC state (such as an RRC_INACTIVE state) for an activated multicast session. The MBS configuration request message is received from at least one UE among one or more UEs, the at least one UE being operated in a non-connected RRC state (such as an RRC_INACTIVE state) and having previously joined the multicast session: for example, the at least one UE may be a UE 101 that is camped in the cell 121 and is operating in the RRC_INACTIVE state and has previously joined the activated multicast session. In response to receiving a notification from the base station and determining that the notification indicates that the multicast session to which the at least one UE has previously joined has been activated, the at least one UE 101 sends the MBS configuration request message. As described above with reference to Fig. 9 As discussed and as discussed in more detail below, the MBS configuration request message may be a new RRC message or a RRCResumeRequest message or a system information block (SIB) reception request.

[0108] The MBS Configuration Request message may include an identifier (e.g., MBS session ID and / or TMGI) for identifying the activated multicast session. In other words, an identifier for indicating the MBS session for which configuration is requested. In addition, the MBS Configuration Request message may include UE identification information (such as IMSI, IMEI) for identifying at least one UE 101 and / or authentication information (ueMAC-I) (such as an authentication token) for authenticating at least one UE 101.

[0109] In an example, upon receiving the MBS configuration request message, the base station or gNB 111 processes the MBS configuration request message, which may include collecting or obtaining necessary information to construct a UE configuration for at least one UE so that 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), at step 1003, the base station or gNB 111 sends an MBS configuration message to the at least one UE. The MBS configuration message includes configuration information for configuring the at least one UE to receive multicast data in a non-connected RRC state (such as an 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 UE 101 to communicate multicast data for the activated multicast session). Note that one or more MRBs may be associated with one MBS session. The MRB configuration information may include packet data convergence protocol (PDCP) and service data adaptation protocol (SDAP) setup information.

[0110] The MBS configuration message is sent by a base station (eg, a source base station or a serving base station) for controlling a cell in which the UE resides to the at least one UE, and is sent in response to receiving an MBS configuration request message from the at least one UE. Figure 1 In an arrangement where UE 101 has sent an MBS configuration request message, gNB 111 sends an MBS configuration message to UE 101, the MBS configuration message being used to configure UE 101 to receive multicast data in a non-connected RRC state (such as RRC_INACTIVE state) for an activated multicast session. Fig. 9 And as discussed in more detail below, the MBS configuration message may be an RRCReconfiguration message or an RRCRelease message with a suspended configuration or an RRCResume message or a SIB message.

[0111] In the case where more than one UE is in a non-connected RRC state and has previously joined the same multicast session and resides in the same cell controlled by a base station, in response to a notification sent by the base station and the notification including a multicast session identifier for the multicast session, each UE that has previously joined the multicast session (and therefore has knowledge of the multicast session identifier) ​​sends an MBS configuration request message to the base station controlling the cell. The base station then sends an MBS configuration message to each UE in response to a corresponding MBS configuration request message received at the base station.

[0112] By sending a notification indicating that a multicast session has been activated when the MBS session is activated, the UE can determine that the notification relates to the MBS session activation, and this helps prevent the UE from automatically initiating an RRC recovery procedure and switching to the RRC_CONNECTED state. In addition, by configuring the UE in the RRC_INACTIVE state after being notified that the multicast session has been activated, it is possible to avoid requiring the UE to switch to the RRC_CONNECTED state when the multicast MBS session is activated, which means that the number of UEs in the RRC_CONNECTED state can be reduced, thereby reducing congestion at the gNB. In addition, in the example where the notification sent by the base station is a group paging message, using a group paging message is simpler than having to page all UEs individually, but a compromised UE may pretend to have joined the session earlier to tamper with the multicast session. By having the UE run the MBS Configuration Request / Response protocol to request MBS configuration, the gNB is able to perform an access authorization check and can deny configuration to the compromised UE (e.g., by not responding to an MBS Configuration Request message sent by the compromised UE).

[0113] Now also refer to Figure 6 , which shows an example message flow according to an example embodiment of the present invention. Figure 1 The wireless communication system describes the message flow in Figure 1 In the figure, the UE is UE 101, the NG RAN is gNB 110 (when UE 101 is in cell 121) or gNB 111 (when UE 101 is in cell 120), the 5GC is the core network 102 and the application server is the MBS application service 103.

[0114] In this example, as referenced above Figure 5a As described, processes such as UE registration 521 , MBS session creation 522 , UE join 523 , and UE switching to RRC_INACTIVE 509 have occurred.

[0115] UE 101 in RRC_INACTIVE state 600 performs a cell reselection process 601 as a background task. This process manages UE mobility that allows "reselection" of a new gNB based 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 serving the cell where UE 101 is camping based on UE mobility is gNB 110 or gNB 111.

[0116] The AF 104 (Application Function) in the core network 102 may be triggered to activate a multicast session (MBS Session Activation 602). Multicast session activation is described in TS 23.247 clause 7.2.5.2. The main result of this process is the reservation of RAN (Radio Access Network) resources by the gNB. These resources allow the communication of multicast data to UEs that have joined the multicast session. The RAN resource allocation includes the MRB configuration (MBS Radio Bearers) used to communicate the multicast data.

[0117] Once the multicast session is activated, the core network 102 may need to page some UEs to inform them of the availability of multicast data. The need to page the RRC_INACTIVE UE is because, as explained in 601, the RRC_INACTIVE UE is still moving and may enter the cell of another gNB, but neither the new gNB (target gNB) nor the first or last serving gNB (source gNB) knows that the UE has moved at this step, and therefore does not know in which cell the UE is currently located. The core network 102 sends a group paging request with an MBS session ID (not shown in the figure) to the gNB, and then each gNB sends a group page to the RRC_INACTIVE UE (as described above with reference to Fig. 9 and Fig.10 As discussed above, group paging is an example of a notification sent by the gNB to the UE. Figure 5bUnlike the processing of the paging message described above (e.g., the processing paging 515 of the group paging message 513), according to an embodiment of the present invention, the UE should not request to resume the RRC connection in response to the paging message (to remain in the non-connected RRC state), and therefore the group paging sent by the gNB is enhanced so that the UE can adopt a different behavior when processing the paging message than the behavior described above for the processing paging in 515. In order to reach the RRC_INACTIVE UE, each gNB can send a group paging / paging message or notification 603 that includes a multicast session activation paging cause indicating that the multicast session has been activated in addition to the multicast session ID for identifying the activated multicast session. The multicast session ID is, for example, a TMGI (temporary mobile group identity) obtained as a result of the MBS session creation 522. Note that in the example, the destination UE is not explicitly listed by ue_identity (i.e., the UE identity assigned by the upper layers) in the notification 603, which is why the notification 603 can be considered as a group paging message.

[0118] In an example, a base station or gNB may determine whether a UE is capable of receiving multicast in an RRC_INACTIVE state and whether AF 104 (application function) allows the UE in the RRC_INACTIVE state to receive multicast data. If the gNB determines that the UE is capable of receiving multicast in an RRC_INACTIVE state and AF 104 (application function) allows the UE in the RRC_INACTIVE state to receive multicast data, the gNB may send a group paging message (i.e., an enhanced group paging message) including an identifier for identifying an activated multicast session (e.g., an MBS session ID and / or TMGI) and information indicating that the multicast session has been activated (e.g., MBS session activation cause information indicating that the cause of the notification is the activation of a multicast MBS session). Otherwise, if the gNB determines that the UE is not capable of receiving multicast in an RRC_INACTIVE state or AF 104 (application function) does not allow the UE in the RRC_INACTIVE state to receive multicast data, the gNB sends a group paging message such as Figure 5b The gNB uses the standard group paging message 513 defined in . Both UE and AF capabilities are known at the gNB from session establishment 523. The gNB may also take into account the UE preference (also known at session establishment) of receiving in connected or non-connected mode.

[0119] Based on 3GPP TS 38.331 version 17.0.0, section 5.3.2.3, the UE may receive a paging message as follows:

[0120] 1> For each TMGI included in the pagingGroupList (if any) included in the paging message:

[0121] 2> If the UE has joined the MBS session indicated by the TMGI included in the pagingGroupList:

[0122] 3>Forward TMGI to the upper layer;

[0123] 1> if in RRC_INACTIVE and the UE has joined one or more MBS sessions indicated by the TMGI included in pagingGroupList; and

[0124] 1> If none of the ue-Identities included in any PagingRecord (if included in the paging message) matches the UE identity assigned by the upper layer:

[0125] 2> If MBS_session activation is included in the paging cause

[0126] 3> Initiate RRC_INACTIVE multicast reception process according to 5.3.X (for example, as referenced Figures 6 to 10 and / or discussed below in the discussion of example procedures for configuring a UE for multicast reception with reference to sections and clauses of TS 38.331 Version 17.0.0)

[0127] 2> otherwise , initiate the RRC connection recovery process according to 5.3.13, where resumeCause is set as follows:

[0128] 3> If the UE is configured with access identification 1 by the upper layer:

[0129] 4>resumeCause is set to mps-PriorityAccess;

[0130] 3> Otherwise, if the UE is configured with access identifier 2 by upper layers:

[0131] 4>resumeCause is set to mcs-PriorityAccess;

[0132] 3> Otherwise, if the UE is configured by upper layers with one or more access identifiers equal to 11-15:

[0133] resumeCause is set to highPriorityAccess;

[0134] 3> Otherwise:

[0135] 4>resumeCause is set to mt-Access.

[0136] The paging message can be as follows:

[0137]

[0138]

[0139] Upon receiving the new group paging message 603, the UE detects both the multicast session ID (TMGI) and the multicast session activation paging cause in the group paging message 603, and then performs process 604. For each UE (such as UE 101) that has joined the multicast session identified by the multicast session ID, process 604 includes preparing to start receiving multicast data and remaining in the RRC_INACTIVE state.

[0140] Then optionally, UE 101 performs a random access procedure to the gNB (such as PRACH procedure 517, PRACH stands for Physical Random Access Channel). This procedure allows UE 101 to update its system information when needed.

[0141] UE 101 then sends an MBS configuration request message 607 to invite gNB 111 to send configuration information to allow UE 101 to receive multicast data corresponding to the activated session as signaled in the paging message 603.

[0142] Whenever the gNB receives an MBS Configuration Request message from the UE, the gNB prepares an MBS Configuration message 609 and sends the MBS Configuration message 609 to the UE 101 in response. In this message, the UE will find the MBS radio bearer configuration parameters to be applied to receive multicast data corresponding to the activated MBS session. The MBS Radio Bearer Information Element includes the PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol) setup information determined at the radio resource reservation. Once the MBS radio bearer configuration is completed at the UE 101, multicast data 610 can be received while remaining in RRC_INACTIVE mode.

[0143] Figure 7 is a flowchart illustrating an example method performed by a UE according to an example of an embodiment of the present invention. The method may be performed by Figure 2 UE 205 (eg, CPU 215 executing instructions stored in memory 225) executes and corresponds to handling Figure 6 Message flow 603 to 610.

[0144] First, during step 700, the communication manager 220 receives an incoming frame from the transceiver 235 and decodes it into a paging message (e.g., paging message 603) from the base station (110, 111) received on the PCCH (Paging Control Channel). The paging message format is defined in TS 38.331 clause 6.2.2 (except for the paging cause field, which is modified in this example of an embodiment of the present invention to add a new cause called "mbs session activation").

[0145] During step 701, UE 205 checks whether the TMGI (temporary mobile group identity) of the multicast session it joined in 523 is present in the PagingGroupList-r17 field of the received paging message. The TMGI is used as a multicast session ID to identify the activated multicast session and is stored in the memory 225. If the stored TMGI of the UE is not found in the paging message 603 (branch "No" at step 701), the process ends (step 709).

[0146] If the stored TMGI of the UE is found in the paging message (branch "yes" at step 701), the ue_identity field of each PagingRecord field of the received paging message is compared with the UE's own identity during step 702. If the ue_identity field matches the UE's own identity defined by the upper layer (branch "no" at step 702), the process ends (step 709).

[0147] Otherwise, when the ue_identity field does not match the UE's own identity defined by the upper layer (branch "yes" at step 702), during step 703, the paging cause field of the paging record is read. If the paging cause is not set to "mbs session activation" (branch "no" at step 703), during step 704, the RRC connection is restored according to clause 5.3.13 of TS 38.331.

[0148] In another example where the TMGI and the paging cause are included in the paging message, step 702 may be omitted because the UE may determine whether the paging message is related to an MBS session that the UE has joined and activated based on the TMGI and the paging cause, without checking the match of the ue_identity field. Step 702 may be performed to ensure backward compatibility with previous releases, where a UE with a matching UE identity is required to switch to RRC_CONNECTED.

[0149] If the paging cause is set to "mbs session activation" (branch "yes" at step 703), the relevance of the system information stored in the memory 225 of the UE is evaluated during step 705. If the gNB selected during the cell reselection process 511 / 601 is different from the gNB that performed the RRC connection release 509, the UE's system information is obsolete. In addition, if the gNB has not changed between 509 and 511 / 601, but if a long time has passed since the RRC connection release 509, the UE's system information is also considered obsolete.

[0150] If the system information is determined to be obsolete and therefore needs to be updated (branch "yes" at step 705), then during step 706, the UE 205 will update the system information by performing a PRACH (Physical Random Access Channel) procedure as defined in TS 38.311 clause 5.2.2.3.3.

[0151] When the system information is updated (706) or evaluated as relevant (branch "No" at step 705), step 707 is performed. During this step 707, the UE 205 sends an MBS configuration request message 607 to invite the gNB (e.g., gNB 111) to send configuration information to allow reception of multicast data corresponding to the activated session as signaled in the received paging message 603.

[0152] In one example, the MBS configuration request message 607 is implemented as a new RRC message sent on the signaling radio bearer 0 on CCCH (Common Control Channel). The message includes at least the identifier (e.g., TMGI) of the activated multicast session as received in the paging message 603, and may also include the UE identity as stored in the system information. For example, the UE identity may be a Short I-RNTI (Inactive-Radio Network Temporary Identifier) ​​value or a Full I-RNTI value.

[0153] Alternatively, the MBS Configuration Request message 607 is implemented as a modified RRCResume request message as defined in TS 38.331 clause 6.2.2 with an additional field containing the TMGI.

[0154] Then during step 708, the UE 101 receives an MBS Configuration message 609 from the gNB. In this MBS Configuration message 609, the UE 205 will find the MBS radio bearer configuration parameters to be applied to receive multicast data corresponding to the MBS session activation notified in the paging message 603. The details of the MBS Radio Bearer Information Elements can be found in TS 38.331 clause 6.3.2. The MBS Radio Bearer Information Elements include PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol) setup information and allow the UE to receive multicast data while remaining in the RRC_INACTIVE state.

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

[0156] Once the MBS radio bearer configuration is completed, multicast data may be received while remaining in RRC_INACTIVE mode, and the process ends (step 709).

[0157] Figure 8 is a flowchart illustrating an example method performed by a base station (e.g., a gNB) according to an example of an embodiment of the present invention. The method may be performed by Figure 3 The base station 305 (eg, by the CPU 315 executing instructions stored in the memory 325) executes and corresponds to the processing Figure 6 Message flow 603 to 610.

[0158] During step 800, the base station or gNB 305 receives a multicast session activation notification or message as part of the MBS session activation 512 / 602 from the core network 102. This step is further detailed in TS 23.247 clause 7.2.5. It includes the reservation of radio resources by the gNB to allow the sending of multicast data on the radio network to reach the UE.

[0159] As part of the session activation process, the core network 102 requests the gNB (305, 110, 111) to send a paging message to the RRC_INACTIVE UE that has previously joined the multicast session to inform the UE that the multicast session has been activated. During step 801, each gNB 305 sends a paging message (e.g., paging message 603), which may include a PagingGroupList-r17 field containing the TMGI (temporary mobile group identity) of the multicast session activated and signaled in 512 / 602. The TMGI is used as a multicast session ID to identify the activated multicast session. The paging cause field (e.g., PagingRecord field) of the paging message should be set to "mbs session activation". The paging message format is defined in TS 38.331 clause 6.2.2 (in addition to the paging cause field, which is modified in this example embodiment of the present invention to add a new cause field called "mbs session activation"). The gNB shall enter the UE's identity in the eu_identity field of the paging message to identify the RRC_INACTIVE UE that has previously joined the multicast session.

[0160] In an example, a base station or gNB may determine whether a UE is capable of receiving multicast in an RRC_INACTIVE state and whether AF 104 (application function) allows the UE in the RRC_INACTIVE state to receive multicast data. If the gNB determines that the UE is capable of receiving multicast in an RRC_INACTIVE state and AF 104 (application function) allows the UE in the RRC_INACTIVE state to receive multicast data, the gNB may send a group paging message (i.e., an enhanced group paging message) including an identifier for identifying an activated multicast session (e.g., an MBS session ID and / or TMGI) and information indicating that the multicast session has been activated (e.g., MBS session activation cause information indicating that the cause of the notification is the activation of a multicast MBS session). Otherwise, if the gNB determines that the UE is not capable of receiving multicast in an RRC_INACTIVE state or AF 104 (application function) does not allow the UE in the RRC_INACTIVE state to receive multicast data, the gNB sends a group paging message such as Figure 5b The gNB uses the standard group paging message 513 defined in . Both UE and AF capabilities are known at the gNB from session establishment 523. The gNB may also take into account the UE preference (also known at session establishment) to receive in connected or non-connected mode.

[0161] During step 802, the gNB 305 waits for a message from an RRC_INACTIVES UE that is located in the cell served by the gNB 305 and that has previously joined the multicast session.

[0162] Some UEs may have joined the multicast session while being in another cell, and some other UEs may have joined the multicast session within the cell of the gNB, but a considerable amount of time has passed without refreshing their system information. In both cases, the system information for these UEs will likely be out-of-date (i.e., obsolete) and will need to be updated. Therefore, if the UE determines that it needs to update its system information, the UE performs a PRACH (Physical Random Access Channel) procedure (branch "yes" at step 803) to refresh the system information as specified in TS 38.331 clause 5.2.2.3.3. As part of the PRACH procedure, the gNB 305 may then optionally request additional UE context information from a neighboring gNB (step 804). The additional context information may include the MBS session join information established in 523. For example, if the UE session join procedure is performed by a UE connected to another gNB, the gNB 305 obtains MBS session join information, such as an MBS session ID, from the other gNB.

[0163] All relevant UEs (e.g., all RRC_INACTIVE UEs located in the cell controlled by gNB 305 and that have previously joined the multicast session) will then send an MBS configuration request message as described in step 707.

[0164] Whenever the gNB 305 receives an MBS configuration request message from a UE, the gNB 305 prepares an MBS configuration message 609 in step 806 and sends the MBS configuration message 609 to the requesting UE. In the MBS configuration message, the UE will find the MBS radio bearer configuration parameters to be applied to receive multicast data corresponding to the activated MBS session. Details of the MBS radio bearer information element can be found in TS38.331 clause 6.3.2. The MBS radio bearer information element includes PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol) setting information determined in step 800 when radio resource reservation is made. The MBS configuration message may also include an MBS session identifier. For example, other fields of the MBS information element such as the session identifier are extracted from the memory 325, where these other fields have been stored in the memory 325 at the session establishment 523 or at the UE context extraction 804.

[0165] Details of an example procedure for configuring a UE for multicast reception are provided below with reference to sections and clauses of TS 38.331 Version 17.0.0. MBSConfigRequest corresponds to the MBS Configuration Request message discussed above.

[0166] The purpose of this procedure is to set up multicast reception in RRC_INACTIVE state, including (one or more than one) multicast MRBs. This procedure is new and will have a clear number later, and will currently be referred to as number 5.3.X.

[0167] Initiate

[0168] The UE initiates this procedure when upper layers or the AS (when responding to RAN paging) request to receive multicast in the RRC_INACTIVE state.

[0169] The UE shall ensure that it has valid and up-to-date basic system information as specified in clause 5.2.2.2 before initiating this procedure.

[0170] When initiating this procedure, the UE shall:

[0171] 1> If the resumption of the RRC connection is triggered by responding to NG-RAN paging:

[0172] 2> Select "0" as the access category;

[0173] 2> Use the selected access category and one or more access identifiers provided by the upper layer to perform the unified access control process as specified in 5.3.14;

[0174] 3> If the access attempt is prohibited, the process ends;

[0175] Actions related to the transmission of MBSConfigRequest or MBSConfigRequest1 messages

[0176] The UE shall set the content of the MBSConfigRequest or MBSConfigRequest1 message as follows:

[0177] 1> If the field useFullResumeID is signaled in SIB1:

[0178] 2> Select MBSConfigRequest1 as the message to use;

[0179] 2> Set ueIdentity to the stored fullI-RNTI value;

[0180] 1> Otherwise:

[0181] 2> Select MBSConfigRequest as the message to use;

[0182] 2> Set ueIdentity to the stored shortI-RNTI value;

[0183] 1> Re-establish the PDCP entity for SRB1;

[0184] 1>Restore SRB1;

[0185] 1> Submit the selected message MBSConfigRequest or MBSConfigRequest1 for transmission to the lower layer.

[0186] UE receives MBSConfiguration

[0187] UEs should:

[0188] 1> If RRCResume includes radioBearerConfig:

[0189] 2> Perform radio bearer configuration according to 5.3.5.6;

[0190] Message Definition

[0191] -MBSConfigRequest

[0192] The MBSConfigRequest message is used to request configuration for receiving multicast in the RRC_INACTIVE state.

[0193] Signaling radio bearer: SRB0

[0194] RLC-SAP:TM

[0195] Logical channel: CCCH

[0196] Direction: UE to network

[0197] MBSConfigurationRequest message

[0198]

[0199] -MBSConfigurationRequest1

[0200] The MBSConfigurationRequest1 message is used to request configuration for receiving multicast in the RRC_INACTIVE state.

[0201] Signaling radio bearer: SRB0

[0202] RLC-SAP:TM

[0203] Logical channel: CCCH1

[0204] Direction: UE to network

[0205] MBSConfigurationRequest1 message

[0206]

[0207] -MBSConfiguration MBSConfiguration message is used to set up multicast reception in RRC_INACTIVE state. Signaling radio bearer: SRB1

[0208] RLC-SAP:AM

[0209] Logical channel: DCCH

[0210] Direction: Network to UE

[0211] MBSConfiguration message

[0212]

[0213] Although the present invention has been described with reference to the embodiments, it should be understood that the present invention is not limited to the disclosed embodiments. It will be appreciated by those skilled in the art that various changes and modifications may be made without departing from the scope of the present invention as defined in the appended claims. All features disclosed in this specification (including any appended claims, abstracts and drawings) and / or all steps of any method or process disclosed in this specification may be combined in any combination, except for at least some mutually exclusive combinations of such features and / or steps. Unless expressly stated otherwise, each feature disclosed in this specification (including any appended claims, abstracts and drawings) may be replaced by alternative features for the same, equivalent or similar purposes. Therefore, unless expressly stated otherwise, each feature disclosed is only an example of a series of general equivalent or similar features.

[0214] 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 used to advantage.

[0215] In the foregoing 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 through a computer-readable medium as one or more instructions or codes, and executed by a hardware-based processing unit.

[0216] Computer-readable media may include computer-readable storage media (which corresponds to tangible media such as data storage media) or communication media containing any medium that facilitates, for example, transferring a computer program from one place to another according to a communication protocol. In this manner, computer-readable media may generally correspond to (1) a non-transitory tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the techniques described in the present disclosure. A computer program product may include computer-readable media.

[0217] As an example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store the desired program code in the form of instructions or data structures and can be accessed by a computer. In addition, any connection is appropriately referred to as a computer-readable medium. For example, if a coaxial cable, optical fiber cable, twisted pair, digital subscriber line (DSL) or wireless technologies such as infrared, radio and microwave are used to transmit instructions from a website, server or other remote source, then coaxial cable, optical fiber cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwave are included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals or other transient media, but are intended for replacement of non-transient tangible storage media. As used herein, disks and discs include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks and blue-ray discs, wherein the discs usually reproduce data magnetically, and the discs reproduce data optically with lasers. The above combination should also be included in the scope of computer-readable media.

Claims

1. A method for configuring a user equipment (UE) of a wireless communication system for multicast reception, wherein the UE has previously joined a multicast session, the method comprising: At a UE operating in a non-connected radio resource control state, i.e., a non-connected RRC state, receiving a notification indicating that the multicast session has been activated; sending an MBS configuration request message for requesting configuration information for receiving multicast data; An MBS configuration message is received, the MBS configuration message including configuration information for configuring the UE to receive multicast data.

2. The method according to claim 1, further comprising: The UE is configured based on the configuration information to receive multicast data in a non-connected RRC state.

3. The method according to claim 2, wherein: Configuration includes: Perform radio bearer configuration.

4. The method according to claim 2 or 3, wherein: After configuration, data for the multicast session is received.

5. A method according to any one of the preceding claims, wherein: The notification is a paging message.

6. The method according to any one of claims 1 to 5, wherein: The notification is a paging message sent by the base station, and the paging message includes an MBS session ID for identifying the activated multicast session and an MBS session activation reason for indicating that the multicast session has been activated.

7. A method according to any one of the preceding claims, wherein: The notification includes at least one of the following: Information indicating that the multicast session has been activated; An identifier used to identify the activated multicast session.

8. A method according to any one of the preceding claims, wherein: The notification is a group paging message.

9. The method according to any one of claims 1 to 4, wherein: The notification is a group paging message, the group paging message including an identifier for identifying the activated multicast session and information for indicating that the multicast session has been activated, The MBS configuration request message is a RRCResumeRequest message. The MBS configuration message is an RRCRelease message with a suspension configuration.

10. The method according to claim 9, wherein: The information indicating that the multicast session has been activated includes an MBS session activation reason.

11. The method according to any one of the preceding claims, further comprising: determining, based on information included in the notification, whether the notification indicates that a multicast session in which the UE had previously joined has been activated, The sending of the MBS configuration request message includes: in response to determining that the notification indicates that the multicast session previously joined by the UE has been activated, sending the MBS configuration request message.

12. A method according to any one of the preceding claims, wherein: The notification is sent by a base station, and the method further includes: after receiving the notification, performing a random access procedure to the base station to update the system information of the UE if necessary.

13. A method at a base station for controlling a cell in which one or more user equipments, i.e., one or more UEs, are camping, the method comprising: Send a notification indicating that a multicast session has been activated, receiving, from at least one of the one or more UEs operating in a non-connected RRC state and having previously joined the multicast session, an MBS configuration request message for requesting configuration information for receiving multicast data; In response to the received MBS configuration request message, an MBS configuration message is sent to the at least one UE among the one or more UEs, the MBS configuration message including configuration information for configuring the at least one UE to receive multicast data.

14. The method according to claim 13, wherein: The notification is a paging message.

15. The method according to claim 13 or 14, wherein: The notification is a paging message sent by the base station, and the paging message includes an MBS session ID and an MBS session activation reason indicating that the multicast session has been activated.

16. The method according to any one of claims 13 to 15, wherein: The notification includes at least one of the following: Information indicating that the multicast session has been activated; An identifier used to identify the activated multicast session.

17. The method according to any one of claims 13 to 16, wherein: The notification is a group paging message.

18. The method according to claim 13, wherein: The notification is a group paging message, the group paging message including an identifier for identifying the activated multicast session and information for indicating that the multicast session has been activated, The MBS configuration request message is a RRCResumeRequest message. The MBS configuration message is an RRCRelease message with a suspension configuration.

19. The method according to claim 18, wherein: The information indicating that the multicast session has been activated includes an MBS session activation reason.

20. A method according to any one of the preceding claims, wherein: The non-connected RRC state is the RRC_INACTIVE state.

21. A method according to any one of the preceding claims, wherein: The MBS configuration request message includes an identifier for identifying the activated multicast session.

22. The method according to claim 21, wherein: The identifier is a temporary mobile group identity, ie, TMGI, or an MBS session ID.

23. The method according to claim 21 or 22, wherein: The MBS configuration request further includes at least one of the following items: UE identification information used to identify the UE; Authentication information used when authenticating the UE.

24. A method according to any one of the preceding claims, wherein: The configuration information includes configuration information of at least one multicast radio bearer, ie, at least one MRB.

25. A device for a user equipment (UE), comprising: One or more processors configured to perform a method according to any one of claims 1 to 12 and claims 20 to 24 when dependent on claim 1.

26. A device for a base station, comprising: One or more processors configured to perform a method according to any one of claims 13 to 19 and claims 20 to 24 when dependent on claim 13.

27. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform the method according to any one of claims 1 to 24.

28. A computer readable medium carrying a computer program according to claim 27.

Images