ENHANCED USER EQUIPMENT (eUE) PROFILE DETERMINATION FOR UE-UE COLLABORATION

Abstract

A method for wireless communication of an enhanced user equipment, eUE, (190) with a radio access network, RAN, node (104) selects (512) a value of a parameter (400) associated with a profile of the eUE (190). The profile of the eUE (190) includes combined physical resources from at least two different user equipments, UEs, (102, 103). The parameter (400) of the eUE (190), although defined for each UE of the at least two different UEs, has a different value and / or definition for the eUE having the combined physical resources. The eUE (190) communicates (516) with the RAN node (104) based on a configuration of the eUE (190) corresponding to the value of the parameter (400).

Description

ENHANCED USER EQUIPMENT (eUE) PROFILE DETERMINATION FOR UE-UE COLLABORATIONFIELD OF THE DISCLOSURE

[0001] This document generally describes methods and devices operating in wireless communication systems such as (but not limited to) the ones described in fifth generation of communication networks (5G) and described in 3rdGeneration Partnership Project (3GPP) standard documents.BACKGROUND

[0002] Two or more user equipments (UEs) may pool together various physical resources for improving coverage, diversity, capacity, etc. when communicating with a radio access network (RAN) node. The two or more UEs may directly communicate with each other for establishing a collaboration (may be referred to as UE-UE collaboration), by using a sidelink (SL), direct link, or other point to point protocol, that bypasses the RAN node. As a result of the collaboration of the two or more UEs, an enhanced UE (eUE) is created. From the network’s perspective, the eUE may behave like a single UE having the combined physical resources of the two or more UEs. However, there is a need for determining and / or updating a profile of the eUE when communicating with the RAN node. The eUE profile is defined by one or more parameters that are also used between a single UE and the RAN node during their communication but will have different values and / or definitions based on the combined resources of the two or more UEs.SUMMARY

[0003] The eUE may operate like a traditional UE in the sense of its operating parameters and has a profile (which includes configuration and / or capabilities) that needs to be known by the RAN node and / or a core network (CN) element. The profile of the eUE is described by the one or more parameters, for example, a powerheadroom report, a buffer status report, a minimum processing delay capability, a beam switch delay capability, a phase noise property, a multiple input multiple output (MIMO) communication capability, etc. Other UE or network related quantities may be used for characterizing the eUE and defining its profile. The profile of the ellE may also change in time and thus, the RAN node may obtain profile updates to stay current with the status of the ellE.

[0004] The embodiments of this application introduce a signaling framework for IIE-UE collaboration using direct communication, i.e. , any type of communication that bypasses the RAN node. In addition, one or more embodiments describe communication between one of the collaborating UEs (may be referred to as primary or leader UE) that forms the eUE and the RAN node.

[0005] In one embodiment, the one or more eUE parameters that define the eUE profile are defined at the UE level, by a leader UE or collectively, by all collaborating UEs that form the eUE. In another embodiment, the one or more eUE parameters are defined by the RAN node, based on information received from the collaborating UEs that form the eUE.

[0006] The eUE may be configured to use one or more antennas from various collaborating UEs for transmitting / receiving information to / from the RAN node, further improving the MIMO communication capability of the individual UEs.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments.

[0008] FIG. 1 is a block diagram of an example wireless communication system in which a UE, a RAN node, and a CN implement the wireless communication methods according to various embodiments.

[0009] FIG. 2 is a signal diagram illustrating UE-UE collaboration for establishing an eUE and providing updated configuration and / or capabilities of the eUE to the RAN node according to various embodiments.

[0010] FIG. 3 is a signal diagram illustrating UE-UE collaboration with multiple UEs requesting permission to establish the eUE and providing updated configuration and / or capabilities of the eUE to the RAN node according to various embodiments.

[0011] FIG. 4 schematically illustrates the structure of a parameter used by the eUE to communicate with the RAN node according to various embodiments.

[0012] FIG. 5 is a flowchart of a method for determining a value of the parameter used to communicate with the RAN node and updating the value of the parameter according to various embodiments.

[0013] FIG. 6 is a flowchart of a method for determining a value of the parameter used to communicate with the eUE and updating the value of the parameter according to various embodiments.

[0014] FIG. 7 is a flowchart of a method for determining a value of the parameter used by the eUE to communicate with the RAN node and updating the value of the parameter according to various embodiments.DETAILED DESCRIPTION

[0015] Methods and devices described in this section embody techniques related to creating an eUE based on two or more UEs that directly communicate with each other. Once created, the eUE has its own profile, different from the profiles of the UEs that form the eUE. The eUE profile is shared with, or communicated to the RAN node. In some scenarios, the eUE profile may change and thus, an updated eUE profile is communicated to the RAN node. The eUE profile includes at least one of a capability or configuration of the eUE and the profile is defined by one or more parameters. The eUE includes physical elements or resources, e.g., antenna arrays, processors, buffers, etc., from the two or more UEs. Each UE that contributes one or more physical elements to the eUE has a unique ID for its own communications, and access to an additional ID, the eUE ID, that is used for eUE related communications.

[0016] The embodiment descriptions in this section refer to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The detailed descriptions do not preclude other embodiments within the scope of the appended claims. For example, instead of using one or more of a power headroomreport, a buffer status report, a minimum processing delay capability, a beam switch delay capability, a phase noise property, or a MIMO communication capability for describing the ellE profile, other parameters may be used. For simplicity, in the following, a collaboration between two UEs is considered as forming the ellE. However, the embodiments discussed in this document equally apply to any number of UEs forming the eUE.

[0017] Reference throughout this section to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

[0018] The two or more UEs forming the eUE collaborate with each other for achieving better communication with the RAN node. The collaborating UEs may communicate with each other using SL, direct link, or other radio access technologies (RATs), e.g., Wifi, bluetooth, near-field communication (NFC), or even wireline / cable connection. SL is a 5G capability that can operate in different spectrum configurations such as dedicated, in-band licensed, and unlicensed, providing the flexibility for it to be adopted in diverse settings. SL allows devices and infrastructures to connect and communicate amongst themselves, enhancing overall performance and efficiency, and this communication is achieved with or without the cellular infrastructure. The SL may also be used for extending coverage via device-to-device communication (e.g., massive Internet of Things (loT) devices such as meters, sensors, vehicles, etc.) with multi-hop mesh relays. SL (which is also called device-to-device protocol (D2D)) requires a proximity service (ProSe) function being implemented in the CN. A UE that wants to use the SL, first contacts the ProSe function through a logical interface called PC3 to get authorization and security parameters. After completing this procedure, the UE can discover other UEs with ProSe capabilities using a PC5 interface. However, the embodiments discussed herein are not limited to ProSe UEs, but may be applied, as noted above, to any other direct device to device communication that bypasses the RAN node.

[0019] The UEs collaborate to form the eUE for improving coverage, diversity, capacity, etc. when communicating with the RAN node. For example, if better coverage is desired, the collaborating UEs may pool physical resources together to achieve two antenna arrays next to each other, such that they form a larger antenna array, whose larger directivity gain may help increase the cellular coverage range. If the target is better diversity, the collaborating UEs may connect to two different cells or transmission and reception points (TRPs). After UE-UE collaboration, the eUE connects to both cells or TRPs, which provides better macro-diversity for both UEs. If the target is a higher data rate and the Simultaneous Transmission with Multiple Panels (STxMP) feature is supported, a network entity (NE) may schedule the eUE to send uplink from multiple panels, which belongs to the collaborating UEs. Therefore, a higher uplink data rate may be supported. The NE may be any part or element of the RAN node and / or CN, as later discussed.

[0020] The collaboration between the UEs forming the eUE may take place at different levels, for example, RAT level, band level, antenna level, and MIMO level. For the RAT level, a first UE of the collaborating UEs may use only cellular communication while a second UE of the collaborating UEs may use both cellular and Wifi communications. For the band level, the first UE may use the frequency range 1 (FR1 ) while the second UE may use the FR1 and frequency range 2 (FR2), where FR1 refers to the sub 6 GHz band and FR2 refers to the millimeter wave (mmWave) band (e.g., 24.25 GHz and higher). For the antennal level, the UEs can “borrow” each other’s antenna array to receive the data, i.e., the first UE may use its own antenna array and the second UE’s antenna array to send first UE data. For this case, the first UE also uses the SL to send part of the first UE data to the second UE, in anticipation of borrowing the antenna array from the second UE. For the MIMO level, multiple data streams to / from the collaborating UEs may be configured for MIMO communication enabling higher rank transmissions between the eUE and RAN. Those skilled in the art, having the benefit of this document, would be able to implement other collaboration levels between the UEs.

[0021] As the eUE is created and acts as a new UE with its own ID that is independent of the collaborating UEs IDs, the RAN node uses the profile of the eUE (i.e., capabilities and configuration) to communicate with the eUE. One or more parameters characterize or define the eUE profile. These parameters are defined based on variousmethods, for example, by the collaborating UEs, or by a leader UE, or by the eUE, or by the RAN node, or by a combination of UEs, eUE, and / or the RAN node. In one embodiment, the one or more parameters are parameters that characterize the profile of a traditional UE but their values and / or definitions are different from the individual traditional UE. Defining one or more of these parameters and updating and sharing these parameters with the RAN node are discussed after describing one communication system that supports these concepts. Other communication systems may also support these concepts.

[0022] FIG. 1 shows a possible wireless communication system 100, which includes a first UE 102, a second UE 103, a first RAN node 104, a second RAN node 106, and a CN element 110. The NE discussed above may be any of the RAN nodes 104, 106, or CN element 110, or a combination of them. The RAN nodes 104 and 106 may operate in a RAN 105 connected to the CN element 110. The CN element 110 may be implemented as an evolved packet core (EPC) 111 (i.e., non-5G system) or a 5G core (5GC) 160, for example. The CN element 110 may also be implemented as a sixth generation (6G) core in another example.

[0023] The first RAN node 104 covers a first cell 124 and a second cell 125, and the second RAN node 106 covers a cell 126 in this example. If the first RAN node 104 is a gNB, the cells 124 and 125 are new radio (NR) cells. If the first RAN node 104 is an ng- eNB or eNB, the cells 124 and 125 are evolved universal terrestrial radio access (E- UTRA) cells. The same is valid for the second RAN node 106. The cells 124, 125, and 126 may be in the same Radio Access Network Notification Areas (RNA) or different RNAs. In general, the RAN 105 can include any number of RAN nodes, and each of the RAN nodes can cover one, two, three, or any other suitable number of cells. The UEs 102 and 103 can support at least a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the RAN nodes 104 and 106. Each of the RAN nodes 104, 106 may connect to the CN element 110 via an interface (e.g., S1 or Ng interface, i.e., CN-based interface). The RAN nodes 104 and 106 may also be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting NG-RAN nodes (i.e., NG-RAN to NG-RAN interface).

[0024] Among other components, the EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data NetworkGateway (PGW) 116. SGW 112 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. PGW 116 provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. 5GC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management Function (AMF) 164, and / or a Session Management Function (SMF) 166. Each of these functions may be hosted by a corresponding processor or a common processor. Among other functionalities, UPF 162 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., AMF 164 is configured to manage authentication, registration, paging, and other related functions, and SMF 166 is configured to manage PDU sessions.

[0025] Because cells 124, 125, and 126 can partially overlap, the UE 102 can select, reselect, or hand over from one of the cells 124, 125, and 126 to another. To directly exchange messages or information (e.g., related to the handover procedure), the first RAN node 104 and second RAN node 106 may support an X2 or Xn interface, i.e. , a dedicated protocol for exchanging messages between the RAN nodes without involving the ON element 110. In addition, the RAN nodes are connected through Ng interfaces to the CN element 110, which may connect to any suitable number of RAN nodes supporting NR cells and / or EUTRA cells.

[0026] The first RAN node 104 is equipped with processing hardware 130 that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally, or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 in an example implementation includes a processor 132 configured to process data that the first RAN node 104 will transmit in the downlink (DL) direction, or process data received by the RAN node 104 in the uplink (UL) direction. The processing hardware 130 can also include a transmitter 136 configured to transmit data in the DL. The processing hardware further can include a receiver 134 configured to receive data in the UL. The processing hardware 130 can also include a storage media 138 for storing instructions that are executed by theprocessor 132. The second RAN node 106 can include generally similar components. Components 140, 142, 144, 146, and 148 of the second RAN node 106 can be similar to the components 130, 132, 134, 136, and 138, respectively.

[0027] The UE 102 is equipped with processing hardware 150 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general- purpose processors, and / or special-purpose processing units. Processing hardware 150 may include a processor 152 to process data that the UE 102 will transmit in the UL, or process data received by UE 102 in the DL. The processing hardware 150 may also include a transmitter 156 configured to transmit data in the UL. The processing hardware may further include a receiver 154 configured to receive data in the DL. The processing hardware 150 may also include a storage media 158 for storing instructions that are executed by the processor 152. The second UE 103 includes similar elements as the UE, i.e., elements 180 to 188 correspond to elements 150 to 158 of the UE 102.

[0028] FIG. 1 also shows the first and second UEs 102 and 103 forming the eUE 190. The first and second UEs 102 and 103 may establish a direct connection 194, e.g., SL or other direct communication protocol, prior to creating the eUE 190. In other embodiments, the first and second UEs 102 and 103 may establish a direct connection after approval by the RAN node. The eUE 190 uses physical elements or resources (e.g., antennas, processors, transmitters, receivers, buffers, etc.) from each of the collaborating first and second UEs 102 and 103, and acts as an independent UE. For simplicity, FIG. 1 shows only two collaborating UEs. However, more than two collaborating UEs may create the eUE 190.

[0029] In one embodiment, as illustrated in FIG. 2, the first and second UEs 102 and 103 (e.g., collaborating UEs) establish 202 a direct connection, using, for example, the 5G SL protocol, but other protocols may also be used that bypass the RAN node 104 (or any other RAN node). In this embodiment, it is assumed that the first and second UEs 102 and 103 are both in a cell served by the RAN node 104. However, the embodiments discussed herein also work for the situation in which different UEs are communicating with different RAN nodes but these UEs are close enough to establish the direct connection. The collaborating UEs 102 and 103 then request 204 approval from the NE (which can bethe corresponding RAN node of the cell, multiple RAN nodes, CN element, etc.) to form / create the ellE 190. The collaborating first and second UEs 102, 103 send their IDs in a report to the RAN node 104.

[0030] Upon approving 205 the collaboration between the first and second UEs 102 and 103, the RAN node 104 assigns 205 a unique eUE ID (e.g., radio network temporary identifier (RNTI), but also other existing or new identifiers may be used) to the eUE 190. In one embodiment, the RAN node 104 may coordinate with a CN element for determining the eUE ID. The eUE ID is sent 206 to the second UE 103 and also sent 208 to the first UE 102. This eUE ID is used by each collaborating UE for assignments and configurations (e.g., scrambling sequence for reference signals (RSs)) for the eUE 190. Note that each UE has a unique ID (e.g., RNTI) used for communicating with the RAN node. The eUE ID is used by the collaborating UEs in addition to their own ID, and the eUE ID is used exclusively for the eUE related communication. Thus, although a collaborating UE has two IDs, the two IDs are not cross used, i.e. , the ID used for its own communication is not mixed up with the eUE ID used for eUE communication with the RAN node 104. The collaborating UEs 102, 103 establish 210 the eUE 190 and associate the eUE ID with the eUE 190. For example, the eUE 190 may be established by creating a profile and associating the profile with the eUE ID.

[0031] The eUE 190 uses the profile for communicating with the RAN node 104. The profile is defined by one or more parameters, for example, a power headroom report, a buffer status report, a minimum processing delay capability, a beam switch delay capability, a phase noise property, or a MIMO communication capability. While these parameters have established definitions and values when used for a single, traditional UE, they are not defined for an eUE, which includes physical elements or resources from plural UEs. Thus, values of the one or more parameters are selected 212 at the eUE 190, based on communication with one or more of the collaborating UEs. In one variation of this embodiment, it is possible that the RAN node 104, based on communication with the collaborating UEs, selects the values of the one or more parameters, as discussed later with regard to FIG. 3. The selection step 212 is discussed later in more detail for each parameter discussed above.

[0032] The selected values of the one or more parameters may be reported to the RAN node by one or more of the collaborating UEs 102, 103. Based on the reports (e.g., UE capability reports) received by the RAN node from the collaborating UEs 102, 103, the RAN node 104 determines 21 configurations for the eUE 190 and sends these configurations (for example, as one or more parameters) to the eUE 190, e.g., in a radio resource control (RRC) message, a medium access control-control element (MAC-CE), or downlink control information (DCI). The eUE configuration may be communicated in terms of the differences from the collaborating individual UEs configurations. An eUE configuration is different from that of each individual collaborating UE. The RAN node 104 and eUE 190 communicate 216 based on the eUE configuration. In some scenarios, the eUE configuration may be updated 218 and provided to the RAN node 104 (when the eUE updates its configuration; if the RAN node updates the configuration, this update information is sent from the RAN node to the eUE). In other embodiments, the collaborating UEs may report updated UE capabilities to the RAN node 104. Accordingly, the RAN node 104 may modify the eUE configuration based on the updated capabilities.

[0033] In some cases, a collaborating UE 102 or 103 communicates 220 or 222 with the RAN node on behalf of itself, e.g., sends / receives secured data that the UE does not want to share or pass onto other collaborating UEs. In such cases, the collaborating UE may store two communication configurations: one communication configuration to be used for the eUE, and the other to be used for its own communication with the RAN node. The RAN node may indicate to the collaborating UE which of the above configurations to use for a specific transmission. For example, the configuration to be used may be based on the RNTI used in scheduling physical downlink shared channel (PDSCH). The two communication configurations may configure separate resources for the same type of transmission (e.g., physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) resources). Therefore, based on the resources associated with a transmission, the RAN node and UE can determine whether the transmission is from an individual collaborating UE or from the eUE.

[0034] Alternatively, the collaborating UE may dynamically switch between the two communication configurations. The dynamic switch may be triggered by signaling from the RAN node or collaborating UEs. In some embodiments, the dynamic switch may be eventtriggered. The event may be based on a UE report of the start / end of the collaboration or RAN node’s approvals of the start / end of the collaboration.

[0035] FIG. 3 is similar to FIG. 2 except that UEs 102, 103 first request 303 the RAN node 104 for permission to collaborate, and the RAN node may approve the collaboration via an acknowledgment message or other similar message. Then, only if such permission is granted, the collaborating UEs 102, 103 establish a direct connection 202 with each other. In another embodiment, permission for the collaboration may be implied when the collaborating UEs 102, 103 receive the eUE ID. Then, the collaborating UEs 102, 103 may establish a direct connection and establish the eUE 190 with the assigned eUE ID. Further, FIG. 3 shows a selection 313 of the new values for the one or more parameters being made at the RAN node 104, with input from the collaborating UEs 102, 103 (e.g., UE capability report). However, in one variation of this embodiment, the RAN node may be omitted from the selection step. Accordingly, only the collaborating UEs 102, 103 and / or the eUE 190 select the new values for the one or more parameters, and report the selected values to the RAN node. All other steps in the figure are similar to the steps in FIG. 2.

[0036] FIG. 4 illustrates a configuration of the parameter 400 that is used to configure the eUE 190 for communicating with the RAN node. The parameter 400 may include any one or any combination of the fields 400-1 to 400-7 noted in this figure. In other words, parameter 400 may be the power headroom report 400-1 , buffer status report 400-2, minimum processing delay capability 400-3, beam switching capability 400-4, phase noise property 400-5, MIMO communication capability 400-6, or other UE capability 400-7, or any combination of these parameters. In some variations of this embodiment, the parameter 400 may include different fields, additional fields, or only a subset of the fields listed in the figure. The values of the parameter 400 define the profile of the eUE 190 as will be discussed in detail later.

[0037] FIG. 5 illustrates a method 500 for wireless communication at the eUE, for determining a parameter to be used by the eUE 190 with the RAN node 104. The collaborating UEs 102, 103, establish 510 the eUE 190. The eUE 190, based on information provided by each of the collaborating UE, selects 512 a value for the parameter 400. If the parameter 400 includes a single field, the value refers to that field.However, if the parameter 400 includes plural fields, multiple values are selected, one for each field. The selected value is transmitted 514 to the RAN node, which selects the configuration and / or capabilities to be applied for communication with the ellE. Based on the selected value of the parameter, the ellE 190 communicates 516 with the RAN node 104, for example, exchanges control and / or user data. In some scenarios, the ellE 190 may update 518 its configuration and / or capabilities by updating value(s) of the parameter 400 and sends the updated value(s) of the parameter to the RAN node. In one variation of this embodiment, the ellE 190 receives the value(s) of the parameter 400 from the RAN node 104 instead of selecting the value in step 512. Then, steps 512 and 514 are replaced by the step of receiving the value of the parameter 400.

[0038] FIG. 6 illustrates a wireless communication method 600 at a RAN node for determining a parameter to be used by the ellE in communication with the RAN node. The RAN node 104 receives 604 a request from one or more UEs 102, 103, for forming the eUE 190. In one embodiment, one UE (e.g., the leader UE or primary UE) of the collaborating UEs takes a lead position and communicates with the RAN node on behalf of the other collaborating UEs, for forming the eUE 190. In another embodiment, each UE requests permission from the RAN node for forming the eUE. The RAN node 104 approves 605 the request(s) and assigns an eUE ID for the eUE 190. The RAN node 104 sends 608 the eUE ID to each of the collaborating UEs 102, 103. In another embodiment, the RAN node 104 may send the eUE ID to the leader UE which in turn sends the eUE ID to the other collaborating UEs via the direct connection. The RAN node 104 may obtain 614 a value of the parameter by either determining the value of the parameter 400 or receiving the value of the parameter 400 from the collaborating UEs 102, 103 and / or the eUE 190. Based on this value, the RAN node 104 applies 630 a configuration and / or capability of the eUE (i.e. , the eUE profile) for communicating with the eUE. Then, the RAN node 104 communicates 616 with the eUE 190 based on the applied configuration and / or capability, and exchanges control and / or user data using the eUE ID. In some scenarios, the RAN node 104 may update 618 the configuration and / or capabilities (i.e., the eUE profile) of the eUE to account for a changing environment or changing functional parameters. The RAN node 104 also communicates 620 with collaborating UE 103, usingthe ID of the UE 103, and communicates 622 with another collaborating UE 102, using the ID of the UE 102, which are different from the eUE ID of the eUE 190.

[0039] FIG. 7 illustrates a wireless communication method 700 at a collaborating UE (UE 102 or 103), for determining a parameter to be used by a eUE in communication with a RAN node. The collaborating UE 102 is one UE of plural UEs that collaborate to create the eUE 190. The UE 102 establishes 702 a direct connection, bypassing the RAN node 104, with another UE 103. The UE 102, considered in this embodiment to be the leader of the collaborating UEs, requests 703 approval from the RAN node 104 to form the eUE 190 with the other UEs. While FIG. 7 shows that the approval 703 takes place after establishing 702 the direct connection with the other UE 103, in one embodiment, step 703 takes place before step 702.

[0040] After the collaboration request approval is received 705 from the RAN node 104, the leader UE 102 receives 708 a eUE ID to be used for the eUE 190. Thus, the leader UE 102 has its own ID for its own communication with the RAN node, and another ID (eUE ID) for communication with the RAN node on behalf of the eUE 190. The data exchanged by the UE 102 under the eUE ID may be shared with other collaborating UEs 103, but the UE’s 102 own data exchanged under its own ID may not be shared with the other collaborating UEs 103. Based on the eUE ID, the leader UE 102 creates 710 the eUE 190 and selects 712 a value of the parameter 400 for the eUE 190. In one embodiment, only the leader UE 102 makes this selection. In another embodiment, the collaborating UEs 102, 103, collectively select the value of the parameter. In yet another embodiment, the RAN node 104 selects the value of the parameter and sends it to the collaborating UEs 102, 103 for being used for the eUE 190. If the collaborating UEs 102, 103 or the eUE 190 select the value of the parameter 400, the leader UE 102 transmits 714 the value to the RAN node 104 for communication between the eUE 190 and the RAN node 104. Then, the leader UE 102 communicates 716 with the RAN node 104 on behalf of the eUE 190. The leader UE 102 also communicates 722 with the RAN node 104 on behalf of itself, using another value for the parameter 400. The value of the parameter and / or its determination is different for the individual collaborating UE and the eUE.

[0041] The following embodiments discuss each field 400-1 to 400-6 of the parameter 400 and present various techniques for determ ining / selecting a value of the oneor more fields. The power headroom report (PHR) 400-1 for the ellE 190 may be determ ined / defined / selected and reported by the ellE (or one or more of the collaborating UEs) or may be determ ined / defined / selected by the RAN node 104 as discussed above with regard to FIGs. 2 to 7. The PHR refers to a mechanism used by the UE to inform the RAN node about the available power headroom. The available power headroom is associated with the difference between the maximum transmit power capability of the UE and the actual transmit power. The power headroom report allows the RAN node to adjust the uplink transmission parameters for efficient resource allocation and power control. By knowing the available power headroom of each UE, the RAN node can dynamically adjust the uplink transmission parameters, such as modulation and coding scheme (MCS), transmit power, and resource allocation, to maximize throughput, coverage, and overall system performance while maintaining quality of service (QoS) requirements. Two options for defining the value of the PHR are discussed now.

[0042] According to the first option, the eUE reports (or the leader UE reports) a single eUE PHR to the RAN node. The eUE PHR may be determined based on local information exchanged between the collaborating UEs 102, 103, e.g., via the SL. In one variation of this embodiment, the eUE reports a different PHR for each beam for the FR2, e.g., different PHR for different transmission configuration indicators (TCIs).

[0043] According to the second option, the RAN node determines the eUE PHR for the eUE based on individual PHRs sent by the collaborating UEs. For example, the RAN node may use the sum, minimum, or maximum of the individual PHRs from all collaborating UEs for defining the eUE PHR. For this approach, each collaborating UE still reports its own PHRs. For different TCIs, the PHRs may be reported separately by each UE, and also derived based on different rules. For example, in one embodiment, the RAN node uses a first rule in which the PHR for the eUE is the sum of those reported by all participating UEs. In a different embodiment, a second rule is used, which may be that the PHR for the eUE is based on the PHR reported by a single given UE of the collaborating UEs. For different TCIs, different rule options may be applied, for example, the RAN node identifies the rule based on a UE indication (e.g., for a first TCI, the first rule is applied, for a second TCI, the second rule applied, and so on).

[0044] Another possible choice of the parameter 400 is the buffer status report (BSR) 400-2. The BSR 400-2 for the eUE 190 may be determ ined / defined / selected and reported by the eUE (or one or more collaborating UEs) or may be determ ined / defined / selected by the RAN node 104. The BSR is a mechanism used by the UE to provide information to the RAN node about the amount of data in the UE's buffer waiting to be transmitted. The BSR includes information such as the size of the buffer and the priority of the data waiting to be transmitted. The RAN node uses the BSR for efficient scheduling and resource allocation in the uplink direction. By knowing the buffer status of each UE, the RAN node makes decisions about which UEs to grant resources to and how much data to schedule for transmission.

[0045] As the UEs (UE 102 and UE 103 in this embodiment) forming the eUE 190 collaborate to communicate with RAN node 104, the buffer of each collaborating UE may need to store not only its own data, but also data related to other collaborating UEs and / or eUE. For example, during the collaboration procedure, the first UE 102 is using the second UE’s 103 antenna array to send uplink data. For this case, the second UE’s 103 buffer will store its own data plus the first UE’s 102 data. Thus, for this scenario, the collaborating UEs may report a combined BSR to the RAN node, due to locally exchanging (e.g., via the direct connection) the individual buffer information.

[0046] In some embodiments, while a UE 102 participates in the UE-UE collaboration to form the eUE 190, the UE 102 may still send certain data on its own. In some cases, the UE 102 may send the BSR based on the amount of the uplink data to be sent on its own, in addition to the combined BSR for the total traffic from the eUE 190. In some examples, the combined BSR and individual BSR may use different resources (e.g., the resources scheduled by DCI using different UE IDs), or different headers (e.g., logical channel IDs). Thus, the RAN node 104 can distinguish the traffic of one collaborating UE 102, 103 from the traffic of the eUE 190 based on the resource to which the BSR is associated with.

[0047] Alternatively, the collaborating UEs may separately report their BSR to the RAN node. Additional information is also indicated to the RAN node, to determine the buffer status of the eUE, to avoid double counting the data. For example, after establishing the UE-UE collaboration, the first UE 102 uses the second UE’s 103 antenna array to senduplink data. Therefore, the second UE 103 needs to buffer the data or in-phase and quadrature-phase (IQ) out samples received from the first UE 102. If directly using the legacy BSR rule, each of the first and second UEs separately reports the data size in their buffers, and the amount of the first UE’s 102 data is double counted by the RAN node. Then, the RAN node may schedule more uplink resources than needed for the first UE’s 102 transmission. To avoid double counting, additional information may be indicated to the RAN node by the eUE or any collaborating UE. For example, the actual buffer size is the sum of the data sizes in all individual BSRs minus X, where the value of X is reported to the RAN node.

[0048] Another possible choice of the parameter 400 is the minimum processing delay capability 400-3. The capability regarding the minimum processing delay 400-3 for the eUE 190 may be determ ined / defined / selected and reported by the eUE (or a collaborating UE forming the eUE) or may be determ ined / defined / selected by the RAN node 104 and then transmitted to the eUE. There are a few processing delay capabilities that a UE may report to the RAN node, for example:• Minimum time delay between PDSCH and its associated acknowledgement (ACK) occasion,• Minimum time gap between DCI and aperiodic (AP) channel state informationreference signal (CSI-RS) or tracking reference signal (TRS), and• Processing time between CSI-RS and the associated CSI report occasion.

[0049] For the case of a single UE, the delay accounts for the time that the UE requires to finish PDSCH / PDCCH decoding, CSI computation as well as switching between receiving / transmitting for the corresponding DL / UL transmission. For the case of UE-UE collaboration, the received / decoded PDSCH / PDCCH may be transferred to another collaborating UE via SL, which requires an additional delay. Therefore, the eUE may need to update these affected capabilities for processing delay.

[0050] The new capabilities values for the eUE may be determined based on at least one of the following options:• Option 1 : the minimum processing delay for the eUE is determined based on a predefined value, e.g., a maximum delay due to SL transmission, which is defined in the technical standards;• Option 2: the minimum processing delay for the eUE is determined based on a predefined rule, e.g., the delay value for the eUE is the maximum delay value out of all collaborating UEs plus a delta value (which corresponds to a SL delay);• Option 3: the minimum processing delay for the eUE is determined based on the collaborating UE configurations, e.g., the total eUE delay is the maximum delay plus a delta value, and the delta value is derived based on the SL configurations, e.g., the maximum periodicity of the SL synchronization signal block (SSB) among all SLs, or based on the parameters of the SL resource pools among the collaborating UEs; or• Option 4: the minimum processing delay for the eUE is determined based on the local information exchanged between the collaborating UEs. For example, all collaborating UEs report their capability values to the leader UE, and the leader UE then determines the capability for the eUE and reports the selected value for the minimum processing delay to the RAN node.

[0051] After the UE-UE collaboration has been established, it is possible that certain transmission / processing tasks do not require SL information exchange between multiple UEs, while some tasks require SL information exchange between multiple UEs, which may require additional delay. In this case, the minimum processing delay capabilities report may be specific to the TCI, RS resource (set) ID, or intended UE ID. For example, for TCI1 , the minimum processing delay capabilities report is managed only by the first UE 102. If a PDSCH is sent using a beam associated with TCI1 , for the first UE 102, and its corresponding ACK is also sent using a beam associated with TCI1 , then the minimum processing delay can be T_ue1. If the PDSCH is sent using a beam associated with TCI1 , for the second UE 103, the minimum processing delay can be defined to be max{T_ue1 , T_ue2} + offset, where the offset takes into account the delay due to local exchange of information (e.g., via SL) between the first UE and the second UE. All the values of T_ue1 , T_ue2, and offset may be reported to the RAN node.

[0052] Another possible choice of parameter 400 is the beam switching delay capability 400-4. The capabilities regarding the beam switching delay 400-4 for the eUE 190 may be determ ined / defined / selected and reported by the eUE (or one or more of the collaborating UEs) or may be determ ined / defined / selected by the RAN node 104 and then transmitted to the eUE. For example, in FR2, the following capabilities are reported by a UE, to the RAN node:• The minimum delay from a beam indication DCI to scheduling PDSCH such that the indicated TCI in the DCI will be applied to the PDSCH;• Beam application time such that the indicated TCI in DCI will take effect; and• Minimum gap time / symbol when beam switch happens (for higher mmWave band when a cyclic prefix (CP) may not be long enough to cover the beam switch time).

[0053] These capabilities depend on UE’s capability to tune the radio frequency (RF) circuit and switch the beamforming directions. After UE-llE collaboration, these capabilities need to be updated by the RAN node by one of the following options:• Option 1 : based on a fixed rule, which may be, the largest delay among all collaborating UEs plus a fixed offset; or• Option 2: based on signaling, for example, the eUE reports the new value; or• Option 3: a combination of the above: the largest delay among all collaborating UEs plus an offset reported by eUE. If no such report is generated by the UEs or received by the RAN node, the offset is set to a default value, e.g., 0.

[0054] Another possible choice of the parameter 400 is the phase noise property 400-5. The capabilities regarding the phase noise property 400-5 and phase tracking reference signal (PTRS) for the eUE 190 may be determ ined / defined / selected and reported by the eUE (or a collaborating UE forming the eUE) or may be determ ined / defined / selected by the RAN node 104 and then transmitted to the eUE. PTRS is a type of reference signal used to improve the accuracy of phase tracking at the receiver, particularly in scenarios where there are challenges related to phase noise or phase tracking errors. By employing PTRS, the receiver can better estimate and compensate for these phase variations, leading to improved performance and reliability of the communication.

[0055] In FR2, the UE may report its recommended PTRS configurations, e.g., whether it is ON / OFF, time / frequency density in different MCSs / bandwidths (BWs), based on its phase noise property. After establishing the IIE-UE collaboration, the participating UEs may have different phase noise properties, and thus may recommend a different PTRS configuration.

[0056] After establishing the IIE-UE collaboration, the PTRS configuration recommendation can be indicated to the RAN node by one of the following options:• Option 1 : based on a fixed rule, for example, use the densest (most dense) PTRS configuration among all collaborating UEs plus a fixed offset; or• Option 2: based on signaling, for example, eUE reports the new configuration; or• Option 3: based on a combination of the above, for example, the densest configuration among all collaborating UEs plus an offset reported by eUE. If no such report is generated by the UEs or received by the RAN node, the offset is set to a default value, e.g., 0.

[0057] Another possible choice of the parameter 400 is the MIMO communication capability 400-6. The MIMO communication capability 400-6 for the eUE 190 may be determ ined / defined / selected and reported by the eUE (or one or more of the collaborating UEs), or may be determined / defined / selected by the RAN node 104 and then transmitted to the eUE. After multiple UEs 102, 103 form the eUE 190, the MIMO communication capability may need to be updated for the eUE 190. In some cases, additional capabilities may also need to be reported. For example, the eUE 190 may support a different (most likely larger) number of MIMO layers / data streams (e.g., rank) than the individual UEs 102, 103 forming the eUE.

[0058] In addition, for the eUE 190, the supported MIMO communication schemes (per the number of MIMO layers) may need to be reported to the RAN node 104. For instance, each collaborating UE may support 2 UL MIMO layers on its own, and the eUE may support up to 4 UL MIMO layers. However, due to the phase incoherence from 2 participating UEs, certain MCSs (e.g., 256 quadrature amplitude modulation (QAM)) may not be supported for a number of MIMO layers larger than 2 or other predefined value. In another example, for the eUE 190, the single frequency network (SFN) transmissionscheme may not be supported (or not supported for MIMO layers > X), due to the nonideal frequency synchronization between collaborating UEs. The number of MIMO layers / data streams and the MIMO communication schemes may be calculated / determined by the RAN node, or by the leader UE, or jointly by the collaborating UEs forming the eUE.

[0059] The following description may be applied to the embodiments discussed above. The description for one of the above figures can apply to another of the above figures. Examples, implementations and methods described above can be combined, if there is no conflict. An event or step described above can be optional or omitted, especially if the step is shown with a dash line. In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters”, and vice versa. In some implementations, “some” means “one or more”. In some implementations, “at least one” means “one or more”.

[0060] A UE in which the techniques of this document can be implemented (e.g., the UE 102 or UE 103) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a mediastreaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0061] Certain embodiments are described in this document as including logic or a number of components or modules. Modules may be software modules (e.g., code, or machine-readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an applicationspecific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0062] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.

[0063] Upon reading this document, those of skill in the art will appreciate additional and alternative structural and functional designs for handling communication between the eUE and the RAN node through the principles disclosed herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those of ordinary skill in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

[0064] Numerical adjectives “first”, “second”, and “third” do not imply any order (are not ordinals) but are markers to distinguish separate instances of similar elements.References to the singular (e.g., “a” or “an”, “the”) should include the plural unless clearly indicated otherwise.

[0065] As used herein, a phrase referring to “at least one of’ or “one or more of’ a list of items refers to any combination of those items, including single members. For example, “at least one of: a, b, or c” is intended to cover the possibilities of: a only, b only, c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

[0066] Although the features and elements of the present embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flowcharts may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a specifically programmed computer or processor.

Claims

WHAT IS CLAIMED IS:1 . A method for wireless communication at an enhanced user equipment, ellE, (190), the method comprising: selecting (512) a value of a parameter (400) associated with a profile of the ellE (190), the profile of the ellE (190) including combined physical resources from at least two different user equipments, UEs, (102, 103); and communicating (516) with a radio access network, RAN, node (104) based on a configuration of the eUE (190) corresponding to the value of the parameter (400).

2. The method of Claim 1 , further comprising: transmitting, to the RAN node, the value of the parameter; and receiving, from the RAN node, the configuration of the ellE via one of a radio resource control (RRC) message, a medium access control-control element (MAC-CE), or downlink control information (DCI).

3. The method of any of Claims 1 to 2, further comprising: establishing a direct connection between the at least two different UEs to form the eUE, wherein the direct connection bypasses the RAN node.

4. The method of any of Claims 1 to 3, wherein the parameter is associated with at least one of: a power headroom report, a buffer status report, a minimum processing delay capability, a beam switch delay capability, a phase noise property, or a multiple input multiple output, MIMO, communication capability.

5. The method of any of Claims 1 to 4, wherein the value of the parameter is determined by a leader UE of the at least two different UEs or collectively by the at least two different UEs and reported by the eUE to the RAN node.

6. The method of any of Claims 1 to 4, wherein the value of the parameter is received from the RAN node.

7. The method of Claim 6, further comprising: transmitting, to the RAN node, UE capabilities of the at least two different UEs; and receiving, from the RAN node, the value of the parameter based on the UE capabilities.

8. The method of any of Claims 1 to 7, wherein the value of the parameter is determined based on at least one of: a predefined number, a predefined rule, each UE configuration of the at least two different UEs, or local information exchanged between the at least two different UEs.

9. The method of Claim 8, wherein the predefined rule is based on at least one of: at least one of a transmission configuration indication, a sum or minimum or maximum of corresponding UE values of the at least two different UEs, or a UE value of one of the at least two different UEs, for a power headroom report; a combined buffer of the at least two different UEs minus a common value, for a buffer status report; a maximum processing delay value of the at least two different UEs plus a given value, for a minimum processing delay capability; a largest beam delay of the at least two different UEs plus a fixed offset, for a beam switch delay capability; ora most dense phase tracking reference signal, PTRS, configuration among the at least two different UEs, for a phase noise property.

10. The method of any of Claims 1 to 9, wherein the parameter is associated with a multiple input multiple output, MIMO, communication capability of the eUE, different from a MIMO communication capability of each of the at least two different UEs.11 . The method of any of Claims 1 to 10, wherein the combined physical resources include a first antenna array from one of the at least two different UEs, and a second antenna array from another one of the at least two different UEs.

12. The method of any of Claims 1 to 11 , further comprising: receiving an eUE identity for the communicating with the RAN node, the eUE identity being different from identities of the at least two different UEs, wherein a respective UE of the at least two different UEs uses a first radio resource control (RRC) configuration for communicating with the RAN node on behalf of the respective UE, and a second RRC configuration for communicating with the RAN node on behalf of the eUE.

13. A method for wireless communication at a radio access network, RAN, node (104), the method comprising: receiving (604) a request for forming an enhanced user equipment, eUE, (190), from at least two different user equipments, UEs, (102, 103); transmitting (608) an identity of the eUE (190) to the at least two different UEs (102, 103); and communicating (616) with the eUE (190) using the identity of the eUE and based on a value of a parameter (400) associated with a profile of the eUE (190), the profile of the eUE (190) including combined physical resources from the at least two different UEs (102, 103).

14. The method of Claim 13, wherein the value of the parameter (400) is determined by at least one of: the eUE, or the RAN node based on UE capabilities received from the at least two different UEs.

15. The method of any of Claims 13 to 14, wherein the parameter is associated with at least one of: a power headroom report, a buffer status report, a minimum processing delay capability, a beam switch delay capability, a phase noise property, or a multiple input multiple output, MIMO, communication capability.

16. The method of any of Claims 13 to 15, wherein the value of the parameter is determined based on at least one of: a predefined number, a predefined rule, each UE configuration of the at least two different UEs, or local information exchanged between the at least two different UEs.

17. The method of Claim 16, wherein the predefined rule is based on at least one of: at least a transmission configuration indication, a sum or minimum or maximum of corresponding UE values of the at least two different UEs, or a UE value of one of the at least two different UEs, for a power headroom report; a combined buffer of the at least two different UEs minus a common value, for a buffer status report; a maximum processing delay value of the at least two different UEs plus a given value, for a minimum processing delay capability; a largest beam delay of the at least two different UEs plus a fixed offset, for a beam switch delay capability; ora most dense phase tracking reference signal, PTRS, configuration among the at least two different UEs, for a phase noise property.

18. A wireless communication device (190, 104) comprising a transceiver (154, 156, 144, 146), a processor (152, 182, 142), and computer-readable storage media (158) storing executable instructions for the processor to perform any one of methods recited in claims 1 -17, using the transceiver.

Images