Apparatus and method for flow control triggering and feedback

Abstract

The present disclosure relates to devices and methods for flow control triggering and feedback. Devices, methods, communication nodes, base stations, storage media, and other embodiments are provided for managing associations in a communication network. In one example embodiment, a New Radio (NR) node is configured for NR user plane protocol communication between a master node (MN) and a secondary node (SN). The NR node is configured to generate a downlink (DL) user data message with DL user data, initiate transmission of the DL user data message to a second node, and process a DL data delivery status message from the second node in response to the DL user data message. In various embodiments, such messaging supports polling and SCG split bearer configuration. In some embodiments, a packet data convergence protocol (PDCP) sequence number is conveyed for transmission and retransmission management. In some embodiments, DL configuration initiated by the SN is allowed, and UL configuration initiated by the MN or the SN is also allowed.

Description

[0001] Related application citation

[0002] This application is a divisional application of the invention patent application with international application number PCT / US2018 / 038501, international application date of June 20, 2018, entry into the Chinese national phase date of December 19, 2019, Chinese national application number 201880041269.0, and invention title "Apparatus and method for flow control triggering and feedback".

[0003] This application claims the benefit of priority to U.S. Provisional Patent Application Serial No. 62 / 522,557, filed June 20, 2017, entitled “ENHANCING NETWORK FLOW CONTROL TRIGGERING AND FEEDBACK”, and U.S. Provisional Patent Application Serial No. 62 / 522,515, filed June 20, 2017, entitled “ENHANCING NETWORK FLOW CONTROL TRIGGERING AND FEEDBACK”, the entirety of which are incorporated herein by reference. Technical Field

[0004] The embodiments relate to systems, methods, and component devices for wireless communication, specifically to device access and associated operations in Third Generation Partnership Project (3GPP) communication systems. Background Technology

[0005] Long-Term Evolution (LTE) and LTE Advanced are standards for wireless communication information (e.g., voice and other data) for user equipment (UEs) such as mobile phones. Such systems operate by having the UE communicate with the network via a cell of a radio access technology (RAT) system with a radio area network (RAN). This RAN may include base station systems such as evolved Node B (eNB) or next-generation Node B (gNB) to provide initial radio connectivity to the larger system. As part of managing the connection between such a system and the UE, the network system can manage ongoing control over the association with RAN equipment and the UE. Attached Figure Description

[0006] The accompanying drawings are not necessarily drawn to scale, and in these drawings, similar reference numerals may describe similar components in different views. Similar reference numerals with different letter suffixes may indicate different instances of similar components. The accompanying drawings illustrate the various embodiments discussed in this document in a generalized, illustrative, and not restrictive manner.

[0007] Figure 1 This is a diagram of a wireless network according to some embodiments.

[0008] Figure 2 Some aspects of communication between a master node and a secondary node according to some embodiments described herein are described.

[0009] Figure 3 A method performed by a device of a node according to some embodiments is described.

[0010] Figure 4 Some aspects of communication between a master node and a secondary node according to some embodiments described herein are described.

[0011] Figure 5 A method performed by a device of a node according to some embodiments is described.

[0012] Figure 6 The illustration shows an example UE that can be configured for specific operations or used in combination with the various embodiments described herein.

[0013] Figure 7 This is a block diagram illustrating an example computer system machine that can be used in association with the various embodiments described herein.

[0014] Figure 8 The illustrations depict some aspects of a UE, wireless device, or apparatus according to some example embodiments.

[0015] Figure 9 An example interface of a baseband circuit device according to some embodiments is illustrated.

[0016] Figure 10 This is a diagram of a control plane protocol stack according to some embodiments.

[0017] Figure 11 This is a diagram of a user plane protocol stack according to some embodiments.

[0018] Figure 12 This is a block diagram illustrating components capable of reading instructions from a machine-readable medium or a computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some example embodiments.

[0019] Figure 13The diagram illustrates the components of a core network according to some embodiments.

[0020] Figure 14 This is a block diagram illustrating components of a system that supports various embodiments described herein, according to some example embodiments. Detailed Implementation

[0021] The following description and accompanying drawings fully illustrate specific embodiments to enable those skilled in the art to implement such embodiments. Other embodiments may include structural variations, logical variations, electrical variations, process variations, and other changes. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. The embodiments recited in the claims cover all available equivalents of these claims.

[0022] Figure 1 The diagram illustrates the architecture of a network system 100 according to some embodiments. System 100 is shown as including user equipment (UE) 101 and UE 102. UE 101 and 102 are shown as smartphones (e.g., handheld touchscreen mobile computing devices that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a personal data assistant (PDA), pager, laptop computer, desktop computer, wireless phone, or any computing device including a wireless communication interface.

[0023] In some embodiments, either UE 101 or 102 may include an Internet of Things (IoT) UE, which may include a network access layer designed to utilize low-power IoT applications with short-lived UE connections. The IoT UE may exchange data with an MTC server or device via a public land mobile network (PLMN), proximity-based service (ProSe), device-to-device (D2D) communication, sensor networks, or the IoT network, utilizing technologies such as machine-to-machine (M2M) or machine-type communication (MTC). M2M or MTC data exchange may be machine-initiated. The IoT network description utilizes short-lived connections to interconnect IoT UEs, such IoT UEs may include uniquely identifiable embedded computing devices (within the Internet infrastructure). The IoT UE may perform background applications (e.g., keeping the network active, updating status, etc.) to facilitate connectivity within the IoT network.

[0024] UEs 101 and 102 can be configured to connect (e.g., be communicatively coupled) to radio access network (RAN) 110—RAN 110 can be, for example, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), a next-generation RAN (NG RAN), or some other type of RAN. UEs 101 and 102 utilize connections 103 and 104, each of which includes a physical communication interface or layer (discussed in more detail below); in this example, connections 103 and 104 are shown as air interfaces that allow communication coupling and are compliant with cellular communication protocols such as Global System for Mobile Communications (GSM), Code-Division Multiple Access (CDMA) network protocols, Push-to-Talk (PTT) protocols, PTT over Cellular (POC) protocols, Universal Mobile Telecommunications System (UMTS) protocols, 3GPP Long-Term Evolution (LTE) protocols, 5G protocols, New Radio (NR) protocols, and so on.

[0025] In this embodiment, UEs 101 and 102 can also directly exchange communication data via the ProSe interface 105. The ProSe interface 105 can alternatively be referred to as a sidelink interface including one or more logical channels, including but not limited to the Physical Sidelink Control Channel (PSCCH), Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Discovery Channel (PSDCH), and Physical Sidelink Broadcast Channel (PSBCH).

[0026] UE 102 is shown configured to access access point (AP) 106 via connection 107. Connection 107 may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, where AP 106 will include... Router. In this example, AP 106 can connect to the Internet, for example, but not to the core network of the wireless system (described in more detail below).

[0027] RAN 110 may include one or more access nodes that allow connectivity between 103 and 104. These access nodes (ANs) may be referred to as base stations (BS), NodeBs, evolved NodeBs (eNBs), next-generation NodeBs (gNBs), RAN nodes, etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). RAN 110 may include one or more RAN nodes for providing macrocell coverage, such as macro RAN node 111, and one or more RAN nodes for providing femtocells or picocells (e.g., cells with smaller coverage area, smaller user capacity, or higher bandwidth compared to macrocells), such as low-power (LP) RAN node 112.

[0028] Either RAN node 111 or 112 can be the termination point of the air interface protocol and can be the first contact point for UEs 101 and 102. In some embodiments, either RAN node 111 or 112 can implement various logical functions for RAN 110, including but not limited to radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0029] According to some embodiments, UEs 101 and 102 can be configured to communicate with each other or with either RAN nodes 111 and 112 via a multi-carrier communication channel using Orthogonal Frequency-Division Multiplexing (OFDM) communication signals, based on various communication technologies. Such communication technologies include, but are not limited to, Orthogonal Frequency-Division Multiple Access (OFDMA) communication technologies (e.g., for downlink communication) or Single-Carrier Frequency-Division Multiple Access (SC-FDMA) communication technologies (e.g., for uplink and ProSe or sidelink communication), although the scope of the embodiments is not limited in this respect. OFDM signals may include multiple orthogonal subcarriers.

[0030] In some embodiments, a downlink resource grid can be used for downlink transmissions from either RAN nodes 111 and 112 to UEs 101 and 102, while uplink transmissions can utilize similar techniques. Such a grid can be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which represents the physical resources in the downlink within each time slot. This time-frequency plane representation is standard practice in OFDM systems, making it intuitive for radio resource allocation. Each column and row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The minimum time-frequency unit in the resource grid is represented by a resource element. Each resource grid comprises several resource blocks, which describe the mapping from a specific physical channel to resource elements. Each resource block comprises a set of resource elements; in the frequency domain, this can represent the minimum number of currently allocable resources. Several different physical downlink channels exist that are transported using such resource blocks.

[0031] The physical downlink shared channel (PDSCH) carries user data and higher-layer signaling to UEs 101 and 102. The physical downlink control channel (PDCCH) carries information about the transmission format and resource allocation related to the PDSCH, etc. It can also inform UEs 101 and 102 about the transmission format, resource allocation, and Hybrid Automatic Repeat Request (H-ARQ) information related to the uplink shared channel. Typically, downlink scheduling (e.g., assigning control and shared channel resource blocks to UE 102 within the cell) can be performed at either RAN node 111 or 112 based on channel quality information fed back from either UE 101 or 102. Downlink resource assignment information can be transmitted on the PDCCH used for (e.g., assigned to) each of UEs 101 and 102.

[0032] PDCCH can use control channel elements (CCEs) to transport control information. Before being mapped to resource elements, the complex-valued symbols of the PDCCH can first be organized into quadruplets, which can then be permuted using a sub-block interleaver for rate matching. Each PDCCH can be transmitted using one or more of these CCEs, where each CCE can correspond to nine sets of four physical resource elements, called a resource element group (REG). Four Quadrature Phase Shift Keying (QPSK) symbols can be mapped for each REG. Depending on the size of the downlink control information (DCI) and channel conditions, one or more CCEs can be used to transmit the PDCCH. In LTE, four or more different PDCCH formats can be defined with different numbers of CCEs (e.g., aggregation levels L = 1, 2, 4, or 8).

[0033] Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the concepts described above. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH), which uses PDSCH resources for control information transmission. EPDCCH may be transmitted using one or more enhanced control channel elements (ECCEs). Similar to the CCEs described above, each ECCE may correspond to nine sets of four physical resource elements, called an enhanced resource element group (EREG). In some cases, an ECCE may have an additional number of EREGs.

[0034] RAN 110 is shown communicatively coupled to core network (CN) 120 via S1 interface 113. In some embodiments, CN 120 may be an evolved packet core (EPC) network, a next-generation packet core (NPC) network, or some other type of CN. In this embodiment, S1 interface 113 is divided into two parts: S1-U interface 114, which carries traffic data between RAN nodes 111 and 112 and serving gateway (S-GW) 122; and S1 mobility management entity (MME) interface 115, which is the signaling interface between RAN nodes 111 and 112 and MME 121.

[0035] In this embodiment, CN 120 includes MME 121, S-GW 122, Packet Data Network (PDN) Gateway (P-GW) 123, and Home Subscriber Server (HSS) 124. MME 121 may functionally resemble the control plane of a legacy Serving GPRS Support Node (SGSN). MME 121 can manage mobility aspects of access, such as gateway selection and tracking area list management. HSS 124 may include a database for network users, including subscription-related information, to support network entities in processing communication sessions. CN 120 may include one or more HSS 124s, depending on the number of mobile subscribers, device capacity, network organization, etc. For example, HSS 124 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc.

[0036] S-GW 122 can be the termination point for S1 interface 113 toward RAN 110 and can route data packets between RAN 110 and CN 120. Furthermore, S-GW 122 can be a local mobility anchor point for handover between RAN nodes and can also provide anchoring for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

[0037] P-GW 123 may be the termination of the SGi interface toward the PDN. P-GW 123 may route data packets between the EPC network and external networks via Internet Protocol (IP) communication interface 125, such external networks being networks including application server 130 (or application function (AF)). Generally, application server 130 may be a unit that provides IP-bearing resources for applications (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.) with the core network. In this embodiment, P-GW 123 is shown communicatively coupled to application server 130 via IP communication interface 125. Application server 130 may also be configured to support one or more communication services (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UEs 101 and 102 via CN 120.

[0038] P-GW 123 can also be a node for policy enforcement and charging data collection. The Policy and Charging Rules Function (PCRF) 126 is the policy and charging control unit of CN 120. In non-roaming scenarios, a single PCRF can exist in the Home Public Land Mobile Network (HPLMN) associated with the UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In roaming scenarios with local breakout of traffic, two PCRFs can be associated with the UE's IP-CAN session: the Home PCRF (H-PCRF) within the HPLMMN and the Visited PCRF (V-PCRF) within the Visited Public Land Mobile Network (VPLMN). PCRF 126 can be communicatively coupled to the application server 130 via P-GW 123. Application server 130 can signal PCRF 126 to indicate new service flows and select appropriate Quality of Service (QoS) and charging parameters. PCRF 126 can supply this rule to the Policy and Charging Enforcement Function (PCEF) (not shown) using an appropriate traffic flow template (TFT) and QoS class identifier (QCI), which will initiate the QoS and charging specified by application server 130.

[0039] In legacy LTE, network-based flow control via X2 was defined for dual connectivity (DC). A similar mechanism was defined for flow control of LTE wireless local area network (LTE-WLAN) aggregation (LWA) via Xw.

[0040] In the context of New Radio (NR), network flow control is being discussed for the following three separate features: Evolved Universal Mobile Telecommunications system Terrestrial Radio Access New Radio (E-UTRA-NR) dual connectivity (EN-DC) (e.g., via the X2 interface), E-UTRA-NR DC (NE-DC) supporting 5G core network (5GC) (e.g., NGEN-DC) and Next-Generation Radio Area Network (NG-RAN) (e.g., via the Xn interface), and Central Unit (CU) and Distributed Unit (DU) segmentation (e.g., via the F1 interface).

[0041] In various systems, LTE DC flow control can be used as a baseline; however, the embodiments disclosed herein include enhancements to network-based flow control to achieve enhanced performance, better interoperability and uplink support, and support for NR-specific features such as secondary cell group (SCG) segmented bearer operation and packet data convergence protocol (PDCP) duplication.

[0042] In the embodiments of this disclosure, we consider enhancements to the above use cases. Given the understanding that the enhancements apply to the Xn, X2, and F1 interfaces, the discussion of flow control can be broadly applied (e.g., using X2 as an example).

[0043] Assuming LTE DC flow control in the existing system as a baseline, the following enhancements can be implemented in this embodiment (e.g., for X2, Xn, and F1 interfaces): 1) uplink support; 2) support for SCG segmentation bearer operations from the secondary node to the primary node (e.g., support for EN-DC, NGEN-DC, and NE-DC); 3) notification of the highest successfully delivered PDCP protocol data unit (PDU) sequence number for PDCP repetition in the downlink; 4) notification of the highest successfully received PDCP PDU sequence number for PDCP repetition in the uplink; and 5) different feedback triggering mechanisms (e.g., polling, configured period, threshold, etc.).

[0044] Figure 2The illustrations depict aspects of various embodiments as described herein. Figure 2 This includes a master node (MN) 210 and a secondary node (SN) 220, which can communicate with each other according to the various embodiments described herein. In addition to the embodiments listed above, other alternatives can operate without enhancements using X2-based flow control, which controls only the downlink flow from the master node to the secondary node. Such communication is handled by… Figure 2 The diagram illustrates DL user data communication 222 from MN 210 to SN 220 and DL data delivery status communication 224 from SN 220 to MN 210. Such communication is part of a legacy mechanism. However, the legacy mechanism has certain drawbacks, such as the lack of defined support for uplink and NR SCG segmented bearer operations, and the problem of redundant enhancements to the NR Packet Data Convergence Protocol (PDCP).

[0045] Therefore, enhanced Phase 3 details of certain embodiments are described below. In some systems, there may be four frame formats for the X2 user plane protocol, which can be applied to the Xn and F1 interfaces as baselines. These include “DL User Data” (PDU type 0) and “DL User Data Extension” (PDU type 3), which can be defined to allow the secondary eNB (SeNB) to detect lost X2-U packets (e.g., packets lost on the X2 interface) and can be associated with the transmission of downlink PDCP protocol data units (PDUs) through the X2-U interface. In various embodiments, the difference lies in the length of the PDCP sequence number (PDCP SN) to be supported. These also include “DL Data Delivery Status” (PDU type 1) and “DL Data Delivery Status Extension” (PDU type 2), which can be defined to transmit feedback to allow the receiving primary node (e.g., primary eNB or MeNB) to control the downlink user data flow via the secondary node (e.g., secondary eNB or SeNB). As above, in some embodiments, the difference may be the length of the PDCPSN to be supported.

[0046] To support the enhancements described in the above principles, Table 1 illustrates embodiments that can be represented as modifications to the legacy frame format.

[0047]

[0048] Table 1

[0049] Table 1 illustrates modifications to the "DL User Data" or "DL User Data Extension" format for use in embodiments described herein. In some embodiments, the modification description may be based on "DL User Data" (PDU type 0), but the same modifications may also be applied to other frame formats (e.g., PDU type 3). In other embodiments, instead of modifying an existing frame format, a new format with a different PDU type number may be defined to support the enhancement.

[0050] In addition to the embodiments described above, other embodiments may involve additional enhancements to the frame format. For uplink support enhancements, improvements can be made as follows. In the legacy implementation, the uplink is transmitted from the secondary node to the primary node along with a “DL data delivery status” frame within the same GPRS Tunneling Protocol for the user plane (GTP-U) PDU for the E-UTRAN Radio Access Bearer (E-RAB) of interest. For support of flow control for uplink PDCP PDU transmissions, embodiments may define “UL user data” and “UL data delivery status” for the uplink direction using different PDU type numbers, thereby enabling uplink flow control for the uplink just as it is for the downlink. Such enhancements allow UL user data communication 232 and UL data delivery status communication 234. For the downlink in the DC, MN 210 is typically a node that sends packets and receives feedback from SN 220. As shown in communications 232 and 234, the embodiments described herein allow uplink flow control, where the roles of MN 210 and SN 220 can be reversed.

[0051] The embodiments described herein also allow support for subcell group (SCG) segmentation bearer operations from SN 220 to MN 210 (e.g., for EN-DC, NGEN-DC, and NE-DC). Since SCG segmentation bearer operations can be introduced in NR, in the embodiments described herein, downlink PDCP PDUs can be transmitted from SN 220 to MN 210 via “DL user data”. Additionally, in the embodiments, a “DL data delivery status” can be transmitted by MN 210 for flow control by SN 220 on those PDCP PDUs transmitted from SN 220 to MN 210. Such embodiments are provided by… Figure 2The DL user data communication 242 and DL data delivery state 244 are described. In other embodiments, flow control for the uplink direction of SCG segmented bearer operations can also be considered similar to the uplink support described above. This is illustrated by UL user data communication 252 and UL data delivery state 254, which exemplify uplink flow control for SCG segmented bearer operations.

[0052] In any such system, some embodiments may include notifying the highest successfully delivered PDCP PDU sequence number in response to PDCP duplication in the downlink. If some PDCP PDUs are transmitted to a secondary node (e.g., intended for delivery to the UE by the secondary node), in some such embodiments, the primary node does not send these PDCP PDUs and waits for them to be delivered to the user equipment (UE) by the secondary node. This can also be applied to SCG segmentation bearer operations in the downlink direction by reversing the roles of the primary and secondary nodes described above. In some such embodiments, this will only occur if there is a report of loss on the interface, in order to avoid duplicate transmissions from the primary and secondary nodes to the UE.

[0053] Some implementations can operate with support for packet repetition within NR-PDCP. This includes the ability of the primary node to directly retransmit PDCP PDUs that were previously transmitted to the secondary node to the UE, and this provides latency benefits (e.g., helping to meet NR latency targets such as ultra-reliability low latency communications (URLLC), etc.).

[0054] To address the PDCP duplication issue, embodiments may include a mechanism whereby the primary node provides the highest successfully delivered PDCP SN to the secondary node in "DL User Data" format, enabling the secondary node to avoid transmitting PDCP PDUs that have already been delivered (by the primary node) to the UE. This indication can be achieved by setting the "HS1" field in Table 1 above to 1, allowing the secondary node to know the highest successfully delivered SN that was previously delivered to the UE by the primary node and accordingly remove buffered downlink PDCP PDUs to avoid duplication. In some embodiments, this can also be applied to SCG segmentation bearer operations in the downlink direction by reversing the roles of the primary and secondary nodes described above. Furthermore, in some embodiments, this can also be applied to the F1 interface in the downlink direction (e.g., between the Central Unit (CU) and the Distribution Unit (CU), whereby the CU provides the highest successfully delivered PDCP PDU SN to the DU (if they have already been delivered to the UE by another DU) to avoid duplication via that DU.

[0055] Furthermore, embodiments may include notifying the highest successfully received PDCP PDU sequence number in response to PDCP duplication in the uplink. When uplink bearer segmentation is configured, if PDCP duplication is allowed for the uplink, it is possible for the UE to retransmit PDCP PDUs that were previously sent to the secondary node to the primary node to meet strict NR latency targets (e.g., URLLC, etc.).

[0056] Therefore, some embodiments may include a mechanism by which the master node provides the secondary node with the highest successfully received PDCP SN, thereby enabling the secondary node to avoid transmitting PDCP PDUs that have already been successfully delivered to the master node's receiving PDCP entity via the interface. Once the secondary node receives such a PDCP SN from the master node, it discards the delivered PDCP PDUs that were successfully received from the UE by the secondary node. In some such embodiments, there are various options regarding how to notify the secondary node of such a highest successfully received PDCP SN. In one option, the “DL User Data” frame of the E-RAB of interest can be used. This indication can be made by setting the “HS2” field to 1 (e.g., in Table 1 above), so that the secondary node knows the highest successfully received SN that was successfully delivered to the master node in the uplink direction by the UE, and the secondary node removes the buffered received PDCP PDUs to be carried to the master node via the interface. In a second option, a “UL Data Delivery Status” frame can be used. For this "UL data delivery status" from the primary node to the secondary node, a field structure similar to the first option can be considered. In some embodiments, this can also be applied to the SCG segmentation bearer operation in the uplink direction by reversing the roles of the primary and secondary nodes described above. Similar to other embodiments, this can also be applied to the F1 interface in the uplink direction (between the CU and DU), so that the CU provides the DU with the highest successful reception PDCP PDU SN (if it has already been received from the UE by another DU) to avoid duplicate transmissions from that DU.

[0057] Figure 3 The illustration depicts an example method 300 performed by a node device (e.g., a next-generation node B (gNB), an evolved Node B (eNB), or any such device of a communication node) according to some embodiments described herein (e.g., MN 210 or 410 or SN 220 or 420). In some embodiments, Figure 3Method 300 can be implemented by one or more processors of a device or apparatus for implementing a node including processing circuitry. In other embodiments, method 300 can be implemented as computer-readable instructions in a storage medium that, when executed by one or more processors of the device, cause the device to perform method 300. In some embodiments, the associated device can be part of an NG-Radio Access Network (NG-RAN) node, and the associated device or apparatus within the NG-RAN includes components such as processing circuitry, memory, interfaces, transmission circuitry, or other such circuitry units.

[0058] Method 300 includes operation 305, accessing DL user data. The user data from operation 305 is then used in operation 310 to generate a DL user data message containing the DL user data, and in operation 315, the processing circuitry initiates the transmission of the DL user data message to the second node. The second node receives and processes the DL user data message and performs corresponding operations to generate a DL data delivery status message. After the DL data delivery status message is received, the processing circuitry processes the DL data delivery status message from the second node, which was generated and sent by the second node in response to the DL user data message, in operation 320.

[0059] In various embodiments, the NR node includes the SN, and the second node includes the MN. This enables the SN to manage messaging and data delivery in a manner known from previous 3GPP systems for the operation of the MN and SN. In some such embodiments, the DL user data includes the sequence number of the highest successfully delivered PDCP Protocol Data Unit (PDU). In other embodiments, the DL user data message includes a DL discard field based on the sequence number of the highest successfully delivered PDCP PDU, the DL discard field indicating a sequence number up to and including that sequence number, which all NR PDCP PDUs should be discarded by the second node.

[0060] Some embodiments operate where the DL user data message includes a first PDU type and the DL data delivery status message includes a second PDU type. In some such embodiments, the DL data delivery status message includes a parameter indicating the highest transmitted NR PDCP sequence number. In other such embodiments, the DL data delivery status message includes a parameter indicating the transmitted status associated with the highest transmitted NR PDCP sequence number. Other embodiments may operate where the DL data delivery status message includes a parameter indicating the highest retransmission NR PDCP sequence number, or where the DL data delivery status message includes a parameter indicating the status associated with the highest retransmission NR PDCP sequence number.

[0061] In addition, alternative embodiments may include similar operations for UL data, wherein the NR node acts as MN or SN, and the second node operates as MN when the NR node is SN, and the second node operates as SN when the NR node is MN.

[0062] In addition to the embodiments described above, for dual-connectivity operation and the various communication systems described herein, additional embodiments may operate using new per-bearer metric feedback instead of per-bearer buffer size and per-UE buffer size (e.g., (average) throughput, (average) queuing delay, etc.). Additional embodiments may also operate in conjunction with optimizations to the number of reported lost sequence number ranges. Other embodiments may operate in conjunction with UE-based flow control; however, such systems (e.g., PDCP polling) are problematic for standardized operation and may have efficiency issues due to the involvement of the air interface. Another option is to retain the legacy X2-based flow control without enhancements; however, the currently defined mechanism has certain drawbacks, including undefined reporting triggers (e.g., left to the secondary eNB implementation), which may limit the efficiency of the scheduler in the primary eNB. Furthermore, some metrics are defined at the per-UE granularity rather than the per-bearer granularity, which may negatively impact quality of service (QoS). Additionally, in general, existing current metrics are rather coarse (e.g., limited to buffer states). The master node can theoretically infer other metrics (e.g., throughput) based on changes in buffer state, but such estimations are slow and inaccurate.

[0063] The embodiments described here can thus provide enhancements using Phase 3 user plane details. As described above, some systems operate with four frame formats for the X2 user plane protocol, applicable to the Xn and F1 interfaces as baselines. These include “DL User Data” (PDU type 0) and “DL User Data Extension” (PDU type 3), defined to allow the SeNB to detect lost X2-U packets (e.g., packets lost on the X2 interface) and associated with the transmission of downlink PDCP PDUs over the X2-U interface. These also include “DL Data Delivery State” (PDU type 1) and “DL Data Delivery State Extension” (PDU type 2), defined to transmit feedback to allow the receiving MeNB to control the downlink user data flow via the SeNB. To support the enhancements described above, embodiments can modify legacy frame formats. Tables 2 and 3 below illustrate examples according to some embodiments. Table 2 illustrates example modifications to the “DL User Data” format, and Table 3 illustrates example modifications to the “DL Data Delivery State” format.

[0064]

[0065] Table 2

[0066]

[0067]

[0068] Table 3

[0069] In such an embodiment, the modification is based on "DL User Data" (PDU type 0) and "DL Data Delivery Status" (PDU type 1), but the same modification can also be applied to other frame formats (e.g., PDU types 2 and 3). In some embodiments, instead of modifying the existing frame format, a new format with different PDU type numbers can be defined to support the enhancement.

[0070] In some embodiments, configuration information for flow control enhancement can be delivered via a control plane procedure from the master node to the secondary node. Such configuration information can be delivered as a field as part of legacy procedures and messages (e.g., in the case of X2-AP messages, such as SENB ADDITION REQUEST, SENB MODIFICATION REQUEST, SENB RELEASE REQUEST, etc.). Alternatively, embodiments may include New Category 1 or New Category 2 procedures with new message structures dedicated to flow control configuration setting, updating, and releasing in the secondary node, as described below. Figure 5 and as exemplified in Table 4.

[0071] Figure 4 A primary node (MN) 410 and a secondary node (SN) 420 are illustrated. These two nodes include new communications for the X2-AP process of flow control configuration in SN 420. In the illustrated embodiment, this includes flow control configuration update communication 422 and flow control configuration update acknowledgment communication 424. Table 4 illustrates aspects of the associated flow control configuration update messages, including details of the information element (IE) and associated details of the data within the message.

[0072]

[0073]

[0074] Table 4

[0075] In the old mechanism, the secondary node (e.g., the SeNB) determined when to trigger the "DL data delivery status" feedback. This can lead to inefficient flow control because the primary node (e.g., a MeNB that manages PDCP for primary cell group (MCG) and secondary cell group (SCG) segmentation bearer operations) cannot control when the feedback is triggered. To allow the primary node to estimate the round-trip time (RTT) on the interface, a feedback control mechanism should be in place, which will help manage flow control on the interface. Additionally, control over triggering will allow for optimized scheduling in the primary eNB. To give such control to the primary node, embodiments may include one or more of the following mechanisms.

[0076] The first mechanism includes polling. Some embodiments of polling may use a one-bit indicator to trigger feedback from the secondary node. This polling bit may be embedded in the “DL user data” format (e.g., represented by the “PL” field above). Once the secondary node receives “DL user data” with the PL field set to 1, it immediately compiles feedback (e.g., a “DL data delivery status” message) and sends it via the interface. When the secondary node compiles the “DL user data status”, the associated field (e.g., the PLR ​​field) is set (e.g., set to a value of 1) to notify the master node that this feedback was generated due to a polling request. Furthermore, in some embodiments, the X2-U sequence number that triggers the feedback via the polling field is set to the X2-U sequence number in the received “DL user data”. This triggers polling so that the master node knows which “DL user data” this feedback corresponds to. This allows the master node to calculate the round-trip time (RTT) of the interface, assuming the secondary node compiles and sends this report as soon as it receives the polling. Alternatively, in some embodiments, the time at which this report is compiled / transmitted can be set to the time at which this "DL delivery data state" is compiled / transmitted, so that the master node knows the report timing and the time it receives this report from the master node estimates the one-way latency of the interface (e.g., from the secondary node to the master node) (e.g., and thus estimates RTT by doubling this one-way latency). The length of this time value can be up to several octets, depending on how it is specified (e.g., currently represented by "Z1"). In various embodiments, this is a fixed value (immutable value) within the format.

[0077] Another mechanism is the configured period. Such embodiments operate to cause secondary nodes to periodically report feedback (e.g., "DL data delivery status" messages), which helps the primary node estimate changes in RTT on the estimation interface. In some such embodiments, a one-bit indication in the "TV" field of the "DL user data" format, which is overwritten by the secondary node (or set if not previously configured), when set to 1, along with setting the current periodic reporting timer value to the value in the "Periodic Reporting Timer Value (in ms)" field, causes the SN to begin providing feedback according to the configured period. This timer value can be up to several octets in length, depending on how it is specified (currently represented by "Y1"), and it is a fixed value (immutable value) within the format. In other embodiments, configuration information for periodic reporting can be delivered via an existing X2-AP procedure or a new X2-AP procedure.

[0078] Another mechanism for managing flow control, according to some embodiments, is a threshold mechanism. In such embodiments, threshold-based reporting can be configured at the sub-node to report feedback (e.g., a "DL data delivery status" message) whenever a configured threshold is met. An example could be the use of a "number of PDCP PDUs successfully delivered to the UE" field, such that a report is triggered whenever that number (e.g., the threshold) of PDCP PDUs is successfully delivered to the UE. Similar to the configuration periodic mechanism, a one-bit "TH" field in the "DL user data" format, when set to 1, is rewritten by the sub-node (or set if not previously configured), combined with the current threshold-based reporting value, and is set in the "number of PDCP PDUs successfully delivered to the UE" field, and is activated whenever such a number of PDCP PDUs are successfully delivered to the UE to begin providing feedback. The threshold length can be up to several octets, depending on how it is specified (currently represented by "Y2"). In some embodiments, this is a fixed value (immutable value) within the format. In other embodiments, configuration information for threshold-based reporting can be delivered via an existing X2-AP process or a new X2-AP process. In some embodiments, it is not desirable to configure periodic reporting and threshold-based reporting simultaneously to avoid confusing the master node.

[0079] Other embodiments may combine new metric feedback instead of per-bearer buffer size and per-UE buffer size (e.g., average throughput, average queuing delay, etc.). In the legacy mechanism, per-UE buffer size and per-bearer buffer size were used for flow control, but buffer size alone is coarse for fine-grained flow control. To better aid buffer management and for optimized scheduling in the master node, the following metrics may be considered in addition to existing buffer size announcements from secondary nodes: (average) throughput per bearer; (average) queuing delay per bearer (per PDCP PDU or on average) until the first transmission, i.e., the delay from the first reception of the secondary node until its first transmission; (average) delay per bearer (per PDCP PDU or on average) from the time of the first transmission by radio link control (RLC) until successful confirmation of delivery, i.e., the delay of RLC retransmission; and buffer status reports from UEs. In other embodiments, other metrics or other metrics may be used in combination with the above metrics. In some embodiments, the master node may request the above metrics by setting the "NM" field in "DL User Data" to 1. Once the secondary node receives "DL User Data" with the "NM" field set to 1, it compiles a "DL Data Delivery Status" with the "NM" field set to 1, and provides new available metrics if the relevant fields in the "DL Data Delivery Status" are set to 1. The secondary node provides feedback on new additional metrics until it receives "DL User Data" with the "NM" field set to 0.

[0080] In some embodiments, different options exist for how per-bearer (average) throughput can be provided to the master node. One embodiment operates by reusing the existing "highest successfully delivered PDCP sequence number" in the "DL data delivery status". This feedback serves to allow the master node to calculate the average throughput of this E-RAB. Some such embodiments may operate as follows: If the master node knows the RTT of the interface, and if the master node knows the time when the reported PDCP SN was sent to the secondary node, the master node can calculate how long it took for the PDCP SN to be received by the secondary node until it was successfully acknowledged by the UE as delivered. Based on this calculated time and the PDCP PDU size, the master node can estimate the throughput of this E-RAB. Additionally, in some embodiments, if the master node uses consecutive "highest successfully delivered PDCP sequence numbers" reported from the secondary node, the master node can calculate a more accurate throughput. However, this estimate may not be precise because there may be a gap between the time when the PDCP SN is successfully acknowledged as delivered and the time when the PDCP SN is reported in the "DL data delivery status". Therefore, embodiments may include new metrics, such as "time offset (in milliseconds) on the highest successfully delivered PDCP sequence number," to inform the master node how many time offsets have elapsed since this PDCP SN was reported in the "DL data delivery status" before it was successfully acknowledged as delivered. The presence of this additional metric can be indicated, for example, when the OF1 field is set to 1. The length of this time offset value can be up to several octets, depending on how it is specified (e.g., "Z3"). Such values ​​can be set to fixed values ​​within the format.

[0081] Another option for reporting throughput per bearer involves the secondary node directly reporting the calculated average throughput. In some such embodiments, the secondary node can calculate and directly report the value of the average throughput per E-RAB. The average throughput can be calculated using the time between consecutive feedback reports.

[0082] The presence of this additional metric can be indicated when the "AV" field is set to 1. The length of this time offset value can be up to several octets, depending on how it is specified.

[0083] In some embodiments, queuing delay (e.g., per PDCP PDU or average) until the PDCP PDU is first transmitted can also be reported. This additional metric of queuing delay reflects how long the PDCP PDU is stored in the secondary node's buffer before it is first transmitted via the air interface. This additional metric can be provided to the primary node to better manage the secondary node's buffer and control flow on the interface. To support the high data rates of NR, a Layer 2 protocol stack can be used to reduce radio link control (RLC) and media access control (MAC) processing time to near-zero ms when transmission opportunities are available. Therefore, in such embodiments, it is safe to ignore RLC / MAC processing time, and queuing delay can be defined as the time from when the secondary node receives the PDCP PDU until this PDCP PDU is processed by RLC / MAC and transmitted via the air interface. Various options exist for how per-bearer (average) queuing delay can be provided to the primary node.

[0084] One option involves using the highest PDCP sequence number processed by the RLC. Similar to the first option described above for per-bearer (average) throughput, the secondary node can report the highest PDCP sequence number processed by the RLC for queuing delays. This PDCP SN can be reported by setting the "HS2" field in the "DL Data Delivery Status" to 1. The length of this field can be the same as the configured PDCP SN size. Additionally, similar to the first option described above for per-bearer (average) throughput, an additional metric, "Time Offset (in ms) on the Highest PDCP Sequence Number Processed by the RLC," can be used to indicate to the primary node how many time offsets have elapsed since this PDCP SN was reported in the "DL Data Delivery Status" before it was processed by the RLC. In some embodiments, the presence of this additional metric can be indicated when the "OF2" field is set to 1. The length of this time offset value can be up to several octets, depending on how it is specified (e.g., represented by "Z4").

[0085] Another option regarding queuing delay involves the calculated queuing time or average queuing delay being directly reported by the secondary node. In some embodiments, the secondary node can calculate the time delay from the time the PDCP PDU associated with the reported "Highest Successful Delivery PDCP SN" is received until it is successfully acknowledged and delivered to the UE. Alternatively, the secondary node can calculate and directly report the value of the average queuing delay per E-RAB. The average queuing delay can be better calculated using the time between consecutive reports. In some embodiments, the presence of this additional metric, "(average) queuing delay (between reports) until first transmission," can be indicated when the "AV2" field is set to 1. The length of this delay value can be up to several octets, depending on how it is specified (currently represented by "Z5").

[0086] Another possible metric is the RLC retransmission delay (per PDCP PDU or on average) until the PDCP PDU is successfully acknowledged for delivery. In some embodiments, an additional metric of the RLC transmission / retransmission time from the time the PDCP PDU is first transmitted until it is successfully acknowledged for delivery can be provided to the master node to better manage the secondary node's buffers and control the flow on the interface. This metric (per PDCP PDU or on average) can be calculated when the master node knows the two metrics mentioned above (throughput and queuing delay until the first transmission). However, the secondary node can calculate the RLC transmission / retransmission delay of the PDCP PDU associated with the reported "highest successfully delivered PDCP SN" until it is successfully acknowledged for delivery by the UE. In other embodiments, the secondary node can calculate its own value and directly report the average RLC transmission / retransmission delay until the PDCP PDU is successfully acknowledged for delivery. This metric can be calculated using the time between consecutive reports. The presence of this additional metric, “average RLC delay per PDCPPDU (between reports) from the time of first transmission until successful acknowledgment of delivery,” can be indicated when the “AV3” field is set to 1. This delay value can be up to several octets in length, depending on how it is specified (e.g., “Z6”).

[0087] Furthermore, some embodiments may operate in conjunction with Buffer Status Reports (BSRs) from the UE. A BSR MAC Control Unit (BSR MAC CE) reported by the UE to the secondary node can be provided to the primary node for optimized scheduling, buffer management, and flow control. In some embodiments, the presence of this metric, “Buffer Status Report from UE,” can be indicated when the “BSR” field is set to 1 (e.g., see the tables(s) above). In some embodiments, the length of the BSR MAC CE can be up to 3 octets according to the MAC protocol specification, but in NR, this length may depend on how it is specified (e.g., “Z7”).

[0088] Finally, some embodiments can operate by incorporating optimizations in the number of reported ranges of lost sequence numbers. Legacy systems operate by reporting lost X2-U packets in the form of a "DL data delivery status" range (e.g., the start and end of each range) of consecutive lost X2-U packets. Reporting the start and end of each range takes twice the number of octets of an X2-U sequence number. This range reporting can be efficient when a large number of consecutive X2-U packets are lost. However, this can be inefficient when a small number of consecutive X2-U packets are lost. Even if the missing X2-U packets have only small gaps, each loss report takes twice the number of octets of an X2-U sequence number to represent the start and end of each range. For example, suppose there is only one missing X2-U packet with sequence number 1. The report would then be "start = 1" and "end = 1", each taking up the size of an X2-U sequence number. In the embodiments described herein, such reporting can be optimized by reporting the number of consecutive X2-U packets lost starting from the start sequence number. If the system limits this number to 1 octet, this effectively reduces the octet size of the end sequence number to 1 octet (e.g., instead of 2 or 3 octets for the X2-U sequence number size) and can effectively report 256 consecutive lost X2-U packets from the start sequence number. Depending on the number of consecutive lost X2-U packets, in the embodiment, the secondary node can compile a report as follows. If the number of consecutive missing packets is less than 256, the secondary node can compile a Type 2 report (e.g., see Table 3). If the number is greater than 256, the secondary node can compile a report as in the legacy manner by indicating the range from the start to the end sequence number (e.g., represented by Type 1 in Table 3). For each gap (less than 257) of consecutive lost X2-U packets reported by the secondary node, the system can save 1 octet for each report compared to using the legacy mechanism.

[0089] In the embodiments described above, the primary node (MN) is generally referred to as the node that sends packets and receives feedback from the secondary node (SN), which holds true for the downlink in the DC. It should be understood that the described enhancements can also be applied to uplink (UL) operation, in which case the roles of MN and SN are reversed, and the described enhancements also apply to F1 operation. In F1 operation, the CU sends downlink packets and receives feedback from the DU, and the DU sends uplink packets and receives feedback from the CU.

[0090] Figure 5 The illustration depicts an example method 500 performed by a node device (e.g., a next-generation node B (gNB), an evolved Node B (eNB), or any such device of a communication node) according to some embodiments described herein (e.g., MN 210 or 410 or SN 220 or 420). In some embodiments, Figure 5 Method 500 can be implemented by one or more processors of a device or apparatus for implementing any machine including a node with processing circuitry. In other embodiments, method 500 can be implemented as computer-readable instructions in a storage medium that, when executed by one or more processors of the device, cause the device to perform method 500. In some embodiments, the associated device can be part of an NG-Radio Access Network (NG-RAN) node, and the associated device or apparatus within the NG-RAN includes components such as processing circuitry, memory, interfaces, transmission circuitry, or other such circuitry units. In some embodiments, operation of method 500 precedes operation of method 300. In other embodiments, method 500 operates independently without operation of method 300. In still other embodiments, various combinations of any operations described herein can be used with operation of method 500 and / or operation of method 300. Some embodiments are implemented by an NR node and a second node including a corresponding node, wherein the NR node includes a node hosting NR Packet Data Convergence Protocol (PDCP) operation.

[0091] Method 500 includes operation 305, accessing flow control data. In operation 310, the accessed flow control data is used to generate a flow control configuration update, and in operation 315, a transmission of the flow control configuration update to the second node is initiated. The flow control configuration is then received and processed, and an update acknowledgment message is sent to the NR node. In operation 320, a DL data delivery status message is processed. In some embodiments, the flow control data includes report polling parameters. In other embodiments, the report polling parameters instruct the NR node hosting the NR PDCP operation to request a downlink delivery status report.

[0092] These methods describe specific embodiments, but it will be apparent that additional methods with repetitive or intermediary operations are possible according to the embodiments described herein. For example, various embodiments of operations at the RAN, gNB, network devices, and UEs have been described above, and it will be apparent that corresponding operations at elements of the communication network (e.g., operations at the gNB, UE, or core network devices associated with operations described for another corresponding device) will occur in conjunction with the described operations, in addition to those specifically described. Furthermore, any of the embodiments described above can be performed in various different embodiments with repetitive or intermediary operations. In addition to the specific communications, information elements, and fields of the methods described above, any of these operations may also involve the generation or processing of the communications, information elements, and / or fields described above. A further set of additional non-exhaustive embodiments is given below.

[0093] Example Implementation

[0094] Example 1 may include a master node (MN) comprising: components for determining or causing determination of a signal to be sent to a secondary node (SN); components for sending or causing sending of the determined signal; components for identifying or causing identification of a signal received from the secondary node (SN); and components for processing or causing processing of the received signal.

[0095] Example 2 may include the subject matter as described in Example 1 or any other example herein, wherein the components for determining or causing the determination of a signal to be sent to the SN include components for determining or causing the determination of a packet or flow control to be sent to the SN.

[0096] Example 3 may include the subject matter as described in Example 2 or any other example herein, wherein the components for determining or causing the determination of a packet also include components for determining or causing the determination of a Packet Data Convergence Protocol (PDCP) or Protocol Data Unit (PDU).

[0097] Example 4 may include the subject matter as described in Example 1 or any other example herein, wherein the component for identifying or causing identification of a signal received from the SN further includes: a component for identifying or causing identification of feedback from the SN.

[0098] Example 5 may include the subject matter as described in Example 1 or any other example herein, wherein the components for processing or causing the processing of the received signal further include: components for processing or causing the processing to flow towards MN.

[0099] Example 6 may include the subject matter as described in Example 1 or any other example in this document, wherein the MN, SN, or another node or entity communicating with the MN or SN is interconnected by an interface.

[0100] Example 7 may include the subject as described in Example 6 or any other example in this document, wherein the interface includes X2, Xn, or F1.

[0101] Example 8 may include the subject matter as described in Example 7 or any other example herein, wherein a user plane entity for the interface supports a data frame structure for transmitting uplink packets toward a peer entity of the interface.

[0102] Example 9 may include the subject matter as described in Example 8 or any other example herein, wherein the user plane entity of the interface also provides feedback to the peer entity of the interface on the received downlink or uplink packets for flow control of the peer entity.

[0103] Example 10 may include the subject matter as described in Example 8 or any other example herein, wherein user plane entity support for the data frame structure further includes: components for transmitting or causing the transmission of the highest successful delivery PDCP sequence number for the downlink or the highest successful reception PDCP sequence number for the uplink for redundant transmission avoidance of the peer entity when PDCP is repeatedly configured.

[0104] Example 11 may include a secondary node (SN) comprising: components for determining or causing the determination of a signal to be sent to a master node (MN); components for sending or causing the sent signal; components for identifying or causing the identification of a signal received from the master node (MN); and components for processing or causing the processing of the received signal.

[0105] Example 12 may include the subject matter as described in Example 11 or any other example herein, wherein the components for determining or causing the determination of a signal to be sent to the MN include: components for determining or causing the determination of a packet or flow control to be sent to the MN.

[0106] Example 13 may include the subject matter as described in Example 12 or any other example herein, wherein the components for determining or causing the determination of a packet further include: components for determining or causing the determination of a Packet Data Convergence Protocol (PDCP) or Protocol Data Unit (PDU).

[0107] Example 14 may include the subject matter as described in Example 11 or any other example herein, wherein the component for identifying or causing the identification of a signal received from the MN further includes: a component for identifying or causing the identification of feedback from the MN.

[0108] Example 15 may include the subject matter as described in Example 11 or any other example herein, wherein the components for processing or causing the processing of the received signal further include: components for processing or causing the processing to flow control toward the SN.

[0109] Example 16 may include the subject matter as described in Example 11 or any other example herein, wherein the MN, SN, or another node or entity communicating with the SN or MN is interconnected by an interface.

[0110] Example 17 may include the subject as described in Example 16 or any other example in this document, wherein the interface includes X2, Xn, or F1.

[0111] Example 18 may include the subject matter as described in Example 17 or any other example herein, wherein the user plane entity for the interface supports a data frame structure for transmitting downlink and uplink packets toward peer entities of the interface.

[0112] Example 19 may include the subject matter as described in Example 18 or any other example herein, and also includes components for providing or causing to provide feedback on received downlink and uplink packets to a peer entity of the interface for flow control of the peer entity.

[0113] Example 20 may include the subject matter described in Example 19 or any other example herein, wherein user plane entity support for the data frame structure further includes components for transmitting or causing the transmission of the highest successful delivery PDCP sequence number for the downlink or the highest successful reception PDCP sequence number for the uplink to avoid redundant transmissions of the peer entity when PDCP is repeatedly configured.

[0114] Example 21 may include a radio access system network in which nodes or entities are interconnected by interfaces (e.g., X2, Xn, or F1). The system includes at least a primary node (MN) and a secondary node (SN), wherein the MN transmits packets (e.g., PDCP PDUs) and receives feedback from the SN, and performs flow control toward (or vice versa) the SN.

[0115] Example 22 may include an MN as described in Example 21 or some other examples herein, wherein a user plane entity for the interface supports a data frame structure for transmitting uplink packets toward peer entities of the interface; and provides feedback to peer entities of the interface on received downlink (e.g., in the case of SCG split bearers) and uplink packets for flow control of the peer entities.

[0116] Example 23 may include an SN as described in Example 21 or some other examples herein, wherein the user plane entity for the interface supports a data frame structure for transmitting downlink (e.g., in the case of SCG split bearer) and uplink packets toward the peer entity of the interface; and for providing feedback on the received downlink and uplink packets toward the peer entity of the interface for flow control of the peer entity.

[0117] Example 24 may include an MN or SN as described in Example 21 or some other examples herein, wherein the user plane entity for the interface supports a data frame structure for transmitting the highest successful delivery PDCP sequence number for the downlink and the highest successful reception PDCP sequence number for the uplink to the peer entity of the interface for redundant transmission avoidance by the peer entity in the event that PDCP is configured repeatedly.

[0118] Example 25 can be a master node (MN) for: determining or causing a signal to be sent to a secondary node (SN); sending or causing the determined signal to be sent; identifying or causing a signal received from the secondary node (SN); and processing or causing the received signal to be processed.

[0119] Example 26 may include the subject matter as described in Example 25 or any other example herein, wherein determining or causing the signal to be sent to the SN includes: determining or causing the packet or flow control to be sent to the SN.

[0120] Example 27 may include the subject matter described in Example 26 or any other example herein, wherein determining or causing the determination of a packet further includes: determining or causing the determination of a packet data convergence protocol (PDCP) or protocol data unit (PDU).

[0121] Example 28 may include the subject matter as described in Example 25 or any other example herein, wherein the signal that identifies or causes the identifier to be received from the SN further includes: feedback that identifies or causes the identifier to be received from the SN.

[0122] Example 29 may include the subject matter as described in Example 25 or any other example herein, wherein processing or causing the processing of the received signal further includes: processing or causing the processing to flow control toward MN.

[0123] Example 30 may include the subject matter as described in Example 25 or any other example herein, wherein the MN, SN, or another node or entity communicating with the MN or SN is interconnected by an interface.

[0124] Example 31 may include the subject as described in Example 30 or any other example in this document, wherein the interface includes X2, Xn, or F1.

[0125] Example 32 may include the subject matter as described in Example 31 or any other example herein, wherein a user plane entity for the interface supports a data frame structure for transmitting uplink packets toward a peer entity of the interface.

[0126] Example 33 may include the subject matter described in Example 32 or any other example herein, wherein the user plane entity of the interface also provides feedback to the peer entity of the interface on the received downlink or uplink packets for flow control of the peer entity.

[0127] Example 34 may include the subject matter described in Example 32 or any other example herein, wherein user plane entity support for the data frame structure further includes: transmitting or causing the transmission of the highest successful delivery PDCP sequence number for the downlink or the highest successful reception PDCP sequence number for the uplink, for redundant transmission avoidance by the peer entity when PDCP is repeatedly configured.

[0128] Example 35 may include a secondary node (SN) for: determining or causing a signal to be sent to the primary node (MN); sending or causing the determined signal to be sent; identifying or causing a signal received from the primary node (MN); and processing or causing the received signal to be processed.

[0129] Example 36 may include the subject matter as described in Example 35 or any other example herein, wherein determining or causing the signal to be sent to the MN includes: determining or causing the packet or flow control to be sent to the MN.

[0130] Example 37 may include the subject matter described in Example 36 or any other example herein, wherein determining or causing a packet to be determined further includes determining or causing a packet data convergence protocol (PDCP) or protocol data unit (PDU).

[0131] Example 38 may include the subject matter as described in Example 35 or any other example herein, wherein the signal that identifies or causes the identifier to be received from the MN also includes: feedback that identifies or causes the identifier to be received from the MN.

[0132] Example 39 may include the subject matter as described in Example 35 or any other example herein, wherein processing or causing the received signal to be processed further includes processing or causing the processing

[0133] Example 40 may include the subject matter as described in Example 35 or any other example herein, wherein the MN, SN, or another node or entity communicating with the SN or MN is interconnected by an interface.

[0134] Example 41 may include the subject as described in Example 40 or any other example in this document, wherein the interface includes X2, Xn, or F1.

[0135] Example 42 may include the subject matter as described in Example 41 or any other example herein, wherein a user plane entity for the interface supports a data frame structure for transmitting downlink and uplink packets toward peer entities of the interface.

[0136] Example 43 may include the subject matter as described in Example 42 or any other example herein, and may also include providing or causing to provide feedback to the peer entity of the interface on received downlink and uplink packets for flow control of the peer entity.

[0137] Example 44 may include the subject matter described in Example 43 or any other example herein, wherein user plane entity support for the data frame structure further includes: transmitting or causing the transmission of the highest successful delivery PDCP sequence number for the downlink or the highest successful reception PDCP sequence number for the uplink, for redundant transmission avoidance by the peer entity when PDCP is repeatedly configured.

[0138] Example 45 may include a method for implementing a master node (MN), comprising: determining or causing a signal to be sent to a secondary node (SN); sending or causing the determined signal to be sent; identifying or causing a signal received from the secondary node (SN); and processing or causing the received signal to be processed.

[0139] Example 46 may include the subject matter described in Example 45 or any other example herein, wherein determining or causing the signal to be sent to the SN includes: determining or causing the packet or flow control to be sent to the SN.

[0140] Example 47 may include the subject matter described in Example 46 or any other example herein, wherein determining or causing the determination of a packet further includes: determining or causing the determination of a packet data convergence protocol (PDCP) or protocol data unit (PDU).

[0141] Example 48 may include the subject matter as described in Example 45 or any other example herein, wherein the signal that identifies or causes the identifier to be received from the SN further includes: feedback that identifies or causes the identifier to be received from the SN.

[0142] Example 49 may include the subject matter as described in Example 45 or any other example herein, wherein processing or causing the processing of the received signal further includes: processing or causing the processing to flow control toward MN.

[0143] Example 50 may include the subject matter as described in Example 45 or any other example herein, wherein the MN, SN, or another node or entity communicating with the MN or SN is interconnected by an interface.

[0144] Example 51 may include the subject as described in Example 50 or any other example herein, wherein the interface includes X2, Xn, or F1.

[0145] Example 52 may include the subject matter as described in Example 51 or any other example herein, wherein a user plane entity for the interface supports a data frame structure for transmitting uplink packets toward a peer entity of the interface.

[0146] Example 53 may include the subject matter as described in Example 52 or any other example herein, wherein the user plane entity of the interface also provides feedback to the peer entity of the interface on the received downlink or uplink packets for flow control of the peer entity.

[0147] Example 54 may include the subject matter described in Example 52 or any other example herein, wherein user plane entity support for the data frame structure further includes: transmitting or causing the transmission of the highest successful delivery PDCP sequence number for the downlink or the highest successful reception PDCP sequence number for the uplink, for redundant transmission avoidance of the peer entity when PDCP is repeatedly configured.

[0148] Example 55 may include a method for implementing a secondary node (MN), comprising: determining or causing a signal to be sent to a primary node (MN); sending or causing the determined signal to be sent; identifying or causing a signal received from the primary node (MN); and processing or causing the received signal to be processed.

[0149] Example 56 may include the subject matter as described in Example 55 or any other example herein, wherein determining or causing the signal to be sent to the MN includes: determining or causing the packet or flow control to be sent to the MN.

[0150] Example 57 may include the subject matter described in Example 56 or any other example herein, wherein determining or causing the determination of a packet further includes: determining or causing the determination of a packet data convergence protocol (PDCP) or protocol data unit (PDU).

[0151] Example 58 may include the subject matter as described in Example 55 or any other example herein, wherein the signal that identifies or causes the identifier to be received from the MN further includes: feedback that identifies or causes the identifier to be received from the MN.

[0152] Example 59 may include the subject matter as described in Example 55 or any other example herein, wherein processing or causing the processing of a received signal further includes: processing or causing the processing of flow control toward the SN.

[0153] Example 60 may include the subject matter as described in Example 55 or any other example herein, wherein the MN, SN, or another node or entity communicating with the SN or MN is interconnected by an interface.

[0154] Example 61 may include the subject as described in Example 60 or any other example herein, wherein the interface includes X2, Xn, or F1.

[0155] Example 62 may include the subject matter as described in Example 61 or any other example herein, wherein a user plane entity for the interface supports a data frame structure for transmitting downlink and uplink packets toward peer entities of the interface.

[0156] Example 63 may include the subject matter as described in Example 62 or any other example herein, and may also include providing or causing to provide feedback on received downlink and uplink packets to the peer entity of the interface for flow control of the peer entity.

[0157] Example 64 may include the subject matter described in Example 63 or any other example herein, wherein user plane entity support for the data frame structure further includes: transmitting or causing the transmission of the highest successful delivery PDCP sequence number for the downlink or the highest successful reception PDCP sequence number for the uplink, for redundant transmission avoidance by the peer entity when PDCP is repeatedly configured.

[0158] Example 65 may include an apparatus comprising one or more elements for performing the methods described or associated with any of Examples 1 through 64, or performing any other methods or processes described herein.

[0159] Example 66 may include one or more non-transitory computer-readable media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the method described or associated with any of Examples 1 through 64, or any other method or process described herein.

[0160] Example 67 may include an apparatus comprising logic, module, or circuit means for performing one or more elements of the methods described or associated with any of Examples 1 through 64, or any other methods or processes described herein.

[0161] Example 68 may include methods, techniques, or processes, or portions thereof, as described or associated with any of Examples 1-64.

[0162] Example 69 may include an apparatus comprising: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process, or some portion thereof, as described or associated with any of Examples 1-64.

[0163] Example 70 may include a signal, or some part thereof, as described or associated with any of Examples 1-64.

[0164] Example 71 may include a radio access system network in which nodes or entities are interconnected by interfaces (e.g., X2, Xn, or F1). The system includes at least a primary node (MN) and a secondary node (SN), wherein the MN transmits packets (e.g., PDCP PDUs) and receives feedback from the SN, and performs flow control toward (or vice versa) the SN.

[0165] Example 72 may include an MN or SN as described in Example 71 or some other examples herein, wherein the user plane entity for the interface supports a data frame structure to trigger feedback reports from peer entities via polling.

[0166] Example 73 may include an MN or SN as described in Example 71 or some other examples herein, wherein the control plane entity of the interface supports procedures and message structures to configure / update / release periodic or event-based reporting triggers of the user plane through the interface.

[0167] Example 74 may include an MN or SN as described in Example 71 or some other examples herein, wherein the user plane entity for the interface supports a data frame structure to provide feedback reports to the peer entity based on triggers configured by the control plane entity or when the peer entity is polled by the user plane.

[0168] Example 75 may include an MN or SN as described in Example 71 or some other examples herein, wherein the user plane entity for the interface supports a data frame structure to request specific feedback from the peer entity (e.g., throughput, queuing delay, RLC delay, buffer status report, etc.) to achieve accurate metric estimation and flow control.

[0169] Example 76 may include an MN or SN as described in Example 71 or some other examples herein, wherein the user plane entity for the interface supports a data frame structure to provide feedback on requests in reports to peer entities for flow control of the peer entities.

[0170] Example 77 may include an MN or SN as described in Example 71 or some other examples herein, wherein the user plane entity for the interface supports a data frame structure to provide time offset information up to the time carried by the report for the reported PDCP SN (e.g., the highest successful delivery of the PDCP SN to the UE) for accurate measurement estimation of the peer entity.

[0171] Example 78 may include an MN or SN as described in Example 71 or some other examples herein, wherein the user plane entity for the interface supports a data frame structure to provide a report of missing packet status to the peer entity, the report being based on the number of consecutively lost packets from the start of the SN.

[0172] Example 79 may include an apparatus comprising one or more elements for performing the methods described or associated with any of Examples 71 to 78 or any other methods or processes described herein.

[0173] Example 80 may include one or more non-transitory computer-readable media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the methods described or associated with any of Examples 71 to 78, or any other methods or processes described herein.

[0174] Example 81 may include an apparatus comprising logic, modules, or circuitry comprising one or more elements for performing the methods described or associated with any of Examples 71 to 78, or any other methods or processes described herein.

[0175] Example 82 may include, or part thereof, a method, technique or process as described or associated with any of Examples 71 through 78.

[0176] Example 83 may include an apparatus comprising: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process, or some portion thereof, as described or associated with any of Examples 71 to 78.

[0177] Example 84 may include a signal, or some part thereof, as described or associated with any of Examples 71 to 78.

[0178] Example 85 may include a signal in a wireless network as shown and described herein.

[0179] Example 86 may include a method of communication in a wireless network as shown and described herein.

[0180] Example 87 may include a system for providing wireless communication as shown and described herein.

[0181] Example 88 may include devices for providing wireless communication as shown and described herein.

[0182] Example 89 is an apparatus for a New Radio (NR) node configured for New Radio (NR) user plane protocol communication between a primary node (MN) and a secondary node (SN). The apparatus includes: a processing circuitry configured to: access downlink (DL) user data; generate DL user data messages using the DL user data; initiate transmission of the DL user data messages to a second node; and process DL data delivery status messages from the second node in response to the DL user data messages; and an interface coupled to the processing circuitry configured to convey the DL user data messages to the second node and receive DL data delivery status messages from the second node.

[0183] In Example 90, the subject as described in Example 89 may optionally include the NR node comprising SN and the second node comprising MN.

[0184] In Example 91, the subject as described in Example 90 may optionally include the DL user data including the sequence number of the most successfully delivered PDCP Protocol Data Unit (PDU).

[0185] In Example 92, the topic as described in Example 91 may optionally include a DL user data message that includes a DL discard field based on the highest successfully delivered PDCP PDU sequence number, the DL discard field indicating a sequence number up to which all NR PDCP PDUs, including that sequence number, should be discarded by the second node.

[0186] In Example 93, the subject matter described in any one or more of Examples 89-92 may optionally include the NR node comprising a node that hosts NR Packet Data Convergence Protocol (PDCP) operations, and the second node comprising a corresponding node.

[0187] In Example 94, the subject matter as described in Example 93 may optionally include the processing circuitry being further configured to: access flow control data; generate a flow control configuration update using the flow control data; initiate a transmission of the flow control configuration update to the second node; and process a flow control configuration update acknowledgment from the second node.

[0188] In Example 95, the subject as described in Example 94 may optionally include the flow control data including report polling parameters.

[0189] In Example 96, the topic as described in Example 95 may optionally include the report polling parameter indicating that the NR node hosting the NR PDCP operation requests a downlink delivery status report.

[0190] In Example 97, the subject matter described in any one or more of Examples 89 to 96 may optionally include a DL user data message comprising a first PDU type and a DL data delivery status message comprising a second PDU type.

[0191] In Example 98, the subject matter as described in Example 97 may optionally include a DL data delivery status message that includes a parameter indicating the highest transmission NR PDCP sequence number.

[0192] In Example 99, the subject matter as described in Example 98 may optionally include a parameter indicating the transmitted status associated with the highest transmission NR PDCP sequence number, wherein the DL data delivery status message includes a parameter indicating the transmitted status associated with the highest transmission NR PDCP sequence number.

[0193] In Example 100, the subject described in any one or more of Examples 97 to 99 may optionally include a DL data delivery status message that includes a parameter indicating the highest retransmission NR PDCP sequence number.

[0194] In Example 101, the subject as described in Example 100 may optionally include a parameter in which the DL data delivery status message includes a parameter indicating the status associated with the highest retransmission NR PDCP sequence number.

[0195] Example 102 is a computer-readable storage medium including instructions that, when executed by one or more processors of an NR node configured for New Radio (NR) user plane protocol communication between a primary node (MN) and a secondary node (SN), cause the one or more processors to: access downlink (DL) user data; generate DL user data messages using the DL user data; initiate the transmission of the DL user data messages to a second node; and process DL data delivery status messages from the second node in response to the DL user data messages.

[0196] In Example 103, the subject as described in Example 102 may optionally include the NR node comprising SN, and the second node comprising MN.

[0197] In Example 104, the subject as described in Example 103 may optionally include the DL user data including the sequence number of the most successfully delivered PDCP Protocol Data Unit (PDU).

[0198] In Example 105, the topic as described in Example 104 may optionally include a DL user data message that includes a DL discard field based on the highest successfully delivered PDCP PDU sequence number, the DL discard field indicating a sequence number up to which all NR PDCP PDUs, including that sequence number, should be discarded by the second node.

[0199] In Example 106, the subject matter described in any one or more of Examples 102-105 may optionally include the processing circuitry being further configured to: access flow control data; generate a flow control configuration update using the flow control data; initiate a transmission of the flow control configuration update to the second node; and process a flow control configuration update acknowledgment from the second node.

[0200] In Example 107, the topic as described in Example 106 may optionally include the flow control data including report polling parameters, wherein the report polling parameters instruct the NR node hosting the NR PDCP operation to request a downlink delivery status report.

[0201] In Example 108, the subject matter described in any one or more of Examples 102 to 107 may optionally include a DL user data message comprising a first PDU type and a DL data delivery status message comprising a second PDU type.

[0202] In Example 109, the subject matter as described in Example 108 may optionally include a DL data delivery status message that includes a parameter indicating the highest transmission NR PDCP sequence number; and a DL data delivery status message that includes a parameter indicating the transmission status associated with the highest transmission NR PDCP sequence number.

[0203] In Example 110, the subject matter described in any one or more of Examples 108-109 may optionally include a DL data delivery status message that includes a parameter indicating the highest retransmission NR PDCP sequence number; and a DL data delivery status message that includes a parameter indicating a status associated with the highest retransmission NR PDCP sequence number.

[0204] Example 111 is a method executed by one or more processors of a new radio (NR) node configured for NR user plane protocol communication between a primary node (MN) and a secondary node (SN), the method comprising: accessing downlink (DL) user data; generating DL user data messages using the DL user data; initiating the transmission of the DL user data messages to the second node; and processing DL data delivery status messages from the second node in response to the DL user data messages.

[0205] In Example 112, the subject as described in Example 111 may optionally include the NR node comprising SN, and the second node comprising MN.

[0206] In Example 113, the subject as described in Example 112 may optionally include the DL user data including the sequence number of the most successfully delivered PDCP Protocol Data Unit (PDU).

[0207] In Example 114, the topic as described in Example 113 may optionally include a DL discard field based on the highest successfully delivered PDCP PDU sequence number, which indicates a sequence number up to which all NR PDCP PDUs, including that sequence number, should be discarded by the second node.

[0208] In Example 115, the subject matter described in any one or more of Examples 111 to 114 may optionally include the NR node comprising a node that hosts NR Packet Data Convergence Protocol (PDCP) operations, and the second node comprising a corresponding node.

[0209] In Example 116, the topic as described in Example 115 may optionally include: accessing flow control data; generating a flow control configuration update using the flow control data; initiating a transmission of the flow control configuration update to the second node; and processing a flow control configuration update acknowledgment from the second node.

[0210] In Example 117, the topic as described in Example 116 may optionally include the flow control data including report polling parameters.

[0211] In Example 118, the topic as described in Example 117 may optionally include the report polling parameter indicating that the NR node hosting the NR PDCP operation requests a downlink delivery status report.

[0212] In Example 119, the subject matter described in any one or more of Examples 111 to 118 may optionally include an embodiment in which the DL user data message includes a first PDU type and the DL data delivery status message includes a second PDU type.

[0213] In Example 120, the subject as described in Example 119 may optionally include a DL data delivery status message that includes a parameter indicating the highest transmission NR PDCP sequence number.

[0214] In Example 121, the subject as described in Example 120 may optionally include a parameter indicating the transmitted status associated with the highest transmission NR PDCP sequence number, wherein the DL data delivery status message includes a parameter indicating the transmitted status associated with the highest transmission NR PDCP sequence number.

[0215] In Example 122, the subject matter described in any one or more of Examples 119-121 may optionally include a parameter indicating the highest retransmission NR PDCP sequence number in the DL data delivery status message.

[0216] In Example 123, the subject as described in Example 122 may optionally include a parameter in which the DL data delivery status message includes a parameter indicating the status associated with the highest retransmission NR PDCP sequence number.

[0217] Example 124 is an apparatus for a new radio (NR) node configured as a secondary node (SN) for communicating with a primary node (MN) using a new radio (NR) user plane protocol. The apparatus includes: a processing circuitry configured to: access downlink (UL) user data; generate UL user data messages using the UL user data; initiate transmission of the UL user data messages to the MN; and process UL data delivery status messages from the MN in response to the UL user data messages; and an interface coupled to the processing circuitry configured to convey the UL user data messages to the MN and receive UL data delivery status messages from the MN.

[0218] In Example 125, the subject matter as described in Example 124 may optionally include the UL user data including the sequence number of the most successfully delivered PDCP Protocol Data Unit (PDU).

[0219] In Example 126, the subject as described in Example 125 may optionally include a UL user data message that includes a UL discard field based on the highest successfully delivered PDCP PDU sequence number, the UL discard field indicating a sequence number up to which all NR PDCP PDUs including that sequence number should be discarded by the second node.

[0220] Example 127 is an apparatus for a new radio (NR) node configured as a master node (MN) in a new radio (NR) user plane protocol communication with a secondary node (SN). The apparatus includes: a processing circuitry configured to: access downlink (UL) user data; generate UL user data messages using the UL user data; initiate transmission of the UL user data messages to the SN; and process UL data delivery status messages from the SN in response to the UL user data messages; and an interface coupled to the processing circuitry, configured to convey the UL user data messages to the SN and receive the UL data delivery status messages from the SN.

[0221] In Example 128, the subject matter described in any one or more of Examples 124 to 127 may optionally include UL user data including the sequence number of the highest successfully delivered PDCP Protocol Data Unit (PDU).

[0222] In Example 129, the subject matter described in any one or more of Examples 125 to 128 may optionally include a UL user data message that includes a UL discard field based on the highest successfully delivered PDCP PDU sequence number, the UL discard field indicating a sequence number up to which all NR PDCP PDUs including that sequence number should be discarded by the second node.

[0223] In Example 130, the subject matter described in any one or more of Examples 117 to 129 may optionally include the report polling parameter indicating that the NR node hosting the NR PDCP operation requests a downlink delivery status report.

[0224] In Example 131, the subject matter described in any one or more of Examples 115 to 130 may optionally include: components for accessing flow control data; components for generating a flow control configuration update using the flow control data; components for initiating a transmission of the flow control configuration update to the second node; and components for processing flow control configuration update acknowledgments from the second node.

[0225] In Example 132, the subject matter described in any one or more of Examples 120 to 131 may optionally include a DL data delivery status message that includes a parameter indicating the transmitted status associated with the highest transmission NR PDCP sequence number.

[0226] In Example 133, the subject matter described in any one or more of Examples 111-132 may optionally include a DL user data message comprising a first PDU type and a DL data delivery status message comprising a second PDU type.

[0227] In Example 134, the subject matter described in any one or more of Examples 113 to 133 may optionally include a DL user data message that includes a DL discard field based on the highest successfully delivered PDCP PDU sequence number, the DL discard field indicating a sequence number up to which all NR PDCP PDUs including that sequence number should be discarded by the second node.

[0228] In Example 135, the subject matter described in any one or more of Examples 111 to 134 may optionally include the NR node comprising SN, and the second node comprising MN.

[0229] In Example 136, the subject matter described in any one or more of Examples 111 to 135 may optionally include the NR node comprising a node that hosts NR Packet Data Convergence Protocol (PDCP) operations, and the second node comprising a corresponding node.

[0230] In Example 137, the subject matter described in any one or more of Examples 135 to 136 may optionally include DL user data including the sequence number of the highest successfully delivered PDCP Protocol Data Unit (PDU).

[0231] In Example 138, the subject matter described in any one or more of Examples 122 to 137 may optionally include a DL data delivery status message that includes a parameter indicating the status associated with the highest retransmission NR PDCP sequence number.

[0232] In Example 139, the subject matter described in any one or more of Examples 133 to 138 may optionally include a DL data delivery status message that includes a parameter indicating the highest retransmission NR PDCP sequence number.

[0233] Example 140 is an apparatus for a novel radio (NR) node configured for NR user plane protocol communication between a primary node (MN) and a secondary node (SN). The apparatus includes: components for accessing downlink (DL) user data; components for generating DL user data messages using the DL user data; components for initiating the transmission of the DL user data messages to the second node; and components for processing DL data delivery status messages from the second node in response to the DL user data messages.

[0234] In Example 141, the subject matter described in any one or more of Examples 131 to 140 may optionally include the flow control data including report polling parameters.

[0235] In Example 142, the subject matter described in any one or more of Examples 133 to 141 may optionally include a DL data delivery status message that includes a parameter indicating the highest transmission NR PDCP sequence number.

[0236] The foregoing description of one or more implementations provides illustrations and descriptions, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. Modifications and variations are possible or can be obtained by implementing various embodiments based on the above teachings.

[0237] In addition to the example embodiments described above, any combination of operations or elements described above can be integrated into the various embodiments described herein. Furthermore, other example embodiments may include any of the examples described above, wherein individual operations or device elements are repeated or ordered in any functional order with intermediary elements or operations.

[0238] Figure 6 Example UE 600 is shown. UE 600 can be an implementation of UE 101, 102, or any other device described herein. UE 600 may include one or more antennas 608 configured to communicate with a transmitting station, such as a base station, eNB / gNB, or another type of wireless wide area network (WWAN) access point. UE 600 can communicate using separate antennas for each wireless communication standard or using antennas shared for multiple wireless communication standards. UE 600 can communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and / or a WWAN.

[0239] Figure 6 A microphone 620 and one or more speakers 612 are also shown for audio input and output to and from the UE 600. As a head-mounted device, the UE 600 includes one or more interfaces for a user interface (UI). The UE 600 includes, in particular, a display screen 604, which may be a liquid crystal display (LCD) screen or another type of display, such as an organic light-emitting diode (OLED) display. The display screen 604 can be configured as a touchscreen. The touchscreen can use capacitive, resistive, or another type of touchscreen technology. An application processor 614 and a graphics processor 618 can be coupled to internal memory 616 to provide processing and display capabilities. A non-volatile memory port 610 can also be used to provide data input / output (I / O) options to the user. The non-volatile memory port 610 can also be used to expand the memory capacity of the UE 600. A keyboard 606 can be integrated with the UE 600 or wirelessly connected to the UE 600 to provide additional user input. A virtual keyboard can also be provided using a touchscreen. The camera 622, located on the front (display 604) or rear of the UE 600, can also be integrated into the housing 602 of the UE 600.

[0240] Figure 7This is a block diagram illustrating an example computer system machine 700 on which any one or more methods discussed herein can be performed, and on which the computer system machine 700 can be used to implement UE 101, 102, or any other device described herein. In various alternative embodiments, the computer system machine 700 operates as a standalone device or is connectable (e.g., networked) to other machines. In a networked deployment, the computer system machine 700 can operate as a server or client machine in a server-client network environment, or it can operate as a peer-to-peer (or distributed) network environment. The computer system machine 700 can be a personal computer (PC) (which may or may not be portable (e.g., a laptop or netbook)), a tablet device, a set-top box (STB), a game console, a personal digital assistant (PDA), a mobile phone or smartphone, a web device, a network router, a network switch, a bridge, or any machine capable of executing instructions (sequential or otherwise) specifying the actions to be taken by the machine. Furthermore, although only a single computer system machine 700 is illustrated, the term "machine" should be understood to include any collection of machines that individually or jointly execute a set (or more) of instructions to perform any one or more methods discussed herein.

[0241] Example computer system machine 700 includes a processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), main memory 704, and static memory 706, which communicate with each other via interconnect 708 (e.g., a link, bus, etc.). Computer system machine 700 may also include a video display device 710, an alphanumeric input device 712 (e.g., a keyboard), and a user interface (UI) navigation device 714 (e.g., a mouse). In one embodiment, the video display device 710, the alphanumeric input device 712, and the UI navigation device 714 are touchscreen displays. The computer system 700 may also include a mass storage device 716 (e.g., a drive unit), a signal generation device 718 (e.g., a speaker), an output controller 732, a power management controller 734, a network interface device 720 (which may include one or more antennas 730, transceivers, or other wireless communication hardware or operatively communicate with them), and one or more sensors 728, such as a Global Positioning System (GPS) sensor, a compass, a position sensor, an accelerometer, or other sensors.

[0242] Mass storage device 716 includes a machine-readable medium 722 on which one or more sets of data structures and instructions 724 (e.g., software) are stored to implement or be utilized by any one or more methods or functions described herein. The instructions 724 may also reside wholly or at least partially within main memory 704, static memory 706, and / or processor 702 during execution by computer system machine 700, wherein main memory 704, static memory 706, and processor 702 also constitute a machine-readable medium.

[0243] Although machine-readable medium 722 is shown as a single medium in the example embodiment, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) storing one or more instructions 724. The term "machine-readable medium" should also be understood to include any tangible medium capable of storing, encoding, or carrying instructions (e.g., instructions 724) that are executed by a machine and cause the machine to perform any one or more methods of this disclosure, or capable of storing, encoding, or carrying data structures utilized by or associated with such instructions.

[0244] Instructions 724 can also be sent or received via network interface device 720, using a transmission medium, through communication network 726, using any of several known transmission protocols (e.g., Hypertext Transfer Protocol, HTTP). The term "transmission medium" should be understood to include any medium capable of storing, encoding, or carrying instructions for machine execution, and includes digital or analog communication signals or other intangible media that facilitate communication of such software.

[0245] Various technologies, or aspects or parts thereof, may take the form of program code (e.g., instruction 724) embodied in a tangible medium, such as a floppy disk, CD-ROM, hard disk drive, non-transitory computer-readable storage medium, or any other machine-readable storage medium, wherein when the program code is loaded into and executed by a machine such as a computer, the machine becomes an apparatus for implementing the various technologies. In the case of program code execution on a programmable computer, the computer may include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. Volatile and non-volatile memory and / or storage elements may be random access memory, erasable programmable read-only memory (EPROM), flash memory drive, optical drive, magnetic hard disk drive, or other media for storing electronic data. Base stations and UEs may also include transceiver modules, counter modules, processing modules, and / or clock modules or timer modules. One or more programs that implement or utilize the various techniques described herein may use application programming interfaces (APIs), reusable controls, and so on. Such programs may be implemented using high-level procedural programming languages ​​or object-oriented programming languages ​​to communicate with computer systems. However, if desired, the programs(s) may be implemented using assembly or machine language. In any case, the language may be a compiled or interpreted language and may be combined with a hardware implementation.

[0246] Figure 8Example components of device 800 are illustrated according to some embodiments. In some embodiments, device 800 may include at least, as shown, an application circuitry device 802, a baseband circuitry device 804, a radio frequency (RF) circuitry device 806, a front-end module (FEM) circuitry device 808, one or more antennas 810, and a power management circuitry (PMC) 812 coupled together. The components of the illustrated device 800 may be included in a UE or RAN node. In some embodiments, device 800 may include fewer elements (e.g., the RAN node may not utilize application circuitry device 802, but instead include a processor / controller to process IP data received from the EPC). In some embodiments, device 800 may include additional elements such as memory / storage devices, displays, cameras, sensors, or input / output (I / O) interfaces. In other embodiments, the components described below may be included in more than one device (e.g., for a cloud RAN (C-RAN) implementation, such circuitry may be separately included in more than one device).

[0247] Application circuit device 802 may include one or more application processors. For example, application circuit device 802 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors (multiple) may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). The processors may be coupled to or may include memory / storage devices and may be configured to execute instructions stored in the memory / storage devices to enable various applications or operating systems to run on device 800. In some embodiments, the processor of application circuit device 802 may process IP data packets received from EPC.

[0248] The baseband circuit device 804 may include, for example, but not limited to, one or more single-core or multi-core processors. The baseband circuit device 804 may include one or more baseband processors or control logic to process baseband signals received from the receive signal path of the RF circuit device 806 and generate baseband signals for the transmit signal path of the RF circuit device 806. The baseband circuit device 804 may interface with the application circuit device 802 to generate and process baseband signals and control the operation of the RF circuit device 806. For example, in some embodiments, the baseband circuit device 804 may include a third-generation (3G) baseband processor 804A, a fourth-generation (4G) baseband processor 804B, a fifth-generation (5G) baseband processor 804C, or other (multiple) baseband processors 804D for other existing generations, generations under development, or future generations (e.g., second-generation (2G), sixth-generation (6G), etc.). Baseband circuitry 804 (e.g., one or more of baseband processors 804A-D) can handle various radio control functions that allow communication with one or more radio networks via RF circuitry 806. In other embodiments, some or all of the functions of baseband processors 804A-D may be included in a module stored in memory 804G and executed via a central processing unit (CPU) 804E. Radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, RF offset, etc. In some embodiments, the modulation / demodulation circuitry of baseband circuitry 804 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuitry of baseband circuitry 804 may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder / decoder functions. Embodiments of modulation / demodulation and encoder / decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments.

[0249] In some embodiments, the baseband circuitry 804 may include one or more audio digital signal processors (DSPs) 804F. The audio DSPs 804F(s) may be or may include elements for compression / decompression and echo cancellation, and in other embodiments may include other suitable processing units. Components of the baseband circuitry 804 may be suitably combined on a single chip or a single chip assembly, or in some embodiments arranged on the same circuit board. In some embodiments, some or all of the constituent components of the baseband circuitry 804 and the application circuitry 802 may be implemented together on, for example, a system on a chip (SOC).

[0250] In some embodiments, baseband circuitry 804 can provide communications compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 804 may support communications with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), wireless local area networks (WLAN), or wireless personal area networks (WPAN). Embodiments of baseband circuitry 804 configured to support radio communications with more than one radio protocol may be referred to as multimode baseband circuitry 804.

[0251] RF circuitry 806 can enable communication with a wireless network using modulated electromagnetic radiation via a non-solid-state medium. In various embodiments, RF circuitry 806 may include switches, filters, amplifiers, etc., to facilitate communication with the wireless network. RF circuitry 806 may include a receive signal path that may include circuitry to down-convert RF signals received from FEM circuitry 808 and provide baseband signals to baseband circuitry 804. RF circuitry 806 may also include a transmit signal path that may include circuitry to up-convert baseband signals provided by baseband circuitry 804 and provide RF output signals to FEM circuitry 808 for transmission.

[0252] In some embodiments, the receive signal path of the RF circuit device 806 may include a mixer circuit device 806a, an amplifier circuit device 806b, and a filter circuit device 806c. In some embodiments, the transmit signal path of the RF circuit device 806 may include a filter circuit device 806c and a mixer circuit device 806a. The RF circuit device 806 may also include a synthesizer circuit device 806d for synthesizing frequencies for use by the mixer circuit device 806a in both the receive and transmit signal paths. In some embodiments, the mixer circuit device 806a in the receive signal path may be configured to down-convert the RF signal received from the FEM circuit device 808 based on the synthesized frequency provided by the synthesizer circuit device 806d. The amplifier circuit device 806b may be configured to amplify the down-converted signal, and the filter circuit device 806c may be a low-pass filter (LPF) or a band-pass filter (BPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal can be provided to the baseband circuitry 804 for further processing. In some embodiments, the output baseband signal may be a zero-frequency baseband signal, although this is not a necessary requirement. In some embodiments, the mixer circuitry 806a receiving the signal path may include a passive mixer, although the scope of the embodiments is not limited in this respect.

[0253] In some embodiments, the mixer circuit 806a of the transmission signal path can be configured to up-convert the input baseband signal based on the synthesis frequency provided by the synthesizer circuit 806d to generate an RF output signal for the FEM circuit 808. The baseband signal can be provided by the baseband circuit 804 and can be filtered by the filter circuit 806c.

[0254] In some embodiments, the mixer circuit device 806a for the receiving signal path and the mixer circuit device 806a for the transmitting signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuit device 806a for the receiving signal path and the mixer circuit device 806a for the transmitting signal path may include two or more mixers and may be arranged for image suppression (e.g., Hartley image suppression). In some embodiments, the mixer circuit device 806a for the receiving signal path and the mixer circuit device 806a for the transmitting signal path may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuit device 806a for the receiving signal path and the mixer circuit device 806a for the transmitting signal path may be configured for superheterodyne operation.

[0255] In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, RF circuitry 806 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and baseband circuitry 804 may include a digital baseband interface for communicating with RF circuitry 806.

[0256] In some dual-mode embodiments, separate radio integrated circuits (ICs) may be provided to process signals for each spectrum, although the scope of the embodiments is not limited in this respect.

[0257] In some embodiments, synthesizer circuitry 806d may be a fractional N synthesizer or a fractional N / N+1 synthesizer, although the scope of the embodiments is not limited in this respect, as other types of frequency synthesizers may be applicable. For example, synthesizer circuitry 806d may be an incremental sum synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.

[0258] The synthesizer circuit device 806d can be configured to synthesize an output frequency based on the frequency input and the divider control input for use by the mixer circuit device 806a of the RF circuit device 806. In some embodiments, the synthesizer circuit device 806d can be a fractional N / N+1 synthesizer.

[0259] In some embodiments, the frequency input may be provided by a voltage-controlled oscillator (VCO), although this is not mandatory. Depending on the desired output frequency, the divider control input may be provided by baseband circuitry device 804 or application circuitry device 802. In some embodiments, the divider control input (e.g., N) may be determined from a lookup table based on the channel indicated by application circuitry device 802.

[0260] The synthesizer circuitry 806d of the RF circuitry 806 may include a frequency divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the frequency divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by N or N+1 (e.g., based on carry-out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded tunable delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these embodiments, the delay elements may be configured to decompose the VCO period into Nd equal phase packets, where Nd is the number of delay elements in the delay line. Thus, the DLL provides negative feedback to help ensure that the total delay across the delay line is one VCO period.

[0261] In some embodiments, synthesizer circuitry 806d may be configured to generate a carrier frequency as an output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and frequency divider circuitry to generate multiple signals having multiple different phases from each other at the carrier frequency. In some embodiments, the output frequency may be the LO frequency (e.g., fLO). In some embodiments, RF circuitry 806d may include an IQ / polar coordinate converter.

[0262] FEM circuitry 808 may include a receive signal path that includes circuitry configured to operate on RF signals received from one or more antennas 810, amplify the received signals, and provide an amplified version of the received signals to RF circuitry 806 for further processing. FEM circuitry 808 may also include a transmit signal path that includes circuitry configured to amplify the signals provided by RF circuitry 806 for transmission by one or more of the one or more antennas 810. In various embodiments, amplification via the transmit or receive signal path may be performed only in RF circuitry 806, only in FEM 808, or in both RF circuitry 806 and FEM 808.

[0263] In some embodiments, FEM circuitry 808 may include a TX / RX switch to switch between transmit and receive modes. FEM circuitry 808 may include a receive signal path and a transmit signal path. The receive signal path of FEM circuitry 808 may include an LNA to amplify a received RF signal and provide the amplified received RF signal as an output (e.g., provided to RF circuitry 806). The transmit signal path of FEM circuitry 808 may include a power amplifier (PA) to amplify the input RF signal (e.g., provided by RF circuitry 806) and includes one or more filters to generate an RF signal for subsequent transmission (e.g., transmitted by one or more of one or more antennas 810).

[0264] In some embodiments, the PMC 812 can manage the power supplied to the baseband circuitry 804. Specifically, the PMC 812 can control power selection, voltage scaling, battery charging, or DC-DC conversion. The PMC 812 is often included when the device 800 can be battery powered, such as when the device 800 is included in a UE. The PMC 812 can increase power conversion efficiency while providing the desired implementation size and thermal characteristics.

[0265] Figure 8 A PMC 812 is shown that is coupled only to the baseband circuitry 804. However, in other embodiments, the PMC 812 may be additionally or alternatively coupled to other components and perform similar power management operations for other components, such as, but not limited to, application circuitry 802, RF circuitry 806, or FEM circuitry 808.

[0266] In some embodiments, the PMC 812 can control various power-saving mechanisms of the device 800 or otherwise act as part of such power-saving mechanisms. For example, if the device 800 is in the RRC_Connected state, in which the device 800 remains connected to the RAN node because it expects to receive traffic soon, then the device 800 can enter a state called Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 800 can interrupt power at short intervals to save power.

[0267] If there is no data traffic activity for an extended period, device 800 can transition to the RRC_Idle state, in which device 800 disconnects from the network and does not perform operations such as channel quality feedback or handover. Device 800 enters a very low-power state and performs paging, periodically waking up to listen to the network before powering down again. Device 800 may not receive data in this state; to receive data, device 800 transitions back to the RRC_Connected state.

[0268] An additional power-saving mode allows device 800 to be unavailable to the network for periods longer than the paging interval (ranging from seconds to hours). During this time, device 800 is completely unreachable from the network and can be completely powered off. Any data sent during this time suffers significant delay, and it is assumed that such delay is acceptable.

[0269] The processors of application circuit device 802 and baseband circuit device 804 are units that can be used to execute one or more instances of a protocol stack. For example, the processor of baseband circuit device 804 can be used individually or in combination to execute layer 3, layer 2, or layer 1 functions, while the processor of application circuit device 802 can utilize data received from these layers (e.g., packet data) and further execute layer 4 functions (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers). For the purposes of this document, layer 3 may include a radio resource control (RRC) layer, which is described in more detail below. For the purposes of this document, layer 2 may include a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, which is described in more detail below. For the purposes of this document, layer 1 may include the physical (PHY) layer of the UE / RAN node, which is described in more detail below.

[0270] Figure 9 An example interface of the baseband circuit device 804 is illustrated according to some embodiments. As described above, Figure 8The baseband circuitry 804 may include processors 804A-804E and memory 804G utilized by such processors. Each of the processors 804A-804E may respectively include memory interfaces 904A-904E for sending / receiving data to / from memory 804G.

[0271] The baseband circuit device 804 may also include one or more interfaces for communicatively coupling to other circuits / devices, such as a memory interface 912 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit device 804) and an application circuit device interface 914 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit device 804). Figure 8 The application circuit device 802 transmits / receives data interface), and the RF circuit device interface 916 (e.g., to / from...). Figure 8 RF circuit device 806 (interface for transmitting / receiving data), wireless hardware connectivity interface 918 (e.g., for transmitting / receiving data to / from Near Field Communication (NFC) components), Components (e.g., low energy consumption) ), Interfaces for sending / receiving data to / from components and other communication components) and power management interface 920 (e.g., an interface for sending / receiving power or control signals to / from PMC 812).

[0272] Figure 10 This is a diagram of a control plane protocol stack according to some embodiments. In this embodiment, control plane 1000 is shown as a communication protocol stack between UE 101 (or UE 102), macro RAN node 111 (or LP RAN node 112) and MME 121.

[0273] PHY layer 1001 can transmit or receive information used by MAC layer 1002 through one or more air interfaces. PHY layer 1001 can also perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers (e.g., RRC layer 1005). PHY layer 1001 can also perform error detection on the transport channel, forward error correction (FEC) encoding / decoding on the transport channel, modulation / demodulation of the physical channel, interleaving, rate matching, mapping to the physical channel, and multiple input multiple output (MIMO) antenna processing.

[0274] MAC layer 1002 can perform mapping between logical channels and transport channels, multiplexing MAC service data units (SDUs) from one or more logical channels onto transport blocks (TBs) for delivery to PHY layer 1001 via transport channels, demultiplexing MAC SDUs from transport blocks (TBs) delivered from PHY layer 1001 via transport channels onto one or more logical channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction via hybrid automatic repeat request (HARQ), and logical channel prioritization.

[0275] RLC layer 1003 can operate in multiple modes, including Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). RLC layer 1003 can perform the transmission of upper-layer protocol data units (PDUs), error correction via automatic repeat request (ARQ) for AM data transmission, and concatenation, segmentation, and reassembly of RLCSDUs for UM and AM data transmission. RLC layer 1003 can also perform RLC data PDU resegmentation for AM data transmission, reordering of RLC data PDUs for UM and AM data transmission, duplicate data detection for UM and AM data transmission, discarding of RLC SDUs for UM and AM data transmission, protocol error detection for AM data transmission, and RLC re-establishment.

[0276] The PDCP layer 1004 can perform IP data header compression and decompression, maintain PDCP sequence numbers (SN), perform in-order delivery of upper-layer PDUs during lower-layer re-establishment, eliminate duplication of lower-layer SDUs during lower-layer re-establishment for radio bearers mapped to RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification of control plane data, control the timer-based discarding of data, and perform security operations (e.g., encryption, decryption, integrity protection, integrity verification, etc.).

[0277] The main services and functions of RRC layer 1005 may include broadcasting system information (e.g., included in the Master Information Block (MIB) or System Information Block (SIB) related to the Non-Access Layer (NAS); broadcasting system information related to the Access Layer (AS); paging, establishment, maintenance, and release of RRC connections between the UE and E-UTRAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release); establishment, configuration, maintenance, and release of point-to-point radio bearers; security functions including key management; mobility between Radio Access Technologies (RATs); and measurement configuration for UE measurement reporting. Such MIBs and SIBs may include one or more information elements (IEs), each of which may include an individual data field or data structure.

[0278] UE 101 and macro RAN node 111 can use the Uu interface (e.g., LTE-Uu interface) to exchange control plane data via a protocol stack including PHY layer 1001, MAC layer 1002, RLC layer 1003, PDCP layer 1004 and RRC layer 1005.

[0279] The Non-Access Layer (NAS) protocol 1006 forms the highest layer of the control plane 1000 between UE 101 and MME 121. The NAS protocol 1006 supports the mobility and session management processes of UE 101 to establish and maintain IP connectivity between UE 101 and P-GW 123.

[0280] The S1 Application Protocol (S1-AP) layer 1015 supports the functions of the S1 interface and includes an Elementary Procedure (EP). The EP is the unit of interaction between the macro RAN node 111 and CN 120. S1-AP layer 1015 services can include two groups: UE-associated services and non-UE-associated services. These services perform functions, including but not limited to: E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transmission, RAN Information Management (RIM), and configuration transfer.

[0281] The Stream Control Transmission Protocol (SCTP) layer (or SCTP / IP layer) 1014 can, in part, rely on the IP protocol supported by the IP layer 1013 to ensure reliable delivery of signaling messages between the macro RAN node 111 and the MME 121. The L2 layer 1012 and L1 layer 1011 can refer to the communication links (e.g., wired or wireless) used by the macro RAN node 111 and the MME 121 to exchange information.

[0282] Macro RAN node 111 and MME 121 can use the S1-MME interface to exchange control plane data via a protocol stack including L1 layer 1011, L2 layer 1012, IP layer 1013, SCTP layer 1014 and S1-AP layer 1015.

[0283] Figure 11 This is an illustration of a user plane protocol stack according to some embodiments. In this embodiment, user plane 1100 is shown as a communication protocol stack between UE 101 (or UE 102), macro RAN node 111 (or LP RAN node 112), S-GW 122, and P-GW 123. User plane 1100 may utilize at least some of the same protocol layers as control plane 1000. For example, UE 101 and macro RAN node 111 may exchange user plane data via a Uu interface (e.g., LTE-Uu interface) through a protocol stack including PHY layer 1001, MAC layer 1002, RLC layer 1003, and PDCP layer 1004.

[0284] The General Packet Radio Service (GPRS) Tunneling Protocol for the user plane (GTP-U) layer 1104 can be used to carry user data within the GPRS core network and between the radio access network and the core network. The transmitted user data can be packets in any of the following formats: IPv4, IPv6, or PPP. The UDP and IP Security (UDP / IP) layer 1103 can provide checksums for data integrity, address port numbers for different functions at the source and destination, and encryption and authentication of selected data streams. Macro RAN nodes 111 and S-GW 122 can exchange user plane data via the S1-U interface through a protocol stack including L1 layer 1011, L2 layer 1012, UDP / IP layer 1103, and GTP-U layer 1104. S-GW 122 and P-GW 123 can utilize the S5 / S8a interface to exchange user plane data via a protocol stack including L1 layer 1011, L2 layer 1012, UDP / IP layer 1103, and GTP-U layer 1104. (As mentioned above...) Figure 10 The NAS protocol discussed here supports the mobility and session management process of UE 101 to establish and maintain IP connectivity between UE 101 and P-GW 123.

[0285] Figure 12 This is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more methods discussed herein, according to some example embodiments. Specifically, Figure 12 A schematic representation of hardware resources 1200 is shown, including one or more processors (or processor cores) 1210, one or more memory / storage devices 1220, and one or more communication resources 1230, each of which can be communicatively coupled via bus 1240. For embodiments utilizing node virtualization (e.g., Network Functions Virtualization (NFV)), a hypervisor 1202 can be executed to provide an execution environment for one or more network slices / subslices using hardware resources 1200.

[0286] Processor 1210 may include, for example, processor 1212 and processor 1214. Processor 1210 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) (e.g., a baseband processor), an application-specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof.

[0287] The memory / storage device 1220 may include main memory, disk storage devices, or any suitable combination thereof. The memory / storage device 1220 may include, but is not limited to, any type of volatile or non-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage devices, and so on.

[0288] Communication resource 1230 may include interconnect or network interface components or other suitable devices for communicating with one or more peripheral devices 1204 or one or more databases 1206 via network 1208. For example, communication resource 1230 may include wired communication components (e.g., for coupling via Universal Serial Bus (USB)), cellular communication components, NFC components, etc. Components (e.g., low energy consumption) ), Components and other communication components.

[0289] Instructions 1250 may include software, programs, applications, applets, or other executable code for causing at least any one of the processors 1210 to perform any one or more of the methods discussed herein. Instructions 1250 may reside wholly or partially within at least one processor of the processor 1210 (e.g., within the processor's cache memory), within memory / storage device 1220, or any suitable combination thereof. Furthermore, any portion of instructions 1250 may be transferred from peripheral device 1204 or database 1206 to hardware resource 1200 from any combination. Therefore, the memory of processor 1210, memory / storage device 1220, peripheral device 1204, and database 1206 are examples of computer-readable and machine-readable media.

[0290] Figure 13 The illustration shows components of CN 120 according to some embodiments. Components of CN 120 can be implemented in a single physical node or separate physical nodes, which include components to read and execute instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media). In some embodiments, Network Functions Virtualization (NFV) is utilized to virtualize any or all of the aforementioned network node functions via executable instructions stored in one or more computer-readable storage media (described in more detail below). A logical instantiation of CN 120 may be referred to as network slice 1301. A logical instantiation of a portion of CN 120 may be referred to as network subslice 1302 (e.g., network subslice 1302 is shown as including P-GW 123 and PCRF 126).

[0291] NFV architectures and infrastructures can be used to virtualize one or more network functions, either directly or by dedicated hardware, onto physical resources including a combination of industry-standard server hardware, storage hardware, or switches. In other words, NFV systems can be used to implement virtual or reconfigurable implementations of one or more EPC components / functions.

[0292] Figure 14This is a block diagram illustrating the components of system 1400 according to some example embodiments. System 1400 is shown to include a virtualized infrastructure manager (VIM) 1402, a network functions virtualization infrastructure (NFVI) 1404, a VNF manager (VNFM) 1406, a virtualized network function (VNF) 1408, an element manager (EM) 1410, an NFV orchestrator (NFVO) 1412, and a network manager (NM) 1414.

[0293] VIM 1402 manages the resources of NFVI 1404. NFVI 1404 may include physical or virtual resources and applications (including hypervisors) used to run system 1400. VIM 1402 can work with NFVI 1404 to manage the lifecycle of virtual resources (e.g., the creation, maintenance, and teardown of virtual machines (VMs) associated with one or more physical resources); track VM instances; track the performance, failure, and security of VM instances and associated physical resources; and expose VM instances and associated physical resources to other management systems.

[0294] VNFM 1406 manages VNF 1408. VNF 1408 can be used to execute EPC components / functions. VNFM 1406 manages the lifecycle of VNF 1408 and tracks the performance, faults, and security of the virtual aspects of VNF 1408. EM1410 tracks the functional performance, faults, and security of VNF 1408. Tracking data from VNFM 1406 and EM 1410 can include, for example, performance measurement (PM) data used by VIM 1402 or NFVI 1404. Both VNFM 1406 and EM 1410 can scale up / down the number of VNF 1408 in system 1400.

[0295] NFVO 1412 can coordinate, authorize, release, and occupy resources of NFVI 1404 to provide requested services (e.g., perform EPC functions, components, or slices). NM 1414 can provide a package of end-user functions with network management responsibilities, which may include network units with VNFs, non-virtualized network functions, or both (VNF management can occur via EM 1410).

[0296] Examples as described herein may include logic or components, modules, or mechanisms, or may operate on logic or components, modules, or mechanisms. A module is a tangible entity (e.g., hardware) capable of performing a specified operation and configured or arranged in a certain manner. In one example, circuitry may be arranged as a module in a specified manner (e.g., arranged internally or with respect to external entities, such as other circuitry). In one example, all or part of one or more computer systems (e.g., standalone, client, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application portions, or applications) to operate to perform the specified operation. In one example, software may reside on a communication device-readable medium. In one example, the software, when executed by the underlying hardware of the module, causes that hardware to perform the specified operation.

[0297] Therefore, the term "module" is understood to encompass tangible entities, whether those entities are physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., provisionally) configured (e.g., programmed) to operate in a specified manner or perform part or all of any of the operations described herein. Consider the example of temporarily configured modules, where it is not necessary to instantiate each module at any given time. For example, in the case where a module comprises a general-purpose hardware processor configured using software, this general-purpose hardware processor can be configured as various different modules at different times. The software can accordingly configure the hardware processor to constitute a particular module at one time and a different module at a different time.

[0298] While a nontransitory computer-readable medium or a communication device-readable medium may be discussed as a single medium as described herein, the term "communication device-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions used by a circuit to implement the described operations.

[0299] The term "communication device readable medium" can include any medium capable of storing, encoding, or carrying instructions for execution by a communication device and causing the communication device to perform any one or more of the technologies disclosed herein, or capable of storing, encoding, or carrying data structures used by or associated with such instructions. Examples of non-limiting communication device readable media can include solid-state memory, as well as optical and magnetic media. Specific examples of communication device readable media can include: non-volatile memory, such as semiconductor memory devices (e.g., EPROM, EEPROM) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; RAM; and CD-ROM and DVD-ROM disks. In some examples, a communication device readable medium can include a non-transitory communication device readable medium. In some examples, a communication device readable medium can include a communication device readable medium that is not a transient propagating signal.

[0300] Commands can also be sent or received via a communication network using a network interface device and a transmission medium, utilizing any of several transmission protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), HTTP, etc.). Examples of communication networks include local area networks (LANs), wide area networks (WANs), packet data networks (e.g., the Internet), mobile phone networks (e.g., cellular networks), Plain Old Telephone Service (POTS) networks, and wireless data networks (e.g., those referred to as…). The IEEE 1002.11 standard family, known as This includes standards such as the IEEE 1002.16 family of standards, the IEEE 1002.15.4 family of standards, the LTE family of standards, the Universal Mobile Telecommunications System (UMTS) family of standards, or peer-to-peer (P2P) networks, etc. In one example, a network interface device may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas to connect to a communication network. In one example, a network interface device may include multiple antennas to communicate wirelessly using single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO) technologies. In some examples, a network interface device may utilize multi-user MIMO technology for wireless communication. The term "transmission medium" should be understood to include any intangible medium capable of storing, encoding, or carrying instructions for execution by a communication device, and includes digital or analog communication signals or other intangible media that facilitate communication of such software.

[0301] Embodiments may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a computer-readable storage device that can be read and executed by at least one processor to perform the operations described herein. Computer-readable storage media may include any non-transitory mechanism for storing information in a machine-readable (e.g., computer-readable) form. For example, computer-readable storage media may include read-only memory (ROM), RAM, disk storage media, optical storage media, flash memory devices, and other storage devices and media. Some embodiments may include one or more processors and may be configured via instructions stored on the computer-readable storage device.

[0302] While embodiments have been described with reference to specific exemplary examples, it will be understood that various modifications and changes may be made to these embodiments without departing from the broader scope of this disclosure. Therefore, the specification and drawings should be considered illustrative rather than restrictive. The accompanying drawings, which form a part of this document, illustrate specific embodiments in which the subject matter may be realized by way of illustration, not limitation. The illustrative embodiments have been described in sufficient detail to enable those skilled in the art to implement the teachings disclosed herein. Other embodiments may be utilized and derived from them, thereby allowing structural and logical substitutions and changes to be made without departing from the scope of this disclosure. This “Detailed Description” section should therefore not be construed in a limiting sense, and the scope of the various embodiments is defined only by the appended claims and their full equivalents.

[0303] While specific embodiments have been illustrated and described herein, it should be understood that any arrangement intended to achieve the same purpose may replace the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of the various embodiments. Those skilled in the art will clearly recognize, upon reading the above description, combinations of the above embodiments and other embodiments not specifically described herein.

[0304] In this document, as is common in patent documents, the term "a" is used to include one or more, independent of any other instance or use of "at least one" or "one or more". In this document, the term "or" is used to refer to a non-exclusive "or", such that "A or B" includes "A but not B", "B but not A", and "A and B", unless otherwise indicated. In this document, the terms "comprising" and "in which" are used as concise English equivalents to the corresponding terms "including" and "wherein". Furthermore, in the appended claims, the terms "comprising" and "including" are open-ended; that is, a system, UE, article, composition, formulation, or process that includes other elements besides those listed after such terms in the claims is still considered to fall within the scope of the claims. Additionally, in the appended claims, the terms "first", "second", "third", etc., are used merely as labels and are not intended to impose numerical requirements on their objects.

[0305] This abstract of disclosure is provided to comply with 37 C. FR § 1.72(b), which requires that the reader quickly determine the nature of the technical disclosure. It is submitted under the understanding that it is not intended to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen in the foregoing Detailed Description section, various features are grouped together in a single embodiment for the purpose of simplification. This approach disclosed should not be construed as reflecting an intention to claim embodiments requiring more features than expressly recited in each claim. Rather, as reflected in the appended claims, the inventive subject matter resides in fewer than all features of a single disclosed embodiment. Therefore, the appended claims are incorporated herein by reference into the Detailed Description section, wherein each claim stands alone as a separate embodiment.

Claims

1. A method for operating a new radio NR node, comprising: Generate the first message; Transmit the first message to another node; as well as In response to the first message, a second message is received from the other node, wherein a bit in the initial octet of the second message indicates the highest successful delivery PDCP protocol data unit (PDU) sequence number (SN) in the second message, and when the bit is set to "1", the receiving includes processing the highest successful delivery PDCP PDU SN in the second message.

2. The method according to claim 1, wherein the NR node includes a secondary node, and wherein the other node includes a primary node MN.

3. The method of claim 1, wherein downlink DL user data accessed by the NR node is used to generate the first message, and the DL user data includes the highest successfully delivered PDCP PDU SN.

4. The method of claim 3, wherein the DL user data message includes a DL discard field based on the highest successfully delivered PDCPPDU SN, the DL discard field indicating a sequence number up to which all NR PDCP PDUs, including the sequence number, should be discarded by the other node, and wherein the DL user data message is transmitted from the NR node to the other node.

5. The method of claim 1, wherein the NR node includes a node that hosts NR PDCP operations.

6. The method according to claim 5, further comprising: Access flow control data; The flow control data is used to generate a flow control configuration update; Initiate the transmission of the flow control configuration update to the other node; as well as Process the flow control configuration update confirmation from the other node.

7. The method of claim 6, wherein the flow control data includes report polling parameters.

8. The method of claim 7, wherein the report polling parameter instructs the NR node hosting the NR PDCP operation to request a downlink DL delivery status report.

9. A method for operating a network node, comprising: Receive the first message from the new radio NR node; as well as In response to receiving the first message, a second message is transmitted to the NR node, wherein a bit in the initial octet of the second message indicates the presence of a highest successful delivery PDCP protocol data unit (PDU) sequence number (SN) in the second message, and when the bit is set to "1", the bit instructs the NR node to process the highest successful delivery PDCP PDU SN in the second message.

10. The method of claim 9, wherein the first message includes a first PDU type and the second message includes a second PDU type.

11. The method of claim 10, wherein the second message includes a parameter indicating the highest transmission NR PDCP SN.

12. The method of claim 11, wherein the second message includes a parameter indicating the transmitted status associated with the highest transmission NRPDCP SN.

13. The method of claim 10, wherein the second message includes a parameter indicating the highest retransmission NR PDCP SN.

14. The method of claim 13, wherein the second message includes a parameter indicating the state associated with the highest retransmission NRPDCP SN.

15. The method of claim 9, wherein downlink DL user data accessed by the NR node is used to generate the first message, and the DL user data includes the highest successfully delivered PDCP PDU SN.

16. The method of claim 15, wherein the DL user data message includes a DL discard field based on the highest successfully delivered PDCP PDU SN, the DL discard field indicating a sequence number up to which all NR PDCP PDUs, including the sequence number, should be discarded by another node, and wherein the DL user data message is transmitted from the NR node to the other node.

17. An electronic device comprising: At least one processor is configured to cause a new radio NR node to perform the method according to any one of claims 1-8.

18. An electronic device comprising: At least one processor is configured to cause a network node to perform the method according to any one of claims 9-16.

19. A non-transitory machine-readable storage medium storing program instructions executable by one or more processors of a new radio NR node to perform the method according to any one of claims 1-8.

20. A non-transitory machine-readable storage medium storing program instructions executable by one or more processors of a network node to perform the method according to any one of claims 9-16.

Images