NR user plane signaling controlled triggering of PDCP replication
Patent Information
- Application Number
- JP2023080910
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2019-02-21
- Filing Date
- 2023-05-16
- Publication Date
- 2025-04-25
- Estimated Expiration
- 2039-02-21
AI Technical Summary
Existing data duplication (DD) methods in dual connectivity (DC) scenarios are inefficient, leading to unnecessary bandwidth occupation and reduced throughput due to improper timing of data duplication activation and deactivation, which can result in call drops and resource wastage.
Implementing a method for controlling data duplication by sending feedback information from distributed units (DUs) to the control unit (CU) via in-band NR user-plane signaling, allowing the CU to make informed decisions on when to activate or deactivate DD based on radio quality, congestion, and other metrics.
This approach ensures that data duplication is triggered only when necessary, conserving bandwidth and improving data delivery reliability and retention by aligning DD with actual radio conditions.
Smart Images

Figure 00000019_0000 
Figure 00000020_0000 
Figure 00000021_0000
Abstract
Description
[Technical Field]
[0001] The present invention relates to communication systems, such as wireless communication networks, and in particular to controlling the use of data duplication (DD) for user equipment (UE) served simultaneously by two or more distributed transmission units (DUs). [Background technology]
[0002] Figure 1 shows the 5G Radio Access Network (RAN), or NG-RAN, architecture described in 3GPP TS38.401, v.0.3.0. The NG-RAN consists of a set of gNBs connected to the 5G Core (5GC) through an NG logical interface, where the gNBs can be considered base stations for the NG-RAN. The gNBs can support frequency division duplexing (FDD), time division duplexing (TDD), or dual-mode operation. The gNBs can be interconnected through an Xn logical interface. The gNBs can consist of a gNB central unit (gNB-CU) and gNB distributed units (gNB-DUs). The gNB-CU and gNB-DUs are connected via an F1 logical interface. One gNB-DU is connected to only one gNB-CU. For resiliency, a gNB-DU can be connected to multiple gNB-CUs depending on the implementation. Note that a "gNB" can be understood as a logical node, and a logical node can be implemented in one or several physical nodes. For example, one or several gNB-DUs forming part of a given gNB may be implemented in hardware that is physically separated (in some cases by a large distance) from each other and / or from the gNB-CU. In the following description, the gNB-CU and gNB-DU may sometimes be referred to simply as the "CU" and "DU," respectively.
[0003] The NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture, i.e., the NG-RAN logical nodes and the interfaces between the NG-RAN logical nodes, are specified as part of the RNL. For each NG-RAN interface (NG, Xn, F1), the relevant TNL protocols and functionality are specified. The TNL provides services for user plane transport and signaling transport. In an NG-Flex configuration, each gNB is connected to all Access and Mobility Functions (AMFs) within an AMF area. The AMF area is specified in 3GPP TS23.501.
[0004] In the case of NG-RAN, the NG and Xn-C interfaces for a gNB consisting of a gNB-CU and a gNB-DU terminate at the gNB-CU. In the case of E-UTRAN New Radio - Dual Connectivity (EN-DC), the S1-U and X2-C interfaces for a gNB consisting of a gNB-CU and a gNB-DU terminate at the gNB-CU. The gNB-CU and the connected gNB-DU are only visible to other gNBs and 5GC as a gNB.
[0005] The architecture in Figure 1 can be expanded by splitting the gNB-CU into two entities, for example, one gNB-CU serving the user plane and hosting the Packet Data Convergence Protocol (PDCP) protocol, and one gNB-CU-CP serving the control plane and hosting the PDCP and Radio Resource Control (RRC) protocols. The gNB-CU-CP and gNB-CU-UP are logical entities and can be implemented in the same or different physical units.
[0006] In a dual connectivity or multi-connectivity scenario (hereinafter collectively referred to as DC), data to a UE may be sent to at least two Radio Link Control (RLC) entities located in one or more DUs connected to a CU. Thus, data arriving at a CU may be sent via either DU, but in some cases it is beneficial to send duplicated data, i.e., the same upper layer data, via both RLC entities. This is known in the existing art as data duplication, hereinafter referred to as DD.
[0007] DD can also be implemented in carrier aggregation (CA) scenarios, where one or more RAN nodes deliver traffic to a UE by aggregating carrier resources. In this case, multiple logical channels can be set up on the aggregated carrier resources, and the aggregated carrier resources can be hosted by a single DU. DD is implemented on such multiple logical channels toward the UE.
[0008] The CU ensures that data sent from higher layers is appropriately divided between the two DUs based on the data handling capacity of each leg. For example, in a DC scenario, if data is being sent on both legs and data transmission is balanced, the UE will receive data from both DUs in approximately order. However, data transmission from the two DUs to the UE can never be perfectly synchronized; therefore, the UE is equipped with a reordering buffer so that data can arrive from both legs slightly out of order but still be delivered to higher layers in order. This functionality in the UE ensures that there is no need for any DD as long as the data transmission from both legs is reasonably well synchronized and the buffers in both DUs are balanced. However, in practice, this is difficult to achieve and is a problem that can arise in DC scenarios. Summary of the Invention
[0009] A problem with existing solutions is that while DD in Data Center (DC) is a known method for improving data throughput and connectivity, it is recognized that the logic for determining when to perform DD must be based on appropriate and timely input; otherwise, DD may be used too frequently, leading to unnecessary DD occupying valuable bandwidth in the transport network and air interface. Alternatively, if used too sparingly, DD usage can lead to reduced throughput when data is held up due to in-order delivery requirements, or to dropped calls when a DU with important data is unable to send the important data to the UE due to poor radio or congestion conditions (and DD is not performed on other legs to alleviate the situation). Similarly, in CA, it is currently not possible to determine when replication should start and when replication should stop due to degradation of radio quality on a logical channel.
[0010] Embodiments of the present invention provide suitable metrics to be sent from the DU to the CU to trigger DD. Methods for conveying this information on the interface between the CU and DU are also described. For example, this information can be conveyed via in-band signaling in NR user plane data frames, as outlined below. The functionality described herein is beneficial in 5G dual connectivity scenarios involving higher frequencies with limited coverage, and includes fast methods for activating and deactivating DD.
[0011] In an exemplary deployment in which the CU is divided into a user plane part (CU-UP) and a control plane part (CU-CP) connected via a standard interface (i.e., the E1 interface specified in TS38.46x), information is conveyed from the DU to the CU-UP. Based on this information, the CU-UP may make a decision regarding when to activate or deactivate DD. The CU-UP may merge information about different DUs and / or different nodes (eNBs and / or NG-RAN nodes) to make the decision. As an example, the CU-UP may receive data replication information (DDI) regarding radio quality on multiple logical channels used to replicate data, where the radio quality is sufficiently good for one channel but poor for another channel. This may prompt a decision not to trigger replication because data can be reliably received by the UE via only one channel transmission. Alternatively, the radio quality may be poor for both channels, in which case the CU-UP may decide to initiate DD, thus increasing the likelihood that the UE will receive the data accurately.
[0012] Also, note that the CU-UP may indicate the result of its decision on whether to activate or deactivate the DD to the CU-CP. This may help the CU-CP adjust the UE configuration, for example, via RRC signaling. For example, if the CU-UP activates a DD and communicates this to the CU-CP, the CU-CP may refrain from issuing an RRC configuration towards the UE that sets the DD to "inactive."
[0013] In a similar manner, the CU-CP may inform the CU-UP of the RRC configuration for a DD issued to the UE. For example, the CU-CP may have configured the UE with a DD as "inactive." In this case, the CU-CP should communicate this information to the CU-UP so that the CU-UP does not initiate a DD towards the UE, which would result in the UE monitoring only one logical channel and therefore not receiving duplicated data, resulting in wasted resources.
[0014] One advantage of the embodiment is that suitable information for triggering DD can be communicated from the DU to the CU to provide a good basis for decision logic in the CU regarding when to trigger DD. This results in additional advantages. One advantage is that DD will be triggered only when necessary, thereby saving valuable TN and air interface bandwidth. As a result, less redundant data will be generated by unnecessary DD. Another advantage is that DD will be triggered advantageously when poor radio conditions that justify DD are identified, thereby improving the sustainability and reliability of data delivery.
[0015] 2 illustrates NR user plane in-band signaling with a CU 202 and two DUs 204, 206. A solution for utilizing in-band NR user plane signaling according to embodiments described herein can ensure that DD triggering information can be conveyed conveniently and with minimal overhead compared to other more time-consuming procedures, such as RRC procedures.
[0016] According to some embodiments, a method in one or more network nodes of a wireless communication system for controlling usage of a DD for a UE simultaneously served by two or more DUs includes receiving feedback information from one or more of the DUs, and also includes determining whether to activate a DD for transmission to the UE based on the feedback information.
[0017] According to some embodiments, one or more network nodes of a wireless communication system comprise a communication circuit element and a processing circuit element operatively associated with the communication circuit element for controlling use of a DD for a UE served simultaneously by two or more DUs. The processing circuit element is configured to receive feedback information from one or more of the DUs. The processing circuit element is also configured to determine, based on the feedback information, whether to activate a DD for transmission to the UE.
[0018] Further aspects of the present invention are directed to apparatus, computer program products or computer-readable storage media corresponding to functional implementations of the above-summarized methods and the above-summarized apparatus and wireless devices.
[0019] Of course, the present invention is not limited to the above features and advantages, and those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings. [Brief explanation of the drawings]
[0020] [Figure 1] FIG. 1 is a block diagram showing the overall NG architecture. [Figure 2] FIG. 1 illustrates NR user plane in-band signaling with two DUs, used for some embodiments. [Figure 3] FIG. 2 is a block diagram of a control unit, according to some embodiments. [Figure 4] FIG. 1 illustrates an example of a gNB-CU split into two entities, according to some embodiments. [Figure 5] FIG. 1 illustrates a method performed by a control unit, according to some embodiments. [Figure 6] 1 is a table illustrating new protocol data unit (PDU) Type 2 data replication information according to some embodiments. [Figure 7]1 is a block diagram of a wireless access point according to some embodiments. [Figure 8] FIG. 1 illustrates an exemplary communication system, according to some embodiments. [Figure 9] FIG. 1 is a generalized block diagram of a host computer communicating with user equipment via a base station over a partially wireless connection, according to some embodiments. [Figure 10] 1 is a flowchart illustrating a method implemented in a communication system including a host computer, a base station, and user equipment. [Figure 11] 1 is a flowchart illustrating a method implemented in a communication system including a host computer, a base station, and user equipment. [Figure 12] 1 is a flowchart illustrating a method implemented in a communication system including a host computer, a base station, and user equipment. [Figure 13] 1 is a flowchart illustrating a method implemented in a communication system including a host computer, a base station, and user equipment. [Figure 14] FIG. 2 is a block diagram illustrating a functional implementation of a control unit, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION
[0021] The embodiments described herein provide for sending a suitable metric from the DU to the CU to trigger data replication (DD).
[0022] In one embodiment, the DD control function resides in the CU and uses feedback information from the DU to determine when to activate DD. This information to the CU can be conveyed by any of the protocols connecting the CU and the DU. The NR user plane protocol specified in 3GPP TS38.425 can also be used.
[0023] The CU evaluates feedback information received from one or more Radio Link Control (RLC) entities for the bearer. The evaluation may include feedback as well as other input parameters available in the CU, such as configured thresholds, Quality of Service (QoS) attributes, and performance and load related information. The evaluation result determines whether a DD shall be triggered. Details related to the signaling and examples of different information elements are described below.
[0024] NR user plane frame for data replication signaling New PDU types may be added to 3GPP TS38.425 to convey the information elements described below. In the current standard, PDU type 0 and PDU type 1 are already used, and the new PDU type Data Replication Information may use the next available PDU type, e.g., 2. As an example, by utilizing the four bits after the PDU type field, 16 different types of DD triggering information element Data Replication Information (DDI) may be defined. Alternatively, the field specifying the DD triggering information may be of different sizes, if necessary. The sizes of the different DDIs may be either predetermined or fixed, or, in another embodiment, one of the octets in the frame contains a length indicator as described in the table shown in FIG. 6. It may also be beneficial to add an octet following the DDI information that determines the subtype of the information contained in the DDI. An example of this would be the DDI radio quality subtypes Signal-to-Noise Ratio (SNR), Channel Quality Indicator (CQI), and Carrier-to-Interference (C / I). The above are just examples of different ways to convey DD information from a DU to a CU, and one skilled in the art will recognize that the fields can be structured in other ways to convey DD triggering information as described below.
[0025] The table in FIG. 6 is only an exemplary embodiment, and other combinations of data fields may be used to convey DD triggering information. One alternative is to use the DL Data Delivery Status (PDU Type 1) as specified in 3GPP TS38.425. Alternatively, use a cause report flag and a cause value to signal DD-related information, and alternatively, define a new DD flag for the DL Data Delivery Status (PDU Type 1) and thus convey the information element. Another alternative is to utilize reserved or spare bits or other "PDU Type" values and subfields. Furthermore, those skilled in the art will also recognize other alternatives, such as utilizing a currently unused value in the GTP-U "Next Extension Header" field.
[0026] 3 shows one embodiment of a network node that may operate according to these techniques as a control unit 10. The control unit 10, such as a gNB-CU, may be connected to and control a wireless access point (e.g., a gNB-DU). The control unit 10 includes communication circuitry 18 for communicating with the DU or wireless access point and with other devices in the core network (e.g., 5GC).
[0027] Control unit 10 further includes processing circuitry 12 operatively associated with communication circuitry 18. In an exemplary embodiment, processing circuitry 12 comprises one or more digital processors 22, such as one or more microprocessors, microcontrollers, digital signal processors (DSPs), field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), application specific integrated circuits (ASICs), or any mixture thereof. More generally, processing circuitry 12 may comprise fixed circuitry or programmable circuitry, the latter being specifically configured via execution of program instructions that implement the functionality taught herein.
[0028] Processing circuitry 12 also includes or is associated with storage 24, which in some embodiments stores one or more computer programs 26 and, optionally, configuration data 28. Storage 24 provides non-transitory storage for computer programs 26 and may comprise one or more types of computer-readable media, such as disk storage, solid-state memory storage, or any mixture thereof. As non-limiting examples, storage 24 comprises any one or more of SRAM, DRAM, EEPROM, and FLASH memory.
[0029] Generally, storage 24 comprises one or more types of computer-readable storage media that provide non-transitory storage of computer programs 26 and any configuration data 28 used by control unit 10. Here, "non-transitory" means permanent, semi-permanent, or at least temporarily persistent storage, and encompasses both long-term storage in non-volatile memory and storage in working memory, for example, for program execution.
[0030] As mentioned above, the gNB-CU may be divided into two entities. It includes one gNB-CU-UP, which serves the user plane and hosts the PDCP protocol, and one gNB-CU-CP, which serves the control plane and hosts the PDCP and RRC protocols. These two entities are shown in FIG. 4 as the control plane 402 and the user plane 404 located together in the same unit, where signaling may be internal. FIG. 4 shows both the control plane 402 and the user plane 404 entities in the control unit 10 as if they were located together in the same unit of a network node. In other embodiments, the user plane 404 may be located outside the unit in which the control plane 402 resides, or even in a separate network node. Without regard to the exact configuration, the processing circuitry 12 may be considered to be the processing circuitry necessary to perform the techniques described herein, regardless of whether the processing circuitry 12 is located together in one unit or whether the processing circuitry 12 is distributed in some manner.
[0031] In some embodiments, processor(s) 22 of processing circuitry 12 may execute a computer program 26 stored in storage 24, the computer program 26 configuring processor(s) 22 to control use of a DD for a UE served simultaneously by two or more DUs. Processing circuitry 12 is configured to receive feedback information from one or more of the DUs and determine, based on the feedback information, whether to activate a DD for transmission to the UE.
[0032] The processing circuit element 12 of the example control unit 10 of one or more network nodes is also configured to implement a corresponding method 500 for controlling use of DD for UEs. The method 500 is shown in Figure 5 and includes receiving feedback information from one or more of the DUs (block 502) and determining, based on the feedback information, whether to activate DD for transmission to the UE (block 504).
[0033] In some embodiments, the feedback information includes, and the determining is based on, an SNR for a link between the UE and each DU, a CQI for the link between the UE and each DU, a Reference Signal Received Power (RSRP) for the link between the UE and each DU, a Reference Signal Received Quality (RSRQ) for the link between the UE and each DU, and / or an average Received Signal Strength Indicator (RSSI) for the link between the UE and each DU. The feedback information may be reported per channel.
[0034] In some cases, the feedback information includes load and / or congestion information for each DU, and the determining is based on the load and / or congestion information. The determining may be based on an evaluation of the load and / or congestion information for all of two or more DUs.
[0035] The feedback information may include hybrid automatic repeat request (HARQ) information and / or retransmission information for each DU, and the determining may be based on the HARQ information and / or retransmission information for each DU. The feedback information may also include latency and / or packet age information for each DU, and the determining may be based on the latency and / or packet age information for each DU. The feedback information may include packet loss information for each DU, and the determining may be based on the packet loss information for each DU. In some embodiments, the feedback information is received via in-band signaling in one or more user plane data frames.
[0036] The method 500 may include activating a DD for transmission to a UE via two or more DUs. The activating may include sending one or more configuration messages to the UE to indicate that the DD is active.
[0037] Data Replication Information There are many different metrics that are all useful for determining whether a DD should be triggered, and some suitable information elements are described herein. Note that this description is not exhaustive and only contains examples. Within the proposed frame structure (see Figure 6), it is possible to define new fields in the DDI frame as needed.
[0038] It should be noted that each of the information elements described herein can be used as the sole trigger or can be combined and weighted with one or more of the information elements described below as triggering conditions for when to start and stop DD. It should also be noted that the means for conveying information as either a numerical value, a range, or coded is also applicable to the other metrics described below.
[0039] Additionally, information elements outlined as part of the DDI can be used to change the logical channel configuration over which replicated traffic is sent. For example, a UE may be configured with two logical channels over which replicated traffic is sent. One of these channels is configured as primary, so that when replication is deactivated, traffic is transmitted only on the primary channel. The DDI allows the CU to reconfigure the primary logical channel if the DDI indicates that a different logical channel configuration would better fulfill the primary role. This may occur if the DDI indicates that the primary logical channel is often prone to poor radio quality, while the secondary logical channel enjoys good radio quality.
[0040] Wireless quality information Poor radio conditions can be used to determine that it is beneficial to start DD. Conversely, if the radio conditions improve above a certain threshold, this can be a trigger to stop DD. The information can either be in the form of one or more numeric values, conveyed as a range of values, or coded as very poor, poor, fair, good, and very good, etc.
[0041] Examples of suitable Radio Quality Information sub-type information elements are SNR, CQI, RSRP, RSRQ, non-standardized (vendor-specific) signal-to-interference-plus-noise ratio (SINR), average RSSI, and average UE and / or network-performed measurements.
[0042] It should be noted that the above information elements may be reported for each channel to capture differences in the radio environment between different channels.
[0043] Congestion / Load Information High congestion situations can be used to determine that it is beneficial to initiate DD. Conversely, if the congestion level falls below a certain threshold, this can be a trigger to stop DD. Congestion information can be in the form of, for example, a percentage of total cell or node resource capacity, number of users or bearers, throughput per user or bearer, or other measure of capacity.
[0044] Different congestion / load situations between legs may trigger the activation / deactivation of DD depending on where they occur. For example, if there is high congestion / load on the TN link, this may trigger the deactivation of DD to reduce the load on the TN link. If the congestion / load on the radio interface becomes high for one or both RLC instances, this may trigger the deactivation of DD to reduce the load on the air interface. If the congestion / load on the air interface becomes high for one of the two RLC instances, DD may be triggered to reduce the overall latency.
[0045] HARQ Information A number of retransmissions and / or HARQ failures per time unit can be used to determine whether it is beneficial to start or stop DD. Conversely, if HARQ retransmissions fall below a certain threshold, this can be a trigger to stop DD.
[0046] RLC information A number of retransmissions and / or HARQ failures per time unit can be used to determine that it is beneficial to start DD. Conversely, if RLC retransmissions fall below a certain threshold, this can be a trigger to stop DD.
[0047] Rate difference If there is a significant difference in throughput between connected DUs, this can be a reason to start DD. Conversely, if the throughput rates become even and fall below a certain threshold, this can be a trigger to stop DD.
[0048] Latency and PDU Age If there is a significant difference in latency or packet age in the buffer contents of the connected DUs, this can be a reason to start DD. Conversely, if the latency or packet age evens out and falls below a certain threshold, this can be a trigger to stop DD.
[0049] Packet Loss Rate Packet loss on one of the transport links can be a reason to initiate DD to increase the reliability of packet delivery, mainly in scenarios where different RLC entities do not share the same transport.
[0050] Rate and Throughput Variations If the rate or throughput variation is high for at least one RLC instance, this should trigger DD as there is a high probability that the latency for at least one leg will be low when the other leg is high.
[0051] FIG. 6 shows an example frame of what may be the new PDU Type 2 Data Replication Information, and the following may be an example of what may be described in a section of TS38.425: 5.5.3 Encoding of Information Elements in a Frame 5.5.3.1 PDU Types Description: PDU type indicates the structure of the NR user plane frame. This field takes the value of the PDU type it identifies, i.e. "0" for PDU type 0. The PDU type is in bits 4 to 7 in the first octet of the frame. Value range: {0 = DL user data, 1 = DL data delivery status, 2 = Data replication information, 3-15 = Reserved for future PDU type extensions} Field length: 4 bits It should be noted that the DDI information can be conveyed to the node responsible for activating or deactivating data duplication in any available PDU type sent from a node capable of retrieving information about radio quality. As an example, another PDU type to be used can be a general uplink (UL) PDU type. As a non-limiting example, the DDI can be sent from the gNB-DU to the gNB-CU, from the gNB-DU to the LTE eNB, or from the LTE eNB to the gNB-CU. The following may also be an example of what may be described in a section of TS38.425: 5.5.3.X Data Replication Information Description: This field specifies a subtype for the Data Replication Information PDU type specified in section 5.5.3.1. Value range: {0 = Radio Quality, 1 = HARQ Information, 2 = RLC Information, 3 = Congestion / Load Information, ..., X~15 = Reserved for future data replication information extensions} Value range: (0~15). Field length: 4 bits. 5.5.3.Y Data Replication Subtype Description: This field specifies a subtype for the Data Replication Information PDU type specified in section 5.5.3.1. Value range: {If Data Replication Info = 0; 0 = Signal-to-Noise Ratio, 1 = Average SINR......X~15 = Reserved for future Data Replication subtype extensions} {If Data Replication Info = 1; 0 = HARQ failure, 1 = HARQ retransmission......X~15 = reserved for future Data Replication subtype extensions} Value range: (0~15). Field length: 4 bits. 5.5.3.2 Spares Description: The spare field is set to '0' by the sender and should not be interpreted by the receiver. This field is reserved for later versions. Value range: (0~2n-1). Field length: n bits. 5.5.3.Z Presence of Length Indicator Description: This parameter indicates whether the frame header is followed by an octet containing the frame length indicator. Value range: {0 = length indicator octet absent, 1 = length indicator octet present}. Field length: 1 bit. 5.5.3.24 Spare Expansion Description: The spare extension field shall not be sent. The receiver should be able to receive the spare extension. The spare extension should not be interpreted by the receiver, as additional new fields may be added in place of the spare extension in later versions of this document. The spare extension may be an integer number of octets carrying new fields or additional information; the maximum length (m) of the spare extension field depends on the PDU type. Value range: 0~2m*8-1. Field length: 0 to m octets. For the PDU types specified in this document, m=4.
[0052] Next, some additional observations and suggestions are described. In RAN2, using a Medium Access Control Command Element (MAC CE) to activate / deactivate UL PDCP replication can start / stop replication over the air interface more rapidly and with less signaling overhead compared to RRC reconfiguration. Such a scheme can adapt to large variations in the radio channel, especially in high-frequency deployments, i.e., frequent changes between poor and good status. Specifically, if the DU discovers that the channel status is temporarily poor, it can use the MAC CE to activate UL PDCP replication.
[0053] However, signaling a command from the DU to the CU-CP and then finally from the CU-CP to the CU-UP does not appear to improve the overall signaling delay. Therefore, it may be determined that signaling a replication activation / deactivation instruction from the DU to the CU-CP does not improve the latency for activation and deactivation. In other words, it should be recognized that F1-C signaling of data replication activation / deactivation from the gNB-DU to the CU-CP does not improve the latency for dynamic replication handling. Furthermore, it is believed that the gNB-DU shall not signal an assertive instruction to activate / deactivate data replication to the CU. This is because whether replication is required depends on several factors outside the control of a single gNB-DU. One factor may be the load on the gNB-DU involved in data replication. If the load on the gNB-DU hosting the primary logical channel increases, this may be a sign that replication needs to be activated. If the load on one of the gNB-DUs involved in the replication increases (and leads to congestion), this may be a sign to exclude replication on this node. Another factor may be the radio link quality on other gNB-DU links. Good or poor radio quality on a given radio link may be a trigger for activating / deactivating replication. Another factor may be the amount of traffic that needs to be scheduled to the UE. For example, if the amount of traffic is limited, a single transmission may be sufficient even if the radio conditions are not perfect.
[0054] For the above reasons, it would be much more useful if the gNB-DU, instead of providing the decision to activate or deactivate data replication (which is a decision that is in any case up to the CU to make), provided information that could help the CU better determine, and even predict, whether data replication should be activated or not.
[0055] Such information may be in different forms, for example, the gNB-DU may provide radio quality information to the gNB-CU in the form of CQI measurements, the gNB-DU may provide load information to the gNB-DU, or the gNB-DU may provide a generalized indication of factors affecting radio link quality, which may be, for example, an enumerated value representing a general radio link quality measure. This information from the gNB-DU would help the gNB-CU make a much more informed decision regarding whether to enable replication. In short, it is recognized that it would be much more beneficial to have the gNB-DU signal radio link quality information to the gNB-CU that would help the gNB-CU make a better decision regarding whether to activate or deactivate data replication.
[0056] Another issue is how to signal such assistance information. To reduce signaling delays, this information may be signaled over the UP protocol, according to some embodiments. That is, signaling radio link quality information over the UP, i.e., from the gNB-DU to the CU-UP, may be much more delay-efficient. To help the gNB-CU make more reliable and faster decisions about when to activate / deactivate data replication, the involved gNB-DU should signal radio link quality information to the CU-UP via the UP.
[0057] This may be the only way to make the potentially required signaling from the gNB-DU to the gNB-CU for data replication activation / deactivation useful, since radio link quality information may generally be useful for the gNB-CU to anticipate decisions regarding radio link management (e.g., traffic switching between radio legs). Also, it may be the responsibility of the gNB-CU to gather sufficient information (such as RRC measurements) to make reliable data replication activation / deactivation decisions.
[0058] 7 illustrates an exemplary DU, shown as a wireless access point 30, which may correspond to the control unit 10. The wireless access point 30 may be a network node operating as a serving node and may be known as or comprise part of a gNB, such as a gNB-DU. The wireless access point 30 includes communication interface circuitry 38 for communicating with other nodes of the same or various types. For example, the wireless access point 30 may cooperate with a remote or cloud-based processing element that performs at least some of the network-side processing described herein.
[0059] Wireless access point 30 communicates with wireless devices operating in the network via antenna 34 and transceiver circuitry 36. Transceiver circuitry 36 may include transmitter circuitry, receiver circuitry, and associated control circuitry, which collectively are configured to transmit and receive signals in accordance with one or more radio access technologies, such as 5G, to communicatively couple wireless devices to the network.
[0060] In one or more embodiments, processing circuitry 32 comprises one or more digital processors 42, such as one or more microprocessors, microcontrollers, DSPs, FPGAs, CPLDs, ASICs, or any mixture thereof. More generally, processing circuitry 32 may comprise fixed or programmable circuitry, where programmable circuitry is specifically configured via execution of program instructions that implement the functionality taught herein, or may comprise some mixture of fixed and programmed circuitry.
[0061] Processing circuitry 32 also includes or is associated with storage 44, which in some embodiments stores one or more computer programs 46 and, optionally, configuration data 48. Storage 44 provides non-transitory storage for computer programs 46 and may comprise one or more types of computer-readable media, such as disk storage, solid-state memory storage, or any mixture thereof. As non-limiting examples, storage 44 comprises any one or more of SRAM, DRAM, EEPROM, and FLASH memory.
[0062] In some embodiments, the processor 42 of the processing circuit element 32 may execute a computer program 46 stored in the storage 44, the computer program 46 configuring the wireless access point 30 (e.g., gNB-DU) to operate under the control of a control unit (e.g., gNB-CU), such as the control unit 10, the control unit including a split control plane / user plane architecture that may be used to implement the techniques described above.
[0063] 8 illustrates a communication system including a communication network 810, such as a 3GPP-type cellular network, comprising an access network 811, such as a gNB-RAN, and a core network 814 (e.g., 5GC), in accordance with various embodiments. The access network 811 comprises multiple base stations 812a, 812b, 812c, such as gNBs or other types of wireless access points, each defining a corresponding coverage area 813a, 813b, 813c. Each base station 812a, 812b, 812c can be connected to the core network 814 via a wired or wireless connection 815. A first UE 891 located in the coverage area 813c wirelessly connects to or is configured to be paged by the corresponding base station 812c. A second UE 892 in the coverage area 813a can be wirelessly connected to the corresponding base station 812a. Although multiple UEs 891, 892 are shown in this example, the disclosed embodiments are equally applicable to situations where only one UE is in the coverage area or where only one UE is connected to the corresponding base station 812.
[0064] The communications network 810 is itself connected to a host computer 830, which may be embodied in standalone server, cloud-implemented server, distributed server hardware and / or software, or as a processing resource in a server farm. The host computer 830 may be owned or controlled by a service provider, or may be operated by or on behalf of the service provider. The connection 821, 822 between the communications network 810 and the host computer 830 may extend directly from the core network 814 to the host computer 830 or may proceed through an optional intermediate network 820. The intermediate network 820 may be one of a public network, a private network, or a hosted network, or a combination of two or more of them; the intermediate network 820 may be a backbone network or the Internet, if any; in particular, the intermediate network 820 may comprise two or more subnetworks (not shown).
[0065] The communication system of FIG. 8 as a whole enables connectivity between one of the connected UEs 891, 892 and a host computer 830. The connectivity may be described as an over-the-top (OTT) connection 850. The host computer 830 and the connected UEs 891, 892 are configured to communicate data and / or signaling via the OTT connection 850 using the access network 811, the core network 814, any intermediate networks 820, and possible further infrastructure (not shown) as intermediaries. The OTT connection 850 may be transparent in the sense that the involved communication devices through which the OTT connection 850 passes are unaware of the routing of the uplink and downlink communications. For example, the base station 812 may not, or need not, be informed regarding the past routing of an incoming downlink communication involving data originating from the host computer 830 that is to be forwarded (e.g., handed over) to the connected UE 891. Similarly, the base station 812 does not need to be aware of the future routing of outgoing uplink communications originating from the UE 891 and destined for the host computer 830 .
[0066] An exemplary implementation of the UE, base station, and host computer described in the previous paragraph, according to one embodiment, will now be described with reference to FIG. 9. In communication system 900, host computer 910 comprises hardware 915, including communication interface 916 configured to set up and maintain wired or wireless connections with interfaces of different communication devices of communication system 900. Host computer 910 further comprises processing circuitry 918, which may have storage and / or processing capabilities. In particular, processing circuitry 918 may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. Host computer 910 further comprises software 911, which is stored in or accessible by host computer 910 and executable by processing circuitry 918. Software 911 includes a host application 912. The host application 912 may be operable to provide services to a remote user, such as a UE 930 connecting via an OTT connection 950 that terminates at the UE 930 and the host computer 910. In providing services to the remote user, the host application 912 may provide user data that is transmitted using the OTT connection 950.
[0067] The communications system 900 further includes a base station 920 provided in the communications system, the base station 920 comprising hardware that enables the base station 920 to communicate with the host computer 910 and the UE 930. The hardware may include a communications interface for setting up and maintaining wired or wireless connections with interfaces of different communications devices of the communications system 900, as well as a wireless interface for setting up and maintaining at least a wireless connection 970 with a UE 930 located in a coverage area (not shown in FIG. 9 ) served by the base station 920. The communications interface may be configured to facilitate a connection 960 to the host computer 910. The connection 960 may be direct, or the connection 960 may pass through a core network of the communications system (not shown in FIG. 9 ) and / or one or more intermediate networks outside the communications system. In the illustrated embodiment, the base station 920 includes a control unit 10 (e.g., a gNB-CU), which controls a wireless access point 30 (e.g., a gNB-DU), which may communicate with and perform handovers for the UE 930. Details of the control unit 10 and the wireless access point 30 were previously described with reference to Figures 3 and 7.
[0068] The communication system 900 further includes the previously mentioned UE 930. The hardware 935 of the UE 930 may include a wireless interface 937 configured to set up and maintain a wireless connection 970 with a base station serving a coverage area in which the UE 930 is currently located. The hardware 935 of the UE 930 further includes processing circuitry 938, which may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The UE 930 further includes software 931, which is stored on or accessible by the UE 930 and executable by the processing circuitry 938. The software 931 includes a client application 932. The client application 932, with the support of the host computer 910, may be operable to provide services to a human or non-human user via the UE 930. On the host computer 910, a running host application 912 may communicate with a running client application 932 via an OTT connection 950 that terminates at the UE 930 and the host computer 910. In providing services to a user, the client application 932 may receive request data from the host application 912 and provide user data in response to the request data. The OTT connection 950 may transfer both the request data and the user data. The client application 932 may interact with the user to generate the user data that the client application 932 provides.
[0069] It should be noted that the host computer 910, base station 920, and UE 930 shown in Figure 9 may be equivalent to the host computer 830, one of the base stations 812a, 812b, and 812c, and one of the UEs 891 and 892, respectively, of Figure 8. That is, the inner workings of these entities may be as shown in Figure 9, and separately, the surrounding network topology may be that of Figure 8.
[0070] 9, the OTT connection 950 is depicted abstractly to show communication between the host computer 910 and the user equipment 930 via the base station 920, without explicit reference to intermediate devices and the precise routing of messages through those devices. The network infrastructure may determine the routing, and the network infrastructure may be configured to hide the routing from the UE 930, from the service provider operating the host computer 910, or both. While the OTT connection 950 is active, the network infrastructure may also make decisions to dynamically change the routing (e.g., based on load balancing considerations or reconfiguration of the network).
[0071] The wireless connection 970 between the UE 930 and the base station 920 follows the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of the OTT service provided to the UE 930 using the OTT connection 950, of which the wireless connection 970 forms the final segment. More precisely, the teachings of these embodiments provide suitable information for triggering DD that can be communicated from the DU to the CU to provide a good basis for decision logic in the CU regarding when to trigger DD. This results in additional advantages. One advantage is that DD will be triggered only when necessary, thereby saving valuable TN and air interface bandwidth. As a result, less redundant data will be generated by unnecessary DD. Another advantage is that DD will be triggered advantageously when poor radio conditions that warrant DD are identified, thereby improving the sustainability and reliability of data delivery. This results in improved performance for users of the RAN.
[0072] Measurement procedures may be provided for the purpose of monitoring data rates, latency, and other factors that one or more embodiments improve upon. There may further be optional network functionality for reconfiguring the OTT connection 950 between the host computer 910 and the UE 930 in response to fluctuations in the measurement results. The measurement procedures and / or the network functionality for reconfiguring the OTT connection 950 may be implemented in software 911 of the host computer 910 or in software 931 of the UE 930, or both. In embodiments, sensors (not shown) may be deployed in or associated with communication devices through which the OTT connection 950 passes, and the sensors may participate in the measurement procedures by providing values of the monitored quantities exemplified above or other physical quantities from which the software 911, 931 may calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 950 may include message formats, retransmission settings, preferred routing, etc.; the reconfiguration need not affect the base station 920, and the reconfiguration may be unknown or imperceptible to the base station 920. Such procedures and functionality are known and may be implemented in the art. In some embodiments, the measurements may involve proprietary UE signaling that facilitates the host computer 910 measuring throughput, propagation time, latency, etc. The measurements may be implemented in software 911, 931 causing messages, particularly empty or "dummy" messages, to be sent using the OTT connection 950 while the software 911, 931 monitors propagation times, errors, etc.
[0073] FIG. 10 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to FIGS. 8 and 9. For simplicity of this disclosure, only a drawing reference to FIG. 10 is included in this section. In a first step 1010 of the method, the host computer provides user data. In an optional sub-step 1011 of the first step 1010, the host computer provides the user data by executing a host application. In a second step 1020, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 1030, the base station transmits the user data carried in the host computer initiated transmission to the UE, according to the teachings of the embodiments described throughout this disclosure. In an optional fourth step 1040, the UE executes a client application associated with the host application executed by the host computer.
[0074] FIG. 11 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to FIGS. 8 and 9. For simplicity of this disclosure, only a drawing reference to FIG. 11 is included in this section. In a first step 1110 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides the user data by executing a host application. In a second step 1120, the host computer initiates a transmission carrying the user data to the UE. The transmission may proceed via the base station in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 1130, the UE receives the user data carried in the transmission.
[0075] FIG. 12 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to FIGS. 8 and 9. For simplicity of this disclosure, only a drawing reference to FIG. 12 is included in this section. In an optional first step 1210 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second step 1220, the UE provides user data. In an optional sub-step 1221 of the second step 1220, the UE provides the user data by executing a client application. In a further optional sub-step 1211 of the first step 1210, the UE executes a client application that provides the user data in response to the received input data provided by the host computer. In providing the user data, the executed client application may further take into account user input received from the user. Regardless of the particular manner in which the user data is provided, the UE initiates transmission of the user data to the host computer in an optional third sub-step 1230. In a fourth step 1240 of the method, the host computer receives user data transmitted from the UE according to the teachings of the embodiments described throughout this disclosure.
[0076] According to some embodiments, a method implemented in a communication system including a host computer, a base station, and a UE includes providing user data at the host computer and initiating a transmission carrying the user data to the UE over a cellular network including the base station. The base station implements a method for controlling use of a DD for a UE simultaneously served by two or more DUs, the method including receiving feedback information from one or more of the DUs and determining, based on the feedback information, whether to activate a DD for transmission to the UE. The method may further include transmitting the user data at the base station. The user data may be provided at the host computer by executing a host application, and the method further includes executing, at the UE, a client application associated with the host application.
[0077] According to some embodiments, a method implemented in a communication system including a host computer, a base station, and a UE includes receiving, at the host computer, from the base station, user data originating from a transmission received by the base station from the UE. The base station implements a method for controlling use of a DD for a UE simultaneously served by two or more DUs, the method including receiving feedback information from one or more of the DUs and determining, based on the feedback information, whether to activate a DD for transmission to the UE. The method may include receiving, at the base station, the user data from the UE. The method may further include initiating, at the base station, transmission of the received user data to the host computer.
[0078] According to some embodiments, a communication system including a host computer comprises processing circuitry configured to provide user data and a communication interface configured to forward the user data to a cellular network for transmission to a UE, the cellular network comprising a base station having communication circuitry and processing circuitry. The processing circuitry of the base station is configured to control use of DD for UEs simultaneously served by two or more DUs by receiving feedback information from one or more of the DUs and determining, based on the feedback information, whether to activate the DD for transmission to the UE. The communication system may further include a base station. The communication system may further include a UE, the UE configured to communicate with the base station. The processing circuitry of the host computer may be configured to execute a host application thereby to provide user data, and the UE may comprise processing circuitry configured to execute a client application associated with the host application.
[0079] According to some embodiments, a communication system includes a host computer having a communication interface configured to receive user data originating from a transmission from a UE to a base station, the base station configured to control use of a DD for UEs simultaneously served by two or more DUs, the base station including an air interface and processing circuitry. The processing circuitry of the base station is configured to receive feedback information from one or more of the DUs and determine, based on the feedback information, whether to activate a DD for transmission to the UE. The communication system may further include a base station. The communication system may further include a UE, the UE configured to communicate with the base station. The host computer may include processing circuitry configured to execute a host application, and the UE may be configured to execute a client application associated with the host application, thereby providing user data to be received by the host computer.
[0080] Figure 13 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to Figures 8 and 9. For simplicity of this disclosure, only a drawing reference to Figure 13 is included in this section. In an optional first step 1310 of the method, the base station receives user data from the UE in accordance with the teachings of embodiments described throughout this disclosure. In an optional second step 1320, the base station initiates transmission of the received user data to the host computer. In a third step 1330, the host computer receives the user data carried in a transmission initiated by the base station.
[0081] 14 illustrates an exemplary functional module or circuit architecture, as may be implemented in one or more network nodes of a wireless communication system, for controlling the use of DD for a UE simultaneously served by two or more DUs. The illustrated embodiment at least functionally includes a receiving module 1402 for receiving feedback information from one or more of the DUs, and a determining module 1404 for determining, based on the feedback information, whether to activate DD for transmission to the UE.
[0082] In particular, modifications and other embodiments of the disclosed invention(s) will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention(s) is not to be limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the present disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
Claims
1. 1. A method (500) in one or more network nodes (10) of a wireless communication system for controlling the use of data duplication (DD) for user equipment (UE) served simultaneously by two or more distributed transmission units (DU), said method (500) comprising: receiving feedback information from one or more of the DUs (502); determining whether to activate DD for transmission to the UE based on the feedback information (504); A method (500) comprising:
2. 2. The method (500) of claim 1, wherein the feedback information includes radio quality information, and wherein the determining (504) is based on the radio quality information.
3. The feedback information is a signal-to-noise ratio (SNR) for the link between the UE and each DU; a Channel Quality Indicator (CQI) for the link between the UE and each DU; Reference Signal Received Power (RSRP) for the link between the UE and each DU; Reference Signal Received Quality (RSRQ) for the link between the UE and the respective DU; and an average received signal strength indicator (RSSI) for the link between the UE and each DU; 3. The method (500) of claim 1 or 2, wherein said determining (504) is based on any one or more of:
4. The method (500) of claim 2 or 3, wherein the feedback information is reported per channel.
5. 5. The method (500) of claim 1, wherein the feedback information includes load and / or congestion information for the respective DUs, and wherein the determining (504) is based on the load and / or congestion information.
6. 6. The method (500) of claim 5, wherein said determining (504) is based on an evaluation of load and / or congestion information for all of said two or more DUs.
7. 7. The method (500) of claim 1, wherein the feedback information includes hybrid automatic repeat request (HARQ) information and / or retransmission information for the respective DUs, and wherein the determining (504) is based on the HARQ information and / or retransmission information for the respective DUs.
8. 8. The method (500) of claim 1, wherein the feedback information includes latency and / or packet age information for the respective DUs, and wherein the determining (504) is based on the latency and / or packet age information for the respective DUs.
9. 9. The method (500) of claim 1, wherein the feedback information includes packet loss information for the respective DUs, and wherein the determining (504) is based on the packet loss information for the respective DUs.
10. The method (500) of any one of claims 1 to 9, wherein the feedback information is received via in-band signaling in one or more user plane data frames.
11. 11. The method (500) of claim 1, further comprising activating DD for transmission to the UE via the two or more DUs.
12. 12. The method (500) of claim 11, wherein the activating includes sending one or more configuration messages to the UE to indicate that DD is active.
13. 1. One or more network nodes (10) of a wireless communication system for controlling the use of data duplication (DD) for user equipment (UE) served simultaneously by two or more distributed transmission units (DU), the one or more network nodes (10) comprising: a communication circuit element (18); and processing circuitry (12) operatively associated with said communication circuitry (18), said processing circuitry (12) comprising: receiving feedback information from one or more of the DUs; determining whether to activate DD for transmission to the UE based on the feedback information; One or more network nodes (10) configured to:
14. The one or more network nodes (10) of claim 13, wherein said feedback information comprises radio quality information, and said determining (504) is based on said radio quality information.
15. The feedback information is a signal-to-noise ratio (SNR) for the link between the UE and each DU; a Channel Quality Indicator (CQI) for the link between the UE and each DU; Reference Signal Received Power (RSRP) for the link between the UE and each DU; Reference Signal Received Quality (RSRQ) for the link between the UE and the respective DU; and an average received signal strength indicator (RSSI) for the link between the UE and each DU; 15. The one or more network nodes (10) according to claim 13 or 14, comprising any one or more of:
16. The one or more network nodes (10) according to claim 14 or 15, wherein said feedback information is reported per channel.
17. 17. The one or more network nodes (10) of claim 13, wherein the feedback information includes load and / or congestion information for the respective DUs, and wherein the determining is based on the load and / or congestion information.
18. 18. The one or more network nodes (10) of claim 17, wherein said determining is based on an evaluation of load and / or congestion information for all of said two or more DUs.
19. 19. The one or more network nodes (10) of claim 13, wherein the feedback information includes Hybrid Automatic Repeat Request (HARQ) information and / or retransmission information for the respective DU, and wherein the determining is based on the HARQ information and / or retransmission information for the respective DU.
20. 20. The one or more network nodes (10) of claim 13, wherein the feedback information includes latency and / or packet age information for the respective DUs, and wherein the determining is based on the latency and / or packet age information for the respective DUs.
21. 21. The one or more network nodes (10) of claim 13, wherein the feedback information includes packet loss information for the respective DUs, and wherein the determining is based on the packet loss information for the respective DUs.
22. 22. The one or more network nodes (10) according to any one of claims 13 to 21, wherein said feedback information is received via in-band signaling in one or more user plane data frames.
23. 23. The one or more network nodes (10) of any one of claims 13 to 22, wherein the processing circuit element (12) is configured to activate DD for transmission to the UE via the two or more DUs.
24. 24. The one or more network nodes (10) of claim 23, wherein the processing circuit element (12) is configured to activate DD by sending one or more configuration messages to the UE to indicate that DD is active.
25. 1. A non-transitory computer-readable medium (24) storing a computer program (26) for controlling the use of data duplication (DD) for user equipment (UE) served simultaneously by two or more distributed transmission units (DU), the computer program (26), when executed by at least one processor (12) of one or more network nodes (10) of a wireless communication system, causing the one or more network nodes (10) to: receiving feedback information from one or more of the DUs; determining whether to activate DD for transmission to the UE based on the feedback information; A non-transitory computer-readable medium (24) comprising instructions to cause the
26. 13. A computer program (26) comprising instructions that, when executed on at least one processing circuit (12), cause the at least one processing circuit (12) to perform the method (500) of any one of claims 1 to 12.
27. 27. A carrier containing the computer program (26) of claim 26, said carrier being one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (24).
28. 13. A network node (10) of a wireless communication system, said network node (10) being connected to a plurality of wireless access points, said network node (10) being adapted to perform the method (500) of any one of claims 1 to 12.
29. A control unit (10) of a wireless communication system, the control unit (10) being connected to a plurality of wireless access points, the control unit (10) being adapted to perform the method (500) of any one of claims 1 to 12.