Method, user equipment and access network node

Abstract

The present disclosure relates to a method of a user equipment, UE, the method comprising: receiving multicast data from an access network node using repetition request processing when the UE is in a radio resource control, RRC, connected state; switching to an RRC inactive state; and receiving multicast from the access network node when the UE is in the RRC inactive state; wherein, when the UE is in the RRC inactive state, the UE receives multicast data using the same repetition request process as the repetition request process for receiving multicast in the RRC connected state.

Description

Technical Field

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

[0002] The present disclosure has particular, but not exclusive, relevance to wireless communication systems and apparatus thereof operating in accordance with 3rd Generation Partnership Project (3GPP) standards or their equivalents or derivatives, including LTE-Advanced, next-generation or 5G networks, and future generations and beyond. The present disclosure has particular, but not exclusive, relevance to improvements related to multicast and broadcast (MBS) services.

[0003] The latest developments in 3GPP standards are known as 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), often referred to as '4G'. Furthermore, the terms '5G' and 'New Radio' (NR) refer to evolved communication technologies that are expected to support a wide range of applications and services. Details of 5G networks are described, for example, in the Next Generation Mobile Networks (NGMN) Alliance's 'NGMN 5G White Paper' (V1.0), which is available at https: / / www.ngmn.org / 5g-white-paper.html. 3GPP aims to support 5G through the so-called 3GPP Next Generation (NextGen) Radio Access Network (RAN) and 3GPP NextGen Core Network.

[0004] Under the 3GPP standard, 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 the core network and communicate with other communication devices or remote servers. For simplicity, this application will use the term RAN node or base station to refer to any such access node. Summary of the Invention

[0005] Problems to be solved by the invention

[0006] Multicast and Broadcast Services (MBS) enable resource-efficient delivery of transmissions to groups of user equipment (UEs). For example, multicast communications to a group of UEs typically require less total bandwidth than a collection of corresponding individual unicast (one-to-one) communications. Multicast transmissions to UEs in a radio resource control (RRC) connected state can provide higher quality of service (QoS) levels, improved reliability, and better continuity than provided using broadcast. MBS can be used for, for example, public safety and mission-critical applications, vehicle-to-everything (V2X) applications, or video delivery to a group of UEs. However, improved MBS methods and procedures are needed to provide improved reliability and resource efficiency. In addition, for some MBS, there may be service continuity requirements. For example, when MBS is used for public safety applications, it is important that the continuity of the MBS can be maintained even when the UE transitions from an RRC connected state to an RRC inactive state (e.g., as may occur due to high RRC load).

[0007] More generally, there is a need for improved mechanisms and procedures for MBS. These mechanisms and procedures include, but are not limited to, procedures for maintaining MBS continuity when a UE transitions between an RRC connected state and an RRC inactive state.

[0008] Solutions for solving problems

[0009] The present disclosure is directed to providing devices and methods that at least partially address the above-mentioned needs and / or problems.

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

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

[0012] The method may further include receiving downlink control information for receiving the multicast data from the access network node, wherein the downlink control information includes a repeat request configuration for a repeat request process.

[0013] The repeat request process may be a hybrid automatic repeat request process, ie, a HARQ process.

[0014] When the UE is in the RRC inactive state, the UE may use a repeat request process to receive multicast data but may not request retransmission.

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

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

[0017] The method may also include: when the UE is in a radio resource control connection state, i.e., an RRC connected state, receiving scheduling information for requesting retransmission of multicast data from an access network node for multiple repeat request processes; wherein, when the UE is in the RRC connected state, receiving multicast data from the access network node includes: receiving the multicast data using multiple repeat request processes; and wherein, when the UE has transitioned from the RRC connected state to the RRC inactive state, the UE receives the multicast data using the same multiple repeat request processes as the multiple repeat request processes used to receive the multicast data in the RRC connected state.

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

[0019] The method may further include decoding retransmitted multicast data received from the access network node using one of the multiple repeat request processes while in the RRC inactive state if the same data has not been decoded at the UE.

[0020] The method may further include not decoding retransmitted multicast data received using one of the multiple repeat request processes while in the RRC inactive state if the UE determines that the multicast data has been decoded at the UE.

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

[0022] In a third aspect, the present disclosure provides a method for a user equipment (UE), comprising: when the UE is in a radio resource control connection state (RRC connection state), using multiple first repeated request processes to receive multicast data from an access network node; receiving an RRC release message from the access network node indicating that the UE is to transition to an RRC inactive state, wherein the RRC release message includes multicast configuration information for a second repeated request process; based on the multicast configuration information, releasing the multiple first repeated request processes; and when the UE is in the RRC inactive state, using the second repeated request process to receive multicast data from the access network node.

[0023] The method may also include: receiving first downlink control information for receiving multicast data using multiple first repeated request processes; and receiving second downlink control information for receiving multicast data using second repeated request processes; wherein the format or type of the first downlink control information is different from the format or type of the second downlink control information.

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

[0025] In a fourth aspect, the present disclosure provides a method for user equipment, i.e., UE, comprising: when the UE is in a radio resource control connection state, i.e., an RRC connection state, receiving multicast data from an access network node using multiple first repetition request processing; when the UE is in the RRC connection state, receiving multicast configuration information for a second repetition request processing for receiving multicast data when the UE is in an RRC inactive state from the access network node; when the UE is in the RRC connection state, receiving multicast data from the access network node using multiple first repetition request processing and using a second repetition request processing; receiving an RRC release message from the access network node indicating that the UE is to transition to an RRC inactive state; transitioning to the RRC inactive state; and when the UE is in the RRC inactive state, receiving multicast data from the access network node using the second repetition request processing.

[0026] The method may also include: receiving first downlink control information for receiving multicast data using multiple first repeated request processes; and receiving second downlink control information for receiving multicast data using second repeated request processes; wherein the format or type of the first downlink control information is different from the format or type of the second downlink control information.

[0027] In a fifth aspect, the present disclosure provides a method for a user equipment, i.e., a UE, comprising: when the UE is in a radio resource control connection state, i.e., an RRC connection state, using at least one multicast radio bearer, i.e., at least one MRB, to receive multicast data from an access network node; transitioning to an RRC inactive state; when the UE is in an RRC inactive state, using an MRB to receive multicast data from an access network node; wherein, when the UE is in an RRC connection state, a radio link control entity, i.e., an RLC entity, associated with the MRB at the UE is maintained at the UE when the UE transitions to the RRC inactive state.

[0028] At least one of the count value and the timer of the MRB stored at the UE when the UE is in the RRC connected state may be maintained at the UE when the UE transitions to the RRC inactive state.

[0029] The method may include, before the UE transitions to the RRC inactive state, switching the RLC entity from a first mode for transmitting repeat request feedback to the access network node to a second mode for not transmitting repeat request feedback to the access network node.

[0030] In a sixth aspect, the present disclosure provides a method for a user equipment, i.e., a UE, comprising: when the UE is in a radio resource control inactive state, i.e., an RRC inactive state, using at least one multicast radio bearer, i.e., at least one MRB, to receive multicast data from an access network node, wherein the UE uses a repeat request process to receive the multicast data; converting to an RRC connected state; and when the UE is in the RRC connected state, using the MRB and using the MRB and repeat request process used to receive multicast data when the UE is in the RRC inactive state to receive multicast data from the access network node.

[0031] Multicast data stored in a buffer associated with the repeat 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.

[0032] When the UE is in the RRC inactive state, a radio link control entity at the UE associated with an MRB, ie, an RLC entity, may be maintained at the UE when the UE transitions to the RRC inactive state.

[0033] In a seventh aspect, the present disclosure provides a method for a user equipment, i.e., a UE, comprising: when the UE is in a radio resource control inactive state, i.e., an RRC inactive state, using at least one multicast radio bearer, i.e., at least one MRB, to receive multicast data from an access network node, wherein the UE uses a first repeated request process to receive the multicast data; converting to an RRC connected state; and when the UE is in the RRC connected state, using the MRB, using the MRB used for receiving multicast when the UE is in the RRC inactive state and using multiple second repeated request processes different from the first repeated request process to receive multicast data from the access network node.

[0034] When the UE is in the RRC inactive state, a radio link control entity at the UE associated with an MRB, ie, an RLC entity, may be maintained at the UE when the UE transitions to the RRC inactive state.

[0035] In an eighth aspect, the present disclosure provides a method for accessing a network node, the method comprising: transmitting multicast data to a user equipment (i.e., UE) using repeated request processing when the UE is in a radio resource control connected state, i.e., an RRC connected state; and transmitting multicast data to the UE using the same repeated request processing when the UE is in a radio resource control inactive state, i.e., an RRC inactive state.

[0036] In a ninth aspect, the present disclosure provides a method for accessing a network node, the method comprising: when a first UE is in a radio resource control connection state, i.e., an RRC connection state, using a first repetition request process and using a first at least one time resource set to transmit multicast data to a first user equipment, i.e., the first UE; and when a second UE is in an RRC inactive state, using a second repetition request process and using a second at least one time resource set to transmit multicast data to a second UE; wherein the first at least one time resource set is configured by the access network node to at least partially overlap in time with the second at least one time resource set.

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

[0038] The method may also include: receiving a request for retransmission of multicast data from the first UE using a first repetition request process; and retransmitting the multicast data using the first repetition request process and using at least one third time resource set, and not using the second repetition request process and at least one third time resource set to transmit the retransmission of the multicast data.

[0039] In a tenth aspect, the present disclosure provides a method for accessing a network node, the method comprising: when the UE is in a radio resource control connection state, i.e., an RRC connection state, transmitting multicast data to a user equipment, i.e., the UE, using multiple first repeated request processes; transmitting an RRC release message to the UE indicating that the UE is to transition to an RRC inactive state, wherein the RRC release message includes multicast configuration information for a second repeated request process, wherein the multicast configuration information indicates that the UE is to release the multiple first repeated request processes; and when the UE is in the RRC inactive state, transmitting multicast data to the UE using the second repeated request process.

[0040] In an eleventh aspect, the present disclosure provides a method for accessing a network node, the method comprising: when the UE is in a radio resource control connection state, i.e., an RRC connection state, transmitting multicast data to a user equipment, i.e., the UE, using multiple first repetition request processes; when the UE is in an RRC connection state, transmitting to the UE multicast configuration information for a second repetition request process for receiving multicast data when the UE is in an RRC inactive state; when the UE is in an RRC connection state, transmitting multicast data to the UE using multiple first repetition request processes and using a second repetition request process; transmitting to the UE an RRC release message indicating that the UE is to transition to an RRC inactive state; and when the UE is in an RRC inactive state, transmitting multicast data to the UE using the second repetition request process.

[0041] In a twelfth aspect, the present disclosure provides a user equipment, i.e., UE, comprising: a component for receiving multicast data from an access network node using repeated request processing when the UE is in a radio resource control connected state, i.e., an RRC connected state; and a component for transitioning to an RRC inactive state; wherein the component for receiving is configured to receive multicast data from the access network node when the UE is in the RRC inactive state; and wherein the UE is configured to receive multicast data when the UE is in the RRC inactive state using the same repeated request processing as that used for receiving multicast data in the RRC connected state.

[0042] In a thirteenth aspect, the present disclosure provides a user equipment, i.e., UE, comprising: a component for receiving first multicast data from an access network node using a first repetition request processing when the UE is in a radio resource control connection state, i.e., an RRC connection state; and a component for switching to an RRC inactive state; wherein the component for receiving is configured to receive second multicast data from the access network node using a second repetition request processing when the UE is in a radio resource control connection state, i.e., an RRC connection state; and wherein the component for receiving is configured for at least one of the following: when the UE is in the RRC connection state, receiving the first multicast data using the first repetition request processing and the first at least one time resource set and the second repetition request processing and the second at least one time resource set; and when the UE is in the RRC inactive state, receiving the second multicast data using the first repetition request processing and the first at least one time resource set and the second repetition request processing and the second at least one time resource set; wherein the first at least one time resource set is configured by the access network node to at least partially overlap with the second at least one time resource set.

[0043] In a fourteenth aspect, the present disclosure provides a user equipment, i.e., UE, comprising: a component for receiving multicast data from an access network node using multiple first repeated request processing when the UE is in a radio resource control connected state, i.e., an RRC connected state, and a component for receiving an RRC release message from the access network node indicating that the UE is to transition to an RRC inactive state, wherein the RRC release message includes multicast configuration information for a second repeated request processing; and a component for releasing the multiple first repeated request processing based on the multicast configuration information; wherein the component for receiving is configured to: receive multicast data from the access network node using the second repeated request processing when the UE is in the RRC inactive state.

[0044] In a fifteenth aspect, the present disclosure provides a user equipment, i.e., UE, comprising: a component for receiving, which is configured to: when the UE is in a radio resource control connection state, i.e., an RRC connection state, receive multicast data from an access network node using multiple first repetition request processing; when the UE is in the RRC connection state, receive multicast configuration information for a second repetition request processing for receiving multicast data when the UE is in an RRC inactive state from the access network node; when the UE is in the RRC connection state, receive multicast data from the access network node using multiple first repetition request processing and using a second repetition request processing; and receive an RRC release message from the access network node indicating that the UE is to transition to an RRC inactive state; and a component for transitioning to the RRC inactive state; wherein the component for receiving is further configured to: when the UE is in the RRC inactive state, receive multicast data from the access network node using the second repetition request processing.

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

[0046] In the seventeenth aspect, the present disclosure provides a user equipment, i.e., UE, comprising: a component for receiving multicast data from an access network node using at least one multicast radio bearer, i.e., at least one MRB, when the UE is in a radio resource control inactive state, i.e., an RRC inactive state, wherein the UE is configured to receive multicast data using repeated request processing; and a component for transitioning to an RRC connected state; wherein the component for receiving is configured to: when the UE is in the RRC connected state, use the MRB and use the MRB and repeated request processing used for receiving multicast data when the UE is in the RRC inactive state to receive multicast data from the access network node.

[0047] In the eighteenth aspect, the present disclosure provides a user equipment, i.e., UE, comprising: a component for receiving multicast data from an access network node using at least one multicast radio bearer, i.e., at least one MRB, when the UE is in a radio resource control inactive state, i.e., an RRC inactive state, wherein the UE is configured to use a first repeated request process to receive multicast data; and a component for transitioning to an RRC connected state; wherein the component for receiving is configured to: use the MRB when the UE is in the RRC connected state, use the MRB for receiving multicast when the UE is in the RRC inactive state, and use multiple second repeated request processes different from the first repeated request process to receive multicast data from the access network node.

[0048] In the nineteenth aspect, the present disclosure provides an access network node, comprising: a component for transmitting multicast data to a user equipment, i.e., a UE, using repeated request processing when the UE is in a radio resource control connected state, i.e., an RRC connected state; wherein the component for transmitting is configured to: transmit multicast data to the UE using the same repeated request processing when the UE is in a radio resource control inactive state, i.e., an RRC inactive state.

[0049] The method may further include transmitting downlink control information for receiving the multicast data to the UE, wherein the downlink control information includes a repeat request configuration for a repeat request process.

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

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

[0052] The method may also include: transmitting scheduling information to the UE for multiple repeat request processes, for the UE to use in requesting retransmission of downlink multicast data when the UE is in a radio resource control connection state, i.e., an RRC connection state; wherein, transmitting multicast data to the UE when the UE is in the RRC connection state includes: transmitting the multicast data using multiple repeat request processes; and wherein, transmitting multicast data to the UE when the UE is in an RRC inactive state includes transmitting the multicast data to the UE using the same multiple repeat request processes.

[0053] In aspect 20, the present disclosure provides an access network node, comprising: a component for transmitting multicast data to a first user equipment, i.e., a first UE, using a first repetition request process and using a first at least one time resource set when the first UE is in a radio resource control connection state, i.e., an RRC connection state; wherein the component for transmitting is configured to: when the second UE is in an RRC inactive state, use a second repetition request process and use a second at least one time resource set to transmit multicast data to the second UE; and wherein the access network node also includes: a component for configuring the first at least one time resource set to at least partially overlap in time with the second at least one time resource set.

[0054] In aspect 21, the present disclosure provides an access network node, comprising: a component for transmitting, which is configured to: transmit multicast data to a user equipment, i.e., a UE, using multiple first repeated request processing when the UE is in a radio resource control connected state, i.e., an RRC connected state; transmit an RRC release message to the UE indicating that the UE is to transition to an RRC inactive state, wherein the RRC release message includes multicast configuration information for a second repeated request processing, wherein the multicast configuration information indicates that the UE is to release the multiple first repeated request processing; and transmit multicast data to the UE using the second repeated request processing when the UE is in the RRC inactive state.

[0055] In aspect 22, the present disclosure provides an access network node, comprising: a component for transmitting, which is configured to: when the UE is in a radio resource control connection state, i.e., an RRC connection state, transmit multicast data to a user equipment, i.e., a UE, using multiple first repetition request processing; when the UE is in the RRC connection state, transmit to the UE multicast configuration information for a second repetition request processing for receiving multicast data when the UE is in an RRC inactive state; when the UE is in the RRC connection state, transmit multicast data to the UE using multiple first repetition request processing and using a second repetition request processing; transmit to the UE an RRC release message indicating that the UE is to transition to an RRC inactive state; and when the UE is in the RRC inactive state, transmit multicast data to the UE using the second repetition request processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Example embodiments of the present disclosure will now be described by way of example with reference to the accompanying drawings, in which:

[0057] Figure 1 A mobile ('cellular' or 'wireless') communication system is schematically shown;

[0058] Figure 2 Shows that it can be Figure 1 Typical frame structures used in communication systems;

[0059] Figure 3 A diagram showing point-to-point (PTP) and point-to-multipoint (PTM) communications;

[0060] Figure 4 A flow chart illustrating a method for a UE to continue receiving multicast transmissions in an RRC inactive state is shown;

[0061] Figure 5 An example of information for maintaining a PTM leg at a UE is shown;

[0062] Figure 6 A flow chart illustrating a method for a UE to continue receiving multicast transmissions in an RRC connected state is shown;

[0063] Figure 7 A method of transmitting an MBS Radio Bearer (MRB) list to a UE is shown;

[0064] Figure 8 A first example of an RLC configuration is shown;

[0065] Figure 9 A second example of an RLC configuration is shown;

[0066] Figure 10 It shows a method for a UE to enter an RRC connected state and receive an MRB configuration;

[0067] Figure 11 A further method for the UE to enter the RRC connected state is shown;

[0068] Figure 12 The first part of the method of establishing and joining a multicast session is shown;

[0069] Figure 13 The second part of the method of establishing and joining a multicast session is shown;

[0070] Figure 14 The third part of the method of establishing and joining a multicast session is shown;

[0071] Figure 15 The first part of the method of MBS session activation and deactivation is shown;

[0072] Figure 16 The second part of the method of MBS session activation and deactivation is shown;

[0073] Figure 17 A method is shown in which the UE does not enter the RRC connected state if PTM configuration is available at the UE;

[0074] Figure 18A flow chart illustrating a method in which a UE receives downlink control information (DCI) from a base station is shown;

[0075] Figure 19 An example of HARQ processing for RRC-inactive UEs and RRC-connected UEs is shown;

[0076] Figure 20 A flow chart illustrating a method for a UE to receive a multicast transmission after transitioning to an RRC inactive state is shown;

[0077] Figure 21 An example of HARQ processing for a UE transitioning from an RRC connected state to an RRC inactive state is shown;

[0078] Figure 22 A flow chart illustrating a method in which a UE receives a configuration for a multicast radio bearer (MRB) before transitioning to an RRC inactive state is shown;

[0079] Figure 23 A further example of HARQ processing for a UE transitioning from an RRC connected state to an RRC inactive state is shown;

[0080] Figure 24 is a schematic block diagram showing the main components of a UE 3; and

[0081] Figure 25 A schematic block diagram illustrating the main components of a base station is shown. DETAILED DESCRIPTION

[0082] Overview

[0083] For now, we will refer to it only by way of example Figure 1 and Figure 2 An exemplary communication system is described below.

[0084] Figure 1 There is schematically shown a mobile ('cellular' or 'wireless') communication system 1 to which example embodiments of the present disclosure are applicable.

[0085] In a communication system 1, user equipment (UE) 3-1, 3-2, 3-3 (e.g., mobile phones and / or other mobile devices) can communicate with each other via a radio access network (RAN) node 5 operating according to one or more compatible radio access technologies (RATs). In the example shown, the RAN node 5 includes an NR / 5G base station or 'gNB' 5 operating one or more associated cells 9. Communications via the base station 5 are typically routed through a core network 7 (e.g., a 5G core network or an evolved packet core network (EPC)).

[0086] As will be appreciated by those skilled in the art, although for illustrative purposes only Figure 1 Three UEs 3 and one base station 5 are shown in FIG, but the system will typically include other base stations 5 and UEs 3 when implemented.

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

[0088] The UE 3 and its serving base station 5 are connected via a suitable air interface, such as the so-called 'Uu' interface etc. Neighbouring base stations 5 may be connected to each other via a suitable base station to base station interface, such as the so-called 'X2' interface, 'Xn' interface and / or similar.

[0089] The core network 7 includes a plurality of 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 (UPFs) 11. The CPF 10 includes one or more access and mobility management functions (AMFs) 10-1, one or more session management functions (SMFs) 10-2, and a plurality of other functions 10-n.

[0090] The base station 5 is connected to the core network node via appropriate interfaces (or 'reference points'), such as the N2 reference point for communication of control signaling between the base station 5 and the AMF 10-1 and the N3 reference point for communication of user data between the base station 5 and each UPF 11. The UEs 3 are each connected to the AMF 10-1 via a logical non-access stratum (NAS) connection over the N1 reference point (similar to the S1 reference point in LTE). It should be understood that N1 communications are transparently routed via the base station 5.

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

[0092] The AMF 10-1 performs mobility management-related functions, maintains NAS signaling connections with each UE 3, and manages UE registration. The AMF 10-1 is also responsible for managing paging. The SMF 10-2 provides session management functionality (forming part of the MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 also allocates an IP address to each UE 3.

[0093] The base station 5 (which may also be referred to as the 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 an unpaired spectrum. It should be understood that the base station 5 may also operate at least one cell 9 on an associated FDD carrier operating in a paired spectrum.

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

[0095] Physical channels may include, for example, the Physical Downlink Shared Channel (PDSCH), the Physical Broadcast Channel (PBCH), and the Physical Downlink Control Channel (PDCCH). The PDSCH carries data that shares the capacity of the PDSCH on a time and frequency basis. The PDSCH can carry various data items, including, for example, user data, UE-specific higher-layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) to support multiple functions, including, for example, scheduling downlink transmissions on the PDSCH and uplink data transmission on the Physical Uplink Shared Channel (PUSCH). The PBCH provides the Master Information Block (MIB) to the UE 3. It also supports time and frequency synchronization in conjunction with the PDCCH, which facilitates cell acquisition, selection, and reselection. The UE 3 can receive synchronization signal blocks (SSBs), and the UE 3 can assume that the reception timings of the PBCH, primary synchronization signal (PSS), and secondary synchronization signal (SSS) are in consecutive symbols and form SS / PBCH blocks. The base station 5 can transmit multiple synchronization signal (SS) blocks corresponding to different DL beams. The total number of SS blocks can be limited to a duration of, for example, 5 milliseconds, as one SS burst. The periodicity of SSB transmission can be indicated to the UE using any suitable signaling (e.g., using ssb-periodicityServingCell for each serving cell). The periodicity value of the SSB can be, for example, greater than or equal to 20 ms. For initial cell selection, the UE 3 can be configured to assume that the SS burst occurs with a periodicity of 2 frames. An indication of which SSBs to transmit within the 5 ms duration can also be provided to the UE 3 (e.g., using ssb-PositionsInBurst).

[0096] DL physical signals may include, for example, reference signals (RS) and synchronization signals (SS). Reference signals (sometimes referred to as pilot signals) are signals with predefined special waveforms known to both UE 3 and 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).

[0097] Similarly, the UE 3 is configured to transmit control information and user data via multiple uplink (UL) physical channels corresponding to REs carrying information originating from higher layers, and to transmit UL physical signals used in the physical layer and corresponding to REs that do not carry information originating from higher layers, and the base station 5 is configured to receive control information and user data via multiple uplink (UL) physical channels corresponding to REs carrying information originating from higher layers, and to receive UL physical signals used in the physical layer and corresponding to REs that do not carry information originating from higher layers. 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) for UL channel measurement.

[0098] When UE 3 initially establishes an RRC connection with base station 5 via a cell, UE 3 registers with the appropriate AMF 9 (or MME). UE 3 is in a so-called RRC connected state, and the associated UE context is maintained by the network. UE 3 can transition from the RRC connected state to the RRC idle state, or to the RRC inactive state. For example, UE 3 can transition from the RRC connected state to the RRC inactive state in response to receiving an RRC release message from base station 5 that includes an indication (e.g., suspendConfig) that UE 3 will enter (transition to) the RRC inactive state. UE 3 can transition from the RRC inactive state to the RRC connected state, and can transmit a corresponding RRC resume request to base station 5. UE 3 can transition from the RRC inactive state to the RRC connected state in response to receiving a paging call (e.g., group paging for a group of UEs 3, etc.) from base station 5. When UE 3 is in a so-called RRC idle state or in an RRC inactive state, it selects an appropriate cell to camp on, so that the network knows the approximate location of UE 3 (although not necessarily at the cell level). It should be understood that the RRC inactive state can be considered as an intermediate state between the RRC connected state and the RRC idle state, in which the RRC is not fully released, so that the UE 3 can return to the RRC connected state for transmitting to and / or receiving transmissions from the base station 5 more quickly.

[0099] Frame structure

[0100] Reference Figure 2 (It shows a typical frame structure (time resources) that can be used in communication system 1), the base station 5 and UE 3 of communication system 1 communicate with each other using resources organized in the time domain into frames of length 10ms. Each frame includes ten equally sized subframes of length 1ms. Each subframe is divided into one or more time slots consisting of 14 equally length orthogonal frequency division multiplexing (OFDM) symbols.

[0101] like Figure 2 As shown, the communication system 1 supports a number of different system parameters (subcarrier spacing (SCS), slot length and therefore OFDM symbol length). In particular, each system parameter is identified by a parameter μ, where μ=0 represents 15 kHz (corresponding to LTE SCS). Currently, SCS for other values ​​of μ can be actually scaled up from μ=0 by powers of 2 (i.e., SCS=15×2 μ The relationship between the parameter μ and SCS (Δf) is shown in Table 1:

[0102]

[0103] Table 1-5G system parameters

[0104] System Information and SIB

[0105] It will be appreciated that transmissions in cell 9 of base station 5 may include one or more broadcast transmissions, one or more unicast transmissions for reception by 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 'Minimum SI' (MSI) and 'Other SI' (OSI). OSI may be broadcast on demand, for example, using a downlink shared channel (DL-SCH). OSI may be broadcast upon request from a UE 3 in a Radio Resource Control (RRC) Idle or RRC Inactive state. OSI may also be requested by a UE 3 in an RRC Connected state, for example, via one or more dedicated RRC transmissions.

[0106] The SI may include information for enabling UE 3 to complete cell selection (e.g., configuring UE 3 to complete cell selection), may include information for enabling UE 3 to complete a cell reselection process, or may include information for enabling UE 3 to receive one or more paging messages transmitted in a cell. The SI may be broadcast using a master information block (MIB) and one or more system information blocks (SIBs).

[0107] MSI includes the MIB and system information block 1 (SIB1). The MIB includes information for UE 3 to receive SIB1, such as the subcarrier spacing used for SIB1. The MIB provides information corresponding to the control resource set (CORESET) and the search space. SIB1 can be referred to as 'residual MSI' (RMSI). SIB1 can be transmitted in a dedicated RRC message, and other SIBs (e.g., SIB2 to SIB9, etc.) can be transmitted using one or more other suitable RRC transmissions. The MIB and SIB1 can provide UE 3 with an indication of scheduling information for receiving and decoding other SIBs (e.g., SIB2 to SIB9, etc.) and can provide information for UE 3 to receive one or more paging messages. The OSI can include, for example, SIB2 to SIB9 transmitted in an SI message using the DL-SCH. The base station 5 can provide UE 3 with a mapping of SIB2 to SIB9 to the corresponding SI message. The MIB and SIB1 to SIB9 are described in more detail, for example, in 3GPP TS 38.331. For example, SIB2 provides information for intra-frequency, inter-frequency, and inter-system cell reselection, SIB3 provides cell-specific information for intra-frequency cell reselection, and SIB4 provides information for inter-frequency cell reselection. SIB5 provides information about inter-system cell reselection to 4G (LTE). SIB6 and SIB7 provide information for Earthquake and Tsunami Warning System (ETWS). SIB8 provides information for Commercial Mobile Alert Service (CMAS) notifications, such as to provide an alert text message to UE 3. SIB9 includes information about Coordinated Universal Time (UTC), Global Positioning System (GPS) time (e.g., for GPS initialization, etc.), and local time.

[0108] The SIBs may be broadcast periodically (e.g., according to a predetermined periodic pattern, etc.), or alternatively may be provided 'on demand', for example, in response to a request from the UE 3. For example, the MIB may be transmitted with a periodicity of 80 ms and repetitions within 80 ms, and the SIB1 may be transmitted with a periodicity of 160 ms and a variable transmission repetition periodicity within 160 ms (e.g., 20 ms, etc.). SIB1 may be used to indicate to the UE 3 which SIBs are transmitted periodically in response to a request from the UE 3 and which SIBs are available on demand. The UE 3 may be configured to request on-demand SIBs using MSG1 (Random Access Preamble (RA)) (which may be referred to as an on-demand SI request based on MSG1) or to request on-demand SIBs using MSG3 (RRC Connection Request) (which may be referred to as an on-demand SI request based on MSG3).

[0109] The physical broadcast channel (PBCH) can be used to broadcast the MIB. The base station 5 can transmit the PBCH and the synchronization signal (SS) (for example, the primary synchronization signal (PSS) and the secondary synchronization signal (SSS)) in the SS / PBCH block. The SS / PBCH block includes four orthogonal frequency division multiplexing (OFDM) symbols mapped to the PSS, SSS and the PBCH associated with the 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 can provide the UE 3 with an indication of the resources used for the SS / PBCH, for example, using dedicated signaling (for example, for an anchor NES cell or a non-anchor NES cell). SIB1 can be transmitted using the physical downlink shared channel (PDSCH). OSI can be similarly transmitted, for example, using the PDSCH.

[0110] When one or more beamforming transmissions are transmitted in a cell provided by a base station 5, some of the SI (e.g., some of the SIBs) may be transmitted using only specific beams or using specific transmission / reception points (TRPs).

[0111] Multicast and Broadcast Service (MBS)

[0112] Methods for providing MBS will now be described.Methods for maintaining multicast transmission (including point-to-multipoint (PTM) transmission) between a base station 5 and a UE 3 (eg, where continuity of MBS service is maintained) will be described.

[0113] The multicast service may include a PTP branch between the base station 5 and a single UE 3 and a PTM branch between the base station 5 and multiple UEs 3. Figure 3 PTP and PTM transmission are schematically shown in FIG. Figure 3 UE 3 is shown separately, but UE 3 can receive both the PTP and PTM parts of the multicast. PTP can be described as a PTP 'branch' or 'part' of the multicast transmission. Similarly, PTM can be described as a PTM 'branch' or 'part' of the multicast transmission.

[0114] A PTM branch has an MBS radio bearer (MRB) in an MBS session, which has a corresponding MRB configuration. Each MRB may have an associated identifier (e.g., an MRB identity) that may be used to identify the MRB. The MRB identity may be included in any suitable transmission for the MRB configuration. The multicast service may be suspended (processing in which the MRB is released) or reactivated based on multicast data activity (or inactivity). The configuration of one or more MRBs may be provided to the UE 3 and / or the base station 5, for example, in any suitable radio link control (RLC) configuration signaling (e.g., in an RLC bearer configuration message).

[0115] The base station 5 may provide the multicast MRB configuration via dedicated signaling to the UE 3. The multicast MRB may be DL-only RLC Unacknowledged Mode (RLC-UM), where no acknowledgement / negative acknowledgement (ACK / NACK) feedback is transmitted, or the MRB may have a bidirectional RLC-UM configuration for PTP transmission.

[0116] The multicast MRB configuration may include an RLC-Acknowledged Mode (RLC-AM) configuration for transmission of ACK / NACK feedback.The multicast MRB configuration may include an RLC Unacknowledged Mode (RLC-UM) configuration, in which ACK / NACK feedback is not transmitted.

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

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

[0119] A multicast MRB configuration may include two RLC-UM entities. One of the RLC-UM entities may be a DL-only RLC-UM entity for PTP transmission, while the other RLC-UM entity may be a DL-only RLC-UM entity for PTM transmission.

[0120] A multicast MRB configuration may include three RLC-UM entities, where one of the RLC-UM entities is a DL-only RLC-UM entity, one of the RLC-UM entities is a UL RLC-UM entity for PTP transmission, and another RLC-UM entity is a DL-only RLC-UM entity for PTM transmission.

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

[0122] When UE 3 transitions from the RRC connected state to the RRC inactive state, the multicast MRB can be suspended. When the UE is in the RRC inactive state, the multicast PTP branch may not be suitable for use because the PTP branch is UE-specific and the resources required to provide the PTP branch may increase linearly with the number of UEs. However, in this example, the multicast PTM portion can be advantageously maintained (or configured) even when UE 3 is in the RRC inactive state.

[0123] When the UE 3 performs cell reselection to a neighboring cell in the RRC inactive state (without restoring the RRC connection), it is advantageous to be able to maintain reception of multicast transmissions. Methods for configuring, resuming and maintaining multicast when the UE is in the RRC inactive state will be described later.

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

[0125] Maintain PTM for multicast

[0126] Figure 4 An example is shown where the UE 3 transitions from the RRC connected state to the RRC inactive state, but advantageously maintains the PTM leg for multicast transmission.

[0127] In step S401, UE 3 is in RRC connected state and receives multicast transmission from base station (access network node) 5. An MRB including a PTM branch has been configured for UE 3, and a PTM branch may also have been configured for UE 3.

[0128] In step S402, UE 3 receives an RRC release message from base station 5. Base station 5 may determine to transmit the RRC release message to UE 3, for example, to reduce congestion in the cell of base station 5 or due to a period of multicast data inactivity. The RRC release message may include an indication that the corresponding configuration is to be suspended (e.g., an information element such as suspendConfig, etc.). Advantageously, in this example, the RRC release message (e.g., in SuspendConfig, etc.) includes information for maintaining at least one PTM branch at UE 3 (e.g., information indicating that UE 3 is to store information corresponding to the PTM branch, etc.). The information for maintaining at least one PTM branch may also be referred to as a 'multicast indication.'

[0129] In step S403, UE 3 enters the RRC inactive state in response to receiving the RRC release message. However, since UE 3 receives information for maintaining the PTM branch in the RRC release message in step S402, UE 3 can advantageously continue to receive the PTM branch of the multicast transmission.

[0130] Figure 5An example of information for maintaining at least one PTM branch at UE 3 that may be included in the RRC release message of step S402 is shown in . However, it will be appreciated that the information for maintaining at least one PTM branch at UE 3 may have any other suitable format. In this example, the information includes an indication of 'RRCINACTIVEMBS', which is an indication of whether UE 3 should keep (maintain) the PTM RLC entity of the multicast MRB when UE 3 is in the RRC inactive state. In other words, upon receiving the indication, UE 3 determines whether to maintain the PTM RLC entity of the MRB. The indication may be, for example, 'TRUE' indicating that UE 3 is to maintain the PTM RLC entity of the MRB, or 'FALSE' indicating that UE 3 is not to maintain the PTM RLC entity of the MRB (although it will be appreciated that the indication need not be 'TRUE' or 'FALSE', and any other suitable indication such as '0' or '1' may alternatively be used). As Figure 5 As shown, in this example, the information included in the RRC release message includes an MRB list, and UE 3 may determine to maintain the PTMRLC entity for the MRBs indicated in the list.

[0131] In case the MBS session has been completed or deactivated, the indication of whether the UE 3 should maintain at least one PTM branch may be used to indicate that a PTM branch is not maintained at the UE 3 .

[0132] The RRC release message received at UE 3 from the network (e.g., from base station 5, etc.) may include an indication of the configuration of MBS for neighboring cells. This information may include the neighboring cell configuration associated with the MBS session list. The neighboring cell MBS session configuration may be used to implicitly indicate which MBS session (MRB) will be maintained when UE 3 enters the RRC inactive state. However, such as Figure 5 The explicit indication shown may be preferred to avoid any ambiguity as to the indication.

[0133] Figure 6 A flow chart illustrating a method for a UE to continue receiving multicast transmissions in an RRC connected state is shown. In step S601, UE 3 is in an RRC inactive state and is receiving a multicast transmission transmitted by a base station. In step 602, base station 5 transmits an RRC resume message to UE 3 (e.g., after base station 5 determines that UE 3 is to transition to an RRC connected state). As described above with reference to Figure 4As described with the RRC release message of step S402, the RRC resume message may similarly include information for maintaining at least one PTM branch at UE 3. In step S603, UE 3 transitions to the RRC connected state and continues to receive multicast transmissions.

[0134] DU and CU

[0135] Figure 7 An example of transmitting an MRB list to UE 3 as part of an RRC release procedure involving DU 50 and CU 60 is shown. DU 50 may also be referred to as a 'first unit' of access network node 5 for radio communication with UE 3, and CU 60 may be referred to as a 'second unit' of access network node 5. Figure 7 The illustrated method begins with the UE 3 being in the RRC connected state and receiving multicast transmissions from the DU 50 including PTM transmissions.

[0136] In step S801, the CU 60 transmits 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', etc.). 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 enters the RRC inactive state. Alternatively, the UE context release request may include an indication that all MRBs for PTM transmission for the UE 3 are to be maintained (e.g., using an indication such as 'KeepPTMindication', which may be, for example, 'TRUE' or 'FALSE'; or similarly, '1' or '0'). The indication of which MRBs the DU 50 should maintain (e.g., which MRB's configuration should continue to be stored or which MRBs should be transmitted) may be in the form of any suitable information element or list, such as 'INACTIVE MRB_ID list', etc. Upon receiving the indication included in the UE Context Release Request, DU 50 may determine to maintain the UE 3 context and maintain one or more multicast FU tunnels associated with the bearer list (e.g., 'INACTIVE MRB_ID List') with the CU-UP. Because the indication included in the UE Context Release Request corresponds to a specific UE 3, it may be referred to as a 'UE-specific' indication. Based on this indication, DU 50 can determine which MBS service UE 3 is to receive when UE 3 is in the RRC Inactive state.

[0137] In step S802, DU 50 determines to maintain the MRB for PTM transmission based on the information included in the UE context release request. DU 50 may determine that DU 50 is to continue PTM transmission for UE 3 based on the indication in the UE context release request (e.g., all PTM transmissions from DU 50, or the PTM transmission set indicated in the UE context release request).

[0138] In step S803, DU 50 transmits an RRC release message to UE 3. The RRC release message includes a set (e.g., a list) of MRBs to be maintained at UE 3 for PTM transmission. UE 3 receives the MRB list and determines to maintain the MRBs indicated in the list (e.g., continues to store the configuration of the MRBs indicated in the list). The set of MRBs may also be referred to as a 'multicast indication.' UE 3 may maintain the PTM branches corresponding to the MRBs indicated in the MRB list. Therefore, advantageously, UE 3 can continue to receive multicast transmissions from DU 50 even after UE 3 has transitioned to the RRC inactive state.

[0139] If UE 3 is the only UE 3 in the cell that is in the RRC connected state and wants to use the MBS session, then when CU 60 uses the UE context release request to release the RRC connection of UE 3, CU 60 can advantageously use the list of MRBs to be maintained for UE 3 (or an indication of all MRBs to be maintained for PTM transmission to UE 3) to indicate to DU 50 that DU 50 wants to maintain PTM transmission for UE 3. Therefore, even after there are no more UEs 3 in the RRC connected state in the cell, UE 3 can continue to receive PTM transmission (which otherwise may cause DU 50 to interrupt PTM transmission). In addition, since the RRC release message received at UE 3 from DU 50 includes the list of MRBs to be maintained, UE 3 can perform control to receive the corresponding PTM transmission.

[0140] When UE 3 is in the RRC connected state, MRBs for PTM transmission are configured. The PTM RLC entities for different UEs 3 may be different because the PTM RLC entity for each UE 3 is configured separately. The RLC configuration may include a logical channel identity (e.g., 'logicalChannelIdentity', etc.) and a multicast RLC bearer configuration, as well as other information. In this example, when the UE 3 RRC connection is released to the inactive state and the UE 3 maintains the PTM RLC entity (e.g., based on an MRB list received from DU 50, etc.), the network (e.g., base station 5, etc.) maintains the corresponding PTM RLC entity at the network. More generally, since the configuration for PTM for a particular UE 3 may be different from the configuration for PTM for another UE 3, when a particular UE 3 is to be based on Figure 8 While the illustrated method maintains the configuration for PTM, the configuration is also maintained at the network (eg, at the DU 50, etc.).

[0141] RLC Configuration

[0142] Alternatively or additionally, the RLC configuration may be used to indicate the PTM to be maintained for the UE 3. For example, the RLC bearer configuration may include an indication that the UE 3 may use the PTM configuration when it is in the RRC inactive state. This indication may also be referred to as a 'multicast indication'. Figure 8 An example of such an RLC bearer configuration that may be transmitted to UE 3 is shown in FIG. Figure 8 As shown, the RLC configuration includes an indication that the UE 3 may use the PTM configuration when it is in the RRC inactive state. Figure 9 In the example of UE3, the indication is 'INACTIVEPTMIndicator', which may be, for example, 'TRUE' or 'FALSE'; or similarly, '1' or '0', to indicate whether the UE 3 may use the PTM configuration when in the RRC inactive state.

[0143] Figure 9 An alternative is shown in which, instead of including a separate indication with a list of MBS radio bearers, a separate multicast RLC bearer configuration for UEs in the inactive state is provided (in this example, as 'InactiveMulticastRLC-BearerConfig-r18'). If InactiveMulticastRLC-BearerConfig-r18 is included in the RLC configuration, UE 3 can use the corresponding PTM configuration when it is in the RRC inactive state.

[0144] Cell reselection

[0145] When UE 3 is receiving a multicast service and then performs cell reselection in the RRC inactive state (cell reselection without resuming the RRC connection), it can continue to receive the multicast service in the new cell. In particular, if the configuration of the multicast service in the new cell is available to UE 3 (for example, if UE 3 has already received the configuration of the multicast service in the new cell from the network), the continuity of the multicast service can be supported. If the configuration of the multicast service in the new cell is not available to UE 3, UE 3 can resume the RRC connection (enter the RRC connected state) to obtain the multicast MRB configuration from the network.

[0146] Configuration for multicast when UE is RRC inactive

[0147] As described above, after UE 3 joins the multicast session, UE 3 may transition from the RRC connected state to the RRC inactive state (e.g., according to any of the methods described above). However, the MBS session may become inactive (e.g., due to the base station determining to deactivate the MBS due to a period of data inactivity or because there are no longer any UEs 3 in the RRC connected state in the cell). If the MBS session becomes inactive, UE 3 may determine to enter the RRC inactive state (e.g., independently of base station 5) to reduce power consumption.

[0148] There is a problem: when UE 3 joins a multicast session, the MBS configuration is obtained from the core network, but the corresponding MRB configuration is not transmitted to UE 3 until the multicast session has been activated. However, UE 3 may need to transition from the RRC Inactive state to the RRC Connected state to receive the configuration for the MRB.

[0149] A method for a UE to enter an RRC connected state and receive an MRB configuration will now be described.

[0150] Figure 10 An example is shown where UE 3 receives a paging transmission from a (R)AN node 5 (eg, base station 5, etc.) In step S121, UE 3 has joined a multicast session and is in an RRC inactive state.

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

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

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

[0154] In step S125 , when UE 3 is in the RRC connected state, UE 3 communicates with base station 5 to provide UE 3 with MRB configuration for multicast.

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

[0156] Advantageously, in Figure 10 In the method shown, the UE 3, despite being initially in RRC inactive mode, is able to obtain configuration for multicast and is able to return to RRC inactive mode (which advantageously reduces power consumption and may also reduce congestion in the cell) and continue to receive multicast transmissions at the end of the process.

[0157] Figure 12 A further example is shown in which the UE enters an RRC connected state to receive information for receiving a multicast transmission.

[0158] The network may have multiple MBS sessions activated, and the network may not know which MBS session is to be used for UE 3 unless 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 can be used to identify an MBS bearer service. If UE 3 does not report the TMGI after the paging from base station 5, UE 3 may need to report the TMGI via additional signaling (e.g., using an 'MBSinterestedIndication' message, etc.). This results in additional delay, which is particularly disadvantageous for delay-sensitive services. Therefore, it is advantageous to include an indication of the MBS session after the paging from base station 5 (e.g., directly in response to the paging from base station 5).

[0159] In step S131 , when the MBS session is activated, the (R)AN node 5 (eg, base station 5 , etc.) transmits a paging message including the TMGI (or multiple TMGIs) of the MBS session to the UE 3 .

[0160] In step S132, after receiving the paging from the base station 5, the UE 3 transmits an RRC resume message to the base station 5. The RRC resume message includes the TMGI of the MBS service to be received by the UE 3. Advantageously, providing the TMGI in the RRC resume message enables the network to identify the MBS service to be received by the UE 3. If the UE 3 does not notify the base station 5 of the TMGI in step S132, the UE 3 may alternatively perform, for example, the steps described in TS 23.247 and referenced later. Figures 12 to 14 The described part of the multicast session joining and session establishment process is performed (steps 1a to 8).

[0161] In step S133 , an RRC recovery procedure is performed, wherein the UE 3 enters an RRC connected state.

[0162] In step S134, after receiving the TMGI from UE 3, the network configures a PTM branch for UE 3. Then, an RRC reconfiguration message including an indication of the corresponding MRB configuration is transmitted from base station 5 to UE 3. Since UE 3 now has the MRB configuration, UE 3 is able to receive multicast from base station 5.

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

[0164] Advantageously, at the end of the process, the UE 3 has an MRB configuration for receiving the multicast and has returned to the RRC inactive state, thereby reducing power consumption at the UE 3 during subsequent reception of the multicast.

[0165] Figures 12 to 14 A multicast session join and session establishment procedure is shown, which is described in more detail in, for example, TS 23.247 V17.4.0.

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

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

[0168] In step 2, Nnrf_NFDiscovery request / response is transmitted between the SMF 8-4 and the Network Repository Function (NRF).

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

[0170] In step 4, an authorization check process is performed at the SMF 8-4 and the UPF 8-3.

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

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

[0173] In step 7, a procedure for establishing shared delivery towards the RAN node in case the NG-RAN supports 5G MBS is performed.

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

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

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

[0177] Now go to Figure 13 , showing that if NG-RAN does not support 5G MBS, 5GC independent MBS service delivery is established.

[0178] In step 11a, an N4 session modification message is exchanged between the SMF 8-4 and the UPF 8-3. Then, a procedure for setting up unicast delivery or requesting multicast DL tunnel information for multicast delivery is performed.

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

[0180] In step 11c, N4mb session modify / create messages are exchanged between the MB-SMF and the MB-UPF.

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

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

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

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

[0185] Figure 14 The transmission of the shared MBS service delivery via 5GC is shown. In step 14, the multicast data is transmitted from the MB-UPF to the (R)AN node 5.

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

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

[0188] Figure 14 The transmission of a separate MBS service via 5GC is also shown. In step 17, the multicast data is transmitted from the MB-UPF to the UPF 8-3.

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

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

[0191] Reduce the occurrence of RRC connected mode

[0192] While some of the methods described above advantageously require UE 3 to return to RRC Connected mode to receive information for multicast reception (e.g., MRB configuration, etc.), it is also advantageous to reduce the number of times UE 3 enters the RRC Connected state. For example, it is advantageous to avoid situations where the multicast configuration changes and many UEs simultaneously enter the RRC Connected state to obtain the new configuration, as this can cause congestion on the Random Access Channel (RACH). Advantageously, in this example, UE 3 does not enter the RRC Connected state when it already has a configuration for PTM transmission of multicast.

[0193] Figure 15 and Figure 16 The MBS session activation and deactivation procedures described in more detail in TS 23.247 V17.4.0 are shown.

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

[0195] In step 2, NMBsmf_MBSSession_ContextStatusNotify is transmitted from MB-SMF to SMF 8-4.

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

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

[0198] In step 4b, Namf_CommunicationN1N2MessageTransfer is transmitted from the SMF 8-4 to the AMF 8-1.

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

[0200] In step 6, a service request is transmitted from UE 3 to AMF 8-1.

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

[0202] In step 7b, a NSmf_PDUSession_UpdateSMContext response is transmitted from the SMF 8-4 to the AMF 8-1.

[0203] Now go to Figure 16 , in step 8a, Namf_MT_UEReachabilityInfo_Notify is transmitted from AMF 8-1 to SMF 8-4.

[0204] In step 8b, Namf_Communication_N1N2MessageTransfer is transmitted from the SMF 8-4 to the AMF 8-1.

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

[0206] In step 10a, the establishment of 5GC shared MBS service delivery is performed.

[0207] In step 10b, steps 8-12 as described in clause 7.2.1.3 of TS 23.247 V17.4.0 are performed.

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

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

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

[0211] In step 14, a Namf_MBSCommunication_N2MessageTransfer response is transmitted from the AMF 8-1 to the MB-SMF.

[0212] In step 15, N4mb session modification messages are exchanged between the MB-UPF and the MB-SMF.

[0213] exist Figure 16 In step 12 of the illustrated process, AMF 8-1 transmits an NGAP Activation Request message to (R)AN node 5, and UE 3 subsequently receives paging from (R)AN node 5, allowing UE 3 to receive the corresponding configuration for PTM. In the event that UE 3 has already joined an MBS session but is now in the RRC Inactive state, if UE 3 has already been configured with PTM configuration before entering the RRC Inactive state, UE 3 does not need to enter the RRC Connected state to obtain the PTM configuration. However, UE 3 can enter the RRC Connected state in response to receiving paging from (R)AN node 5. An improved method will now be described in which UE 3 does not enter the RRC Connected state if the PTM configuration is available at UE 3.

[0214] Figure 17 An example is shown where, after receiving a paging from the (R)AN node 5, the UE 3 does not enter the RRC connected state if a PTM configuration is available at the UE 3. It will be appreciated that Figure 17 The paging in does not have to be Figure 15 and 16 The method shown may be a paging corresponding to the paging from the (R)AN node 5, and the paging may be any other suitable paging from the (R)AN node 5. More generally, the (R)AN node 5 may determine to transmit to the UE 3 a transmission for causing the UE 3 to enter the RRC Connected state so that the configuration for PTM may be received, but in this example, if the UE 3 already has the configuration for PTM available (e.g., stored) at the UE 3, then the UE 3 will advantageously remain in the RRC Inactive state.

[0215] In step 191, paging is transmitted from the (R)AN node 5 to the UE 3. The paging may be used to cause the UE 3 to enter the RRC connected state so that the configuration for the PTM may be transmitted from the (R)AN node 5 to the UE 3.

[0216] In step 192, UE 3 determines not to enter the RRC Connected state even though it has received a paging call from (R)AN node 5. UE 3 may determine not to enter the RRC Connected state based on multicast information stored at UE 3 (e.g., MRB configuration for PTM stored at UE 3, etc.). Therefore, UE 3 advantageously does not transition to the RRC Connected state unnecessarily, thereby reducing power consumption at UE 3 and reducing the risk of network congestion.

[0217] Alternatively, the (R)AN node 5 may determine that the UE 3 already has a PTM configuration available at the UE 3 and may determine not to transmit a page 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 transmitted 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 transmitted the PTM configuration to the UE 3, the (R)AN node 5 may receive an indication from the network that the UE 3 already has a PTM configuration and determine not to transmit a corresponding page to the UE 3.

[0218] DCI and HARQ scheduling information

[0219] In wireless communications, some of the transmitted packets may be lost or may be subject to errors introduced by noise or interference. A hybrid automatic repeat request (HARQ) process may be used to mitigate such packet loss and errors by using retransmissions (or selective retransmissions) of data packets. For example, UE 3 may receive a transmission from base station 5 that includes errors or lost packets. Where possible, UE 3 may attempt to correct errors in the received transmission and may provide feedback on the received transmission to base station 5, such as including an acknowledgment (ACK) or negative acknowledgment (NACK). Based on the feedback, base station 5 may retransmit some or all of one or more of the original transmissions.

[0220] A HARQ process may include multiple simultaneous HARQ processes, each of which is used for a corresponding portion of the transmission. Thus, while the base station is waiting for feedback from the UE 3 corresponding to a particular HARQ process (and therefore corresponding to a particular portion of the transmission), the base station 5 may continue data transmission for other HARQ processes.

[0221] As described in more detail below, downlink control information (DCI) may be used to provide information about the HARQ process (e.g., HARQ configuration, etc.), such as time and frequency resources for the UE 3 to transmit HARQ acknowledgments, to the UE 3. The DCI may include, for example, one or more dedicated bits to indicate whether HARQ feedback is enabled (or disabled) for a particular HARQ process.

[0222] Figure 18 This example illustrates a method in which UE 3 transmits HARQ feedback based on DCI. 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 transmits the corresponding downlink transmission to UE 3. In step S173, UE 3 transmits HARQ feedback to base station 5 based on the HARQ configuration information received in the DCI from base station 5 in step S171.

[0223] The present inventors have appreciated that continuity of MBS services can be improved during transitions of UE 3 between RRC connected and RRC inactive states by providing an improved method for transmitting DCI to UE 3 in both RRC connected and RRC inactive states. The types of DCI that can be transmitted from base station 5 to UE 3 will now be described in more detail.

[0224] DCI 4_0

[0225] DCI format 4_0 is used to schedule a PDSCH for broadcast in a cell. In other words, DCI format 4_0 is a DCI for broadcast. DCI format 4_0 may alternatively be simply referred to as DCI 4_0.

[0226] DCI 4_0 and the corresponding PDCCH configuration may be used to transmit a broadcast to a UE 3 in an RRC connected state, an RRC inactive state, or an RRC idle state.

[0227] DCI 4_0 may be transmitted using a cyclic redundancy check scrambled by the MBMS point-to-multipoint control channel (MCCH) radio network temporary identifier (RNTI), i.e., MCCH-RNTI, or the group-RNTI (G-RNTI) for the multicast traffic channel (MTCH) configured by MBS session information (e.g., MBS-SessionInfo).

[0228] DCI 4_0 includes frequency domain resource assignments - If the cell is configured with CORESET 0, then is equal to the size of CORESET 0, and if the cell is not configured with CORESET0, then Equal to the size of the initial DL bandwidth portion.

[0229] DCI 4_0 includes a time domain resource assignment. The time domain resource assignment is used to indicate the slot offset, PDSCH mapping type, starting symbol, and number of allocated symbols. A lookup table (the time domain resource assignment may include a pointer to the lookup table) may be used to indicate this information.

[0230] DCI 4_0 includes virtual resource block (VRB) to physical resource block (PRB) mapping. 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, the index for a specific VRB is mapped to the PRB with the same index. In interleaved mapping, a function is used to map the index for a specific VRB to the corresponding PRB index.

[0231] The DCI 4_0 includes an indication of the modulation and coding scheme (MCS), which may be in the form of a pointer to a look-up table.

[0232] DCI 4_0 includes a redundancy version (RV) indicating a corresponding puncturing pattern.

[0233] If the CRC of DCI 4_0 is scrambled by MCCH-RNTI, DCI 4_0 includes MCCH change notification.

[0234] It should be understood that, where appropriate, a modified version of DCI 4_0 may be used in which some of the above information (such as MCCH change notification, etc.) is omitted.

[0235] In contrast to DCI 4_1 and DCI 4_2 described below, DCI 4_0 does not include a field indicating HARQ scheduling information for UE 3 in the RRC connected state. For example, DCI 4_0 does not include a new data indicator (NDI), an HARQ process number, or an indication of HARQ frequency or time resources.

[0236] DCI 4_1

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

[0238] When DCI 4_1 is used, the same transmission configuration index (TCI) state as the TCI state for unicast PDCCH may be used.

[0239] As described above for DCI 4_0, DCI 4_1 includes frequency domain resource assignment, time domain resource assignment, VRB to PRB mapping, MCS, and RV.

[0240] DCI 4_1 also includes a HARQ process number indicating the corresponding HARQ process.

[0241] DCI 4_1 may include a new data indicator (NDI) for indicating whether resource allocation is for retransmission or for new transmission.

[0242] DCI 4_1 includes a PUCCH resource indicator that indicates that UE 3 will use a specific PUCCH resource when returning a HARQ acknowledgement. If UE 3 has been configured with dedicated PUCCH resources, the PUCCH resource indicator may indicate one of these resources. The PUCCH resource indicator may be in the form of a 3-bit field.

[0243] DCI 4_1 includes a PDSCH to HARQ feedback timing indicator, which indicates the number of time slots between the reception of the PDSCH and the transmission of the HARQ feedback. The PDSCH to HARQ feedback timing indicator may be in the form of a 3-bit field.

[0244] It will be appreciated that, where appropriate, a modified version of DCI 4_1 may be used in which some of the above information is omitted.

[0245] DCI 4_2

[0246] DCI format 4_2 is used for scheduling of PDSCH. DCI format 4_2 may alternatively be referred to as DCI 4_2. DCI 4_2 for multicast MBS includes a TCI state for PDSCH reception.

[0247] DCI 4_2 may be transmitted through a cyclic redundancy check scrambled by the G-RNTI configured by G-RNTI configuration information (eg, G-RNTI-Config, etc.) or group configuration scheduling-RNTI (eg, G-CS-RNTI).

[0248] DCI 4_2 includes frequency domain resource assignment, time domain resource assignment, VRB to PRB mapping, PRB bundling size indicator, rate matching indicator, zero power channel condition information reference signal (ZP-CSI-RS) trigger, HARQ process number, downlink assignment index, PUCCH resource indicator, PDSCH to HARQ feedback timing indicator, and antenna port indication, transmission configuration indication, demodulation reference signal (DMRS) sequence initialization, priority indicator, and enable / disable HARQ-ACK feedback indication (where a value of 1 indicates that HARQ-ACK feedback is enabled and a value of 0 indicates that HARQ-ACK feedback is disabled).

[0249] It will be appreciated that, where appropriate, a modified version of DCI 4_2 may be used in which some of the above information is omitted.

[0250] The size of DCI 4_2 is configurable and can be, for example, between 20 bits and 140 bits.

[0251] DCI 4_0, DCI 4_1, and DCI 4_2 are described in more detail in 3GPP TS 38.212 V17.3.0.

[0252] RRC release

[0253] Some elements of the RRC release procedure will now be described in more detail. When UE 3 receives the RRC Release message, UE 3: resets the MAC and releases the default MAC cell group configuration (if any); reestablishes the RCL entity for Signaling Radio Bearer 1 (SRB1); suspends all of one or more SRBs and Data Radio Bearers (DRBs) and one or more Multicast MRBs except Signaling Radio Bearer 0 (SRB0); indicates to lower layers that the Packet Data Convergence Protocol (PDCP) is suspended for all DRBs and Multicast MRBs; and indicates to upper layers that the RRC connection is suspended. UE 3 enters the RRC Inactive state and performs cell selection.

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

[0255] When upper layers request RLC entity re-establishment, 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.

[0256] When the upper layer requests the PDCP entity to pause, the receiving PDCP entity: stops and resets the reordering timer; and delivers all stored PDCP SDUs to the upper layer in ascending order of associated count values ​​after performing header decompression.

[0257] The present inventors have recognized that multicast reception may be interrupted (without service reception continuity) during the transition of UE 3 from the RRC Connected state to the RRC Inactive state due to HARQ buffer flushing, MAC reset, RLC re-establishment, and PDCP suspension. However, for MBS multicast, service continuity requirements may exist (e.g., when MBS is used for public safety-oriented services). An improved method for alleviating this problem when UE 3 transitions from the RRC Connected state to the RRC Inactive state will be described later.

[0258] RRC recovery

[0259] Some elements of the RRC recovery process will now be described in more detail. Upon receiving the RRC recovery message, UE 3 performs cell group configuration for the received master cell group (e.g., masterCellGroup), including RLC reestablishment / RLC establishment and MAC configuration. If the RRC recovery message includes radio bearer configuration, UE 3 performs radio bearer configuration. If signaling radio bearer 2 (SRB2) is suspended, UE 3 resumes SRB2. If SRB3 and SRB4 are configured, UE 3 also resumes SRB3 and SRB4. UE 3 also resumes all suspended DRBs and multicast MRBs. UE 3 may also reestablish the PDCP entity for the multicast MRB.

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

[0261] When the upper layer requests the RLC entity to be re-established, UE 3 discards all RLC SDUs, RLC SDU segments and RLC PDUs (if any). UE 3 stops and resets all timers and resets state variables to their initial values. For UM DRBs and UM MRBs, UE 3 passes all stored PDCP SDUs to the upper layer in ascending order of the associated count values ​​after performing header decompression. For AM DRBs and AM MRBs for the Uu interface, 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, UE 3 may reset the ROHC protocol for the downlink and start in the No Context (NC) state in unidirectional mode (U mode), where packets are sent in only one direction (from the compressor to the decompressor).

[0262] The present inventors have recognized that, due to MAC configuration, RLC establishment / reestablishment, and PDCP reestablishment, multicast reception may be interrupted (without service reception continuity) during the transition of UE 3 from the RRC Inactive state to the RRC Connected state. However, for MBS multicast, service continuity requirements may exist (e.g., when MBS is used for public safety-oriented services). An improved method for alleviating this problem when UE 3 transitions from the RRC Inactive state to the RRC Connected state will be described later.

[0263] Multicast transmission and group-common PDSCH

[0264] The PDSCH is used to transmit end-user application data, Signaling Radio Bearer (SRB) messages, system information, and paging messages.A Group Common PDSCH (GC-PDSCH) is a PDSCH transmitted for reception by a corresponding group of UEs 3 .

[0265] 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. DCI (e.g., DCI 4_1 or DCI 4_2, etc.) transmitted to UEs 3 in the RRC-connected state may include HARQ scheduling information, such as NDI, HARQ process number, HARQ feedback time resource, and HARQ feedback frequency resource. If the network assumes that there is no HARQ feedback for these UEs 3, the DCI used to schedule multicast transmissions for UEs 3 in the RRC-inactive state does not need to carry HARQ scheduling information. A single MBS multicast cell supports multicast transmissions to UEs 3 in both the RRC-connected state and the RRC-inactive state. Two different types of DCI can be used to schedule multicast transmissions: one type of DCI for UEs in the RRC-connected state and one type of DCI for UEs in the RRC-inactive state.

[0266] A common identifier, the Group-RNTI (G-RNTI), can be used to group and identify a group of UEs 3 residing on a cell. The use of the G-RNTI enables more flexible scheduling of unicast and multicast data within the PDSCH channel. A single DCI can be transmitted to a group of UEs 3 based on the G-RNTI for reception of a specific downlink transmission by those UEs 3. Using the G-RNTI to identify a group of UEs 3 (rather than individual UEs 3) reduces PDCCH overhead. For multicast, UEs that have joined a particular MBS session can be configured with the same G-RNTI to receive the MBS session.

[0267] Methods for enabling UE 3 to continue receiving multicast transmissions when UE 3 transitions from an RRC connected state to an RRC inactive state (or vice versa) have been described above. A particularly advantageous method for improving MBS continuity (e.g., reducing interruptions in MBS reception by UE 3, etc.) when UE 3 transitions from an RRC connected state to an RRC inactive state (or vice versa) will now be described. While the methods for improving MBS continuity described below may be applied to any of the above methods where appropriate, it should be understood that the improved methods described below are not limited to application to the above methods and may alternatively be applied to any other suitable method for UE 3 transitioning from an RRC connected state to an RRC inactive state (or vice versa).

[0268] Same GC-PDSCH

[0269] An example will now be described in which the same GC-PDSCH is used for MBS multicast transmission for both an RRC connected UE and an RRC inactive UE 3. In this case, if HARQ scheduling information is provided, the HARQ scheduling information is common to both the RRC connected UE 3 and the RRC inactive UE 3.

[0270] No HARQ scheduling information

[0271] In the first option, no HARQ scheduling information is provided. In this case, a single DCI or two different DCIs can be used to schedule multicast transmissions for GC-PDSCH. For example, both the RRC-connected UE 3 and the RRC-inactive UE 3 use a single HARQ process to receive multicast transmissions. During the state transition between the RRC-connected state and the RRC-inactive state, the UE 3 maintains (keeps) 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 refresh the corresponding HARQ buffer (which may be a so-called 'soft buffer'). Advantageously, since the HARQ process is maintained without refreshing the corresponding HARQ buffer, the reception continuity of the multicast is improved when the UE 3 transitions between the RRC-connected state and the RRC-inactive state.

[0272] Multiple HARQ processes for RRC-inactive UEs

[0273] A further improved method will now be described in which HARQ scheduling information is provided to increase the reliability of transmission of transport blocks (TBs) over the air interface to UE 3. In this example, HARQ scheduling information is provided, including NDI, HARQ process ID, HARQ feedback resources, and HARQ timing resources (or any other suitable HARQ information, as described above, for example, with reference to DCI 4_1 and DCI 4_2). Advantageously, in addition to RRC-connected UEs 3, RRC-inactive UEs 3 can also receive multicast transmissions using the same set of multiple HARQ processes and can utilize HARQ retransmissions even when the RRC-inactive UEs 3 do not transmit HARQ feedback.

[0274] In this example, the RRC-connected UE 3 that is receiving the multicast uses the HARQ scheduling information (e.g., DCI 4_1 or DCI 4_2, etc.) provided in the DCI received from the base station 5. The RRC-connected UE 3 can 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 processing. Advantageously, the RRC-inactive UE uses the NDI and HARQ processing number indicated in the DCI to receive and process downlink transmissions. For example, the RRC-inactive UE 3 can use the NDI to determine whether the downlink transmission corresponds to new data or a retransmission. The RRC-inactive UE 3 can be configured not to transmit HARQ feedback (in this case, the RRC-inactive UE 3 can ignore the HARQ feedback frequency and time resources provided in the DCI). In this case, the HARQ retransmissions by the base station 5 that is providing the MBS multicast cell are based on feedback (e.g., NACK, etc.) from the RRC-connected UE 3, since the RRC-inactive UE 3 does not transmit HARQ feedback. However, since the RRC-inactive UE 3 is using the same HARQ process to receive multicast, the RRC-inactive UE 3 can still receive the HARQ retransmissions. If the UE 3 has successfully received and decoded the corresponding transport block, the RRC-inactive UE 3 can be configured to simply ignore the received multicast HARQ retransmissions. However, advantageously, in this example, if the UE 3 does not successfully receive and decode the transport block corresponding to the HARQ retransmission, the UE 3 can use (receive and process) the received HARQ retransmission. For example, the UE 3 can instruct the physical layer to combine the received HARQ retransmission with the data currently in the buffer for the corresponding transport block and attempt to decode the combined data. Thus, advantageously, UE 3 is able to utilize HARQ retransmissions even when UE 3 is in the RRC inactive state and is not transmitting HARQ feedback, thereby improving the reliability of MBS multicast reception over the air interface.

[0275] Single HARQ process for RRC-inactive UEs

[0276] An example in which an RRC-inactive UE 3 receives downlink data using one HARQ process will now be described. In this example, as in the above-described example using multiple HARQ processes, HARQ scheduling information is provided, including NDI, HARQ process ID, HARQ feedback resources, and HARQ timing resources (or any other suitable HARQ information, as described above, for example, with reference to DCI 4_1 and DCI 4_2). However, in this example, a single HARQ process is used. The RRC-connected UE 3 can transmit HARQ feedback to the base station 5 based on the HARQ configuration information included in the DCI for the single HARQ process. The RRC-inactive UE 3 also receives downlink data transmitted using the HARQ process. In this example, retransmissions are not identified, but the RRC-inactive UE 3 attempts to decode each received transport block for multicast, and if the transport block is successfully decoded, it is passed to the MAC layer. Since, in this example, UE 3 does not recognize whether the transmission is a new data transmission or a retransmission (because the same PDSCH is used for both RRC-connected UE 3 and RRC-inactive UE 3, and the inactive UE 3 has not requested a retransmission), the duplicate transport blocks can be passed to the MAC layer of UE 3. However, Layer 2 (L2) protocol functions can be used to remove the duplicate transport blocks. Advantageously, in this example, the operation of the RRC-inactive UE 3 is simplified because the RRC-inactive UE 3 only needs to be configured to receive data using a single HARQ process.

[0277] Different GC-PDSCH

[0278] Now refer to Figure 19 Describing an example where the GC-PDSCH for an RRC connected UE 3 is different from the GC-PDSCH for an RRC inactive UE 3, Figure 19 Three HARQ processes corresponding to a first GC-PDSCH for one or more RRC connected UEs 3 and another HARQ process for a second GC-PDSCH for one or more RRC inactive UEs 3 are shown. Transport blocks 1 to 6 transmitted using the HARQ processes are also shown. Figure 19 As shown, HARQ process-2 includes an initial transmission of transport block 2 indicated by a solid line, and a retransmission of transport block 2 indicated by a dashed box.

[0279] Two GC-PDSCHs are scheduled using corresponding 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 frequency division multiplexed (FDM), time division multiplexed (TDM), or both. Advantageously, in this example, when UE 3 transitions from the RRC connected state to the RRC inactive state (or vice versa), UE 3 may receive the two GC-PDSCHs (e.g., simultaneously or substantially simultaneously), thereby improving MBS multicast service continuity.

[0280] The HARQ process for the corresponding GC-PDSCH (in this example Figure 19 The DCI of HARQ process-1 to HARQ process-3 shown in FIG provides HARQ scheduling information to the RRC connected UE 3.

[0281] like Figure 19 As shown, transport blocks for two GC-PDSCHs can be delivered from the network to the UE 3 in a duplicated and synchronized manner. In other words, a specific transport block constructed based on the MAC PDU can be transmitted by the base station 5 over the air interface using two GC-PDSCHs at approximately the same time (or completely or substantially the same time). Figure 19 As shown, transport block 3 is transmitted at approximately the same time in the first GC-PDSCH and the second GC-PDSCH. Even if HARQ feedback and HARQ retransmission are used for the GC-PDSCH ( Figure 19 This synchronization can also be advantageously maintained when the first GC-PDSCH in Figure 19 As shown, HARQ process-2 includes a retransmission of transport block 2, indicated by a dotted line. The retransmission may be caused by one of the RRC-connected UEs 3 transmitting a NACK corresponding to transport block 2 to the base station 5. To maintain synchronization between the first GC-PDSCH and the second GC-PDSCH, in this example, the transport block is not transmitted using the second GC-PDSCH during the time period in which the retransmission occurs for the first GC-PDSCH. After the HARQ retransmission in HARQ process-2, the method continues with 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 GC-PDSCH and the second GC-PDSCH.

[0282] Although Figure 19In the example shown, the second GC-PDSCH includes a waiting period when retransmission of transport block 2 occurs, but this is not necessarily the case. Alternatively, the duplicate transmission can be performed at the PDCP and / or RLC layer. In other words, two different RLC entities can be established to support transmission at the two GC-PDSCHs, in which case synchronous transmission of transport blocks is not required.

[0283] DCI / HARQ switching

[0284] Now refer to Figure 20 An example of switching DCI to a different format is described below. During a transition between the RRC connected state and the RRC inactive state of UE 3, the DCI may be switched to support multicast reception after the transition occurs. In this example, an RRC release message transmitted from base station 5 to UE 3 is used to indicate the new DCI and corresponding PDCCH configuration to UE 3 (however, any other suitable transmission from base station 5 to UE 3 may alternatively be used).

[0285] As described above, the DCI for receiving multicast when UE 3 is in the RRC inactive state does not necessarily need to include HARQ scheduling information for HARQ feedback. When UE 3 is in the RRC connected state, multiple HARQ processes can be used to provide multicast, and when UE 3 is in the RRC inactive state, a single HARQ process can be used to provide multicast.

[0286] In this example, the DCI for a UE in an RRC connected state (e.g., DCI 4_1 or DCI 4_2, etc.) includes a corresponding HARQ process number, and multicast reception is based on multiple HARQ processes (each HARQ process is associated with a corresponding HARQ buffer). If the DCI switches to a new format or a format for broadcast (e.g., DCI 4_0, etc.), the HARQ process number is not indicated, and UE 3 can assume a single HARQ process. In this case, the previous HARQ buffer can be flushed (cleared or overwritten) at UE 3, and the corresponding HARQ process can be released. The new HARQ process is used for subsequent multicast reception.

[0287] like Figure 20 As shown, in step S200, UE 3 is initially in the RRC connected state. In step S201, UE 3 receives DCI (eg, DCI 4_1 or DCI 4_2, etc.) for HARQ processing, for receiving corresponding MBS multicast.

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

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

[0290] In optional step S204, UE 3 transmits HARQ feedback for the HARQ process to base station 5. It should be understood that HARQ feedback may be configured based on the DCI received in step S201 (or the DCI may include an indication that HARQ feedback is not required).

[0291] In step S205, after the base station determines that UE 3 is about to enter the RRC Inactive state (e.g., due to high RRC load), the base station transmits an RRC Release message to UE 3. The RRC Release message includes an indication of the multicast MRB configuration. After receiving the RRC Release message, UE 3 transitions from the RRC Connected state to the RRC Inactive state.

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

[0293] 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 which is in the RRC inactive state.

[0294] In step S208, UE 3 receives DL multicast data corresponding to a single HARQ process and thus continues to receive multicast.

[0295] Advantageously, with the help of the multicast MRB configuration information (which may also be referred to as multicast configuration information or DCI configuration information) included in the RRC release message, Figure 20 In the method shown, UE 3 can continue to receive MBS multicast even after UE 3 has transitioned to the RRC Inactive state. UE 3 transitions from receiving multicast using multiple HARQ processes in the RRC Connected state to receiving multicast using a single HARQ process in the RRC Inactive state.

[0296] Where appropriate, Figure 20 The method shown in can also be applied to any method of providing MBS multicast using multiple HARQ processes or a single HARQ process that has been described above.

[0297] Although the RRC release procedure and the transition of the UE 3 from the RRC connected state to the RRC inactive state have been described with reference to Figure 20However, the DCI can also be switched as part of the transition from the RRC Inactive state to the RRC Connected state. For example, a new multicast MRB configuration can be provided to UE 3 from the base station as part of the RRC recovery procedure. UE 3 can switch from receiving multicast via a single HARQ process when UE 3 is in the RRC Inactive state to receiving multicast via multiple HARQ processes when UE 3 is in the RRC Connected state.

[0298] Although Figure 20 The method advantageously enables UE 3 to continue receiving MBS multicast after transitioning to the RRC inactive state, but Figure 21 shows an example of a situation that may occur where one or more transport blocks may not be received and decoded by the UE 3. Figure 20 This may happen when the DCI switch occurs at the same time as a failure to successfully receive and decode the transport block. Figure 21 In the example shown, transport block 5 is not successfully received and decoded (indicated by the dashed box), and a corresponding NACK is transmitted from UE 3 to the base station. However, in this example, the DCI switch occurs shortly after the failure to decode transport block 5. Due to the switch to the new MRB configuration, the unsuccessfully decoded transport blocks are removed from the HARQ buffer and are not submitted to the MAC layer. In this example, this results in UE 3 failing to successfully receive and decode transport block 5. Furthermore, in this example, due to the time it takes to switch to the new DCI / HARQ process, transport blocks 6 and 7 are also not received by UE 3. A further improved method will now be described in which early DCI switching is used to alleviate these problems.

[0299] Switch in advance

[0300] Now refer to Figure 22 and Figure 23 An example is described of providing new DCI and corresponding PDCCH configuration to UE 3 before UE 3 is released into the RRC inactive state. Advantageously, this method enables more reliable reception and decoding of multicast transport blocks at UE 3, thereby improving the continuity of MBS multicast when UE 3 transitions from the RRC connected state to the RRC inactive state.

[0301] In this example, UE 3 is configured to monitor two different DCIs simultaneously and uses two separate buffers (or two separate buffer sets) to maintain two multicast data receptions. However, only one copy of the received data (e.g., received transport blocks, etc.) is submitted to the MAC layer (alternatively, appropriate L2 processing can be used to remove the duplicate transport blocks). Advantageously, Figure 22 and Figure 23The method shown avoids the switching delay between the two configurations (including Figure 20 RRC message parsing delay that may occur in the example of Figure 21 The gaps in transport block reception caused by decoding failures are shown in FIG.

[0302] Now go to Figure 22 In step S210, UE 3 is in RRC connected state. Steps 211 to 214 are the same as Figure 20 Steps S201 to S204 are the same and will not be repeated here.

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

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

[0305] In step S217 , UE 3 receives two DCIs for multicast (eg, DCI 4_1 / 4_2 and DCI 4_0 ).

[0306] In step S218, UE 3 receives the multicast data using the two DCIs (using the corresponding HARQ processes). In other words, simultaneous (or near-simultaneous) reception of the multicast data using the two DCIs occurs.

[0307] In step S219, DCI / HARQ switching is performed, wherein UE 3 switches to using the new multicast MRB configuration received in step S215, and no longer uses the previous DCI configuration (corresponding to step S211) to receive multicast.

[0308] In step S220, the base station 5 transmits an RRC release message to the UE 3, and the UE 3 then transitions to the RRC inactive state. However, since the DCI / HARQ switch to the new DCI and HARQ processes has occurred, the continuity of the MBS multicast reception is improved, and the downlink data is more reliably received and decoded at the UE 3.

[0309] Now go to Figure 23 In this example, transport block 1 of HARQ process-1 is not successfully received and decoded by UE 3. UE 3 transmits a corresponding NACK and retransmits transport block 1 in HARQ process-1, as shown in FIG. Figure 23 UE 3 also receives transport block 2 and transport block 3 in HARQ process-2 and HARQ process-3, respectively. After receiving the HARQ retransmission of transport block 1, the new MRB configuration (corresponding to Figure 22 It should be understood that at this stage, UE 3 has already Figure 22 4. UE 3 receives an indication of the new multicast MRB configuration in step S215. UE 3 can now receive transport block 4 in both HARQ process-2 and the new HARQ process (configured in step S215). Advantageously, even if there is a delay in the configuration of the new HARQ process where the use of the new HARQ process would result in not receiving transport block 4, transport block 4 can still be received using the existing HARQ process-2. After receiving transport block 4, the DCI / HARQ switch of step 219 occurs, and UE 3 then enters the RRC inactive state (in the Figure 22 After receiving the RRC release message in step S220 of UE 3, UE 3 then continues to use the newly configured HARQ process to receive transport blocks 5 to 9. However, since the new HARQ process has been configured before switching to the RRC inactive mode, the Figure 21 In the case shown in FIG, some transport blocks are not received. According to the timing of the HARQ / DCI switching of step 219, it should be understood that Figure 23 In the example shown, transport block 5 may be received by UE 3 in both HARQ process-3 and the new HARQ process for the RRC inactive state, or may be received by UE 3 only in the new HARQ process (but transport block 5 is advantageously received in at least one of the HARQ processes).

[0310] RRC release

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

[0312] To achieve improved continuity for MBS multicast when a transition from the RRC connected state to the RRC inactive state occurs, the multicast MRB used when UE 3 was in the RRC connected state is not suspended. Advantageously, the UE multicast MRB is maintained during the transition to the RRC inactive state, thereby improving the continuity of MBS multicast. The PDCP entity and RLC entity for the multicast MRB at UE 3 continue to operate during the transition (e.g., counter values, such as the count values ​​for 'RX_NEXT' and 'RX_DELIV' for PDCP, continue to run). The t reordering timer for PDCP also continues to run (the t reordering timer is used to detect the loss of PDCP data PDUs).

[0313] In this example, when UE 3 is in connected state, multicast MRB may be configured as follows:

[0314] - Multicast MRB with bidirectional RLC-UM configuration for PTP transport;

[0315] - Multicast MRB with RLC-AM entity configuration for PTP transmission;

[0316] - Multicast MRB with two RLC-UM entities: one DL-only RLC-UM entity for PTP transmission and one DL-only RLC-UM entity for PTM transmission;

[0317] - 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

[0318] - Multicast MRB with two RLC entities: one RLC-AM entity for PTP transmission and one RLC-UM entity for PTM transmission.

[0319] Before transitioning from the RRC Connected state to the RRC Inactive state, UE 3 switches the multicast MRB bearer type to PTM transmission over the RLC-UM entity (e.g., using an RRC Release message, etc., before UE 3 is released). UE 3's PTP receive leg for the multicast MRB is terminated before transitioning to the RRC Inactive state. UE 3 maintains the multicast MRB during the transition; the PDCP entity and RLC entity for the multicast MRB at UE 3 continue to operate (as described above).

[0320] RRC recovery

[0321] An improved method including an RRC recovery procedure will now be described. In this example, when UE 3 is in an inactive state, UE 3 receives a multicast service via a PTM transmission. UE 3 monitors the group-scheduled PDDCH on a common frequency resource (CFR) used for multicast. The multicast MRB is configured as a DL-only RLC-UM entity for PTM transmission.

[0322] If the GC-PDSCH for UE 3 in the RRC connected state is the same as the GC-PDSCH for UE 3 in the RRC inactive state, UE 3 continues to use the DL HARQ process (as used when UE 3 was in the RRC inactive state) for multicast reception. When UE 3 is monitoring new DCI to receive multicast during the transition to the RRC connected state, the buffer (e.g., soft buffer, etc.) used to receive data corresponding to the DL HARQ process can be maintained (not refreshed). During the transition from the RRC inactive state to the RRC connected state, the UE 3 multicast MRB is maintained (no new MRB is established). Therefore, advantageously, the continuity of MBS multicast during the transition is improved. Since the multicast MRB is maintained, the PDCP and RLC entities of the multicast MRB at UE 3 continue to operate (e.g., count values, such as the count values ​​of 'RX_NEXT' and 'RX_DELIV' for PDCP, etc., continue to operate). The PDCP tReordering timer also continues to run (the tReordering timer is used to detect the loss of PDCP data PDUs).

[0323] Alternatively, if the GC-PDSCH for UE 3 in the RRC connected state is different from the GC-PDSCH for UE 3 in the RRC inactive state, a new DL HARQ process set is used to continue receiving multicast at UE 3. The DL HARQ process used for multicast PTM reception while UE 3 is in the RRC inactive state is released, and the corresponding HARQ soft buffer is flushed until UE 3 can receive the newly configured GC-PDSCH via new DCI, at which point UE 3 is in the RRC connected state. Alternatively, simultaneous reception of two GC-PDSCHs can also be performed by UE 3. In this case, only one copy of the transport block (received via two GC-PDSCHs) is passed to the MAC layer after decoding at the physical layer (alternatively, the duplicate transport block can be processed using appropriate L2 processing). The multicast MRB is maintained at UE 3 during the transition from the RRC inactive state to the RRC connected state. As described above, in the case where the GC-PDSCH for the UE 3 in the RRC connected state is the same as the GC-PDSCH for the UE 3 in the RRC inactive state, the PDCP entity and the RLC entity continue to operate.

[0324] User Equipment

[0325] Figure 24 It shows that Figure 1 A schematic block diagram of the main components of UE 3 is shown.

[0326] As shown, UE 3 has transceiver circuitry 310 operable to transmit and receive signals to and from base station 5 via one or more antennas 330 (e.g., comprising one or more antenna elements). UE 3 also has a controller 370 for controlling the operation of UE 3. Controller 370 is associated with memory 390 and coupled to transceiver circuitry 310. Although not necessarily required for the operation of UE 3, UE 3 may of course have all the usual functionality of a conventional UE 3 (e.g., a user interface 350, such as a touch screen / keypad / microphone / speaker, and / or the like, for allowing direct user control and interaction), and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. For example, the software may be pre-installed in memory 390 and / or may be downloaded via a telecommunications network or from a removable data storage device (RMD).

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

[0328] The communication control module 430 is operable to control communications between the UE 3 and one or more of its serving base stations 5 (as well as other communication devices connected to the base stations 5, such as further UEs and / or core network nodes, etc.). The communication control module 430 is configured to overall handle uplink communications (including both dynamic and semi-static signaling (e.g., SRS, etc.) via associated uplink channels (e.g., via the Physical Uplink Control Channel (PUCCH), the Random Access Channel (RACH), and / or the Physical Uplink Shared Channel (PUSCH), etc.). The communication control module 430 is also configured to overall handle the reception of downlink communications (including both dynamic and semi-static signaling (e.g., CSI-RS, etc.) via associated downlink channels (e.g., via the Physical Downlink Control Channel (PDCCH) and / or the Physical Downlink Shared Channel (PDSCH)). The communication control module 430 is responsible for, for example: determining where to monitor downlink control information (e.g., the locations of the CSS / USS, CORESET, and associated PDCCH candidates to monitor); determining the resources to be used by the UE 3 for transmission / reception of UL / DL communications (including interleaved resources and resources subject to frequency hopping); managing frequency hopping on the UE side; determining how to configure time slots / symbols (e.g., for UL, DL, or SBFD communications, or the like); determining which one or more bandwidth portions are configured for the UE 3; determining how uplink transmissions should be encoded; appropriately applying any SBFD-specific communication configurations; and the like. The communication control module 430 can be configured to control communications according to any of the methods described above (e.g., receiving multicast transmissions from the base station 5, or transmitting HARQ feedback to the base station 5, etc.).

[0329] base station

[0330] Figure 25 It is shown for Figure 1A schematic block diagram of the main components of a base station 5 of a communication system 1 is shown. As shown, the base station 5 has transceiver circuitry 510 for transmitting and receiving signals to and from a communication device (such as a UE 3) via one or more antennas 530 (e.g., a single-panel or multi-panel antenna array / massive antenna, etc.), and a core network interface 550 (e.g., including N2, N3, and other reference points / interfaces). The transceiver circuitry 510 is used to transmit and receive signals to and from a communication device (such as a UE 3) via one or more antennas 530 (e.g., a single-panel or multi-panel antenna array / massive antenna, etc.). The core network interface 550 is used to transmit and receive signals to and from network nodes in the core network 7. Although not shown, the base station 5 may also be coupled to other base stations via appropriate interfaces (e.g., so-called 'Xn' interfaces in NR, etc.). The base station 5 has a controller 570 to control the operation of the base station 5. The controller 570 is associated with a memory 590. For example, software may be pre-installed in the memory 590 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD). In this example, the controller 570 is configured to control the overall operation of the base station 5 via program instructions or software instructions stored in the memory 590 .

[0331] As shown, these software instructions include an operating system 610 and a communication control module 630, among others.

[0332] The communication control module 630 is operable to control communications between the base station 5 and the UE 3, as well as other network entities connected to the base station 5. The communication control module 630 is configured to generally control the reception and decoding of uplink communications (including both dynamic and semi-static signaling (e.g., SRS, etc.)) via associated uplink channels (e.g., via the physical uplink control channel (PUCCH), the random access channel (RACH), and / or the physical uplink shared channel (PUSCH)). The communication control module 630 is also configured to generally control the transmission of downlink communications (including both dynamic and semi-static signaling (e.g., CSI-RS, etc.)) via associated downlink channels (e.g., via the physical downlink control channel (PDCCH) and / or the physical downlink shared channel (PDSCH)). The communication control module 630 is responsible for managing full-duplex (e.g., SBFD, etc.) communications, which includes separating UL and DL communications via different physical antenna elements where appropriate. The communication control module 630 is responsible for, for example: determining where to configure the UE 3 to monitor downlink control information (e.g., the location of the CSS / USS, CORESET, and associated PDCCH candidates to be monitored); determining the resources (including interleaved resources and resources subject to frequency hopping) to be scheduled for UE transmission / reception for UL / DL communication; managing frequency hopping on the base station side; appropriately configuring time slots / symbols (e.g., for UL, DL, or SBFD communication, or the like); configuring one or more bandwidth portions for the UE 3; providing relevant configuration signaling to the UE 3; and the like. The communication control module 630 can be configured to control communications (e.g., transmitting multicast transmissions, or receiving HARQ feedback from the UE 3, etc.) according to any of the methods described above.

[0333] Modifications and Replacements

[0334] As will be appreciated by those skilled in the art, many modifications and substitutions may be made to the exemplary embodiments described above while still benefiting from the present disclosure.

[0335] Although the description has been made with reference to the transport blocks Figures 19 to 23 However, a transport block may also be referred to as a “data unit”, and it should be understood that the corresponding method may also be applied to any other suitable data transmission unit.

[0336] It should be understood that, for example, while specific terminology for cellular communication generations (2G, 3G, 4G, 5G, 6G, etc.) may be used to refer to particular communication entities for clarity, technical features described with respect to a given entity are not limited to devices of that particular communication generation. Technical features may be implemented in any functionally equivalent communication entity, regardless of any differences in the terminology used to refer to them.

[0337] In the above description, for ease of understanding, the UE and the base station are described as having multiple discrete functional components or modules. Although these modules may be provided in this manner for certain applications, for example, where an existing system has been modified to implement the exemplary embodiments of the present disclosure, in other applications, such as in a system designed from the outset with the inventive features in mind, these modules may be built into the entire operating system or code, and therefore these modules may not be discernible as discrete entities.

[0338] In the above example embodiments, multiple software modules are described. As will be understood by those skilled in the art, software modules can be provided in compiled or uncompiled form and can be supplied as signals over a computer network or on a recording medium. In addition, one or more dedicated hardware circuits can be used to perform some or all of the functionality performed by the software. However, the use of software modules is preferred because it facilitates updating base stations or UEs to update their functionality.

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

[0340] The base station may comprise a 'distributed' base station having a central unit 'CU' and one or more separate distributed units (DUs).

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

[0342] It should be noted that the present disclosure is not limited to dedicated communication devices and, as explained in the following paragraphs, can be applied to any device with communication functionality.

[0343] The terms "user equipment" or "UE" (as used by 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, mobile phones, smartphones, tablets, cellular IoT devices, IoT devices and machines, etc. It will be understood that the terms "mobile station" and "mobile device" also cover devices that remain stationary for extended periods of time.

[0344] UE can be, for example, an equipment for production or manufacturing and / or an energy-related machinery (for example, equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal generators; nuclear power generators; batteries; nuclear systems and / or related equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil pressure equipment; pneumatic equipment; metal processing machinery; manipulators; robots and / or their application systems; tools; injection molding molds or die-casting molds; reels; conveying equipment; lifting equipment; material handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper processing machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or tools for agriculture, forestry and / or fisheries; 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.).

[0345] A UE may be, for example, a transportation device (e.g., transportation devices such as rolling stock, motor vehicles, motorcycles, bicycles, trains, buses, carts, rickshaws, ships and other watercraft, airplanes, rockets, satellites, drones, balloons, etc.). A UE may be, for example, an information and communication device (e.g., information and communication devices such as computers and related devices, communication and related devices, electronic components, etc.).

[0346] UE can be, for example, a refrigerator, a product using a refrigerator, a trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, consumer electronics and electronic equipment (for example, consumer electronic equipment such as the following: audio equipment; video equipment; speakers; radios; televisions; microwave ovens; rice cookers; coffee machines; dishwashers; washing machines; dryers; electric fans or related equipment; vacuum cleaners; etc.).

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

[0348] A UE may be, for example, an electronic lamp, a luminaire, a measuring instrument, an analyzer, a tester, or a surveying or sensing instrument (e.g., a surveying or sensing instrument such as a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag; etc.), a watch or clock, a laboratory instrument, an optical device, a medical device and / or system, a weapon, a piece of cutlery, a hand tool, or the like.

[0349] A UE may be, for example, a wirelessly equipped personal digital assistant or related equipment such as a wireless card or module designed to be attached to or plugged into another electronic device (eg, a personal computer, an electrical measuring machine, etc.).

[0350] A UE may be part of or a device that uses various wired and / or wireless communication technologies to provide applications, services, and solutions described below regarding the "Internet of Things" (IoT).

[0351] IoT devices (or "things") can be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like that enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may include automated devices that follow software instructions stored in internal memory. IoT devices can operate without the need for human supervision or interaction. IoT devices can also remain stationary and / or inactive for extended periods of time. IoT devices can be implemented as part of (usually) stationary equipment. IoT devices can also be embedded in non-stationary equipment (e.g., vehicles) or attached to animals or people to be monitored / tracked.

[0352] It will be understood that IoT technology can be implemented on any communication device that can connect to a communication network for transmitting / receiving data, regardless of whether such communication device is controlled by human input or by software instructions stored in memory. It will be understood that IoT devices are sometimes also referred to as machine type communication (MTC) devices or machine-to-machine (M2M) communication devices. It will be understood that a UE can support one or more IoT or MTC applications. Some examples of MTC applications are listed in the table below. This list is not exhaustive and is intended to indicate some examples of machine type communication applications.

[0353]

[0354]

[0355] The applications, services and solutions may be MVNO (Mobile Virtual Network Operator) services, emergency radio communication systems, PBX (Private Branch Exchange) systems, PHS / digital cordless telecommunication systems, POS (Point of Sale) systems, advertising call systems, MBMS (Multimedia Broadcast and Multicast Services), V2X (Vehicle to Everything) systems, train radio systems, location-related services, disaster / emergency wireless communication services, community services, video streaming services, femtocell application services, VoLTE (Voice over LTE) services, billing services, radio on demand services, roaming services, activity monitoring services, telecom operator / communication NW selection services, function restriction services, PoC (Proof of Concept) services, personal information management services, ad hoc network / DTN (Delay Tolerant Network) services, etc.

[0356] Furthermore, the above UE categories are merely examples of applications of the technical ideas and exemplary embodiments described herein. Needless to say, these technical ideas and exemplary embodiments are not limited to the above UEs, and various modifications may be made to the UEs.

[0357] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0358] For example, the whole or part of the exemplary embodiments disclosed above may be described as, but not limited to, the following supplementary notes.

[0359] (Supplementary Note 1)

[0360] A method for a user equipment (UE), the method comprising:

[0361] When the UE is in a radio resource control connected state (RRC connected state), receiving multicast data from an access network node using a repeated request process;

[0362] Transitioning to the RRC Inactive state; and

[0363] When the UE is in an RRC inactive state, receiving multicast data from an access network node;

[0364] When the UE is in the RRC inactive state, the UE receives the multicast data using the same repeat request process as that used for receiving the multicast data in the RRC connected state.

[0365] (Supplementary Note 2)

[0366] The method according to Supplementary Note 1, wherein the UE maintains the received multicast data in a buffer associated with the repeat request process during a transition from the RRC connected state to the RRC inactive state.

[0367] (Supplementary Note 3)

[0368] The method according to Supplementary Note 1 or 2, wherein the method further comprises: receiving downlink control information for receiving multicast data from an access network node, wherein the downlink control information includes a repeat request configuration for repeat request processing.

[0369] (Supplementary Note 4)

[0370] The method according to any one of Supplementary Notes 1 to 3, wherein the repeat request process is a hybrid automatic repeat request process (HARQ process).

[0371] (Supplementary Note 5)

[0372] The method according to any one of Supplementary Notes 1 to 4, wherein when the UE is in an RRC inactive state, the UE receives the multicast data using a repeat request process but does not request retransmission.

[0373] (Supplementary Note 6)

[0374] The method according to any one of Supplementary Notes 1 to 5, wherein the UE receives the multicast data using a single repeat request process when the UE is in an RRC connected state and when the UE is in an RRC inactive state.

[0375] (Supplementary Note 7)

[0376] The method of Supplementary Note 6, wherein, when the UE is in an RRC inactive state, the UE attempts to decode each data unit received using the repeat request process, regardless of whether the data unit is retransmitted data or newly transmitted data; and

[0377] After the data unit has been decoded at the UE, the UE determines whether the data unit is retransmitted data or newly transmitted data.

[0378] (Supplementary Note 8)

[0379] The method according to any one of Supplementary Notes 1 to 5, wherein the method further comprises:

[0380] When the UE is in a radio resource control connected state (RRC connected state), receiving scheduling information for requesting retransmission of multicast data from an access network node for a plurality of repeated request processes;

[0381] Wherein, when the UE is in an RRC connected state, receiving the multicast data from the access network node includes: receiving the multicast data using a plurality of repeated request processes; and

[0382] When the UE has transitioned from the RRC connected state to the RRC inactive state, the UE receives the multicast data using the same multiple repeat request process as that used for receiving the multicast data in the RRC connected state.

[0383] (Supplementary Note 9)

[0384] The method according to Supplementary Note 8, wherein the scheduling information includes at least one of an indication of an identifier of a repeat request process in a plurality of repeat request processes, and an indication of whether data transmitted to the UE using a repeat request process in the plurality of repeat request processes is newly transmitted data or retransmitted data.

[0385] (Supplementary Note 10)

[0386] The method according to Supplementary Note 8 or 9, wherein the method further comprises: decoding retransmitted multicast data received from the access network node using one of a plurality of repeat request processes while in an RRC inactive state if the same data has not been decoded at the UE.

[0387] (Supplementary Note 11)

[0388] The method according to any one of Supplementary Notes 8 to 10, wherein the method further comprises: if the UE determines that the multicast data has been decoded at the UE, not decoding the retransmitted multicast data received using one of the multiple repeat request processes when in the RRC inactive state.

[0389] (Supplementary Note 12)

[0390] A method for a user equipment (UE), the method comprising:

[0391] When the UE is in a radio resource control connected state (RRC connected state), receiving first multicast data from an access network node using a first repeat request process;

[0392] Transitioning to the RRC Inactive state; and

[0393] When the UE is in a radio resource control connected state (RRC connected state), receiving second multicast data from the access network node using a second repeat request process;

[0394] The method includes at least one of the following:

[0395] When the UE is in an RRC connected state, receiving first multicast data using a first repetition request process and a first at least one set of time resources and a second repetition request process and a second at least one set of time resources; and

[0396] receiving second multicast data using both the first repeat request process and the first at least one set of time resources and the second repeat request process and the second at least one set of time resources when the UE is in an RRC inactive state;

[0397] The first at least one set of time resources is configured by the access network node to at least partially overlap with the second at least one set of time resources.

[0398] (Supplementary Note 13)

[0399] A method for a user equipment (UE), the method comprising:

[0400] When the UE is in a radio resource control connected state (RRC connected state), receiving multicast data from an access network node using a plurality of first repeat request processes;

[0401] receiving an RRC release message from the access network node indicating that the UE is to transition to an RRC inactive state, wherein the RRC release message includes multicast configuration information for a second repeat request process;

[0402] releasing the plurality of first repeated request processes based on the multicast configuration information; and

[0403] When the UE is in the RRC inactive state, the multicast data is received from the access network node using a second repeat request process.

[0404] (Supplementary Note 14)

[0405] The method according to Supplementary Note 13, wherein the method further comprises:

[0406] receiving first downlink control information for receiving multicast data using a plurality of first repeat request processes; and

[0407] receiving second downlink control information for receiving multicast data using a second repeat request process;

[0408] The format or type of the first downlink control information is different from the format or type of the second downlink control information.

[0409] (Supplementary Note 15)

[0410] The method according to Supplementary Note 14, wherein the UE determines to release the plurality of first repetition request processes based on at least one of the following:

[0411] a difference between a format or type of the first downlink control information and a format or type of the second downlink control information;

[0412] The multicast configuration information indicates that when the UE is in the RRC inactive state, a single repeat request process is to be used to receive multicast data.

[0413] (Supplementary Note 16)

[0414] A method for a user equipment (UE), the method comprising:

[0415] When the UE is in a radio resource control connected state (RRC connected state), receiving multicast data from an access network node using a plurality of first repeat request processes;

[0416] receiving, from an access network node, multicast configuration information for a second repeat request process for receiving multicast data when the UE is in an RRC inactive state, when the UE is in an RRC connected state;

[0417] When the UE is in an RRC connected state, receiving multicast data from an access network node using a plurality of first repeat request processes and using a second repeat request process;

[0418] receiving an RRC release message from the access network node indicating that the UE is to transition to an RRC inactive state;

[0419] Transition to the RRC Inactive state; and

[0420] When the UE is in the RRC inactive state, a second repeat request process is used to receive multicast data from the access network node.

[0421] (Supplementary Note 17)

[0422] The method according to Supplementary Note 16, wherein the method further comprises:

[0423] receiving first downlink control information for receiving multicast data using a plurality of first repeat request processes; and

[0424] receiving second downlink control information for receiving multicast data using a second repeat request process;

[0425] The format or type of the first downlink control information is different from the format or type of the second downlink control information.

[0426] (Supplementary Note 18)

[0427] A method for a user equipment (UE), the method comprising:

[0428] When the UE is in a radio resource control connected state, i.e., an RRC connected state, receiving multicast data from an access network node using at least one multicast radio bearer, i.e., at least one MRB;

[0429] Transition to RRC inactive state;

[0430] When the UE is in the RRC inactive state, it uses MRB to receive multicast data from the access network node;

[0431] Wherein, when the UE is in the RRC connected state, a radio link control entity (RLC entity) associated with the MRB at the UE is maintained at the UE when the UE transitions to the RRC inactive state.

[0432] (Supplementary Note 19)

[0433] The method according to Supplementary Note 18, wherein at least one of a count value and a timer of an MRB stored at the UE when the UE is in an RRC connected state is maintained at the UE when the UE transitions to an RRC inactive state.

[0434] (Supplementary Note 20)

[0435] The method according to Supplementary Note 18 or 19, wherein the method includes: before the UE transitions to the RRC inactive state, switching the RLC entity from a first mode for transmitting repeat request feedback to the access network node to a second mode for not transmitting repeat request feedback to the access network node.

[0436] (Supplementary Note 21)

[0437] A method for a user equipment (UE), the method comprising:

[0438] When the UE is in a radio resource control inactive state (RRC inactive state), receiving multicast data from an access network node using at least one multicast radio bearer (MRB), wherein the UE uses a repeat request process to receive the multicast data;

[0439] Transitioning to the RRC connected state; and

[0440] The multicast data is received from the access network node using the MRB when the UE is in the RRC connected state and using the MRB and repeat request process used to receive the multicast data when the UE is in the RRC inactive state.

[0441] (Supplementary Note 22)

[0442] The method according to Supplementary Note 21, wherein the multicast data stored in the buffer associated with the repeat 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.

[0443] (Supplementary Note 23)

[0444] The method according to Supplementary Note 21 or 22, wherein a radio link control entity (RLC entity) associated with an MRB at the UE when the UE is in an RRC inactive state is maintained at the UE when the UE transitions to the RRC inactive state.

[0445] (Supplementary Note 24)

[0446] A method for a user equipment (UE), the method comprising:

[0447] When the UE is in a radio resource control inactive state (RRC inactive state), receiving multicast data from an access network node using at least one multicast radio bearer (MRB), wherein the UE receives the multicast data using a first repeat request process;

[0448] Transitioning to the RRC connected state; and

[0449] The UE receives multicast data from the access network node using the MRB when the UE is in the RRC connected state, using the MRB used to receive multicast when the UE is in the RRC inactive state, and using a plurality of second repeat request processes different from the first repeat request process.

[0450] (Supplementary Note 25)

[0451] The method according to Supplementary Note 24, wherein a radio link control entity (RLC entity) associated with an MRB at the UE when the UE is in an RRC inactive state is maintained at the UE when the UE transitions to the RRC inactive state.

[0452] (Supplementary Note 26)

[0453] A method for accessing a network node, the method comprising:

[0454] transmitting multicast data to a user equipment (UE) using a repeat request process when the UE is in a radio resource control connected state (RRC connected state); and

[0455] When the UE is in a radio resource control inactive state, ie, an RRC inactive state, the multicast data is transmitted to the UE using the same repeat request process.

[0456] (Supplementary Note 27)

[0457] A method for accessing a network node, the method comprising:

[0458] When the first UE is in a radio resource control connected state (RRC connected state), transmitting multicast data to the first user equipment (first UE) using a first repetition request process and using a first at least one set of time resources; and

[0459] when the second UE is in an RRC inactive state, transmitting multicast data to the second UE using a second repeat request process and using a second at least one set of time resources;

[0460] The first at least one set of time resources is configured by the access network node to at least partially overlap with the second at least one set of time resources in time.

[0461] (Supplementary Note 28)

[0462] The method according to Supplementary Note 27, wherein the first at least one set of time resources is the same as the second at least one set of time resources.

[0463] (Supplementary Note 29)

[0464] The method according to Supplementary Note 27 or 28, wherein the method further comprises:

[0465] receiving a request for retransmission of the multicast data from the first UE using a first repeat request process; and

[0466] The multicast data is retransmitted using the first repeat request process and using the third at least one set of time resources, and retransmissions of the multicast data are not transmitted using the second repeat request process and the third at least one set of time resources.

[0467] (Supplementary Note 30)

[0468] A method for accessing a network node, the method comprising:

[0469] When the UE is in a radio resource control connected state (RRC connected state), multicast data is transmitted to the user equipment (UE) using a plurality of first repetition request processes;

[0470] Transmitting an RRC release message to the UE indicating that the UE is to transition to an RRC inactive state, wherein the RRC release message includes multicast configuration information for the second repeat request process, wherein the multicast configuration information indicates that the UE is to release the plurality of first repeat request processes; and

[0471] When the UE is in the RRC inactive state, the multicast data is transmitted to the UE using a second repeat request process.

[0472] (Supplementary Note 31)

[0473] A method for accessing a network node, the method comprising:

[0474] When the UE is in a radio resource control connected state (RRC connected state), multicast data is transmitted to the user equipment (UE) using a plurality of first repetition request processes;

[0475] When the UE is in an RRC connected state, transmitting to the UE multicast configuration information for a second repeat request process for receiving multicast data when the UE is in an RRC inactive state;

[0476] When the UE is in an RRC connected state, transmitting multicast data to the UE using a plurality of first repeat request processes and using a second repeat request process;

[0477] transmitting an RRC release message to the UE indicating that the UE is to transition to an RRC inactive state; and

[0478] When the UE is in the RRC inactive state, the multicast data is transmitted to the UE using a second repeat request process.

[0479] (Supplementary Note 32)

[0480] A user equipment (UE) includes:

[0481] means for receiving multicast data from an access network node using a repeat request process when the UE is in a radio resource control connected state (RRC connected state); and

[0482] means for transitioning to an RRC inactive state;

[0483] wherein the means for receiving is configured to receive multicast data from the access network node when the UE is in an RRC inactive state; and

[0484] The UE is configured to receive the multicast data using the same repeat request process as that used for receiving the multicast data in the RRC connected state when the UE is in the RRC inactive state.

[0485] (Supplementary Note 33)

[0486] A user equipment (UE) includes:

[0487] means for receiving first multicast data from an access network node using a first repeat request process when the UE is in a radio resource control connected state (RRC connected state); and

[0488] means for transitioning to an RRC inactive state;

[0489] wherein the receiving means is configured to receive second multicast data from the access network node using a second repeat request process when the UE is in a radio resource control connected state (RRC connected state);

[0490] and wherein the means for receiving is configured to at least one of:

[0491] When the UE is in an RRC connected state, receiving first multicast data using a first repetition request process and a first at least one set of time resources and a second repetition request process and a second at least one set of time resources; and

[0492] receiving second multicast data using both the first repeat request process and the first at least one set of time resources and the second repeat request process and the second at least one set of time resources when the UE is in an RRC inactive state;

[0493] The first at least one set of time resources is configured by the access network node to at least partially overlap with the second at least one set of time resources.

[0494] (Supplementary Note 34)

[0495] A user equipment (UE) includes:

[0496] 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 connected state (RRC connected state), and for receiving an RRC release message from the access network node indicating that the UE is to transition to an RRC inactive state, wherein the RRC release message includes multicast configuration information for a second repeat request process; and

[0497] A component for releasing a plurality of first repeated request processes based on the multicast configuration information;

[0498] The receiving component is configured to: when the UE is in an RRC inactive state, receive the multicast data from the access network node using a second repeat request process.

[0499] (Supplementary Note 35)

[0500] A user equipment (UE) includes:

[0501] A component for receiving, configured to:

[0502] When the UE is in a radio resource control connected state (RRC connected state), receiving multicast data from an access network node using a plurality of first repeat request processes;

[0503] receiving, from an access network node, multicast configuration information for a second repeat request process for receiving multicast data when the UE is in an RRC inactive state, when the UE is in an RRC connected state;

[0504] When the UE is in an RRC connected state, receiving multicast data from an access network node using a plurality of first repeat request processes and using a second repeat request process; and

[0505] receiving an RRC release message from the access network node indicating that the UE is to transition to an RRC inactive state; and

[0506] means for transitioning to an RRC inactive state;

[0507] The receiving component is further configured to: when the UE is in an RRC inactive state, receive the multicast data from the access network node using a second repeat request process.

[0508] (Supplementary Note 36)

[0509] A user equipment (UE) includes:

[0510] means for receiving multicast data from an access network node using at least one multicast radio bearer, i.e. at least one MRB, when the UE is in a radio resource control connected state, i.e. an RRC connected state; and

[0511] means for transitioning to an RRC inactive state;

[0512] wherein the receiving means is configured to receive multicast data from the access network node using MRB when the UE is in an RRC inactive state; and

[0513] The UE is configured to maintain a radio link control entity (RLC entity) associated with the MRB at the UE when the UE is in the RRC connected state when the UE transitions to the RRC inactive state.

[0514] (Supplementary Note 37)

[0515] A user equipment (UE) includes:

[0516] means for receiving multicast data from an access network node using at least one multicast radio bearer, i.e., at least one MRB, when the UE is in a radio resource control inactive state, i.e., an RRC inactive state, wherein the UE is configured to receive the multicast data using a repeat request process; and

[0517] means for transitioning to an RRC connected state;

[0518] The receiving component is configured to: receive multicast data from the access network node using the MRB when the UE is in an RRC connected state and using the MRB and repeat request processing used for receiving multicast data when the UE is in an RRC inactive state.

[0519] (Supplementary Note 38)

[0520] A user equipment (UE) includes:

[0521] means for receiving multicast data from an access network node using at least one multicast radio bearer, i.e., at least one MRB, when the UE is in a radio resource control inactive state, i.e., an RRC inactive state, wherein the UE is configured to receive the multicast data using a first repeat request process; and

[0522] means for transitioning to an RRC connected state;

[0523] The receiving component is configured to: use the MRB when the UE is in an RRC connected state, use the MRB used to receive multicast when the UE is in an RRC inactive state, and use multiple second repetition request processes different from the first repetition request process to receive multicast data from the access network node.

[0524] (Supplementary Note 39)

[0525] An access network node, comprising:

[0526] means for transmitting multicast data to a user equipment (UE) using a repeat request process when the UE is in a radio resource control connected state (RRC connected state);

[0527] The component for transmitting is configured to: when the UE is in a radio resource control inactive state, ie, an RRC inactive state, transmit the multicast data to the UE using the same repeat request process.

[0528] (Supplementary Note 40)

[0529] An access network node, comprising:

[0530] means for transmitting multicast data to a first user equipment (i.e., a first UE) using a first repetition request process and using a first at least one set of time resources when the first UE is in a radio resource control connected state (i.e., an RRC connected state);

[0531] wherein the means for transmitting is configured to: when the second UE is in an RRC inactive state, transmit the multicast data to the second UE using a second repeat request process and using a second at least one set of time resources; and

[0532] The access network node further includes: a component for configuring the first at least one time resource set to at least partially overlap with the second at least one time resource set in time.

[0533] (Supplementary Note 41)

[0534] An access network node, comprising:

[0535] A component for transmitting, configured to:

[0536] When the UE is in a radio resource control connected state (RRC connected state), multicast data is transmitted to the user equipment (UE) using a plurality of first repetition request processes;

[0537] Transmitting an RRC release message to the UE indicating that the UE is to transition to an RRC inactive state, wherein the RRC release message includes multicast configuration information for the second repeat request process, wherein the multicast configuration information indicates that the UE is to release the plurality of first repeat request processes; and

[0538] When the UE is in the RRC inactive state, the multicast data is transmitted to the UE using a second repeat request process.

[0539] (Supplementary Note 42)

[0540] An access network node, comprising:

[0541] A component for transmitting, configured to:

[0542] When the UE is in a radio resource control connected state (RRC connected state), multicast data is transmitted to the user equipment (UE) using a plurality of first repetition request processes;

[0543] When the UE is in an RRC connected state, transmitting to the UE multicast configuration information for a second repeat request process for receiving multicast data when the UE is in an RRC inactive state;

[0544] When the UE is in an RRC connected state, transmitting multicast data to the UE using a plurality of first repeat request processes and using a second repeat request process;

[0545] transmitting an RRC release message to the UE indicating that the UE is to transition to an RRC inactive state; and

[0546] When the UE is in the RRC inactive state, the multicast data is transmitted to the UE using a second repeat request process.

[0547] This application is based upon and claims the benefit of priority from United Kingdom patent application No. 2301029.1 filed on January 14, 2023, the disclosure of which is incorporated herein in its entirety by reference.

[0548] [Reference Signs List]

[0549] 1 Communication System

[0550] 3 User Equipment

[0551] 5 Base Stations

[0552] 7 Core Network

[0553] 9 Residential Area

[0554] 10 Control Surface Functions

[0555] 11 User Plane Functions

[0556] 50 DU

[0557] 60 CU

[0558] 310 Transceiver Circuit

[0559] 330 antenna

[0560] 350 User Interface

[0561] 370 Controller

[0562] 390 Memory

[0563] 410 Operating System

[0564] 430 Communication Control Module

[0565] 510 transceiver circuit

[0566] 530 antenna

[0567] 550 core network interface

[0568] 570 Controller

[0569] 590 Memory

[0570] 610 Operating System

[0571] 630 Communication Control Module

Claims

1. A method performed by a user equipment (UE), the method comprising: During the transition between the radio resource control inactive state, i.e., the RRC inactive state, and the RRC connected state, service continuity for multicast reception is maintained with the access network node by using a multicast radio bearer, i.e., MRB, of a downlink radio link control unacknowledged mode only entity, i.e., a DL RLC-UM only entity, configured for point-to-multipoint transmission, i.e., PTM transmission.

2. The method according to claim 1, wherein Maintaining the service continuity includes at least one of the following: maintaining the MRB configured as a DL-only RLC-UM entity for PTM transmission during transitions between the RRC inactive state and the RRC connected state, and Before transitioning between the RRC inactive state and the RRC connected state, the type of the MRB is switched to a DL-only RLC-UM entity for PTM transmission.

3. The method according to claim 2, wherein: Maintaining service continuity is performed by switching the type of the MRB to a DL-only RLC-UM entity for PTM transmission before transitioning from an RRC connected state to the RRC inactive state, and Before transitioning from the RRC connected state to the RRC inactive state, terminating a point-to-point reception leg for the MRB.

4. The method according to claim 2 or 3, wherein: Switching the type of the MRB is performed by switching from at least one of the following: Multicast MRB with bidirectional RLC-UM configuration for point-to-point transmission, i.e., PTP transmission; A multicast MRB with an RLC acknowledged mode entity, i.e., an RLC-AM entity, configured for PTP transmission; A multicast MRB with two RLC-UM entities: one DL-only RLC-UM entity for PTP transmission and another 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 another DL-only RLC-UM entity for PTM transmission, and A multicast MRB with two RLC entities: one RLC-AM entity for PTP transmission and another DL-only RLC-UM entity for PTM transmission.

5. The method according to claim 1 or 2, wherein: During the transition between the RRC inactive state and the RRC connected state, a packet data convergence protocol entity (PDCP entity and RLC entity) on the UE corresponding to the MRB is maintained.

6. The method according to any one of claims 1 to 3, further comprising: At least one repeat request process for receiving multicast data is used during the RRC connected state, and the at least one repeat request process is used for receiving multicast data during the RRC inactive state.

7. The method according to claim 6, wherein: Multicast data stored in a buffer corresponding to the at least one repeat 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.

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

9. The method according to claim 6 or 7, further comprising: receiving control information for scheduling group-common multicast transmission in the RRC inactive state and the RRC connected state, wherein: 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 to receive a multicast transmission, and The scheduling information is ignored during the RRC inactive state.

10. The method according to claim 9, wherein: In the case where a transport block is retransmitted in the repeat request process and the transport block was successfully decoded before, the transport block is ignored.

11. The method according to claim 9, wherein In the case where a transport block is retransmitted in the repeat request process and the transport block has not been successfully decoded before, the transport block is used for combining with a previously received transport block.

12. The method according to claim 6 or 7, wherein: receiving control information for scheduling group-common multicast transmission in the RRC inactive state and the RRC connected state, wherein: 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 to receive a multicast transmission, and One of the plurality of processes is used during the RRC inactive process.

13. The method according to claim 12, wherein: In case a transport block is transmitted during the RRC inactive state and the transport block is successfully decoded, the transport block is delivered to a medium access control layer, MAC layer.

14. The method according to any one of claims 1 to 3, further comprising: using at least one first repeat request process for receiving multicast data during the RRC inactive state; as well as at least one second repeat request process for receiving multicast data is used during the RRC connected state, wherein The at least one second repeated request process is different from the at least one first repeated request process.

15. The method according to claim 14, wherein releasing the at least one first repeat request process upon transition between the RRC inactive state and the RRC connected state, and Multicast data stored in a buffer corresponding to the at least one first repeat request process before transition between the RRC inactive state and the RRC connected state is refreshed upon transition between the RRC inactive state and the RRC connected state.

16. The method according to claim 14, further comprising: receiving, in the RRC inactive state, first control information for scheduling group-common multicast transmission; receiving second control information for scheduling group common multicast transmission in the RRC connected state, wherein: A transport block is transmitted in a duplicated manner through a group common transmission corresponding to the first control information and a group common transmission corresponding to the second control information.

17. The method according to claim 16, wherein Respective transmissions of the transport blocks through the group common transmission corresponding to the first control information and the group common transmission corresponding to the second control information are synchronized with each other.

18. The method according to claim 16, wherein Respective transport blocks transmitted through the group common transmission corresponding to the first control information and the group common transmission corresponding to the second control information are processed by respective different RLC entities at the UE.

19. The method according to any one of claims 14 to 18, wherein At least one of the first control information and the second control information is configured before transition between the RRC inactive state and the RRC connected state.

20. The method according to any one of claims 16 to 18, further comprising: Prior to transitioning between the RRC inactive state and the RRC connected state, multicast reception is switched between a group common transmission corresponding to the first control information and a group common transmission corresponding to the second control information.

21. The method according to any one of claims 1 to 20, wherein Any transport blocks that were not successfully decoded due to transitioning between the RRC inactive state and the RRC connected state are discarded or removed from a buffer.

22. The method according to claim 4, wherein The at least one repeat request process comprises a hybrid automatic repeat request process, or HARQ process.

23. The method according to any one of claims 1 to 22, wherein The transition between the RRC inactive state and the RRC connected state includes at least one of the following: transitioning from the RRC inactive state to the RRC connected state, and Transitioning from the RRC connected state to the RRC inactive state.

24. A method for accessing a network node, the method comprising: During a transition of a user equipment (UE) between a radio resource control inactive state (RRC inactive state) and an RRC connected state, service continuity for multicast reception is maintained with the UE by using a multicast radio bearer (MRB) of a downlink radio link control unacknowledged mode (DL RLC-UM)-only entity configured for point-to-multipoint transmission (PTM transmission).

25. A user equipment (UE), comprising: Means for maintaining service continuity for multicast reception with an access network node during a transition between a radio resource control inactive state, i.e., an RRC inactive state, and an RRC connected state, by using a multicast radio bearer, i.e., an MRB, of a downlink-only radio link control unacknowledged mode entity, i.e., a DL RLC-UM-only entity, configured for point-to-multipoint transmission, i.e., PTM transmission.

26. An access network node, comprising: Means for maintaining service continuity for multicast reception with a user equipment (UE) during a transition between a radio resource control inactive state (RRC inactive state) and an RRC connected state by using a multicast radio bearer (MRB) of a downlink radio link control unacknowledged mode (DL RLC-UM)-only entity configured for point-to-multipoint transmission (PTM transmission).

Images