Mobile device, access network node and method

Abstract

The present disclosure relates to a method for a user equipment (UE), the method including receiving multicast data from an access network node using a repeat request process when the UE is in a Radio Resource Control (RRC) connected state, transitioning to an RRC inactive state, and receiving the multicast from the access network node when the UE is in the RRC inactive state, wherein the UE receives the multicast data when the UE is in the RRC inactive state using the same repeat request process as used to receive the multicast in the RRC connected state.

Description

[Technical Field]

[0001] The present disclosure relates to communication systems. [Background technology]

[0002] This disclosure relates particularly, but not exclusively, to wireless communication systems and devices thereof that operate in accordance with 3rd Generation Partnership Project (3GPP®) standards or equivalents or derivatives thereof (including LTE-Advanced, next generation, or 5G networks, future generations, and beyond). This disclosure relates particularly, but not exclusively, to improvements relating to multicast and broadcast (MBS) services.

[0003] Recent developments in 3GPP standards are referred to as the Long-Term Evolution (LTE) of the Evolved Packet Core (EPC) network and the Evolved Universal Mobile Telecommunications Service (UMTS) Terrestrial Radio Access Network (E-UTRAN), commonly referred to as "4G." Furthermore, the terms "5G" and "New Radio" (NR) refer to evolved communications technologies that are expected to support a variety of applications and services. Various details of 5G networks are described, for example, in the "NGMN 5G White Paper" V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, available at https: / / www.ngmn.org / 5g-white-paper.html. 3GPP plans to support 5G through the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and 3GPP NextGen core network.

[0004] In 3GPP standards, a NodeB (or eNB in ​​LTE, gNB in ​​5G) is a radio access network (RAN) node (or simply "access node," "access network node," or "base station") through which communication devices (user equipment or "UE") connect to a core network and communicate with other communication devices and remote servers. For simplicity, this application uses the terms RAN node or base station to refer to such access nodes collectively. Summary of the Invention [Problem to be solved by the invention]

[0005] Multicast and broadcast services (MBS) enable resource-efficient delivery of transmissions for a group of user equipment (UE). For example, multicast communication to a group of UEs typically requires less overall bandwidth than unicast (one-to-one) communication to a corresponding set of individual UEs. Multicast transmissions to UEs in a radio resource control (RRC)-connected state can achieve higher quality of service (QoS) levels, improved reliability, and improved continuity than broadcast transmissions. MBS can be used, for example, in public safety and mission-critical applications, vehicle-to-everything (V2X) applications, or for video delivery to a group of UEs. However, improvements to MBS methods and procedures are needed to improve reliability and resource efficiency. Furthermore, some MBS may require service continuity. For example, when using MBS for public safety applications, it is important to be able to maintain MBS continuity even when a UE transitions from an RRC-connected state to an RRC-inactive state (e.g., due to a high RRC load).

[0006] More generally, there is a need for improved MBS mechanisms and procedures, including but not limited to procedures for maintaining MBS continuity as a UE transitions between an RRC connected state and an RRC inactive state. [Means for solving the problem]

[0007] The present disclosure aims to provide apparatus and methods that at least partially address the above needs and / or problems.

[0008] In a first aspect, the present disclosure provides a method for a user equipment (UE), the method including: receiving multicast data from an access network node using a repeat request process when the UE is in a Radio Resource Control (RRC) connected state; transitioning to an RRC inactive state; and receiving the multicast data from the access network node when the UE is in the RRC inactive state, wherein the UE receives the multicast data when the UE is in the RRC inactive state using the same repeat request process as used for receiving the multicast data in the RRC connected state.

[0009] The UE may maintain the received multicast data in a buffer associated with the repeated request process during the transition from the RRC connected state to the RRC inactive state.

[0010] The method further includes receiving downlink control information for receiving the multicast data from the access network node, the downlink control information including a repeat request setting for the repeat request process.

[0011] The repeat request process may be a hybrid automatic repeat request (HARQ) process.

[0012] The UE may use the repeated request process for reception of the multicast data when the UE is in the RRC inactive state, but may not request retransmission.

[0013] The UE may receive the multicast data using a single repeated request process when the UE is in the RRC connected state and when the UE is in the RRC inactive state.

[0014] When the UE is in the RRC inactive state, the UE may attempt to decode each data unit received using the repeated request process regardless of whether the data unit is retransmitted data or newly transmitted data, and the UE may determine whether the data unit is retransmitted data or newly transmitted data after the data unit is decoded at the UE.

[0015] The method may further include receiving, from the access network node, scheduling information for requesting retransmission of the multicast data for multiple repeat request processes when the UE is in a radio resource control (RRC) connected state, wherein receiving the multicast data from the access network node when the UE is in the RRC connected state includes receiving the multicast data using the multiple repeat request processes, and when the UE transitions from the RRC connected state to the RRC inactive state, the UE receives the multicast data using the same multiple repeat request processes as used to receive the multicast data in the RRC connected state.

[0016] The scheduling information may include at least one of an indication of an identification of a repeat request process among the plurality of repeat request processes, and an indication of whether data transmitted to the UE using a repeat request process among the plurality of repeat request processes is newly transmitted data or retransmitted data.

[0017] The method may further include decoding the multicast retransmission data received from the access network node using one of the plurality of repeat request processes when in the RRC inactive state, if the same data has not yet been decoded at the UE.

[0018] The method may further include not decoding retransmission data of the multicast received using one of the plurality of repeat request processes when in the RRC inactive state, if the UE determines that the multicast data has already been decoded at the UE.

[0019] In a second aspect, the present disclosure provides a method for a user equipment (UE), the method including, when the UE is in a radio resource control (RRC) connected state, receiving multicast first data from an access network node using a first repeated request process; transitioning to an RRC inactive state; and, when the UE is in a radio resource control (RRC) connected state, receiving multicast first data from an access network node using a first repeated request process. receiving second data of the multicast from the access network node using a second repeat request process when the UE is in an RRC connected state, the method comprising at least one of: receiving the first data of the multicast using the first repeat request process and a first set of at least one time resource and the second repeat request process and a second set of at least one time resource when the UE is in the RRC connected state; and receiving the second data of the multicast using both the first repeat request process and the first set of at least one time resource and the second repeat request process and the second set of at least one time resource when the UE is in the RRC inactive state, wherein the first set of at least one time resource is configured by the access network node to at least partially overlap with the second set of at least one time resource.

[0020] In a third aspect, the present disclosure provides a method for a user equipment (UE), the method including: receiving multicast data from an access network node using a plurality of first repeat request processes when the UE is in a radio resource control (RRC) connected state; receiving an RRC release message from the access network node indicating that the UE transitions to an RRC inactive state, the RRC release message including multicast configuration information for a second repeat request process; releasing the plurality of first repeat request processes based on the multicast configuration information; and receiving the multicast data from the access network node using the second repeat request process when the UE is in the RRC inactive state.

[0021] The method may further include receiving, using the plurality of first repeat request processes, first downlink control information for receiving the multicast data, and receiving, using the second repeat request process, second downlink control information for receiving the multicast data, wherein a format or type of the first downlink control information is different from a format or type of the second downlink control information.

[0022] The UE may determine to release the plurality of first repeat request processes based on at least one of a difference between a format or type of the first downlink control information and a format or type of the second downlink control information, and an indication in the multicast configuration information that a single repeat request process is used to receive the multicast data when the UE is in the RRC inactive state.

[0023] In a fourth aspect, the present disclosure provides a method for a user equipment (UE), the method including: receiving multicast data from an access network node using a plurality of first repeat request processes when the UE is in a radio resource control (RRC) connected state; receiving multicast configuration information for a second repeat request process for receiving the multicast data when the UE is in an RRC inactive state from the access network node when the UE is in the RRC connected state, receiving the multicast data from the access network node using the plurality of first repeat request processes and using the second repeat request process when the UE is in the RRC connected state; receiving an RRC release message from the access network node indicating that the UE will transition to an RRC inactive state; transitioning to the RRC inactive state; and receiving the multicast data from the access network node using the second repeat request process when the UE is in the RRC inactive state.

[0024] The method may further include receiving first downlink control information for receiving the multicast data using the plurality of first repeat request processes, and receiving second downlink control information for receiving the multicast data using the second repeat request process, wherein a format or type of the first downlink control information is different from a format or type of the second downlink control information.

[0025] In a fifth aspect, the present disclosure provides a method for a user equipment (UE), the method including: receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when the UE is in a radio resource control (RRC) connected state; transitioning to an RRC inactive state; and receiving the multicast data from the access network node using the MRB when the UE is in the RRC inactive state, wherein a radio link control (RLC) entity in the UE associated with the MRB when the UE is in the RRC connected state is maintained in the UE when the UE transitions to the RRC inactive state.

[0026] At least one of the count values ​​or timers for the MRB stored in the UE when the UE is in the RRC connected state may be maintained in the UE when the UE transitions to the RRC inactive state.

[0027] The method may include, before the UE transitions to the RRC inactive state, switching the RLC entity from a first mode for sending repeated request feedback to the access network node to a second mode in which the repeated request feedback is not sent to the access network node.

[0028] In a sixth aspect, the present disclosure provides a method for a user equipment (UE), the method including receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when the UE is in a radio resource control (RRC) inactive state, the UE receiving the multicast data using a repeated request process, transitioning to an RRC connected state, receiving the multicast data from the access network node using the MRB when the UE is in the RRC connected state, and receiving the multicast data using the MRB and the repeated request process when the UE was in the RRC inactive state.

[0029] The multicast data stored in a buffer associated with the repeated request process when the UE is in the RRC inactive state may be maintained in the buffer when the UE transitions to the RRC connected state.

[0030] A radio link control (RLC) entity at the UE that was associated with the MRB when the UE was in the RRC inactive state may be maintained at the UE when the UE transitions to the RRC inactive state.

[0031] In a seventh aspect, the present disclosure provides a method for a user equipment (UE), the method including receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when the UE is in a radio resource control (RRC) inactive state, the UE receiving the multicast data using a first repeat request process, transitioning to an RRC connected state, and when the UE is in the RRC connected state, receiving the multicast data from the access network node using the MRB using a plurality of second repeat request processes different from the first repeat request process, the second repeat request process using the MRB that was used to receive the multicast when the UE was in the RRC inactive state.

[0032] A radio link control (RLC) entity at the UE that was associated with the MRB when the UE was in the RRC inactive state may be maintained at the UE when the UE transitions to the RRC inactive state.

[0033] In an eighth aspect, the present disclosure provides a method for an access network node, the method including: transmitting multicast data to a user equipment (UE) using a repeat request process when the UE is in a radio resource control (RRC) connected state; and transmitting the multicast data to the UE using the same repeat request process when the UE is in a radio resource control (RRC) inactive state.

[0034] In a ninth aspect, the present disclosure provides a method in an access network node, the method comprising: transmitting multicast data to a first user equipment (UE) using a first repeat request process and using a first set of at least one time resource when the first UE is in a radio resource control (RRC) connected state; and transmitting the multicast data to a second UE using a second repeat request process and using a second set of at least one time resource when a second UE is in an RRC inactive state, wherein the first set of at least one time resource is configured by the access network node to at least partially overlap in time with the second set of at least one time resource.

[0035] The first set of at least one time resource may be the same as the second set of at least one time resource.

[0036] The method may further include receiving a retransmission request for the multicast data from the first UE using a first repeat request process; retransmitting the multicast data using the first repeat request process and using a third set of at least one time resource; and not transmitting the retransmission of the multicast data using the second repeat request process and the third set of at least one time resource.

[0037] In a tenth aspect, the present disclosure provides a method for an access network node, the method including: transmitting multicast data to a user equipment (UE) using a plurality of first repeat request processes when the UE is in a radio resource control (RRC) connected state; and transmitting an RRC release message to the UE indicating that the UE transitions to an RRC inactive state, the RRC release message including multicast configuration information for a second repeat request process, the multicast configuration information indicating that the UE releases the plurality of first repeat request processes; and transmitting the multicast data to the UE using the second repeat request process when the UE is in the RRC inactive state.

[0038] In an eleventh aspect, the present disclosure provides a method for an access network node, the method including: transmitting multicast data to a user equipment (UE) using a plurality of first repeat request processes when the UE is in a radio resource control (RRC) connected state; transmitting multicast configuration information for a second repeat request process for receiving the multicast data when the UE is in the RRC inactive state to the UE when the UE is in the RRC connected state; transmitting the multicast data to the UE using the plurality of first repeat request processes and using the second repeat request process when the UE is in the RRC connected state; transmitting an RRC release message to the UE indicating that the UE will transition to the RRC inactive state; and transmitting the multicast data to the UE using the second repeat request process when the UE is in the RRC inactive state.

[0039] In a twelfth aspect, the present disclosure provides a user equipment (UE), comprising: means for receiving multicast data from an access network node using a repeat request process when the UE is in a radio resource control (RRC) connected state; and means for transitioning to an RRC inactive state, wherein the receiving means is configured to receive the multicast data from the access network node when the UE is in the RRC inactive state, and the UE is configured to receive the multicast data when the UE is in the RRC inactive state using the same repeat request process as used for receiving the multicast data in the RRC connected state.

[0040] In a thirteenth aspect, the present disclosure provides a method for transmitting multicast first data from an access network node using a first repeated request process when a user equipment (UE) is in a radio resource control (RRC) connected state, the method comprising: receiving multicast first data from an access network node using a first repeated request process when the UE is in a radio resource control (RRC) connected state; and transitioning to an RRC inactive state, the receiving means comprising: and configured to receive second data of the multicast from the access network node using a second repeat request process when the UE is in an RRC connected state, wherein the receiving means is configured to at least one of: receive the first data of the multicast using the first repeat request process and a first set of at least one time resource and the second repeat request process and a second set of at least one time resource when the UE is in the RRC connected state; and receive the second data of the multicast using both the first repeat request process and the first set of at least one time resource and the second repeat request process and the second set of at least one time resource when the UE is in an RRC inactive state, wherein the first set of at least one time resource is configured by the access network node to at least partially overlap with the second set of at least one time resource.

[0041] In a fourteenth aspect, the present disclosure provides a user equipment (UE), comprising: means for receiving multicast data from an access network node using a plurality of first repeat request processes when the UE is in a radio resource control (RRC) connected state; means for receiving an RRC release message from the access network node indicating that the UE transitions to an RRC inactive state, the RRC release message including multicast configuration information for a second repeat request process; and means for releasing the plurality of first repeat request processes based on the multicast configuration information, wherein the receiving means is configured to receive the multicast data from the access network node using the second repeat request process when the UE is in the RRC inactive state.

[0042] In a fifteenth aspect, the present disclosure provides a user equipment (UE), comprising: a receiving means configured to receive multicast data from an access network node using a plurality of first repeat request processes when the UE is in a radio resource control (RRC) connected state, receive multicast configuration information for a second repeat request process for receiving the multicast data when the UE is in an RRC inactive state from the access network node when the UE is in an RRC connected state, receive the multicast data from the access network node using the plurality of first repeat request processes and the second repeat request process when the UE is in the RRC connected state, and receive an RRC release message from the access network node indicating that the UE will transition to an RRC inactive state; and means for transitioning to the RRC inactive state, wherein the receiving means is further configured to receive the multicast data from the access network node using the second repeat request process when the UE is in the RRC inactive state.

[0043] In a sixteenth aspect, the present disclosure provides a user equipment (UE), comprising: means for receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when the UE is in a radio resource control (RRC) connected state; and means for transitioning to an RRC inactive state, wherein the receiving means is configured to receive the multicast data from the access network node using the MRB when the UE is in the RRC inactive state, and the UE is configured to maintain a radio link control (RLC) entity in the UE associated with the MRB when the UE is in the RRC connected state when the UE transitions to the RRC inactive state.

[0044] In a seventeenth aspect, the present disclosure provides a user equipment (UE) means for receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when the UE is in a radio resource control (RRC) inactive state, the UE comprising: means configured to use a repeated request process to receive the multicast data; and means for transitioning to an RRC connected state, the receiving means configured to use the MRB when the UE is in the RRC connected state and to receive the multicast data from the access network node using the MRB and the repeated request process when the UE was in the RRC inactive state.

[0045] In an eighteenth aspect, the present disclosure provides a user equipment (UE) comprising: means for receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when the UE is in a radio resource control (RRC) inactive state, the UE being configured to receive the multicast data using a first repeat request process; and means for transitioning to an RRC connected state, the receiving means being configured to receive the multicast data from the access network node using the MRB when the UE is in the RRC connected state, the MRB used to receive the multicast when the UE was in the RRC inactive state, and a plurality of second repeat request processes different from the first repeat request process.

[0046] In a nineteenth aspect, the present disclosure provides an access network node comprising: means for transmitting multicast data to a user equipment (UE) using a repeat request process when the UE is in a radio resource control (RRC) connected state, the transmitting means being configured to transmit the multicast data to the UE using the same repeat request process when the UE is in a radio resource control (RRC) inactive state.

[0047] The method further includes sending downlink control information to a UE for receiving the multicast data, where the downlink control information includes a repeat request setting for the repeat request process.

[0048] The repeat request process may be a hybrid automatic repeat request (HARQ) process.

[0049] The access network node may optionally transmit the multicast data to the UE using only a single repeated request process when the UE is in the RRC connected state and when the UE is in the RRC inactive state.

[0050] The method further includes transmitting, to the UE for multiple repeat request processes, scheduling information used by the UE to request retransmission of the multicast downlink data when the UE is in a radio resource control (RRC) connected state, wherein transmitting the multicast data to the UE when the UE is in the RRC connected state includes transmitting the multicast data using the multiple repeat request processes, and transmitting the multicast data to the UE when the UE is in the RRC inactive state includes transmitting the multicast data to the UE using the same multiple repeat request processes.

[0051] In a twentieth aspect, the present disclosure provides an access network node comprising: means for transmitting multicast data to a first user equipment (UE) using a first repeat request process and using a first set of at least one time resource when the first UE is in a radio resource control (RRC) connected state; the transmitting means being configured to transmit the multicast data to the second UE using a second repeat request process and using a second set of at least one time resource when a second UE is in an RRC inactive state; the access network node further comprising: means for configuring the first set of at least one time resource to at least partially overlap in time with the second set of at least one time resource.

[0052] In a twenty-first aspect, the present disclosure provides an access network node comprising: a transmitting means configured to: transmit multicast data to a user equipment (UE) using a plurality of first repeat request processes when the UE is in a radio resource control (RRC) connected state; transmit an RRC release message to the UE indicating that the UE transitions to an RRC inactive state, the RRC release message including multicast configuration information for a second repeat request process, the multicast configuration information indicating that the UE releases the plurality of first repeat request processes; and transmit the multicast data to the UE using the second repeat request process when the UE is in the RRC inactive state.

[0053] In a twenty-second aspect, the present disclosure provides an access network node comprising: a transmitting means configured to: transmit multicast data to a user equipment (UE) using a plurality of first repeat request processes when the UE is in a radio resource control (RRC) connected state; transmit multicast configuration information for a second repeat request process for receiving the multicast data to the UE when the UE is in an RRC inactive state when the UE is in an RRC connected state; transmit the multicast data to the UE using the plurality of first repeat request processes and the second repeat request process when the UE is in the RRC connected state; transmit an RRC release message to the UE indicating that the UE will transition to the RRC inactive state; and transmit the multicast data to the UE using the second repeat request process when the UE is in the RRC inactive state. [Brief explanation of the drawings]

[0054] Embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] FIG. 1 illustrates schematically a mobile (“cellular” or “wireless”) communications system. [Figure 2] FIG. 2 shows a typical frame structure used in the communication system of FIG. [Figure 3] Figure 3 shows a diagram of point-to-point (PTP) and point-to-multipoint (PTM) communication. [Figure 4] FIG. 4 is a flow diagram illustrating a method by which a UE continues to receive multicast transmissions in an RRC inactive state. [Figure 5] FIG. 5 shows an example of information for maintaining a PTM leg in a UE. [Figure 6] FIG. 6 is a flow diagram illustrating a method by which a UE continues to receive multicast transmissions in an RRC connected state. [Figure 7] FIG. 7 illustrates a method for transmitting an MBS radio bearer (MRB) list to a UE. [Figure 8] FIG. 8 shows a first example of an RLC configuration. [Figure 9] FIG. 9 shows a second example of an RLC setup. [Figure 10] FIG. 10 illustrates how the UE moves to the RRC connected state and receives the MRB configuration. [Figure 11] FIG. 11 illustrates a further method for a UE to transition to an RRC connected state. [Figure 12] FIG. 12 illustrates a first portion of a method for establishing and joining a multicast session. [Figure 13] FIG. 13 illustrates a second portion of the method for establishing and joining a multicast session. [Figure 14] FIG. 14 illustrates a third portion of the method for establishing and joining a multicast session. [Figure 15] FIG. 15 illustrates a first part of a method for activating and deactivating an MBS session. [Figure 16]FIG. 16 illustrates a second part of the method for activating and deactivating an MBS session. [Figure 17] FIG. 17 illustrates a method in which the UE does not move to an RRC connected state when a PTM configuration is available in the UE. [Figure 18] FIG. 18 is a flow diagram illustrating a method for a UE to receive downlink control information (DCI) from a base station. [Figure 19] FIG. 19 shows an example of HARQ processes for RRC inactive and RRC connected UEs. [Figure 20] FIG. 20 is a flow diagram illustrating a method for a UE to receive a multicast transmission after transitioning to an RRC inactive state. [Figure 21] FIG. 21 illustrates an example of a HARQ process for a UE transitioning from an RRC connected state to an RRC inactive state. [Figure 22] FIG. 22 is a flow diagram illustrating a method for a UE to receive configuration for a multicast radio bearer (MRB) before transitioning to an RRC inactive state. [Figure 23] FIG. 23 illustrates a further example of an HARQ process for a UE transitioning from an RRC connected state to an RRC inactive state. [Figure 24] FIG. 24 is a schematic block diagram showing the main components of the UE 3. [Figure 25] FIG. 25 is a schematic block diagram showing the main components of a base station. DETAILED DESCRIPTION OF THE INVENTION

[0055] overview An exemplary communication system will now be described in general terms, by way of example only, with reference to Figures 1 and 2.

[0056] FIG. 1 illustrates schematically a mobile (“cellular” or “wireless”) communications system 1 to which embodiments of the present disclosure are applicable.

[0057] In communication system 1, user equipment (UE) 3-1, 3-2, 3-3 (e.g., cellular telephones and / or other mobile devices) can communicate with one another via radio access network (RAN) nodes 5 that operate according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN nodes 5 include NR / 5G base stations or "gNBs" 5 that operate one or more associated cells 9. Communications via base stations 5 are typically routed through a core network 7 (e.g., a 5G core network or evolved packet core network (EPC)).

[0058] As will be appreciated by those skilled in the art, although FIG. 1 shows three UEs 3 and one base station 5 for illustrative purposes, other base stations 5 and UEs 3 will typically be included when the system is implemented.

[0059] Each base station 5 controls one or more associated cells 9 directly or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, etc.) It will be appreciated that the base stations 5 may be configured to support 4G, 5G, 6G and / or other 3GPP or non-3GPP communication protocols.

[0060] A UE 3 and its serving base station 5 are connected via a suitable radio interface (such as, for example, the so-called "Uu" interface). Neighboring base stations 5 may be connected to each other via a suitable inter-base station interface (such as, for example, the so-called "X2" interface, "Xn" interface, etc.).

[0061] The core network 7 includes multiple logical nodes (or "functions") for supporting communications in the communication system 1. In this example, the core network 7 includes a control plane function (CPF) 10 and one or more user plane functions (UPF) 11. The CPF 10 includes one or more Access and Mobility Management Functions (AMF) 10-1, one or more Session Management Functions (SMF) 10-2, and multiple other functions 10-n.

[0062] The base stations 5 are connected to core network nodes via appropriate interfaces (or "reference points"), such as the N2 reference point for communication of control signaling between the base stations 5 and the AMF 10-1, and the N3 reference point for communication of user data between the base stations 5 and each UPF 11. The UEs 3 are each connected to the AMF 10-1 via a logical non-access stratum (NAS) connection via the N1 reference point (equivalent to the S1 reference point in LTE). It will be appreciated that the N1 communications are transparently routed via the base stations 5.

[0063] The one or more UPFs 11 are connected to an external data network (eg an IP network such as the Internet) via a reference point N6 for the communication of user data.

[0064] The AMF 10-1 performs mobility management related functions, maintains a NAS signaling connection with each UE 3, and manages UE registrations. The AMF 10-1 is also responsible for managing paging. The SMF 10-2 provides session management functions (forming part of the LTE MME functionality) and also integrates some control plane functions (provided by the LTE Serving Gateway and Packet Data Network Gateway). The SMF 10-2 also allocates an IP address to each UE 3.

[0065] A base station 5 (also referred to as an access network node 5) of the communication system 1 is configured to operate at least one cell 9 on an associated TDD carrier operating in unpaired spectrum. It will be appreciated that the base station 5 may also operate at least one cell 9 on an associated FDD carrier operating in paired spectrum.

[0066] The base station 5 is also configured to transmit control information and user data via a plurality of downlink (DL) physical channels and a plurality of physical signals, which the UE 3 is configured to receive, where the DL physical channels correspond to resource elements (REs) that carry information originating from higher layers, and the DL physical signals correspond to REs used by the physical layer that do not carry information originating from higher layers.

[0067] The physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH transmits data that shares the capacity of the PDSCH based on time and frequency. The PDSCH can transmit various data items, including, for example, user data, UE-specific upper layer control messages mapped from higher channels, system information blocks (SIBs), and paging. The PDCCH transmits downlink control information (DCI) to support various functions, including, for example, scheduling downlink transmissions on the PDSCH and uplink data transmissions on the physical uplink shared channel (PUSCH). The PBCH provides a Master Information Block (MIB) to the UE. The PBCH, in conjunction with the PDCCH, also supports time and frequency synchronization and assists in cell acquisition, selection, and reselection. The UE 3 may receive a synchronization signal block (SSB) and may assume that the reception opportunities for the PBCH, primary synchronization signal (PSS), and secondary synchronization signal (SSS) are consecutive symbols, forming an SS / PBCH block. The base station 5 may transmit multiple synchronization signal (SS) blocks corresponding to different DL beams. The total number of SS blocks may be limited, for example, to a duration of 5 ms as an SS burst. The periodicity of the SSB transmission may be indicated to the UE using any appropriate signaling (e.g., per serving cell using ssb-periodicityServingCell). The SSB periodicity value may be, for example, 20 ms or greater. During initial cell selection, the UE 3 may be configured to assume that SS bursts occur with a periodicity of two frames.The UE 3 may be provided with an indication (eg, using ssb-PositionsInBurst) of which SSBs will be transmitted within the 5 ms period.

[0068] DL physical signals may include, for example, reference signals (RS) and synchronization signals (SS). Reference signals (sometimes known as pilot signals) are signals with predefined special waveforms that are known to both the UE 3 and the base station 5. Reference signals may include, for example, cell-specific reference signals, UE-specific reference signals (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signals (CSI-RS).

[0069] Similarly, the UE 3 is configured to transmit control information and user data via a plurality of uplink (UL) physical channels corresponding to REs carrying information originating from higher layers, and to transmit UL physical signals corresponding to REs used in the physical layer that do not carry information originating from higher layers, and the base station 5 is configured to receive these. The physical channels may include, for example, a PUSCH, a physical uplink control channel (PUCCH), and / or a physical random-access channel (PRACH). The UL physical signals may include, for example, a demodulation reference signal (DMRS) for UL control / data signals and / or a sounding reference signal (SRS) used for UL channel measurement.

[0070] When a UE 3 first establishes an RRC connection with a base station 5 via a cell, it registers with the appropriate AMF 9 (or MME). The UE 3 is in a so-called RRC connected state, and the associated UE context is maintained by the network. The UE 3 may transition from the RRC connected state to an RRC idle state or an RRC inactive state. For example, the UE 3 may transition from the RRC connected state to the RRC inactive state in response to receiving an RRC release message from the base station 5 that includes an indication (e.g., suspendConfig) to move to the RRC inactive state. The UE 3 may transition from the RRC inactive state to the RRC connected state and send a corresponding RRC Resume request to the base station 5. The UE 3 may transition from the RRC inactive state to the RRC connected state in response to receiving a paging from the base station 5 (e.g., a group paging for the UE 3's group). When the UE 3 is in the so-called RRC idle, or RRC inactive, state, the UE 3 selects a suitable cell to camp on, allowing the network to know the approximate location (although not necessarily at a cell level) of the UE 3. It will be appreciated that the RRC inactive state can be seen as an intermediate state between the RRC connected and RRC idle states, in which the RRC is not completely released and the UE 3 can return more quickly to the RRC connected state for sending and / or receiving transmissions to and from the base station 5.

[0071] Frame structure 2 shows a typical frame structure (time resource) used in communication system 1, in which base stations 5 and UEs 3 communicate with each other using resources organized in the time domain into 10 ms long frames. Each frame contains ten 1 ms long, equally sized subframes. Each subframe is divided into one or more slots containing 14 equally long Orthogonal Frequency-Division Multiplexing (OFDM) symbols.

[0072] As shown in FIG. 2, the communication system 1 supports multiple different numerologies (subcarrier spacing (SCS), slot length, and OFDM symbol length). Specifically, each numerology is identified by a parameter μ, where μ=0 represents 15 kHz (corresponding to LTE SCS). Currently, SCS for other values ​​of μ can be derived substantially by scaling up from μ=0 by a power of 2 (i.e., SCS=15×2μkHz). The relationship between the parameter μ and SCS (Δf) is shown in Table 1. [Table 1]

[0073] System Information and SIB It will be appreciated that transmissions in a cell 9 of a base station 5 may include one or more broadcast transmissions, one or more unicast transmissions for reception by a UE 3, or one or more multicast transmissions for reception by a corresponding group of UEs 3. System information (SI) transmitted in a cell may include a "minimum SI" (MSI) and an "other SI" (OSI). OSI may be broadcast on demand, for example, using a downlink shared channel (DL-SCH). OSI may also be broadcast upon request from UEs 3 in a radio resource control (RRC) idle or RRC inactive state. OSI may also be requested by UEs 3 in an RRC connected state, for example, via one or more dedicated RRC transmissions.

[0074] The SI may include information to enable (e.g., configure) the UE 3 to complete a cell selection, to enable the UE 3 to complete a cell reselection procedure, or to enable the UE 3 to receive one or more paging messages transmitted within a cell. The SI may be broadcast using a Master Information Block (MIB) and one or more System Information Blocks (SIB).

[0075] The MSI includes the MIB and system information block 1 (SIB1). The MIB includes information used by the UE 3 to receive SIB1, such as the subcarrier spacing of SIB1. The MIB provides information corresponding to the Control Resource Set (CORESET) and the Search Space. SIB1 is also referred to as the "remaining MSI" (RMSI). SIB1 may be transmitted in a dedicated RRC message, and other SIBs (e.g., SIB2 to SIB9) may be transmitted using one or more other appropriate RRC transmissions. The MIB and SIB1 may provide the UE 3 with scheduling information for receiving and decoding other SIBs, such as SIB2 to SIB9, and may provide information used by the UE 3 to receive one or more paging messages. The OSI may include, for example, SIB2 to SIB9 transmitted using the DL-SCH in an SI message. A mapping of SIB2 to SIB9 corresponding to the SI message may be provided to the UE 3 by the base station 5. The MIB and SIB1 to SIB9 are described in further detail, for example, in 3GPP TS 38.331. For example, SIB2 provides information about intra-frequency, inter-frequency, and inter-system cell reselection, SIB3 provides cell-specific information about intra-frequency cell reselection, and SIB4 provides information about inter-frequency cell reselection. SIB5 provides information about inter-system cell reselection for 4G (LTE). SIB6 and SIB7 provide information about earthquake and tsunami warning system (ETWS). SIB8 provides information about commercial mobile alert service (CMAS) notifications, for example, to send alert text messages to UE3.SIB9 contains information about coordinated universal time (UTC), global positioning system (GPS) time (eg, for GPS initialization), and local time.

[0076] The SIBs may be broadcast periodically (e.g., according to a predetermined periodic pattern) or may be provided "on-demand," e.g., upon request from UE 3. For example, MIB may be transmitted with a periodicity of 80 ms and repeated within 80 ms, while SIB1 may be transmitted with a periodicity of 160 ms and with a variable transmission repetition period within 160 ms (e.g., 20 ms). SIB1 can be used to indicate to UE 3 which SIBs are transmitted periodically and which SIBs are available on-demand upon request from UE 3. UE 3 may be configured to request on-demand SIBs using MSG1 (random access preamble (RA)), also referred to as MSG1-based on-demand SI request, or MSG3 (RRC Connection Request), also referred to as MSG3-based on-demand SI request.

[0077] The physical broadcast channel (PBCH) can be used to broadcast the MIB. The base station 5 may transmit the PBCH with synchronization signals (SS) (e.g., a primary synchronization signal (PSS) and a secondary synchronization signal (SSS)) in an SS / PBCH block. The SS / PBCH block may comprise four orthogonal frequency-division multiplexed (OFDM) symbols mapped to the PSS, SSS, and PBCH associated with a demodulation reference signal (DM-RS). In the frequency domain, the SS / PBCH block consists of 240 consecutive subcarriers. When the UE 3 is in RRC connected mode, the base station 5 may provide the UE 3 with an indication of the resources used for the SS / PBCH, for example, using dedicated signaling (e.g., for the anchor NES cell or for the non-anchor NES cell). The SIB1 may be transmitted using a physical downlink shared channel (PDSCH). The OSI may also be transmitted, for example, using the PDSCH.

[0078] When one or more beamformed transmissions are transmitted within a cell served by base station 5, some of the SIs (e.g., some of the SIBs) may be transmitted only using a particular beam or using a particular transmission / reception point (TRP).

[0079] Multicast and Broadcast Services (MBS) A method for providing MBS is described below. A method for maintaining multicast transmissions, including point-to-multipoint (PTM) transmissions between base stations 5 and UEs 3 (e.g., maintaining continuity of MBS services) is described.

[0080] A multicast service may include a PTP leg between a base station 5 and a single UE 3, and PTM legs between the base station 5 and multiple UEs 3. PTP and PTM transmissions are shown schematically in Figure 3. While the UEs 3 are shown individually in Figure 3, it will be understood that a UE 3 may receive both the PTP and PTM parts of a multicast. A PTP may be described as a PTP "leg" or "part" of a multicast transmission. Similarly, a PTM may be described as a PTM "leg" or "part" of a multicast transmission.

[0081] The PTM leg has MBS radio bearers (MRBs) in the MBS session and has corresponding MRB configurations. Each MRB may have an associated identifier (e.g., MRB-Identity) that can be used to identify the MRB. The MRB identifier may be included in any appropriate transmission for MRB configuration. The multicast service may be suspended or reactivated (the process by which an MRB is released) based on multicast data activity (or inactivity). The configuration of one or more MRBs may be provided to the UE 3 and / or base station 5, for example, by appropriate radio link control (RLC) configuration signaling (e.g., in an RLC Bearer Configuration message).

[0082] The base station 5 may provide the multicast MRB configuration to the UE 3 via dedicated signaling. The multicast MRB may be a DL-only RLC unacknowledge mode (RLC-UM) that does not send acknowledge / negative-acknowledge (ACK / NACK) feedback, or the MRB may have a bidirectional RLC-UM configuration for PTP transmission.

[0083] The multicast MRB configuration may include an RLC-acknowledge mode (RLC-AM) configuration for transmitting ACK / NACK feedback, and an RLC-unacknowledge mode (RLC-UM) configuration for not transmitting ACK / NACK feedback.

[0084] The multicast MRB configuration may include an RLC-AM entity for PTP transmission.

[0085] The multicast MRB configuration may include a DL-only RLC-UM entity for PTM transmission.

[0086] A multicast MRB configuration may include two RLC-UM entities: one RLC-UM entity may be a DL-only RLC-UM entity for PTP transmission, and the other RLC-UM entity may be a DL-only RLC-UM entity for PTM transmission.

[0087] A multicast MRB configuration may include three RLC-UM entities, one RLC-UM entity may be a DL-only RLC-UM entity, one RLC-UM entity may be a UL RLC-UM entity for PTP transmission, and another RLC-UM entity may be a DL-only RLC-UM entity for PTM transmission.

[0088] A multicast MRB configuration may include two RLC entities, one RLC entity may be an RLC-AM entity for PTP transmission and the other RLC entity may be a DL-only RLC-UM entity for PTM transmission.

[0089] If UE3 transitions from an RRC connected state to an RRC inactive state, the multicast MRB may be suspended. Because the multicast PTP leg is UE specific and the resources required to provide the PTP leg may increase proportionally with the number of UEs, the multicast PTM leg may not be suitable for use when the UE is in an RRC inactive state. However, in this example, the multicast PTM part can be advantageously maintained (or configured) even when UE3 is in an RRC inactive state.

[0090] Advantageously, reception of multicast transmissions can be maintained when the UE 3 performs cell reselection to a neighboring cell in RRC inactive state (without resuming the RRC connection). Methods for setting up, resuming, and maintaining multicast when the UE is in RRC inactive state are described below.

[0091] An improved procedure for maintaining the multicast PTM leg when UE 3 transitions from an RRC connected state to an RRC inactive state is described below. It will be appreciated that in the method described below, PTM transmissions from the base station may be received by UEs in an RRC inactive state as well as UEs in an RRC connected state.

[0092] Maintaining PTM for Multicast FIG. 4 illustrates an example in which UE 3 advantageously transitions from an RRC connected state to an RRC inactive state but maintains the PTM leg of the multicast transmission.

[0093] In step S401, UE 3 is in an RRC connected state and receives a multicast transmission from a base station (access network node) 5. The MRB includes a PTM leg configured for UE 3, and a PTM leg may also be configured for UE 3.

[0094] In step S402, the UE 3 receives an RRC Release message from the base station 5. The base station 5 may decide to send the RRC Release message to the UE 3, for example, to reduce congestion in the cell of the base station 5 or due to a data inactivity period for multicast. The RRC Release message may include an indication indicating that a corresponding configuration is suspended (e.g., an information element such as suspendConfig). In this example, the RRC Release message advantageously includes information (e.g., in SuspendConfig) for maintaining at least one PTM leg in the UE 3 (e.g., information indicating that the UE 3 stores information corresponding to the PTM leg). The information for maintaining at least one PTM leg is also referred to as a "multicast indication."

[0095] In step S403, UE 3 moves to an RRC inactive state in response to receiving the RRC Release message, but advantageously, UE 3 can continue to receive the PTM leg of the multicast transmission because UE 3 received information to maintain the PTM leg in the RRC Release message of step S402.

[0096] An example of information regarding the maintenance of at least one PTM leg in the UE 3, which may be included in the RRC Release message of step S402, is shown in FIG. 5. However, it will be understood that the information regarding the maintenance of at least one PTM leg in the UE 3 may be in other suitable formats. In this example, the information includes an indication of "RRCINACTIVEMBS," which indicates whether the UE 3 should maintain the PTM RLC entity of the multicast MRB when the UE 3 is in an RRC inactive state. In other words, upon receiving this indication, the UE 3 decides whether to maintain the PTM RLC entity of the MRB. This indication may be, for example, "TRUE," indicating that the UE 3 maintains the PTM RLC entity of the MRB, or "FALSE," indicating that the UE 3 does not maintain the PTM RLC entity of the MRB (however, it will be understood that this indication does not necessarily have to be "TRUE" or "FALSE," and other suitable indications, such as "0" or "1," may be used instead). As shown in FIG. 5, in this example, the information included in the RRC release message includes a list of MRBs, and the UE 3 may decide to maintain the PTM RLC entities of the MRBs shown in this list.

[0097] The indication of whether the UE 3 should maintain at least one PTM leg when the MBS session is terminated or deactivated may be used to indicate that no PTM legs are maintained at the UE 3.

[0098] The RRC release message that the UE 3 receives from the network (e.g., base station 5) may include an indication of the configuration for MBS in neighboring cells. This information may include neighboring cell configurations associated with an MBS session list. The neighboring cell MBS session configurations can be used to implicitly indicate which MBS sessions (MRBs) to maintain if the UE 3 moves to an RRC inactive state. However, to avoid ambiguity in the indication, an explicit indication as shown in FIG. 5 may be desirable.

[0099] 6 is a flow diagram illustrating a method for a UE to continue receiving multicast transmissions in an RRC connected state. In step S601, the UE 3 is in an RRC inactive state and receives multicast transmissions transmitted from a base station. In step 602, the base station 5 sends an RRC resume message to the UE 3 (e.g., after the base station 5 determines that the UE 3 transitions to the RRC connected state). As described above with reference to the RRC release message in step S402 of FIG. 4, the RRC resume message may include information for maintaining at least one PTM leg in the UE 3. In step S603, the UE 3 transitions to the RRC connected state and continues receiving multicast transmissions.

[0100] DU and CU Figure 7 shows an example in which an MRB list is sent to UE 3 as part of an RRC release procedure involving DU 50 and CU 60. DU 50 may be referred to as the "first unit" of access network node 5 for wireless communication with UE 3, and CU 60 may be referred to as the "second unit" of access network node 5. At the start of the method shown in Figure 7, UE 3 is in an RRC connected state and is receiving multicast transmissions, including PTM transmissions, from DU 50.

[0101] In step S801, the CU 60 sends a UE Context Release Request message to the DU 50. The UE Context Release Request includes an identifier of the UE (e.g., "UE ID"). In this example, the UE Context Release Request also includes a list of MRBs to be maintained for the UE 3 when the UE 3 moves to an RRC inactive state. Alternatively, the UE Context Release Request may include an indication indicating that all MRBs for PTM transmission of the UE 3 are maintained (e.g., using an indication such as "KeepPTMindication" that is "TRUE" or "FALSE", or similarly "1" or "0"). The indication indicating which MRBs the DU 50 should maintain (e.g., store or transmit configurations for) may be in the form of any suitable information element or list, such as an "MRB_ID list of INACTIVE". Upon receiving the indication included in the UE Context Release Request, the DU 50 may decide to maintain the context of the UE 3 and maintain one or more multicast FU tunnels associated with a list of bearers (e.g., "MRB_ID list of INACTIVE") together with the CU-UP. The instruction included in the UE Context Release Request may be called a "UE-specific" instruction because it corresponds to a specific UE 3. Based on this instruction, the DU 50 can determine the MBS service that the UE 3 should receive when the UE 3 is in an RRC inactive state.

[0102] In step S802, the DU 50 determines to maintain the MRB for PTM transmission based on the information included in the UE Context Release Request. The DU 50 may determine to continue PTM transmission for the UE 3 (e.g., all PTM transmissions from the DU 50 or a set of PTM transmissions indicated in the UE Context Release Request) based on the instruction in the UE Context Release Request.

[0103] In step S803, the DU50 sends an RRC release message to the UE3. The RRC release message includes a set (e.g., a list) of MRBs for PTM transmission to be maintained in the UE3. The UE3 receives the MRB list and decides to maintain the MRBs indicated in the list (e.g., continue to store the configuration). The set of MRBs is also called a "multicast indication." The UE3 may maintain the PTM legs corresponding to the MRBs indicated in the MRB list. Therefore, advantageously, the UE3 can continue receiving multicast transmissions from the DU50 even after transitioning to the RRC inactive state.

[0104] When UE3 is in an RRC connected state in a cell and is the only UE3 using an MBS session, when CU60 releases the RRC connection of UE3 using a UE Context Release Request, CU60 can advantageously indicate to DU50 that DU50 will maintain PTM transmission for UE3 using a list of MRBs maintained for UE3 (or an indication that all MRBs for PTM transmission to UE3 are maintained). Thus, UE3 can continue to receive PTM transmission even after there are no more UE3s in an RRC connected state in the cell (otherwise, DU50 may stop PTM transmission). Furthermore, since the RRC release message that UE3 receives from DU50 includes a list of MRBs to be maintained, UE3 can exercise control to receive the corresponding PTM transmission.

[0105] When UE 3 is in the RRC connected state, an MRB for PTM transmission is configured. Because the PTM RLC entity for each UE 3 is configured individually, the PTM RLC entity for different UEs 3 may be different. The RLC configuration may include, among other information, a logical channel identifier (e.g., "logicalChannelIdentity") and a multicast RLC bearer configuration. In this example, if UE 3's RRC connection is released to an inactive state and UE 3 maintains a PTM RLC entity (e.g., based on an MRB list received from DU 50), the network (e.g., base station 5) maintains the corresponding PTM RLC entity in the network. More generally, since the configuration used for PTM for a particular UE 3 may differ from the configuration used for PTM for another UE 3, if a particular UE 3 maintains a configuration for PTM based on the method shown in FIG. 8, the network (e.g., DU 50) also maintains that configuration.

[0106] RLC settings Alternatively, or in addition, the RLC configuration may be used to indicate the PTM to be maintained for UE 3. For example, the RLC bearer configuration may include an indication that the PTM configuration can be used when UE 3 is in an RRC inactive state. This indication is also referred to as a "multicast indication." An example of such an RLC bearer configuration that may be sent to UE 3 is shown in FIG. 8. As shown in FIG. 8, the RLC configuration includes an indication that the PTM configuration can be used when UE 3 is in an RRC inactive state. In the example of FIG. 9, this indication is an "INACTIVEPTMIndicator," which may be, for example, "TRUE" or "FALSE," or equally "1" or "0," indicating whether UE 3 can use the PTM configuration when in an RRC inactive state.

[0107] Figure 9 shows an alternative example of separately providing the multicast RLC bearer configuration for UEs in inactive state (in this example as "InactiveMulticastRLC-BearerConfig-r18") rather than including a separate indication in the list of MBS radio bearers. If the RLC configuration includes InactiveMulticastRLC-BearerConfig-r18, UE 3 can use the corresponding PTM configuration when in RRC inactive state.

[0108] Cell Reselection If the UE 3 is receiving a multicast service, and performs cell reselection in an RRC inactive state (cell reselection without resuming the RRC connection), it may be possible to continue receiving the multicast service in the new cell. In particular, if the multicast service configuration in the new cell is available to the UE 3 (e.g., the UE 3 has received the multicast service configuration in the new cell from the network), continuity of the multicast service can be supported. If the multicast service configuration in the new cell is not available to the UE 3, the UE 3 may resume the RRC connection (transition to the RRC connected state) and obtain the multicast MRB configuration from the network.

[0109] Configuration for multicast when UE is RRC inactive As described above, after UE 3 joins a multicast session, UE 3 can transition from the RRC connected state to the RRC inactive state (e.g., according to any of the methods described above). However, it is possible that the MBS session becomes inactive (e.g., because the base station decides to deactivate the MBS due to a period of data inactivity, or because there are no more UEs 3 in the RRC connected state in the cell). If the MBS session becomes inactive, UE 3 may decide (e.g., independently of base station 5) to move to the RRC inactive state to reduce power consumption.

[0110] When UE3 joins a multicast session, the problem is that although the MBS configuration is obtained from the core network, the corresponding MRB configuration is not sent to UE3 until the multicast session is active. However, UE3 may need to transition from an RRC inactive state to an RRC connected state to receive the configuration for the MRB.

[0111] The following describes how the UE moves to the RRC connected state and receives the MRB configuration.

[0112] 10 shows an example in which a UE 3 receives a paging transmission from an (R)AN node 5 (such as a base station 5). In step S121, the UE 3 is participating in a multicast session and is in an RRC inactive state.

[0113] In step S122, the MBS session is activated by the base station 5.

[0114] In step S123, the base station 5 sends a paging transmission to the UE 3.

[0115] In step S124, in response to receiving the paging from the base station 5, the UE 5 transitions to an RRC connected state.

[0116] In step S125, if the UE 3 is in an RRC connected state, the UE 3 and the base station 5 communicate to provide the UE 3 with an MRB configuration for multicast.

[0117] In step S126, an RRC release procedure is performed to return UE 3 to an inactive state (e.g., to reduce power consumption of UE 3). The RRC release procedure may be, for example, any of the RRC release procedures described above to allow UE 3 to continue receiving multicast transmissions even after UE 3 returns to an RRC inactive state.

[0118] Advantageously, in the method shown in FIG. 10, UE3, although initially in RRC inactive mode, is able to acquire the configuration for multicast, return to RRC inactive mode (which can effectively reduce power consumption and also congestion in the cell), and continue receiving multicast transmissions at the end of the procedure.

[0119] FIG. 12 shows a further example of a UE transitioning to an RRC connected state to receive information for receiving a multicast transmission.

[0120] The network may activate multiple MBS sessions, and the network may not know which MBS session is used for the UE 3 unless the UE 3 provides a corresponding indication to the network. In this example, a temporary mobile group identity (TMGI) is used to indicate a specific MBS session. The TMGI may also be used to identify an MBS bearer service. If the TMGI is not reported by the UE 3 following a paging from the base station 5, the UE 3 may need to report the TMGI via additional signaling (e.g., using an "MBSinterestedIndication" message). This causes additional delay, which is particularly disadvantageous for delay-sensitive services. Therefore, it is advantageous to include an indication of the MBS session following a paging from the base station 5 (e.g., in direct response to the paging).

[0121] In step S131, if an MBS session is activated, the (R)AN node 5 (such as, for example, a base station 5) sends a paging message to the UE 3 including the TMGI(s) of the MBS session.

[0122] In step S132, after receiving paging from the base station 5, the UE 3 sends an RRC Resume message to the base station 5. The RRC Resume message includes the TMGI of the MBS service that the UE 3 receives. Advantageously, including the TMGI in the RRC Resume message allows the network to identify the MBS service that the UE 3 receives. If the UE 3 does not notify the base station 5 of the TMGI in step S132, the UE 3 may instead perform part of the multicast session join and session establishment procedure (steps 1a to 8), for example, as described in TS 23.247 and described below with reference to Figures 12 to 14.

[0123] In step S133, the RRC resume procedure is performed and the UE 3 moves to the RRC connected state.

[0124] In step S134, after receiving the TMGI from the UE 3, the network configures a PTM leg for the UE 3. Then, an RRC Reconfiguration message containing a corresponding MRB configuration instruction is sent from the base station 5 to the UE 3. Now, since the UE 3 has the MRB configuration, the UE 3 can receive multicast from the base station 5.

[0125] In step S135, an RRC release procedure is performed to return the UE 3 to an inactive state (e.g., to reduce power consumption of the UE 3). The RRC release procedure may be, for example, any of the RRC release procedures described above.

[0126] Advantageously, at the end of this procedure, the UE 3 has an MRB configuration for receiving multicast and returns to an RRC inactive state, reducing the power consumption of the UE 3 during subsequent reception of multicast.

[0127] 12 to 14 show the multicast session joining and session establishment procedures, which are described in more detail in, for example, TS23.247 V17.4.0.

[0128] In step 1a, the UE 3 sends an uplink (UL) non-access stratum (NAS) message to the AMF 8-1.

[0129] In step 1b, the AMF 8-1 sends an Nsmf_PDUSession_UpdateSMContext request to the SMF 8-4.

[0130] In step 2, an Nnrf_NFDiscovery request / response is sent between the SMF8-4 and the Network Repository Function (NRF).

[0131] In step 3, a Nmbsmf_MBSSession_ContextStatusSubscribe request / response is sent between the SMF 8-4 and the NRF.

[0132] In step 4, an authorization check procedure is performed by the SMF 8-4 and the UPF 8-3.

[0133] In step 5, the Nsmf_PDUSession_UpdateSMContext response is sent from the SMF 8-4 to the AMF 8-1.

[0134] In step 6, an N2 message request is sent from the AMF 8-1 to the (R)AN node 5.

[0135] In step 7, if the NG-RAN supports 5g MBS, a procedure is performed to establish shared delivery to the RAN nodes.

[0136] In step 8, RRC messages (PDU Session Modification command) are exchanged between the UE 3 and the (R)AN node 5.

[0137] In step 9, an N2 message response is sent from the (R)AN node 5 to the AMF 8-1.

[0138] In step 10, an Nsmf_PDUSession_UpdateSMContext request is sent from the AMF 8-1 to the SMF 8-4.

[0139] Next, Figure 13 shows the establishment of 5GC Individual MBS traffic delivery when the NG-RAN does not support 5G MBS.

[0140] In step 11a, N4 Session Modification messages are exchanged between the SMF 8-4 and the UPF 8-3, after which procedures are performed to set up unicast transport or to request multicast DL tunnel information for multicast transport.

[0141] In step 11b, an Nmbsmf_MBSSession_ContextUpdate request is sent from the SMF 8-4 to the MB-SMF.

[0142] In step 11c, N4mb Session Modification / Create messages are exchanged between the MB-SMF and the MB-UPF.

[0143] In step 11d, an Nmbsmf_MBSSession_ContextUpdate response is sent from the MB-SMF to the SMF 8-4.

[0144] In step 11e, N4 Session Modification messages are exchanged between the SMF 8-4 and the UPF 8-3.

[0145] In step 12, an Nsmf_PDUSession_UpdateSMContext response message is sent from the SMF 8-4 to the AMF 8-1.

[0146] In step 13, the multicast data is sent from the AF to the MB-UPF.

[0147] 14 shows the transmission via 5GC Shared MBS traffic delivery. In step 14, multicast data is sent from the MB-UPF to the (R)AN node 5.

[0148] In step 15, bearer selection is performed in the (R)AN node 5.

[0149] In step 16, the multicast data is transmitted from the (R)AN node 5 to the UE 3 via PTP or PTM.

[0150] Figure 14 also shows transmission via 5GC Individual MBS traffic delivery. In step 17, multicast data is sent from MB-UPF to UPF 8-3.

[0151] In step 18, the multicast data is transmitted from the UPF 8-3 to the (R)AN node 5 via a PDU session.

[0152] In step 19, multicast data is transmitted from the (R)AN node 5 to the UE 3 via a PDU session.

[0153] Reduced occurrence of RRC connected mode While in some of the above methods it is advantageous for UE 3 to return to the RRC connected mode to acquire information (such as MRB configuration) for receiving multicast, it is also advantageous to reduce the number of times UE 3 transitions to the RRC connected state. For example, it is advantageous to avoid a situation in which multicast configuration is changed and many UEs simultaneously transition to the RRC connected state to acquire the new configuration, as this may cause random access channel (RACH) congestion. In this example, advantageously, UE 3 does not transition to the RRC connected state if UE 3 already has configuration for multicast PTM transmission.

[0154] 15 and 16 show the MBS session activation and deactivation procedures, which are described in more detail in TS 23.247 V17.4.0.

[0155] In step 1, the MB-SMF triggers session activation.

[0156] In step 2, NMBsmf_MBSSession_ContextStatusNotify is sent from MB-SMF to SMF8-4.

[0157] In step 3, a Namf_MT_EnableGroupReachability request is sent from the SMF 8-4 to the AMF 8-1.

[0158] In step 4a, a Namf_MT_EnableGroupReachability response is sent from the AMF 8-1 to the SMF 8-4.

[0159] In step 4b, a Namf_Communication N1N2MessageTransfer is sent from the SMF 8-4 to the AMF 8-1.

[0160] In step 5, the AMF pages the UE in idle mode.

[0161] In step 6, a Service Request is sent from the UE 3 to the AMF 8-1.

[0162] In step 7a, an NSmf_PDUSession_UpdateSMContext request is sent from the AMF 8-1 to the SMF 8-4.

[0163] In step 7b, an NSmf_PDUSession_UpdateSMContext response is sent from the SMF 8-4 to the AMF 8-1.

[0164] Next, referring to Figure 16, in step 8a, Namf_MT_UEReachabilityInfo_Notify is sent from the AMF 8-1 to the SMF 8-4.

[0165] In step 8b, Namf_Communication_N1N2MessageTransfer is sent from SMF 8-4 to AMF 8-1.

[0166] In step 9, an N2 request is sent from the AMF 8-1 to the (R)AN node 5.

[0167] In step 10a, establishment of 5GC Shared MBS traffic delivery is performed.

[0168] In step 10b, steps 8 to 12 described in section 7.2.1.3 of TS 23.247 V17.4.0 are performed.

[0169] In step 11, a Namf_MBSCommunication_N2MessageTransfer request (TMGI) is sent from MB-SMF to AMF 8-1.

[0170] In step 12, an NGAP activation request (TMGI) is sent from the AMF 8-1 to the (R)AN node 5.

[0171] In step 13, an NGAP activation response is sent from the (R)AN node 5 to the AMF 8-1.

[0172] In step 14, a Namf_MBSCommunication_N2Message Transfer response is sent from AMF 8-1 to MB-SMF.

[0173] In step 15, N4mb Session Modification messages are exchanged between the MB-UPF and MB-SMF.

[0174] In step 12 of the procedure shown in Figure 16, the AMF 8-1 sends an NGAP activation request message to the (R)AN node 5, after which the UE 3 can receive paging from the (R)AN node 5 and receive the corresponding configuration for PTM. In a situation where the UE 3 is participating in an MBS session but is currently in an RRC inactive state, if the PTM configuration is configured before the UE 3 moves to the RRC inactive state, the UE 3 does not need to move to an RRC connected state to obtain the PTM configuration. However, the UE 3 may move to an RRC connected state in response to receiving paging from the (R)AN node 5. An improved method for preventing the UE 3 from moving to an RRC connected state when the PTM configuration is available in the UE 3 is described below.

[0175] Figure 17 shows an example in which UE 3 does not move to an RRC connected state if a PTM configuration is available in UE 3 after receiving paging from (R)AN node 5. It will be understood that the paging in Figure 17 does not necessarily have to be paging corresponding to the methods shown in Figures 15 and 16, but may be other suitable paging from the (R)AN node 5. More generally, the (R)AN node 5 may decide to send a transmission to UE 3 to put UE 3 into an RRC connected state so that it can receive the PTM configuration, but in this example, advantageously, UE 3 remains in an RRC inactive state if UE 3 already has the PTM configuration available to UE 3 (e.g., stored).

[0176] In step 191, paging is sent from the (R)AN node 5 to the UE 3. The paging may be to bring the UE 3 into an RRC connected state so that the (R)AN node 5 can send PTM configuration to the UE 3.

[0177] In step 192, the UE 3 decides not to move to the RRC connected state despite receiving paging from the (R)AN node 5. The UE 3 may decide not to move to the RRC connected state based on multicast information stored in the UE 3 (e.g., MRB settings for PTM stored in the UE 3). Thus, advantageously, the UE 3 does not transition to the RRC connected state unnecessarily, reducing the power consumption of the UE 3 and mitigating the risk of network congestion.

[0178] Alternatively, the (R)AN node 5 may determine that the UE 3 already has a PTM configuration available to the UE 3 and decide not to send paging to the UE 3. The (R)AN node 5 may determine that the UE 3 already has a PTM configuration, for example, based on a PTM configuration previously sent from the (R)AN node 5 to the UE 3. If the (R)AN node 5 is not the same (R)AN node 5 that previously sent the PTM configuration to the UE 3, the (R)AN node 5 may receive an indication from the network indicating that the UE 3 already has a PTM configuration and decide not to send the corresponding paging to the UE 3.

[0179] DCI and HARQ scheduling information In wireless communications, some transmitted packets may be lost or may be erroneous due to noise or interference. Hybrid Automatic Repeat Request (HARQ) procedures can be used to mitigate such packet loss and errors by using retransmission (or selective retransmission) of data packets. For example, a UE 3 may receive a transmission from a base station 5 that includes errors or missing packets. The UE 3 may attempt to correct errors in the received transmission, if possible, and may provide feedback to the base station 5 regarding the received transmission, including, for example, an acknowledgement (ACK) or negative acknowledgement (NACK). Based on this feedback, the base station 5 may retransmit some or all of one or more original transmissions.

[0180] The HARQ procedure may include multiple simultaneous HARQ processes, each used for a respective part of the transmission. Thus, while the base station 5 is waiting for feedback from the UE 3 corresponding to a particular HARQ process (and thus a particular part of the transmission), it can continue transmitting data for other HARQ processes.

[0181] Information about the HARQ process (e.g., HARQ configuration), including the time and frequency resources that the UE 3 uses to send the HARQ acknowledgement, can be provided to the UE 3 using downlink control information (DCI), as described in more detail below. The DCI may, for example, include a dedicated bit indicating whether HARQ feedback is enabled (or disabled) for a particular HARQ process.

[0182] An example of a method for UE 3 to send HARQ feedback based on DCI is shown in Figure 18. In step S171, UE 3 receives DCI from base station 5. The DCI includes HARQ configuration information for at least one HARQ process. In step S172, the base station sends a corresponding downlink transmission to UE 3. In step S173, UE 3 sends HARQ feedback to base station 5 based on the HARQ configuration information received in the DCI from base station 5 in step S171.

[0183] The inventors have found that the continuity of MBS services can be improved by improving the method of transmitting DCI to UEs 3 in RRC connected and RRC inactive states when the UEs 3 transition between the RRC connected and RRC inactive states. The types of DCI transmitted from the base station 5 to the UEs 3 are described in more detail below.

[0184] DCI4_0 DCI format 4_0 is used for scheduling a PDSCH for broadcast within a cell. In other words, DCI format 4_0 is a DCI for broadcast. DCI format 4_0 may be simply referred to as DCI4_0.

[0185] DCI4_0 and the corresponding PDCCH configuration may be used to send a broadcast to UEs 3 that are in an RRC connected state, an RRC inactive state, or an RRC idle state.

[0186] DCI4_0 may be transmitted with a cyclic redundancy check scrambled by the MBMS point-to-multipoint Control Channel (MCCH) radio network temporary identifier (RNTI), MCCH-RNTI, or group-RNTI (G-RNTI) for the multicast traffic channel (MTCH), as configured by the MBS session information (such as MBS-SessionInfo).

[0187] DCI4_0 is the frequency domain resource allocation

number

number

[0188] DCI4_0 contains the time domain resource allocation, which is used to indicate the slot offset, PDSCH mapping type, starting symbol, and number of allocated symbols. This information may be indicated using a lookup table (the time domain resource allocation may contain a pointer to the lookup table).

[0189] DCI4_0 contains the virtual resource block (VRB) to physical resource block (PRB) mapping. The VRB to PRB mapping is a field used to indicate whether the PDSCH uses non-interleaved VRB to PRB mapping or interleaved VRB to PRB mapping. In non-interleaved mapping, a specific VRB index is mapped to the PRB with the same index. In interleaved mapping, a function is used to map a specific VRB index to the corresponding PRB index.

[0190] DCI4_0 contains an indication of the modulation and coding scheme (MCS) in the form of a pointer to a lookup table.

[0191] DCI4_0 includes a redundancy version (RV) that indicates the corresponding puncturing pattern.

[0192] If the CRC of DCI4_0 is scrambled by the MCCH-RNTI, DCI4_0 contains an MCCH change notification.

[0193] It will be appreciated that a modified version of DCI4_0 may be used that omits some of the above information (such as the MCCH change notification) if desired.

[0194] Unlike DCI4_1 and DCI4_2 described below, DCI4_0 does not include fields indicating HARQ scheduling information for UE 3 in an RRC connected state, such as a new data indicator (NDI), a HARQ process number, or an indication of a HARQ frequency or time resource.

[0195] DCI4_1 DCI format 4_1 (and the corresponding PDCCH configuration) is used for multicast transmission. DCI format 4_1 may be simply referred to as DCI4_1.

[0196] If DCI4_1 is used, the same transmission configuration index (TCI) state as the TCI state for the unicast PDCCH may be used.

[0197] DCI4_1 includes frequency domain resource allocation, time domain resource allocation, VRB to PRB mapping, MCS and RV as described above for DCI4_0.

[0198] DCI4_1 also includes a HARQ process number indicating the corresponding HARQ process.

[0199] DCI4_1 may include a new data indicator (NDI) that is used to indicate whether the resource allocation is for a retransmission or a new transmission.

[0200] DCI4_1 contains a PUCCH resource indicator that indicates that UE3 should use a specific PUCCH resource when returning the HARQ acknowledgement. If UE3 is configured with dedicated PUCCH resources, the PUCCH resource indicator may indicate one of those resources. The PUCCH resource indicator may be in the form of a 3-bit field.

[0201] DCI4_1 contains a PDSCH-HARQ feedback timing indicator that indicates the number of slots between the reception of the PDSCH and the transmission of the HARQ feedback. The PDSCH-HARQ feedback timing indicator may be in the form of a 3-bit field.

[0202] It will be appreciated that a modified version of DCI4_1 that omits some of the above information can be used if desired.

[0203] DCI4_2 DCI format 4_2 is used for PDSCH scheduling. DCI format 4_2 may be simply referred to as DCI4_2. DCI4_2 for multicast MBS includes the TCI status for PDSCH reception.

[0204] DCI4_2 may be scrambled by the G-RNTI and transmitted along with a cyclic redundancy check configured by G-RNTI configuration information (such as G-RNTI-Config) or group-configured scheduling-RNTI (G-CS-RNTI).

[0205] DCI4_2 includes frequency domain resource allocation, time domain resource allocation, VRB to PRB mapping, PRB bundling size indicator, rate matching indicator, zero power channel status information reference signal (ZP-CSI-RS) trigger, HARQ process number, downlink assignment index, PUCCH resource indicator, PDSCH-to-HARQ feedback timing indicator, antenna port indication, transmission configuration indication, demodulation reference signal (DMRS) sequence initialization, priority indicator, and enabling / disabling HARQ-ACK feedback indication (a value of 1 indicates enabling HARQ-ACK feedback, and a value of 0 indicates disabling HARQ-ACK feedback).

[0206] It will be appreciated that a modified version of DCI4_2 that omits some of the above information can be used if desired.

[0207] The size of DCI4_2 can be set, for example, in the range from 20 bits to 140 bits.

[0208] DCI4_0, DCI4_1, and DCI4_2 are described in more detail in 3GPP TS 38.212 V17.3.0.

[0209] RRC release Some elements of the RRC release procedure are described in more detail below. When UE 3 receives the RRC release message, it resets its MAC, releases any default MAC cell group configuration, re-establishes the RCL entity for signaling radio bearer 1 (SRB1), suspends all SRB(s) and data radio bearers (DRBs) and one or more multicast MRBs except signaling radio bearer 0 (SRB0), notifies lower layers of all DRBs and multicast MRBs of packet data convergence protocol (PDCP) suspension, and notifies upper layers of the suspension of the RRC connection. UE 3 moves to an RRC inactive state and performs cell selection.

[0210] After receiving the RRC release message, the UE 3 flushes one or more buffers corresponding to the DL HARQ processes, except for the DL HARQ process used for the MBS broadcast. For each DL HARQ process, the UE 3 considers the next received transmission for a transport block (TB) as the first transmission.

[0211] If higher layers request re-establishment of the RLC entity, the UE 3 discards all RLC service data units (SDUs), RLC SDU segments, and RLC protocol data units (PDUs), if any, stops and resets all timers, and resets all state variables to their initial values.

[0212] If the upper layer requests the PDCP entity to be suspended, the receiving PDCP entity stops and resets the reordering timer, performs header decompression, and then passes all stored PDCP SDUs to the upper layer in ascending order of their associated count values.

[0213] The inventors have found that when UE3 transitions from the RRC connected state to the RRC inactive state, multicast reception may be interrupted (service reception may not be continued) due to HARQ buffer flushing, MAC reset, RLC re-establishment, and PDCP suspension. However, in MBS multicast, service continuity may be required (for example, when the MBS is a public safety service). An improved method for mitigating this problem when UE3 transitions from the RRC connected state to the RRC inactive state will be described below.

[0214] RRC restart Some elements of the RRC resume procedure are described in more detail below: Upon receiving the RRC resume message, the UE 3 performs cell group configuration for the receiving master cell group (e.g., masterCellGroup), which includes both RLC re-establishment / RLC establishment and MAC configuration. If the RRC resume message includes radio bearer configuration, the UE 3 performs radio bearer configuration. If signaling radio bearer 2 (SRB2) is suspended, the UE 3 resumes SRB2. The UE 3 also resumes SRB3 and SRB4, if configured. The UE 3 also resumes all suspended DRBs and multicast MRBs. The UE 3 may re-establish the PDCP entities for the multicast MRBs.

[0215] When an upper layer requests the establishment of an RLC entity, the UE 3 establishes the RLC entity and sets the state variables of the RLC entity to their initial values.

[0216] If re-establishment of the RLC entity is requested by higher layers, the UE 3 discards all RLC SDUs, RLC SDU segments, and RLC PDUs, if any. The UE 3 stops and resets all timers and resets state variables to their initial values. For UM DRBs and UM MRBs, the UE 3 performs header decompression and then passes all stored PDCP SDUs to higher layers in ascending order of their associated count values. For AM DRBs and AM MRBs for the Uu interface, the UE 3 may perform header decompression using robust header compression (ROHC) for all stored PDCP SDUs. For UM DRBs, AM DRBs, UM MRBs, and AM MRBs, the UE 3 may reset the ROHC protocol for the downlink and enter the no context (NC) state in unidirectional mode (U-mode), where packets are transmitted in only one direction (from compressor to decompressor).

[0217] The inventors have found that when UE3 transitions from the RRC inactive state to the RRC connected state, multicast reception may be interrupted (service reception may not be continued) due to MAC configuration, RLC establishment / re-establishment, and PDCP re-establishment. However, in MBS multicast, service continuity may be required (for example, when the MBS is a public safety service). An improved method for mitigating this problem when UE3 transitions from the RRC inactive state to the RRC connected state will be described below.

[0218] Multicast transmission and Group Common PDSCH The PDSCH is used to transport end user application data, signaling radio bearer (SRB) messages, system information, and paging messages. The Group common PDSCH (GC-PDSCH) is a PDSCH transmitted for reception by a corresponding group of UEs 3.

[0219] In a cell of a communication network, there may be one or more UEs 3 in an RRC connected state and one or more UEs 3 in an RRC inactive state. A DCI (e.g., DCI4_1 or DCI4_2) transmitted to a UE 3 in an RRC connected state may include HARQ scheduling information such as an NDI, a HARQ process number, a HARQ feedback time resource, and a HARQ feedback frequency resource. A DCI used to schedule multicast transmissions for UEs 3 in an RRC inactive state does not need to carry HARQ scheduling information if the network assumes there will be no HARQ feedback for these UEs 3. A single MBS multicast cell supports multicast transmissions to UEs 3 in both an RRC connected state and an RRC inactive state. Two different types of DCI may be used to schedule multicast transmissions: one type for UEs in an RRC connected state and another type for UEs in an RRC inactive state.

[0220] A common identifier, Group-RNTI (G-RNTI), can be used to group and identify a group of UEs camped on a cell. The use of G-RNTI allows for more flexible scheduling of unicast and multicast data within the PDSCH channel. Based on the G-RNTI, a single DCI can be sent to a group of UEs, allowing those UEs to receive a particular downlink transmission. Using the G-RNTI to identify a group of UEs (rather than individual UEs) reduces PDCCH overhead. In the case of multicast, UEs participating in a particular MBS session may be configured with the same G-RNTI to receive the MBS session.

[0221] The above describes a method for UE 3 to continue receiving multicast transmissions when UE 3 transitions from an RRC connected state to an RRC inactive state (or from an RRC inactive state to an RRC connected state). A particularly advantageous method for improving MBS continuity (e.g., reducing interruptions in MBS reception by UE 3) when UE 3 transitions from an RRC connected state to an RRC inactive state (or from an RRC inactive state to an RRC connected state) is described below. The below-described method for improving MBS continuity may be applied to any of the above-described methods as appropriate, although it will be appreciated that the below-described improved method is not limited to application to the above-described methods and may also be applied to other suitable methods for UE 3 transitioning from an RRC connected state to an RRC inactive state (or from an RRC inactive state to an RRC connected state).

[0222] Same GC-PDSCH An example will be described in which the same GC-PDSCH is used for MBS multicast transmission for both UEs 3 in an RRC connected state and UEs 3 in an RRC inactive state, where if HARQ scheduling information is provided, the HARQ scheduling information is common to both UEs 3 in an RRC connected state and UEs 3 in an RRC inactive state.

[0223] No HARQ schedule information In the first option, no HARQ scheduling information is provided. In this case, either a single DCI or two different DCIs may be used to schedule multicast transmissions for the GC-PDSCH. For example, both the RRC-connected UE 3 and the RRC-inactive UE 3 receive multicast transmissions using a single HARQ process. During a state transition between the RRC-connected state and the RRC-inactive state, the UE 3 maintains the HARQ process (the identifier of the HARQ process used by the UE does not change when the UE transitions from the RRC-connected state to the RRC-inactive state) and does not flush the corresponding HARQ buffer (also known as a "soft buffer"). Advantageously, maintaining the HARQ process and not flushing the corresponding HARQ buffer improves the continuity of multicast reception when the UE 3 transitions between the RRC-connected state and the RRC-inactive state.

[0224] Multiple HARQ processes for RRC inactive UEs A further improved method of providing HARQ scheduling information to increase the reliability of transport block (TB) transmissions over the air interface to UEs 3 is described below. In this example, HARQ scheduling information is provided that includes an NDI, a HARQ process ID, a HARQ feedback resource, and a HARQ timing resource (or other suitable HARQ information, e.g., as described above with reference to DCI4_1 and DCI4_2). Advantageously, in addition to RRC-connected UEs 3, RRC-inactive UEs 3 can also use the same set of HARQ processes to receive multicast transmissions and can utilize HARQ retransmissions even if the RRC-inactive UEs 3 do not send HARQ feedback.

[0225] In this example, an RRC-connected UE 3 receiving multicast uses the HARQ scheduling information provided in the DCI (e.g., DCI4_1 or DCI4_2) received from the base station 5. The RRC-connected UE 3 may transmit HARQ feedback to the base station 5 based on the HARQ configuration information included in the DCI. The RRC-inactive UE 3 also receives downlink data transmitted using HARQ processes. Advantageously, the RRC-inactive UE 3 receives and processes downlink transmissions using the NDI and HARQ process number indicated in the DCI. For example, the RRC-inactive UE 3 can use the NDI to determine whether a downlink transmission corresponds to new data or a retransmission. The RRC-inactive UE 3 may be configured not to transmit HARQ feedback (in which case the RRC-inactive UE 3 may ignore the HARQ feedback frequency and time resources provided in the DCI). In this case, because the RRC-inactive UE 3 does not send HARQ feedback, the HARQ retransmission by the base station 5 serving the MBS multicast cell is based on feedback (e.g., NACK) from the RRC-connected UE 3. However, because the RRC-inactive UE 3 is receiving multicast using the same HARQ process, the RRC-inactive UE 3 may still receive HARQ retransmissions. The RRC-inactive UE 3 may be configured to simply ignore received multicast HARQ retransmissions if the UE 3 has already successfully received and decoded the corresponding transport block. However, in this example, the UE 3 may advantageously use (receive and process) the received HARQ retransmission if the UE 3 has not successfully received and decoded the transport block corresponding to the HARQ retransmission. For example, the UE 3 may instruct the physical layer to combine the received HARQ retransmission with the data currently stored in the buffer for the corresponding transport block and attempt to decode the combined data.Therefore, even if the UE 3 is in an RRC inactive state and has not sent any HARQ feedback, the UE 3 can still take advantage of HARQ retransmissions and improve the reliability of MBS multicast reception over the air interface.

[0226] Single HARQ process for RRC inactive UEs An example in which an RRC inactive UE 3 receives downlink data using one HARQ process is described below. In this example, similar to the above example in which multiple HARQ processes are used, HARQ scheduling information is provided, including an NDI, a HARQ process ID, a HARQ feedback resource, and a HARQ timing resource (or other suitable HARQ information, e.g., as described above with reference to DCI4_1 and DCI4_2). However, in this example, a single HARQ process is used. The RRC connected UE 3 may transmit HARQ feedback to the base station 5 based on the HARQ configuration information included in the DCI of the single HARQ process. The RRC inactive UE 3 also receives downlink data transmitted using the HARQ process. In this example, the RRC inactive UE 3 attempts to decode each transport block for a received multicast rather than identifying retransmissions, and passes successfully decoded transport blocks to the MAC layer. In this example, because the UE 3 does not distinguish whether the transmission is a new data transmission or a retransmission (because the same PDSCH is used for RRC-connected and RRC-inactive UEs, and the inactive UE 3 does not request retransmissions), duplicate transport blocks may be passed to the MAC layer of the UE 3. However, layer 2 (L2) protocol functions can be used to remove the duplicate transport blocks. Advantageously, this example simplifies the operation of the RRC-inactive UE 3, since it only needs to be configured to receive data using a single HARQ process.

[0227] Different GC-PDSCH An example in which the GC-PDSCH used for an RRC-connected UE 3 is different from the GC-PDSCH used for an RRC-inactive UE 3 will be described below with reference to Figure 19, which shows three HARQ processes corresponding to a first GC-PDSCH for one or more RRC-connected UEs 3 and a second GC-PDSCH for one or more RRC-inactive UEs 3. Transport blocks 1 to 6 transmitted using these HARQ processes are also shown. As shown in Figure 19, HARQ process 2 includes the initial transmission of transport block 2, indicated by a solid line, and a retransmission of transport block 2, indicated by a dashed line.

[0228] The two GC-PDSCHs are scheduled using different DCIs. For example, DCI 4_0 may be used for the GC-PDSCH for RRC inactive UE 3, and DCI 4_1 or 4_2 may be used for the GC-PDSCH for RRC connected UE 3. The two GC-PDSCHs may be multiplexed using frequency division multiplexing (FDM), time division multiplexing (TDM), or both. Advantageously, in this example, UE 3 can receive both GC-PDSCHs (e.g., simultaneously or substantially simultaneously), thereby improving the continuity of the MBS multicast service when UE 3 transitions from an RRC connected state to an RRC inactive state (or from an RRC inactive state to an RRC connected state).

[0229] The HARQ scheduling information may be provided to the RRC connected UE 3 using DCI for the HARQ processes of the corresponding GC-PDSCH (in this example, HARQ process-1 to HARQ process-3 shown in FIG. 19).

[0230] As shown in Figure 19, transport blocks for both GC-PDSCHs can be delivered from the network to UE 3 in an overlapped and synchronized manner. In other words, a particular transport block constructed based on a MAC PDU can be transmitted by base station 5 over the air interface using both GC-PDSCHs at approximately (or exactly, or substantially) the same time. For example, as shown in Figure 19, transport block 3 is transmitted approximately simultaneously on the first GC-PDSCH and the second GC-PDSCH. This synchronization can be advantageously maintained even when HARQ feedback and HARQ retransmissions are used for the GC-PDSCH for UE 3 of the RRC connection (first GC-PDSCH in Figure 19). For example, as shown in Figure 19, HARQ process 2 includes a retransmission of transport block 2, indicated by the dashed line. This retransmission may occur when one of UEs 3 of the RRC connection sends a NACK for transport block 2 to base station 5. To maintain synchronization between the first and second GC-PDSCHs, in this example, no transport blocks are transmitted using the second GC-PDSCH during the period in which the first GC-PDSCH is retransmitted. Subsequently, after the HARQ retransmission in HARQ process-2, the method proceeds to HARQ process-3 and the HARQ process for the second GC-PDSCH, both of which are used to transmit transport block 5 (the next transport block in the sequence), thereby maintaining synchronization between the first and second GC-PDSCHs.

[0231] 19, the second GC-PDSCH includes a WAIT period between retransmissions of transport block 2, but this is not necessary. Alternatively, overlapping transmissions may be performed at the PDCP and / or RLC layers. In other words, two different RLC entities may be established to support transmissions on the two GC-PDSCHs, in which case synchronized transmission of the transport blocks is not required.

[0232] DCI / HARQ switching An example of switching the DCI to a different format is described below with reference to Figure 20. When UE 3 transitions between an RRC connected state and an RRC inactive state, the DCI may be switched to support multicast reception after the transition. In this example, an RRC release message sent from base station 5 to UE 3 is used to inform UE 3 of the new DCI and corresponding PDCCH configuration (although any other suitable transmission from base station 5 to UE 3 could be used instead).

[0233] As mentioned above, the DCI for multicast reception when the UE 3 is in the RRC inactive state does not necessarily include HARQ scheduling information for HARQ feedback. When the UE 3 is in the RRC connected state, the multicast may be provided using multiple HARQ processes, and when the UE 3 is in the RRC inactive state, the multicast may be provided using a single HARQ process.

[0234] In this example, the DCI (e.g., DCI4_1 or DCI4_2) of a UE in an RRC connected state includes a corresponding HARQ process number, and multicast reception is based on multiple HARQ processes (each associated with a corresponding HARQ buffer). If the DCI is switched to a new format or to the format used for broadcast (e.g., DCI4_0), the HARQ process number is not indicated and UE 3 can assume a single HARQ process. In this case, UE 3 can flush (empty or overwrite) the previous HARQ buffer and release the corresponding HARQ process. The new HARQ process is used for subsequent multicast reception.

[0235] As shown in Figure 20, in step S200, UE3 is initially in an RRC connected state. In step S201, UE3 receives a DCI (such as DCI4_1 or DCI4_2) for a HARQ process to receive the corresponding MBS multicast.

[0236] In step S202, the UE 3 receives DL multicast data transmitted using multiple HARQ processes.

[0237] In step S203, the UE 3 stores the received data in separate buffers for each HARQ process ID.

[0238] In optional step S204, the UE 3 transmits HARQ feedback for the HARQ process to the base station 5. It will be appreciated that the HARQ feedback may be set based on the DCI received in step S201 (or the DCI may include an indication that no HARQ feedback is required).

[0239] In step S205, for example, after the base station determines that UE 3 moves to an RRC inactive state (e.g., due to a high RRC load), the base station sends an RRC release message to UE 3. The RRC release message includes an indication of a multicast MRB configuration. Following reception of the RRC release message, UE 3 transitions from an RRC connected state to an RRC inactive state.

[0240] In step S206, the UE3 is in the RRC inactive state and applies the multicast MRB configuration received from the base station 5.

[0241] In step S207, the base station 5 transmits DCI corresponding to the new multicast MRB configuration to the UE 3. In this example, a single HARQ process is used for the UE 3 in the RRC inactive state.

[0242] In step S208, UE3 receives DL multicast data corresponding to a single HARQ process, and thus continues receiving multicast.

[0243] In the method shown in Figure 20, the multicast MRB configuration information (also referred to as multicast configuration information or DCI configuration information) included in the RRC release message advantageously allows the UE 3 to continue receiving MBS multicasts even after transitioning to the RRC inactive state. The UE 3 transitions from receiving multicasts using multiple HARQ processes while in the RRC connected state to receiving multicasts using a single HARQ process while in the RRC inactive state.

[0244] The method illustrated in FIG. 20 may be applied to any of the methods for providing MBS multicast using multiple HARQ processes or a single HARQ process described above, where appropriate.

[0245] While the method of Figure 20 describes the transition of UE 3 from an RRC connected state to an RRC inactive state with reference to an RRC release procedure, the DCI may be switched as part of the transition from the RRC inactive state to the RRC connected state. For example, a new multicast MRB configuration may be provided to UE 3 from the base station as part of the RRC resume procedure. UE 3 may switch from receiving multicast via a single HARQ process while in the RRC inactive state to receiving multicast via multiple HARQ processes when in the RRC connected state.

[0246] While the method of FIG. 20 has the advantage that UE3 can continue receiving MBS multicasts even after transitioning to the RRC inactive state, FIG. 21 illustrates an example of a situation in which UE3 may be unable to receive and decode one or more transport blocks. This situation can occur when using the method of FIG. 20 and DCI switching coincides with a failure to receive and decode a transport block. In the example shown in FIG. 21, the reception and decoding of transport block 5 (indicated by the dashed line) fails, and a corresponding NACK is sent from UE3 to the base station. However, in this example, DCI switching occurs immediately after the failure to decode transport block 5. Due to the switch to the new MRB configuration, the transport blocks that were not successfully decoded are removed from the HARQ buffer and are not sent to the MAC layer. In this example, UE3 is unable to successfully receive and decode transport block 5. Furthermore, in this example, transport blocks 6 and 7 are also not received by UE3 due to the time required to switch to the new DCI / HARQ process. A further improved method using early DCI switching to mitigate these issues is described below.

[0247] Early Switchover An example in which new DCI and corresponding PDCCH configuration are provided to UE 3 before UE 3 is released to RRC inactive state will be described below with reference to Figures 22 and 23. This method advantageously allows multicast transport blocks to be more reliably received and decoded at UE 3, improving MBS multicast continuity when UE 3 transitions from RRC connected state to RRC inactive state.

[0248] In this example, UE3 is configured to monitor two different DCIs simultaneously and to maintain two multicast data receptions using two separate buffers (or two separate buffer sets), but only one copy of the received data (e.g., received transport blocks) is sent to the MAC layer (alternatively, appropriate L2 processing can be used to remove duplicate transport blocks). Advantageously, the methods shown in Figures 22 and 23 avoid switching delays between the two configurations (including possible RRC message parsing delays in the example of Figure 20) and avoid gaps in transport block reception caused by decoding failures as shown in Figure 21.

[0249] Next, referring to Figure 22, in step S210, UE3 is in an RRC connected state. Steps 211 to 214 are the same as steps S201 to S204 in Figure 20, and therefore will not be described again here.

[0250] In step S215, UE 3 receives an indication of a new multicast MRB configuration from base station 5. However, unlike the method shown in Figure 20, UE 3 remains in an RRC connected state at this stage. Because the information indicating the new multicast configuration is received before RRC release occurs, step S215 is sometimes referred to as an "early" multicast configuration indication.

[0251] In step S216, the UE 3 applies the received multicast configuration and can simultaneously receive multicast using two DCIs (using corresponding HARQ processes).

[0252] In step S217, UE3 receives two DCIs (eg, DCI4_1 / 4_2 and DCI4_0) for multicast.

[0253] In step S218, the UE 3 receives the multicast data using two DCIs (using corresponding HARQ processes), in other words, simultaneous (or nearly simultaneous) reception of the multicast data using the two DCIs is performed.

[0254] In step S219, DCI / HARQ switching is performed, and UE3 switches to using the new multicast MRB configuration received in step S215 and no longer receives multicast using the previous DCI settings (corresponding to step S211).

[0255] In step S220, the base station 5 sends an RRC release message to the UE 3, after which the UE 3 transitions to the RRC inactive state. However, since the DCI / HARQ switch to the new DCI and HARQ processes has already been performed, the continuity of reception of MBS multicast is improved, and the reception and decoding of downlink data at the UE 3 is more reliable.

[0256] Referring now to FIG. 23, in this example, transport block 1 of HARQ process-1 is not successfully received and decoded by UE3. As shown in FIG. 23, UE3 sends a corresponding NACK, and transport block 1 is retransmitted in HARQ process-1. UE3 also receives transport blocks 2 and 3 in HARQ process-2 and HARQ process-3, respectively. After receiving the HARQ retransmission of transport block 1, a new MRB configuration is applied in UE3 (corresponding to step S216 in FIG. 22). It will be appreciated that at this stage, UE3 has already received an indication of the new multicast MRB configuration in step S215 of FIG. 22. UE3 can now receive transport block 4 both in HARQ process-2 and in the new HARQ process (configured in step S215). Advantageously, even if there is a delay in configuring the new HARQ process and transport block 4 cannot be received using the new HARQ process, transport block 4 can still be received using the existing HARQ process-2. Following reception of transport block 4, a DCI / HARQ switch occurs in step 219, and UE 3 moves to the RRC inactive state (after receiving the RRC release message in step S220 of FIG. 22). UE 3 then proceeds to receive transport blocks 5-9 using the newly configured HARQ process. However, because the new HARQ process was already configured before switching to the RRC inactive mode, this advantageously avoids a situation in which some transport blocks are not received, as shown in FIG. 21. It will be appreciated that in the example shown in FIG. 23, depending on the timing of the HARQ / DCI switch in step 219, transport block 5 may be received by UE 3 on both HARQ process-3 for the RRC inactive state and the new HARQ process, or may be received by UE 3 only on the new HARQ process (although it is advantageous that transport block 5 is received on at least one HARQ process).

[0257] RRC release An improved method including an RRC release procedure is described below: In this example, when UE 3 is in an RRC connected state, the multicast MRB is configured as a DL-only RLC-UM entity for PTM transmission.

[0258] To improve MBS multicast continuity when a transition from an RRC connected state to an RRC inactive state occurs, the multicast MRB used when the UE 3 is in the RRC connected state is not suspended. Advantageously, the UE multicast MRB is maintained during the transition to the RRC inactive state, improving MBS multicast continuity. The PDCP and RLC entities of the multicast MRB at the UE 3 continue to operate during the transition (e.g., the PDCP "RX_NEXT" and "RX_DELIV" count values ​​continue to operate). The PDCP t-reordering timer (used to detect lost PDCP Data PDUs) also continues to operate.

[0259] In this example, if UE3 is in a connected state, the multicast MRB may be configured as follows: - Multicast MRB with bidirectional RLC-UM configuration for PTP transmission, -Multicast MRB with RLC-AM entity configuration for PTP transmission, A multicast MRB having two RLC-UM entities, one DL-only RLC-UM entity for PTP transmission and one DL-only RLC-UM entity for PTM transmission; A multicast MRB with three RLC-UM entities: one DL RLC-UM entity and one UL RLC-UM entity for PTP transmission and one DL-only RLC-UM entity for PTM transmission; or A multicast MRB with two RLC entities: one RLC-AM entity for PTP transmission and one DL-only RLC-UM entity for PTM transmission.

[0260] Before transitioning from the RRC connected state to the RRC inactive state (e.g., before UE3 is released using an RRC release message), UE3 switches the multicast MRB bearer type to RLC-UM entity-based PTM transmission. Before transitioning to the RRC inactive state, UE3's PTP reception leg for the multicast MRB is terminated. UE3's multicast MRB is maintained during the transition, and the PDCP entity and RLC entity for the multicast MRB in UE3 continue to operate (as described above).

[0261] RRC restart An improved method including an RRC resumption procedure is described below. In this example, UE 3 receives multicast services via PTM transmissions when in an inactive state. UE 3 monitors the group-scheduled PDDCH via the common frequency resource (CFR) for multicast. The multicast MRB is configured as a DL-only RLC-UM entity for PTM transmissions.

[0262] If the GC-PDSCH used for UE3 in the RRC connected state is the same as the GC-PDSCH used for UE3 in the RRC inactive state, UE3 continues to use the DL HARQ process (used when UE3 is in the RRC inactive state) for multicast reception. If UE3 monitors a new DCI for multicast reception during the transition to the RRC connected state, the buffer (e.g., soft buffer) for receiving data corresponding to the DL HARQ process can be maintained (not flushed). The UE3 multicast MRB is maintained (no new MRB establishment) during the transition from the RRC inactive state to the RRC connected state. Therefore, the continuity of MBS multicast during the transition is advantageously improved. Because the multicast MRB is maintained, the PDCP and RLC entities of the multicast MRB in UE3 continue to operate (e.g., continue to operate the PDCP "RX_NEXT" and "RX_DELIV" count values). The PDCP t-reordering timer (used to detect PDCP Data PDU loss) also continues to operate.

[0263] Alternatively, if the GC-PDSCH used for UE3 in the RRC connected state is not the same as the GC-PDSCH used for UE3 in the RRC inactive state, a new set of DL HARQ processes is used, and multicast reception continues at UE3. The DL HARQ processes used for multicast PTM reception when UE3 is in the RRC inactive state are released, and the corresponding HARQ soft buffers are flushed until UE3 can receive the newly configured GC-PDSCH via the new DCI when UE3 is in the RRC connected state. Alternatively, simultaneous reception of two GC-PDSCHs at UE3 is possible. In this case, only one copy of the transport block (received via both GC-PDSCHs) is passed to the MAC layer after being decoded at the physical layer (or processed using appropriate L2 processing for the duplicated transport block). The multicast MRB at UE3 is maintained during the transition from the RRC inactive state to the RRC connected state. If the GC-PDSCH used for UE3 in the RRC connected state is the same as the GC-PDSCH used for UE3 in the RRC inactive state, the PDCP entity and the RLC entity continue to operate as described above.

[0264] User Equipment FIG. 24 is a schematic block diagram illustrating the main components of the UE 3 shown in FIG.

[0265] As shown, the UE 3 includes transceiver circuitry 310 capable of transmitting signals to and receiving signals from a base station 5 via one or more antennas 330 (e.g., comprising one or more antenna elements). The UE 3 includes a controller 370 that controls the operation of the UE 3. The controller 370 is associated with a memory 390 and coupled to the transceiver circuitry 310. Although not necessary for the operation of the UE 3, the UE 3 may include all of the usual functionality of a traditional UE 3 (e.g., a user interface 350, such as a touchscreen / keypad / microphone / speaker, that allows for direct user control and interaction), which may be provided by any or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 390 and / or downloaded, for example, via a communications network or a removable data storage device (RMD).

[0266] Controller 370, in this example, is configured to control the overall operation of UE 3 via program or software instructions stored in memory 390. As shown, these software instructions include, among other things, an operating system 410 and a communications control module 430.

[0267] The communications control module 430 is operable to control communications between the UE 3 and its one or more serving base stations 5 (and other communications devices connected to the base stations 5, e.g., other UEs and / or core network nodes). The communications control module 430 is configured to perform overall processing of uplink communications over associated uplink channels (e.g., physical uplink control channel (PUCCH), random access channel (RACH), and / or physical uplink shared channel (PUSCH)), including both dynamic signaling and semi-static signaling (e.g., SRS). The communications control module 430 is also configured to perform overall processing of reception of downlink communications over associated downlink channels (e.g., physical downlink control channel (PDCCH) and / or physical downlink shared channel (PDSCH)), including both dynamic signaling and semi-static signaling (e.g., CSI-RS). The communications control module 430 is responsible for, for example, determining where to monitor downlink control information (such as the location of the CSS / USS to monitor, CORESET, and associated PDCCH candidates), determining the resources the UE 3 will use to transmit / receive UL / DL communications (including interleaved resources and resources subject to frequency hopping), managing frequency hopping at the UE side, determining how to configure slots / symbols (e.g., for UL, DL, or SBFD communications), determining which bandwidth portion or portions are configured for the UE 3, determining how uplink transmissions should be coded, appropriately applying SBFD-specific communications configurations, etc. The communications control module 430 may be configured to control communications according to any of the methods described above (e.g., receiving multicast transmissions from the base station 5 or sending HARQ feedback to the base station 5).

[0268] base station FIG. 25 is a schematic block diagram illustrating the main components of a base station 5 of the communication system 1 shown in FIG. 1. As shown, the base station 5 comprises a transceiver circuit 510 for transmitting signals to and receiving signals from communication devices (such as UE 3) via one or more antennas 530 (e.g., single or multi-panel antenna arrays / large-scale antennas), and a core network interface 550 (e.g., including N2, N3, and other reference points / interfaces) for transmitting signals to and receiving signals from network nodes in the core network 7. Although not shown, the base station 5 may connect to other base stations via an appropriate interface (e.g., the so-called "Xn" interface in NR). The base station 5 comprises a controller 570 that controls the operation of the base station 5. The controller 570 is associated with a memory 590. Software may be pre-installed in the memory 590 and / or downloaded via the communication system 1 or from a removable data storage device (RMD), etc. Controller 570, in this example, is configured to control the overall operation of base station 5 by means of program or software instructions stored in memory 590. As shown, these software instructions include, among other things, an operating system 610 and a communications control module 630.

[0269] The communications control module 630 is operable to control communications between the base station 5 and the UEs 3 and other network entities connected to the base station 5. The communications control module 630 is configured to generally control the reception and decoding of uplink communications over associated uplink channels (e.g., physical uplink control channel (PUCCH), random-access channel (RACH), and / or physical uplink shared channel (PUSCH)), including both dynamic signaling and semi-static signaling (e.g., SRS). The communications control module 630 is also configured to generally handle the transmission of downlink communications over associated downlink channels (e.g., physical downlink control channel (PDCCH) and / or physical downlink shared channel (PDSCH)), including both dynamic signaling and semi-static signaling (e.g., CSI-RS). The communications control module 630 is responsible for managing full-duplex communications (e.g., SBFD), including separating UL and DL communications over different physical antenna elements, if necessary. The communication control module 630 is responsible for, for example, determining the configuration locations for the UE 3 to monitor for downlink control information (e.g., the locations of the CSS / USS, CORESET, and associated PDCCH candidates to monitor), determining the resources scheduled for transmission / reception of UL / DL communications by the UE (including interleaved resources and resources subject to frequency hopping), managing frequency hopping at the base station side, properly configuring slots / symbols (e.g., for UL, DL, or SBFD communications), configuring one or more bandwidth portions for the UE 3, providing related configuration signaling to the UE 3, etc. The communication control module 630 may be configured to control communications according to any of the methods described above (e.g., sending multicast transmissions or receiving HARQ feedback from the UE 3).

[0270] Modifications and Substitutions As will be appreciated by those skilled in the art, several modifications and alternatives to the above-described embodiments are possible while having the benefit of the disclosure contained herein.

[0271] Although Figures 19 to 23 are described with reference to transport blocks, it will be understood that a transport block may also be referred to as a "data unit" and that the corresponding methods may also be applied to other suitable units of data transmission.

[0272] For example, for clarity, although specific terms for cellular communication generations (e.g., 2G, 3G, 4G, 5G, 6G, etc.) may be used to refer to particular communication entities, the technical features described for a particular entity are not limited to devices of that particular communication generation, and it will be understood that these technical features may be implemented in any functionally equivalent communication entity regardless of the terms used to refer to them.

[0273] In the above description, the UE and base station are described for ease of understanding as having several separate functional components or modules. While these modules may be provided in this manner in certain applications, such as when an existing system is modified to implement embodiments of the present disclosure, in other applications, such as systems designed from the beginning with the features of the present invention in mind, these modules may be incorporated into an overall operating system or code, and therefore may not be identifiable as separate entities.

[0274] In the above embodiments, several software modules have been described. As will be understood by those skilled in the art, these software modules may be provided in compiled or uncompiled form, and may be supplied as signals via a computer network or via a recording medium. Furthermore, the functions performed by some or all of these software modules may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred to facilitate updating the functions of the base station or UE.

[0275] Each controller may comprise any suitable form of processing circuitry, including, for example, but not limited to, one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuitry, internal memory / cache (program and / or data), processing registers, communication buses (e.g., control buses, data buses and / or address buses), direct memory access (DMA) functionality, hardware or software-implemented counters, pointers, and / or timers, etc. Various other modifications will be apparent to those skilled in the art and will not be described in further detail herein.

[0276] A base station may be configured as a "distributed" base station with a central unit "CU" and one or more individual distributed units (DUs).

[0277] User equipment (or "UE," "mobile station," "mobile device," or "wireless device") in this disclosure is an entity connected to a network via an air interface.

[0278] It should be noted that the present disclosure is not limited to dedicated communication devices, but may be applied to any device having the communication capabilities described below.

[0279] The terms "user equipment" or "UE" (as used in 3GPP), "mobile station," "mobile device," and "wireless device" are generally intended to be synonymous with each other and include standalone mobile stations such as terminals, cell phones, smartphones, tablets, cellular IoT devices, IoT devices, and machines. It will be understood that the terms "mobile station" and "mobile device" also include devices that remain fixed for extended periods of time.

[0280] The UE may be, for example, production or manufacturing equipment and / or energy-related machinery (e.g., equipment or machinery such as boilers, engines, turbines, solar panels, wind turbines, hydroelectric generators, thermal generators, nuclear generators, batteries, nuclear systems and / or related equipment, heavy electrical machinery, pumps including vacuum pumps, compressors, fans, blowers, hydraulic equipment, pneumatic equipment, metalworking machinery, manipulators, robots and / or application systems thereof, tools, dies, rolls, conveying equipment, lifting equipment, material handling equipment, textile machinery, sewing equipment, printing and / or related machinery, paper processing machinery, chemical machinery, mining and / or construction machinery and / or related equipment, agricultural, forestry and / or fishing machinery and / or implements, safety and / or environmental protection equipment, tractors, precision bearings, chains, gears, power transmission equipment, lubrication equipment, valves, pipe fittings, and / or application systems of any of the foregoing equipment or machinery, etc.).

[0281] The UE may be, for example, a transportation device (such as a railcar, automobile, motorcycle, bicycle, train, bus, cart, rickshaw, ship or other water vehicle, aircraft, rocket, satellite, drone, balloon, etc.), or may be, for example, an information and communications device (such as an electronic computer and related devices, communication and related devices, electronic components, etc.).

[0282] The UE may be, for example, refrigeration machines, refrigeration machine applications, commercial and / or service industry equipment, vending machines, automated service machines, office machines or equipment, consumer electronic devices and appliances (e.g., audio equipment, video equipment, loudspeakers, radios, televisions, microwave ovens, rice cookers, coffee makers, dishwashers, washing machines, dryers, electronic fans or related equipment, vacuum cleaners, etc.).

[0283] The UE may be, for example, an electrical application system or device (such as an x-ray system, a particle accelerator, a radioisotope device, a sonic device, an electromagnetic application device, an electronic power application device, etc.).

[0284] The UE may be, for example, an electronic lamp, lighting fixture, measuring, analytical, testing, or surveying or sensing equipment (e.g., smoke detectors, motion sensors, radio frequency tags, etc.), a watch or clock, laboratory equipment, optical equipment, medical equipment and / or systems, weapons, tableware, hand tools, etc.

[0285] The UE may be, for example, a personal digital assistant or related device with wireless capabilities (such as a wireless card or module designed to be attached to or inserted into another electronic device (e.g., a personal computer, electrical measurement equipment)).

[0286] The UE may be a device or part of a system that uses various wired and / or wireless communication technologies to provide the applications, services, and solutions described below in relation to the "internet of things (IoT)."

[0287] Internet of Things devices (or "things") are equipped with appropriate electronics, software, sensors, network connectivity, etc., and are able to collect and exchange data among themselves and with other communicating devices. IoT devices may comprise automated machinery that follows software instructions stored in internal memory. IoT devices may operate without the need for human supervision or operation. IoT devices may also remain stationary or inactive for long periods of time. IoT devices may be implemented as part of (typically) stationary equipment. IoT devices may be integrated into non-stationary equipment (e.g., vehicles) or attached to animals or people being monitored / tracked.

[0288] It will be appreciated that IoT technology can be implemented in any communication device that can connect to a communication network and send / receive data, regardless of whether such communication device is controlled by human input or software instructions stored in memory. It will be appreciated that IoT devices are also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) devices. It will be appreciated that a UE can support one or more IoT or MTC applications. Some examples of MTC applications are shown in the table below. This list is not exhaustive and is intended to illustrate some examples of machine-type communication applications. [Table 2]

[0289] The applications, services, and solutions may be Mobile Virtual Network Operator (MVNO) services, emergency wireless communication systems, Private Branch eXchange (PBX) systems, PHS / digital cordless telephone systems, Point of sale (POS) systems, advertise calling systems, Multimedia Broadcast and Multicast Service (MBMS), Vehicle to Everything (V2X) systems, train radio systems, location-related services, disaster / emergency wireless communication services, community services, video streaming services, femtocell application services, Voice over LTE (VoLTE) services, billing services, wireless on-demand services, roaming services, activity monitoring services, carrier / network selection services, function restriction services, Proof of Concept (PoC) services, personal information management services, ad hoc networks / Delay Tolerant Networking (DTN) services, and the like.

[0290] Furthermore, the above-mentioned UE categories are merely examples of application of the technical ideas and embodiments described in this specification. Of course, these technical ideas and embodiments are not limited to the above-mentioned UEs, and various modifications are possible.

[0291] Many other variations will be apparent to those skilled in the art and will not be described in further detail here.

[0292] For example, all or part of the embodiments disclosed above can be described as follows, but are not limited to these. (Appendix 1) 1. A method for a user equipment (UE), comprising: receiving multicast data from an access network node using a repeated request process when the UE is in a Radio Resource Control (RRC) connected state; Transitioning to an RRC inactive state; receiving the multicast data from the access network node when the UE is in the RRC inactive state; Including, the UE receives the multicast data using the same repeat request process as used to receive the multicast data in the RRC connected state when the UE is in the RRC inactive state; method. (Appendix 2) The UE maintains the received data of the multicast in a buffer associated with the repeat request process during a transition from the RRC connected state to the RRC inactive state. The method described in Appendix 1. (Appendix 3) receiving downlink control information for receiving the multicast data from the access network node, the downlink control information including a repeat request setting for the repeat request process; 3. The method according to claim 1 or 2. (Appendix 4) the repeat request process is a hybrid automatic repeat request (HARQ) process; 4. The method of any one of appendices 1 to 3. (Appendix 5) The UE uses the repeated request process for receiving the multicast data but does not request retransmission when the UE is in an RRC inactive state. 5. The method of any one of appendices 1 to 4. (Appendix 6) The UE receives the multicast data using a single repeated request process when the UE is in the RRC connected state and when the UE is in the RRC inactive state. 6. The method of any one of appendices 1 to 5. (Appendix 7) When the UE is in the RRC inactive state, the UE attempts to decode each data unit received using the repeated request process, regardless of whether the data unit is retransmitted data or newly transmitted data; and The UE determines whether the data unit is retransmitted data or newly transmitted data after the data unit is decoded at the UE; The method described in Appendix 6. (Appendix 8) receiving, from the access network node, schedule information for requesting retransmission of the multicast data for multiple repeated request processes when the UE is in a radio resource control (RRC) connected state; receiving the multicast data from the access network node when the UE is in the RRC connected state includes receiving the multicast data using the multiple repeated request processes; When the UE transitions from the RRC connected state to the RRC inactive state, the UE receives the multicast data using the same multiple repeated request processes as those used to receive the multicast data in the RRC connected state. 6. The method of any one of appendices 1 to 5. (Appendix 9) the scheduling information includes at least one of an indication of an identification of a repeat request process among the plurality of repeat request processes, and an indication of whether data transmitted to the UE using a repeat request process among the plurality of repeat request processes is newly transmitted data or retransmitted data. The method described in Appendix 8. (Appendix 10) and decoding the retransmission data of the multicast received from the access network node using one of the plurality of repeat request processes when in the RRC inactive state, if the same data has not yet been decoded by the UE. 10. The method according to claim 8 or 9. (Appendix 11) and further including not decoding the retransmission data of the multicast received using one of the plurality of repeat request processes when in the RRC inactive state, if the UE determines that the multicast data has already been decoded. 11. The method of any one of appendices 8 to 10. (Appendix 12) 1. A method for a user equipment (UE), comprising: receiving multicast first data from an access network node using a first repeated request process when the UE is in a radio resource control (RRC) connected state; Transitioning to an RRC inactive state; receiving the multicast second data from the access network node using a second repeated request process when the UE is in a radio resource control (RRC) connected state; Including, receiving the multicast first data using the first repeated request process and a first set of at least one time resource and the second repeated request process and a second set of at least one time resource when the UE is in the RRC connected state; receiving the multicast second data using both the first repeated request process and the first set of at least one time resource and the second repeated request process and the second set of at least one time resource when the UE is in the RRC inactive state; the first set of at least one time resource is configured by the access network node to at least partially overlap with the second set of at least one time resource. method. (Appendix 13) 1. A method for a user equipment (UE), comprising: receiving multicast data from an access network node using a plurality of first repeated request processes when the UE is in a radio resource control (RRC) connected state; receiving an RRC release message from the access network node indicating that the UE will transition to an RRC inactive state, the RRC release message including multicast configuration information for a second repeated request process; releasing the plurality of first repeat request processes based on the multicast configuration information; receiving the multicast data from the access network node using the second repeated request process when the UE is in the RRC inactive state; A method comprising: (Appendix 14) receiving first downlink control information for receiving the multicast data using the plurality of first iterative request processes; receiving second downlink control information for receiving the multicast data using the second repeated request process; the format or type of the first downlink control information is different from the format or type of the second downlink control information; The method described in Appendix 13. (Appendix 15) The UE: a difference between the format or type of the first downlink control information and the format or type of the second downlink control information; and an indication in the multicast configuration information that a single repeated request process is used to receive the multicast data when the UE is in the RRC inactive state; determining to release the plurality of first repeat request processes based on at least one of: The method described in Appendix 14. (Appendix 16) 1. A method for a user equipment (UE), comprising: receiving multicast data from an access network node using a plurality of first repeated request processes when the UE is in a radio resource control (RRC) connected state; receiving, when the UE is in the RRC connected state, multicast configuration information for a second repeated request process for receiving the multicast data from the access network node; receiving the multicast data from the access network node using the plurality of first repeated request processes and using the second repeated request process when the UE is in the RRC connected state; receiving an RRC release message from the access network node indicating that the UE will transition to an RRC inactive state; transitioning to the RRC inactive state; receiving the multicast data from the access network node using the second repeated request process when the UE is in the RRC inactive state; A method comprising: (Appendix 17) receiving first downlink control information for receiving the multicast data using the plurality of first iterative request processes; receiving second downlink control information for receiving the multicast data using the second iterative request process; the format or type of the first downlink control information is different from the format or type of the second downlink control information; The method described in Appendix 16. (Appendix 18) 1. A method for a user equipment (UE), comprising: receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when the UE is in a radio resource control (RRC) connected state; Transitioning to an RRC inactive state; receiving the multicast data from the access network node using the MRB when the UE is in the RRC inactive state; Including, A radio link control (RLC) entity in the UE associated with the MRB when the UE is in the RRC connected state is maintained in the UE when the UE transitions to the RRC inactive state. method. (Appendix 19) At least one of a count value or a timer for the MRB stored in the UE when the UE is in the RRC connected state is maintained in the UE when the UE transitions to the RRC inactive state. 18. The method described in Appendix 18. (Appendix 20) before the UE transitions to the RRC inactive state, switching the RLC entity from a first mode for sending repeated request feedback to the access network node to a second mode in which the repeated request feedback is not sent to the access network node. 20. The method of claim 18 or 19. (Appendix 21) 1. A method for a user equipment (UE), comprising: receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when the UE is in a radio resource control (RRC) inactive state, wherein the UE receives the multicast data using a repeated request process; Transitioning to an RRC connected state; receiving the multicast data from the access network node using the MRB when the UE is in the RRC connected state, and receiving the multicast data using the MRB and the repeated request process when the UE is in the RRC inactive state; A method comprising: (Appendix 22) The multicast data stored in a buffer associated with the repeated request process when the UE is in the RRC inactive state is maintained in the buffer when the UE transitions to the RRC connected state. 22. The method described in Appendix 21. (Appendix 23) A radio link control (RLC) entity in the UE associated with the MRB when the UE is in the RRC inactive state is maintained in the UE when the UE transitions to the RRC inactive state. 23. The method according to claim 21 or 22. (Appendix 24) 1. A method for a user equipment (UE), comprising: receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when the UE is in a radio resource control (RRC) inactive state, wherein the UE receives the multicast data using a first repeated request process; Transitioning to an RRC connected state; When the UE is in the RRC connected state, using the MRB that was used to receive the multicast when the UE was in the RRC inactive state, receiving the multicast data from the access network node using the MRB using a plurality of second repeated request processes different from the first repeated request process; A method comprising: (Appendix 25) A radio link control (RLC) entity in the UE associated with the MRB when the UE is in the RRC inactive state is maintained in the UE when the UE transitions to the RRC inactive state. The method described in Appendix 24. (Appendix 26) 1. A method of an access network node, comprising: transmitting multicast data to a user equipment (UE) using a repeat request process when the UE is in a radio resource control (RRC) connected state; transmitting the multicast data to the UE using the same repeated request process when the UE is in a radio resource control (RRC) inactive state; A method comprising: (Appendix 27) 1. A method of an access network node, comprising: transmitting multicast data to a first user equipment (UE) using a first repeated request process and using a first set of at least one time resource when the first UE is in a radio resource control (RRC) connected state; transmitting the multicast data to a second UE using a second repeated request process and using a second set of at least one time resource when the second UE is in an RRC inactive state; Including, the first set of at least one time resource is configured by the access network node to at least partially overlap in time with the second set of at least one time resource. method. (Appendix 28) The first set of at least one time resource may be the same as the second set of at least one time resource. The method described in Appendix 27. (Appendix 29) receiving a retransmission request for multicast data from the first UE using a first repeat request process; retransmitting the multicast data using the first iterative request process and using a third set of at least one time resource, and not transmitting retransmissions of the multicast data using the second iterative request process and the third set of at least one time resource; 29. The method of claim 27 or 28, further comprising: (Appendix 30) 1. A method of an access network node, comprising: transmitting multicast data to a user equipment (UE) using a plurality of first repeated request processes when the UE is in a radio resource control (RRC) connected state; sending an RRC release message to the UE indicating that the UE will transition to an RRC inactive state, the RRC release message including multicast configuration information for a second repeat request process, the multicast configuration information indicating that the UE will release the first plurality of repeat request processes; transmitting the multicast data to the UE using the second repeated request process when the UE is in the RRC inactive state; A method comprising: (Appendix 31) 1. A method of an access network node, comprising: transmitting multicast data to a user equipment (UE) using a plurality of first repeated request processes when the UE is in a radio resource control (RRC) connected state; sending, to the UE, multicast configuration information for a second repeated request process for receiving the multicast data when the UE is in the RRC inactive state; and transmitting the multicast data to the UE using the plurality of first repeated request processes and using the second repeated request process when the UE is in the RRC connected state; sending an RRC release message to the UE indicating that the UE will transition to the RRC inactive state; transmitting the multicast data using the second repeated request process when the UE is in the RRC inactive state; A method comprising: (Appendix 32) means for receiving multicast data from an access network node using a repeated request process when a user equipment (UE) is in a radio resource control (RRC) connected state; means for transitioning to an RRC inactive state; Equipped with the receiving means is configured to receive the multicast data from the access network node when the UE is in the RRC inactive state; the UE is configured to receive the multicast data when the UE is in the RRC inactive state using the same repeat request process as used to receive the multicast data in the RRC connected state. UE. (Appendix 33) means for receiving multicast first data from an access network node using a first repeated request process when a user equipment (UE) is in a radio resource control (RRC) connected state; means for transitioning to an RRC inactive state; Equipped with the receiving means is configured to receive the multicast second data from the access network node using a second repeated request process when the UE is in a radio resource control (RRC) connected state; The receiving means includes: receiving the first data of the multicast using the first repeated request process and a first set of at least one time resource and the second repeated request process and a second set of at least one time resource when the UE is in the RRC connected state; receiving the second data of the multicast using both the first repeated request process and the first set of at least one time resource and the second repeated request process and the second set of at least one time resource when the UE is in the RRC inactive state; and configured to perform at least one of the first set of at least one time resource is configured by the access network node to at least partially overlap with the second set of at least one time resource. UE. (Appendix 34) means for receiving multicast data from an access network node using a plurality of first repeated request processes when a user equipment (UE) is in a radio resource control (RRC) connected state; means for receiving an RRC release message from the access network node indicating that the UE will transition to an RRC inactive state, the RRC release message including multicast configuration information for a second repeated request process; means for releasing the plurality of first repeat request processes based on the multicast setting information; Equipped with the receiving means is configured to receive the multicast data from the access network node using the second repeated request process when the UE is in the RRC inactive state. UE. (Appendix 35) A receiving means, receiving multicast data from an access network node using a plurality of first repeated request processes when the user equipment (UE) is in a radio resource control (RRC) connected state; receiving, from the access network node when the UE is in an RRC connected state, multicast configuration information for a second repeated request process for receiving the multicast data when the UE is in the RRC inactive state; receiving the multicast data from the access network node using the first repeat request processes and using the second repeat request process when the UE is in the RRC connected state; receiving an RRC release message from the access network node indicating that the UE will transition to the RRC inactive state; A receiving means configured as follows: means for transitioning to the RRC inactive state; Equipped with the receiving means is further configured to receive the multicast data from the access network node using the second repeated request process when the UE is in the RRC inactive state. UE. (Appendix 36) means for receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when the user equipment (UE) is in a radio resource control (RRC) connected state; means for transitioning to an RRC inactive state; Equipped with The receiving means is configured to receive the multicast data from the access network node using the MRB when the UE is in the RRC inactive state; The UE is configured to maintain a radio link control (RLC) entity associated with the MRB when the UE is in the RRC connected state, when the UE transitions to the RRC inactive state. UE. (Appendix 37) means for receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when a user equipment (UE) is in a radio resource control (RRC) inactive state, wherein the UE is configured to use a recursive request process to receive the multicast data; A means for transitioning to an RRC connected state; Equipped with The receiving means is configured to receive the multicast data using the MRB when the UE is in the RRC connected state, and using the MRB and the repeated request process when the UE is in the RRC inactive state. UE. (Appendix 38) means for receiving multicast data from an access network node using at least one multicast radio bearer (MRB) when a user equipment (UE) is in a radio resource control (RRC) inactive state, wherein the UE is configured to receive the multicast data using a first repeated request process; A means for transitioning to an RRC connected state; Equipped with the receiving means is configured to receive the multicast data from the access network node using the MRB when the UE is in the RRC connected state, and using the MRB that was used to receive the multicast when the UE was in the RRC inactive state, and using a plurality of second repeated request processes different from the first repeated request process. UE. (Appendix 39) means for transmitting multicast data to a user equipment (UE) using a repeated request process when the UE is in a radio resource control (RRC) connected state; the transmitting means is configured to transmit the multicast data to the UE using the same repeated request process when the UE is in a radio resource control (RRC) inactive state. Access network node. (Appendix 40) means for transmitting multicast data to a first user equipment (UE) using a first repeated request process and using a first set of at least one time resource when the UE is in a radio resource control (RRC) connected state; the transmitting means is configured to transmit the multicast data to the second UE using a second repeated request process and using a second set of at least one time resource when the second UE is in an RRC inactive state; the access network node further comprising means for configuring the first set of at least one time resource to at least partially overlap in time with the second set of at least one time resource. Access network node. (Appendix 41) A transmitting means, transmitting multicast data to a user equipment (UE) using a plurality of first repeated request processes when the UE is in a radio resource control (RRC) connected state; sending an RRC release message to the UE indicating that the UE will transition to an RRC inactive state, the RRC release message including multicast configuration information for a second repeat request process, the multicast configuration information indicating that the UE will release the plurality of first repeat request processes; transmitting the multicast data to the UE using the second repeated request process when the UE is in the RRC inactive state; a transmitting means configured to Access network node. (Appendix 42) A transmitting means, transmitting multicast data to a user equipment (UE) using a plurality of first repeated request processes when the UE is in a radio resource control (RRC) connected state; sending, to the UE, when the UE is in an RRC connected state, multicast configuration information for a second repeated request process for receiving the multicast data when the UE is in an RRC inactive state; When the UE is in the RRC connected state, transmitting the multicast data to the UE using the first repeat request processes and using the second repeat request process; sending an RRC release message to the UE indicating that the UE will transition to the RRC inactive state; transmitting the multicast data to the UE using the second repeated request process when the UE is in the RRC inactive state; a transmitting means configured to Access network node.

[0293] This application claims the benefit of priority from UK Patent Application No. 2301029.1 filed on January 14, 2023, the disclosure of which is incorporated herein by reference in its entirety. [Explanation of symbols]

[0294] 1. Communication Systems 3. User Equipment 5 base station 7 Core Network 9 cells Includes 10 Control Plane Functions 11 User Plane Function 50 DU 60 CU 310 Transceiver Circuit 330 Antenna 350 User Interface 370 Controller 390 memory 410 Operating System 430 Communication Control Module 510 Transceiver Circuit 530 Antenna 550 Core Network Interface 570 Controller 590 memory 610 Operating System 630 Communication Control Module

Claims

1. 1. A method performed by a user equipment (UE), comprising: maintaining service continuity for multicast reception with an access network node by using a multicast radio bearer (MRB) configured as a downlink (DL)-only Radio Link Control-Unacknowledge Mode (RLC-UM) entity for point-to-multipoint (PTM) transmissions during a transition between a Radio Resource Control (RRC) inactive state and an RRC connected state; method.

2. Maintaining said service continuity includes: maintaining the MRB configured as a DL-only RLC-UM entity for PTM transmission during the transition between the RRC inactive state and the RRC connected state; or switching the type of the MRB to a DL-only RLC-UM entity for PTM transmission before the transition between the RRC inactive state and the RRC connected state; at least one of The method of claim 1.

3. maintaining the service continuity is performed by switching the type of the MRB to a DL-only RLC-UM entity for PTM transmission before transitioning from the RRC connected state to the RRC inactive state; a point-to-point receive leg for the MRB is terminated before the transition from the RRC connected state to the RRC inactive state; The method of claim 2.

4. The switching of the type of the MRB includes: Multicast MRB with bidirectional RLC-UM configuration for point-to-point (PTP) transmission; Multicast MRB with RLC-Acknowledged Mode (RLC-AM) entity configuration for PTP transmission; A multicast MRB with two RLC-UM entities, one DL-only RLC-UM entity for PTP transmission and the other DL-only RLC-UM entity for PTM transmission; a multicast MRB with three RLC-UM entities: one DL RLC-UM entity for PTP transmission, one UL RLC-UM entity for PTP transmission, and one DL-only RLC-UM entity for PTM transmission; or Multicast MRB with two RLC entities, one RLC-AM entity for PTP transmission and one DL-only RLC-UM entity for PTM transmission; Executed by switching from at least one of The method according to claim 2 or 3.

5. During the transition between the RRC inactive state and the RRC connected state, a Protocol Data Convergence Protocol (PDCP) entity and an RLC entity in the UE corresponding to the MRB are maintained.

3. The method according to claim 1 or 2.

6. and further comprising using at least one repeat request process to receive multicast data during the RRC connected state, wherein the at least one repeat request process is used to receive multicast data during the RRC inactive state.

4. The method according to any one of claims 1 to 3.

7. the data of the multicast stored in a buffer corresponding to the at least one repeated request process before the transition between the RRC inactive state and the RRC connected state is maintained in the buffer during the transition between the RRC inactive state and the RRC connected state; The method of claim 6.

8. receiving control information for scheduling group common multicast transmission in the RRC inactive state and the RRC connected state; the control information does not include scheduling information for the at least one repeated request process; the at least one repeating request process is for a single process to receive a multicast transmission; 8. The method according to claim 6 or 7.

9. receiving control information for scheduling group common multicast transmission in the RRC inactive state and the RRC connected state; the control information includes scheduling information for the at least one repeated request process; the at least one repeat request process includes a plurality of processes for receiving multicast transmissions; The scheduling information is ignored during the RRC inactive state.

8. The method according to claim 6 or 7.

10. If a transport block is retransmitted in the repeated request process and the transport block was previously successfully decoded, the transport block is ignored.

10. The method of claim 9.

11. If a transport block is retransmitted in the repeated request process and the transport block was not previously successfully decoded, the transport block is used to combine with the previously received transport block.

10. The method of claim 9.

12. receiving control information for scheduling group common multicast transmission in the RRC inactive state and the RRC connected state; the control information includes scheduling information for the at least one repeated request process; the at least one repeat request process includes a plurality of processes for receiving multicast transmissions; one of the plurality of processes is used during the RRC inactive process; 8. The method according to claim 6 or 7.

13. If a transport block is transmitted during the RRC inactive state and the transport block is successfully decoded, the transport block is passed to a Media Access Control (MAC) layer. The method of claim 12.

14. using at least one first repeated request process to receive multicast data during the RRC inactive state; and using at least one second repeated request process to receive multicast data during the RRC connected state; the at least one second iterative request process is different from the at least one first iterative request process; 4. The method according to any one of claims 1 to 3.

15. the at least one first repeated request process is released upon the transition between the RRC inactive state and the RRC connected state; the multicast data stored in a buffer corresponding to the at least one first repeated request process before the transition between the RRC inactive state and the RRC connected state is flushed upon the transition between the RRC inactive state and the RRC connected state.

15. The method of claim 14.

16. receiving first control information for scheduling group common multicast transmission in the RRC inactive state; receiving second control information for scheduling group common multicast transmission in the RRC connected state; the transport block is transmitted in a redundant manner by the group common transmission corresponding to the first control information and the group common transmission corresponding to the second control information.

15. The method of claim 14.

17. the transmission of the transport block by the group common transmission corresponding to the first control information and the transmission of the transport block by the group common transmission corresponding to the second control information are synchronized with each other.

17. The method of claim 16.

18. The transport blocks transmitted by the group common transmission corresponding to the first control information and the group common transmission corresponding to the second control information are processed by different RLC entities in the UE.

17. The method of claim 16.

19. at least one of the first control information and the second control information is set before the transition between the RRC inactive state and the RRC connected state; 19. The method of any one of claims 14 to 18.

20. and further comprising: before the transition between the RRC inactive state and the RRC connected state, switching multicast reception between the group common transmission corresponding to the first control information and the group common transmission corresponding to the second control information.

19. The method of any one of claims 16 to 18.

21. The transition between the RRC inactive state and the RRC connected state causes transport blocks that are not successfully decoded to be discarded or removed from the buffer.

21. The method of any one of claims 1 to 20.

22. the at least one repeat request process comprises a hybrid automatic repeat request (HARQ) process. The method of claim 4.

23. The transition between the RRC inactive state and the RRC connected state comprises: A transition from the RRC inactive state to the RRC connected state, or a transition from the RRC connected state to the RRC inactive state; at least one of 23. The method of any one of claims 1 to 22.

24. 1. A method of an access network node, comprising: maintaining service continuity for multicast reception with a user equipment (UE) by using a multicast radio bearer (MRB) configured as a downlink (DL)-only Radio Link Control-Unacknowledge Mode (RLC-UM) entity for point-to-multipoint (PTM) transmission while the UE is in transition between a Radio Resource Control (RRC) inactive state and an RRC connected state; method.

25. means for maintaining service continuity for multicast reception with an access network node by using a multicast radio bearer (MRB) configured as a downlink (DL)-only Radio Link Control-Unacknowledge Mode (RLC-UM) entity for point-to-multipoint (PTM) transmission during transition between a Radio Resource Control (RRC) inactive state and an RRC connected state; User equipment (UE).

26. means for maintaining service continuity for multicast reception with a user equipment (UE) by using a multicast radio bearer (MRB) configured as a downlink (DL)-only Radio Link Control-Unacknowledge Mode (RLC-UM) entity for point-to-multipoint (PTM) transmission while the UE is in transition between a Radio Resource Control (RRC) inactive state and an RRC connected state; Access network node.

Images