WO2023245567A1

WO2023245567A1 - Methods and apparatus of multicast services transmission and reception in rrc inactive or idle state

Info

Publication number: WO2023245567A1
Application number: PCT/CN2022/100882
Authority: WO
Inventors: Xuanbo SHAO; Xuelong Wang
Original assignee: Mediatek Singapore Pte. Ltd.
Priority date: 2022-06-23
Filing date: 2022-06-23
Publication date: 2023-12-28

Abstract

This disclosure describes methods and apparatus of multicast service transmission and reception in RRC INACTIVE/IDLE state, which can enhance the service coverage, better capacity utilization and decrease the power consumption. In one embodiment, the UE needs to report its assistance information for receiving the multicast service based on gNB requesting before the gNB wants to schedule the UE to receive the multicast service in RRC INACTIVE/IDLE state, which is used for gNB scheduling, or, the UE can autonomously report the corresponding assistance information to the gNB and request the gNB can configure the UE to receive the multicast service in RRC INACTIVE/IDLE state. The CFR used for the UE receiving the multicast service can be larger than active BWP or the subset of the active BWP or a separate frequency from active BWP or different with CFR configured in RRC CONNECTED. For better service continuity, the UE can receive the missed multicast service caused by the BWP/CFR switching from the RRC CONNECTED state to the RRC INACTIVE /IDLE state using the PTM scheme for all UEs receiving the multicast service, PTP scheme for dedicated UEs receiving the multicast service or subset PTM scheme for UEs only missed the multicast service, which is scheduled by the gNB.

Description

METHODS AND APPARATUS OF MULTICAST SERVICES TRANSMISSION AND RECEPTION IN RRC INACTIVE OR IDLE STATE

FIELD

The present invention relates generally to wireless communication systems, and more particularly, the method and apparatus of multicast services transmission and reception in RRC INACTIVE or RRC IDLE state.

BACKGROUND

With the rapid development of mobile communication system, the demand of multicast broadcast service (MBS) is emerging, e.g., popular media content, live stream, video distribution, vehicle-to-everything (V2X) communication, public safety (PS) communication and so on. In these cases, gNB can send a multicast or broadcast services to very larger number of UE consuming the same data, which can decrease the physical downlink control channel signalling overhead to some extent. MBS based on new radio (NR) is discussed in 3GPP Release 17 version. However, the current procedure design for the Rel-17 MBS multicast service only consider that it can be received by the UE in RRC CONNECTED state. For example, the common frequency resource (CFR) design for multicast reception is only defined within the UE’s dedicated active bandwidth part (BWP) in RRC CONNECTED state.

The increasing number of UEs interested with the multicast services only in RRC CONNECTED state will increase the network congestion, especially for the high data rate service. Besides, in order to enhance the services coverage, better capacity utilization and reduce the power consumption, it is beneficial for UE receiving the MBS multicast in RRC INACTIVE/IDLE state, e.g., some UEs with better channel condition can receive the same multicast service in RRC INACTIVE/IDLE state.

Considering that UEs have different UE processing capability, e.g., some UEs don’t support HARQ-ACK, multiple HARQ process, or larger CFR reception in RRC IDLE/INACTIVE state, however, these features are supported by the UEs in RRC CONNECTED state and the same multicast services are received by the UEs in RRC CONNECTED state and RRC IDLE/INACTIVE state. It is better that UE can report some assistance information for gNB scheduling based on gNB’s request or UE autonomous trigger, e.g., whether it can or want to receive the multicast in RRC INACTIVE/IDLE state to the gNB and so on. For example, if the UE has the capability and want to process the multicast reception in RRC IDLE/INACTIVE state, then the gNB can configure the UE to receive the multicast service in the RRC IDLE/INACTIVE state. Otherwise, the UE is not preferred to receive the multicast service in the RRC IDLE/INACTIVE sate, if gNB still want to the UE to receive the multicast service in RRC IDLE/INACTIVE sate, the CFR configuration or UE’s behaviour needs to be further adjusted to accommodate the multicast reception in RRC IDLE/INACTIVE state.

In current RRC CONNECTED multicast CFR design, the CFR is configured within the UE’s dedicated active BWP and all the UEs receiving the same multicast service share the same one CFR. However, if some UEs are switched to RRC IDLE/INACTIVE sate to receive the multicast service, the active BWP also needs to be switched to default BWP, e.g., SIB1 configured initial BWP. The corresponding issue is that whether the switched BWP can also cover the CFR for receiving the multicast services and the CFR parameter configured in the RRC CONNECTED state can also be supported by the UE in RRC INACTIVE/IDLE state, e.g., the HARQ-ACK operation, semi-static-scheduling, etc.

SUMMARY

The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

In an aspect of the disclosure, UE needs to report the multicast reception assistance information in RRC IDLE/INACTIVE state by gNB request before UE are switched to RRC IDLE/INACTIVE state to receive the multicast. The multicast scheduling in RRC CONNECTED state can support the HARQ-ACK feedback (e.g., ACK/NACK or NACK-only based HARQ feedback) , SPS, SCell and larger CFR (e.g., the CFR can be the same with UE dedicated BWP) , etc. However, whether UE can support these behaviors in RRC IDLE/INACTIVE state needs to be based on UE processing capability. For example, some UEs may not support the HARQ-ACK feedback or SPS in the RRC IDLE/INACTIVE state as the legacy UE cannot support theses behavior, or the maximum data rate and TB size processing is different for the UE in RRC CONNECTED state and RRC IDLE/INACTIVE state. Thus, if gNB wants the UE to receive the multicast in RRC IDLE/INACTIVE state, it needs to request the UE’s capability of multicast reception in RRC IDLE/INACTIVE firstly, e.g., via the signalling of UE multicast_INACTIVE/IDLE information request. And then UE needs to report its corresponding capability by UE multicast_INACTIVE/IDLE information response.

In another aspect of the disclosure, if the UE have the corresponding capability to receive the multicast service in RRC INACTIVE/IDLE state, the UE also can autonomously request to receive the multicast in RRC INACTIVE/IDLE state. When gNB receive the UE’s request, it can schedule the UE to receive the multicast in RRC INACTIVE/IDLE state via RRC configuration information, e.g., configurating the proper CFR parameter.

In another aspect of the disclosure, the CFR used for the multicast reception in RRC IDLE/INACTIVE state can be different the CFR configured by the multicast in RRC CONNECTED state or CFR parameter configured exceed to UE’s capability for multicast reception in RRC IDLE/INACTIVE state, the gNB needs to adjust the CFR configuration for the multicast reception for both RRC CONNECTED state and RRC INACTIVE/IDLE state, e.g., via RRC reconfiguration message, and UE needs to receive the multicast reception in the latest CFR configuration. e.g., the UE can receive the multicast service with larger CFR or even the CFR is not confined within the initial BWP or CORESET#0 in the RRC IDLE/INACTIVE state. If the CFR configured by gNB are separate with default BWP for the UE receiving the multicast in RRC INACTIVE/IDLE state, the UE needs to keep a larger RF chain to cover the default BWP and CFR or the UE switch the default BWP and CFR back and forth for receiving the legacy SIB/paging and multicast in RRC INACTIVE/IDLE state.

In another aspect of the disclosure, the gNB needs to retransmit the missed services due to the RRC (re) configuration for the UEs switched RRC INACTIVE/IDLE state, the retransmission can be PTM (point-to-multipoint) scheme for all UEs receiving the multicast, or the PTP (point-to-point) scheme for dedicated UEs, or subset of PTM scheme for only a group UEs switched from RRC CONNECTED state to RRC INACTIVE/IDLE state. The UE, especially for the switched UE, can receive the retransmitted services based on the gNB configuration and keep the better service continuity.

To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed figures set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 (a) is a schematic system diagram illustrating an exemplary Base Station (i.e. BS) , in accordance with certain aspects of the present disclosure.

FIG. 1 (b) is a schematic system diagram illustrating an exemplary UE, in accordance with certain aspects of the present disclosure.

FIG. 2 illustrates an exemplary NR wireless communication system, in accordance with certain aspects of the present disclosure.

FIG. 3 (a) illustrates an exemplary procedure between the Network and UE information exchange for UE receiving the multicast services in RRC INACTIVE/IDLE state, in accordance with certain aspects of the present disclosure.

FIG. 3 (b) illustrates an exemplary procedure than UE autonomous request to receive the multicast services in RRC INACTIVE/IDLE state, in accordance with certain aspects of the present disclosure.

FIG. 3 (c) illustrates an exemplary flow chart on how/whether does the UE to receive the multicast in RRC INACTIVE/IDLE state, in accordance with certain aspects of the present disclosure.

FIG. 4 (a) illustrates an exemplary diagram that the MBS multicast CFR design for the RRC CONNECTED UEs receiving the same multicast services, in accordance with certain aspects of the present disclosure.

FIG. 4 (b) illustrates an exemplary diagram that UE3 are switched to RRC INACTIVE/IDLE sate to receive the MBS multicast service, however, the switched BWP does not contain the legacy CFR range, in accordance with certain aspects of the present disclosure.

FIG. 4 (c) illustrates an exemplary diagram that the service interruption retransmission scheme for the UEs is switched into RRC INACTIVE/IDLE state, in accordance with certain aspects of the present disclosure.

FIG. 5 illustrates an exemplary diagram that UE’s switched BWP from RRC CONNECTED state to RRC INACTIVE/IDLE state also contain the multicast CFR range configured in RRC CONNECTED state, and the UE can receive the multicast service in the same CFR in RRC INACTIVE/IDLE state, in accordance with certain aspects of the present disclosure.

FIG. 6 illustrates an exemplary diagram that UE’s switched BWP from RRC CONNECTED state to RRC INACTIVE/IDLE state is a subset of the multicast CFR range configured in RRC CONNECTED state, and the UE can receive the multicast service in a new CFR range in RRC INACTIVE/IDLE state, in accordance with certain aspects of the present disclosure.

FIG. 7 illustrates an exemplary diagram that UE’s switched BWP from RRC CONNECTED state to RRC INACTIVE/IDLE state is a subset of the multicast CFR range configured in RRC CONNECTED state, and the UE still can receive the multicast service in the same CFR range in RRC INACTIVE/IDLE state, in accordance with certain aspects of the present disclosure.

FIG. 8 illustrates an exemplary diagram that UE’s switched BWP from RRC CONNECTED state to RRC INACTIVE/IDLE state does not have the relationship with multicast CFR range configured in RRC CONNECTED state, and the UE can receive the multicast service in the same CFR range in RRC INACTIVE/IDLE state and receive the legacy information (e.g., paging, SI information) in the switched BWP with different RF chain or the same RF chain with different rang in the different time, in accordance with certain aspects of the present disclosure.

FIG. 9 illustrates an exemplary diagram that UE’s switched BWP from RRC CONNECTED state to RRC INACTIVE/IDLE state does not have the relationship with multicast CFR range configured in RRC CONNECTED state, and the UE can receive the multicast service in the same CFR range in RRC INACTIVE/IDLE state and receive the legacy information (e.g., paging, SI information) in the switched BWP simultaneously with a single RF chain, in accordance with certain aspects of the present disclosure.

DETAILED DESCRIPTION

The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

Several aspects of telecommunication systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

Aspects of the present disclosure provide methods, apparatus, processing systems, and computer readable mediums for NR (new radio access technology, or 5G technology) or other radio access technology. NR may support various wireless communication services. These services may have different quality of service (QoS) requirements e.g. latency, connected density and reliability requirements. Figure 1 (a) is a schematic system diagram illustrating an exemplary Base Station (i.e. BS) . The BS may also be referred to as an access point, an access terminal, a base station, a Node-B, an eNode-B, a gNB, or by other terminology used in the art. As an example, base stations serve a number of mobile stations within a serving area, for example, a cell, or within a cell sector. The Base Station has an antenna, which transmits and receives radio signals. A RF transceiver, coupled with the antenna, receives RF signals from antenna, converts them to baseband signals, and sends them to processor. RF transceiver also converts received baseband signals from processor, converts them to RF signals, and sends out to antenna. Processor processes the received baseband signals and invokes different functions. Memory stores program instructions and data to control the operations of Base Station. Figure 1 (b) is a schematic system diagram illustrating an exemplary UE. The UE may also be referred to as a mobile station, a mobile terminal, a mobile phone, smart phone, wearable, an IoT device, a table let, a laptop, or other terminology used in the art. UE has an antenna, which transmits and receives radio signals. A RF transceiver, coupled with the antenna, receives RF signals from antenna, converts them to baseband signal, and sends them to processor. RF transceiver also converts received baseband signals from processor, converts them to RF signals, and sends out to antenna. Processor processes the received baseband signals and invokes different functional modules to perform features in UE. Memory stores program instructions and data to control the operations of mobile station. Figure 2 illustrates an exemplary NR wireless communication system. Different protocol split options between Central Unit and Distributed Unit of gNB nodes may be possible. In one embodiment, SDAP and PDCP layer are located in the central unit, while RLC, MAC and PHY layers are located in the distributed unit.

The described invention operates in the context of multicast services transmission in a cellular system. In certain systems, such as NR systems, NR multicast service is transmitted in the coverage or some dedicated group of a cell. In current design, the multicast service only can be received by the UE in the RRC CONNECTED state, which will increase the network congestion, especially for the high data rate service packet for an increasing number of UEs interested with the multicast service. Besides, in order to enhance the services coverage, better capacity utilization and reduce the UE power consumption, it is beneficial for UE receiving the MBS multicast in RRC INACTIVE/IDLE state.

In this disclosure, some UEs can receive the multicast service in RRC IDLE/INACTIVE state by gNB scheduling (e.g., RRC configuration) , e.g., the UE with better channel condition. No matter whether the multicast services can be received by the UEs in the RRC CONNECTED state or in the RRC INACTIVE/IDLE state, the same frequency resource utilization (e.g., CFR range) is reasonable for the UEs receiving the same multicast, otherwise, it will degrade the multicast frequency resource utilization efficiency.

In this disclosure, gNB needs to request some assistance information before it want to configure the UE to receive the multicast in RRC INACTIVE/IDLE state, e.g., whether the UE wants to receive the multicast in RRC INACITVE/IDLE state, whether the UE can support HARQ-ACK feedback, which CFR configuration information does the UE prefer, etc. The UE needs to report the corresponding assistance information for the gNB further schedule. As an exemplary described in Figure 3 (a) , if gNB want to switch the UE into RRC INACTIVE/IDLE state, it needs to request the UE that whether the UE can receive the multicast and corresponding assistance information firstly, e.g., via the signalling UE multicast_INACTIVE/IDLE information request, then the UE will response the enquiry, e.g., via the signalling UE multicast_INACTIVE/IDLE information response. UE can response to gNB based on UE defined capability or the UE’s current reception status, e.g., even if the UE has the capability to receive the multicast in RRC INACTIVE/IDLE state, the UE has the bad channel condition and sent NACK with high probability due to staying in cell edge, it is also not preferred to be switched into RRC INACTIVE state to receive the multicast, or the UE can report to support multicast reception in RRC IDLE/INACTIVE state, however, HARQ-ACK feedback or SPS is not supported. Then the gNB needs to further confirm whether the UE can be switched into RRC INACTIVE/IDLE state to receive the multicast service based on UE’s response information.

In this disclosure, the UE can autonomously send the request information and assistance information to gNB that it wants to receive the multicast in RRC INACTIVE/IDLE state without gNB request the corresponding information. Then, the gNB can schedule the UE to receive the multicast service in RRC INACTIVE/IDLE state via RRC (re) configuration information. As an exemplary as illustrated in Figure 3(b) , considering the larger power consumption or heavy singling overhead in RRC CONNECTED mode, the UE can autonomously send a request to the gNB that the UE want to receive the multicast service in RRC INACTIVE/IDLE state and corresponding assistance information for gNB scheduling, e.g., the UE preferred parameter for receiving multicast in RRC INACTIVE/IDLE state.

Besides, considering the multicast session can be started or not started after the UE has joined the multicast session, the UE’s assistance information can be more helpful for the gNB’s scheduling, especially for the multicast session not started. For example, in Figure 4 (b) , when the multicast session has been started, if the configured parameters for receiving the multicast exceed the UE’s capability to receive the multicast in RRC INACTIVE/IDLE state, the UE is not preferred to be switched into RRC INACTIVE/IDLE state to receive the multicast session, and if the gNB scheduling mechanism does not exceed the UE’s capability and the UE want to receive the multicast in RRC INACTIVE/IDLE state, the gNB can schedule the UE into RRC INACTIVE/IDLE state to receive the multicast, e.g., via RRC (re) configure information. Another case is that the multicast session has not been started before the gNB want to schedule some UEs to receive the multicast service in the RRC INACTIVE/IDLE state or the UE autonomously request to receive the multicast in RRC INACTIVE/IDLE state, the gNB needs to follow the minimal capability between UEs in RRC CONNECTED state and UEs in RRC INACTIVE/IDLE state to configure the parameter for receiving the multicast services.

In the current multicast design, the CFR is defined to instruct the UE where and how to receive the multicast services, e.g., the frequency resource size, PDCCH/PDSCH parameter, etc, and the CFR range is defined within the UE’s dedicated active BWP, and all the UEs receiving the multicast service share the same CFR in the RRC CONNECTED state. An example as illustrated in Figure 4 (a) , the UE1, UE2 and UE 3 have its dedicated active BWP for the legacy unicast services reception, the three UEs have one common frequency resource (CFR) for multicast reception and the CFR is a common subset of the three UE’s dedicated BWP. However, if UE is switched to RRC INACTIVE/INLE state from the RRC CONNECTED state, the UE’s active dedicated are also needs to be switched to the default BWP, e.g., the SIB1 configured initial BWP, which may not conation the CFR for receiving the multicast. As the illustrated in the Figure 4 (b) , the UE3 is switched to the RRC INACTIVE/IDLE state, and the corresponding BWP configured for UE3 is also switched to the default BWP, e.g., the SIB1 configured initial DL BWP. The default BWP may contain or not contain the CFR configured for the multicast reception in RRC CONNECTED state. In this disclosure, the UE3 with some enhancement operation, e.g., defining a new receiving behavior with larger RF receiving, can receive the multicast in RRC INACTIVE/IDLE state even if the default BWP does not contain the CFR for multicast reception.

In this disclosure, the gNB needs to retransmit the UE missed multicast service since the BWP/CFR switching will cause the service interruption. The retransmission scheme can be PTM (point to multipoint) scheme for all UEs receiving multicast service or PTP (point to point) scheme for dedicated UEs missed multicast services or subset PTM scheme for only for a group UEs missed multicast services due to the service interruption. As an exemplary in Figure 4 (c) , 10 UEs are receiving the multicast in RRC CONNECTED mode, then gNB configure some UEs, e.g. UE1, UE2, UE5 and UE9, to receive the multicast services in RRC INACTIVE/IDLE state. When the UE1, UE2, UE5 and UE9 are switched into the RRC INACTIVE/IDLE state, the BWP/CFR switching will occur and will cause the multicast service interruption for these UEs. In order to keep the better service continuity, the gNB needs to retransmit these interrupted services using PTM, PTP or subset PTM scheme. At the receiver, the UE will receive the missed multicast services in RRC INACTIVE/IDLE state.

In this disclosure, the default BWP, e.g., SIB1 configured initial BWP, configured for the UE in the RRC INACTIVE/IDLE state can contain the CFR range for the multicast reception. If the multicast session has not started, the UE switched into the RRC INACTIVE/IDLE state can directly receive the multicast service after the gNB send some notification information, e.g., paging information, to notify the UE to receive the multicast in the configured CFR. If the multicast session has been started before the UE enter the RRC INACTIVE/IDLE state, the switching BWP may cause the service interruption due to the corresponding CFR switching, e.g, CFR reconfiguration associated with the BWP reconfiguration, which will cause the service loss.

The one alternative is that the gNB needs to retransmit the missed service to the UEs switched into the RRC INACTIVE/IDLE state. For example, the retransmission can be performed with the point to multiple (PTM) scheme using the same G-RNTI in initial transmission, point to point (PTP) scheme with C-RNTI or the sub-set of PTM scheme, e.g., the PTM retransmission is only used for the switched UEs with a different G-NRTI used in RRC INACTIVE/IDLE state. Another alternative is that the UE at least open the same RF chain with the CFR range even if the dedicated BWP are switched into the default BWP containing the CFR range as the same parameter are used for the multicast service reception no matter which RRC state is in, which means that the UE still can receive the multicast service when the BWP switching occurs.

Figure 5 illustrates an exemplary diagram with the switched BWP, e.g., the SIB1 configured initial BWP contain the CFR for multicast reception. In the RRC CONNECTED state, the UE1 and UE2 share the same CFR for multicast reception in the period of [t1, t2] , after the t2, the UE1 is switched into the RRC INACTIVE/IDLE state by the gNB scheduling, e.g., via the RRC release, and the switched BWP, e.g., the SIB1-configured initial BWP, still contain the CFR range. In order to improve the multicast quality caused by the multicast service interruption for the RRC INACTIVE/IDLE UEs due to BWP switching, the gNB needs to retransmit the missed service by the PTM, PTP or sub-set PTM scheme for the UEs switched into RRC INACTIE/IDLE state. At the receiver, the UE 1 needs to use the G-RNTI used for the CONNECTED mode transmission or the G-RNTI defined for the missed service or the UE dedicated C-RNTI to receive the missed retransmission service due to service interruption. Alternatively, the UE1 always keep at least the RF can receive the CFR range even if the BWP switching occurs as the same CFR parameter is used for the UEs receiving the multicast service.

In this disclosure, the default BWP, e.g., SIB1 configured initial BWP, configured for the UE in the RRC INACTIVE/IDLE state can be a subset of the CFR range for the multicast reception, which means that if it follows the legacy CFR rule, e.g., the CFR is confined within the UE’s dedicated BWP, the CFR needs to be adjusted or defining a new UE behavior, e.g., the UE can receive the multicast service with larger CFR, e.g., the CFR is larger than the active BWP.

If the multicast session has not started, the gNB can adjust the CFR parameter for all the UEs receiving the multicast services, e.g., the configuring a new smaller CFR confined with in the minimal active BWP. Or, if the multicast session has been started before the UE enters the RRC INACTIVE/IDLE state and UE only can receive the multicast in the CFR within the dedicated BWP, the gNB needs to (re) configure a smaller CFR for both the RRC CONNECTED UE and RRC INACTIVE/IDLE UEs. At the receiver, the UE needs to receive the multicast services based on the latest configuration parameter, e.g., using the smaller CFR to receive the multicast service due to considering the RRC INACTIVE/IDLE UE’s capability.

As an exemplary in Figure 6, the switched BWP, e.g., the SIB1 configured initial BWP, for the RRC INACTIVE/IDLE UEs is a subset of the configured CFR for multicast reception. In the RRC CONNECTED state, the UE1 and UE2 share the same CFR for multicast reception in the period of [t1, t2] , after the t2, the UE1 is switched into the RRC INACTIVE/IDLE state by the gNB scheduling, e.g., via the RRC (re) configuration information, and the switched BWP, e.g., the SIB1-configured initial BWP, is a subset of the CFR range. The gNB needs to (re) configure the CFR parameter for multicast reception for UE1 and UE2. Then, after t2, UE1 and UE 2 use the (re) configured CFR parameter for the multicast reception.

If the multicast session has been started before the UE enters the RRC INACTIVE/IDLE state and UE can receive the multicast service in a larger CFR, e.g., the CFR for multicast reception can be larger than the UE’s dedicated BWP. At the receiver, the UE needs to receive the multicast services using the same CFR as configured in the RRC CONNECTED state. However, the BWP switching may cause the service interruption due to the corresponding CFR switching, e.g., CFR reconfiguration associated with the BWP reconfiguration, which will cause the service loss. The similar mechanism as mentioned above can be used for this case, e.g., the gNB retransmission scheme with (subset) PTM with G-RNTI and PTP with C-RNTI or the UE at least open the same RF chain with the CFR range in the switching period.

As an exemplary in Figure 7, the switched BWP, e.g., the SIB1 configured initial BWP, for the RRC INACTIVE/IDLE UEs is a subset of the configured CFR for multicast reception. In the RRC CONNECTED state, the UE1 and UE2 share the same CFR for multicast reception in the period of [t1, t2] , after the t2, the UE1 is switched into the RRC INACTIVE/IDLE state by the gNB scheduling, e.g., via the RRC (re) configuration information, and the switched BWP, e.g., the SIB1-configured initial BWP, is a subset of the CFR range. The UE 1 can still use the legacy CFR for multicast reception in RRC INACTIVE/IDLE state. In order to improve the multicast quality caused by the multicast service interruption for the RRC INACTIVE/IDLE UEs due to BWP switching, the gNB needs to retransmit the missed service by the PTM, PTP or sub-set PTM scheme for the UEs switched into RRC INACTIE/IDLE state. At the receiver, the UE 1 needs to use the G-RNTI used for the CONNECTED mode transmission or the G-RNTI defined for the missed service or the UE dedicated C-RNTI to receive the missed retransmission service due to service interruption. Alternatively, the UE1 always keep at least the RF can receive the CFR range even if the BWP switching occurs as the same CFR parameter is used for the UEs receiving the multicast service.

In this disclosure, the default BWP, e.g., SIB1 configured initial BWP, configured for the UE in the RRC INACTIVE/IDLE state can be the different frequency range with CFR range for the multicast reception, which means that the CFR and active BWP can be two separate frequency resources. The legacy definition for the CFR will be not work for the case. A new behavior is needed for the UE to continue receiving the multicast service in RRC INACTIVE/IDLE state, e.g., the UE needs to keep one larger RF chain to cover both the CFR and active BWP, or UE perform CFR/BWP switching back and forth for receiving the multicast services and legacy SIB1 or paging service in RRC INACTIVE/IDLE state. If the multicast session has not been started before the UE enters the RRC INACTIVE/IDLE state, the UE needs to follow the RRC (re) configuration parameter to receive the multicast services after gNB send some notification information, e.g., paging information, to notifying the UE to receive the multicast information. If the multicast session has been started, the BWP switching may cause the service interruption due to the corresponding CFR switching, e.g., CFR reconfiguration associated with the BWP reconfiguration, which will cause the service loss. The similar mechanism as mentioned above can be used for this case, e.g., the gNB retransmission scheme with (subset) PTM with G-RNTI and PTP with C-RNTI or the UE at least still open the same RF chain with the CFR range in the switching period.

Figure 8 illustrates an exemplary diagram with the switched BWP, e.g., the SIB1 configured initial BWP, does not have relationship with the CFR for receiving the multicast, and the UE will perform CFR/BWP switching back and forth for receiving the multicast services within the CFR and legacy unicast service, e.g., SIB/Paging information, in the switch BWP. In the RRC CONNECTED state, the UE1 and UE2 share the same CFR for multicast reception in the period of [t1, t2] , after the t2, the UE1 is switched into the RRC INACTIVE/IDLE state by the gNB scheduling, e.g., via the RRC release, and the switched BWP has no relationship with the CFR, and the UE1 does not can use a larger RF chain to receive the CFR and active BWP simultaneously, e.g., the frequency gap between the CFR and active BWP is very larger, the UE1 needs to switch the CFR and BWP back and forth for receiving the multicast services, e.g., in some time slot, the UE1 receive the multicast service in CFR, and in another time slot, the UE2 switch its RF chain to active BWP and receive the legacy unicast service, e.g., SIB or paging information. In order to improve the multicast service loss caused by the multicast service interruption for the RRC INACTIVE/IDLE UEs due to BWP switching from the RRC CONNECTED state to the RRC INACTIVE/IDLE state, the gNB needs to retransmit the missed service by the PTM, PTP or sub-set PTM scheme for the UEs switched into RRC INACTIE/IDLE state. At the receiver, the UE 1 needs to use the G-RNTI used for the CONNECTED mode transmission or the G-RNTI defined for the missed service or the UE dedicated C-RNTI to receive the missed retransmission service due to service interruption. Alternatively, the UE1 always keep at least the RF can receive the CFR range as the same with CFR parameter is used for the UEs receiving the multicast service in RRC CONNECTED mode.

Figure 9 illustrates an exemplary diagram with the switched BWP, e.g., the SIB1 configured initial BWP, does not have relationship with the CFR for receiving the multicast, and the UE will use a larger RF chain for receiving the multicast services within the CFR and legacy unicast service, e.g., SIB/Paging information, in the switch BWP. In the RRC CONNECTED state, the UE1 and UE2 share the same CFR for multicast reception in the period of [t1, t2] , after the t2, the UE1 is switched into the RRC INACTIVE/IDLE state by the gNB scheduling, e.g., via the RRC release, and the switched BWP has no relationship with the CFR, the UE1 use a larger RF chain to receive the multicast services in CFR and the legacy unicast service, e.g., SIB or paging information. In order to improve the multicast service loss caused by the multicast service interruption for the RRC INACTIVE/IDLE UEs due to BWP switching from the RRC CONNECTED state to the RRC INACTIVE/IDLE state, the gNB needs to retransmit the missed service by the PTM, PTP or sub-set PTM scheme for the UEs switched into RRC INACTIE/IDLE state. At the receiver, the UE 1 needs to use the G-RNTI used for the CONNECTED mode transmission or the G-RNTI defined for the missed service or the UE dedicated C-RNTI to receive the missed retransmission service due to service interruption. Alternatively, the UE1 always keep at least the RF can receive the CFR range even if the BWP switching occurs as the same CFR parameter is used for the UEs receiving the multicast service.

It is understood that the specific order or hierarchy of blocks in the processes /flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes /flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for. ”

While aspects of the present disclosure have been described in conjunction with the specific embodiments thereof that are proposed as examples, alternatives, modifications, and variations to the examples may be made. Accordingly, embodiments as set forth herein are intended to be illustrative and not limiting. There are changes that may be made without departing from the scope of the claims set forth below.

Claims

A method of wireless communication comprising:

Multicast service transmission from gNB to the UE in the RRC INACTIVE/IDLE state;

Multicast service reception for the UEs in RRC INACTIVE/IDLE state.
The method of claim 1, wherein the gNB shall request the UE’s assistance information before the UE is configured to receive multicast service in RRC INACTIVE/IDLE state.
The method of claim 1, wherein the gNB shall retransmit the missed multicast service packet caused by BWP switching via PTM (point to multipoint) scheme for all UEs receiving the multicast service or PTP (point to point) are dedicated UE receiving multicast or a subset PTM scheme for UEs only missed the multicast service.
The method of claim 1, wherein the gNB shall (re) configure the multicast reception parameter based on UE’s reporting assistance information for receiving multicast in RRC INACTIVE/IDLE state.
The method of claim 1, wherein the UE needs to report the assistance information for receiving the multicast in RRC INACTIVE/IDLE state based on gNB request or the UE autonomously report the corresponding without gNB request.
The method of claim 1, wherein the UE needs to continue performing the multicast service reception on RRC INACTIVE/IDLE state with the CFR and the CFR can be within or not be within the switched BWP.
The method of claim 4, wherein the gNB will (re) configure the CFR information based on the UE’s reporting assistance information and whether the multicast session start or not start.
The method of claim 5, wherein the UE needs report whether it can receive the multicast service or whether it want to receive the multicast service in RRC INACTIVE/IDLE state.
The method of claim 5, wherein the UE needs to report whether it can support HARQ-ACK or SPS for multicast reception in RRC INACTIVE/IDLE state.
The method of claim 5, wherein the UE needs to report whether it can use larger CFR or different CFR configured in RRC CONNECTED state for multicast reception in RRC INACTIVE/IDLE state.
The method of claim 6, wherein the RRC INACTIVE/IDLE UE needs to receive the missed service due to service interruption using PTM scheme or PTP scheme or subset PTM scheme.
The method of claim 6, wherein the RRC INACTIVE/IDLE UE can perform the multicast reception in the same CFR configured in the RRC CONNECTED state if the switched BWP contain the CFR.
The method of claim 6, wherein both RRC CONNECTED UE and RRC INACTIVE/IDLE UE can perform the multicast reception in the new smaller CFR if the previous CFR configured in RRC CONNECTED state contain the switched BWP.
The method of claim 6, wherein the RRC INACTIVE/IDLE UE can perform the multicast reception in the previous CFR even if the previous CFR configured in RRC CONNECTED state contain the switched BWP.
The method of claim 6, wherein the RRC INACTIVE/IDLE UE can perform the multicast reception in the previous CFR via CFR/switched BWP switching back and forth even if the previous CFR configured in RRC CONNECTED state has no relationship with switched BWP.
The method of claim 6, wherein the RRC INACTIVE/IDLE UE can perform the multicast reception with a single RF chain to cover both the CFR and switched BWP if the previous CFR configured in RRC CONNECTED state has no relationship with switched BWP.