WO2024164179A1

WO2024164179A1 - Linked pdcp entities for ue assistance with data transmissions

Info

Publication number: WO2024164179A1
Application number: PCT/CN2023/075011
Authority: WO
Inventors: Nathan Edward Tenny; Tao Chen; Ming-Yuan Cheng; Chun-Fan Tsai
Original assignee: Mediatek Inc.
Priority date: 2023-02-08
Filing date: 2023-02-08
Publication date: 2024-08-15

Abstract

This disclosure describes methods of configuration and processing for linked entities of a protocol layer at a remote UE and a relay UE. A first entity of the protocol layer may be embodied at the remote UE. The remote UE may transfer, to the relay UE, a configuration for a second entity of the protocol layer. Subsequent traffic for the protocol layer, in the form of PDUs of an upper protocol layer for transmission in the uplink or SDUs of a lower protocol layer received in the downlink, results in normal processing of the traffic at the first entity of the protocol layer, a notification of the traffic to the second entity of the protocol layer, and the execution of processing steps for the traffic at the second entity of the protocol layer, so that the two entities of the protocol layer remain in a synchronised state. The protocol layer may, for example, be a PDCP or SDAP layer. A control PDU of the protocol layer may be transferred from the remote UE to the relay UE, or from the relay UE to the remote UE, allowing the two entities of the protocol layer to process the same control PDUs and remain in a synchronised state.

Description

LINKED PDCP ENTITIES FOR UE ASSISTANCE WITH DATA TRANSMISSIONS

FIELD

This disclosure relates to wireless communications, and specifically to a method of implementation for a plurality of wireless devices to aggregate traffic across a short-range interface for communication with a cellular network.

BACKGROUND

In a wireless communication environment, achievable communication data rates may be limited by several factors. As one example, communication between a transmitter and a receiver may be limited by the quality of a wireless link; such examples are often seen in practical deployments as reduced data rates for user equipments (UEs) at the edge of a serving cell, where degradation of the signal between a UE and a base station reduces the achievable data rate. As another example, a device may have intrinsic limitations that affect its transmitted data rate, such as a maximum transmission power, limitations on the design of an antenna, and so on. In such a case, a first UE experiencing limitations on the data rate with which it can communicate with a network may enlist the assistance of a second UE with its communications. In some cases, the two UEs may be treated as a single entity by some or all layers of a protocol stack in a serving network.

To facilitate communication with a network, a first UE may communicate with a second UE on a short-range interface. The short-range interface may use various radio technologies, such as a third generation partnership project (3GPP) sidelink communication technology, WiFi radio, or other short-range communication technologies. Alternatively, the short-range interface may use wired transport, such that certain protocol layers of a protocol stack designed for wireless communication are carried over the wired interface. From the perspective of the network, the first UE may be a remote UE and the second UE may be a relay UE, allowing the network to maintain awareness of both devices while relying on the radio communications of the second UE to supplement or replace direct radio communication with the first UE. It is noted that the relaying feature in 3GPP Release 17 is specified with the assumption that the remote and relay UEs communicate using a 3GPP sidelink; however, the relaying architecture may be extended to support communication between the remote and relay UEs using a non-3GPP technology such as WiFi.

Starting from 3GPP Release 18, the new radio (NR) radio technology can be used for a relaying enhancement that applies multi-path communication, in which a remote UE communicates with a base station through both a direct path (radio communication directly between the remote UE and the base station) and an indirect path (radio communication between the remote UE and a relay UE, and between the relay UE and the base station, allowing forwarding of communications between the remote UE and the base station using the relay UE as an intermediary) . The relaying architecture may use either a “layer 2 relay” or a “layer 3 relay” construction. In the layer 3 relay architecture, the remote UE is not separately visible to the base station on the indirect path; it appears as a radio bearer of the relay UE. On the other hand, in the layer 2 relay architecture, the base station maintains protocol stacks for both the remote UE and the relay UE, with a linkage between them at upper protocol layers. In a typical implementation within the base station, lower layers of a protocol stack instantiated in a context for the relay UE, such as physical (PHY) , medium access control (MAC) , and radio link control (RLC) layers, are associated with upper layers of a protocol stack instantiated in a context for the remote UE, such as packet data convergence protocol (PDCP) and service data adaptation protocol (SDAP) layers. Communications to and from the remote UE are processed by the lower layers associated with the relay UE and by the upper layers associated with the remote UE.

This disclosure is directed to describing methods to adapt the 3GPP layer 2 relay architecture to support multi-path relaying in which the remote and relay UEs communicate via a non-3GPP radio technology.

SUMMARY

The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

In an aspect of the disclosure, a method operable in a first UE of configuring a protocol entity for a first protocol layer is provided. The method comprises receiving, from a base station, a first configuration for a first instance of the protocol entity; establishing the first instance of the protocol entity according to the configuration; and sending, to a second UE on a short-range interface, a second configuration for a second instance of the protocol entity. The protocol entity may be a PDCP entity or an SDAP entity. The method may further comprise receiving, from a second protocol layer above the protocol entity, a PDU of the second protocol layer; processing, in the protocol entity, the PDU of the second protocol layer to produce a PDU of the first protocol layer; delivering, to a third protocol layer below the protocol entity, a notification of receipt for the PDU of the second protocol layer; and sending, to the second UE via the short-range interface, the PDU of the second protocol layer.

In another aspect of the disclosure, a method operable in a first UE of processing in a protocol entity is provided. The method comprises receiving, from a second UE on a short-range interface, a PDU notification for the protocol entity; and executing, in the protocol entity, one or more processing steps corresponding to the processing of a PDU by the protocol entity.

In another aspect of the disclosure, a method operable in a first UE of processing in a protocol entity is provided. The method comprises receiving, from a protocol layer above the protocol entity, a PDU notification; and executing, in the protocol entity, one or more processing steps corresponding to the processing of a PDU by the protocol entity.

In another aspect of the disclosure, a method operable in a first UE of processing a control PDU of a protocol layer is provided. The method comprises receiving, from a base station, the control PDU; sending, to a second UE on a short-range interface, the control PDU; and executing, at a protocol entity of the protocol layer, one or more processing steps corresponding to the processing of a control PDU of the protocol layer.

In another aspect of the disclosure, a method operable in a first UE of processing a control PDU of a protocol layer is provided. The method comprises receiving, from a second UE on a short-range interface, the control PDU; and executing, at a protocol entity of the protocol layer, one or more processing steps corresponding to the processing of a control PDU of the protocol layer.

To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating an example of relay and remote UE operation with multi-path communication.

FIG. 2 is a diagram illustrating an example of protocol stacks for layer 2 relaying with multi-path communication.

FIG. 3 is a diagram illustrating an example of protocol stacks for layer 2 relaying with multi-path communication in which linked PDCP entities are instantiated in a remote UE and a relay UE.

FIG. 4 illustrates an example of configuring linked PDCP entities and processing data for transmission according to a security configuration.

FIG. 5 illustrates an example of processing two SDAP PDUs through linked PDCP entities for transmission to a gNB.

FIG. 6 illustrates an example of handling a PDCP control PDU received by one of a pair of linked PDCP entities.

FIG. 7 illustrates is a diagram illustrating an example of protocol stacks for layer 2 relaying with multi-path communication.

DETAILED DESCRIPTION

The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

Several aspects of telecommunication systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

Figure 1 shows an example of relay and remote UE operation with multi-path communication. A first (remote) UE operates in the service area of a base station of a communication system, such as the gNB in the figure. A second (relay) UE also operates in the service area of the base station, and the first and second UEs are connected by a short-range interface. The first UE communicates directly with the gNB over an airlink (a “direct path” for communication) , and the first UE also communicates indirectly with the gNB by using the second UE as an intermediary (an “indirect path” for communication) . The short-range interface may use any of several radio technologies, including 3GPP sidelink, WiFi, Bluetooth, and so on, in addition to the possibility of using wired communication.

Figure 2 shows a set of exemplary user-plane protocol stacks for a layer 2 relaying architecture between a remote UE and a gNB via a relay UE, taking into account multi-path communication. The protocol stacks for each UE comprise a service data application protocol (SDAP) layer, a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, a medium access control (MAC) layer, and a physical (PHY) layer, in addition to the transport stack of the short-range interface (which is not shown in detail in the figure, and whose contents will depend on what wireless or wired technology is used for transport over the short-range interface) . Additional protocol layers (not shown) may be carried above the layers in the figure, such as internet protocol (IP) over SDAP. The UEs are connected to one another via a short-range protocol stack, which is not shown in detail in the figure. The arrows show the paths taken by a protocol data unit (PDU) of the SDAP layer over the direct path (left side) and the indirect path (right side) . On the left-hand path, for data to be transmitted in the uplink direction, an SDAP PDU is passed to the PDCP layer as a PDCP service data unit (SDU) and processed by the PDCP layer to produce a PDCP PDU. The PDCP PDU is passed to the RLC layer, thence to the MAC layer and to the PHY layer, and the resulting lower-layer PDU (s) is/are transmitted over the air to the base station. At the base station, the received communication is passed upward through the layers of the protocol stack in order, up to the SDAP layer. This transmission path is the legacy behaviour for user-plane data communication in NR.

On the right-hand path in Figure 2, the same SDAP PDU is delivered to the PDCP layer, and a “split” occurs at the PDCP layer: The PDCP PDU produced by processing of the SDAP PDU is delivered to the short-range protocol stack for transmission over the air to the relay UE. The behaviour of the short-range protocol stack depends on the radio technology in use for the short-range link, but it should be symmetrical between the remote and relay UEs, so that after the communication is processed through the short-range stack at the relay UE, the top layer of the short-range stack emits a copy of the PDCP PDU. The relay UE then passes the PDCP PDU to the lower layers of the NR stack (RLC/MAC/PHY) for transmission to the gNB according to legacy transmission procedures. The resulting transmission arrives at the gNB, and the gNB processes it through the lower layers of the NR stack (PHY/MAC/RLC) , resulting in a PDCP PDU identical to the PDCP PDU that was delivered to the short-range stack by the PDCP layer of the remote UE. In accordance with the layer 2 relaying architecture, the gNB passes the PDCP PDU to the PDCP layer associated with the remote UE. The PDCP layer of the remote UE processes the PDCP PDU and passes a PDCP SDU (equiv. SDAP PDU) to the SDAP layer, where the original SDAP PDU is reconstructed (and typically passed to upper layers for further processing as user-plane data of the remote UE) . The steps are reversed for downlink data.

The procedures shown in Figure 2 may not be feasible for all UE implementations. For example, it is common for the security functions of PDCP (ciphering/deciphering and integrity protection) to be implemented in hardware rather than software, and in a particular implementation, it may be difficult or impossible for the remote UE to extract a PDCP PDU for delivery to the short-range stack after security processing in hardware has taken place. An alternative approach may be to implement security in software, but for high-data-rate services, the speed of software processing may not be adequate to support applying security to the data in real time. Thus, an alternative protocol design at the remote and relay UEs may be preferable, in which data are passed between the remote UE and the relay UE in the clear, before processing by PDCP. For example, when preparing an uplink packet for transmission to the gNB via the relay UE, the remote UE may transfer an SDAP PDU instead of a PDCP PDU to the relay UE, and PDCP processing may take place at the relay UE.

Figure 3 shows an exemplary set of user-plane protocol stacks for modified layer 2 relaying, in which PDCP is instantiated at both the remote and relay UEs. As in Figure 2, the arrows show the processing for user-plane data transferred between the remote UE and the gNB via the direct path (left) and the indirect path (right) . On the left-hand path, processing is unchanged from Figure 2. On the right-hand path, however, and taking the uplink direction as an example, the remote UE delivers an SDAP PDU to the short-range stack for transmission to the relay UE. The remote UE transmits the SDAP PDU to the relay UE via the layers of the short-range stack, and the relay UE processes the resulting transmission through the layers of the short-range stack to reconstruct the SDAP PDU. The relay UE passes the SDAP PDU to a PDCP layer for processing, and the data proceed through the protocol stack to be transmitted to the gNB. Upon reception of the transmission, the gNB processes the received data through the lower layers (PHY/MAC/RLC) of a protocol stack associated with the relay UE, producing an RLC SDU (equiv. PDCP PDU) , which is then passed to a PDCP entity associated with the remote UE, in accordance with the layer 2 relaying architecture. The PDCP entity associated with the remote UE processes the PDCP PDU to reconstruct the original SDAP PDU, which may then be passed to upper layers in accordance with normal processing of user-plane data. The steps are reversed for downlink data.

The procedure shown in Figure 3 raises two specific problems related to the shift of PDCP functionality from the remote UE to the relay UE. The first problem is that the relay UE is required to perform PDCP processing, potentially including security processing, for the remote UE. In legacy operation, the relay UE does not have access to security parameters for the remote UE (e.g., the keys used for ciphering/deciphering and integrity processing) , so it cannot perform this security processing. The second problem is that the two PDCP entities in the remote and relay UEs must be kept in a synchronised state, because from the perspective of the gNB, there is only a single PDCP entity associated with the remote UE. The gNB does not intrinsically have the capability to maintain separate PDCP operations for two entities that both handle data for the same radio bearer of the remote UE.

A general solution to both problems would be to redesign the relaying architecture so that the split occurs at SDAP instead of PDCP. In such a redesign, the gNB would maintain separate PDCP entities for the relay UE and the remote UE, and data would split/converge at the SDAP layer. An uplink transmission would, for instance, be security-protected by PDCP in the remote UE for the direct path and in the relay UE for the indirect path, and the corresponding PDCP processing would take place in the gNB’s context for the remote UE for the direct path and in the gNB’s context for the relay UE for the indirect path. However, this general solution is not aligned with 3GPP’s standardised operation; it requires specific support in violation of the standard at both of the UEs and at the gNB. This deficiency may be considered prohibitive for such a solution.

Figure 4 shows an example of a message flow for a simple solution to the first problem mentioned above, the relay UE’s inability to perform security procedures for the remote UE. The principle of the solution is to share the PDCP security parameters between the remote UE and the relay UE. In step 1 of the figure, the remote UE, the relay UE, and the gNB collectively establish a layer 2 relaying configuration according to legacy procedures. In step 2, the remote UE passes a set of PDCP parameters to the relay UE, including security parameters; the security parameters may comprise one or more keys, one or more algorithm identifiers, and any other information needed for the PDCP security procedures to operate. Other PDCP parameters may be transferred as well at this step, to facilitate operation of PDCP at the relay UE; such parameters may include, for instance, a sequence number (SN) length, a discard timer configuration, header compression parameters, and any other parameters required for PDCP to operate. In step 3, the relay UE establishes a PDCP entity to process data for the remote UE; this entity may be understood as a “shadow” or “mirror” of the PDCP entity used by the remote UE for communication on the direct path. In particular, it is noted that the gNB need not be aware of the establishment or existence of this PDCP entity at the relay UE; from the gNB perspective, there is only a single PDCP entity, associated with the remote UE. After step 3, the relay UE is ready to process data for the remote UE. The subsequent steps show the processing of uplink data, and they can be reversed for the equivalent processing of downlink data.

In step 4, the remote UE delivers an SDAP PDU to the relay UE over the short-range interface, in accordance with the protocol design from Figure 3. In step 5, the relay UE performs PDCP processing according to the parameters received from the remote UE in step 2, including security processing using the keys and other security parameters belonging to the remote UE, followed by lower-layer processing (for example, through RLC, MAC, and PHY layers) according to the configuration of the relay UE itself. In step 6, the relay UE transmits the resulting data over the air to the gNB; it is noted that the transmission configuration is in line with the parameters of the relay UE with respect to the lower layers (e.g., RLC/MAC/PHY) , but with the parameters of the remote UE with respect to the PDCP layer, and in particular, the data are secured with keys belonging to the remote UE. In step 7, the gNB performs processing of the received data through the lower layers of the protocol stack (e.g., PHY/MAC/RLC) in accordance with the configuration of the relay UE, resulting in a PDCP PDU. In step 8, the gNB transfers the PDCP PDU to a PDCP entity associated with the remote UE and performs the corresponding processing; this step may include, for instance, deciphering of a packet that was ciphered with a key belonging to the remote UE. In step 9, the resulting PDCP SDU from step 8 is passed to SDAP and onward to upper layers, in accordance with legacy processing of user-plane data.

The transfer over the air of security parameters in step 2 of Figure 4 may not be acceptable under typical 3GPP security expectations. Security information (e.g., keys) belonging to the remote UE is typically maintained only in the remote UE and not transferred over the air to any other entity. One way to avoid this problem is for the gNB to configure null security at the remote UE, so that data belonging to the remote UE are not ciphered/deciphered or integrity protected. This approach may require upper-layer (e.g., application-layer) security for service data, meaning that, for example, an SDAP PDU processed by the remote UE for uplink transmission arrives with the contained data already ciphered and/or integrity protected. In this case, the PDCP parameters transferred at step 2 of Figure 4 need not include any security parameters; from the perspective of the PDCP layer, data will be transferred in the clear without security protection, but the actual user data are assumed to be protected by the application layer or other layers above the protocol stacks shown in the figures. With this modification, the procedure of Figure 4 may be applied with step 2 modified to refer to “PDCP parameters (except security) ” .

Referring again to the protocol design of Figure 3, the essential feature of the design is the presence of separate PDCP entities in the remote and relay UEs, in correspondence with a single PDCP entity in the gNB. The first PDCP entity in the remote UE and the second PDCP entity in the relay UE need to present to the gNB the illusion of being one and the same. In particular, the status of the first and second PDCP entities must be maintained in synchrony; for example, SNs must be assigned by the first and second PDCP entities in the same order that they would be assigned by a single PDCP entity instantiated at the remote UE, and PDCP SDUs must be stored and discarded in the same manner in the first and second PDCP entities. Otherwise conditions may occur that would interfere with proper processing of PDCP data, such as the same SN being assigned to two different uplink packets, or a PDCP control PDU sent by the gNB being processed by one PDCP entity and not by the other.

Figure 5 shows an exemplary message flow for the maintenance of synchronised PDCP states between the remote and relay UEs, applied to the case of uplink data transmission. The SDAP entity in the remote UE is shown as delivering two SDAP PDUs (equiv. PDCP SDUs) for transmission to the network; the first SDAP PDU, which is assigned the SN X by the PDCP entities, is transmitted on the direct path, and the second SDAP PDU, which is assigned the SN X+1 by the PDCP entities, is transmitted on the indirect path.

Steps 1a through 1d of Figure 5 comprise communication between the SDAP entity in the remote UE and two PDCP entities: a first PDCP entity in the remote UE and a second PDCP entity in the relay UE. In step 1a, the SDAP entity delivers the first SDAP PDU to the first PDCP entity for transmission on the direct path. In step 1b, the SDAP entity delivers, to the short-range protocol stack in the remote UE, a first SDAP PDU notification. The first SDAP PDU notification may comprise a copy of the first SDAP PDU, or it may comprise a notification that the first SDAP PDU was delivered without also including a copy of the first SDAP PDU. In step 1c, the short-range protocol stack in the remote UE transmits, to the short-range protocol stack in the relay UE, the first SDAP PDU notification. It is noted that this transmission step may comprise processing by multiple layers of the short-range protocol stacks, and that the actual data transmitted over the short-range interface may be modified relative to the original version of the first SDAP PDU notification; for instance, the data may be segmented or concatenated for transmission, headers of various protocol layers may be added, and so on. In step 1d, the short-range protocol stack in the relay UE delivers, to the second PDCP entity, the first SDAP PDU notification. After these steps, the first and second PDCP entities are both aware of the delivery of the first SDAP PDU, and at least the first PDCP entity holds a copy of the first SDAP PDU to be processed as a PDCP SDU.

In step 2a of Figure 5, the first PDCP entity performs PDCP processing steps on the first SDAP PDU (considered as a PDCP SDU) . The PDCP processing steps may, for instance, comprise SN assignment, header compression, and any other functions of the PDCP layer. If security is enabled for communications to and from the remote UE, the first PDCP entity may perform security processing on the first SDAP PDU. After the completion of step 2a, a first PDCP PDU is ready for onward transmission from the first PDCP entity.

In step 2b, the second PDCP entity performs PDCP processing steps relative to the first SDAP PDU (considered as a PDCP SDU) . Depending on the implementation of steps 1b, 1c, and 1d, the second PDCP entity may or may not receive an actual copy of the first SDAP PDU. The second PDCP entity may perform the steps for SN assignment, header compression, optionally security processing, and any other functions of the PDCP layer. However, in the event that the second PDCP entity has not received a copy of the first SDAP PDU, some steps may not be carried out since they lack the essential information to execute them. As one example, security processing requires a copy of the packet to be processed, and if the first SDAP PDU has not been provided to the second PDCP entity, the second PDCP entity cannot perform security processing. However, the second PDCP entity (with or without a copy of the first SDAP PDU) may perform steps that are necessary for maintenance of the state of the second PDCP entity in synchronisation with the first PDCP entity, such as SN assignment, update of internal variables such as the TX_NEXT variable, and so on. After the completion of step 2b, processing of the first SDAP PDU may terminate at the second PDCP entity; that is, in the operation shown in the figure, the second PDCP entity does not forward a PDCP PDU to other layers of a communication stack for further processing. The actions of step 2b are taken only to keep the two PDCP entities synchronised. In particular, due to maintaining their states in a synchronised condition, the first and second PDCP entities may both assign the same SN value (shown as X in the figure) to the common PDCP SDU that they both process (i.e., the first SDAP PDU considered as a PDCP SDU) .

In step 3 of Figure 5, the first PDCP entity delivers the first PDCP PDU to the lower layers of a 3GPP communication stack in the remote UE for transmission to the gNB. The lower layers may, for example, comprise RLC, MAC, and PHY layers, and the first PDCP PDU may be processed in these layers according to their normal functionality. In step 4, the lower layers transmit the data resulting from such processing over the air (for example, on a Uu interface) to the gNB, which associates the transmission with the protocol stack of the remote UE in accordance with legacy procedures. From the gNB’s perspective, the transmission appears as the result of normal processing by the remote UE of the first SDAP PDU, delivered over the direct path.

Steps 5a through 5d of Figure 5 comprise the transfer of a second SDAP PDU (equiv. PDCP SDU) to the first and second PDCP entities for transmission on the indirect path. In step 5a, the SDAP layer in the remote UE delivers the second SDAP PDU to the short-range communication protocol stack for transmission to the relay UE. In step 5b, the short-range communication protocol stack in the remote UE transmits the second SDAP PDU over the short-range interface to the relay UE, which receives the second SDAP PDU through its own short-range communication protocol stack. In step 5c, the short-range communication protocol stack in the relay UE transfers the second SDAP PDU to the second PDCP entity.

In step 5d, the SDAP entity delivers, to the first PDCP entity, a second SDAP PDU notification. As with the first SDAP PDU notification (steps 1b through 1d) described above, this notification may comprise a copy of the second SDAP PDU, or it may comprise only an indication that the second SDAP PDU is being transmitted.

In step 6a, the first PDCP entity performs PDCP processing relative to the second SDAP PDU (now considered as a PDCP SDU) . As with step 2b described above, the processing in this step may comprise a complete set of PDCP functionality carried out on a copy of the second SDAP PDU, or it may comprise a subset of PDCP functionality, such as assigning the SN and updating internal variables including TX_NEXT. The objective of this step is not to produce a PDCP PDU for transmission but to keep the state of the first PDCP entity synchronised with that of the second PDCP entity.

In step 6b, the second PDCP entity performs PDCP processing on the second SDAP PDU (now considered as a PDCP SDU) . The PDCP processing steps may, for instance, comprise SN assignment, header compression, and any other functions of the PDCP layer. If security is enabled for communications to and from the remote UE, the second PDCP entity may perform security processing on the second SDAP PDU (using security parameters associated with the remote UE that were shared from the remote UE to the relay UE at configuration of the second PDCP entity) . After the completion of step 6b, a second PDCP PDU is ready for onward transmission from the second PDCP entity.

After the completion of steps 6a and 6b, the first and second PDCP entities should be in a synchronised state with one another. In particular, the first and second PDCP entities may assign the same SN value (shown as X+1 in the figure) to the second SDAP PDU, maintain their internal variables such as TX_NEXT with matching values, and so on.

In step 7, the second PDCP entity delivers, to the lower layers of a 3GPP protocol stack in the relay UE, the second PDCP PDU. The lower layers may, for example, comprise RLC, MAC, and PHY layers; these protocol layers may process the second PDCP PDU according to their normal operations. In step 8, the lower layers in the relay UE transmit, to the gNB, the data resulting from processing the second PDCP PDU; the gNB receives this transmission and associates it with the relay UE, according to legacy communication procedures. The received communication can then be processed at the gNB as a normal communication received from the remote UE via the indirect path through the relay UE. (It is noted that after initial processing through lower layers of the 3GPP protocol stack associated with the relay UE, the gNB is expected to transfer the received data to upper layers of a protocol stack associated with the remote UE, in keeping with normal processing of communications on the indirect path. This subsequent processing is not shown in the figure. )

The foregoing examples assume that data transmission is “split” between the direct and indirect paths; that is, each SDAP PDU is destined for over-the-air transmission on one path or the other, but a single SDAP PDU will not be duplicated and transmitted on both paths. In the alternative scenario where duplication is configured for some or all of the remote UE’s data, a similar data flow may apply, with each SDAP PDU being delivered to both the first and second PDCP entities (e.g., steps 1b through 1d of Figure 5 would be replaced with the corresponding transfer of an SDAP PDU, rather than only a notification) and with both the first and second PDCP entities emitting a PDCP PDU for onward transmission. The (single) PDCP entity at the gNB may then receive both copies of the PDCP PDU, which it may recognise as being duplicated, allowing the gNB to discard one of the copies.

A similar procedure is needed when one of the UEs receives a transmission in the downlink direction. For example, if a packet with SN=Y arrives at the remote UE, the PDCP entity at the remote UE will retain the information that SN Y was received (e.g., for duplicate detection) before delivering the packet upward to the SDAP layer. If a copy of the same packet, with SN=Y, subsequently arrives at the relay UE, the PDCP entity at the relay UE will not recognise it as a duplicate and will forward it to the SDAP layer, resulting in duplicate data in upper layers. To avoid this problem, when a PDCP SDU is produced by processing a PDCP PDU at the remote UE’s PDCP entity, a notification should be sent to the relay UE’s PDCP entity, and when a PDCP SDU is produced by processing a PDCP PDU at the relay UE’s PDCP entity, a notification should be sent to the remote UE’s PDCP entity. These notifications can be substantially identical to the SDAP PDU notifications shown in Figure 5 (recalling that a PDCP SDU is equivalent to an SDAP PDU) , with an indication such as a flag in the notification that reflects whether the SDAP PDU/PDCP SDU is being sent in the uplink direction or received in the downlink direction.

The reception of a PDCP control PDU by either of the UEs requires some special handling. In legacy operation, a PDCP control PDU may (under various circumstances) be sent on either leg of a split bearer, suggesting that in multi-path relaying, a PDCP control PDU might arrive on either the direct or indirect path, depending on bearer configuration and the transmitter’s implementation. This uncertainty causes no problem for a single receiving PDCP entity. However, with the linked PDCP entities instantiated in the remote and relay UEs, it is necessary to take some steps to ensure that reception of a PDCP control PDU does not cause the two PDCP entities to become desynchronised. (As one example, a PDCP status report causes discarding of certain stored PDCP SDUs according to the content of the report; if only one of the two linked PDCP entities received a status report, it would consider the corresponding PDCP SDUs as having been received by the gNB, but the other linked PDCP entity would be unaware that they were received. Subsequently, a PDCP SDU might be considered by one PDCP entity as new data and by the other PDCP entity as a duplicate transmission, because the corresponding SN would be marked as having been received only in one of the PDCP entities. )

Figure 6 shows an exemplary flow for processing a received PDCP control PDU (CPDU) between a first PDCP entity instantiated in the remote UE and a second PDCP entity instantiated in the relay UE. In the example, the PDCP CPDU is sent to the remote UE on the direct path, but the procedure is symmetrical if it is sent via the relay UE on the indirect path or directly to the relay UE. In step 1, a gNB sends a PDCP CPDU over the air to lower layers of a communication protocol stack (for example, PHY/MAC/RLC layers) located in the remote UE. It is noted that the over-the-air transmission actually comprises one or more lower-layer PDUs derived from the PDCP CPDU through the normal processing of the transmission protocol stack at the gNB (not shown in the figure) . In step 2, the remote UE’s lower protocol layers deliver the PDCP CPDU to a first PDCP entity located in the remote UE. The first PDCP entity is capable of processing the received PDCP CPDU, but as noted above, additional actions are needed to keep a second linked PDCP entity in synchronisation with the first PDCP entity. Thus, in step 3, the first PDCP entity delivers the PDCP CPDU to a first short-range protocol stack located in the remote UE, for transfer to the relay UE. In step 4, the first short-range protocol stack, in accordance with its normal operation, transmits the PDCP CPDU over the air to a second short-range protocol stack located in the relay UE. In step 5, the second short-range protocol stack delivers the PDCP CPDU to a second PDCP entity located in the relay UE. Finally, in step 6, both the first PDCP entity and the second PDCP entity process the PDCP CPDU, ensuring that their states remain synchronised. For example, synchronous operation of step 6 means that if the PDCP CPDU comprises a PDCP status report, the remote and relay UEs will each interpret the same set of uplink PDCP PDUs as having been received at the gNB.

If modifications to the gNB behaviour are considered, an alternative to the processing of Figure 6 is possible. Since the gNB is aware of the relaying configuration of the remote and relay UEs, the gNB can take special actions for transmissions to these UEs. To keep the linked PDCP entities in synchronisation, the gNB may duplicate PDCP CPDUs to be transmitted to the remote UE, so that for each PDCP CPDU, a first copy of the PDCP CPDU is sent to the remote UE on the direct path and a second copy of the PDCP CPDU is sent to the relay UE as if for transmission on the indirect path. Because of the linked-PDCP architecture (as shown in Figure 3) , the second copy will be processed in the PDCP entity instantiated at the relay UE instead of being forwarded to the remote UE. Accordingly, the relay UE’s PDCP entity and the remote UE’s PDCP entity will remain synchronised, since they receive the same instructions from the duplicated PDCP CPDUs.

In an alternative gNB behaviour compatible with the example shown in Figure 6, the gNB may send PDCP CPDUs only via the direct path to the remote UE. This restriction allows some simplification of the relay UE implementation, since the relay UE’s instance of the linked PDCP entities need not implement the functionality to relay PDCP CPDUs to the remote UE. In this case, the procedure shown in Figure 6 still applies, but the complementary procedure described above, in which the PDCP CPDU comes to the relay UE and is forwarded to the remote UE, would not occur. In some embodiments, the relay UE may indicate to the gNB whether it can support relaying of PDCP CPDUs, for example, as a UE capability or via control signalling during setup of the relaying configuration.

Furthermore, the system may support a model of uplink-only relaying, in which the remote and relay UE cooperate to forward uplink traffic, but all downlink communications go via the direct path to the remote UE. In this model, PDCP CPDUs in the downlink direction are necessarily sent via the direct path to the remote UE. The remote and relay UEs may subsequently cooperate to implement the procedure shown in Figure 6 (again, without the complementary procedure in which the PDCP CPDU comes to the relay UE and is forwarded to the remote UE) .

In some UE implementations, certain functions of the SDAP layer, such as header addition, may be implemented in hardware without an external interface. Thus, the constraint described previously for the PDCP layer, in which the UE cannot retrieve a PDCP PDU after processing, may apply as well to the SDAP layer. In such a scenario, it may be necessary to implement linked SDAP entities in the remote and relay UEs in a manner similar to that described above for PDCP entities. An example of the resulting protocol stacks is shown in Figure 7.

The gNB in figure 7 may operate according to normal behaviour as reflected in 3GPP specifications. In particular, the gNB may instantiate only one PDCP entity and only one SDAP entity corresponding to the remote UE, as shown. The relay UE may instantiate a PDCP entity for the remote UE, linked to the PDCP entity instantiated in the remote UE as described previously, and the relay UE may also instantiate an SDAP entity for the remote UE, with a similar linkage to the SDAP entity instantiated in the remote UE. That is, the remote UE, after its own SDAP layer is configured, may send SDAP configuration information to the relay UE, allowing the relay UE to configure another instance of the SDAP entity associated with the remote UE. The SDAP configuration information may, for example, comprise a PDU session ID, presence indicators for SDAP headers in the uplink and/or downlink directions, a default DRB indicator, and/or one or more lists of quality-of-service (QoS) flow identifiers (QFIs) . For communication in the uplink direction, instead of forwarding SDAP PDUs via the short-range stack, as in the protocol stack configuration of Figure 3 and the corresponding flow of Figure 4, the remote UE may forward SDAP SDUs (equiv. PDUs of an overlying upper protocol layer) in a similar manner, and the SDAP SDUs may be processed in parallel at the remote and relay UEs. The overlying upper protocol layer may, for example, be an internet protocol (IP) layer. Alternatively, the SDAP layer in the remote UE may perform partial processing of SDAP SDUs and then transfer modified SDAP SDUs. As one example, the SDAP layer in the remote UE may process SDAP SDUs completely, except for adding the SDAP header, and then transfer one or more headerless SDAP PDUs via the short-range interface to the relay UE, where the header may be added in the instance of the remote UE’s SDAP entity hosted at the relay UE. Such examples have the effect of factoring the SDAP functionality into a first part (executed only in the remote UE) and a second part (executed in parallel in the remote UE for communication on the direct path and in the relay UE for communication on the indirect path) . Similarly, for communication in the downlink direction, the instance of the remote UE’s SDAP entity hosted in the relay UE may perform partial or complete processing of an SDAP PDU received from the instance of the remote UE’s PDCP entity hosted in the relay UE, followed by transferring a partially processed SDAP PDU or an SDAP SDU (equivalent to a PDU of the overlying upper layer) to the remote UE on the short-range interface.

In a system using the protocol stacks shown in Figure 7, a modified version of the flow in Figure 4 may be employed. In step 2, SDAP parameters are transferred along with PDCP parameters. In step 3, the relay UE establishes an SDAP entity as well as a PDCP entity. In step 4, the remote UE delivers either an SDAP SDU or a partially processed SDAP SDU, as described previously. In step 5, the relay UE performs SDAP processing as well as PDCP and lower-layer processing. As described previously, the SDAP processing may comprise the full functionality of the SDAP layer or only selected functions.

In a system using the protocol stacks shown in Figure 7, similar modifications to those described above may be applied to the flow of Figure 5. In steps 1a through 1d and steps 5a through 5d, the SDAP PDUs may be replaced with either SDAP SDUs or partially processed SDAP SDUs, and the notifications may be sent to an SDAP entity rather than to a PDCP entity. In steps 2a, 2b, 6a, and 6b, the remote and relay UEs may perform SDAP processing as well as PDCP processing (meaning that the corresponding columns of the figure should be understood to describe the combined SDAP and PDCP layers rather than only the PDCP layer) .

In a system using the protocol stacks shown in Figure 7, the SDAP layer at the remote UE may generate an SDAP CPDU for transmission in the uplink. In some embodiments, the SDAP CPDU may be sent via the short-range interface to the instance of the remote UE’s SDAP entity hosted at the relay UE, to keep the operation of the two instances of the SDAP entity synchronised.

It is understood that the specific order or hierarchy of blocks in the processes /flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes /flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for. ”

Claims

A method operable in a first [remote] UE of configuring a protocol entity for a first protocol layer, comprising:

receiving, from a base station, a first configuration for a first instance of the protocol entity;

establishing the first instance of the protocol entity according to the configuration; and

sending, to a second [relay] UE on a short-range interface, a second configuration for a second instance of the protocol entity.
The method of claim 1, wherein the protocol entity is a PDCP entity.
The method of claim 2, wherein the second configuration includes a security configuration.
The method of claim 3, wherein the security configuration comprises at least one key.
The method of claim 1, wherein the protocol entity is an SDAP entity.
The method of claim 1, further comprising:

receiving, by the protocol entity from a second protocol layer above the protocol entity, a PDU of the second protocol layer;

processing, in the protocol entity, the PDU of the second protocol layer to produce a PDU of the first protocol layer;

delivering, by the protocol entity to a third protocol layer below the protocol entity, a notification of receipt for the PDU of the second protocol layer; and

sending, to the second UE via the short-range interface, the PDU of the second protocol layer.
The method of claim 6, wherein the notification of receipt comprises a copy of the PDU of the second protocol layer.
A method operable in a first [relay] UE of processing in a protocol entity, comprising:

receiving, from a second [remote] UE on a short-range interface, a PDU notification for the protocol entity; and

executing, in the protocol entity, one or more processing steps corresponding to the processing of a PDU by the protocol entity.
A method operable in a first [remote] UE of processing in a protocol entity, comprising:

receiving, by the protocol entity from a protocol layer above the protocol entity, a PDU notification; and

executing, in the protocol entity, one or more processing steps corresponding to the processing of a PDU by the protocol entity.
A method, operable in a first [remote or relay] UE, of processing a control PDU of a protocol layer, comprising:

receiving, from a base station, the control PDU;

sending, to a second [relay or remote] UE, on a short-range interface, the control PDU; and

executing, at a protocol entity of the protocol layer, one or more processing steps corresponding to the processing of a control PDU of the protocol layer.
A method, operable in a first [remote or relay] UE, of processing a control PDU of a protocol layer, comprising:

receiving, from a second [relay or remote] on a short-range interface, the control PDU; and

executing, at a protocol entity of the protocol layer, one or more processing steps corresponding to the processing of a control PDU of the protocol layer.