Handling of group paging message for multicast broadcast service in a wireless communication system

Abstract

The disclosure relates to a method and user equipment (UE) for handling of paging message for multicast broadcast service (MBS) in a wireless communication system. The method includes for handling paging messages for receiving MBS in a wireless communication system. The method includes receiving, by a (UE), a paging message; determining whether the UE is notified to stop monitoring group radio network temporary identifiers (G-RNTIs) for all joined multicast sessions in a radio resource control (RRC) inactive state; and acquiring multicast MBS control channel (MCCH) information, wherein the UE was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by at least one temporary mobile group identities (TMGI) included in a paging group list for which point-to-multipoint (PTM) configuration was not included in a RRC release message.

Description

HANDLING OF GROUP PAGING MESSAGE FOR MULTICAST BROADCAST SERVICE IN A WIRELESS COMMUNICATION SYSTEM

[0001] The disclosure relates to wireless communication systems. More particulary, the disclosure relates to a method and user equipment (UE) for managing group paging messages associated with multicast broadcast service (MBS) within a wireless network.

[0002] In wireless communication, new radio multicast and broadcast services (NR MBS) refers to services that deliver common content to multiple user equipments (UEs) within a specified coverage area. These services can be categorized into multicast services, targeting a group of UEs that have subscribed to the multicast content, and broadcast services, which target all UEs within the broadcast coverage area. The coverage area can range from a single radio cell to a larger region.

[0003] In legacy systems, such as the 3GPP Release 17 MBS, multicast session activation for UEs in the radio resource control (RRC)_IDLE or RRC_INACTIVE states is typically managed through group notification or group paging mechanisms. Upon receiving a paging message, the UE transitions to the RRC_CONNECTED state to start receiving the multicast session. However, advancements in 3GPP Release 18 MBS have introduced scenarios where multicast sessions can be received by UEs in the RRC_INACTIVE state, aiming to extend service delivery and enhance network capacity to accommodate a larger number of UEs.

[0004] Despite these advancements, several issues have been identified in existing standards, regarding the handling of group paging for multicast sessions in the RRC_INACTIVE state. One major issue arises when UEs receive group paging messages and are not notified to stop monitoring the group radio network temporary identifier (G-RNTI) for all joined multicast sessions configured for reception in the RRC_INACTIVE state. The condition to acquire multicast MBS control channel (MCCH) is ambiguously stated as requiring the UE to stop monitoring the G-RNTI for any session for which point-to-multipoint (PTM) configuration was not included in the RRCRelease message.

[0005] This condition is problematic for several reasons:

[0006] 1. The multicast session may not be included in the group paging message.

[0007] 2. The multicast session may have already been activated, as the condition refers solely to the RRCRelease message, while the session may have been activated in a previous group paging and received PTM configuration in the multicast MCCH.

[0008] As a result, improper handling of group paging messages by UEs configured to receive multicast in the RRC_INACTIVE state can occur. Specifically, UEs may fail to acquire the multicast MCCH to receive PTM configuration, leading to loss or degradation of service reception.

[0009] Further, another issue arises when UEs remain in the RRC_INACTIVE state upon receiving group paging indicating multicast session activation. If UEs are notified to stop monitoring the G-RNTI for at least one multicast session for which PTM configuration was not included in the RRCRelease message, they need to acquire the multicast MCCH. In cases where PTM configuration for some sessions was provided by the RRCRelease and is already stored, UEs should first apply the PTM configuration for these sessions before acquiring the multicast MCCH for other sessions.

[0010] These issues highlight the need for improvements in the handling of group paging for multicast sessions in the RRC_INACTIVE state to ensure proper service reception and network efficiency.

[0011] The above information is presented as background information only to assist with an understanding of the disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the disclosure.

[0012] Aspects of the disclosure are to address at least the above-mentioned problems and / or disadvantages and to provide at least the advantages described below. The disclosure provides a method and an apparatus for handling group paging messages for MBS in a wireless network.

[0013] The disclosure provides a method for handling group paging messages for receiving MBS in a wireless communication system.

[0014] The disclosure provides a UE for handling group paging messages in a wireless communication system.

[0015] The disclosure provides group notification approach that enable multicast reception in RRC_INACTIVE.

[0016] The disclosure provides a UE and a network where multicast data reception performance will gain significantly.

[0017] The disclosure provides a method to determine the condition for multicast MCCH acquisition upon group paging reception, a method to utilize stored PTM configuration upon group paging reception, and a method to determine the timing of the multicast MCCH acquisition upon group paging reception.

[0018] In an embodiment, a method for handling paging messages for receiving multicast and broadcast service (MBS) by the UE in a wireless communication system is provided. The method includes receiving a paging message, determining whether the UE is notified to stop monitoring group radio network temporary identifiers (G-RNTIs) for all joined multicast sessions configured for reception in a radio resource control (RRC) inactive state, and acquiring multicast MBS control channel (MCCH) information, wherein the UE was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by at least one temporary mobile group identity (TMGI) included in a paging group list for which point-to-multipoint (PTM) configuration was not included in an RRC release message.

[0019] In an embodiment, a UE for handling paging messages for receiving multicast and broadcast service (MBS) in a wireless communication system comprising memory storing instructions and at least one processor operably coupled to the memory is provided. The instructions, when executed by the processor individually or collectively, cause the UE to receive a paging message, determine whether the UE is notified to stop monitoring group radio network temporary identifiers (G-RNTIs) for all joined multicast sessions configured for reception in a radio resource control (RRC) inactive state, and acquire multicast MBS control channel (MCCH) information, wherein the UE (100) was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by at least one temporary mobile group identity (TMGI) included in a paging group list for which point-to-multipoint (PTM) configuration was not included in an RRC release message.

[0020] In an embodiment, one or more non-transitory computer-readable storage media storing one or more computer programs including computer-executable instructions that, when executed by one or more processors of a user equipment (UE) individually or collectively, cause the location management server to perform operations is provided. The operations comprises receiving a paging message, determining whether the UE is notified to stop monitoring group radio network temporary identifiers (G-RNTIs) for all joined multicast sessions configured for reception in a radio resource control (RRC) inactive state, and acquiring multicast MBS control channel (MCCH) information, wherein the UE was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by at least one temporary mobile group identity (TMGI) included in a paging group list for which point-to-multipoint (PTM) configuration was not included in an RRC release message.

[0021] Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses various embodiments of the disclosure.

[0022] The above and other aspects, features, and advantages of certain embodiments of the disclosure will be more apparent from the following description taken in conjunction with the accompanying drawings, in which:

[0023] FIG. 1 is a block diagram of a UE for handling a group paging message for multicast broadcast service in a wireless communication system according to an embodiment of the disclosure.

[0024] FIG. 2 is a flow chart that illustrates a method for handling a group paging message for receiving multicast and broadcast service (MBS) in a wireless communication system according to an embodiment of the disclosure.

[0025] FIG. 3 is an operational flow diagram that illustrates a method for handling a group paging message by a UE in RRC_INACTIVE state according to an embodiment of the disclosure.

[0026] FIG. 4 is an operational flow diagram that illustrates a method for checking the availability of the stored PTM configuration (e.g., received via RRCRelease) before acquiring multicast MCCH according to an embodiment of the disclosure.

[0027] FIG. 5 is an operational flow diagram that illustrates a method for a group paging and multicast MCCH acquisition, network to ensure the multicast MCCH is updated with PTM configuration immediately after or in parallel with the group paging broadcasting according to an embodiment of the disclosure.

[0028] FIG. 6 is a flow chart that illustrates a use case 1 for receiving group paging and continuing a multicast session according to an embodiment of the disclosure.

[0029] FIG. 7 is a flow chart that illustrates a use case 2 for utilizing stored PTM configuration information when available according to an embodiment of the disclosure.

[0030] Throughout the drawings, it should be noted that like reference numbers are used to depict the same or similar elements, features, and structures.

[0031] The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the disclosure as defined by the claims and their equivalents. It includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope and spirit of the disclosure. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

[0032] The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the disclosure. Accordingly, it should be apparent to those skilled in the art that the following description of various embodiments of the disclosure is provided for illustration purpose only and not for the purpose of limiting the disclosure as defined by the appended claims and their equivalents.

[0033] It is to be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a component surface" includes reference to one or more of such surfaces.

[0034] As is traditional in the field, embodiments are described and illustrated in terms of blocks that carry out a described function or functions.　These blocks, which referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and / or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits and the like, and optionally be driven by firmware and software. The circuits, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.　The circuits constituting a block be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments be physically separated into two or more interacting and discrete blocks without departing from the scope of the proposed method.　Likewise, the blocks of the embodiments be physically combined into more complex blocks without departing from the scope of the proposed method.

[0035] FIGS. 1 through 7, discussed below, and the various embodiments used to describe the principles of the disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the disclosure may be implemented in any suitably arranged system or device.

[0036] It should be appreciated that the blocks in each flowchart and combinations of the flowcharts may be performed by one or more computer programs which include instructions. The entirety of the one or more computer programs may be stored in a single memory device or the one or more computer programs may be divided with different portions stored in different multiple memory devices.

[0037] Any of the functions or operations described herein can be processed by one processor or a combination of processors. The one processor or the combination of processors is circuitry performing processing and may include circuitry like an application processor (AP, e.g. a central processing unit (CPU)), a communication processor (CP, e.g., a modem), a graphics processing unit (GPU), a neural processing unit (NPU) (e.g., an artificial intelligence (AI) chip), a wireless fidelity (Wi-Fi) chip, a Bluetooth®chip, a global positioning system (GPS) chip, a near field communication (NFC) chip, connectivity chips, a sensor controller, a touch controller, a finger-print sensor controller, a display driver integrated circuit (IC), an audio CODEC chip, a universal serial bus (USB) controller, a camera controller, an image processing IC, a microprocessor unit (MPU), a system on chip (SoC), an IC, or the like.

[0038] An existing mechanism supports a large number of multicast user equipments (UEs) by enabling multicast reception in the RRC_INACTIVE state. This approach allows the system to support more UEs than active connections. Group paging notifications are sent to these UEs for session activation, requiring them to decide whether to continue in RRC_INACTIVE or move to RRC_CONNECTED.

[0039] A problem arises if a UE remains in RRC_INACTIVE upon receiving group paging that indicates multicast session activation. If the UE was notified to stop monitoring the G-RNTI for at least one multicast session for which the PTM configuration was not included in the RRCRelease message, the UE needs to acquire multicast MCCH. There may be cases where some sessions indicated to stop monitoring G-RNTI have PTM configurations provided by RRCRelease and are already stored. In such cases, the UE should first apply the PTM configuration for these sessions and then acquire multicast MCCH to obtain PTM configuration for other sessions.

[0040] In an embodiment, the proposed solution relates to the 3GPP Rel18 eMBS work item and is incorporated into the 3GPP TS 38331 Rel-18 specification. This solution addresses the improper handling of group paging by introducing a condition that only addresses the multicast session(s) indicated by the TMGI(s) in the group paging message. This ensures that the concerned session(s) would be a deactivated session as it is being group paged.

[0041] A standardized solution is provided for cases where some sessions indicated to stop monitoring G-RNTI have PTM configurations provided by RRCRelease. For these cases, the UE first applies the PTM configuration for these sessions and then acquires multicast MCCH to get PTM configuration for other sessions.

[0042] In an embodiment, a system and method are provided for handling group paging messages for MBS in a wireless network. The disclosure introduces a selection of concepts in a simplified format further described in the detailed description. This method handles group paging messages for UEs capable and / or configured to receive MBS multicast in the RRC_INACTIVE state. The method provides an approach for the UE to handle group paging messages effectively and accurately in the RRC_INACTIVE state and determine whether the UE needs to acquire multicast MBS control channel (MCCH) to receive point-to-multipoint (PTM) configuration.

[0043] In the related art (3GPP TS 38331 v1830), when the UE receives a group paging message and is not notified to stop monitoring the G-RNTI(s) for all joined multicast sessions configured for reception in RRC_INACTIVE, the condition to acquire multicast MCCH is stated as the UE was notified to stop monitoring G-RNTI for any session for which PTM configuration was not included in the RRCRelease message. This condition is ambiguous and inaccurate because:

[0044] The multicast session may not be included in the group paging message.

[0045] The multicast session may have already been activated as the condition only refers to the RRCRelease message, whereas the session may have been activated in previous group paging and received PTM configuration in multicast MCCH.

[0046] As a consequence, there would be improper handling of group paging messages by the UE. The UE may not acquire multicast MCCH to receive PTM configuration, leading to a loss or degradation of service reception.

[0047] Referring now to the drawings, and more particularly to FIGS. 1 through 7, there are shown preferred embodiments.

[0048] FIG 1 is a block diagram of a UE (100) for handling group paging messages for multicast broadcast service in a wireless communication system according to an embodiment of the disclosure. Examples of the UE (100) may include but are not limited to consumer electronics (such as mobile phones and smartphones), tablets, wearable devices, computing devices (such as laptops, notebooks, desktops, television, workstations, etc.), internet of things (IoT) devices, automotive systems (such as connected cars, autonomous vehicles, vehicle-to-everything (V2X) communication devices, etc.), enterprise devices such as robotics, specialized equipment (such as medical devices, public safety devices, etc.), and media devices (such as gaming consoles, streaming devices, etc.).

[0049] In an embodiment, the UE (100) may include at least one processor (101), memory (102), a communicator (103), and a group paging message controller (104). The processor (101) is coupled with the memory (102), the communicator (103), and the group paging message controller (104). The group paging message controller (104) may be included in the processor (101).

[0050] The processor (101) manages the handling of group paging messages for multicast broadcast service in a wireless communication system. It communicates with the memory (102), the communicator (103), and the group paging message controller (104).

[0051] Configured to execute instructions stored in the memory (102), the processor (101) may include one or a plurality of processors which may be a general-purpose processor such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and / or an artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).

[0052] The memory (102) may store the operating system, application software, and temporary data used by the processor (101). It may also store instructions to be executed by the processor (101) and include non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard disks, optical disks, floppy disks, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Further, the memory (102) may in some examples be considered a non-transitory storage medium. The term non-transitory indicates that the storage medium is not embodied in a carrier wave or a propagated signal, but it should not be interpreted to mean that the memory (102) is non-movable. The memory (102) may include MCCH information, PTM configuration which may be multicast sessions indicated by the TMGI(s) included in the pagingGroupList, PTM configuration information, RRCRelease message, and multicast PTM configuration provided in RRCRelease for the multicast session. This information enables the UE (100) to handle group paging messages for multicast broadcast service (MBS) in a wireless communication system, ensuring seamless connectivity and robust communication within the network.

[0053] The communicator (103) may facilitate communication between the processor (101) and the memory (102), supporting various communication protocols such as transmission control protocol / internet protocol (TCP / IP), user datagram protocol (UDP), transport layer security (TLS), internet protocol security (IPSec), and hypertext transfer protocol secure (HTTPS). Further, the communicator (103) may be configured for internal communication between internal hardware components. It may include an electronic circuit specific to a standard that enables wired or wireless communication and facilitates the transmission of messages.

[0054] The group paging message controller (104) may be specialized hardware designed for handling group paging messages for multicast broadcast service in a wireless communication system. In an embodiment, the structure of such an innovative integrated circuit of the group paging message controller (104) may include a multi-core architecture that enables the handling of group paging messages for multicast broadcast service. Each core may be optimized for specific tasks such as multicast sessions configured for reception in the RRC INACTIVE state, notifying to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by TMGI(s) included in a paging group list, etc. The integrated circuit of the group paging message controller (104) may be made of a combination of analog and digital components designed to enable handling of group paging messages for multicast broadcast service in a wireless communication system. The analog components may include a low-noise amplifier, while the digital components include a microcontroller unit (MCU) and a digital signal processor (DSP) that work in tandem to introduce one new attribute that includes information related to the storage format to be used by the UE (100).

[0055] The group paging message controller (104) may receive a group paging message and further determines whether the UE (100) is notified to stop monitoring G-RNTIs for all joined multicast sessions configured for reception in the RRC INACTIVE state. This determination may be used for managing the power consumption and resource allocation of the UE (100), ensuring that it does not waste energy monitoring sessions that are no longer relevant. By optimizing the monitoring process, the group paging message controller (104) may enhance the multicast broadcast service, providing a more reliable and responsive communication experience for users.

[0056] Further, the group paging message controller (104) may acquire multicast MCCH information if the UE (100) was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by TMGI(s) included in a paging group list for which PTM configuration was not included in an RRC Release message. The multicast MCCH information may comprise MBS Multicast Configuration message. This acquisition process may include retrieving and processing the necessary control information to ensure that the UE (100) may accurately manage its multicast session monitoring. By handling this information, the group paging message controller (104) may be used to maintain continuity of multicast broadcast services, even when certain sessions are no longer actively monitored. This capability may underscore the importance of the group paging message controller (104) in the overall architecture of wireless communication systems.

[0057] FIG 2 is a flow chart illustrating a method for handling group paging messages for receiving MBS in a wireless communication system.

[0058] At operation 201, the method may include the UE (100) receiving a group paging message.

[0059] At operation 202, the method may include the UE (100) determining whether the UE (100) is notified to stop monitoring G-RNTIs for all joined multicast sessions configured for reception in the RRC INACTIVE state. This determination may be based on the analysis of the received paging message and the current state of the UE (100).

[0060] At operation 203, the method may include the UE (100) acquiring multicast MCCH information if the UE (100) was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by TMGI(s) included in a paging group list for which PTM configuration was not included in an RRC release message when the UE (100) is not notified to stop monitoring the G-RNTIs for all joined multicast sessions. The acquisition of MCCH information may include decoding and processing the multicast control channel to extract relevant configuration details for the multicast sessions.

[0061] In an embodiment, when the UE (100) is not notified to stop monitoring the G-RNTIs for all joined multicast sessions, the UE (100) may perform at least one of the following actions: unconditionally acquiring multicast MCCH, attempting to acquire multicast MCCH in the immediately next repetition period once the group paging message is received, attempting to acquire multicast MCCH in the immediately next modification period once the group paging message is received, or not acquiring multicast MCCH and utilizing the PTM configuration from the multicast MCCH message previously received or stored by the UE (100) for at least one activated multicast session. These actions ensure that the UE (100) may efficiently handle group paging messages and maintain seamless multicast broadcast service. In an embodiment, network may ensure to page UE after multicast MCCH is updated with PTM configuration.

[0062] In an embodiment, the method may include the UE (100) applying a stored PTM configuration for the at least one multicast session when the PTM configuration has previously been received in the RRC release message. This approach leverages the stored configuration to minimize latency and ensure prompt response to the group paging message, enhancing the overall user experience. By utilizing stored configurations, the UE (100) may quickly adapt to changes in multicast session requirements without the need for repeated acquisition of MCCH information, thus optimizing resource utilization and improving service continuity.

[0063] Furthermore, the method may include receiving a notification to stop monitoring a G-RNTI for at least one multicast session where the PTM configuration for the multicast session was not included in an RRC release message, and the activation for at least one of the multicast sessions is indicated by TMGI(s) included in a pagingGroupList. This notification may trigger the UE (100) to adjust its monitoring behavior and acquire necessary configuration details for the affected multicast sessions. By dynamically adjusting its monitoring behavior based on received notifications, the UE (100) may ensure that it remains aligned with the current multicast session requirements, thereby maintaining effective communication.

[0064] Further, in an embodiment, the method may include the UE (100) bypassing the acquisition of an MCCH, utilizing a PTM configuration from a multicast MCCH message previously received and / or stored, and receiving at least one activated multicast session based on the PTM configuration from the multicast MCCH message. This approach may ensure that the UE (100) can continue receiving multicast sessions without interruption, leveraging previously acquired configuration details. By bypassing unnecessary acquisition processes, the UE (100) may maintain a high level of service continuity and reduce the overhead associated with frequent configuration updates.

[0065] FIG 3 is an operational flow diagram illustrating a method for handling a group paging message by a UE (100) in the RRC_INACTIVE state.

[0066] At operation 301, the method may include configuring the UE (100) to receive multicast in the RRC_INACTIVE state. The UE (100) may remain in the RRC_INACTIVE state and, when receiving a group paging message, is not notified to stop monitoring the G-RNTI(s) for all joined multicast sessions configured for reception in RRC_INACTIVE. This condition necessitates acquiring the multicast MCCH. The configuration process may include setting specific parameters and states within the UE (100) to ensure readiness for multicast reception.

[0067] At operation 301, the efficiency of multicast communication may be maintained while the UE (100) is in the RRC_INACTIVE state. This may include setting up the UE (100) to continuously monitor the multicast control channel (MCCH) without transitioning to a different state, which could potentially disrupt the reception of multicast messages. The parameters set during this configuration ensure that the UE (100) is optimally tuned to handle multicast traffic, even in an inactive state, thus allowing it to seamlessly receive group paging messages and other multicast data.

[0068] At operation 302, the method may include a scenario where the UE (100) was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by the TMGI(s) included in the pagingGroupList for which the PTM configuration was not included in the RRCRelease message. This notification and reception of pagingGroupList may prompt the UE (100) to adjust its monitoring behavior and prepare for acquiring necessary configuration details. The adjustment process may include the UE (100) selectively tuning out of certain multicast sessions while continuing to monitor others, based on the received notification. This selective monitoring may ensure that the UE (100) is not overwhelmed by unnecessary data and can focus on the multicast sessions that are relevant and configured for reception in the RRC_INACTIVE state.

[0069] At operation 303, the method may include the condition where the UE (100) does not acquire the MBS multicast configuration message on the multicast MCCH. This condition may arise due to various factors such as already availability of the required configuration, network congestion, signal interference, or configuration errors. When the UE (100) fails to acquire the necessary configuration message, it may need to implement fallback mechanisms to ensure that it may still participate in multicast sessions. These mechanisms could include retrying the acquisition process, switching to alternative channels, or utilizing stored configuration data from previous sessions.

[0070] At operation 304, the method may include the condition where the UE (100) acquires the MBS multicast configuration message on the multicast MCCH. The acquisition process may include decoding and processing the multicast control channel to extract relevant configuration details for the multicast sessions. For example, the specific multicast sessions are those for which UE was notified to stop monitoring the G-RNTI and are indicated by the TMGI(s) included in the pagingGroupList for which the PTM configuration was not included in the RRCRelease. Successfully acquiring and decoding the configuration message may allow the UE (100) to update its settings and ensure that it is properly configured to receive multicast data. The UE (100) may stay synchronized with the network's multicast configuration and to participate effectively in the multicast sessions. The process of decoding and processing the MCCH may require the UE (100) to have robust decoding algorithms and sufficient processing power to handle the potentially complex configuration data, ensuring that it can quickly and accurately update its multicast settings.

[0071] FIG 4 is an operational flow diagram illustrating a method for checking the availability of the stored PTM configuration (e.g., received via RRC Release) before acquiring the multicast MCCH.

[0072] At operation 401, the method may include configuring the UE (100) to receive multicast in the RRC_INACTIVE state. The UE (100) may remain in the RRC_INACTIVE state, and when receiving a group paging message, is not notified to stop monitoring the G-RNTI(s) for all joined multicast sessions configured for reception in RRC_INACTIVE. This condition may necessitate acquiring the multicast MCCH. The configuration process may include setting specific parameters and states within the UE (100) to ensure readiness for multicast reception.

[0073] At operation 402, the method may include a scenario where the UE (100) is notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by the TMGI(s) included in the pagingGroupList for which the PTM configuration was not included in the RRCRelease message. This notification may prompt the UE (100) to adjust its monitoring behavior and prepare for acquiring necessary configuration details.

[0074] At operation 403, the method may include the condition where the UE (100) does not acquire the MBS multicast configuration message on the multicast MCCH. This condition may arise due to various factors such as already availability of the required configuration, network congestion, signal interference, or configuration errors.

[0075] At operation 404, the method may include the condition where the UE (100) applies the multicast PTM configuration provided in the RRCRelease (e.g., stored configuration). For example, this may be performed for first set of multicast sessions for which stored PTM configurations are available. This approach may leverage the stored configuration to minimize latency and ensure prompt response to the group paging message, enhancing the overall user experience.

[0076] At operation 405, the method may include the condition where the UE (100) acquires the MBS multicast configuration message on the multicast MCCH. For example, this may be performed for second set of multicast sessions for which stored PTM configurations are not available. The acquisition process may include decoding and processing the multicast control channel to extract relevant configuration details for the multicast sessions.

[0077] FIG 5 is an operational flow diagram illustrating a method for a group paging and multicast MCCH acquisition, network to ensure the multicast MCCH is updated with PTM configuration immediately after or in parallel with the group paging broadcasting.

[0078] In an embodiment, as illustrated in FIG 5, the method may include group paging and multicast MCCH acquisition, depicting a scenario for group paging reception and multicast MCCH acquisition. Many UEs may receive group paging on their paging occasions (POs), and in accordance with the present RRC specification, these UEs attempt to acquire multicast MCCH at their immediate next repetition period. Considering all possibilities, some UEs may fail to acquire updated multicast MCCH information if the immediate next repetition period does not carry updated MCCH information. Consequently, these UEs would observe an absence of PTM configuration on the acquired multicast MCCH message corresponding to the group-paged MBS sessions. In this situation, the UEs would be forced to initiate RRC connection resumption, which is drastic and defeats the purpose.

[0079] FIG 6 is a flow chart that illustrates a use case for receiving group paging and continuing a multicast session.

[0080] At operation 601, the method may include that the UE (100) is in RRC_INACTIVE mode and is configured to receive multicast in RRC_INACTIVE mode. The configuration process may include setting specific parameters and states within the UE (100) to ensure readiness for multicast reception.

[0081] At operation 602, the method may include that the UE (100) receives a group paging message.

[0082] At operation 603, the method may include that the UE (100) determines that it was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by the TMGI(s) included in the pagingGroupList for which the PTM configuration was not included in the RRCRelease message. This determination may be based on the analysis of the received paging message and the current state of the UE (100).

[0083] If the determination is true, at operation 604, the method may include that the UE (100) acquires the multicast MCCH and receives the PTM configuration for the multicast session which is activated in the group paging. The acquisition process may include decoding and processing the multicast control channel to extract relevant configuration details for the multicast sessions.

[0084] At operation 605, the method may include that the UE (100) starts monitoring the relevant G-RNTI to receive the multicast session which is activated in the group paging. This may ensure that the PTM configuration for the multicast session activated in the group paging is acquired from the multicast MCCH channel and that the reception of the multicast session is continued reliably. The UE (100) may employ advanced signal processing techniques to ensure accurate and reliable monitoring of the relevant G-RNTI.

[0085] FIG 7 is a flow chart that illustrates a use case for utilizing stored PTM configuration information.

[0086] At operation 701, the method may include the UE (100) being in RRC_INACTIVE mode and configured to receive multicast in RRC_INACTIVE. The configuration process may include setting specific parameters and states within the UE (100) to ensure readiness for multicast reception.

[0087] At operation 702, the method may include the UE (100) receiving a group paging message. The group paging message may contain various parameters such as session identifiers, timing information, and configuration details necessary for the UE (100) to process and respond to the paging request.

[0088] At operation 703, the method may include the UE (100) determining that it was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by the TMGI(s) included in the pagingGroupList for which the PTM configuration was not included in the RRCRelease message. This determination may be based on the analysis of the received paging message and the current state of the UE (100).

[0089] At operation 704, if there is a stored PTM configuration for at least one session, the UE (100) may apply the multicast PTM configuration provided in the RRCRelease for the multicast session which is activated in the group paging. This approach may leverage the stored configuration to minimize latency and ensure prompt response to the group paging message, enhancing the overall user experience.

[0090] At operation 705, if the determination is true for at least one other session (e.g., stored PTM configuration for the session is not available), the UE (100) may acquire the multicast MCCH and receives the PTM configuration for the multicast session which is activated in the group paging. The acquisition process may include decoding and processing the multicast control channel to extract relevant configuration details for the multicast sessions.

[0091] At operation 706, the method may include the UE (100) starting to monitor the relevant G-RNTI to receive the multicast session which is activated in the group paging. This method may ensure that the stored PTM configuration for at least one multicast session activated in the group paging is applied without the need to delay for the multicast MCCH acquisition. It may prevent any loss of paging / PTM configuration and avoid any multicast service degradation. The approach may specify group paging handling in the 3GPP specification utilizing stored PTM configuration when available and avoiding MCCH decoding.

[0092] In an embodiment, when the UE is receiving group paging message and the UE is NOT notified to stop monitoring the G-RNTI(s) for all the joined multicast sessions that are configured for reception in RRC_INACTIVE, the UE does not acquire multicast MCCH. Instead, UE may utilize the PTM configuration from the multicast MCCH message received (and / or stored) in the current modification period due to at least one activated multicast session.

[0093] In an embodiment, an example specification text may be provided to illustrate the procedure of handling of group paging message by the UE (100) configured to receive multicast in RRC_INACTIVE state.

[0094] Example 1:

[0095] 5.3.2.3 Reception of the Paging message by the UE or PagingRecord by the L2 U2N Remote UE

[0096] Upon receiving the Paging message by the UE or receiving PagingRecord from its connected L2 U2N Relay UE by a L2 U2N Remote UE, the UE shall:

[0097] 1>if in RRC_IDLE, for each of the PagingRecord, if any, included in the Paging message, or

[0098] 1>if in RRC_IDLE, for the PagingRecord, if any, included in the UuMessageTransferSidelink message received from the connected L2 U2N Relay UE:

[0099] 2>if the ue-Identity included in the PagingRecord matches the UE identity allocated by upper layers:

[0100] 3>if upper layers indicate the support of paging cause:

[0101] 4>forward the ue-Identity, accessType (if present) and paging cause (if determined) to the upper layers;

[0102] 3>else:

[0103] 4>forward the ue-Identity and accessType (if present) to the upper layers;

[0104] NOTE 1: If the L2 U2N Relay UE supports the MUSIM feature, it can forward the paging cause to the connected L2 U2N Remote UE.

[0105] 1>if in RRC_INACTIVE, for each of the PagingRecord, if any, included in the Paging message, or

[0106] 1>if in RRC_INACTIVE, for the PagingRecord, if any, included in the UuMessageTransferSidelink message received from the connected L2 U2N Relay UE:

[0107] 2>if the ue-Identity included in the PagingRecord matches the UE's stored fullI-RNTI:

[0108] 3>if the UE is configured by upper layers with Access Identity 1:

[0109] 4>initiate the RRC connection resumption procedure according to 5.3.13 with resumeCause set to mps-PriorityAccess;

[0110] 3>else if the UE is configured by upper layers with Access Identity 2:

[0111] 4>initiate the RRC connection resumption procedure according to 5.3.13 with resumeCause set to mcs-PriorityAccess;

[0112] 3>else if the UE is configured by upper layers with one or more Access Identities equal to 11-15:

[0113] 4>initiate the RRC connection resumption procedure according to 5.3.13 with resumeCause set to highPriorityAccess;

[0114] 3>else if mt-SDT indication was included in the Paging message and if the conditions for initiating SDT for a resume procedure initiated in response to RAN paging according to 5.3.13.1b are fulfilled:

[0115] 4>if pagingGroupList was not included in the Paging message; or:

[0116] 4>if pagingGroupList was included in the Paging message but the UE has not joined any MBS session(s) indicated by the TMGI(s) included in the pagingGroupList or:

[0117] 4>if pagingGroupList was included in the Paging message, the UE is configured to receive MBS multicast in RRC_INACTIVE, and inactiveReceptionAllowed was included for all the MBS session(s) indicated by the TMGI(s) that the UE has joined:

[0118] 5>initiate the RRC connection resumption procedure according to 5.3.13 with resumeCause set to mt-SDT:

[0119] 4> else:

[0120] 5>initiate the RRC connection resumption procedure according to 5.3.13 with resumeCause set to mt-Access;

[0121] 3> else:

[0122] 4> initiate the RRC connection resumption procedure according to 5.3.13 with resumeCause set to mt-Access;

[0123] NOTE 2: If both conditions for initiating MT-SDT and MO-SDT according to 5.3.13.1b are fulfilled, UE may initiate RRC connection resumption procedure for MT-SDT or MO-SDT based on implementation.

[0124] NOTE 3: A MUSIM UE may not initiate the RRC connection resumption procedure, e.g. when it decides not to respond to the Paging message due to UE implementation constraints as specified in TS 24.501

[0023] .

[0125] 2> else if the ue-Identity included in the PagingRecord matches the UE identity allocated by upper layers:

[0126] 3> if upper layers indicate the support of paging cause:

[0127] 4> forward the ue-Identity, accessType (if present) and paging cause (if determined) to the upper layers;

[0128] 3> else:

[0129] 4> forward the ue-Identity and accessType (if present) to the upper layers;

[0130] 3> perform the actions upon going to RRC_IDLE as specified in 5.3.11 with release cause 'other';

[0131] 1>if in RRC_IDLE, for each TMGI included in pagingGroupList, if any, included in the Paging message:

[0132] 2>if the UE has joined an MBS session indicated by the TMGI included in the pagingGroupList:

[0133] 3>forward the TMGI to the upper layers;

[0134] 1>if in RRC_INACTIVE and the UE has joined one or more MBS session(s) indicated by the TMGI(s) included in the pagingGroupList:

[0135] 2>if PagingRecordList is not included in the Paging message; or

[0136] 2>if none of the ue-Identity included in any of the PagingRecord matches the UE identity allocated by upper layers or the UE's stored fullI-RNTI:

[0137] 3>if the UE is not configured to receive multicast in RRC_INACTIVE for at least one of the MBS sessions indicated by the TMGI(s) that the UE has joined; or

[0138] 3>if inactiveReceptionAllowed is not included for at least one of the MBS sessions indicated by the TMGI(s) that the UE has joined:

[0139] 4>initiate the RRC connection resumption procedure according to 5.3.13 with resumeCause set as below:

[0140] 5>if the UE is configured by upper layers with Access Identity 1:

[0141] 6>set resumeCause to mps-PriorityAccess;

[0142] 5>else if the UE is configured by upper layers with Access Identity 2:

[0143] 6>set resumeCause to mcs-PriorityAccess;

[0144] 5>else if the UE is configured by upper layers with one or more Access Identities equal to 11-15:

[0145] 6>set resumeCause to highPriorityAccess;

[0146] 5>else:

[0147] 6>set resumeCause to mt-Access;

[0148] 3> else:

[0149] 4> start monitoring the G-RNTI(s), if configured, corresponding to the TMGI(s);

[0150] 4> if the UE was notified to stop monitoring the G-RNTI(s) for all the joined multicast sessions that are configured for reception in RRC_INACTIVE:

[0151] 5> apply the multicast PTM configuration provided in RRCRelease;

[0152] 5> if multicast MCCH is present:

[0153] 6>start monitoring the Multicast MCCH-RNTI;

[0154] 6>acquire the MBSMulticastConfiguration message on multicast MCCH;

[0155] 4> else if the UE was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by the TMGI(s) included in the pagingGroupList for which the PTM configuration was not included in RRCRelease message:

[0156] 5> acquire the MBSMulticastConfiguration message on multicast MCCH;

[0157] 2> else if the ue-Identity included in any of the PagingRecord matches the UE identity allocated by upper layers:

[0158] 3> forward the TMGI(s) to the upper layers;

[0159] 1>if the UE is acting as a L2 U2N Relay UE, for each of the PagingRecord, if any, included in the Paging message:

[0160] 2>if the ue-Identity included in the PagingRecord in the Paging message matches the UE identity in sl-PagingIdentityRemoteUE included in sl-PagingInfo-RemoteUE received in RemoteUEInformationSidelink message from a L2 U2N Remote UE:

[0161] 3>inititate the Uu Message transfer in sidelink to that UE as specified in 5.8.9.9.

[0162] It will be appreciated that various embodiments of the disclosure according to the claims and description in the specification can be realized in the form of hardware, software or a combination of hardware and software.

[0163] Any such software may be stored in non-transitory computer readable storage media. The non-transitory computer readable storage media store one or more computer programs (software modules), the one or more computer programs include computer-executable instructions that, when executed by one or more processors of an electronic device individually or collectively, cause the electronic device to perform a method of the disclosure.

[0164] Any such software may be stored in the form of volatile or non-volatile storage such as, for example, a storage device like read only memory (ROM), whether erasable or rewritable or not, or in the form of memory such as, for example, random access memory (RAM), memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a compact disk (CD), digital versatile disc (DVD), magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are various embodiments of non-transitory machine-readable storage that are suitable for storing a computer program or computer programs comprising instructions that, when executed, implement various embodiments of the disclosure. Accordingly, various embodiments provide a program comprising code for implementing apparatus or a method as claimed in any one of the claims of this specification and a non-transitory machine-readable storage storing such a program.

[0165] While the disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims and their equivalents.

Claims

1.A method for handling of paging message for receiving multicast and broadcast service (MBS) in a wireless communication system, comprisingreceiving (201), by a user equipment (UE) (100), a paging message;determining (202), by the UE (100), whether the UE (100) is notified to stop monitoring group radio network temporary identifiers (G-RNTIs) for all joined multicast sessions configured for reception in a radio resource control (RRC) inactive state; andacquiring (203), by the UE (100), multicast MBS control channel (MCCH) information, wherein the UE (100) was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by at least one temporary mobile group identity (TMGI) included in a paging group list for which point-to-multipoint (PTM) configuration was not included in an RRC release message.2.The method of claim 1, further comprising:in case that the UE (100) is not notified to stop monitoring the G-RNTIs for all joined multicast sessionsacquiring, by the UE (100), multicast MCCH; orattempting, by the UE (100), to acquire multicast MCCH in a next repetition period once the paging message is received; orattempting, by the UE (100), to acquire multicast MCCH in a next modification period once the paging message is received; ornot acquiring, by the UE (100), multicast MCCH and utilizing the PTM configuration from a multicast MCCH message previously been received or stored by the UE (100) for at least one activated multicast session.3.The method of claim 1, further comprising:applying a multicast PTM configuration provided in the RRC Release message, wherein the UE was notified to stop monitoring the G-RNTIs for all joined multicast sessions configured for reception in the RRC inactive state.4.The method of claim 1, further comprising:receiving a notification to stop monitoring at least one G-RNTI for at least one multicast session,wherein the PTM configuration for the multicast session was not included in the RRC release message, andwherein an activation for at least one multicast session is indicated by the at least one TMGI included in the paging group list.5.The method of claim 1, further comprising:bypassing, by the UE (100), an acquisition of the MCCH;utilizing, by the UE (100), the PTM configuration from a multicast MCCH message previously received or stored; andreceiving, by the UE (100), at least one activated multicast session based on the PTM configuration from a multicast MCCH message.6.A user equipment (UE) (100) for handling of paging message for receiving multicast and broadcast service (MBS) in a wireless communication system, comprising:memory (102) storing instructions; andat least one processor (101) operably coupled to the memory,wherein the instructions, when executed by the processor individually or collectively, cause the UE to:receives a paging message;determines whether the UE (100) is notified to stop monitoring group radio network temporary identifiers (G-RNTIs) for all joined multicast sessions configured for reception in a radio resource control (RRC) inactive state; andacquires multicast MBS control channel (MCCH) information, wherein the UE (100) was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by at least one temporary mobile group identity (TMGI) included in a paging group list for which point-to-multipoint (PTM) configuration was not included in an RRC release message.7.The UE of claim 6, wherein the instructions, when executed by the processor individually or collectively, cause the UE to apply a multicast PTM configuration provided in the RRC Release message, wherein the UE was notified to stop monitoring the G-RNTIs for all joined multicast sessions configured for reception in the RRC inactive state.8.The UE of claim 6, wherein, in case that the UE (100) is not notified to stop monitoring the G-RNTIs for all joined multicast sessions, the instructions, when executed by the processor individually or collectively, cause the UE to:acquire multicast MCCH; orattempt to acquire multicast MCCH in a next repetition period once the paging message is received; orattempt to acquire multicast MCCH in a next modification period once the paging message is received; ornot acquire multicast MCCH and utilizing the PTM configuration from a multicast MCCH message previously been received or stored by the UE (100) for at least one activated multicast session.9.The UE of claim 6, wherein the instructions, when executed by the processor individually or collectively, cause the UE to:receive a notification to stop monitoring at least one G-RNTI for at least one multicast session,wherein the PTM configuration for the multicast session was not included in the RRC release message, andwherein an activation for at least one multicast session is indicated by the at least one TMGI included in the paging group list.10.The UE of claim 6, wherein the instructions, when executed by the processor individually or collectively, cause the UE to:bypass an acquisition of the MCCH;utilize the PTM configuration from a multicast MCCH message previously received or stored; andreceive at least one activated multicast session based on the PTM configuration from a multicast MCCH message.11.One or more non-transitory computer-readable storage media storing one or more computer programs including computer-executable instructions that, when executed by one or more processors of a user equipment (UE) individually or collectively, cause the location management server to perform operations, the operations comprising:receiving a paging message;determining whether the UE (100) is notified to stop monitoring group radio network temporary identifiers (G-RNTIs) for all joined multicast sessions configured for reception in a radio resource control (RRC) inactive state; andacquiring multicast MBS control channel (MCCH) information, wherein the UE (100) was notified to stop monitoring the G-RNTI for at least one of the multicast sessions indicated by at least one temporary mobile group identity (TMGI) included in a paging group list for which point-to-multipoint (PTM) configuration was not included in an RRC release message.12.The one or more non-transitory computer-readable storage media of claim 11, wherein the operations further comprising: applying a multicast PTM configuration provided in the RRC Release message, wherein the UE was notified to stop monitoring the G-RNTIs for all joined multicast sessions configured for reception in the RRC inactive state.13.The one or more non-transitory computer-readable storage media of claim 11, wherein, in case that the UE (100) is not notified to stop monitoring the G-RNTIs for all joined multicast sessions, the operations further comprising::acquiring multicast MCCH; orattempting to acquire multicast MCCH in a next repetition period once the paging message is received; orattempting to acquire multicast MCCH in a next modification period once the paging message is received; ornot acquiring multicast MCCH and utilizing the PTM configuration from a multicast MCCH message previously been received or stored by the UE (100) for at least one activated multicast session.14.The one or more non-transitory computer-readable storage media of claim 11, wherein the operations further comprising:receiving a notification to stop monitoring at least one G-RNTI for at least one multicast session,wherein the PTM configuration for the multicast session was not included in the RRC release message, andwherein an activation for at least one multicast session is indicated by the at least one TMGI included in the paging group list.15.The one or more non-transitory computer-readable storage media of claim 11, wherein the operations further comprising:bypassing an acquisition of the MCCH;utilizing the PTM configuration from a multicast MCCH message previously received or stored; andreceiving at least one activated multicast session based on the PTM configuration from a multicast MCCH message.

Images