MRB architecture with PDCP retransmission
By adopting enhanced multicast radio bearer (MRB) architecture and PDCP-level retransmission technology in 5G NR radio access network, the retransmission problem in multicast sessions is solved, and transmission stability and efficiency are improved.
Patent Information
- Application Number
- CN202080105281.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2020-08-03
- Publication Date
- 2025-03-07
- Estimated Expiration
- 2040-08-03
AI Technical Summary
In 5G NR radio access network, the prior art is difficult to effectively support retransmission in multicast sessions, resulting in instability and inefficiency of data transmission.
Adopting an enhanced multicast radio bearer (MRB) architecture, the packet data aggregation protocol (PDCP) status report is carried out by wireless devices on base stations of 5G NR RAN, supporting operations of multicast RLC branches and unicast RLC branches, enabling PDCP-level retransmission of PDCP protocol data unit (PDU).
Through this method, the transmission stability and efficiency of multicast services in 5G NR RAN are improved, flexible retransmission in multicast sessions is supported, and network latency and data loss are reduced.
Smart Images

Figure CN116325882B_ABST
Abstract
Description
Background Art
[0001] Long Term Evolution (LTE), fifth generation (5G) New Radio (NR) (5GNR), and other recently developed communication technologies allow wireless devices to communicate information at data rates (e.g., in terms of units such as gigabits per second) that were available only a few years ago. Today's communication networks are also more secure, resilient to multipath fading, allow for lower network traffic latency, and provide better communication efficiency (e.g., in terms of units such as bits per second per unit of bandwidth used). These and other recent improvements have facilitated the emergence of new ways to deliver media and content to mobile wireless devices, including broadcast, multicast, and unicast media delivery techniques. Summary of the invention
[0002] Various aspects include systems and methods for supporting retransmissions in a multicast session conducted in a fifth generation (5G) new radio (NR) (5G NR) radio access network (RAN). Various aspects may provide an enhanced multicast radio bearer (MRB) architecture that utilizes packet data convergence protocol (PDCP) status reporting by a wireless device to a base station of a 5G NR RAN. Various aspects may support multiple radio link control (RLC) entities, also referred to as RLC branches, in a multicast session. One or more multicast RLC branches may be used for multicast and / or unicast transmissions to a wireless device, and a unicast RLC branch may be used for unicast transmissions to a specific wireless device. Various aspects may enable PDCP-level retransmissions of PDCP protocol data units (PDUs). Various aspects may include methods performed by a processor of a wireless device and / or a processor of a base station of a 5G NR RAN.
[0003] Various aspects may include: determining that a PDCP status reporting condition for a multicast session has occurred; generating a PDCP status report indicating at least a first missing count (FMC) of a next unreceived PDCP protocol data unit (PDU) for the multicast session in response to determining that a PDCP status reporting condition for the multicast session has occurred; and issuing a PDCP status report to a base station of a 5G NR RAN.
[0004] Some aspects may also include: receiving a retransmitted PDCP PDU from a base station of the 5G NR RAN via a unicast transport channel or a multicast transport channel, wherein the retransmitted PDCP PDU corresponds to a next unreceived PDPC PDU. In some aspects, the next unreceived PDPC PDU was scheduled to be received via a multicast transport channel, and the retransmitted PDCP PDU is received via the multicast transport channel. In some aspects, the next unreceived PDPC PDU was scheduled to be received via a multicast transport channel, and the retransmitted PDCP PDU is received via a unicast transport channel. In some aspects, the PDCP status reporting condition for the multicast session includes receiving a PDCP PDU including a polling bit from a base station of the 5G NR RAN. In some aspects, the PDCP PDU including the polling bit is received via a unicast transport channel. In some aspects, the PDCP PDU including the polling bit is received via a multicast transport channel.
[0005] In some aspects, the probability factor is configured as part of the MRB PDCP configuration. Some aspects may also include: generating a random number in response to receiving a PDCP PDU including a polling bit, and determining whether a PDCP status reporting condition for a multicast session has occurred includes: determining whether the random number corresponds to the PDCP status reporting condition based at least in part on the probability factor. In some aspects, the PDCP PDU including the polling bit includes a subgroup identifier, and determining whether a PDCP status reporting condition for a multicast session has occurred includes: determining whether the subgroup identifier corresponds to a subgroup identifier configured for the wireless device. In some aspects, the PDCP status reporting condition for the multicast session includes expiration of a countdown timer associated with the PDCP status report.
[0006] Some aspects may also include activating a unicast RLC entity associated with a unicast transport channel of the MRB for the multicast session and a multicast RLC entity associated with a multicast transport channel of the MRB for the multicast session.
[0007] Some aspects may also include: receiving an indication from a base station to deactivate a unicast RLC entity or to deactivate a multicast RLC entity; and maintaining the RLC entity indicated to be deactivated in a suspended state. In some aspects, the unicast RLC entity operates in an acknowledged mode (AM) or an unacknowledged mode (UM); and the multicast RLC entity operates in an UM or a transparent mode (TM).
[0008] Some aspects may also include: activating a unicast radio link control (RLC) entity associated with a unicast transport channel of a multicast radio bearer (MRB) for a multicast session and a multicast RLC entity associated with a multicast transport channel of the MRB for the multicast session, wherein the multicast RLC operates in an acknowledgement mode (AM); configuring the multicast RLC entity with a first logical channel identifier (LCID) for multicast reception and a second LCID for unicast reception, and configuring the unicast RLC entity with a third LCID for unicast reception.
[0009] Some aspects may also include: receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a second LCID, wherein the packet is a hybrid automatic repeat request (HARQ) encoded with the second LCID and a cell radio network temporary identifier (C-RNTI); receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a first LCID, wherein the packet is a HARQ encoded with the first LCID and a group radio network temporary identifier (G-RNTI); and / or receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a third LCID, wherein the packet is a HARQ encoded with the third LCID and the C-RNTI.
[0010] Some aspects may also include: activating a unicast radio link control (RLC) entity associated with a unicast transport channel of a multicast radio bearer (MRB) for a multicast session and a multicast RLC entity associated with a multicast transport channel of the MRB for the multicast session, wherein the multicast RLC operates in an unconfirmed mode (UM); configuring the multicast RLC entity with a first logical channel identifier (LCID) for multicast reception, and configuring the unicast RLC entity with a second LCID for unicast reception.
[0011] Some aspects may also include: receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a first LCID, wherein the packet is a hybrid automatic repeat request (HARQ) encoded with the first LCID and a group radio network temporary identifier (G-RNTI); and / or receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a second LCID, wherein the packet is a HARQ encoded with the second LCID and a cell radio network temporary identifier (C-RNTI).
[0012] Some aspects may also include: activating a unicast radio link control (RLC) entity associated with a unicast transport channel of a multicast radio bearer (MRB) for a multicast session and a multicast RLC entity associated with a multicast transport channel of the MRB for the multicast session, wherein the multicast RLC operates in confirmed mode (AM) or unconfirmed mode (UM) and the unicast RLC operates in AM or UM; configuring the multicast RLC entity with a first logical channel identifier (LCID) for multicast reception, and configuring the unicast RLC entity with a second LCID for unicast reception.
[0013] Some aspects may also include: receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a first LCID, wherein the packet is a hybrid automatic repeat request (HARQ) encoded with the first LCID and a group radio network temporary identifier (G-RNTI), or the packet is a HARQ encoded with the first LCID and a cell radio network temporary identifier (C-RNTI); and / or receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a second LCID, wherein the packet is a HARQ encoded with the second LCID and the C-RNTI.
[0014] Various aspects may include: receiving packets for transmission in a multicast session at a packet data convergence protocol (PDCP) layer; storing copies of the packets for transmission in a retransmission buffer of the PDCP layer; and adding a PDCP header to the packets for transmission to generate a PDCP protocol data unit (PDU).
[0015] Some aspects may also include: receiving a PDCP status report from at least one wireless device receiving a multicast session, the PDCP status report indicating at least a first missing count (FMC) of a next unreceived PDCP PDU for the multicast session; determining that a stored copy of a packet for transmission in a retransmission buffer of a PDCP layer is associated with the FMC of a next unreceived PDCP PDU for the multicast session; adding a PDCP header to the determined stored copy of the packet for transmission in the retransmission buffer of the PDCP layer to generate a retransmitted PDCP protocol PDU; selecting a unicast radio link control (RLC) entity of a multicast radio bearer (MRB) for the multicast session or one of multicast RLC entities associated with a multicast transmission channel of the MRB for the multicast session; and sending the retransmitted PDCP PDU to the selected RLC entity for retransmission. In some aspects, selecting one of the unicast RLC entity or the multicast RLC entity for retransmission is based at least in part on the number of wireless devices requesting retransmission.
[0016] Some aspects may also include: determining whether a polling condition has occurred; and inserting a polling bit into a next PDCP PDU to be transmitted in response to determining that the polling condition has occurred. In some aspects, the polling condition is the expiration of a polling time. In some aspects, the polling condition is the number of PDCP PDUs sent reaching a threshold or the number of bytes of PDCP data sent reaching a threshold.
[0017] Some aspects may also include: determining a probability factor; and issuing an indication of the probability factor using radio resource control (RRC) signaling.
[0018] Some aspects may also include determining a subgroup identifier of wireless devices selected to report the PDCP status; and inserting the subgroup identifier into a next PDCP PDU to be transmitted in response to determining that a polling condition has occurred.
[0019] In some aspects, receiving a packet for transmission in a multicast session at a PDCP layer includes: receiving a packet for transmission in the multicast session at a PDCP entity associated with a multicast radio bearer (MRB) of the multicast session. Some aspects may also include: issuing a PDCP PDU to a unicast radio link control (RLC) entity associated with a unicast transmission channel of the MRB for the multicast session or a multicast RLC entity associated with a multicast transmission channel of the MRB for the multicast session. In some aspects, the unicast RLC entity operates in an acknowledged mode (AM) or an unacknowledged mode (UM); and the multicast RLC entity operates in AM, UM, or a transparent mode (TM).
[0020] Some aspects may also include: applying hybrid automatic repeat request (HARQ) operations separately to unicast transmission channels of MRBs for multicast sessions and multicast transmission channels of MRBs for multicast sessions. In some aspects, receiving packets for transmission in a multicast session at a PDCP layer includes: receiving packets for transmission in a multicast session at a PDCP entity associated with both a multicast radio bearer (MRB) for the multicast session and a data radio bearer (DRB) for the multicast session.
[0021] Some aspects may also include: issuing a PDCP PDU to a multicast radio link control (RLC) entity associated with a first logical channel identifier (LCID) for multicast transmission and a second LCID for unicast transmission, or to a unicast RLC entity associated with a third LCID for unicast transmission, wherein the multicast RLC entity operates in an acknowledged mode (AM) and the unicast RLC entity operates in an AM or unacknowledged mode (UM).
[0022] Some aspects may also include: encoding packets for a multicast session associated with a first LCID using a hybrid automatic repeat request (HARQ) encoding operation based at least in part on the first LCID and a group radio network temporary identifier (G-RNTI); encoding packets for a multicast session associated with a second LCID using a HARQ encoding operation based at least in part on the second LCID and a cell radio network temporary identifier (C-RNTI); and / or encoding packets for a multicast session associated with a third LCID using a HARQ encoding operation based at least in part on the third LCID and the C-RNTI.
[0023] Some aspects may also include: issuing a PDCP PDU to a multicast radio link control (RLC) entity associated with a first logical channel identifier (LCID) for multicast transmission and a unicast RLC entity associated with a second LCID for unicast transmission, wherein the multicast RLC entity operates in an unacknowledged mode (UM) and the unicast RLC entity operates in an acknowledged mode (AM) or UM.
[0024] Some aspects may also include: encoding packets for a multicast session associated with a first LCID using a hybrid automatic repeat request (HARQ) coding operation based at least in part on the first LCID and a group radio network temporary identifier (G-RNTI); and / or encoding packets for a multicast session associated with a second LCID using a HARQ coding operation based at least in part on the second LCID and a cell radio network temporary identifier (C-RNTI).
[0025] Some aspects may also include: issuing a PDCP PDU to a multicast radio link control (RLC) entity associated with a first logical channel identifier (LCID) for multicast transmission and a unicast RLC entity associated with a second LCID for unicast transmission, wherein the multicast RLC entity and the unicast RLC entity operate in an acknowledged mode (AM) or an unacknowledged mode (UM).
[0026] Some aspects may also include: encoding packets for a multicast session associated with a first LCID using a hybrid automatic repeat request (HARQ) encoding operation based at least in part on the first LCID and a group radio network temporary identifier (G-RNTI) or using a HARQ encoding operation based at least in part on the first LCID and a cell radio network temporary identifier (C-RNTI); and encoding packets for a multicast session associated with a second LCID using a HARQ encoding operation based at least in part on the second LCID and the C-RNTI.
[0027] In some aspects, a packet originally encoded using a HARQ encoding operation based at least in part on the first LCID and the G-RNTI for a multicast session associated with the first LCID is retransmitted as a packet encoded using a HARQ encoding operation based at least in part on the first LCID and the C-RNTI.
[0028] Other aspects may include a wireless device having a processor configured to perform one or more operations of the method summarized above. Other aspects may include a non-transitory processor-readable storage medium having processor-executable instructions stored thereon configured to cause a processor of the wireless device to perform the operations of the method summarized above. Other aspects include a wireless device having components for performing the functions of the method summarized above. Other aspects include a system-on-chip for use in a wireless device, the wireless device including a processor configured to perform one or more operations of the method summarized above. Other aspects include a system-level package including two systems-on-chip for use in a wireless device, the wireless device including a processor configured to perform one or more operations of the method summarized above. Other aspects may include a network computing device having a processor configured to perform one or more operations of the method summarized above. Other aspects may include a non-transitory processor-readable storage medium having processor-executable instructions stored thereon configured to cause a processor of the network computing device to perform the operations of the method summarized above. Other aspects include a network computing device having means for performing the operations of the method summarized above. BRIEF DESCRIPTION OF THE DRAWINGS
[0029] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the claims and, together with the general description given above and the detailed description given below, serve to explain features of the claims.
[0030] Figure 1 is a system block diagram illustrating an example communication system suitable for implementing any of the various embodiments.
[0031] Figure 2 is a component block diagram illustrating an example computing and wireless modem system suitable for implementing any of the various embodiments.
[0032] Figure 3 is a component block diagram illustrating a software architecture suitable for implementing any of the various embodiments, the software architecture including a radio protocol stack for user plane and control plane in wireless communications.
[0033] Figure 4A is a block diagram illustrating an example of interaction between stack architecture layers in a transmitting communication device and a receiving communication device according to various embodiments.
[0034] Figure 4B It is a network architecture diagram.
[0035] Figure 4C is a block diagram illustrating the properties of various packet types.
[0036] Figure 4D is a diagram of a base station architecture for providing multicast sessions according to various embodiments.
[0037] Figure 4E is a block diagram illustrating an example base station and wireless device configuration supporting a multicast session in accordance with various embodiments.
[0038] Figure 4F is a block diagram of example PDCP packet attributes in accordance with various embodiments.
[0039] Figure 4G is a diagram of a base station architecture for providing multicast sessions according to various embodiments.
[0040] Figure 4H is a diagram of a base station architecture for providing multicast sessions according to various embodiments.
[0041] Figure 5A , Figure 5B , Figure 5C , Figure 5D , Figure 5E , Fig. 5F , Figure 5G , Figure 5H , Fig.5I , Figure 5J and / or Figure 5K is a process flow diagram illustrating a method that may be performed by a wireless device to support PDCP retransmission in a 5G NR RAN according to various embodiments.
[0042] Fig. 6A , Figure 6B , Figure 6C , Fig.6D , Fig. 6E , Fig. 6F , Figure 6G , Figure 6H , Fig.6I , Figure 6J , Figure 6K , Figure 6L , Figure 6M and / or Figure 6N is a process flow diagram illustrating a method that may be performed by a base station for supporting PDCP retransmission in a 5G NR RAN according to various embodiments.
[0043] Figure 7 is a component block diagram of a network computing device suitable for use with the various embodiments.
[0044] Figure 8 is a component block diagram of a wireless device suitable for use with the various embodiments. DETAILED DESCRIPTION
[0045] Various embodiments will be described in detail with reference to the accompanying drawings. In all drawings, the same reference numerals will be used as much as possible to refer to the same or similar parts. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.
[0046] Various embodiments include systems and methods for supporting retransmission of packets in a multicast session conducted in a fifth generation (5G) new radio (NR) (5G NR) radio access network (RAN). Various embodiments include an enhanced multicast radio bearer (MRB) architecture that utilizes packet data convergence protocol (PDCP) status reporting by a wireless device to a base station of a 5G NR RAN. Various embodiments may support multiple radio link control (RLC) entities, also referred to as RLC branches, in a multicast session. One or more multicast RLC branches may be used for multicast and / or unicast transmissions to a wireless device, and a unicast RLC branch may be used for unicast transmissions to a specific wireless device. Various embodiments may enable PDCP-level retransmissions of PDCP protocol data units (PDUs). Various embodiments may improve multicast service delivery in a 5G NR RAN by supporting handover operations between MRB and data radio bearer (DRB) operations and / or providing flexibility for retransmissions in a multicast session.
[0047] The term "wireless device" is used herein to refer to any or all of the following: cellular telephones, smart phones, portable computing devices, personal or mobile multimedia players, laptop computers, tablet computers, smartbooks, ultrabooks, handheld computers, wireless email receivers, multimedia Internet-enabled cellular telephones, wireless router devices, wireless home appliances, medical devices and equipment, entertainment devices (e.g., wireless game controllers, music and video players, satellite radio, etc.), wireless communication elements within autonomous and semi-autonomous vehicles, wireless devices attached to or incorporated into various mobile platforms, and similar electronic devices that include memory, multiple SIM cards, wireless communication components, and programmable processors.
[0048] The term "system on chip (SoC)" is used herein to refer to a single integrated circuit (IC) chip that includes multiple resources and / or processors integrated on a single substrate. A single SOC may include circuits for digital, analog, mixed signal, and radio frequency functions. A single SOC may also include any number of general and / or special processors (digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). The SOC may also include software for controlling the integrated resources and processors and for controlling peripheral devices.
[0049] The term "system-in-package (SIP)" may be used herein to refer to a single module or package that contains multiple resources, computing units, cores, and / or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged on a unified substrate. A SIP may also include multiple independent SOCs that are coupled together via high-speed communication circuits and packaged in close proximity, such as on a single motherboard or in a single wireless device. The proximity of the SOCs facilitates high-speed communication and the sharing of memory and resources.
[0050] As used herein, the terms "SIM", "SIM card" and "Subscriber Identity Module" may interchangeably refer to a memory that may be an integrated circuit or embedded in a removable card, and stores an International Mobile Subscriber Identity (IMSI), related keys and / or other information for identifying and / or authenticating a wireless device on a network and enabling communication services with the network. Examples of SIM include the Universal Subscriber Identity Module (USIM) specified in the Long Term Evolution (LTE) 3GPP standard, and the Removable User Identity Module (R-UIM) specified in the 3GPP standard. Universal Integrated Circuit Card (UICC) is another term for SIM. In addition, SIM may also refer to a Virtual SIM (VSIM), which may be implemented as a remote SIM profile loaded in an application on a wireless device and enable conventional SIM functions on the wireless device.
[0051] Because the information stored in the SIM enables the wireless device to establish a communication link with a specific network for one or more specific communication services, the term "SIM" is also used herein as a shorthand for the communication services associated with and enabled by the information stored in a specific SIM, because the SIM and the communication network and the services and subscriptions supported by the network are interrelated. Likewise, the term SIM may also be used as a shorthand for the protocol stack and / or modem stack and the communication processes used in establishing and conducting communication services with subscriptions and networks enabled by the information stored in the specific SIM.
[0052] As used herein, the terms "multi-SIM wireless device", "MS wireless device", "dual SIM wireless device" and "DS wireless device" may interchangeably describe a wireless device that is configured with more than one SIM. Examples of multi-SIM wireless devices include multi-SIM multi-standby (MSMS) wireless devices (such as dual SIM (DS) dual standby (DSDS) wireless devices, etc.) and multi-SIM multi-active (MSMA) wireless devices (such as dual SIM dual active (DSDA) wireless devices, etc.). An MSMS wireless device may be a wireless device that is configured with more than one SIM and allows idle mode operations to be performed on two subscriptions simultaneously, as well as selectively communicating on one subscription while performing idle mode operations on at least one other subscription. An MSMA wireless device may be a wireless device that is configured with more than one SIM and allows idle mode and / or active mode operations to be performed on two subscriptions simultaneously using at least two different radio frequency (RF) resources (e.g., two different radio transceivers).
[0053] Various embodiments described herein use the term "server" to refer to any computing device capable of acting as a server, such as a primary exchange server, a web server, a mail server, a document server, a content server, or any other type of server. A server can be a dedicated computing device or a computing device that includes a server module (e.g., running an application that enables the computing device to operate as a server). A server module (e.g., a server application) can be a full-featured server module or a lightweight or secondary server module (e.g., a lightweight or secondary server application) configured to provide synchronization services between dynamic databases on a receiver device. A lightweight server or secondary server can be a stripped-down version of server-type functionality that can be implemented on a receiver device so that it can act as an Internet server (e.g., a corporate email server) only to the extent necessary to provide the functionality described herein.
[0054] As used herein, the terms "network", "system", "wireless network", "cellular network" and "wireless communication network" may interchangeably refer to part or all of an operator's wireless network associated with a wireless device and / or a subscription on a wireless device. The techniques described herein may be used for various wireless communication networks, such as code division multiple access (CDMA), time division multiple access (TDMA), FDMA, orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), and other networks. In general, any number of wireless networks may be deployed in a given geographic area. Each wireless network may support at least one radio access technology that may operate on one or more frequencies or frequency ranges. For example, a CDMA network may implement Universal Terrestrial Radio Access (UTRA) (including Wideband Code Division Multiple Access (WCDMA) standards), CDMA2000 (including IS-2000, IS-95 and / or IS-856 standards), and the like. In another example, a TDMA network may implement GSM Enhanced Data Rates for GSM Evolution (EDGE). In another example, an OFDMA network may implement Evolved UTRA (E-UTRA) (including the LTE standard), IEEE 802.11 (WiFi), IEEE 802.16 (WiMAX), IEEE 802.20, Etc. Reference may be made to a wireless network using the LTE standard, and thus the terms "Evolved Universal Terrestrial Radio Access," "E-UTRAN," and "eNodeB" may also be used interchangeably herein to refer to a wireless network. However, this reference is provided merely as an example and is not intended to exclude wireless networks using other communication standards. For example, although various third generation (3G) systems, fourth generation (4G) systems, and fifth generation (5G) systems are discussed herein, these systems are referenced merely as examples, and future generation systems (e.g., sixth generation (6G) or higher systems) may be substituted in various examples.
[0055] The terms "network operator," "operator," "mobile network operator," "carrier," and "service provider" are used interchangeably herein to describe a wireless communication service provider that owns or controls the elements to sell and deliver communication services to end users, and provides the necessary provisions and credentials as policies are implemented in user device subscriptions.
[0056] As used herein, the term "RF resources" refers to components in a communication device that send, receive, and decode radio frequency signals. RF resources typically include several components coupled together to send RF signals, referred to as a "transmit chain," and several components coupled together to receive and process RF signals, referred to as a "receive chain."
[0057] LTE is a mobile network standard for 4G high-speed data wireless communications developed by 3GPP (3rd Generation Partnership Project) and specified in its Release 8 series of documents. The 5G system is an advanced technology from 4G LTE and provides a new radio access technology (RAT) through the evolution of the existing mobile communication network structure. The implementation of the 5G system or network is currently being adopted, which provides new radio (NR) (also known as 5G) support via NR base stations (such as next-generation NodeB (gNodeB or gNB)). 5G systems and NR base stations are providing flexibility in bandwidth scheduling and utilization. Future generation systems (e.g., sixth generation (6G) or higher systems) can provide the same or similar flexibility in bandwidth scheduling and utilization.
[0058] In LTE and / or 5G (or later) systems, a network device such as a base station may broadcast packets to wireless devices in a cell. For ease of reference, the term "network device" or "network computing device" is used to refer to any of a variety of network elements that may perform the operations of the various embodiments, non-limiting examples of which include a base station, an eNodeB, a gNodeB, etc. The network device may use a multicast radio bearer (MMRB) and / or a data radio bearer (DRB) to provision services to wireless devices in a cell.
[0059] Figure 1 1 is a system block diagram illustrating an example communication system 100 suitable for implementing any of the various embodiments. The communication system 100 may be a 5G New Radio (NR) network or any other suitable network, such as an LTE network, a 5G network, etc. Although Figure 1 A 5G network is illustrated, but later generations of networks may include the same or similar elements. Therefore, references to 5G networks and 5G network elements in the following description are for illustrative purposes and are not intended to be limiting.
[0060] The communication system 100 may include a heterogeneous network architecture including a core network 140 and various mobile devices (in Figure 1120a-120e). The communication system 100 may also include several base stations (illustrated as BS110a, BS110b, BS110c and BS110d) and other network entities. A base station is an entity that communicates with a wireless device and may also be referred to as a Node B, an LTE evolved Node B (eNodeB or eNB), an access point (AP), a radio head, a transmit receive point (TRP), a new radio base station (NR BS), a 5G NodeB (NB), a next generation NodeB (gNodeB or gNB), etc. Each base station may provide communication coverage for a specific geographic area. In 3GPP, the term "cell" may refer to the coverage area of a base station, a base station subsystem serving the coverage area, or a combination thereof, depending on the context in which the term is used. The core network 140 may be any type of core network, such as an LTE core network (e.g., an evolved packet core (EPC) network), a 5G core network, etc.
[0061] The base stations 110a-110d may provide communication coverage for a macro cell, a pico cell, a femto cell, another type of cell, or a combination thereof. A macro cell may cover a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access by mobile devices with a service subscription. A pico cell may cover a relatively small geographic area and may allow unrestricted access by mobile devices with a service subscription. A femto cell may cover a relatively small geographic area (e.g., a home) and may allow restricted access by mobile devices associated with the femto cell (e.g., mobile devices in a closed subscriber group (CSG)). A base station for a macro cell may be referred to as a macro BS. A base station for a pico cell may be referred to as a pico BS. A base station for a femto cell may be referred to as a femto BS or a home BS. In Figure 1 In the illustrated example, base station 110a may be a macro BS for macro cell 102a, base station 110b may be a pico BS for pico cell 102b, and base station 110c may be a femto BS for femto cell 102c. Base stations 110a-110d may support one or more (e.g., three) cells. The terms “eNB”, “base station”, “NR BS”, “gNB”, “TRP”, “AP”, “Node B”, “5G NB” and “cell” may be used interchangeably herein.
[0062] In some examples, the cell may not be stationary, and the geographic area of the cell may move depending on the location of the mobile base station. In some examples, the base stations 110a-110d may be interconnected to each other and to one or more other base stations or network nodes (not shown) in the communication system 100 through various types of backhaul interfaces (such as direct physical connections, virtual networks, etc.) using any suitable transport network.
[0063] The base stations 110a-110d may communicate with the core network 140 via a wired or wireless communication link 126. The wireless devices 120a-120e may communicate with the base stations 110a-110d via a wireless communication link 122.
[0064] The wired communication link 126 may use a variety of wired networks (e.g., Ethernet, TV cable, telephone, fiber optic, and other forms of physical network connections) that may use one or more wired communication protocols, such as Ethernet, Point-to-Point Protocol, High-Level Data Link Control (HDLC), Advanced Data Communications Control Protocol (ADCCP), and Transmission Control Protocol / Internet Protocol (TCP / IP).
[0065] The communication system 100 may also include a relay station (e.g., relay BS 110d). A relay station is an entity that can receive data transmissions from an upstream station (e.g., a base station or a mobile device) and send data to a downstream station (e.g., a wireless device or a base station). A relay station may also be a mobile device that can relay transmissions for other wireless devices. Figure 1 In the illustrated example, a relay station 110d may communicate with the macro base station 110a and the wireless device 120d to facilitate communication between the base station 110a and the wireless device 120d. A relay station may also be referred to as a relay base station, a relay base station, a relay, or the like.
[0066] The communication system 100 may be a heterogeneous network that includes different types of base stations, such as macro base stations, pico base stations, femto base stations, relay base stations, etc. These different types of base stations may have different transmit power levels, different coverage areas, and different impacts on interference in the communication system 100. For example, a macro base station may have a high transmit power level (e.g., 5 to 40 watts), while a pico base station, a femto base station, and a relay base station may have a lower transmit power level (e.g., 0.1 to 2 watts).
[0067] A network controller 130 may be coupled to a set of base stations and may provide coordination and control for these base stations. The network controller 130 may communicate with the base stations via a backhaul. The base stations may also communicate with each other, for example, directly or indirectly via a wireless backhaul or a wired backhaul.
[0068] Wireless devices 120a, 120b, 120c may be distributed throughout communication system 100, and each wireless device may be stationary or mobile. A wireless device may also be referred to as an access terminal, terminal, mobile station, subscriber unit, station, user equipment (UE), etc.
[0069] The macro base station 110a may communicate with the communication network 140 via a wired or wireless communication link 126. The wireless devices 120a, 120b, 120c may communicate with the base stations 110a-110d via a wireless communication link 122.
[0070] The wireless communication links 122, 124 may include multiple carrier signals, frequencies or frequency bands, each of which may include multiple logical channels. The wireless communication links 122 and 124 may utilize one or more radio access technologies (RATs). Examples of RATs that may be used in the wireless communication links include 3GPP LTE, 3G, 4G, 5G (e.g., NR), GSM, CDMA, WCDMA, Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other mobile phone communication technology cellular RATs. Other examples of RATs that may be used in one or more of the various wireless communication links 122, 124 within the communication system 100 include medium-range protocols such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire, and relatively short-range RATs such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE).
[0071] Some wireless networks (e.g., LTE) utilize orthogonal frequency division multiplexing (OFDM) on the downlink and single carrier frequency division multiplexing (SC-FDM) on the uplink. OFDM and SC-FDM divide the system bandwidth into multiple (K) orthogonal subcarriers, which are also commonly referred to as tones, bins, etc. Each subcarrier can be modulated with data. In general, modulation symbols are sent in the frequency domain with OFDM and in the time domain with SC-FDM. The spacing between adjacent subcarriers can be fixed, and the total number of subcarriers (K) can depend on the system bandwidth. For example, the spacing of the subcarriers can be 15kHz, and the minimum resource allocation (referred to as a "resource block" (RB)) can be 12 subcarriers (or 180kHz). Therefore, for system bandwidths of 1.25, 2.5, 5, 10, or 20 megahertz (MHz), the nominal fast file transfer (FFT) size can be equal to 128, 256, 512, 1024, or 2048, respectively. The system bandwidth may also be divided into sub-bands. For example, a sub-band may cover 1.08 MHz (ie, 6 resource blocks), and there may be 1, 2, 4, 8, or 16 sub-bands for system bandwidths of 1.25, 2.5, 5, 10, or 20 MHz, respectively.
[0072] Although the description of some embodiments may use terms and examples associated with LTE technology, some embodiments may be applicable to other wireless communication systems, such as new radio (NR) or 5G networks. NR can utilize OFDM with a cyclic prefix (CP) on the uplink (UL) and downlink (DL), and includes support for half-duplex operation using time division duplex (TDD). A single component carrier bandwidth of 100 MHz can be supported. NR resource blocks can span 12 subcarriers with a subcarrier bandwidth of 75 kHz in a duration of 0.1 milliseconds (ms). Each radio frame can be composed of 50 subframes with a length of 10 ms. Therefore, each subframe can have a length of 0.2 ms. Each subframe can indicate a link direction (e.g., DL or UL) for data transmission, and the link direction of each subframe can be dynamically switched. Each subframe can include DL / UL data and DL / UL control data. Beamforming can be supported, and the beam direction can be dynamically configured. Multiple-input multiple-output (MIMO) transmission with precoding can also be supported. MIMO configurations in the DL can support up to eight transmit antennas with multi-layer DL transmissions of up to eight streams and up to two streams per wireless device. Multi-layer transmissions of up to 2 streams per wireless device can be supported. Aggregation of multiple cells can be supported with up to eight serving cells. Optionally, NR can support different air interfaces other than OFDM-based air interfaces.
[0073] Some mobile devices may be considered as machine type communication (MTC) or evolved or enhanced machine type communication (eMTC) mobile devices. MTC and eMTC mobile devices include, for example, robots, drones, remote devices, sensors, meters, monitors, location tags, etc., which can communicate with a base station, another device (e.g., a remote device), or some other entity. For example, a wireless node may provide a connection to or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link. Some mobile devices may be considered as Internet of Things (IoT) devices, or may be implemented as NB-IoT (narrowband Internet of Things) devices. The wireless devices 120a-e may be included in a housing that houses components of the wireless device (such as a processor component, a memory component, a similar component, or a combination thereof).
[0074] In general, any number of communication systems and any number of wireless networks can be deployed in a given geographic area. Each communication system and wireless network can support a specific radio access technology (RAT) and can operate on one or more frequencies. RAT can also be referred to as radio technology, air interface, etc. Frequency can also be referred to as carrier, channel, etc. Each frequency can support a single RAT in a given geographic area to avoid interference between communication systems of different RATs. In some cases, 4G / LTE and / or 5G / NR RAT networks can be deployed. For example, a 5G non-independent (NSA) network can utilize both the 4G / LTE RAT in the 4G / LTE RAN side of a 5G NSA network and the 5G / NR RAT in the 5G / NR RAN side of a 5G NSA network. Both the 4G / LTE RAN and the 5G / NR RAN can be connected to each other and to the 4G / LTE core network (e.g., Evolved Packet Core (EPC) network) in the 5G NSA network. Other example network configurations may include a 5G independent (SA) network, in which the 5G / NR RAN is connected to the 5G core network.
[0075] In some embodiments, two or more wireless devices 120a-e (e.g., illustrated as UE 120a and UE 120e) may communicate directly (e.g., without using base stations 110a-110d as an intermediary to communicate with each other) using one or more sidelink channels 124. For example, the wireless devices 120a-e may communicate using peer-to-peer (P2P) communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) protocols (e.g., which may include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, or similar protocols), mesh networks, or similar networks, or combinations thereof. In this case, the wireless devices 120a-e may perform scheduling operations, resource selection operations, and other operations described elsewhere herein as being performed by the base station 110a.
[0076] Figure 2 is a component block diagram illustrating an example computing and wireless modem system 200 suitable for implementing any of the various embodiments. The various embodiments may be implemented on a number of single-processor and multi-processor computer systems including a system on a chip (SOC) or a system in a package (SIP).
[0077] refer to Figure 1 and Figure 2, the illustrated example wireless device 200 (which may be a SIP in some embodiments) includes two SOCs 202, 204 coupled to a clock 206, a voltage regulator 208, at least one SIM 268 and / or a SIM interface, and a wireless transceiver 266 configured to send and receive wireless communications via an antenna (not shown) to / from a network wireless device (such as a base station 110a). In some embodiments, the first SOC 202 operates as a central processing unit (CPU) of the wireless device, which executes instructions of a software application by performing arithmetic, logic, control, and input / output (I / O) operations specified by the instructions. In some embodiments, the second SOC 204 may operate as a dedicated processing unit. For example, the second SOC 204 may operate as a dedicated 5G processing unit responsible for managing high-capacity, high-speed (e.g., 5 Gbps, etc.) and / or very high frequency short wavelength (e.g., 28 GHz mmWave spectrum, etc.) communications.
[0078] The first SOC 202 may include a digital signal processor (DSP) 210, a modem processor 212, a graphics processor 214, an application processor (AP) 216, one or more coprocessors 218 (e.g., vector coprocessors) connected to one or more of a processor, a memory 220, a custom circuit 222, system components and resources 224, an interconnect / bus module 226, one or more temperature sensors 230, a thermal management unit 232, and a thermal power envelope (TPE) component 234. The second SOC 204 may include a 5G modem processor 252, a power management unit 254, an interconnect / bus module 264, multiple mmWave transceivers 256, a memory 258, and various additional processors 260, such as an application processor, a packet processor, etc.
[0079] Each processor 210, 212, 214, 216, 218, 252, 260 may include one or more cores, and each processor / core may perform operations independently of other processors / cores. For example, the first SOC 202 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., MICROSOFT WINDOWS 10). In addition, any one or all of the processors 210, 212, 214, 216, 218, 252, 260 may be included as part of a processor cluster architecture (e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).
[0080] The first SOC 202 and the second SOC 204 may include various system components, resources, and custom circuits for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other specialized operations (such as decoding data packets and processing encoded audio and video signals for rendering in a web browser). For example, the system components and resources 224 of the first SOC 202 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral device bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components for supporting processors and software clients running on wireless devices. The system components and resources 224 and / or custom circuits 222 may also include circuits for interfacing with peripheral devices such as cameras, electronic displays, wireless communication devices, external memory chips, etc.
[0081] The first SOC 202 and the second SOC 204 can communicate via an interconnect / bus module 250. The various processors 210, 212, 214, 216, 218 can be interconnected to one or more memory elements 220, system components and resources 224 and custom circuits 222, and a thermal management unit 232 via an interconnect / bus module 226. Similarly, the processor 252 can be interconnected to a power management unit 254, a mmWave transceiver 256, a memory 258, and various additional processors 260 via an interconnect / bus module 264. The interconnect / bus modules 226, 250, 264 can include an array of reconfigurable logic gates and / or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications can be provided by advanced interconnects, such as a high-performance network on chip (NoC).
[0082] The first SOC 202 and / or the second SOC 204 may also include input / output modules (not shown) for communicating with resources external to the SOC, such as a clock 206, a voltage regulator 208, one or more wireless transceivers 266, and at least one SIM 268 and / or a SIM interface (i.e., an interface for receiving one or more SIM cards). Resources external to the SOC (e.g., clock 206, voltage regulator 208) may be shared by two or more internal SOC processors / cores. At least one SIM 268 (or one or more SIM cards coupled to one or more SIM interfaces) may store information supporting multiple subscriptions including a first 5G NR subscription and a second 5G NR subscription, etc.
[0083] In addition to the example SIP 200 discussed above, various embodiments may be implemented in a wide variety of computing systems that may include a single processor, multiple processors, multi-core processors, or any combination thereof.
[0084] Figure 3 is a component block diagram illustrating a software architecture 300 suitable for implementing any of the various embodiments, the software architecture 300 including a radio protocol stack for a user plane and a control plane in wireless communications. Figures 1 to 3 , the wireless device 320 may implement the software architecture 300 to facilitate communication between the wireless device 320 (e.g., wireless devices 120a-120e, 200) and the base station 350 (e.g., base station 110a-d) of the communication system (e.g., 100). In some embodiments, the layers in the software architecture 300 may form a logical connection with the corresponding layers in the software of the base station 350. The software architecture 300 may be distributed between one or more processors (e.g., processors 212, 214, 216, 218, 252, 260). Although illustrated with respect to one radio protocol stack, in a multi-SIM (subscriber identity module) wireless device, the software architecture 300 may include multiple protocol stacks, each of which may be associated with a different SIM (e.g., in a dual SIM wireless communication device, two protocol stacks are associated with two SIMs, respectively). Although described below with reference to the LTE communication layer, the software architecture 300 may support any of a variety of standards and protocols for wireless communication and / or may include additional protocol stacks that support any of a variety of standards and protocols for wireless communication.
[0085] The software architecture 300 may include a non-access stratum (NAS) 302 and an access stratum (AS) 304. The NAS 302 may include functions and protocols that support packet filtering, security management, mobility control, session management, and services and signaling between (one or more) SIMs of a wireless device and its core network 140. The AS 304 may include functions and protocols that support communications between (one or more) SIMs and entities (e.g., base stations) of a supported access network. In particular, the AS 304 may include at least three layers (layer 1, layer 2, and layer 3), each of which may include various sublayers.
[0086] In the user plane and control plane, layer 1 (L1) of AS 304 may be a physical (PHY) layer 306, which may oversee functions that enable transmission and / or reception over an air interface. Examples of such physical layer 306 functions may include cyclic redundancy check (CRC) attachment, decoding blocks, scrambling and descrambling, modulation and demodulation, signal measurement, MIMO, etc. The PHY layer 306 may include various logical channels, including a physical downlink control channel (PDCCH) and a physical downlink shared channel (PDSCH). As an example, the PHY layer 306 may support channel state information (CSI) measurements and reporting (e.g., channel quality indicator (CQI) measurements and reporting).
[0087] In the user plane and the control plane, Layer 2 (L2) of AS 304 may be responsible for the link between the wireless device 320 and the base station 350 through the physical layer 306. In various embodiments, Layer 2 may include a medium access control (MAC) sublayer 308, a radio link control (RLC) sublayer 310, a packet data convergence protocol (PDCP) 312 sublayer, and a service data adaptation protocol (SDAP) 317 sublayer, each of which forms a logical connection that terminates at the base station 350.
[0088] In the control plane, layer 3 (L3) of AS 304 may include a radio resource control (RRC) sublayer 3. Although not shown, software architecture 300 may include additional layer 3 sublayers and various upper layers above layer 3. In various embodiments, RRC sublayer 313 may provide functionality including broadcasting system information, paging, and establishing and releasing an RRC signaling connection between wireless device 320 and base station 350.
[0089] In various embodiments, the SDAP sublayer 317 may provide mapping between quality of service (QoS) flows and data radio bearers (DRBs). In the downlink, at the base station 350, the SDAP sublayer 317 may provide mapping to one of the multicast radio bearers (MRBs) or DRBs for the DL multicast QoS flows. In the uplink, at the wireless device 320, the SDAP sublayer 317 may deliver the multicast QoS flows received by the DL to the upper layer. In various embodiments, the PDCP sublayer 312 may provide uplink functions including multiplexing between different radio bearers and logical channels, sequence number addition, handover data handling, integrity protection, encryption, and header compression. In the downlink, the PDCP sublayer 312 may provide functions including in-order delivery of data packets, duplicate data packet detection, integrity verification, decryption, and header decompression.
[0090] In the uplink, the RLC sublayer 310 may provide segmentation and concatenation of upper layer data packets, retransmission of lost data packets, and automatic repeat request (ARQ). In the downlink, the RLC sublayer 310 functions may include reordering of data packets to compensate for out-of-sequence reception, reassembly of upper layer data packets, and ARQ.
[0091] In the uplink, the MAC sublayer 308 can provide functions including multiplexing between logical channels and transport channels, random access procedures, logical channel priority sorting, and hybrid ARQ (HARQ) operations. In the downlink, the MAC layer functions may include channel mapping, demultiplexing, discontinuous reception (DRX), and HARQ operations within the cell.
[0092] While the software architecture 300 may provide functionality to send data over a physical medium, the software architecture 300 may also include at least one host layer 314 that provides data transfer services to various applications in the wireless device 320. In some embodiments, the application specific functionality provided by the at least one host layer 314 may provide an interface between the software architecture and a general purpose processor.
[0093] In other embodiments, the software architecture 300 may include one or more higher logical layers (e.g., transport, session, presentation, application, etc.) that provide host layer functionality. In some embodiments, the software architecture 300 may include an application layer where a logical connection terminates at another device (e.g., an end-user device, a server, etc.). In some embodiments, the software architecture 300 may also include a hardware interface 316 between the physical layer 306 and communication hardware (e.g., one or more radio frequency (RF) transceivers) in the AS 304.
[0094] Figure 4A The interaction between stack architecture layers in the transmitting communication device 401 and the receiving communication device 415 according to various embodiments is illustrated. Figures 1 to 4A , the communication devices 401 and 415 may each be any type of communication device (e.g., wireless devices 120a-120e, 200, 320, base stations 110a-d, 350) implementing various embodiments. As a specific example, the communication device 401 may be a base station (e.g., gNB) of a 5G NR RAN, and the communication device 415 may be a wireless device (also referred to as a UE).
[0095] Each communication device 401, 415 may include one or more higher data layers 402 configured to exchange data with a modem stack (or radio protocol stack) 406. As an example, the higher data layer 402 may be one or more application layers, one or more service layers, one or more messaging layers, an application layer, etc. As an example, the functionality executed in the higher data layer 402 may include an application 403 (e.g., a multicast application, a messaging application, etc.), a security service 404, an Internet Protocol (IP) service 405 (e.g., a Transmission Control Protocol (TCP) service, a Uniform Datagram Protocol (UDP) service, etc.), other higher data layer functions, or any combination thereof. In some embodiments, the higher data layer 402 and the modem stack 406 on the communication device 401, 415 may run on the same processor of the communication device 401, 415. In some embodiments, the higher data layer 402 and the modem stack 406 on the communication device 401, 415 may run on different processors of the communication device 401, 415. As an example, the higher data layer 402 may run on an application processor (e.g., the application processor 216), and the modem stack 406 may run on a modem processor (e.g., the modem processor 212, the modem processor 252, the modem processor 272). Figure 4A Although illustrated as running on the same communication device 401, 415, in some embodiments, the higher data layer 402 may run on a processor of a separate communication device.
[0096] In some embodiments, the modem stack 406 may include a service data adaptation protocol (SDAP) layer 417, a packet data convergence protocol (PDCP) layer 407, a radio link control (RLC) layer 408, a medium access control (MAC) layer 409, and a physical (PHY) layer 410. The PHY 410 may be the lowest layer of the modem stack 406, and the PDCP layer 407 may be the highest layer of the modem stack 406.
[0097] The SDAP layer 417 can handle SDAP packets and can provide mapping between quality of service (QoS) flows and data radio bearers (DRBs). The SDAP entity of the SDAP layer 417 can receive SDAP. In the downlink (DL) direction, at the base station (e.g., gNB side), the SDAP layer 417 can provide a mapping to one of the multicast radio bearers (MRBs) or DRBs for the DL multicast QoS flow. In the uplink (UL) direction, at the wireless device side, the SDAP layer 417 can deliver the DL received multicast QoS flow to the upper layer. The SDAP layer 417 can receive packets from the higher data layer 402 and can output packets to the PDCP layer 407. The SDAP layer 417 can receive packets from the PDCP layer 407 and can output packets to the higher layer 402.
[0098] The PDCP layer 407 may handle PDCP packets, and may provide maintenance of PDCP SNs, header compression, ciphering and / or integrity protection of PDCP packets, duplicate detection and discarding, reordering, in-order delivery, out-of-order delivery, etc. The PDCP layer 407 may receive packets from the higher data layer 402 and / or the SDAP layer 417, and may output packets to the RLC layer 408. The PDCP layer 407 may receive packets from the RLC layer 408, and may output packets to the higher layer 402 and / or the SDAP layer 417.
[0099] The RLC layer 408 may handle RLC packets and may provide error correction, segmentation, reassembly, reordering, duplicate detection, error detection, and / or error recovery for RLC packets. In addition, the RLC layer 408 may buffer RLC packets in a receive buffer, such as to support reordering, waiting for missing RLC packets, etc. The RLC layer 408 may operate in different modes, such as an acknowledged mode (AM), an unacknowledged mode (UM), and a transparent mode (TM). The RLC layer 408 may receive packets from the PDCP layer 407 and may output packets to the PDCP layer 407. The RLC layer 408 may receive packets from the MAC layer 409 and may output packets to the MAC layer 409.
[0100] The MAC layer 409 may handle various functions including mapping between logical channels and transport channels, multiplexing MAC SDUs belonging to one or different logical channels onto a transport block (TB) delivered to / from the physical layer on the transport channel and demultiplexing MAC SDUs therefrom, scheduling information reporting, error correction through HARQ, priority handling between wireless devices by using dynamic scheduling, priority handling between logical channels of one wireless device by logical channel prioritization, etc. The MAC layer 409 may receive packets from the RLC layer 408 and may output packets to the RLC layer 408. The MAC layer 409 may receive packets from the PHY layer 410 and may output packets to the PHY layer 410.
[0101] The PHY layer 410 may handle PHY packets and may provide a communication interface between the hardware supporting the physical transmission medium (e.g., transceivers, antennas, etc.) and the higher layers of the modem stack 406. The PHY layer 410 may convert PHY packets into a bit stream for transmission and / or convert a received bit stream into a PHY packet. The PHY layer 410 provides encoding, transmission, reception, and / or decoding of PHY packets. The PHY layer 410 may receive packets from the MAC layer 409 and may output packets to the MAC layer 409.
[0102] Packets transmitted to / from a higher data layer of the modem stack 406 may be referred to as a service data unit (SDU) in a given layer, and packets transmitted to / from a lower layer of the modem stack 406 may be referred to as a protocol data unit (PDU). For example, packets received from the PDCP layer 407 in the RLC layer 408 and transmitted from the RLC layer 408 to the PDCP layer 407 may be referred to as RLC SDUs. Similarly, packets received from the MAC layer 409 in the RLC layer 408 and transmitted from the RLC layer 408 to the MAC layer 409 may be referred to as RLC PDUs.
[0103] The SDU of a layer may be the PDU of the next higher layer, just as the PDU of the layer may be the SDU of the next lower layer. For example, an SDAP PDU sent from the SDAP layer 417 to the PDCP layer 407 may be referred to as a PDCP SDU upon being received by the PDCP layer 407. As another example, a PDCP PDU sent from the PDCP layer 407 to the RLC layer 408 may be referred to as an RLC SDU upon being received by the RLC layer 408. Similarly, a MAC SDU sent from the MAC layer 409 to the RLC layer 408 may be referred to as an RLC PDU upon being received by the RLC layer 408.
[0104] Each layer within the protocol stack can convert a PDU to an SDU and convert an SDU to a PDU by performing various operations assigned to the layer on the packet. For example, an RLC SDU can be segmented by the RLC layer 408 to cover the RLC SDU to one or more RLC PDUs. Similarly, multiple received RLC PDUs can be reordered and reorganized to cover multiple received RLC PDUs to an RLC SDU. In addition, a layer can add data to a packet to convert an SDU to a PDU, or a layer can remove data from a packet to convert a PDU to an SDU. For example, the RLC layer 408 can add a packet header / footer to the RLC SDU to convert the RLC SDU to an RLC PDU. Similarly, the RLC layer 408 can remove a packet header / footer from the RLC PDU to convert an RLC PDU to an RLC SDU.
[0105] refer to Figure 4A , the following is an example of packet handling when one communication device 401 sends a communication that is received by another communication device 415.
[0106] An application of the higher data layer 402 of the sending communication device 401 may generate packets of a message 420 for transmission to an application 403 of the receiving communication device. The packets of the message 420 may be sent from the higher data layer 401 to the SDAP layer 417, which may send the message as a PDCP SDU 419 to the PDCP layer 407 of the modem stack 406 on the sending communication device 401.
[0107] The PDCP layer 407 may receive the packet of the message as a PDCP SDU 419 and convert the PDCP SDU into a PDCP PDU 421. The PDCP layer 407 may transmit the PDCP PDU 421 to the lower RLC layer 408.
[0108] The RLC layer 408 may receive the PDCP PDU 421 as an RLC SDU, and may convert the RLC SDU (i.e., the PDCP PDU 421) into one or more RLC PDUs 422 by, for example, adding an RLC packet header / footer and / or applying segmentation. As an example, when the RLC SDU (i.e., the PDCP PDU 421) is larger than the maximum RLC PDU size, it may be necessary to segment the RLC SDU into multiple RLC PDUs 422. When segmentation is applied to convert the RLC SDU into multiple RLC PDUs 422, each created RLC PDU 422 may be associated with a single RLC SDU (i.e., a single PDCP PDU 421). In addition, the RLC layer 408 may add a sequence number to the one or more RLC PDUs 422. The sequence number may indicate the ordering of the one or more RLC PDUs 422. The RLC layer 408 may transmit one or more RLC PDUs 422 to the lower MAC layer 409, which may transmit one or more MAC SDUs 424 to the physical layer 410. A similar process occurs in the protocol stack 406 on the receiving UE when SDUs are exchanged 428-434 between the physical layer 410, the MAC layer 409, the RLC layer 408, the PDCP layer 407, and the SDAP layer 417.
[0109] Figure 4B is a diagram for sending a Figure 4B Figure 1. Network architecture diagram of 5G NR RAN architecture delivering multicast services to UEs (labeled as UEs) in Figure 1. Figures 1 to 4A , multicast services can be delivered along point-to-multipoint (PTM) paths (also known as multicast) and / or point-to-point (PTP) paths (also known as unicast). For a multicast / broadcast (MB) flow (MB-Flow), the session management function (SMF) can configure the MB context identifier (ID), MB flow ID, and the associated quality of service (QoS) flow ID. For a given multicast session, the base stations in the 5G NR RAN (in Figure 4B Similarly, a base station in a 5G NR RAN (denoted as gNB-CU in the figure) can send packets to a group of many different wireless devices via a multicast radio bearer (MRB). Figure 4BIn some implementations, the SMF and the user plane function (UPF) may be shared or independent. In some implementations, an MB PDU session may be associated with a unicast PDU session. In some implementations, an MB PDU session may not be associated with a unicast PDU session. In some implementations, a unicast PDU session may be associated with an MB PDU session to support mobility of wireless devices from MRB to DRB. In some implementations, the UPF delivers MB data to the gNB via the MB-N3 interface (PTM) or the N3 interface (PTP). In some implementations, the gNB may be configured to select whether to serve multicast data via an MRB or a DRB. The selection between an MRB and a DRB may support multicast session service continuity.
[0110] Figure 4C The diagram shows the packet transformation through L2 layer, PDCP, RLC and MAC. Figures 1 to 4C , illustrating various headers added in the transmit (Tx) direction and removed in the receive (Rx) direction. Packets for transmission in a multicast session may have a PDCP header added by a PDCP entity at the PDCP layer, thereby generating a PDCP PDU. The PDCP PDU may have an RLC header added by an RLC entity at the RLC layer, thereby generating an RLC PDU. The RLC PDU may have a MAC subheader added by a MAC entity at the MAC layer, thereby generating a MAC PDU. In the 5G NR RAN, fast packet processing may be supported in the L2 user plane (U-plane). Once entering the PDCP layer, the L2 packets may continue to be processed quickly to the MAC layer. RLC "real-time" segmentation may be disconnected from automatic repeat request (ARQ) operations. Segmented and / or re-segmented RLC SDUs may be stored in an L2 buffer. The RLC header may be processed "offline" to be marked with segmentation and / or re-segmentation flags. When RLC Acknowledged Mode (AM) is configured, ARQ may be logically handled by Tx / Rx windowing and reassembly timers and / or state prohibit timers.
[0111] Various embodiments may provide for utilizing an enhanced MRB architecture that utilizes PDCP status reporting by a wireless device to a base station of a 5G NR RAN. Various embodiments may support multiple RLC entities, also referred to as RLC branches, in a multicast session. One or more multicast RLC branches may be used for multicast and / or unicast transmissions to a wireless device, and a unicast RLC branch may be used for unicast transmissions to a specific wireless device. Various embodiments may enable PDCP level retransmissions of PDCP protocol data units (PDUs).
[0112] Figure 4D The diagram illustrates the MRB architecture based on PDCP retransmission from the perspective of the gNB according to various embodiments. Figures 1 to 4D In various embodiments, the PDCP entity 450 of the PDCP layer may be configured to select to send packets to a multicast RLC entity (e.g., a multicast RLC branch) or a unicast RLC entity (e.g., a unicast RLC branch). For example, the PDCP entity 450 may send a PDCP PDU to a multicast RLC entity 451, and the PDCP entity 450 may send a PDCP PDU to a unicast RLC entity 452. In various embodiments, such as a switchable PDCP entity 450 may be associated with an MRB for a multicast session. For example, Figure 4D MRB2 is illustrated in association with a PDCP entity 450 that provides robust header compression (ROHC) and access stratum (AS) security, such as encryption. ROHC and / or AS security may be optional. A multicast RLC entity 451 may be configured with a single logical channel identifier (LCID) and provides packets to the MAC layer for use in multicast traffic using the LCID (e.g., Figure 4D The MAC layer may perform HARQ operations to encode packets from the multicast RLC entity 451 using a group radio network temporary identifier (G-RNTI) and send the packets via the multicast transport channel. The unicast RLC entity 452 may be configured with a single logical channel identifier (LCID) and provide packets to the MAC layer for use in transmitting packets using the LCID (e.g., Figure 4D The MAC and PHY layers may perform HARQ operations to encode packets from the unicast RLC entity 452 using a cell radio network temporary identifier (C-RNTI) and send the packets via the unicast transport channel.
[0113] In various embodiments, the PDCP entity 450 may be configured to support PDCP retransmissions, such as PDCP ARQ retransmissions. In various embodiments, PDCP retransmissions may increase the reliability of the L1 layer and the L2 layer in a multicast session because the PDCP entity 450 may retransmit the PDCP PDU by multicast / broadcast transmission via the multicast RLC entity 451 or by unicast transmission via the unicast RLC entity 452. Various embodiments utilizing the PDCP entity 450 with a replicated RLC entity structure (such as the multicast RLC entity 451 and the unicast RLC entity 452) may enable a base station to switch to unicast transmission and / or enable a wireless device to transition to a base station that does not support multicast without reconfiguring the MRB as a DRB for a multicast PDU session. In various embodiments, the 5G NRRAN may maintain a given MRB with its logical channel for unicast delivery (e.g., Figure 4D Mapping between DTCH0 of MRB2 in.
[0114] In various embodiments, when the base station activates a switchable PDCP entity 450 having two RLC entities 451, 452, the wireless device can similarly maintain two RLC entities, namely a multicast RLC entity and a unicast RLC entity, and for each PDCP entity, the wireless device maintains a multicast session. In various embodiments, the multicast RLC entity at the base station (e.g., the multicast RLC entity 451) and the multicast RLC entity at the wireless device can operate in UM or TM mode. In various embodiments, the unicast RLC entity at the base station (e.g., the unicast RLC entity 452) and the unicast RLC entity at the wireless device can operate in AM or UM mode.
[0115] In various embodiments, the wireless device may be configured to provide a PDCP status report to a base station of the 5G NR RAN. The PDCP status report may indicate at least a first missing count (FMC) of the next unreceived PDCP PDU for the multicast session. In various embodiments, the PDCP entity 450 may receive the PDCP status report and use the PDCP status report to enable PDCP retransmission. In various embodiments, the base station of the 5G NR RAN may maintain a retransmission buffer at the PDCP layer. The base station of the 5G NR RAN may store a copy of a packet for transmission in a multicast session in the retransmission buffer. For example, the PDCP entity 450 may store a copy of a packet for transmission in the retransmission buffer. The base station of the 5G NR RAN may add a PDCP header to the packet for transmission to generate a PDCP PDU, and provide the PDCP PDU to the multicast RLC entity 451 and / or the unicast RLC entity 452 for transmission on a multicast RLC branch or a unicast RLC branch.
[0116] Figure 4D The architecture illustrated in illustrates a common PDCP 450 entity, where the multicast RLC branch operates in UM or TM mode and the unicast RLC branch operates in UM or AM mode. PDCP level retransmissions may be used because the multicast RLC branch may not be configured to support ARQ. PDCP retransmissions may be issued by a base station (e.g., gNB) over a unicast or multicast RLC branch.
[0117] Figure 4E The enhanced PDCP functionality of MRB supporting PDCP retransmission according to various embodiments is illustrated. Figures 1 to 4E , Figure 4E The diagram illustrates a retransmission buffer in the Tx path and a PDCP status report, such as a PDCP status PDU, generated in the Rx path. For example, a PDCP status PDU module on a wireless device may track PDCP PDU reception and generate a PDCP status report. The PDCP status PDU module may monitor receive buffer reordering and discard copies of packets received at the PDCP layer of the wireless device. The PDCP status PDU module may issue a PDCP status report to a base station of the 5G NR RAN. The PDCP layer of the base station of the 5G NR RAN may use the PDCP status report to determine whether retransmission of the PDCP PDU may be required.
[0118] As an example, the basic procedures in the PDCP Tx path may include associating a COUNT value corresponding to TX_NEXT to the PDCP SDU, performing header compression of the PDCP SDU when ROHC is configured for MRB, performing IP and encryption using TX_NETX when AS security is configured for MRB, retransmitting the PDCP SDU based on one or more received PDCP status reports to recover from a retransmission buffer, setting the PDCP serial number (SN) of the PDCP data PDU to TX_NEXT, incrementing TX_Next by 1, and submitting the resulting PDCP data PDU to a lower layer (e.g., to the multicast RLC entity 451 and / or the unicast RLC entity 452).
[0119] As an example, the basic procedures in the PDCP Rx path may include: performing window-based PDCP Rx procedures (e.g., for PDCP in-order delivery and PDU duplicate detection), and generating a PDCP status report (e.g., PDCP status PDU) to feedback the PDCP Rx status. The wireless device may issue a PDCP status report via a unicast RLC branch.
[0120] Various embodiments support polling in the PDCP Tx path. In various embodiments, a polling mechanism may be provided in the PDCP Tx path to support PDCP status PDU feedback from the PDCP Rx path. In various embodiments, PDCP polling may operate in conjunction with or in place of RLC AM polling.
[0121] In some embodiments, a PDCP entity (such as PDCP entity 450) in a PDCP Tx path may configure periodic polling. In various embodiments, a PDCP entity (such as PDCP entity 450) may determine whether a polling condition has occurred, and in response to the occurrence of a polling condition, a polling may be triggered to receive a PDU status report from one or more wireless devices. In some embodiments, a periodic polling timer may be configured by RRC signaling. In some embodiments, when a polling timer expires, a polling bit may be inserted into a PDCP data PDU. As a specific example, a first RRC parameter may enable or disable a polling timer, and a second RRC parameter may be a timer having a configuration value in PDCP-Config. Optionally, an infinite value may be represented as a disabled timer.
[0122] In various embodiments, a base station of the 5G NR RAN may determine whether a polling condition has occurred, and in response to determining that a polling condition has occurred, insert a polling bit into the next PDCP PDU to be transmitted. The polling condition may be expiration of a polling time. The polling condition may be that the number of PDCP PDUs sent reaches a threshold. The polling condition may be that the number of bytes of PDCP data sent reaches a threshold.
[0123] In some embodiments, a polling bit (e.g., a P field) may be inserted into a PDCP data PDU, such as in a PDCP header, to trigger a PDCP status report by the wireless device. The polling bit may be inserted in response to the number of PDCP data PDUs sent out without polling reaching a configured threshold, such as a threshold configured by RRC signaling. The polling bit may be inserted in response to the number of bytes of the PDCP data PDUs sent out without polling reaching a configured threshold, such as a threshold configured by RRC signaling.
[0124] In some embodiments, in the PDCP Rx path, the prohibit timer can be configured by RRC signaling. The PDCP Rx entity can be configured with a prohibit timer. In some embodiments, once the prohibit timer expires, the wireless device can generate and report a PDCP status PDU. The RRC configuration message can enable or disable the polling timer. The timer can be a configuration value in PDCP-Config, and an infinite value can be represented as a prohibit timer. In some embodiments, the prohibit timer starts or restarts when a PDCP data PDU arrives at an empty PDCP Rx buffer or a PDCP status PDU is issued. The PDCP status PDU can be issued only when the prohibit timer expires.
[0125] In various embodiments, in the downlink (DL) direction, a base station (e.g., a gNB) may issue a polling bit via a multicast RLC branch or a unicast RLC branch. In some embodiments using a multicast RLC branch, all wireless devices may receive a PDCP polling request. In the uplink (UL) direction, the wireless device may issue a PDCP status PDU via a unicast RLC branch. In some embodiments, the feedback probability may be configured per MRB to reduce UL load. For example, when a polling request is received, the wireless device may generate a random number and compare the random number to a probability factor to determine whether to issue feedback. In various embodiments, the probability factor may be configured to the wireless device as part of the MRB PDCP configuration.
[0126] Optionally, the base station (e.g., gNB) may set polling bits for different groups of wireless devices (such as subgroups) so that only subgroups of wireless devices may trigger an RLC status report. For example, different subgroups of wireless devices may be mapped to different bits 11, 10, 01, 00. The group division may be based on the last digit of a subscription permanent identifier (SUPI), an international mobile subscriber identity (IMSI), a C-RNTI, a G-RNTI, etc. In some embodiments, using a unicast RLC branch, a base station (e.g., gNB) may issue a polling bit PDCP PDU to a selected wireless device (e.g., a wireless device with a certain RF channel condition). In the UL direction, the wireless device may issue a PDCP status report, such as a PDCP status PDU, via a unicast RLC branch.
[0127] Figure 4F Various aspects of a PDCP status report, such as a PDCP Status PDU, are illustrated. Figures 1 to 4F, three example PDCP status PDU formats 460, 461, and 462 that may support PDCP status reporting are illustrated. In various embodiments, in the PDCP Rx path, the PDCP Rx entity generates a PDCP status PDU 460 to indicate the status of a received PDCP data PDU. The PDCP status PDU 460 may be sent via unicast on a per-wireless device basis. The PDCP status PDU 460 may include the following fields: FMC (First Missing Count) indicates the COUNT of the next unreceived PDCP SDU; Bitmap indicates the PDCP SDUs missing or correctly received starting from the FMC in the PDCP Rx path, where a value of "1" indicates received and a value of "0" indicates missing. The PDCP status PDU 460 format includes an FMC that may be 32 bits. This field indicates the COUNT value of the first missing PDCP SDU within a reordering window (e.g., RX_DELIV). The PDCP status PDU 460 format may optionally include a bitmap. This field indicates which SDUs are missing and which SDUs are correctly received in the receiving PDCP entity. The bit position of the Nth bit in the bitmap is N, that is, the bit position of the first bit in the bitmap is 1.
[0128] In addition, PDCP PDU formats 461 and 462 may support ARQ retransmission procedures in PDCP. In various embodiments, when the PDCP Tx entity receives a PDCP status PDU from a PDCP Rx entity of a plurality of wireless devices, the PDCP Tx entity may decide to retransmit the PDCP SN based on feedback of a plurality of PDCP status reports from the plurality of wireless devices. The PDCP Tx entity may determine whether to retransmit the PDCP PDU through a multicast RLC branch or a unicast RLC branch based on the number of wireless devices requesting retransmission. PDCP PDU formats 461 and 462 may be 12-bit and 18-bit PDCP SNs. If there is no PDCP-based AS security, the PDCP data PDU may not include a MAC-integrity (MAC-I) field.
[0129] In various embodiments, the PDCP entity may be associated with the MRB of the multicast session and the DRB of the multicast session. In this way, the PDCP entity of the PDCP layer may be a common PDCP entity for the multicast RLC leg and the unicast RLC leg of the multicast session.
[0130] Figure 4G An example architecture of a common PDCP entity 470 for MRB and DRB RLC legs is illustrated according to various embodiments. Figures 1 to 4G, the common PDCP entity 470 is similar to the PDCP entity 450, except that both MRBs and DRBs are associated with the PDCP entity 470. The PDCP replication structure of the PDCP entity 470 can allow switching between unicast and multicast without reconfiguring the MRBs and / or DRBs. The common PDCP entity 470 can enable low-loss switching between MRBs and DRBs through various PDCP recovery and retransmission embodiments discussed herein. The common PDCP entity 470 can enable low-loss switching between MRB to MRB, MRB to DRB, and DRB to MRB during handover. In various embodiments, the common PDCP entity 470 can support MRB RLC branches and DRB RLC branches. In various embodiments, PDCP level retransmission can be supported by the common PDCP entity 470. The common PDCP entity 470 can select a multicast RLC branch for retransmission or a unicast RLC branch for retransmission.
[0131] In various embodiments, the logical channel configuration of the RLC entities 451, 452 associated with the common PDCP entity 470 may differ depending on the mode the multicast RLC entity 451 may be operating in. In various embodiments, the multicast RLC entity 451 may be configured to operate in either AM or UM mode.
[0132] In various embodiments, when the multicast RLC entity 451 may be operating in AM mode, the multicast RLC entity 451 may be associated with two different logical channels, such as two different LCIDs. The first LCID may be used for multicast and may be associated with the G-RNTI used for HARQ operations. The second LCID may be used for unicast (or wireless device specific transmission) and may be associated with the C-RNTI used for HARQ operations. For example, Figure 4G A multicast RLC entity 451 is illustrated with a first LCID of MBTCH2 and a second LCID of data traffic channel X (DTCHX). A unicast RLC entity 452 may have its own corresponding LCID (e.g., a third LCID DTCHY). The LCID of the unicast RLC entity 452 may be associated with a C-RNTI for HARQ operation. The configuration of the unicast RLC entity 452 under AM or UM may be a configuration choice.
[0133] In various embodiments, when the multicast RLC entity 451 may be operating in UM mode, the multicast RLC entity 451 may have a single LCID. RLC retransmission may not be supported in UM mode because there may be only a single LCID associated with the multicast RLC entity 451. This single LCID (e.g., LCID MBTCH 2) of the multicast RLC entity 451 may be used for multicast and may be associated with the G-RNTI for HARQ operation. Thus, no separate data channel may be associated with the multicast RLC entity 451 in UM mode. The unicast RLC entity 452 may have its own corresponding LCID (e.g., a second LCID DTCHY). The LCID of the unicast RLC entity 452 may be associated with the C-RNTI for HARQ operation. The configuration of the unicast RLC entity 452 under AM or UM may be a configuration choice.
[0134] In various embodiments, the 5G NR RAN network may activate and / or deactivate a multicast RLC branch (e.g., multicast RLC entity 451) or a unicast RLC branch (e.g., unicast RLC entity 452). The RLC branch may be deactivated by MAC control element (CE) signaling, RRC signaling, PDCCH signaling, etc. In various embodiments, when the RLC branch is deactivated by the 5G NR RAN, the wireless device may maintain the deactivated RLC branch configuration in a suspended state. In this way, if the RLC branch is reactivated by the 5G NR RAN, time may be saved by avoiding reconfiguration of the reactivated RLC branch.
[0135] In various embodiments, at the time of switching between the MRB RLC branch and the DRB RLC branch, data recovery may be supported by PDCP level retransmission.For example, a PDCP status report trigger may be activated in response to switching between an MRB and a DRB.
[0136] Figure 4G The architecture diagram shows that one MRB and one DRB can be integrated with a common PDCP entity 470. The MRB branch uses a multicast RLC entity 451, which can operate in AM or UM mode to support ARQ-based retransmissions for the multicast RLC branch. The unicast DRB RLC branch can also operate in AM or UM mode, and the selection of AM or UM mode can be specific to a wireless device. Figure 4GIn an architecture of , PDCP level ARQ may not be required, since the multicast RLC entity may be able to support ARQ functionality. In various embodiments, PDCP retransmission may be used for MRB to DRB (or DRB to MRB) switching to avoid any data loss due to activation and deactivation of one of the RLC branches. A multicast RLC branch may be associated with two LCIDs, one LCID for multicast and the other for unicast RLC retransmission purposes.
[0137] for Figure 4G In the architecture of the present invention, the multicast RLC branch can be configured in AM mode and associated with 2 LCIDs, such as one multicast LCID and one unicast LCID. Multicast RLC branch retransmissions can be via the multicast LCID for all wireless devices or via the unicast LCID intended for a specific wireless device. The multicast LCID data can be sent using a HARQ process, which can be scrambled with the G-RNTI and the multicast LCID. Similarly, the unicast LCID data can be sent to the wireless device using a HARQ operation and can be scrambled with the C-RNTI at the physical layer. In various embodiments, the multicast RLC entity 451 can be identified by a multicast LCID and a G-RNTI for a group of wireless devices or by a unicast LCID and a C-RNTI for a specific wireless device.
[0138] Figure 4H An example architecture of a common PDCP entity 480 for MRB and DRB RLC legs is illustrated according to various embodiments. Figures 1 to 4H , the common PDCP entity 480 is similar to the PDCP entity 470, except that the MAC entity supports sharing of G-RNTI and C-RNTI for HARQ processes for multicast packets. The MAC entity may enable hybrid HARQ operation for MRBs and DRBs.
[0139] In various embodiments, the common PDCP entity 480 may interface with the multicast RLC entity 451 so that the multicast RLC entity may operate under AM or UM. The multicast RLC entity 451 may have a single LCID (e.g., Figure 4HLCID MBTCH2 in the multicast RLC entity 451). RLC retransmission can be supported. This single LCID (e.g., LCID MBTCH 2) of the multicast RLC entity 451 can be used for multicast and can be associated with a G-RNTI for HARQ operation or a C-RNTI for HARQ operation. A MAC-level decision can determine whether the retransmission continues via the multicast G-RNTI (such as via a multicast channel) or via a unicast C-RNTI (such as via a unicast channel). The unicast RLC entity 452 can have its own corresponding LCID (e.g., a second LCID DTCHY). The LCID of the unicast RLC entity 452 can be associated with the C-RNTI for HARQ operation. The configuration of the unicast RLC entity 452 under AM or UM can be a configuration selection. In some embodiments, within the multicast HARQ process, the G-RNTI can be used for HARQ operations in the initial Tx of the PDCP PDU, and the HARQ retransmission operation can use the G-RNTI or C-RNTI for multicast retransmission. In various embodiments, soft combining of original HARQ transmissions using G-RNTI and retransmissions using C-RNTI may be supported.
[0140] Figure 4H The architecture is similar to Figure 4G , but the key difference is how HARQ Figure 4H The multicast RLC entity 451 and Figure 4H The multicast RLC data may be associated with a single multicast LCID in all modes in the architecture. The multicast RLC data may be sent using a HARQ process that may use G-RNTI, C-RNTI, or a mix of G-RNTI and C-RNTI in any manner. The use of G-RNTI in the HARQ operation may result in all wireless devices of the group being able to decode, and the use of C-RNTI may result in only the target wireless device being able to decode. For unicast RLC data, HARQ may be associated with C-RNTI scrambling only.
[0141] for Figure 4H In the architecture, the multicast RLC entity 451 can be configured in AM mode and associated with a multicast LCID. Multicast RLC branch retransmissions can be based on a multicast HARQ process, where the base station (e.g., gNB) can flexibly use G-RNTI or C-RNTI scrambling for HARQ transmission. For example, for initial Tx, the encoding of the packet can be based on G-RNTI scrambling, and retransmissions can be performed with C-RNTI or G-RNTI scrambling. The multicast RLC entity 451 can be identified by G-RNTI and multicast LCID, or C-RNTI and multicast LCID.
[0142] exist Figure 4G and Figure 4H In the architecture, the PDCP entity is common to both MRBs and DRBs. Figure 4G and 4H In the architecture of , the DRB RLC branch can be used for initial transmission of multicast data for a specific wireless device or retransmission of multicast data for a specific wireless device using a unicast RLC branch at the time of switching from MRB to DRB.
[0143] In various embodiments, such as Figure 4G and Figure 4H In the architecture illustrated in FIG, the PDCP entity (e.g., PDCP entities 470, 480) may be common to both MRBs and DRBs, and the DRB RLC branch may be used for initial transmission of multicast data for a specific wireless device or retransmission of multicast data for a specific wireless device using a unicast RLC branch when switching from an MRB to a DRB.
[0144] In various embodiments, any HARQ transmission or HARQ retransmission from the unicast RLC branch may use only unicast HARQ, such as HARQ operations that use the C-RNTI to encode packets, and any HARQ transmission or HARQ retransmission from the multicast RLC branch may use either the G-RNTI or the C-RNTI for packet encoding in a flexible manner.
[0145] Figure 5A , Figure 5B , Figure 5C , Figure 5D , Figure 5E , Fig. 5F , Figure 5G , Figure 5H , Fig.5I , Figure 5J and Figure 5K Operations of a method 500 for supporting retransmissions in a multicast session conducted in a fifth generation (5G) new radio (NR) (5G NR) radio access network (RAN) are illustrated in accordance with various embodiments. The operations of the method 500 presented below are intended to be illustrative. In some embodiments, the method 500 may be performed with one or more additional operations not described and / or without one or more of the operations discussed. Furthermore, the operations of the method 500 may be performed in a manner that is not described in detail. Figure 5A , Figure 5B , Figure 5C , Figure 5D , Figure 5E , Fig. 5F , Figure 5G , Figure 5H , Fig.5I , Figure 5J and Figure 5K The order illustrated in and described below is not intended to be limiting.
[0146] In some embodiments, the method 500 may be implemented in one or more processors (e.g., digital processors, analog processors, digital circuits designed to process information, analog circuits designed to process information, state machines, and / or other mechanisms for electronically processing information) of a wireless device (e.g., wireless devices 120a-120e, 200, 320, 415). The one or more processors may include one or more devices that perform some or all of the operations of the method 500 in response to instructions stored electronically on an electronic storage medium. The one or more processors may include one or more devices that are configured by hardware, firmware, and / or software to be specifically designed to perform one or more of the operations of the method 500. For example, referring to Figures 1 to 5A , Figure 5B , Figure 5C , Figure 5D , Figure 5E , Fig. 5F , Figure 5G , Figure 5H , Fig.5I , Figure 5J and Figure 5K The operations in the method 500 may be performed by a wireless device (e.g., wireless devices 120a-120e, 200, 320, 415). As a specific example, the operations may be performed by a PDCP entity (e.g., a PDCP entity 450, 470, 480 running on a wireless device (e.g., wireless devices 120a-120e, 200, 320, 415).
[0147] Figure 5A Illustrated is a method 500 that may be performed by a processor of a wireless device according to various embodiments.
[0148] In box 502, the processor may perform operations including: determining whether a PDCP status reporting condition for a multicast session has occurred. In various embodiments, the PDCP status reporting condition for the multicast session may include receiving a PDCP PDU including a polling bit from a base station of the 5G NR RAN. In some embodiments, the PDCP PDU including the polling bit may be received via a unicast transmission channel. In some embodiments, the PDCP PDU including the polling bit may be received via a multicast transmission channel. In various embodiments, the PDCP PDU including the polling bit may include a subgroup identifier, and determining whether a PDCP status reporting condition for a multicast session has occurred may include: determining whether the subgroup identifier corresponds to a subgroup identifier configured for the wireless device. In various embodiments, the PDCP status reporting condition for the multicast session may include the expiration of a countdown timer associated with the PDCP status report.
[0149] In block 504, the processor may perform operations including generating a PDCP status report of the FMC indicating at least a next unreceived PDCP PDU for the multicast session in response to determining that a PDCP status reporting condition for the multicast session has occurred.
[0150] In box 506, the processor can perform operations including: issuing a PDCP status report to a base station of the 5G NR RAN.
[0151] Figure 5B Additional or alternative operations are illustrated that may be performed by a processor as part of method 500 according to some embodiments.
[0152] In block 508, the processor may perform operations including: receiving a retransmitted PDCP PDU from a base station of the 5G NR RAN via a unicast transport channel or a multicast transport channel. The retransmitted PDCP PDU may correspond to a next unreceived PDCP PDU. In some embodiments, the next unreceived PDPC PDU was scheduled to be received via a multicast transport channel, and the retransmitted PDCP PDU may be received via the multicast transport channel. In some embodiments, the next unreceived PDPC PDU was scheduled to be received via a multicast transport channel, and the retransmitted PDCP PDU may be received via a unicast transport channel.
[0153] Figure 5C Additional or alternative operations are illustrated that may be performed by a processor as part of method 500 according to some embodiments.
[0154] In block 510, the processor may perform operations including: generating a random number in response to receiving a PDCP PDU including a polling bit. In various embodiments, the probability factor may be configured as part of the MRB PDCP configuration. The generated random number may be used together with the probability factor to determine whether the wireless device should issue a PDCP status report.
[0155] In block 512, the processor may perform operations including determining whether a PDCP status reporting condition for a multicast session has occurred by determining whether the random number corresponds to a PDCP status reporting condition based at least in part on a probability factor.
[0156] Figure 5D Additional or alternative operations are illustrated that may be performed by a processor as part of method 500 according to some embodiments.
[0157] In block 514, the processor may perform operations including: activating a unicast RLC entity associated with a unicast transport channel of an MRB for a multicast session and a multicast RLC entity associated with a multicast transport channel of an MRB for a multicast session. In various embodiments, the unicast RLC entity may operate in an acknowledged mode (AM) or an unacknowledged mode (UM), and the multicast RLC entity may operate in an UM or a transparent mode. TM Next operation.
[0158] Figure 5E Additional or alternative operations are illustrated that may be performed by a processor as part of method 500 according to some embodiments.
[0159] In block 516, the processor may perform operations including receiving an indication from a base station to deactivate a unicast RLC entity or to deactivate a multicast RLC entity.
[0160] In block 518, the processor may perform operations including maintaining the RLC entity indicated for deactivation in a suspended state.
[0161] Fig. 5F Additional or alternative operations are illustrated that may be performed by a processor as part of method 500 according to some embodiments.
[0162] In block 520, the processor may perform operations including activating a unicast RLC entity associated with a unicast transport channel of an MRB for a multicast session and a multicast RLC entity associated with a multicast transport channel of an MRB for a multicast session. The multicast RLC may operate in AM.
[0163] In block 522, the processor may perform operations including configuring a multicast RLC entity with a first LCID for multicast reception and a second LCID for unicast reception.
[0164] In block 524, the processor may perform operations including configuring the unicast RLC entity with a third LCID for unicast reception.
[0165] Figure 5G Additional or alternative operations are illustrated that may be performed by a processor as part of method 500 according to some embodiments.
[0166] In block 526, the processor may perform operations including receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a first LCID. The packet may be HARQ encoded with the first LCID and a G-RNTI.
[0167] In block 528, the processor may perform operations including receiving a packet for the multicast session from a base station of the 5G NR RAN associated with the second LCID. The packet may be HARQ encoded with the second LCID and the C-RNTI.
[0168] In block 530, the processor may perform operations including: receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a third LCID. The packet may be HARQ encoded with the third LCID and C-RNTI.
[0169] Figure 5H Additional or alternative operations are illustrated that may be performed by a processor as part of method 500 according to some embodiments.
[0170] In block 532, the processor may perform operations including activating a unicast RLC entity associated with a unicast transport channel of an MRB for a multicast session and a multicast RLC entity associated with a multicast transport channel of an MRB for a multicast session. The multicast RLC may operate under UM.
[0171] In block 534, the processor may perform operations including configuring a multicast RLC entity with a first LCID for multicast reception.
[0172] In block 536, the processor may perform operations including configuring the unicast RLC entity with a second LCID for unicast reception.
[0173] Fig.5I Additional or alternative operations are illustrated that may be performed by a processor as part of method 500 according to some embodiments.
[0174] In block 538, the processor may perform operations including receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a first LCID. The packet may be HARQ encoded with the first LCID and a G-RNTI.
[0175] In block 540, the processor may perform operations including receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a second LCID. The packet may be HARQ encoded with the second LCID and C-RNTI.
[0176] Figure 5J Additional or alternative operations are illustrated that may be performed by a processor as part of method 500 according to some embodiments.
[0177] In block 542, the processor may perform operations including activating a unicast RLC entity associated with a unicast transport channel of an MRB for a multicast session and a multicast RLC entity associated with a multicast transport channel of an MRB for a multicast session. The multicast RLC may operate in AM or UM, and the unicast RLC may operate in AM or UM.
[0178] In block 544, the processor may perform operations including configuring a multicast RLC entity with a first LCID for multicast reception.
[0179] In block 546, the processor may perform operations including configuring the unicast RLC entity with a second LCID for unicast reception.
[0180] Figure 5K Additional or alternative operations are illustrated that may be performed by a processor as part of method 500 according to some embodiments.
[0181] In block 548, the processor may perform operations including receiving a packet for a multicast session from a base station of a 5G NR RAN associated with the first LCID. The packet may be HARQ encoded with the first LCID and a G-RNTI, or the packet may be HARQ encoded with the first LCID and a C-RNTI.
[0182] In block 550, the processor may perform operations including receiving a packet for a multicast session from a base station of a 5G NR RAN associated with a second LCID. The packet may be HARQ encoded with the second LCID and C-RNTI.
[0183] Fig. 6A A method 600 is illustrated, and Figure 6B , Figure 6C , Fig.6D , Fig. 6E , Fig. 6F , Figure 6G , Figure 6H , Fig.6I , Figure 6J , Figure 6K , Figure 6L , Figure 6M and / or Figure 6NAlternative or additional operations of method 600 for supporting retransmissions in a multicast session conducted in a fifth generation (5G) New Radio (NR) (5G NR) radio access network (RAN) according to various embodiments are illustrated. The operations of method 600 presented below are intended to be illustrative. In some embodiments, method 600 may be performed with one or more additional operations not described and / or without one or more of the operations discussed. Furthermore, the operations of method 600 may be performed in Fig. 6A , Figure 6B , Figure 6C , Fig.6D , Fig. 6E , Fig. 6F , Figure 6G , Figure 6H , Fig.6I , Figure 6J , Figure 6K , Figure 6L , Figure 6M and / or Figure 6N The order illustrated in and described below is not intended to be limiting.
[0184] The operations in method 600 may be implemented in one or more processors of the base station, such as a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other machine for electronically processing information. The one or more processors may include one or more devices that perform some or all of the operations of method 600 in response to instructions stored electronically on an electronic storage medium. The one or more processors may include one or more devices that are configured by hardware, firmware, and / or software to be specifically designed to perform one or more of the operations of method 600. For example, referring to Figures 1 to 6N The operations of method 600 may be performed by a processor of a base station (e.g., base stations 110a-d, 350, 401). As a specific example, the operations may be performed by a PDCP entity (e.g., a PDCP entity 450, 470, 480 running on a processor of a base station (e.g., base stations 110a-d, 350, 401)).
[0185] Fig. 6A A method 600 is illustrated according to various embodiments.
[0186] In block 602, the processor may perform operations including receiving, at a PDCP layer, a packet for transmission in a multicast session.
[0187] In block 604, the processor may perform operations including storing a copy of the packet for transmission in a retransmission buffer of the PDCP layer.
[0188] In block 606, the processor may perform operations including adding a PDCP header to a packet for transmission to generate a PDCP PDU.
[0189] refer to Figure 6B In block 608, the processor may perform operations including receiving a PDCP status report from at least one wireless device receiving the multicast session. The PDCP status report may indicate at least an FMC for a next unreceived PDCP PDU for the multicast session.
[0190] In block 610, the processor may perform operations including determining that a stored copy of a packet for transmission in a retransmission buffer of a PDCP layer is associated with an FMC for a next non-received PDCP PDU for a multicast session.
[0191] In block 612, the processor may perform operations including adding a PDCP header to the determined stored copy of the packet for transmission in a retransmission buffer of the PDCP layer to generate a retransmitted PDCP protocol PDU.
[0192] In block 614, the processor may perform operations including: selecting one of a unicast RLC entity for the MRB for the multicast session or a multicast RLC entity associated with a multicast transport channel for the MRB for the multicast session. In various embodiments, selecting one of the unicast RLC entity or the multicast RLC entity for retransmission may be based at least in part on the number of wireless devices requesting retransmission.
[0193] In block 616, the processor may perform operations including sending the retransmitted PDCP PDU to the selected RLC entity for retransmission.
[0194] Figure 6C Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0195] In block 618, the processor may perform operations including determining whether a polling condition has occurred. In some embodiments, the polling condition may be expiration of a polling time. In some embodiments, the polling condition may be that the number of PDCP PDUs sent reaches a threshold or the number of bytes of PDCP data sent reaches a threshold.
[0196] In block 620, the processor may perform operations including inserting a polling bit into a next PDCP PDU to be transmitted in response to determining that a polling condition has occurred.
[0197] Fig.6D Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0198] In block 622, the processor may perform operations including determining a probability factor.
[0199] In block 624, the processor may perform operations including issuing an indication of the probability factor using RRC signaling.
[0200] Fig. 6E Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0201] In block 626, the processor may perform operations including determining a subgroup identifier of wireless devices selected to report the PDCP status.
[0202] In block 628, the processor may perform operations including inserting the subgroup identifier into a next PDCP PDU to be transmitted in response to determining that a polling condition has occurred.
[0203] Fig. 6F Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0204] In block 630, the processor may perform operations including receiving, at a PDCP entity associated with an MRB for the multicast session, a packet for transmission in the multicast session.
[0205] In block 632, the processor may perform operations including issuing a PDCP PDU to an RLC entity associated with a unicast transport channel of an MRB for a multicast session or a multicast RLC entity associated with a multicast transport channel of an MRB for a multicast session.
[0206] Figure 6G Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0207] In block 634, the processor may perform operations including separately applying HARQ operations to a unicast transmission channel of an MRB for a multicast session and a multicast transmission channel of an MRB for a multicast session.
[0208] Figure 6H Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0209] In block 636, the processor may perform operations including receiving, at a PDCP entity associated with both a multicast radio bearer of the multicast session and a data radio bearer of the multicast session, a packet for transmission in the multicast session.
[0210] Fig.6I Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0211] In block 638, the processor may perform operations including issuing a PDCP PDU to a multicast radio link control entity associated with a first logical channel identifier for multicast transmission and a second LCID for unicast transmission or to a unicast RLC entity associated with a third LCID for unicast transmission. In some embodiments, the multicast RLC entity operates in an acknowledged mode (AM) and the unicast RLC entity operates in an AM or unacknowledged mode (UM).
[0212] Figure 6J Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0213] In block 640, the processor may perform operations including encoding packets for a multicast session associated with the first LCID using a HARQ encoding operation based at least in part on the first LCID and the G-RNTI.
[0214] In block 642, the processor may perform operations including encoding packets for a multicast session associated with a second LCID using a HARQ encoding operation based at least in part on the second LCID and the C-RNTI.
[0215] In block 644, the processor may perform operations including encoding packets for a multicast session associated with a third LCID using a HARQ encoding operation based at least in part on the third LCID and the C-RNTI.
[0216] Figure 6K Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0217] In block 645, the processor may perform operations including: issuing a PDCP PDU to a multicast RLC entity associated with a first logical channel identifier for multicast transmission and a unicast RLC entity associated with a second LCID for unicast transmission. In some embodiments, the multicast RLC entity operates in an unacknowledged mode (UM) and the unicast RLC entity operates in an acknowledged mode (AM) or UM.
[0218] Figure 6L Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0219] In block 646, the processor may perform operations including encoding packets for a multicast session associated with the first LCID using a HARQ encoding operation based at least in part on the first LCID and the G-RNTI.
[0220] In block 647, the processor may perform operations including encoding packets for a multicast session associated with the second LCID using a HARQ encoding operation based at least in part on the second LCID and the C-RNTI.
[0221] Figure 6M Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0222] In block 648, the processor may perform operations including: issuing a PDCP PDU to a multicast radio link control entity associated with a first LCID for multicast transmission and a unicast RLC entity associated with a second LCID for unicast transmission. In some embodiments, the multicast RLC entity and the unicast RLC entity operate in an acknowledged mode (AM) or an unacknowledged mode (UM).
[0223] Figure 6N Additional or alternative operations are illustrated that may be performed by a processor as part of method 600 according to some embodiments.
[0224] In box 649, the processor can perform operations including: encoding packets for a multicast session associated with the first LCID using HARQ encoding operations based at least in part on the first LCID and the G-RNTI or using HARQ encoding operations based at least in part on the first LCID and the C-RNTI.
[0225] In block 650, the processor may perform operations including encoding a packet for a multicast session associated with the second LCID using a HARQ encoding operation based at least in part on the second LCID and the C-RNTI. In various embodiments, a packet for a multicast session associated with the first LCID that was originally encoded using a HARQ encoding operation based at least in part on the first LCID and the G-RNTI is retransmitted as a packet encoded using a HARQ encoding operation based at least in part on the first LCID and the C-RNTI.
[0226] Figure 7 7 is a component block diagram of a network computing device 700 (such as a base station (e.g., base stations 110a-d, 350)) suitable for use with various embodiments. This network computing device (e.g., a base station such as a gNB, eNB) may include at least Figure 7 Components shown in the figure. Figures 1 to 6N, the network computing device 700 may include a processor 701 coupled with a volatile memory 702 and a large-capacity non-volatile memory (such as a disk drive 703).
[0227] The network computing device 700 may also include a peripheral memory access device such as a floppy disk drive, a compact disk (CD), or a digital video disk (DVD) drive 706 coupled to the processor 701. The network computing device 700 may also include a network access port 704 (or interface) coupled to the processor 701 for establishing a data connection with a network such as the Internet and / or a local area network coupled to other system computers and servers.
[0228] The network computing device 700 may include one or more antennas 707 for emitting and receiving electromagnetic radiation that may be connected to a wireless communication link. The network computing device 700 may include additional access ports such as USB, Firewire, Thunderbolt, etc. for coupling to peripherals, external storage, or other devices.
[0229] Figure 8 is a component block diagram of a wireless device 800 suitable for use with various embodiments. Figures 1 to 7 , various embodiments may be implemented on a variety of wireless devices 800 (e.g., wireless devices 120a-120e, 200, 320, 120a-120e), an example of which is shown in Figure 8 800 is illustrated in the form of a smartphone. The wireless device 800 may include a first SOC 202 (e.g., SOC-CPU) coupled to a second SOC 204 (e.g., a 5G-enabled SOC). The first SOC 202 and the second SOC 204 may be coupled to an internal memory 816, a display 812, and to a speaker 814. The first SOC 202 and the second SOC 204 may also be coupled to at least one SIM 268 and / or a SIM interface, which may store information supporting a first 5G NR subscription and a second 5G NR subscription, the first 5G NR subscription and the second 5G NR subscription supporting services on a 5G non-standalone (NSA) network.
[0230] The wireless device 800 may include an antenna 804 for emitting and receiving electromagnetic radiation, which may be connected to a wireless transceiver 266 coupled to one or more processors in the first SOC 202 and / or the second SOC 204. The wireless device 800 may also include a menu selection button or rocker switch 820 for receiving user input.
[0231] The wireless device 800 also includes a sound coding / decoding (CODEC) circuit 810, which digitizes the sound received from the microphone into a data packet suitable for wireless transmission, and decodes the received sound data packet to generate an analog signal, which is provided to the speaker to generate sound. In addition, one or more of the processors in the first SOC 202 and the second SOC 204, the wireless transceiver 266, and the CODEC 810 may include a digital signal processor (DSP) circuit (not shown separately).
[0232] The processors of the wireless network computing device 700 and the wireless device 800 may be one or more of any programmable microprocessors, microcomputers or multi-processor chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described below. In some mobile devices, multiple processors may be provided, such as one processor within the SOC 204 dedicated to wireless communication functions and one processor within the SOC 202 dedicated to running other applications. Software applications may be stored in the memory 220, 816 before they are accessed and loaded into the processor. The processor may include internal memory sufficient to store application software instructions.
[0233] As used in this application, the terms "component", "module", "system", etc. are intended to include computer-related entities configured to perform specific operations or functions, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process, a processor, an object, an executable file, an execution thread, a program, and / or a computer running on a processor. By way of illustration, both an application running on a wireless device and a wireless device can be referred to as a component. One or more components can reside in a process and / or an execution thread, and a component can be located on a processor or core and / or distributed between two or more processors or cores. In addition, these components can be executed from various non-temporary computer-readable media having various instructions and / or data structures stored thereon. Components can communicate by means of local and / or remote processes, function or procedure calls, electronic signals, data packets, memory reads / writes, and other known network, computer, processor, and / or process-related communication methods.
[0234] Several different cellular and mobile communication services and standards are available or contemplated in the future, all of which can be implemented and benefit from various embodiments. Such services and standards include, for example, the Third Generation Partnership Project (3GPP), LTE systems, third generation wireless mobile communication technology (3G), fourth generation wireless mobile communication technology (4G), fifth generation wireless mobile communication technology (5G), and subsequent 3GPP technologies, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020TM), Enhanced Data Rates for GSM Evolution (EDGE), Advanced Mobile Phone System (AMPS), Digital AMPS (IS-136 / TDMA), Evolution Data Optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Network (WLAN), Wi-Fi Protected Access I & II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN). For example, each of these technologies involves the transmission and reception of voice, data, signaling and / or content messages. It should be understood that any reference to terminology and / or technical details related to individual telecommunication standards or technologies is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology unless specifically recited in the language of the claims.
[0235] The various embodiments shown and described are provided as examples only to illustrate the various features of the claims. However, the features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment and can be used or combined with other embodiments shown and described. In addition, the claims are not intended to be limited by any one example embodiment.
[0236] The foregoing method descriptions and process flow charts are provided merely as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter," "then," "next," etc. are not intended to limit the order of operations; these words are used to guide the reader through the description of the method. In addition, any reference to a claim element in the singular form, such as the use of the article "a," "an," or "the" should not be construed as limiting the element to the singular.
[0237] Various illustrative logic blocks, modules, components, circuits, and algorithmic operations described in conjunction with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been generally described above with respect to their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. A skilled person may implement the described functionality in a varying manner for each specific application, but this embodiment decision should not be interpreted as causing a deviation from the scope of the claims.
[0238] Hardware for implementing the various illustrative logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or performed using 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 device designed to perform the functions described herein, discrete gate or transistor logic, discrete hardware components, or any combination thereof. A general purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of receiver smart objects, for example, a combination of a DSP and a microprocessor, a combination of multiple microprocessors, a combination of one or more microprocessors in conjunction with a DSP core, or any other such configuration. Optionally, some operations or methods may be performed by circuits specific to a given function.
[0239] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The operation of the method or algorithm disclosed herein may be embodied in a processor-executable software module or a processor-executable instruction, which may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that can be accessed by a computer or processor. By way of example and not limitation, this non-transitory computer-readable or processor-readable storage medium may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, disk storage or other magnetic storage smart objects, or any other medium that can be used to store desired program codes in the form of instructions or data structures and can be accessed by a computer. As used herein, disks and discs include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and blue-ray discs, wherein the disks generally reproduce data magnetically, and the discs reproduce data optically with lasers. The above combinations are also included within the scope of non-transitory computer-readable media and processor-readable media. Furthermore, the operations of a method or algorithm may reside as one or any combination of code sets and / or instruction sets on a non-transitory processor-readable storage medium and / or a computer-readable storage medium, which may be incorporated into a computer program product.
[0240] The foregoing description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be 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 the claims. Therefore, the present disclosure is not intended to be limited to the embodiments shown herein, but is to be consistent with the widest scope consistent with the appended claims and the principles and novel features disclosed herein.
Claims
1. A method for supporting retransmission in a multicast session in a fifth generation 5G New Radio NR radio access network RAN, performed by a processor of a wireless device, comprising: determining whether a Packet Data Convergence Protocol (PDCP) status reporting condition for the multicast session has occurred; generating a PDCP status report indicating at least a first missing count FMC of a next non-received PDCP protocol data unit (PDU) for the multicast session in response to determining that the PDCP status reporting condition for the multicast session has occurred; Sending the PDCP status report to a base station of the 5G NR RAN; And receiving a retransmitted PDCP PDU from the base station of the 5G NRRAN via a multicast transmission channel, wherein the retransmitted PDCP PDU corresponds to the next unreceived PDCP PDU.
2. The method according to claim 1, wherein: The next unreceived PDCP PDU was scheduled to be received via the multicast transport channel; and The retransmitted PDCP PDU is received via the multicast transport channel.
3. The method according to claim 1, further comprising: A unicast radio link control, RLC, entity associated with a unicast transport channel of a multicast radio bearer, MRB, for the multicast session and a multicast RLC entity associated with the multicast transport channel of the MRB for the multicast session are activated.
4. The method according to claim 3, further comprising: receiving, from the base station, an instruction to deactivate the unicast RLC entity or to deactivate the multicast RLC entity; as well as The unicast RLC entity or the multicast RLC entity instructed to be deactivated is maintained in a suspended state.
5. The method according to claim 3, wherein: The unicast RLC entity operates in an acknowledged mode AM or an unacknowledged mode UM; and The multicast RLC entity operates in UM or transparent mode TM.
6. The method according to claim 1, further comprising: activating a unicast radio link control, RLC, entity associated with a unicast transport channel of a multicast radio bearer, MRB, for the multicast session and a multicast RLC entity associated with the multicast transport channel of the MRB for the multicast session, wherein the multicast RLC entities operate in acknowledged mode AM; configuring the multicast RLC entity with a first logical channel identifier LCID for multicast reception and a second LCID for unicast reception; and The unicast RLC entity is configured with a third LCID for unicast reception.
7. The method according to claim 6, further comprising: receiving a packet for the multicast session from the base station of the 5G NR RAN associated with the first LCID, wherein the packet is a hybrid automatic repeat request (HARQ) encoded with the first LCID and a group radio network temporary identifier (G-RNTI); receiving a packet for the multicast session from the base station of the 5G NR RAN associated with the second LCID, wherein the packet is HARQ encoded with the second LCID and a cell radio network temporary identifier (C-RNTI); or Receive packets for the multicast session from the base station of the 5G NR RAN associated with the third LCID, wherein the packets are HARQ encoded with the third LCID and the C-RNTI.
8. The method according to claim 1, further comprising: activating a unicast radio link control, RLC, entity associated with a unicast transport channel of a multicast radio bearer, MRB, for the multicast session and a multicast RLC entity associated with the multicast transport channel of the MRB for the multicast session, wherein the multicast RLC entities operate in an unacknowledged mode, UM; configuring the multicast RLC entity with a first logical channel identifier LCID for multicast reception; and The unicast RLC entity is configured with a second LCID for unicast reception.
9. The method according to claim 8, further comprising: receiving a packet for the multicast session from the base station of the 5G NR RAN associated with the first LCID, wherein the packet is a hybrid automatic repeat request (HARQ) encoded with the first LCID and a group radio network temporary identifier (G-RNTI); or Receiving packets for the multicast session from the base station of the 5G NR RAN associated with the second LCID, wherein the packets are HARQ encoded with the second LCID and a cell radio network temporary identifier (C-RNTI).
10. The method according to claim 1, further comprising: activating a unicast radio link control, RLC, entity associated with a unicast transport channel of a multicast radio bearer, MRB, for the multicast session and a multicast RLC entity associated with the multicast transport channel of the MRB for the multicast session, wherein the multicast RLC entity operates in an acknowledged mode, AM, or an unacknowledged mode, UM, and the unicast RLC entity operates in AM or UM; configuring the multicast RLC entity with a first logical channel identifier LCID for multicast reception; and The unicast RLC entity is configured with a second LCID for unicast reception.
11. The method according to claim 10, further comprising one of the following: receiving packets for the multicast session from the base station of the 5G NR RAN associated with the first LCID, wherein: The packet is a hybrid automatic repeat request HARQ encoded with the first LCID and a group radio network temporary identifier G-RNTI, or the packet is a HARQ encoded with the first LCID and a cell radio network temporary identifier C-RNTI; or Receive packets for the multicast session from the base station of the 5G NR RAN associated with the second LCID, wherein the packets are HARQ encoded with the second LCID and the C-RNTI.
12. A method for supporting retransmission in a multicast session, performed by a processor of a base station of a fifth generation 5G New Radio NR radio access network RAN, comprising: receiving, at a Packet Data Convergence Protocol (PDCP) layer, packets for transmission in the multicast session; storing a copy of the packet for transmission in a retransmission buffer of the PDCP layer; adding a PDCP header to the packet for transmission to generate a PDCP protocol data unit (PDU); receiving a PDCP status report from at least one wireless device receiving the multicast session, the PDCP status report indicating at least a first missing count (FMC) of a next unreceived PDCP PDU for the multicast session; determining that a stored copy of the packet for transmission in the retransmission buffer of the PDCP layer is associated with the FMC for the next unreceived PDCP PDU for the multicast session; adding a PDCP header to the determined stored copy of the packet for transmission in the retransmission buffer of the PDCP layer to generate a retransmitted PDCP protocol PDU; selecting a multicast radio link control, RLC, entity associated with a multicast transport channel of a multicast radio bearer, MRB, for the multicast session; and The retransmitted PDCP PDU is sent to the multicast RLC entity for retransmission.
13. The method according to claim 12, wherein: Selecting the multicast RLC entity for retransmission is based at least in part on a number of wireless devices requesting retransmission.
14. The method according to claim 12, wherein: Receiving the packet for transmission in the multicast session at the PDCP layer includes: receiving the packet for transmission in the multicast session at a PDCP entity associated with a multicast radio bearer (MRB) of the multicast session, the method further comprising: The PDCP PDU is sent out to a unicast radio link control, RLC, entity associated with a unicast transport channel of the MRB for the multicast session or a multicast RLC entity associated with the multicast transport channel of the MRB for the multicast session.
15. The method according to claim 14, wherein: The unicast RLC entity operates in an acknowledged mode AM or an unacknowledged mode UM; and The multicast RLC entity operates in AM, UM or transparent mode TM.
16. The method according to claim 14, further comprising: A hybrid automatic repeat request (HARQ) operation is separately applied to the unicast transmission channel of the MRB for the multicast session and the multicast transmission channel of the MRB for the multicast session.
17. The method according to claim 12, wherein: Receiving the packet for transmission in the multicast session at the PDCP layer includes receiving the packet for transmission in the multicast session at a PDCP entity associated with both a multicast radio bearer (MRB) of the multicast session and a data radio bearer (DRB) of the multicast session.
18. The method according to claim 17, further comprising: sending the PDCP PDU to a multicast radio link control RLC entity associated with a first logical channel identifier LCID for multicast transmission and a second LCID for unicast transmission or to a unicast RLC entity associated with a third LCID for unicast transmission, The multicast RLC entity operates in an acknowledged mode AM, and the unicast RLC entity operates in an AM or an unacknowledged mode UM.
19. The method according to claim 18, further comprising: encoding packets for the multicast session associated with the first LCID using a hybrid automatic repeat request (HARQ) encoding operation based at least in part on the first LCID and a group radio network temporary identifier (G-RNTI); encoding a packet for the multicast session associated with the second LCID using a HARQ encoding operation based at least in part on the second LCID and a cell radio network temporary identifier (C-RNTI); as well as Packets for the multicast session associated with the third LCID are encoded using a HARQ encoding operation based at least in part on the third LCID and the C-RNTI.
20. The method of claim 17, further comprising: sending the PDCP PDU to a multicast radio link control RLC entity associated with a first logical channel identifier LCID for multicast transmission and a unicast RLC entity associated with a second logical channel identifier LCID for unicast transmission, The multicast RLC entity operates in an unacknowledged mode UM, and the unicast RLC entity operates in an acknowledged mode AM or UM.
21. The method according to claim 20, further comprising: encoding packets for the multicast session associated with the first LCID using a hybrid automatic repeat request (HARQ) encoding operation based at least in part on the first LCID and a group radio network temporary identifier (G-RNTI); and Packets for the multicast session associated with the second LCID are encoded using a HARQ encoding operation based at least in part on the second LCID and a cell radio network temporary identifier (C-RNTI).
22. The method of claim 17, further comprising: sending the PDCP PDU to a multicast radio link control RLC entity associated with a first logical channel identifier LCID for multicast transmission and a unicast RLC entity associated with a second logical channel identifier LCID for unicast transmission, The multicast RLC entity and the unicast RLC entity operate in an acknowledged mode AM or an unacknowledged mode UM.
23. The method according to claim 22, further comprising: encoding a packet for the multicast session associated with the first LCID using a hybrid automatic repeat request (HARQ) encoding operation based at least in part on the first LCID and a group radio network temporary identifier (G-RNTI) or using a HARQ encoding operation based at least in part on the first LCID and a cell radio network temporary identifier (C-RNTI); and Packets for the multicast session associated with the second LCID are encoded using a HARQ encoding operation based at least in part on the second LCID and the C-RNTI.
24. The method according to claim 23, wherein: Packets originally encoded using a HARQ encoding operation for the multicast session associated with the first LCID based at least in part on the first LCID and the G-RNTI are retransmitted as packets encoded using a HARQ encoding operation based at least in part on the first LCID and the C-RNTI.
25. A wireless device comprising: A processor configured with processor-executable instructions for: Determining whether a Packet Data Convergence Protocol (PDCP) status reporting condition for a multicast session in progress in a fifth generation 5G New Radio (NR) radio access network RAN has occurred; generating a PDCP status report indicating at least a first missing count FMC of a next non-received PDCP protocol data unit (PDU) for the multicast session in response to determining that the PDCP status reporting condition for the multicast session has occurred; Sending the PDCP status report to a base station of the 5G NR RAN; as well as Receiving a retransmitted PDCP PDU from the base station of the 5G NR RAN via a multicast transport channel, wherein the retransmitted PDCP PDU corresponds to the next unreceived PDCP PDU.
26. A base station of a fifth generation 5G new radio NR radio access network RAN, comprising: A processor configured with processor-executable instructions for: receiving, at a Packet Data Convergence Protocol (PDCP) layer, a packet for transmission in a multicast session; storing a copy of the packet for transmission in a retransmission buffer of the PDCP layer; adding a PDCP header to the packet for transmission to generate a PDCP protocol data unit (PDU); receiving a PDCP status report from at least one wireless device receiving the multicast session, the PDCP status report indicating at least a first missing count FMC for a next non-received PDCP PDU for the multicast session; determining that a stored copy of the packet for transmission in the retransmission buffer of the PDCP layer is associated with the FMC for the next unreceived PDCP PDU for the multicast session; adding a PDCP header to the determined stored copy of the packet for transmission in the retransmission buffer of the PDCP layer to generate a retransmitted PDCP protocol PDU; selecting a multicast radio link control, RLC, entity associated with a multicast transport channel of a multicast radio bearer, MRB, for the multicast session; and The retransmitted PDCP PDU is sent to the multicast RLC entity for retransmission.
27. A non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a wireless device to perform the operations of the method of any one of claims 1 to 11.
28. A non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a base station to perform the operations of the method according to any one of claims 12 to 24.
Citation Information
Patent Citations
Communication method and related product
CN109982266A
Method for transmitting lossless data packet based on quality of service (QOS) framework in wireless communication system and a device therefor
WO2018128452A1