Dynamic change of multicast / broadcast service delivery

Abstract

Systems and methods are provided for dynamically changing multicast service delivery between multicast and unicast while maintaining service continuity. A wireless communication device can receive multicast radio resource configuration information from a network. The wireless communication device can configure an air interface protocol stack of the wireless communication device in accordance with the multicast radio resource configuration information. The wireless communication device can receive data of a multicast service in accordance with the multicast radio resource configuration information.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to wireless communication, including but not limited to systems and methods for dynamically changing multicast or broadcast traffic delivery between multicast and unicast while maintaining traffic continuity. BACKGROUND

[0002] The Third Generation Partnership Project (3GPP) standardization organization is currently specifying a new radio interface, called 5G New Radio (5G NR), and a Next Generation Packet Core Network (NG-CN or NGC). 5G NR will have three main components: a 5G Access Network (5G-AN), a 5G Core Network (5GC), and a User Equipment (UE). To facilitate different data traffic and requirements, the elements (also referred to as network functions) of the 5GC have been simplified, where some of the elements are based on software, enabling these elements to be adjusted as needed. SUMMARY

[0003] The example embodiments disclosed herein are directed to addressing one or more of the issues existing in the prior art and provide additional features that will become apparent upon reading the following detailed description in conjunction with the drawings. In accordance with various embodiments, example systems, methods, devices, and computer program products are disclosed herein. It should be understood, however, that these embodiments are presented by way of example only, not limitation, and that the disclosed embodiments can be modified in various ways while still remaining within the scope of the disclosure.

[0004] At least one aspect relates to a system, method, apparatus, computer readable medium, or wireless communication device. The wireless communication device can receive multicast radio resource configuration information from a network. The wireless communication device can configure an air interface protocol stack of the wireless communication device in accordance with the multicast radio resource configuration information. The wireless communication device can receive data of a multicast traffic in accordance with the multicast radio resource configuration information.

[0005] In some embodiments, the wireless communication device can transmit a multicast traffic request to the network prior to receiving the multicast radio resource configuration. In some embodiments, the wireless communication device can transmit the multicast traffic request to a multicast session management function or entity of a core network. In some embodiments, the wireless communication device can transmit the multicast traffic request to a radio access network (RAN) node.

[0006] In some embodiments, multicast radio resource configuration information may include Packet Data Convergence Protocol (PDCP) configuration or Radio Link Control (RLC) bearer configuration.

[0007] In some embodiments, multicast radio resource configuration information may include at least one operation corresponding to a multicast radio bearer configuration, an RLC bearer configuration, or a multicast media access control (MAC) and physical PHY layer configuration set. In some embodiments, SDAP configuration may include a multicast service session identifier for identifying a session corresponding to a multicast service.

[0008] In some embodiments, for a multicast radio bearer configured with a Type 1 RLC bearer, each PDCP entity corresponding to the multicast radio bearer may be associated with an Acknowledged Mode (AM) RLC entity or an Unacknowledged Mode (UM) RLC entity in the corresponding direction. In some embodiments, for a multicast radio bearer configured with a Type 2 RLC bearer, each PDCP entity corresponding to the multicast radio bearer may be associated with at least one UM DL RLC entity. In some embodiments, for a multicast radio bearer configured with both Type 1 and Type 2 RLC bearers, each PDCP entity corresponding to the multicast radio bearer may be associated with an AM RLC entity or a UM RLC entity, and at least one UM DL RLC entity.

[0009] In some embodiments, a Type 2 RLC bearer can be configured as a point-to-multipoint (PTM) attribute / type / mode (or in PTM mode). In some embodiments, a peer RLC entity of a Type 1 RLC entity of a network can serve a specific UE receiving multicast services, and a peer RLC entity of a Type 2 RLC entity of a network can serve at least one wireless communication device receiving multicast services.

[0010] In some embodiments, the multicast media access control (MAC) and physical PHY layer configuration set for a multicast service may include at least one of the following: a MAC discontinuous reception (DRX) configuration corresponding to the multicast service, a list of cell identifiers to which the multicast service is scheduled, an index of the bandwidth part (BWP) associated with the multicast service; or a physical downlink shared data channel (PDSCH) configuration and a physical downlink control channel (PDCCH) configuration.

[0011] In some embodiments, a mapping relationship may exist between the physical layer identifier and the session identifier of a multicast service, and this mapping relationship can be provided and sent to a specific wireless communication device via dedicated signaling. In some embodiments, the wireless communication device can identify a logical channel based on the logical channel identifier (LCID) and the physical layer identifier or the session identifier associated with the physical layer identifier in the received MAC protocol data unit (PDU). The wireless communication device can submit the corresponding service data of the multicast service in the MAC PDU to the identified logical channel.

[0012] In some embodiments, the logical channel identifier (LCID) corresponding to the RLC bearer may include at least two LCID values, lcid2-1 and lcid2-2. If the corresponding LCID value in the subheader of the received MAC PDU is lcid2-1, the MAC entity submits the service data in the received MAC PDU to the logical channel identified by lcid2-2.

[0013] In some embodiments, the receiving RLC entity may uniquely deliver an RLC Service Data Unit (SDU) to an associated PDCP entity based on the served radio bearer identifier and physical layer identifier or a session identifier associated with the physical layer identifier. In some embodiments, the RLC bearer configuration may be provided through a broadcast channel and broadcast in the cell, or provided to a designated wireless communication device through dedicated signaling.

[0014] In some embodiments, step 1 configuration may include at least one operation corresponding to a multicast / broadcast radio bearer configuration, RLC bearer configuration, or MAC and PHY layer configuration set. In some embodiments, step 1 configuration includes enabling or disabling a PTP-type RLC bearer or a PTM-type RLC bearer serving a multicast bearer associated with a multicast service.

[0015] In some embodiments, the wireless communication device may receive indications of enabling or disabling operations for PTP-type RLC bearers and / or PTM-type RLC bearers via Layer 1 signaling. Layer 1 signaling may include a MAC control element (CE) or downlink control information (DCI). The MAC CE or DCI may include a radio bearer identifier or a radio bearer list or an associated identifier for a multicast service.

[0016] In some embodiments, the wireless communication device may receive instructions for enabling or disabling a configured operation via RRC signaling or Layer 1 signaling. Layer 1 signaling includes a MAC control element (CE) or downlink control information (DCI). The MAC CE or DCI may include an identifier for a multicast service. In some embodiments, the associated identifier is identified by a G-RNTI or session identifier to identify the multicast service, or by an identifier that other wireless communication devices can use to identify the multicast service. In some embodiments, a disabling operation may include releasing the corresponding RLC bearer. In some embodiments, a disabling operation may include suspending the RLC bearer without removing or retaining (e.g., potentially for later use) the configuration of the RLC bearer.

[0017] In some embodiments, in response to the suspension, the corresponding MAC entity may discard received data to be delivered to the logical channel. In some embodiments, the disable operation includes at least one of the following in the RLC entity process: if the reassembly timer (t-reassembly) is running, stopping and resetting t-reassembly; discarding any available RLC SDUs, RLC SDU segments, and RLC PDUs; and setting state variables to their initial values. In some embodiments, the enable operation may include an RLC bearer recovery operation or an RLC bearer reconstruction operation.

[0018] In some embodiments, the RLC bearer recovery operation may include, in response to a MAC entity receiving data to be delivered to a corresponding logical channel, the MAC entity delivering the data to the corresponding logical channel. In some embodiments, the RLC bearer recovery operation may include reassembling received packets and starting a corresponding reassembly timer (t-reassembly).

[0019] In some embodiments, step 1 configuration may include releasing the MAC or PHY configuration set associated with the multicast service. In some embodiments, step 1 configuration may include suspending the MAC or PHY configuration set associated with the multicast service. In some embodiments, one or more Type 2RLC bearers associated with the multicast service are suspended. In some embodiments, one or more Type 2RLC bearers associated with the multicast service are released.

[0020] In some embodiments, step 1 configuration may include a recovery operation of the MAC or PHY configuration set associated with the multicast service. In some embodiments, one or more Type 2RLC bearers associated with the multicast service may be recovered or established.

[0021] In some embodiments, step 1 configuration may include triggering conditions for PDCP status reports. These triggering conditions may include one of the following: when an MRB received from a PTM type (sometimes referred to as PTM attribute, PTM mode, or PTM method) RLC bearer, the MRB may be configured to be received in conjunction with a suspend or release operation of a type 2 or PTM type RLC bearer; or when an MRB received from a PTM type RLC bearer, the MRB may be configured to be received in conjunction with an establishment operation of a type 1 or PTP type RLC bearer. When receiving from both PTM and PTP modes; when the MAC / PHY configuration set associated with the multicast service is suspended or released; when the multicast type RLC bearer associated with the multicast radio bearer is released, deactivated, or suspended, and the unicast type RLC bearer associated with the multicast radio bearer is established or exists; when the maximum block error rate (BLER) associated with the multicast service is reached; or when the minimum reference signal received power (RSRP), reference signal received quality (RSRQ), or signal-to-interference-plus-noise (SINR) value measured based on the physical layer reference signal of the multicast service is reached; when the first lost PDCP is reached. The following events occur: when the maximum difference between the sequence numbers of the PDU and the PDCP PDU that was successfully received is reached; when the maximum number of lost PDCP PDUs or the maximum ratio of lost PDCP PDUs to the total number of PDCP PDUs is reached within a time window; when the PDCP reordering timer expires; when the maximum number of packets waiting to be reordered in a PDCP entity is reached; when a PDCP control PDU indicating a PDCP SR is received; when a timer periodically triggering the wireless communication device to perform a PDCP SR for a PDCP entity associated with a bearer serving a multicast service expires; when the network signals the MAC CE to the wireless communication device to indicate that a specific bearer of a specific multicast service requires a PDCP SR; and when the network provides information on the physical downlink control channel corresponding to the multicast service to signal the wireless communication device to perform a PDCP SR operation.

[0022] In some embodiments, the PDCP status report content includes at least one of the following: the last received PDCP PDU count or the first lost PDCP PDU count; a bitmap of the lost PDCP PDUs; or the number or ratio of lost PDCP PDUs within a time window or sequence number window. In some embodiments, the PDCP status report is sent in a Type 1 RLC entity. Attached Figure Description

[0023] Various exemplary embodiments of this solution are described in detail below with reference to the accompanying drawings. The drawings are provided for illustrative purposes only and depict merely exemplary embodiments of this solution to aid the reader's understanding. Therefore, the drawings should not be construed as limiting the breadth, scope, or applicability of this solution. It should be noted that these drawings are not necessarily drawn to scale for clarity and ease of explanation.

[0024] Figure 1 An example cellular communication network that can implement the technology disclosed herein, according to embodiments of this disclosure, is shown;

[0025] Figure 2 Block diagrams of example base stations and user equipment according to some embodiments of the present disclosure are shown;

[0026] Figure 3 A communication diagram illustrating an example sequence of multicast / broadcast service delivery dynamically altered between multicast and unicast while maintaining service continuity is shown.

[0027] Figure 4A A communication diagram of the delivery scheme from the perspective of the Random Access Network (RAN) is shown;

[0028] Figure 4B A communication diagram of the delivery scheme is shown from the perspective of the user equipment (UE).

[0029] Figure 5 The diagram illustrates the communication scheme of the handover scheme from the perspective of the user equipment (UE).

[0030] Figure 6 A communication diagram of the retransmission scheme from the user equipment (UE) perspective is shown; and

[0031] Figure 7 A flowchart is shown as an example method for dynamically changing multicast / broadcast service delivery between multicast and unicast while maintaining business continuity. Detailed Implementation

[0032] Various exemplary embodiments of this solution are described below with reference to the accompanying drawings to enable those skilled in the art to make and use this solution. It will be apparent to those skilled in the art that, after reading this disclosure, various changes or modifications can be made to the examples described herein without departing from the scope of this solution. Therefore, this solution is not limited to the exemplary embodiments and applications described and illustrated herein. Furthermore, the specific order or hierarchy of steps in the methods disclosed herein is merely an example method. Based on design preferences, the specific order or hierarchy of steps in the disclosed methods or processes can be rearranged while remaining within the scope of this solution. Therefore, those skilled in the art will understand that the methods and techniques disclosed herein present various steps or actions in an exemplary order, and unless otherwise expressly stated, this solution is not limited to the specific order or hierarchy presented.

[0033] The following abbreviations are used in this disclosure:

[0034]

[0035]

[0036]

[0037]

[0038]

[0039] 1. Mobile communications technology and environment

[0040] Figure 1 An example wireless communication network and / or system 100, which can implement the technologies disclosed herein, is illustrated according to embodiments of this disclosure. In the following discussion, the wireless communication network 100 can be any wireless network, such as a cellular network or a narrowband Internet of Things (NB-IoT) network, and is referred to herein as "network 100". Such an example network 100 includes: a base station 102 (hereinafter referred to as "BS 102"; also called a wireless communication node) and a user equipment 104 (hereinafter referred to as "UE 104"; also called a wireless communication device), which can communicate with each other via a communication link 110 (e.g., a wireless communication channel); and a set of cells 126, 130, 132, 134, 136, 138, and 140 covering a geographic area 101. Figure 1In this context, BS 102 and UE 104 are contained within the corresponding geographical boundaries of cell 126. Each of the other cells 130, 132, 134, 136, 138, and 140 may include at least one base station that operates on its allocated bandwidth to provide sufficient radio coverage to its intended users.

[0041] For example, BS 102 can operate on the allocated channel transmission bandwidth to provide sufficient coverage to UE 104. BS 102 and UE 104 can communicate via downlink radio frame 118 and uplink radio frame 124, respectively. Each radio frame 118 / 124 can be further divided into subframes 120 / 127, which can include data symbols 122 / 128. In this disclosure, BS 102 and UE 104 are described as non-limiting examples of "communication nodes," which generally practice the methods disclosed herein. According to various embodiments of this scheme, such communication nodes are capable of wireless and / or wired communication.

[0042] Figure 2 A block diagram of an example wireless communication system 200 for transmitting and receiving wireless communication signals (e.g., OFDM / OFDMA signals) according to some embodiments of this solution is shown. System 200 may include components and elements configured to support known or conventional operating features that do not need to be described in detail herein. In one illustrative embodiment, as described above, system 200 may be used in applications such as... Figure 1 The wireless communication environment 100 is a wireless communication environment in which communication (e.g., sending and receiving) data symbols are performed.

[0043] System 200 typically includes a base station 202 (hereinafter referred to as "BS 202") and a user equipment 204 (hereinafter referred to as "UE 204"). BS 202 includes a BS (Base Station) transceiver module 210, a BS antenna 212, a BS processor module 214, a BS memory module 216, and a network communication module 218, each module being coupled and interconnected with each other via a data communication bus 220 when necessary. UE 204 includes a UE (User Equipment) transceiver module 230, a UE antenna 232, a UE memory module 234, and a UE processor module 236, each module being coupled and interconnected with each other via a data communication bus 240 when necessary. BS 202 communicates with UE 204 via a communication channel 250, which can be any wireless channel or other medium suitable for data transmission as described herein.

[0044] As those skilled in the art will understand, system 200 may also include, in addition to Figure 2Any number of modules other than those shown. Those skilled in the art will understand that the various illustrative blocks, modules, circuits, and processing logic described in conjunction with the embodiments disclosed herein can be implemented in hardware, computer-readable software, firmware, or any practical combination thereof. To clearly illustrate this interchangeability and compatibility of hardware, firmware, and software, they have been generally described in terms of the functionality of the various illustrative components, blocks, modules, circuits, and steps. Whether such functionality is implemented as hardware, firmware, or software can depend on the specific application and design constraints on the overall system. Those skilled in the art can implement such functionality in a suitable manner for each specific application, but such implementation decisions should not be construed as limiting the scope of this disclosure.

[0045] According to some embodiments, UE transceiver 230, referred to herein as "uplink" transceiver 230, includes a radio frequency (RF) transmitter and an RF receiver, each of which includes circuitry coupled to antenna 232. A duplex switch (not shown) may alternatively couple the uplink transmitter or receiver to the uplink antenna in a time-division duplex manner. Similarly, according to some embodiments, BS transceiver 210, referred herein as "downlink" transceiver 210, includes an RF transmitter and an RF receiver, each of which includes circuitry coupled to antenna 212. A downlink duplex switch may alternatively couple the downlink transmitter or receiver to downlink antenna 212 in a time-division duplex manner. The operation of the two transceiver modules 210 and 230 can be time-coordinated such that the uplink receiver circuitry is coupled to the uplink antenna 232 to receive transmissions on the radio transmission link 250 while the downlink transmitter is coupled to the downlink antenna 212. Conversely, the operation of the two transceivers 210 and 230 can be time-coordinated, such that the downlink receiver is coupled to the downlink antenna 212 to receive transmissions on the wireless transmission link 250 while the uplink transmitter is coupled to the uplink antenna 232. In some embodiments, there is tight time synchronization with a minimum guard time between changes in duplex direction.

[0046] UE transceiver 230 and base transceiver 210 are configured to communicate via wireless data communication link 250 and cooperate with RF antenna devices 212 / 232 that are appropriately configured to support specific wireless communication protocols and modulation schemes. In some illustrative embodiments, UE transceiver 230 and base transceiver 210 are configured to support industry standards such as Long Term Evolution (LTE) and emerging 5G standards. However, it should be understood that this disclosure is not necessarily limited to specific standards and associated protocols in application. Instead, UE transceiver 230 and base transceiver 210 may be configured to support alternative or additional wireless data communication protocols, including future standards or variations thereof.

[0047] According to various embodiments, for example, BS 202 may be an evolved Node B (eNB), serving eNB, target eNB, femtobase station, or picobase station. In some embodiments, UE 204 may be embodied as various types of user equipment, such as mobile phones, smartphones, personal digital assistants (PDAs), tablets, laptops, wearable computing devices, etc. Processor modules 214 and 236 may be implemented or realized using a general-purpose processor, content-addressable memory, digital signal processor, application-specific integrated circuit, field-programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. In this way, the processor may be implemented as a microprocessor, controller, microcontroller, state machine, etc. The processor may also be implemented as a combination of computing devices, such as a combination of a digital signal processor and a microprocessor, multiple microprocessors, a combination of one or more microprocessors with a digital signal processor core, or any other such configuration.

[0048] Furthermore, the steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be directly embodied in hardware, firmware, software modules executed by processor modules 214 and 236 respectively, or any actual combination thereof. Memory modules 216 and 234 can be implemented as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. In this regard, memory modules 216 and 234 can be coupled to processor modules 210 and 230 respectively, such that processor modules 210 and 230 can read information from and write information to memory modules 216 and 234 respectively. Memory modules 216 and 234 can also be integrated into their respective processor modules 210 and 230. In some embodiments, memory modules 216 and 234 may each include a cache memory for storing temporary variables or other intermediate information during the execution of instructions to be executed by processor modules 210 and 230 respectively. Memory modules 216 and 234 may each include non-volatile memory for storing instructions to be executed by processor modules 210 and 230, respectively.

[0049] Network communication module 218 typically refers to hardware, software, firmware, processing logic, and / or other components of base station 202 that enable bidirectional communication between base transceiver 210 and other network components and communication nodes configured to communicate with base station 202. For example, network communication module 218 may be configured to support Internet or WiMAX traffic. In a non-limiting typical deployment, network communication module 218 provides an 802.3 Ethernet interface, enabling base transceiver 210 to communicate with traditional Ethernet-based computer networks. In this way, network communication module 218 may include a physical interface for connecting to a computer network (e.g., a Mobile Switching Center (MSC)). As used herein with respect to a particular operation or function, the terms “configured for,” “configured as,” and variations thereof refer to devices, components, circuits, structures, machines, signals, etc., that are physically constructed, programmed, formatted, and / or arranged to perform a particular operation or function.

[0050] The Open Systems Interconnection (OSI) model (referred to herein as the "OSI model") is a conceptual and logical layout that defines network communications used by systems (e.g., wireless communication devices, wireless communication nodes) that interconnect and communicate with other systems. The model is divided into seven sub-components or layers, each representing a conceptual set of services offered to the layers above and below it. The OSI model also defines logical networks and effectively describes computer packet transmission using different layer protocols. The OSI model can also be referred to as the seven-layer OSI model or the seven-layer model. In some embodiments, the first layer may be the physical layer. In some embodiments, the second layer may be the Media Access Control (MAC) layer. In some embodiments, the third layer may be the Radio Link Control (RLC) layer. In some embodiments, the fourth layer may be the Packet Data Convergence Protocol (PDCP) layer. In some embodiments, the fifth layer may be the Radio Resource Control (RRC) layer. In some embodiments, the sixth layer may be the Non-Access Stratum (NAS) layer or the Internet Protocol (IP) layer, and the seventh layer is other layers.

[0051] 2. System and method for dynamically changing multicast / broadcast services between multicast and unicast while maintaining service continuity Figure 3

[0052] Broadcast technologies in cellular networks struggle to provide service reliability over the air interface. For example, existing 3GPP Single Cell Point to Multi-point (SC-PTM) and MBSFN (Multimedia Broadcast multicast / broadcast service Single Frequency Network) do not provide HARQ or ARQ feedback and retransmission. When UE reception quality degrades and service reliability / continuity is required, the UE can only switch between unicast and broadcast transmissions via application-layer schemes.

[0053] Meanwhile, for SC-PTM services, if a mobile UE discovers that a neighboring cell does not provide broadcast services, the UE can initiate a unicast connection between the server and the UE at the application layer, allowing the service to continue during the UE's movement. However, the application layer has a limitation: the time from confirming the service (that multicast or broadcast services are not available in the target cell) to receiving multicast and broadcast service data in the target cell via unicast may introduce a relatively long service interruption time. In some services, such as MCPTT (Mission Critical Push to Talk) used for public safety, service quality degradation or even interruption is unacceptable.

[0054] A potential approach is to directly implement the handover between point-to-point (PTP or unicast) and point-to-multipoint (PTM or multicast) transmissions of multicast / broadcast services on the access network side of the cellular network. This technical goal has become a consensus in the 3GPP New Work Item: NR MBS (3GPP New Work Item, New Work Item on NR support of Multicast and Broadcast Services) (RP-193248). This paper presents systems and methods for switching delivery modes (e.g., unicast or multicast) in the access network for multicast / broadcast services. This paper primarily discusses this approach for multicast / broadcast services in 3GPP systems, where the receiving UE can be identified by the access network. The terms multicast, broadcast, and multicast / broadcast are used interchangeably.

[0055] Now for reference Figure 4AThis diagram illustrates a communication sequence of an example sequence for dynamically changing the multicast / broadcast service delivery mode between multicast and unicast while maintaining service continuity. In step 0, the UE (e.g., UE 104) may request or acquire multicast / broadcast service from the network. In step 1, the UE may receive a configuration (sometimes referred to as step 1 configuration) to correctly receive multicast / broadcast service data. This can also be a reconfiguration based on interactions between the UE and the network that occurred prior to the configuration. For a given UE, reconfiguration enables dynamic switching between multicast (PTM) and unicast (PTP) multicast / broadcast service delivery while maintaining service continuity. In step 2, based on the received configuration, the UE configures its local protocol stack and receives multicast and broadcast service data in the UE air interface (sometimes referred to herein as step 2 configuration). Multicast / broadcast service data transmission may have already occurred before a specific UE acquires the multicast / broadcast service data transmission, in cases where the multicast / broadcast service has already been acquired by another UE.

[0056] A. Information carried by the UE in step 0

[0057] For multicast / broadcast services, the UE requests the service from the network, enabling the 3GPP system to allocate corresponding resources for the multicast / broadcast service. This data is then sent to the access network node and cell where the UE resides. The UE carries a service identifier during the application process. The multicast / broadcast service identifier is at least one or a combination of the following options: session ID, IP multicast address (with or without a source address), TMGI (Temporary Mobile Group Identity), NAS (Non-Access Stratum) layer or application layer ID used to identify the service, G-RNTI (Group Radio Network Temporary Identity), and other possible AS layer IDs used to identify the service. The network and the UE use the above identifiers or combinations of identifiers to uniquely identify the multicast / broadcast service.

[0058] The session ID can be assigned by the UE itself and is used to uniquely identify multicast / broadcast service sessions within the UE. In addition, the UE can also carry other service description information in the service request (or service application), including S-NSSAI (Single Network Slice Selection Assistance Information) for identifying service slice information and DNN (Data Network Name) for identifying gateway information. In some implementations, the recipient of the above request can be a multicast / broadcast service session management function or a network entity in the core network, or it can be an access network node, such as a gNB or more specifically a gNB-CU (Central Unit).

[0059] B. Configuration content in step 1

[0060] The configuration provided by the network in step 1 (sometimes referred to as the step 1 configuration) may include the multicast / broadcast radio bearer (MRB) configuration, SDAP configuration, PDCP configuration, RLC bearer configuration, RLC configuration, and multicast / broadcast MAC / PHY configuration set serving multicast / broadcast services. This configuration may also include operations on the multicast radio bearer configuration, RLC bearer configuration, and multicast / broadcast MAC / PHY configuration set. Operations may include adding, modifying, suspending, and releasing.

[0061] The UE configures its local protocol stack according to the above configuration, such as establishing an MRB, modifying an existing MRB, releasing or suspending an existing MRB; establishing an RLC bearer, modifying an existing RLC bearer, suspending or releasing an existing RLC bearer. MRB configuration includes SDAP configuration and PDCP configuration. RLC bearer configuration also includes corresponding RLC configuration and MAC logical channel configuration. The UE establishes the corresponding MRB after receiving the configuration, or when the UE receives the first multicast / broadcast service data packet or the first MAC PDU corresponding to the multicast / broadcast service. For example, when receiving multicast / broadcast services, the UE only establishes the corresponding RLC entity and PDCP entity after receiving the first MAC PDU. The UE can also establish the corresponding RLC entity and PDCP entity after the first establishment operation.

[0062] There may be MRBs serving specific multicast / broadcast services. For a given multicast / broadcast service, the UE can receive operations on the MRB list, i.e., establishing, modifying, or releasing an MRB. The configuration of a specific MRB can be provided in step 1. This configuration includes the configuration of the SDAP and PDCP entities associated with the MRB. For a specific MRB of a specific multicast / broadcast service, the UE can receive operations to add, modify, suspend, or release RLC bearers associated with the specific MRB. For a given MRB of a multicast / broadcast service, one or two RLC bearers can be associated in different scenarios, and the network completes the aforementioned association modification through step 1. The configuration in step 1 also includes MAC / PHY-related configurations associated with the multicast / broadcast service. The configuration in step 1 will be described in more detail below.

[0063] In the above configuration, the MRB configuration includes SDAP configuration, where the SDAP configuration includes a session ID that identifies the multicast / broadcast service session. The session ID can be used to identify subsequent configuration information, enabling the UE to determine that subsequent configurations are associated with a specific multicast / broadcast service. The session ID can be the session ID carried in the signaling when the UE requests the multicast / broadcast service in step 0.

[0064] The MRB configuration also includes an MRB Identity (MRB ID), which uniquely identifies the MRB serving multicast / broadcast services across multiple radio bearers. Service data flows corresponding to multicast / broadcast services are sent from the core network to the access network nodes at the granularity of QoS flows. QoS flow data is mapped to one or more MRBs by the SDAP entity associated with the multicast / broadcast service (it should be noted that each QoS flow can only be mapped to one specific MRB), and each MRB is associated with a PDCP entity.

[0065] The aforementioned RLC bearer configuration may include the served radio bearer (identified by the MRB ID), the RLC entity configuration, and the corresponding MAC logical channel (identified by the Logical Channel ID (LCID)). The PDCP entity associated with the MRB may be associated with one or both of the two types of RLC bearers, which are defined as Type 1 and Type 2, respectively. Type 1 RLC bearers can be point-to-point (PTP) or unicast, while Type 2 RLC bearers can be point-to-multipoint (PTM) or multicast. The RLC entity associated with a Type 1 RLC bearer is referred to as a Type 1 RLC entity, and the RLC entity associated with a Type 2 RLC bearer is referred to as a Type 2 RLC entity.

[0066] Now for reference Figure 4B and Figure 5This diagram illustrates the communication schemes of the delivery scheme from both the Radio Access Network (RAN) and User Equipment (UE) perspectives. From a network perspective, the difference between the two types of RLC entities is that a Type 1 RLC entity (RLC1-1 and RLC2-1) (peer RLC entities in the network, as shown on the network side, RLC1-1, RLC2-1) can serve only a specific UE (e.g., UE1, UE2), while a Type 2 RLC entity (RLC2-2, RLC3-2) (peer RLC entity (RLC0) in the network) can serve at least one UE (e.g., UE2, UE3). All or part of the configuration of an RLC entity or RLC bearer can be shared by multiple UEs. In other words, multiple UEs receiving multicast / broadcast services in PTM mode can share the same peer RLC entity on the network side. For example, the network side can generate and transmit RLC PDUs received by multiple UEs using the shared RLC entity. For the same MRB associated with the same multicast / broadcast service, its PDCP PDU is replicated and delivered to all RLC entities associated with that MRB. Within a CU, there may be only one MRB for one or more QoS flows of the same multicast / broadcast service.

[0067] This configuration may also include a MAC / PHY configuration set for multicast / broadcast services. The MAC / PHY configuration set further includes at least one of the following configurations: a MAC DRX configuration corresponding to the multicast / broadcast service, and a physical layer identifier (e.g., G-RNTI) for monitoring the multicast / broadcast service at the physical layer (G-RNTI or group radio network temporary identifier is used to identify physical layer transmissions of the multicast / broadcast service or multicast / broadcast service group); a list of cell groups or cell IDs associated with the multicast / broadcast service; a channel state information measurement configuration (CSI measurement configuration); and a BWP configuration or BWP index associated with the multicast / broadcast service in a specific cell. The aforementioned BWP configuration may also include: frequency domain location and bandwidth for scheduling the multicast / broadcast service on physical resources, subcarrier spacing and cyclic prefix (CP), and physical downlink shared data channel (PDSCH) and physical downlink control channel (PDCCH) configurations.

[0068] Depending on the UE's multicast / broadcast service reception characteristics, MRB characteristics, or RLC mode, the association between the PDCP entity and the RLC entity associated with the MRB serving the multicast / broadcast service is at least one of the following.

[0069] For an MRB configured with one Type 1 RLC bearer, each PDCP entity can be associated with one AM (Acknowledged Mode) RLC entity or two UM (Unacknowledged Mode) RLC entities (one in each direction), where each UM RLC entity includes or corresponds to a Type 1 RLC entity (or a Type 1 RLC entity). In this case, an MRB serving multicast / broadcast services can be associated with a Type 1 RLC bearer. The associated RLC entity and RLC bearer are PTP type RLC entities and RLC bearers. The RLC entity can be an AM attribute RLC entity or a UM attribute RLC entity. In this case, the UE receives MRB data for multicast / broadcast services in PTP mode. The network can configure the corresponding RLC entity with AM or UM attributes based on the characteristics of the service. For example, in the QoS characteristics of an MRB corresponding to a multicast / broadcast service, if the packet delay budget is high and the packet error rate is low, the corresponding RLC entity can be configured in AM mode. If the packet delay budget is low and the packet error rate is high, the corresponding RLC entity can be configured in UM mode.

[0070] For an MRB configured with a Type 2 RLC bearer, each PDCP entity can be associated with at least one UM downlink (DL) RLC entity that includes or corresponds to a Type 2 RLC entity (or a Type 2 RLC entity). In this case, the MRB serving multicast / broadcast services can be associated with a Type 2 RLC bearer. The associated RLC entity and RLC bearer can be PTM type RLC entities and RLC bearers. The RLC entity can be an RLC entity with UM attributes. In this case, the UE receives MRB data for multicast / broadcast services in PTM mode. The network can configure the reception behavior of the corresponding DL RLC entity to have UM attributes.

[0071] For an MRB configured with both Type 1 RLC bearers and Type 2 RLC bearers, each PDCP entity can be associated with: one AM RLC entity or two UM RLC entities (one for each direction), and at least one UM DL RLC entity. In this case, the MRB serving multicast / broadcast services can be associated with both Type 1 and Type 2 RLC bearers. The Type 1 RLC entity associated with the RLC bearer can be an RLC entity with AM or UM attributes. The Type 2 RLC entity associated with the RLC bearer can be an RLC entity with UM attributes.

[0072] In different scenarios, Type 1 RLC entities provide different functions. For example, in some scenarios, a Type 1 RLC entity (if any) is responsible for receiving initial transmission data via PTP from a peer PDCP entity in a network serving a multicast / broadcast service. A Type 2 RLC entity (if any) serving the same MRB is responsible for receiving initial transmission data from a peer PDCP entity in the same MRB serving the multicast / broadcast service. The copied PDCP PDUs are discarded at the PDCP layer. If in-order delivery is required, reordering is performed at the PDCP layer. By enabling both Type 1 RLC and Type 2 RLC bearers to receive initial transmission data from peer PDCP entities in a network serving a multicast / broadcast service, the reception reliability of the corresponding MRB is expected to be enhanced.

[0073] In another scenario, a Type 1 RLC entity (if any) is responsible for receiving retransmissions from a peer PDCP entity in a network serving a multicast / broadcast service using PTP, while a Type 2 RLC entity is responsible for receiving initial transmissions from the same peer PDCP entity in the same network serving a multicast / broadcast service using PTM. In the same scenario, the Type 1 RLC entity can be responsible for the uplink transmission of PDCP status reports for the MRB serving the multicast / broadcast service. In the above configuration, the Type 1 RLC bearer and the Type 2 RLC bearer can be configured independently. For example, Type 1 RLC and Type 2 RLC can be different RLC modes.

[0074] C.RLC bearer configuration related operations

[0075] In different scenarios, the UE can receive different configurations and corresponding operations provided by the network, and receive specific multicast / broadcast services under different reception modes (PTM, PTP, or both). The UE can switch from one mode to another, or receive services based on two modes simultaneously. The above mode switching process relies on the same MRB associated with multicast / broadcast services of different types of RLC bearers (Type 1 only, Type 2 only, or both). Based on the above scheme, flexible switching between PTP, PTM, and both PTP and PTM can be supported when receiving the MRB of multicast / broadcast services.

[0076] To implement the above handover process flexibly and efficiently, further improvements to the signaling design may be needed to reduce latency. This section focuses on the related operations in the configuration. Before expanding on the operational descriptions, there are two types of operational granularity:

[0077] (1) The receiving mode switching operation (including switching between PTP or PTM and their combinations) can be an operation specific to a particular multicast / broadcast service. Therefore, this operation applies to all MRBs serving the multicast / broadcast service. All multicast radio bearers serving the multicast / broadcast service will perform the corresponding related operation. This operation is based on a "per multicast / broadcast service" granularity; and

[0078] (2) The receiving mode switching operation (including switching between PTP or PTM and their combinations) is an operation for a specific MRB or part of the MRB serving the multicast / broadcast service, based on the “per MRB” operation granularity.

[0079] In some embodiments, the RLC bearer of a certain MRB serving multicast / broadcast services in the configuration received by the UE is a Type 1 attribute, and the UE receives multicast / broadcast services according to the RLC bearer included in the cell group configuration in the reconfiguration message. In this case, the UE receives multicast / broadcast services in PTP mode. The process is as follows: The UE receives data based on a specific UE physical layer identifier (e.g., C-RNTI (Cell-Radio Network Temporary Identifier) ​​or a configured Scheduling RNTI (CS-RNTI)). Then, the MAC entity delivers the MAC PDU to the appropriate logical channel (LCH) according to the LCID and RLC bearer configuration in the data packet, and then the corresponding RLC entity and PDCP entity receive and process the multicast / broadcast service data at the corresponding layer.

[0080] In some embodiments, the RLC bearer of a certain MRB serving the multicast / broadcast service in the configuration received by the UE is of type 2 attribute, and the UE receives the multicast / broadcast service in PTM mode. The process is as follows: The UE detects and receives multicast / broadcast service data according to the Physical Layer Identifier (G-RNTI) associated with the multicast / broadcast service in the Physical Layer. Then, the MAC entity delivers the MAC PDU to the corresponding LCH according to the LCID in the data packet. Then, the corresponding RLC entity and PDCP entity receive and process the multicast / broadcast service data in the corresponding layer.

[0081] Now for reference Figure 6This diagram illustrates the communication flow of a handover scheme from the user equipment (UE) perspective. Using the same MRB, by associating different types of RLC bearers and their associated MAC / PHY configuration sets, as well as combinations of different types of RLC bearers, the UE can switch between different reception modes or receive simultaneously using different modes. Based on the description in the previous section, the configuration provided by the network in Step 1 may include the session ID corresponding to the multicast / broadcast service in the SDAP configuration and the MRB ID in the MRB configuration; and the RLC bearer configuration associated with the MRB may include a PTP type RLC bearer or a PTM type RLC bearer, or a combination of both. The handover described above can be implemented through related operations of the configuration content included in the configuration in Step 1. These operations include adding, modifying, suspending, and releasing operations corresponding to at least one of the following configurations: MRB configuration (including PDCP entity configuration), RLC bearer configuration (including RLC entity configuration), and MAC / PHY configuration set.

[0082] In one scenario, such as receiving a specific multicast / broadcast service for a UE, the network configures the UE from PTM reception to PTP reception according to the granularity of the multicast / broadcast service or the specific MRB serving the multicast / broadcast service. The configuration in step 1 may include releasing PTM-type RLC bearers and adding PTP-type RLC bearers for all MRBs or a specific MRB serving the multicast / broadcast service. Conversely, if the network configures the UE from PTP reception to PTM reception, the configuration in step 1 may include releasing PTP-type RLC bearers and adding PTM-type RLC bearers for all MRBs or a specific MRB serving the multicast / broadcast service.

[0083] To reduce the aforementioned signaling latency or overhead, the network can add corresponding indication fields, such as enable or disable bits, to the configuration of each or some of the RLC bearers. For example, the RLC bearer associated with each MRB serving multicast / broadcast services corresponds to two possible states: enabled or disabled. In this case, the RLC bearer associated with a specific MRB serving multicast / broadcast services can correspond to the following three possible states (where "1" represents "enabled" and "0" represents "disabled" in the description field):

[0084] • PTP-type RLC bearers are enabled, and PTM-type RLC bearers are disabled, with the description field representing "1" and "0" respectively. In this case, the MRB receives multicast / broadcast services via PTP.

[0085] • PTP-type RLC bearers are disabled, and PTM-type RLC bearers are enabled, with the description field representing "0" and "1" respectively. In this case, the MRB receives multicast / broadcast services in PTM mode.

[0086] Both PTP and PTM type RLC bearers are enabled, and their description fields can be represented as "1" and "1" respectively. In this case, the MRB receives multicast / broadcast services using a combination of PTP and PTM. The PTP type RLC bearer performs different functions depending on the scenario. For example, in a PDCP retransmission scenario, to improve reliability, the PTP type RLC bearer is responsible for receiving PDCP retransmission data and / or transmitting PDCP status reports to the network in the uplink. However, in a mode switching scenario, the PTP RLC entity is responsible for receiving initial transmissions and / or retransmissions from the peer PDCP entity in the network serving the multicast / broadcast service, and / or sending the corresponding MRB's PDCP status report.

[0087] It should be noted that such an enable / disable indication mechanism can be used for PTM RLC bearers, or such an indication can be used to indicate both PTP RLC bearers and PTM RLC bearers separately.

[0088] The aforementioned enable and / or disable operations can be indicated at a lower layer. For example, the MAC CE (MAC Control Element) or Layer 1 Downlink Control Information (DCI) signaling sent to the UE contains an identifier for the multicast / broadcast service (identified by the G-RNTI or session ID or other ID that the UE can use to identify the multicast / broadcast service), and / or the bearer identifier for the multicast / broadcast service, as well as an enable or disable indication field. If the operation is per multicast / broadcast service, it is not necessary to carry the bearer identifier for the multicast / broadcast service, such as the bearer's MRB ID.

[0089] If the enable or disable information of the aforementioned RLC bearer is indicated by RRC signaling, the RRC signaling also indicates whether the operation is for each multicast / broadcast service or for each MRB or MRB list serving the multicast / broadcast service.

[0090] In some embodiments, the disable operation corresponding to the RLC bearer indicates the release of the RLC bearer or the suspension of the RLC bearer.

[0091] The aforementioned disabling operation can correspond to the RLC bearer release operation in the existing standard. That is, the operation also corresponds to the release of one or more associated RLC entities and the release of the corresponding LCH.

[0092] The aforementioned disable operation can correspond to an RLC bearer suspension operation. RLC bearer suspension corresponds to the suspension operation of the corresponding RLC entity and the release of the corresponding LCH of the RLC entity. If the corresponding LCH is released, the corresponding MAC entity discards the data to be delivered to the corresponding LCH.

[0093] The above-mentioned suspend operation of the RLC entity also includes the following possible operations and combinations of related operations (t-reassembly is a timer used for reassembly, which the receiving RLC entity uses to detect the loss of lower-level RLC PDUs):

[0094] • If t-recombination is in progress, stop and reset t-recombination;

[0095] • Discard all RLC SDUs, RLC SDU segments, and RLC PDUs (if any); and

[0096] • Set all state variables to their initial values.

[0097] In some embodiments, the enable operation corresponding to the RLC bearer indicates the reconstruction of the associated RLC entity. The RLC bearer reconstruction operation corresponds to the following steps: after the MAC receives data to be delivered to the corresponding LCH, it delivers the data to the corresponding LCH. After reconstruction, the RLC entity enters the working state from suspension: reassembles the received data packets and starts the corresponding reassembly timer (t-reassembly).

[0098] Step 1 configuration may include releasing the MAC / PHY configuration set associated with the multicast / broadcast service. With this configuration, the receiving UE's MAC entity no longer monitors the G-RNTI for the multicast / broadcast service. The MAC may perform further operations, including: stopping the reception of services at least in the physical layer of PTM mode, releasing the HARQ process associated with the G-RNTI, refreshing the HARQ buffer, and releasing the DRX configuration for the multicast / broadcast service. The receiving UE also releases other MAC / PHY configuration sets associated with the multicast / broadcast service.

[0099] The configuration in step 1 may include suspending the MAC / PHY configuration set associated with the multicast / broadcast service. With this configuration, the MAC entity of the receiving UE no longer monitors the G-RNTI for the multicast / broadcast service. The MAC may perform further operations, including: stopping the reception of services at least in the physical layer of PTM mode, releasing the HARQ process associated with the G-RNTI, refreshing the HARQ buffer, and releasing the DRX configuration for the multicast / broadcast service. When the configuration of the MAC / PHY configuration set associated with the multicast / broadcast service is suspended or canceled, the configuration itself is stored by the UE and not released.

[0100] Step 1 configuration may include rebuilding the MAC / PHY configuration set associated with the multicast / broadcast service. Through this rebuilding operation, the UE-side MAC entity restores the G-RNTI for monitoring the multicast / broadcast service and receives service data according to the physical layer configuration. The MAC may perform further operations, including: receiving service data in PTM mode on the air interface according to the stored MAC / PHY configuration set. Simultaneously, all or some types of 2RLC bearers associated with the UE-side multicast / broadcast service are re-established.

[0101] If all Type 2RLC bearers corresponding to the multicast / broadcast service are released, the MAC / PHY configuration set associated with the multicast / broadcast service is suspended or released. If at least one MRB associated with a Type 2RLC bearer is in receive mode, the MAC / PHY configuration set associated with the multicast / broadcast service is not suspended or released. If any Type 2RLC bearer is added or rebuilt, the MAC / PHY configuration set associated with the multicast / broadcast service is rebuilt.

[0102] The RLC bearer configuration and associated MAC / PHY configuration set with the aforementioned PTM attributes can be provided via multicast or broadcast channels and broadcast within the cell; alternatively, they can be provided via dedicated signaling, i.e., sent from the network to a specific UE in a point-to-point manner. In some scenarios, the configuration received by the UE may include an enable indication of the RLC bearer configuration with PTM attributes, and then the UE obtains the corresponding PTM type RLC configuration and / or MAC / PHY configuration set associated with the multicast / broadcast service via the broadcast channel. More specifically, the enable indication may also provide broadcast channel scheduling information, such as frequency domain, time domain, scheduling period, and time offset values, or a combination of the above information.

[0103] To minimize service interruptions to the UE when switching between the two types of RLC bearers for associated MRBs or all MRBs of multicast / broadcast services, a timer variable t_Switch is provided in the network-provided configuration. The UE starts the timer after receiving the configuration and releases or suspends a specific RLC bearer after the timer expires.

[0104] To minimize service interruptions to the UE when switching between the two types of RLC bearers for associated MRBs or all MRBs of multicast / broadcast services, the release or suspension of an RLC bearer will trigger a PDCP status report in the network-provided configuration. For example, when a UE switches an MRB for a multicast / broadcast service from PTM or "PTP and PTM" reception to PTP reception, the UE will be triggered to execute a PDCP status report if PDCP status reporting is enabled in the corresponding network configuration.

[0105] D. Specific receiving behaviors based on RLC bearer configuration

[0106] During multicast / broadcast service reception, the UE performs the following related configurations on the MAC / PHY based on the G-RNTI associated with the MAC / PHY configuration set. The G-RNTI value corresponding to the multicast / broadcast service, along with associated MAC configurations (such as DRX configuration) and the serving cell ID or a list of serving cell IDs, can be provided to the MAC entity. When the MAC entity has the G-RNTI, it monitors the PDCCH of the G-RNTI during each TTI based on the DRX configuration. If the TTI and the downlink allocation of the serving cell or the list of serving cells have already been received on the PDCCH of the MAC entity's G-RNTI: an attempt is made to decode the received data; if the data the MAC entity attempts to decode is successfully decoded for that transport block: the decoded MAC PDU is delivered to the demultiplexing and demultiplexing entity.

[0107] The configuration of the RLC bearer included in step 1 may also include the associated LCID and the Radio Bearer Identity (RB ID) of the MRB served by the RLC bearer.

[0108] For the Radio Bearer Identifier (RB ID) of the MRB, there are two options depending on whether the RB ID space is shared between multicast / broadcast services and unicast services:

[0109] (1) From the UE's perspective, a separate RB ID space can be used between multicast / broadcast services received by the UE and unicast services received by the UE. The RB ID space between multicast / broadcast services can be distinguished based on G-RNTI or the session ID associated with G-RNTI. That is, the RB IDs of the MRBs of different multicast / broadcast services can be the same. Based on this assumption, the receiving RLC entity submits the RLC SDU to the associated PDCP entity according to two parameters: the RB ID of the MRB of the RLC bearer service in the RLC bearer configuration, and the G-RNTI or session ID associated with the received service data.

[0110] (2) From the UE's perspective, there is a shared RB ID space between the multicast / broadcast services received by the UE and the UE's unicast services. That is, the RB IDs of the MRBs of different multicast / broadcast services cannot be the same. Based on this assumption, the receiving RLC entity submits the RLC SDU to the associated PDCP entity according to a parameter: the RB ID of the MRB of the RLC bearer service in the RLC bearer configuration.

[0111] For LCIDs associated with Type 2 or PTM RLC bearer configurations, there are two options depending on whether the LCID space is shared between multicast / broadcast and unicast services:

[0112] (1) The LCID corresponding to type 2 RLC bearer has a single value: lcid2. From the perspective of each UE, an independent LCID space can be used between multicast / broadcast services received by the UE and unicast services of the UE. The LCID space between multicast / broadcast services can be distinguished based on G-RNTI or the session ID associated with G-RNTI. That is, the LCID of MRBs of different multicast / broadcast services can be the same. Based on this assumption, the receiving MAC entity submits the service data in the received MAC PDU to the associated logical channel according to two parameters: the LCID associated with the received service data in the received MAC PDU, and the G-RNTI or session ID associated with the received service data.

[0113] (2) The LCID corresponding to type 2 RLC bearer is a pair of values: lcid2-1 and lcid2-2. From the perspective of each UE, the shared LCID space can be used between multicast / broadcast services received by the UE and unicast services received by the UE. That is, the LCIDs of MRBs of different multicast / broadcast services cannot be the same. Based on this assumption, if the LCID value in the subheader of the associated service data in the received MAC PDU is lcid2-1, the receiving MAC entity will submit the service data in the received MAC PDU to the logical channel identified by lcid2-2.

[0114] E. Retransmission Scenario

[0115] Now for reference Figure 7 This diagram illustrates the retransmission scheme from the user equipment (UE) perspective. Based on dual RLC bearers (Type 1 RLC bearer and Type 2 RLC bearer) associated with the MRB serving multicast / broadcast services, retransmission from peer PDCP entities in the network to the MRB can be achieved. The initial transmission from the peer PDCP entity in the MRB network is received by the Type 2 RLC bearer of type PTM. Regardless of whether there is UE feedback, retransmission of multicast / broadcast service data from the peer PDCP entity in the MRB network is received by the Type 1 RLC bearer of type PTP. As shown in the diagram, the RLC entity corresponding to the Type 1 RLC bearer is RLC1, and the RLC entity corresponding to the Type 2 RLC bearer is RLC2. The physical layer identifier used by the MAC entity to monitor multicast / broadcast services is G-RNTI, while the physical layer identifier used by the MAC entity to monitor PTP transmissions is C-RNTI or CS-CRNTI.

[0116] The UE generates a corresponding PDCP Status Report (PDCP SR) based on the reception status of the corresponding PDCP entity. The UE sends the PDCP SR to the peer PDCP entity on the network side via a Type 1 RLC bearer or a PTP-type RLC bearer. The network-side PDCP entity can maintain a specific UE's reception status context. This context records the PDCP status reports received by the UE, including lost PDCP PDU SN information. Based on the PDCP SR, the network retransmits lost PDC PDUs for the UE.

[0117] F.PDCP Status Report

[0118] In the handover and retransmission scenarios described above, one of the key factors is the PDCP status report provided by the UE. For example, the network can determine the appropriate reception mode (PTP, PTM, or both) for the UE based on the status report of one or more specific MRBs serving multicast / broadcast services. In the retransmission scenario, the network can use the UE's status report to identify PDCP SNs that were not successfully sent to the UE, thus enabling retransmission.

[0119] The triggering conditions and content of the relevant PDCP status report are listed below:

[0120] 1- For a specific MRB received from a PTM type RLC bearer, that MRB is then configured to receive from a PTP type RLC bearer in conjunction with a suspend or release operation of a type 2 or PTM type RLC bearer. With PDCP SR enabled for the MRB, such a configuration can trigger PDCP SR for Receive PDCP.

[0121] 2. For a specific MRB received from a PTM-type RLC bearer, the MRB is then configured to receive from both PTM and PTP modes in conjunction with the establishment operation of a Type 1 or PTP-type RLC bearer. With PDCP SR enabled for the MRB, such a configuration can trigger PDCP SR for PDCP reception.

[0122] 3. Suspension or release of the MAC / PHY configuration set associated with multicast and broadcast services may result in the loss of some data. PDCP SR can be triggered if a Type 1 or PTP type RLC bearer associated with the MRB still exists.

[0123] 4. In the event of a degraded reception quality for a multicast / broadcast service in MRB or PTM mode, triggering a PDCP SR allows the network to become aware of the reception quality as early as possible. The network can perform any action (such as reception mode switching) to improve reception quality, enabling the UE to receive multicast / broadcast services in PTP mode. Therefore, the UE can directly monitor reception quality at the MAC layer, such as the BLER (Block Error Rate) of transport blocks. Once the configured BLER threshold is reached, the PDCP SR is triggered. The network-provided configuration can include the BLER threshold at the MAC layer or its derived values, such as the threshold of the result after filtering within a certain time window t_Window. If a certain threshold is reached, the UE is triggered to perform a PDCP SR on the PDCP entity associated with the PTP-type RLC bearer, allowing the network to know the reception status of the corresponding MRB or multicast / broadcast service.

[0124] The 5-network can be configured with corresponding measurement reference signals, such as channel state information reference signals associated with multicast / broadcast services. If the measurement result associated with the configured reference signal falls below a certain threshold, the PDCP SR is triggered.

[0125] 6-PDCP SR can also be triggered directly by PDCP layer reception statistics. The network defines a threshold for the PDCP Sequence Number (SN) gap value or length. The PDCP SN gap represents the difference between the SN of the first lost PDCP PDU and the SN of a subsequent successfully received PDCP PDU. Once the threshold is reached, PDCP SR is triggered. Other PDCP reception statistics can be defined, such as the percentage of PDCP PDUs lost within a configured time window or SN length window (t_Windows or SN_Window) out of the total PDCP PDUs. Once this percentage is reached, PDCP SR is triggered. The number N of packets waiting to be reordered in the PDCP entity can also provide the reception status of the MRB. If the value N is higher than a configured threshold, PDCP SR is triggered. PDCP SR is also triggered directly when the PDCP reordering timer expires. In the MRB configuration, the network can add an enable bit that triggers PDCP SR based on the expiration of the reordering timer. If this bit is "TRUE", the UE is allowed to trigger PDCP SR under the above conditions.

[0126] 7- Timer-based network configurations include timers that periodically trigger the UE to perform PDCP SR for PDCP entities associated with bearers serving multicast / broadcast services. The timer configuration may include the timer's trigger period and / or time-domain offset. After receiving the configuration, the timer that triggers the PDCP SR is set based on the value of T_polling plus the time-domain offset.

[0127] 8-PDCP SR can also be triggered by the network. For example, the network can trigger a PDCP SR triggered by the PDCP control PDU. The control PDU can use a 1-bit indication field to indicate to the UE that the UE needs to perform a PDCP SR for the receive PDCP entity at the receive control PDU.

[0128] 9. Other forms of signaling from the network side. For example, the network instructs the UE to perform PDCP SR on a specific MRB for a specific multicast / broadcast service via MAC CE. The aforementioned information includes the MRB ID and the multicast / broadcast service identifier (G-RNTI, session ID, TMGI, or any identifier uniquely identifying the multicast / broadcast service). Furthermore, the network can instruct the UE to perform PDCP SR for a specified MRB using the MRB ID of the specified multicast / broadcast service, identified by the G-RNTI, session ID, TMGI, or any identifier uniquely identifying the multicast / broadcast service, on the Physical Downlink Control Channel (PDCCH) at the physical layer. It should be noted that the G-RNTI itself can be identified by the DCI of the PDCCH itself.

[0129] The status report of the corresponding PDCP entity should include at least one of the following:

[0130] • Count the last PDCP PDU received in sequence or the first missing PDCP PDU;

[0131] • The bitmap of the missing PDCP PDU;

[0132] • The number or ratio of PDCP PDUs lost in the time window (t_Window) or SN window.

[0133] G. Where should the PDCP SR be sent when there are two associated RLC entities?

[0134] An MRB serving multicast / broadcast services can be associated with two types of RLC bearers (Type 1 or PTP type, and Type 2 or PTM type, respectively). In existing 3GPP specifications, when more than one RLC entity is associated with a PDCP entity, one of the RLC entities is defined as the primary entity for transmitting PDCP control PDUs (including PDCP SRs). In the scenarios described above (e.g., mode switching between PTP and PTM, and between PTM / PTP, to deliver multicast / broadcast services) and in retransmission scenarios, PDCP control PDUs, such as PDCP SRs, may also be required. In both cases, the PDCP SR is transmitted on a Type 1 or PTP type RLC bearer or on an RLC entity associated with a PTP type RLC bearer. The RLC entity associated with a PTP type RLC bearer is the primary RLC entity. For an RB serving multicast / broadcast services, it is associated with more than one RLC entity and submits PDCP status reports to either a Type 1 RLC entity or a PTP type RLC entity.

[0135] H. Dynamically change multicast / broadcast service delivery

[0136] Now for reference Figures 1 to 6 This illustrates a flowchart of a method 700 for dynamically changing multicast / broadcast service delivery between multicast and unicast while maintaining business continuity. Method 700 can be used in conjunction with this document. ​ The components described are used to implement or are performed by these components. In general, method 700 may include transmitting a multicast / broadcast service request (705). Method 700 may include transmitting multicast / broadcast radio resource configuration information (710). Method 700 may include configuring the air interface protocol stack (715). Method 700 may include transmitting multicast / broadcast service data (720). Method 700 may include configuring or partially configuring multicast / broadcast services to enable or disable them (725).

[0137] More specifically, method 700 may include transmitting a multicast / broadcast service request (705). The terms multicast, broadcast, and multicast / broadcast are used interchangeably. In some embodiments, a wireless communication device (e.g., UE 104) may provide, transmit, or otherwise send a multicast / broadcast service request to a network (e.g., network 100). A multicast / broadcast service request may be an initiation of a multicast / broadcast service for the wireless communication device. The multicast / broadcast service request may be sent before receiving multicast / broadcast radio resource configuration.

[0138] In some embodiments, the wireless communication device may provide, transmit, or otherwise send multicast / broadcast service requests to the multicast / broadcast session management function or entity of the 3GPP core network. In some embodiments, the wireless communication device may provide, transmit, or otherwise send multicast / broadcast service requests to a radio access network (RAN) node. The RAN node may be, for example, a gNB or gNB-CU.

[0139] Method 700 may include transmitting multicast / broadcast radio resource configuration information (710). In response to receiving a multicast / broadcast service request, the network (or receiving node) may generate multicast / broadcast radio resource configuration information and return the information to the wireless communication device. The wireless communication device may then receive the multicast radio resource configuration information from the network (or the node receiving the multicast / broadcast service request). In some embodiments, the multicast radio resource configuration information may define, specify, or otherwise include: a multicast / broadcast radio bearer (MRB) configuration for serving multicast / broadcast services; a Service Data Adaptation Protocol (SDAP) configuration; a Packet Data Convergence Protocol (PDCP) configuration; a Radio Link Control (RLC) bearer configuration, an RLC configuration; or a multicast Media Access Control (MAC) and Physical (PHY) layer configuration set.

[0140] In some embodiments, SDAP configuration may include a multicast / broadcast service session identifier. The multicast / broadcast service session identifier can identify a session corresponding to a multicast / broadcast service. The multicast / broadcast service session identifier can also uniquely identify a session corresponding to a multicast / broadcast service within a wireless communication device.

[0141] In some embodiments, there may be a mapping relationship between MRB configurations and MAC / PHY configuration sets. MRB configurations may be identified by session IDs, while MAC / PHY configuration sets may be identified by G-RNTIs or other identifiers associated with multicast / broadcast services in the physical layer.

[0142] Mapping relationships can be provided or included via broadcast downlink channels and broadcast within the cell (e.g., cell 126). Mapping relationships can also be provided or included in dedicated signaling and sent to a specific UE (e.g., UE104).

[0143] In some embodiments, multicast / broadcast radio resource configuration information can specify one or more types of RLC bearers for multicast / broadcast services. A multicast / broadcast radio bearer can be configured to receive from one RLC entity of a type 1 RLC bearer. In this case, the PDCP entity can be associated with one acknowledged mode (AM) RLC entity or two unacknowledged mode (UM) RLC entities. A multicast / broadcast radio bearer can be configured to receive from one RLC entity of a type 2 RLC bearer. In this case, the PDCP entity can be associated with one UM downlink RLC entity. A multicast / broadcast radio bearer can be configured to receive from two RLC entities, each PDCP entity can be associated with one AM RLC entity or two UM RLC entities and one UM downlink RLC entity.

[0144] In some embodiments, a Type 1 RLC bearer can be configured with a point-to-point (PTP) attribute. In some embodiments, a Type 1 peer RLC entity on the network side can serve a specific UE. In some embodiments, a Type 2 RLC bearer can be configured with a point-to-multipoint (PTM) attribute. In some embodiments, a Type 2 peer RLC entity on the network side can serve at least one UE at a peer RLC entity on the network.

[0145] In some embodiments, a Type 2 RLC bearer may be associated with a MAC / PHY layer configuration set for a multicast / broadcast service. This configuration set may define, identify, or include a MAC Discontinuous Receive (DRX) configuration corresponding to the multicast / broadcast service. The configuration set may also define, identify, or include a list of cell groups or cell identifiers to which the multicast / broadcast service is scheduled. The configuration set may also define, identify, or include a Bandwidth Part (BWP) configuration or BWP index associated with the multicast / broadcast service. This configuration set may define, identify, or include a Physical Downlink Shared Data Channel (PDSCH) configuration and a Physical Downlink Control Channel (PDCCH) configuration.

[0146] Method 700 may include configuring the air interface protocol stack (715). Based on multicast / broadcast radio resource configuration information, the wireless communication device may configure its air interface protocol stack. The air interface protocol stack may define communication links (e.g., for multicast / broadcast radio services) between the wireless communication device and other radio access network nodes in the network. In some embodiments, the multicast / broadcast radio resource configuration information may include: operations defining or corresponding to multicast / broadcast radio bearer configurations; operations defining or corresponding to RLC bearer configurations; or operations defining or corresponding to MAC / PHY layer configuration sets. When configuring the air interface protocol stack, the wireless communication device may perform one or more operations defined by the multicast radio resource configuration information.

[0147] In some embodiments, a wireless communication device may determine or identify a logical channel for transmitting or receiving service data for a multicast / broadcast service based on the Logical Channel Identifier (LCID) and physical layer identifier (including a G-RNTI associated with a multicast / broadcast service or a session identifier associated with a physical layer identifier or a multicast / broadcast service) in a received MAC Protocol Data Unit (PDU). The Logical Channel Identifier (LCID) may identify or reference the RLC bearer of the multicast / broadcast service. The LCID may include at least two LCID values, namely lcid2-1 and lcid2-2. If the LCID value of the service data in the subheader or header of the received MAC PDU is lcid2-1, the MAC entity may submit the service data in the received MAC PDU to the logical channel identified by lcid2-2.

[0148] In some embodiments, the receiving RLC entity may uniquely deliver RLC Service Data Units (SDUs) to the associated PDCP entity based on the radio bearer identifier and physical layer identifier served in the RLC bearer configuration, wherein the physical layer identifier includes a G-RNTI associated with a multicast / broadcast service or a session identifier associated with a physical layer identifier or a multicast / broadcast service. In some embodiments, the RLC bearer configuration and MAC / PHY layer configuration set may be received from or provided by a broadcast channel and broadcast in the cell (e.g., cell 126). In some embodiments, the RLC bearer configuration and MAC or PHY layer configuration set may be received from or provided via dedicated signaling.

[0149] In some embodiments, the wireless communication device may perform step 2 configuration to configure the air interface protocol stack. In some embodiments, step 1 configuration may identify or include one or more operations. The operations configured in step 1 may include operations corresponding to a multicast / broadcast radio bearer configuration, operations corresponding to an RLC bearer configuration, or operations corresponding to a MAC / PHY configuration set. Step 1 may include receiving the configuration itself. Step 2 configuration may include applying or executing configuration on the air interface protocol stack.

[0150] In some embodiments, step 1 configuration may include triggering conditions for a PDCP status report corresponding to a PDCP entity associated with a multicast / broadcast radio bearer.

[0151] Triggering conditions may include receiving data from a PTP-type RLC bearer when a multicast / broadcast radio bearer is configured to receive data in conjunction with a suspend or release operation of a Type 2 or PTM type RLC bearer. In such cases, the wireless communication device receives service data from the multicast / broadcast radio bearer from PTM mode to PTP mode. If a PTM type or Type 2 RLC bearer is released, data loss may occur, and a PDCP status report will therefore be issued.

[0152] Triggering conditions may include when a multicast / broadcast radio bearer is configured to receive from a PTM-type RLC bearer, and the MRB can then be configured to receive from both PTM and PTP modes in conjunction with the establishment operation of a type 1 or PTP-type RLC bearer. With PDCP SR enabled for the MRB, such a configuration can trigger the reception of PDCP for PDCP SR. When receiving a multicast radio bearer from a PTM-type RLC bearer, the multicast radio bearer can be configured to receive from a PTP-type RLC bearer in conjunction with the suspension or release of a type 2 or PTM-type RLC bearer. When receiving a multicast radio bearer from a PTM-type RLC bearer, the multicast radio bearer can be configured to receive from both PTM and PTP modes in conjunction with the establishment of a type 1 or PTP-type RLC bearer.

[0153] When a UE receives bearer data in PTP mode, the UE can be triggered to report the bearer reception status. Triggering conditions may also include reaching the maximum block error rate (BLER) associated with multicast / broadcast services at the MAC / PHY layer (e.g., within a time window). Triggering conditions may also include reaching the minimum measured Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), or Signal-to-Interference-plus-Noise (SINR) value based on the physical layer reference signal for multicast / broadcast services.

[0154] Triggering conditions may also include reaching the maximum difference (e.g., PDCP sequence number) between the sequence number (SN) of the PDCP PDU from the first lost PDCP PDU to the successfully received PDCP PDU. Triggering conditions may also include reaching the maximum number of lost PDCP PDUs within a time window (t_window) or the maximum ratio of the number of lost PDCP PDUs to the total number of PDCP PDUs. Triggering conditions may include when the PDCP reordering timer expires. Triggering conditions may include when the maximum number of packets waiting to be reordered in the PDCP entity is reached (e.g., then the PDCP SR is triggered).

[0155] Triggering conditions may include when a PDCP Status Report (SR) is triggered by a PDCP control PDU, where a bit indicates that a PDCP SR is required. The control PDU can use this bit to indicate to the UE that a PDCP SR needs to be performed for the receiving PDCP entity to which the control PDU resides. Triggering conditions may also include when a timer periodically triggers the wireless communication device to perform a PDCP SR for a PDCP entity associated with a bearer of a service multicast / broadcast service. The timer configuration may include the timer's trigger period (T_polling) and time-domain offset. After receiving the configuration, the timer that triggers the PDCP SR is set based on the value of T_polling plus the time-domain offset.

[0156] Triggering conditions may include when the network signals the MAC CE to the wireless communication device to indicate that a specific bearer of a particular multicast / broadcast service requires a PDCP SR. For example, the MAC CE includes the MRB ID and the multicast / broadcast service identifier (G-RNTI, session ID, TMGI, or an identifier that uniquely identifies the multicast / broadcast service).

[0157] Furthermore, the network can instruct the UE to perform a PDCP SR for a specified MRB by using the MRB ID for the specified multicast / broadcast service on the Physical Downlink Control Channel (PDCCH) at the Physical Layer. The multicast / broadcast service can be identified by the G-RNTI, Session ID, TMGI, or any identifier that uniquely identifies the multicast / broadcast service. It should be noted that the G-RNTI itself can be identified by the DCI of the PDCCH itself.

[0158] Triggering conditions may include when the network provides information on the physical downlink control channel (e.g., PDCCH) corresponding to the multicast / broadcast service to signal that the wireless communication device is performing PDCP SR operation on a bearer supporting PDCP SR. The MRB ID may be carried in the downlink control information.

[0159] Method 700 may include transmitting multicast / broadcast service data (720). The wireless communication device may access, identify, or receive multicast / broadcast service data based on multicast radio resource configuration information. In some embodiments, the wireless communication device may transmit multicast / broadcast service data via an air interface protocol stack configured using multicast radio resource configuration information. Transmission of multicast / broadcast service data may be initiated or launched in response to the configuration of the air interface protocol stack.

[0160] In some embodiments, the PDCP status report may be transmitted in conjunction with data from multicast / broadcast services. In some embodiments, the PDCP status report content may include the last received PDCP PDU count or the first lost PDCP PDU count; a bitmap of the lost PDCP PDUs; and the number or ratio of lost PDCP PDUs within a time window or sequence number window. In some embodiments, the PDCP status report may be transmitted in a Type 1 RLC entity or a PTP-type RLC entity.

[0161] Method 700 may include a configuration for enabling or disabling multicast / broadcast services (725). The configuration for transmitting multicast / broadcast service data to the wireless communication device may be enabled or disabled according to the configuration in step 1. Enabling or disabling may be for at least a portion of the configuration for the multicast / broadcast service. In some embodiments, the configuration in step 1 may include enabling or disabling operations for two states of an RLC bearer. An RLC bearer may correspond to each multicast bearer serving the multicast / broadcast service.

[0162] In some embodiments, the wireless communication device may identify or receive instructions to enable or disable configured operations via Layer 1 signaling. Layer 1 signaling may include a MAC control element (CE) or downlink control information (DCI). The MAC CE or DCI may include an identifier for a multicast / broadcast service, and a radio bearer identifier or radio bearer list corresponding to the multicast / broadcast service. The identifier for the multicast / broadcast service may be a G-RNTI or a session ID, or other identifiers that the wireless communication device can use to identify the multicast / broadcast service.

[0163] In some embodiments, step 1 configuration may include enabling or disabling two states of an RLC bearer. An RLC bearer may correspond to each multicast bearer serving a multicast / broadcast service. Disabling an RLC bearer corresponds to a release or suspension operation. In some embodiments, one or more Type 2 RLC bearers associated with a multicast / broadcast service are suspended or released. In some embodiments, a disabling operation may be releasing the corresponding RLC bearer. A disabling operation may include releasing the corresponding RLC entity corresponding to the RLC bearer and the corresponding logical channel. This release may not apply to the content, settings, or configurations associated with the RLC bearer, and these content, settings, or configurations may be deleted (to prevent future use). In some embodiments, a disabling operation may include stopping and resetting the t-reassembly if a reassembly timer (t-reassembly) is running. In some embodiments, a disabling operation may include discarding any available RLC SDUs, RLC SDU segments, and RLC PDUs. In some embodiments, a disabling operation may include setting a state variable to its initial value.

[0164] In some embodiments, step 1 configuration may include releasing the MAC or PHY configuration set associated with the multicast / broadcast service. The UE-side MAC entity may cease monitoring the G-RNTI of the multicast / broadcast service. The UE-side MAC entity may stop receiving the service in PTM mode on the air interface. The UE-side MAC may release the HARQ process associated with the G-RNTI, clear the HARQ cache, and release the DRX configuration of the multicast / broadcast service. The UE may not save the MAC / PHY configuration set associated with the multicast / broadcast service. The UE may delete these contents, settings, or configurations associated with the multicast / broadcast service (to prevent future use).

[0165] In some embodiments, disabling may be suspending the RLC bearer without removing or retaining (e.g., potentially for later use) the RLC bearer's configuration. Suspending an RLC bearer may correspond to suspending or releasing a logical channel corresponding to the RLC entity, and suspending the corresponding RLC entity. Suspension may apply to content, settings, or configurations associated with the RLC bearer, but these content, settings, or configurations are retained or saved (for later use upon restoration / enablement). In some embodiments, in response to this suspension (including suspension of a logical channel corresponding to the RLC bearer), the corresponding MAC entity may receive data intended for delivery to the corresponding logical channel and discard the received data.

[0166] In some embodiments, step 1 configuration may include suspending the MAC or PHY configuration set associated with the multicast / broadcast service. The UE-side MAC entity may cease monitoring the G-RNTI of the multicast / broadcast service. The UE-side MAC entity may stop receiving the service in PTM mode on the air interface. The UE-side MAC entity may release the HARQ process associated with the G-RNTI, clear the HARQ buffer, release the DRX configuration of the multicast / broadcast service, and the UE saves the MAC or PHY configuration set associated with the multicast / broadcast service (for later use during recovery / enablement).

[0167] In some embodiments, the enabling operation may include RLC bearer recovery or establishment operations. In some embodiments, the RLC bearer recovery operation may include, in response to a MAC entity receiving data to be delivered to a corresponding logical channel, the MAC entity delivering the data to the corresponding logical channel. In some embodiments, the RLC bearer recovery operation may include reassembling received packets and starting a corresponding reassembly timer (t-reassembly). In some embodiments, step 1 configuration may include recovery operations for the MAC or PHY configuration set associated with the multicast / broadcast service. In some embodiments, one or more Type 2 RLC bearers associated with the multicast / broadcast service are recovered or established.

[0168] While various embodiments of the present solution have been described above, it should be understood that these embodiments are presented merely as examples and not as limitations. Similarly, various illustrations may depict exemplary architectures or configurations, provided to enable those skilled in the art to understand the exemplary features and functionality of the present solution. However, those skilled in the art should understand that the solution is not limited to the exemplary architectures or configurations shown, but can be implemented using various alternative architectures and configurations. Additionally, as those skilled in the art will understand, one or more features of one embodiment may be combined with one or more features of another embodiment described herein. Therefore, the breadth and scope of this disclosure should not be limited by any of the illustrative embodiments described above.

[0169] It should also be understood that any reference to elements in this document using names such as "first," "second," etc., generally does not restrict the number or order of these elements. Rather, these names may be used herein as a convenient means of distinguishing two or more elements or instances of elements. Therefore, referring to the first element and the second element does not imply that only two elements can be used, or that the first element must somehow precede the second element.

[0170] Additionally, those skilled in the art will understand that information and signals can be represented using any of a variety of different techniques and methods. For example, the data, instructions, commands, information, signals, bits, and symbols referenced in the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

[0171] Those skilled in the art will further understand that any of the various illustrative logic blocks, modules, processors, devices, circuits, methods, and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., digital implementation, analog implementation, or a combination of both), firmware, various forms of program or design code incorporating instructions (which may be referred to herein as "software" or "software module" for convenience), or any combination of these technologies. To clearly illustrate this interchangeability of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps have been generally described above in accordance with their functions. Whether such functionality is implemented as hardware, firmware, or software, or a combination of these technologies, depends on the specific application and design constraints on the overall system. Those skilled in the art can implement the described functions in various ways for each specific application, but such implementation decisions will not depart from the scope of this disclosure.

[0172] Furthermore, those skilled in the art will understand that the various illustrative logic blocks, modules, devices, components, and circuits described herein may be implemented within or executed by an integrated circuit (IC), which may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, or any combination thereof. Logic blocks, modules, and circuits may also include antennas and / or transceivers for communicating with various components within a network or device. A general-purpose processor may be a microprocessor, but optionally, it may be any conventional processor, controller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other suitable configuration performing the functions described herein.

[0173] If implemented in software, these functions can be stored as one or more instructions or code in a computer-readable medium. Therefore, the steps of the methods or algorithms disclosed herein can be implemented as software stored in a computer-readable medium. Computer-readable media include computer storage media and communication media, with communication media including any medium capable of transferring computer programs or code from one place to another. Storage media can be any available medium that is accessible to a computer. By way of example and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and is accessible to a computer.

[0174] In this document, the term "module" as used herein refers to software, firmware, hardware, and any combination of these elements used to perform the associated functions described herein. Additionally, for the purposes of discussion, various modules are described as discrete modules; however, it will be apparent to those skilled in the art that two or more modules can be combined to form a single module that performs the associated functions according to embodiments of this solution.

[0175] Additionally, in embodiments of this solution, memory or other storage devices and communication components may be employed. It should be understood that, for clarity, the above description has referenced various functional units and processors in describing embodiments of this solution. However, it will be apparent that any suitable functional distribution can be used among different functional units, processing logic elements, or domains without departing from this solution. For example, a function shown to be performed by a separate processing logic element or controller may be performed by the same processing logic element or controller. Therefore, references to specific functional units are merely references to suitable components used to provide the described functionality and do not indicate a strict logical or physical structure or organization.

[0176] Various modifications to the embodiments described in this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the novel features and principles disclosed herein, as set forth in the following claims.

Claims

1. A method for wireless communication, comprising: The wireless communication device receives multicast radio resource configuration information from the network. The multicast radio resource configuration information includes radio link control (RLC) bearer configuration, wherein the RLC bearer configuration includes at least one of a plurality of RLC bearer types, the plurality of RLC bearer types including (i) type 1 RLC bearer, the type 1 RLC bearer being a point-to-point (PTP) type, and (ii) type 2 RLC bearer, the type 2 RLC bearer being a point-to-multipoint (PTM) type; as well as The wireless communication device configures its air interface protocol stack according to the multicast radio resource configuration information. in: For a multicast radio bearer configured with the Type 1 RLC bearer, each Packet Data Convergence Protocol (PDCP) entity corresponding to the multicast radio bearer is associated with an Acknowled Mode (AM) RLC entity or an Unacknowled Mode (UM) RLC entity for the corresponding direction. For a multicast radio bearer configured with the type 2 RLC bearer, each PDCP entity corresponding to the multicast radio bearer is associated with at least one UM DL RLC entity; as well as For a multicast radio bearer that is configured with both the Type 1 RLC bearer and the Type 2 RLC bearer, each PDCP entity corresponding to the multicast radio bearer is associated with the following entities: the AM RLC entity or the UM RLC entity, and the at least one UM DL RLC entity.

2. The method according to claim 1, comprising sending a multicast service request to the network by the wireless communication device before receiving the multicast radio resource configuration.

3. The method according to claim 2, comprising sending the multicast service request from the wireless communication device to the multicast session management function or entity of the core network.

4. The method according to claim 2, comprising sending the multicast service request from the wireless communication device to the radio access network (RAN) node.

5. The method according to claim 1, wherein, The multicast radio resource configuration information includes PDCP configuration.

6. The method according to claim 1, wherein, The multicast radio resource configuration information includes at least one operation corresponding to the multicast radio bearer configuration associated with the multicast service, or the multicast media access control (MAC) and physical PHY layer configuration set.

7. The method according to claim 1, wherein, The peer RLC entity of the network associated with the type 1 RLC bearer serves a specific wireless communication device that receives multicast services, and the peer RLC entity of the network associated with the type 2 RLC bearer serves at least one wireless communication device that receives the multicast services.

8. The method according to claim 5, wherein, The multicast media access control (MAC) and physical PHY layer configuration set for multicast services includes at least one of the following: MAC discontinuous reception (DRX) configuration corresponding to the multicast service, a list of cell identifiers to which the multicast service is scheduled, a bandwidth portion (BWP) index associated with the multicast service, or a physical downlink shared data channel (PDSCH) configuration and a physical downlink control channel (PDCCH) configuration.

9. The method according to claim 5, wherein, There is a mapping relationship between the physical layer identifier and the session identifier of the multicast service, and the mapping relationship is provided to a specific wireless communication device through dedicated signaling.

10. The method according to claim 5, wherein, The logical channel identifier (LCID) corresponding to the RLC bearer includes at least two LCID values, lcid2-1 and lcid2-2. If the corresponding LCID value in the subheader of the received MAC PDU is lcid2-1, the MAC entity submits the service data in the received MAC PDU to the logical channel identified by lcid2-2.

11. The method according to claim 5, wherein, The RLC bearer configuration is provided via a broadcast channel and broadcast within the cell, or provided to specific wireless communication devices via dedicated signaling.

12. The method according to claim 5, wherein, Step 1 configuration includes the multicast radio resource configuration information.

13. The method according to claim 1, wherein, Step 1 configuration includes enabling or disabling operations for Type 1 RLC bearers or Type 2 RLC bearers that serve multicast bearers associated with multicast services.

14. A wireless communication device, comprising: At least one processor, the at least one processor being configured to perform the method according to any one of claims 1 to 13.

15. A computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1 to 13.

Images