WO2023179157A1

WO2023179157A1 - Methods and devices for receiving a multicast transmission

Info

Publication number: WO2023179157A1
Application number: PCT/CN2022/143365
Authority: WO
Inventors: Jie LING; Erik Stare; Dung PHAM VAN
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-03-22
Filing date: 2022-12-29
Publication date: 2023-09-28

Abstract

A method implemented by a terminal device is provided. The method comprises: receiving a first multicast configuration from a network node via broadcast signaling; performing a first reception of multicast session data from the network node based on the first multicast configuration; receiving a second multicast configuration from the network node via a terminal device specific radio resource control (RRC) signaling; and switching from the first reception to, a second reception of the multicast session data from the network node based on the second multicast configuration.

Description

METHODS AND DEVICES FOR RECEIVING A MULTICAST TRANSMISSION

Technical Field

The present disclosure generally relates to wireless communication, and more particularly to methods and devices for receiving a multicast transmission.

Background

This section introduces aspects that may facilitate better understanding of the present disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

In 3GPP Release 17, the solutions for NR (New Radio) support of multicast and broadcast services (NR_MBS) are being specified.

Due to the time consideration, the objective of support for reception of multicast services by UEs (User Equipments) in RRC_IDLE/RRC_INACTIVE states is deprioritized in Release 17.

In Rel-17, e.g. the following support is provided:

● A broadcast MBS session (created in 5GC (5th Generation Core) ) can be received via a broadcast MRB (MBMS Radio Bearer) (created by NG-RAN (Next Generation -Radio Access Network) ) in all RRC (Radio Resource Control) states. The reception of a broadcast MBS session does not require MBS session join by the UE. The UE may (or may not) instead have interactions with the application. To receive the broadcast MRB, the RAN configures the UE via a broadcast signaling mechanism consisting of a System Information Block x (SIBx) and a Multicast Configuration CHannel (MCCH) .

● A multicast MBS session (created in 5GC) can be received via a multicast MRB (created by NG-RAN) in RRC CONNECTED. The reception of a multicast MBS session requires a prior MBS session join by the UE. With Rel-17, UEs in RRC INACTIVE/IDLE cannot receive a multicast MRB. A UE is individually RRC configured to receive a multicast MRB in RRC CONNECTED. The RRC configuration normally takes place at MBS session activation, i.e. when there is multicast data to transmit. The UE may then be in RRC INACTIVE/IDLE and will be paged to go to RRC CONNECTED and be RRC configured to receive the multicast session.

summary

With 3GPP Rel-17, reception of multicast sessions is only supported for UEs in RRC CONNECTED. In RRC CONNECTED, the UE is individually RRC configured to receive a multicast MRB.

To receive a multicast session, the UE first joins an MBS session in RRC CONNECTED, but the UE may not be RRC configured to receive the session until there is session data to transmit.

The RRC configuration normally takes place only when the MBS session is activated. Since there can be a significant amount of time between MBS session join and MBS session activation, the gNB (gNodeB) may have moved the UE to RRC INACTIVE or IDLE in the meantime, waiting for the session to be activated.

When the MBS session is activated, all RRC_INACTIVE UEs or RRC_IDLE that have earlier joined the MBS session will be paged. This paging will trigger them to perform Random Access to go to RRC CONNECTED and be RRC configured. Only after this can they receive the MBS session. With many UEs initially in RRC INACTIVE or RRC IDLE, this process may introduce excess latency.

For cases with many UEs in RRC CONNECTED waiting for session activation, such UEs may also suffer from excess latency due to many UEs that need to be RRC configured for the reception of the MBS session at the same time.

The present disclosure proposes an improved solution of multicast session data transmission.

According to a first aspect of the present disclosure, a method implemented by a terminal device is provided. The method may comprise: receiving a first multicast configuration from a network node via broadcast signaling; performing a first reception of multicast session data from the network node based on the first multicast configuration; receiving a second multicast configuration from the network node via a terminal device specific radio resource control, RRC, signaling; and switching from the first reception to, a second reception of the multicast session data from the network node based on the second multicast configuration.

In an alternative embodiment of the first aspect, the broadcast signaling may include common configuration information for terminal devices to receive the same multicast transmission.

In another alternative embodiment of the first aspect, in the case that the terminal device is in an RRC INACTIVE state, the method may further comprise: in parallel with the first reception, performing random access to enter an RRC CONNECTED state.

According to a second aspect of the present disclosure, a method implemented by a network node is provided. The method may comprise: transmitting a first multicast configuration to one or more terminal devices via broadcast signaling; performing a first transmission of multicast session data to the one or more terminal devices based on the first multicast configuration; transmitting a second multicast configuration to the one or more terminal devices via a terminal device specific radio resource control, RRC, signaling; and performing a second transmission of the multicast session data to the one or more terminal devices based on the second multicast configuration.

According to a third aspect of the present disclosure, a terminal device is provided. The terminal device may comprise a processor and a memory communicatively coupled to the processor. The memory may be adapted to store instructions which, when executed by the processor, cause the terminal device to perform operations of the method according to the first aspect.

According to a fourth aspect of the present disclosure, a terminal device is provided. The terminal device may comprise at least a receiving unit. The receiving unit may be adapted to: receive a first multicast configuration from a network node via broadcast signaling; perform a first reception of multicast session data from the network node based on the first multicast configuration; receive a second multicast configuration from the network node via a terminal device specific radio resource control, RRC, signaling; and switch from the first reception to, a second reception of the multicast session data from the network node based on the second multicast configuration.

According to a fifth aspect of the present disclosure, a network node is provided. The network node may comprise a processor and a memory communicatively coupled to the processor. The memory may be adapted to store instructions which, when executed by the processor, cause the network node to perform operations of the method according to the second aspect.

According to a sixth aspect of the present disclosure, a network node is provided. The network node may comprise at least a transmission unit. The transmission unit may be adapted to: transmit a first multicast configuration to one or more terminal devices via broadcast signaling; perform a first transmission of multicast session data to the one or more terminal devices based on the first multicast configuration; transmit a second multicast configuration to the one or more terminal devices via a terminal device specific radio resource control, RRC, signaling; and perform a second transmission of the multicast session data to the one or more terminal devices based on the second multicast configuration.

According to a seventh aspect of the present disclosure, a wireless communication system is provided. The wireless communication system may comprise at least one or more terminal devices according to the third or fourth aspect and a network node according to the fifth or sixth aspect.

According to an eighth aspect of the present disclosure, a non-transitory computer readable medium having a computer program stored thereon which, when executed by a set of one or more processors of a terminal device, may cause the terminal device to perform operations of the method according to the first aspect.

According to a ninth aspect of the present disclosure, a non-transitory computer readable medium having a computer program stored thereon which, when executed by a set of one or more processors of a network node, may cause the network node to perform operations of the method according to the second aspect.

With above aspects of the present disclosure, the UEs in RRC CONNECTED and UEs in RRC INACTIVE/IDLE can receive the multicast session data even before RRC configured, which can reduce the latency.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure may be best understood by way of example with reference to the following description and accompanying drawings that are used to illustrate embodiments of the present disclosure. In the drawings:

Fig. 1 is a flow chart illustrating a method implemented on a terminal device according to some embodiments of the present disclosure;

Fig. 2 is a flow chart illustrating a method implemented on network node according to some embodiments of the present disclosure;

Fig. 3 is a block diagram illustrating a terminal device according to some embodiments of the present disclosure;

Fig. 4 is another block diagram illustrating a terminal device according to some embodiments of the present disclosure;

Fig. 5 is a block diagram illustrating a network node according to some embodiments of the present disclosure;

Fig. 6 is another block diagram illustrating a network node according to some embodiments of the present disclosure;

Fig. 7 is a block diagram illustrating a wireless communication system according to some embodiments of the present disclosure;

Fig. 8 is a block diagram schematically illustrating a telecommunication network connected via an intermediate network to a host computer;

Fig. 9 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection; and

Figs. 10 to 13 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment.

DETAILED DESCRIPTION

The following detailed description describes methods and devices for receiving a multicast transmission. In the following detailed description, numerous specific details such as logic implementations, types and interrelationships of system components, etc. are set forth in order to provide a more thorough understanding of the present disclosure. It should be appreciated, however, by one skilled in the art that the present disclosure may be practiced without such specific details. In other instances, control structures, circuits and instruction sequences have not been shown in detail in order not to obscure the present disclosure. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

References in the specification to “one embodiment” , “an embodiment” , “an example embodiment” etc. indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dot-dash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments of the present disclosure. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments of the present disclosure.

In the following detailed description and claims, the terms “coupled” and “connected, ” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, cooperate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other.

An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media) , such as machine-readable storage media (e.g., magnetic disks, optical disks, read only memory (ROM) , flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other forms of propagated signals -such as carrier waves, infrared signals) . Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code/data even when the electronic device is turned off (when power is removed) , and while the electronic device is turned on, that part of the code that is to be executed by the processor (s) of that electronic device is typically copied from the slower non-volatile memory into volatile memory (e.g., dynamic random access memory (DRAM) , static random access memory (SRAM) ) of that electronic device. Typical electronic devices also include a set of one or more physical network interfaces to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. One or more parts of an embodiment of the present disclosure may be implemented using different combinations of software, firmware, and/or hardware.

To receive a multicast session, the UE first joins an MBS session in RRC CONNECTED, but the UE may not be RRC configured to receive the session until there is session data to transmit, i.e. when the MBS session is activated. Note that the multicast session can be in configured state that allows UE to join but no multicast data is transmitted (TS23.247, section 4.3) .

The RRC configuration normally takes place only when the MBS session is activated. Since there can be a significant amount of time between MBS session join and MBS session activation, the gNB may have moved the UE to RRC INACTIVE or IDLE in the meantime, waiting for the session to be activated.

Regarding the RRC configuration, there may be generally three cases:

1) When a UE is in RRC CONNECTED and has an earlier RRC configuration, e.g. for reception of unicast, this UE needs to be RRC re-configured to receive multicast, i.e. get the additional configuration for this.

2) When a UE is in RRC INACTIVE/IDLE and has a stored earlier RRC configuration (having this is a legacy behavior for RRC INACTIVE but would be new for RRC IDLE UEs) , and this UE comes back to RRC CONNECTED, it has to be re-configured to receive multicast, as in 1) .

3) When a UE is in RRC IDLE, without a stored RRC configuration (i.e. as in legacy) , and the UE returns to RRC CONNECTED, this UE needs a full RRC configuration. This full RRC configuration needs at least to include RRC configuration for multicast reception and, if also unicast is to be received, it also includes the RRC configuration for unicast. Both should be covered.

When the MBS session is activated, all RRC INACTIVE UEs that

__have earlier joined the MBS session will be paged. This paging will trigger them to perform Random Access to go to RRC CONNECTED and be RRC configured. Only after this can they receive the MBS session.

Especially when there are many UEs that have joined an MBS session, there may be a large number of UEs that all need to perform Random Access and move to RRC connected and be RRC configured at the same time. The session activation may e.g. be due the start of a group call, e.g. with Mission-Critical Push-To-Talk (MCPTT) . For such services, it is typically very important to minimize the call setup time, i.e. all UEs should be ready to receive data as soon as possible. However, due to the required procedural steps, performed by many UEs at the same time, it may not be possible to meet short call setup time. Instead, the resulting call setup time may suffer and will increase with the number of UEs that participates in the MBS session and are initially in RRC INACTIVE/IDLE.

In the present disclosure, a UE, which has earlier joined an MBS session, can in RRC INACTIVE/IDLE be configured to receive a multicast MBS session via a multicast MRB using a broadcast configuration signaling mechanism. This may be similar to the configuration method used for NR broadcast, i.e. using SIBx/MCCH.

The multicast MRB DL (DownLink) transmission is identical (using the same radio resources) for UEs in all RRC states. This avoids duplication of radio resources. The configuration received and used by UEs in RRC INACTIVE/IDLE is identical for all UEs, so it will be restricted to common elements needed to receive the PTM (Point To Multipoint) transmission directed to RRC CONNECTED UEs. The multicast Common Frequency Resource (CFR) , including the frequency range and numerology as well as group-common PDCCH (Physical Downlink Control CHannel) , PDSCH (Physical Downlink Shared CHannel) and SPS (Semi-Persistence Scheduling) configurations of the transmission, is an example of such common configurations.

With this functionality, e.g. the following cases can be supported:

1. A UE in RRC INACTIVE/IDLE, without prior configuration, can after being paged, quasi-instantly start receiving the MBS session in RRC INACTIVE/IDLE, and in parallel perform Random Access and be RRC configured. Finally, the UE switches seamlessly to receive the MBS session using the RRC configuration.

2. UEs, which are initially in RRC CONNECTED and not yet configured to receive the MBS session, may first use the broadcast configuration signaling to receive the MBS session data. When the UE has been RRC configured, it will seamlessly switch to use the RRC configuration instead. This may be applicable to cases with many UEs in RRC CONNECTED, queueing to be RRC CONNECTED. Although the latency gain may be small in comparison with the latency gain for UEs in RRC INACTIVE/IDLE, this may still be significant in extreme cases.

Specifically, when the MBS session is activated, there may be UEs in both RRC CONNECTED and RRC INACTIVE/IDLE. UEs in RRC CONNECTED can be RRC configured as normal to receive the multicast MRB carrying the multicast session data, without any need to first perform Random Access. From the perspective of RRC CONNECTED UEs, data transmission on the multicast MRB can therefore be started very quickly, with potentially very low latency and resulting very low call setup time, unless there are many UEs that need to be RRC configured at the same time.

To allow UEs in RRC INACTIVE/IDLE to receive the same MBS session data already in RRC INACTIVE/IDLE, the network transmits, temporarily or continually, an additional broadcast signal that convey the required configuration data, common for all RRC INATIVE/IDLE UEs, which allows UEs in RRC INACTIVE/IDLE to receive and use this configuration data to receive the MBS session data.

In total, the common configuration signal would contain all configuration data that are needed to receive, in RRC INACTIVE/IDLE, the same multicast (PTM) transmission that is transmitted to RRC CONNECTED UEs. Although UEs in RRC CONNECTED are individually RRC configured to receive the multicast, the broadcast signaling would only contain common signaling data for all UEs to receive the same group-common transmission. This may e.g. include the configuration of a Common Frequency Resource (CFR) , used for the multicast transmission to RRC CONNECTED UEs, i.e. the exact frequency resources to be used, the configuration of the group-common PDCCH, PDSCH and SPS.

In one embodiment, the following steps could be performed by the network and the UE:

1. When the MBS session is activated, the network pages all UEs that have joined the MBS session.

2. At the same time, the network starts the transmission of broadcast configuration signaling, using e.g. SIBx/MCCH.

3. At the same time or later, the network starts the multicast MRB transmission of MBS session data to RRC CONNECTED UEs and/or to RRC INACTIVE/IDLE UEs.

4. UEs in RRC INACTIVE/IDLE, which are paged for MBS session activation, initiate in parallel two processes: (1) Random Access (RA) to go to RRC CONNECTED and (2) Reception of the multicast MRB using broadcast configuration signaling.

5. The UE detects the presence of SIBx, decodes this and decodes MCCH.

6. The UE is configured to receive the multicast MRB session data via SIBx/MCCH.

7. Using the received configuration, the UE decodes the multicast MRB transmission mentioned in the above step 3 while still being in RRC INACTIVE/IDLE.

8. All steps above, related to reception of the multicast MRB, are performed in parallel with the UE performing the steps of Random Access and being RRC configured.

9. After completion of RRC configuration, the UE applies the RRC configuration instead of the broadcast signaling to receive the multicast MRB, now in RRC CONNECTED, and uses all configured functionality of the MRB in RRC CONNECTED, e.g. various UE feedback.

10. When all UEs that were paged to receive the MBS session have been RRC configured, the broadcast signaling can be turned off.

Since UEs, that were initially in RRC INACTIVE/IDLE, can access the MBS session data already in the initial state, using the broadcast signaling, the additional delays involved in the call setup time for these UEs, caused by RA and RRC configuration, including queueing effects (RA congestion, RRC configuration congestion) can be avoided, thereby significantly reducing overall latency.

As mentioned, UEs that are initially in RRC CONNECTED do not need to perform Random Access but will still need to be RRC configured.

In a further embodiment, depending on how many UEs there are initially in RRC CONNECTED, that need to be RRC configured because of MBS session activation, there could in some cases, be many such UEs, resulting in RRC configuration delays. It could then be beneficial, also for these UEs, to receive the broadcast signaling. Like UEs in RRC INACTIVE/IDLE, such RRC CONNECTED UEs could then also start receiving the multicast MRB using only the group-common broadcast configuration, before the UE becomes RRC configured, after which the applied configuration is switched to the RRC configuration. UEs in RRC CONNECTED may use the earliest received configuration to receive the MBS session data via the multicast MRB.

The net effect of both embodiments will be that the UE can access the MBS session data with reduced latency and will be able to benefit from the full functionality of multicast with RRC configuration (e.g. link layer adaptation, HARQ (Hybrid Automatic Repeat reQuest) retransmission based on UE-specific feedback, beamforming) . Compared to only using the common configuration, the advantage is higher reliability/radio performance once the UE is RRC configured. Compared to only using RRC configuration, the advantage is a lower latency.

In another embodiment, to speed up the reconfiguration of multicast MRB, the RRC_INACTIVE/IDLE UE that performs resume procedure in parallel with reception of multicast data indicates to the network in the UL (UpLink) message, i.e., RRCResumeRequest, that it is performing resume procedure to switch to reception of multicast data in RRC_CONNECTED from reception of multicast data in RRC_INACTIVE/IDLE. In response to this indication, the network provides the relevant MBS configuration information in the RRCResume message (instead of the RRCReconfiguration message later on) . In this case, the network can decide to provide only the UE-specific configuration parameters, i.e., delta signaling, which was not provided to the UE earlier via common control signaling. Such an indication to the network can be realized by, for example, a one-bit flag using unused bits in existing RRCResumeRequest message.

In another embodiment, to minimize the network resources, the network only broadcasts the common MBS configuration via common control channel, e.g., SIBx/MCCH when a multicast is (de) activated, i.e., after network individually pages UEs or pages a group of UEs. This is to avoid the periodic transmission of SIBx/MCCH.

Once having been provided with common MBS configuration, UEs may stay in RRC_INACTIVE/IDLE state for reception of the multicast data. However, the network may want to bring these UEs back to RRC_CONNECTED to further benefit them from PTM transmission in RRC_CONNECTED.

In yet another embodiment, it can be specified that when a UE or group of UEs in RRC_IDLE/RRC_INACTIVE are paged, they are indicated to get MBS configuration on a common control channel, then receive MBS data and at the same time perform random access procedure to be brought back to RRC_CONNECTED. Such an indication can be realized by a new flag in the paging message.

Following MBS session activation, the UE can be configured in two steps, first via a group-common (broadcast) signal, second to receive via RRC configuration. This allows for at least one of the following:

1. A UE in RRC INACTIVE/IDLE can start receiving the multicast MRB session data using the broadcast signal configuration in parallel with performing Random Access to go to RRC CONNECTED. After RRC configuration, the UE continues receiving the multicast MRB in RRC CONNECTED.

2. A UE in RRC CONNECTED can start receiving the multicast MRB session data using the broadcast signal configuration and in parallel be RRC configured to receive the same multicast MRB.

It should be noted that the multicast transmission may be the same for the two configuration cases. Logically, the same multicast session can be delivered via two different multicast transmissions -one for UEs configured with broadcast signaling and another for UEs configured with RRC signaling.

Fig. 1 is a flow chart illustrating a method 100 implemented on a terminal device according to some embodiments of the present disclosure. As an example, operations of this flow chart may be performed by a UE, but they are not limited thereto. The operations in this and other flow charts will be described with reference to the exemplary embodiments of the other figures. However, it should be appreciated that the operations of the flow charts may be performed by embodiments of the present disclosure other than those discussed with reference to the other figures, and the embodiments of the present disclosure discussed with reference to these other figures may perform operations different than those discussed with reference to the flow charts.

In one embodiment, the UE may receive a first multicast configuration from a network node via broadcast signaling (block 101) . The UE may perform a first reception of multicast session data from the network node based on the first multicast configuration (block 102) . The UE may receive a second multicast configuration from the network node via UE-specific RRC signaling (block 103) . The UE may switch from the first reception to a second reception of the multicast session data from the network node based on the second multicast configuration (block 1 04) .

As an example, multicast transmission in the first reception may be the same as in the second reception, or the multicast session data in the first reception and in the second reception may belong to the same or different multicast sessions.

As an example, the first reception may be performed before the terminal device is RRC configured.

As an example, the broadcast signaling may include common configuration information for UEs to receive the same multicast transmission.

As a further example, the common configuration information may include configuration of a common frequency resource for multicast transmission to RRC CONNECTED UEs.

As a further example, the broadcast signaling may include at least one of: an SIB and an MCCH.

As a further example, the first reception may be performed by:

detecting presence of the SIB;

decoding the SIB and the MCCH; and

receiving the multicast session data via the SIB and the MCCH.

As an example, the broadcast signaling may include a group-common configuration.

As an example, in the case that the UE is in an RRC INACTIVE state, the method 100 may further comprise:

in parallel with the first reception, performing random access to enter an RRC CONNECTED state.

As a further example, the method 100 may further comprise:

transmitting an RRC resume request to the network node including a first indication which indicates that the UE is switching from the first reception to the second reception; and

receiving an RRC resume response from the network node including an RRC configuration for the switching.

As a further example, the first indication may comprise a one-bit flag in the RRC resume request.

As a further example, the method 100 may further comprise:

remaining in the RRC INACTIVE state in response to receiving a common multicast and broadcast configuration from the network node via a common control channel.

As a further example, the method 100 may further comprise:

receiving a paging message from the network node including a second indication which indicates that a multicast and broadcast configuration is to be obtained from the network node; and

receiving the multicast and broadcast configuration from the network node while performing the random access.

As a further example, the method 100 may further comprise:

decoding the received multicast session data in the RRC INACTIVE state.

Fig. 2 is a flow chart illustrating a method 200 implemented on a network node according to some embodiments of the present disclosure.

In one embodiment, the network node may transmit a first multicast configuration to one or more UEs via broadcast signaling (block 201) . The network node may perform a first transmission of multicast session data to the one or more UEs based on the first multicast configuration (block 202) . The network node may transmit a second multicast configuration to the one or more terminal devices via UE-specific RRC signaling (block 203) . The network node may perform a second transmission of the multicast session data to the one or more UEs based on the second multicast configuration (block 204) .

As an example, multicast transmission in the first transmission may be the same as in the second transmission, or the multicast session data in the first transmission and in the second transmission may belong to the same or different multicast sessions.

As an example, the first transmission may be performed before the one or more UEs are RRC configured.

As an example, the broadcast signaling may include common configuration information for the one or more UEs to receive the same multicast transmission.

As an example, the method 200 may further comprise:

receiving an RRC resume request from a UE which is in an RRC INACTIVE state, including a first indication which indicates that the UE is switching reception of the multicast session data based on the first multicast configuration to reception based on the second multicast configuration; and

transmitting an RRC resume response to the UE including an RRC configuration for the switching.

As an example, the method 200 may further comprise:

broadcasting a common multicast and broadcast configuration to UEs which are in an RRC INACTIVE state via a common control channel after paging the UEs.

As an example, the method 200 may further comprise:

transmitting a paging message to a UE which is in an RRC INACTIVE state, including a second indication which indicates that a multicast and broadcast configuration is to be obtained by the UE; and

transmitting the multicast and broadcast configuration to the UE while the UE is performing the random access.

As an example, the method 200 may further comprise:

turning off the broadcast signaling in response to the one or more UEs being all RRC configured.

Fig. 3 is a block diagram illustrating a terminal device 300 according to some embodiments of the present disclosure. As an example, the terminal device 300 may act as a UE, but it is not limited thereto. It should be appreciated that the terminal device 300 may be implemented using components other than those illustrated in Fig. 3.

With reference to Fig. 3, the terminal device 300 may comprise at least a processor 301, a memory 302, a network interface 303 and a communication medium 304. The processor 301, the memory 302 and the network interface 303 may be communicatively coupled to each other via the communication medium 304.

The processor 301 may include one or more processing units. A processing unit may be a physical device or article of manufacture comprising one or more integrated circuits that read data and instructions from computer readable media, such as the memory 302, and selectively execute the instructions. In various embodiments, the processor 301 may be implemented in various ways. As an example, the processor 301 may be implemented as one or more processing cores. As another example, the processor 301 may comprise one or more separate microprocessors. In yet another example, the processor 301 may comprise an application-specific integrated circuit (ASIC) that provides specific functionality. In still another example, the processor 301 may provide specific functionality by using an ASIC and/or by executing computer-executable instructions.

The memory 302 may include one or more computer-usable or computer-readable storage medium capable of storing data and/or computer-executable instructions. It should be appreciated that the storage medium is preferably a non-transitory storage medium.

The network interface 303 may be a device or article of manufacture that enables the terminal device 300 to send data to or receive data from other devices. In different embodiments, the network interface 303 may be implemented in different ways. As an example, the network interface 303 may be implemented as an Ethernet interface, a token-ring network interface, a fiber optic network interface, a network interface (e.g., Wi-Fi, WiMax, etc. ) , or another type of network interface.

The communication medium 304 may facilitate communication among the processor 301, the memory 302 and the network interface 303. The communication medium 304 may be implemented in various ways. For example, the communication medium 304 may comprise a Peripheral Component Interconnect (PCI) bus, a PCI Express bus, an accelerated graphics port (AGP) bus, a serial Advanced Technology Attachment (ATA) interconnect, a parallel ATA interconnect, a Fiber Channel interconnect, a USB bus, a Small Computing System Interface (SCSI) interface, or another type of communications medium.

In the example of Fig. 3, the instructions stored in the memory 302 may include those that, when executed by the processor 301, cause the terminal device 300 to implement the method described with respect to Fig. 1.

Fig. 4 is another block diagram illustrating a terminal device 400 according to some embodiments of the present disclosure. As an example, the terminal device 400 may act as a UE, but it is not limited thereto. It should be appreciated that the terminal device 400 may be implemented using components other than those illustrated in Fig. 4.

With reference to Fig. 4, the terminal device 400 may comprise at least a receiving unit 401 and a switching unit 402. The receiving unit 401 may be adapted to perform at least the operations described in the

blocks

101, 102 and 103 of Fig. 1. The switching unit 402 may be adapted to perform at least the operation described in the block 104 of Fig. 1.

Fig. 5 is a block diagram illustrating a network node 500 according to some embodiments of the present disclosure. It should be appreciated that the network node 500 may be implemented using components other than those illustrated in Fig. 5.

With reference to Fig. 5, the network node 500 may comprise at least a processor 501, a memory 502, a network interface 503 and a communication medium 504. The processor 501, the memory 502 and the network interface 503 may be communicatively coupled to each other via the communication medium 504.

The processor 501, the memory 502, the network interface 503 and the communication medium 504 are structurally similar to the processor 301, the memory 302, the network interface 303 and the communication medium 304 respectively, and will not be described herein in detail.

In the example of Fig. 5, the instructions stored in the memory 502 may include those that, when executed by the processor 501, cause the network node 500 to implement the method described with respect to Fig. 2.

Fig. 6 is another block diagram illustrating a network node 600 according to some embodiments of the present disclosure. It should be appreciated that the network node 600 may be implemented using components other than those illustrated in Fig. 6.

With reference to Fig. 6, the network node 600 may comprise at least a transmission unit 601. The transmission unit 601 may be adapted to perform at least the operation described in the

blocks

201, 202, 203 and 204 of Fig. 2.

The units shown in Figs. 4 and 6 may constitute machine-executable instructions embodied within a machine, e.g., readable medium, which when executed by a machine will cause the machine to perform the operations described. Besides, any of these units may be implemented as hardware, such as an application specific integrated circuit (ASIC) , Digital Signal Processor (DSP) , Field Programmable Gate Array (FPGA) or the like.

Moreover, it should be appreciated that the arrangements described herein are set forth only as examples. Other arrangements (e.g., more controllers or more detectors, etc. ) may be used in addition to or instead of those shown, and some units may be omitted altogether. Functionality and cooperation of these units are correspondingly described in more detail with reference to Figs. 1-2.

Fig. 7 is a block diagram illustrating a wireless communication system 700 according to some embodiments of the present disclosure. The wireless communication system 700 may comprise at least one or more terminal devices 701 and a network node 702. In one embodiment, the one or more terminal devices 701 may act as the

terminal device

300 or 400 as depicted in Fig. 3 or 4, and the network node 702 may act as the network node 500 or 600 as depicted in Fig. 5 or 6. In one embodiment, the one or more terminal devices 701 and the network node 702 may communicate with each other.

In the present disclosure, in all cases, UEs in RRC CONNECTED and UEs in RRC INACTIVE/IDLE can receive the same multicast transmission (same radio resources) , which avoids the need for duplication of downlink radio resources to reach UEs in both RRC CONNECTED and RRC INACTIVE/IDLE. This is done in such a way that the advantages of multicast in RRC CONNECTED are preserved for UEs in RRC CONNECTED (e.g. using link adaptation and HARQ retransmissions based on UE feedback) , while at the same time allowing for UEs in RRC INACTIVE/IDLE to “piggy-back” on the same DL transmission. UEs in RRC INACTIVE/IDLE can even benefit from HARQ retransmissions triggered by UEs in RRC CONNECTED, or possibly initiated by the gNB without prior HARQ feedback, with the purpose to improve coverage for UEs in RRC INACTIVE/IDLE. In addition, the following advantages have been identified (corresponding to the two mentioned cases in the previous section) :

1. UEs in RRC_INACTIVE/IDLE, that are paged to go to RRC CONNECTED to receive the multicast MRB session data, can access MBS session data already in the initial state, while the UE can continue in parallel to reach RRC CONNECTED and seamlessly continue receiving the MBS session in RRC CONNECTED. This allows for reduced latency of receiving the MBS session data, primarily for UEs that are initially in RRC INACTIVE/IDLE, but potentially also for UEs that are initially in RRC CONNECTED, for cases with a large number of UEs to be RRC configured for the MBS session. The advantage is a reduced latency before UEs initially in RRC INACTIVE/IDLE can receive the multicast session.

2. UEs that are initially in RRC CONNECTED, and not yet configured to receive the MBS session, may first use the broadcast configuration signaling to receive the MBS session data. When the UE has been RRC configured, it will seamlessly switch to use the RRC configuration instead. This may be applicable for cases with many UEs in RRC CONNECTED, queueing to be RRC CONNECTED. Although the latency gain may be small in comparison with the latency gain for UEs in RRC INACTIVE/IDLE, this may still be significant in extreme cases with many UEs requiring RRC configuration at the same time.

Fig. 8 is a block diagram schematically illustrating a telecommunication network connected via an intermediate network to a host computer.

With reference to FIG. 8, in accordance with an embodiment, a communication system includes a telecommunication network 810, such as a 3GPP-type cellular network, which comprises an access network 811, such as a radio access network, and a core network 814. The access network 811 comprises a plurality of

base stations

812a, 812b, 812c, such as NBs (NodeBs) , eNBs, gNBs or other types of wireless access points, each defining a

corresponding coverage area

813a, 813b, 813c. Each

base station

812a, 812b, 812c is connectable to the core network 814 over a wired or wireless connection 815. A first user equipment (UE) 891 located in coverage area 813c is configured to wirelessly connect to, or be paged by, the corresponding base station 812c. A second UE 892 in coverage area 813a is wirelessly connectable to the corresponding base station 812a. While a plurality of

UEs

891, 892 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 812.

The telecommunication network 810 is itself connected to a host computer 830, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 830 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The

connections

821, 822 between the telecommunication network 810 and the host computer 830 may extend directly from the core network 814 to the host computer 830 or may go via an optional intermediate network 820. The intermediate network 820 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 820, if any, may be a backbone network or the Internet; in particular, the intermediate network 820 may comprise two or more sub-networks (not shown) .

The communication system of Fig. 8 as a whole enables connectivity between one of the connected

UEs

891, 892 and the host computer 830. The connectivity may be described as an over-the-top (OTT) connection 850. The host computer 830 and the connected

UEs

891, 892 are configured to communicate data and/or signaling via the OTT connection 850, using the access network 811, the core network 814, any intermediate network 820 and possible further infrastructure (not shown) as intermediaries. The OTT connection 850 may be transparent in the sense that the participating communication devices through which the OTT connection 850 passes are unaware of routing of uplink and downlink communications. For example, a base station 812 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 830 to be forwarded (e.g., handed over) to a connected UE 891. Similarly, the base station 812 need not be aware of the future routing of an outgoing uplink communication originating from the UE 891 towards the host computer 830.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to FIG. 9. In a communication system 900, a host computer 910 comprises hardware 915 including a communication interface 916 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 900. The host computer 910 further comprises processing circuitry 918, which may have storage and/or processing capabilities. In particular, the processing circuitry 918 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 910 further comprises software 911, which is stored in or accessible by the host computer 910 and executable by the processing circuitry 918. The software 911 includes a host application 912. The host application 912 may be operable to provide a service to a remote user, such as a UE 930 connecting via an OTT connection 950 terminating at the UE 930 and the host computer 910. In providing the service to the remote user, the host application 912 may provide user data which is transmitted using the OTT connection 950.

The communication system 900 further includes a base station 920 provided in a telecommunication system and comprising hardware 925 enabling it to communicate with the host computer 910 and with the UE 930. The hardware 925 may include a communication interface 926 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 900, as well as a radio interface 927 for setting up and maintaining at least a wireless connection 970 with a UE 930 located in a coverage area (not shown in Fig. 9) served by the base station 920. The communication interface 926 may be configured to facilitate a connection 960 to the host computer 910. The connection 960 may be direct or it may pass through a core network (not shown in Fig. 9) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 925 of the base station 920 further includes processing circuitry 928, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 920 further has software 921 stored internally or accessible via an external connection.

The communication system 900 further includes the UE 930 already referred to. Its hardware 935 may include a radio interface 912 configured to set up and maintain a wireless connection 970 with a base station serving a coverage area in which the UE 930 is currently located. The hardware 935 of the UE 930 further includes processing circuitry 938, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 930 further comprises software 931, which is stored in or accessible by the UE 930 and executable by the processing circuitry 938. The software 931 includes a client application 932. The client application 932 may be operable to provide a service to a human or non-human user via the UE 930, with the support of the host computer 910. In the host computer 910, an executing host application 912 may communicate with the executing client application 932 via the OTT connection 950 terminating at the UE 930 and the host computer 910. In providing the service to the user, the client application 932 may receive request data from the host application 912 and provide user data in response to the request data. The OTT connection 950 may transfer both the request data and the user data. The client application 932 may interact with the user to generate the user data that it provides.

It is noted that the host computer 910, base station 920 and UE 930 illustrated in Fig. 9 may be identical to the host computer 830, one of the

base stations

812a, 812b, 812c and one of the

UEs

891, 892 of Fig. 8, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 9 and independently, the surrounding network topology may be that of Fig. 8.

In Fig. 9, the OTT connection 950 has been drawn abstractly to illustrate the communication between the host computer 910 and the use equipment 930 via the base station 920, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 930 or from the service provider operating the host computer 910, or both. While the OTT connection 950 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network) .

The wireless connection 970 between the UE 930 and the base station 920 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 930 using the OTT connection 950, in which the wireless connection 970 forms the last segment. More precisely, the teachings of these embodiments may increase access rate due to support of RA procedure across cells/carriers to gain additional RA opportunities, and also due to improved cell configuration from indication of RA events. Thereby benefits such as reduced user waiting time and better responsiveness are provided.

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 950 between the host computer 910 and UE 930, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 950 may be implemented in the software 911 of the host computer 910 or in the software 931 of the UE 930, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 950 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which

software

911, 931 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 950 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 920, and it may be unknown or imperceptible to the base station 920. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 910 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the

software

911, 931 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 950 while it monitors propagation times, errors etc.

Fig. 10 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 8 and 9. For simplicity of the present disclosure, only drawing references to Fig. 10 will be included in this section. In a first step 1010 of the method, the host computer provides user data. In an optional substep 1011 of the first step 1010, the host computer provides the user data by executing a host application. In a second step 1020, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 1030, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 1040, the UE executes a client application associated with the host application executed by the host computer.

Fig. 11 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 8 and 9. For simplicity of the present disclosure, only drawing references to Fig. 11 will be included in this section. In a first step 1110 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 1120, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 1130, the UE receives the user data carried in the transmission.

Fig. 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 8 and 9. For simplicity of the present disclosure, only drawing references to Fig. 12 will be included in this section. In an optional first step 1210 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second step 1220, the UE provides user data. In an optional substep 1221 of the second step 1220, the UE provides the user data by executing a client application. In a further optional substep 1211 of the first step 1210, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third substep 1230, transmission of the user data to the host computer. In a fourth step 1240 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Fig. 13 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 8 and 9. For simplicity of the present disclosure, only drawing references to Fig. 13 will be included in this section. In an optional first step 1310 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 1320, the base station initiates transmission of the received user data to the host computer. In a third step 1330, the host computer receives the user data carried in the transmission initiated by the base station.

Some portions of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of transactions on data bits within a computer memory. These algorithmic descriptions and representations are ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of transactions leading to a desired result. The transactions are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be appreciated, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to actions and processes of a computer system, or a similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method transactions. The required structure for a variety of these systems will appear from the description above. In addition, embodiments of the present disclosure are not described with reference to any particular programming language. It should be appreciated that a variety of programming languages may be used to implement the teachings of embodiments of the present disclosure as described herein.

An embodiment of the present disclosure may be an article of manufacture in which a non-transitory machine-readable medium (such as microelectronic memory) has stored thereon instructions (e.g., computer code) which program one or more data processing components (generically referred to here as a “processor” ) to perform the operations described above. In other embodiments, some of these operations might be performed by specific hardware components that contain hardwired logic (e.g., dedicated digital filter blocks and state machines) . Those operations might alternatively be performed by any combination of programmed data processing components and fixed hardwired circuit components.

In the foregoing detailed description, embodiments of the present disclosure have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the spirit and scope of the present disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Throughout the description, some embodiments of the present disclosure have been presented through flow diagrams. It should be appreciated that the order of transactions and transactions described in these flow diagrams are only intended for illustrative purposes and not intended as a limitation of the present disclosure. One having ordinary skill in the art would recognize that variations can be made to the flow diagrams without departing from the spirit and scope of the present disclosure as set forth in the following claims.

Claims

A method (100) implemented by a terminal device, the method comprising:

receiving (101) a first multicast configuration from a network node via broadcast signaling;

performing (102) a first reception of multicast session data from the network node based on the first multicast configuration;

receiving (103) a second multicast configuration from the network node via terminal device specific radio resource control, RRC, signaling; and

switching (104) from the first reception to, a second reception of the multicast session data from the network node based on the second multicast configuration.
The method of claim 1, wherein multicast transmission in the first reception is the same as in the second reception, or

wherein the multicast session data in the first reception and in the second reception belong to the same or different multicast sessions.
The method of claim 1 or 2, wherein the first reception is performed before the terminal device is RRC configured.
The method of any of claims 1-3, wherein the broadcast signaling includes common configuration information for terminal devices to receive the same multicast transmission.
The method of claim 4, wherein the common configuration information includes configuration of a common frequency resource for multicast transmission to RRC CONNECTED terminal devices.
The method of claim 4 or 5, wherein the broadcast signaling includes at least one of: a system information block, SIB, and a multicast configuration channel, MCCH.
The method of claim 6, wherein the first reception is performed by:

detecting presence of the SIB;

decoding the SIB and the MCCH; and

receiving the multicast session data via the SIB and the MCCH.
The method of any of claims 1-7, wherein the broadcast signaling includes a group-common configuration.
The method of any of claims 1-8, wherein in the case that the terminal device is in an RRC INACTIVE state, the method further comprises:

in parallel with the first reception, performing random access to enter an RRC CONNECTED state.
The method of claim 9, further comprising:

transmitting an RRC resume request to the network node including a first indication which indicates that the terminal device is switching from the first reception to the second reception; and

receiving an RRC resume response from the network node including an RRC configuration for the switching.
The method of claim 10, wherein the first indication comprises a one-bit flag in the RRC resume request.
The method of claim 9, further comprising:

remaining in the RRC INACTIVE state in response to receiving a common multicast and broadcast configuration from the network node via a common control channel.
The method of claim 9, further comprising:

receiving a paging message from the network node including a second indication which indicates that a multicast and broadcast configuration is to be obtained from the network node; and

receiving the multicast and broadcast configuration from the network node while performing the random access.
The method of any of claims 9-13, further comprising:

decoding the received multicast session data in the RRC INACTIVE state.
A method (200) implemented by a network node, the method comprising:

transmitting (201) a first multicast configuration to one or more terminal devices via broadcast signaling;

performing (202) a first transmission of multicast session data to the one or more terminal devices based on the first multicast configuration;

transmitting (203) a second multicast configuration to the one or more terminal devices via terminal device specific radio resource control, RRC, signaling; and

performing (204) a second transmission of the multicast session data to the one or more terminal devices based on the second multicast configuration.
The method of claim 15, wherein multicast transmission in the first transmission is the same as in the second transmission, or

wherein the multicast session data in the first transmission and in the second transmission belong to the same or different multicast sessions.
The method of claim 15 or 16, wherein the first transmission is performed before the one or more terminal devices are RRC configured.
The method of any of claims 15-17, wherein the broadcast signaling includes common configuration information for the one or more terminal devices to receive the same multicast transmission.
The method of claim 18, wherein the common configuration information includes configuration of a common frequency resource for multicast transmission to RRC CONNECTED terminal devices.
The method of claim 18 or 19, wherein the broadcast signaling includes at least one of: a system information block, SIB, and a multicast configuration channel, MCCH.
The method of any of claims 15-20, wherein the broadcast signaling includes a group-common configuration.
The method of any of claims 15-21, further comprising:

receiving an RRC resume request from a terminal device which is in an RRC INACTIVE state, including a first indication which indicates that the terminal device is switching reception of the multicast session data based on the first multicast configuration to reception based on the second multicast configuration; and

transmitting an RRC resume response to the terminal device including an RRC configuration for the switching.
The method of claim 22, wherein the first indication comprises a one-bit flag in the RRC resume request.
The method of any of claims 15-21, further comprising:

broadcasting a common multicast and broadcast configuration to terminal devices which are in an RRC INACTIVE state via a common control channel after paging the terminal devices.
The method of any of claims 16-21, further comprising:

transmitting a paging message to a terminal device which is in an RRC INACTIVE state, including a second indication which indicates that a multicast and broadcast configuration is to be obtained by the terminal device; and

transmitting the multicast and broadcast configuration to the terminal device while the terminal device is performing the random access.
The method of any of claims 15-25, further comprising:

turning off the broadcast signaling in response to the one or more terminal devices being all RRC configured.
A terminal device (300) , comprising:

a processor (301) ; and

a memory (302) communicatively coupled to the processor and adapted to store instructions which, when executed by the processor, cause the terminal device to perform operations of the method of any of claims 1-14.
A network node (500) , comprising:

a processor (501) ; and

a memory (502) communicatively coupled to the processor and adapted to store instructions which, when executed by the processor, cause the network node to perform operations of the method of any of claims 15-26.
A wireless communication system (700) , comprising:

one or more terminal devices (701) of claim 27; and

a network node (702) of claim 28, communicating with at least the one or more terminal devices.
A non-transitory computer readable medium having a computer program stored thereon which, when executed by a set of one or more processors of a terminal device, causes the terminal device to perform operations of the method of any of claims 1-14.
A non-transitory computer readable medium having a computer program stored thereon which, when executed by a set of one or more processors of a network node, causes the network node to perform operations of the method of any of claims 15-26.