Systems, methods, and devices for MAC layer UE inter-coordination (IUC) and resource utilization.

Abstract

Techniques described herein include solutions for enabling inter-user equipment (UE) coordination (IUC) using a media access control (MAC) control element (CE). A first UE may send an IUC request to a second UE, and the second UE may respond with a MAC CE that includes IUC information. The IUC information may indicate one or more wireless resources that the first UE may use to communicate with the second UE. The IUC information may further include a time domain validity of the wireless resources, which may include one or more durations during which the wireless resources may be used for communication. The first UE may further implement a latency bound for which the second UE responds with the IUC information. In some implementations, discontinuous reception (DRX) may be used by the first and second UEs, and the DRX active time of the UEs may be modified or configured to facilitate IUC.

Description

Technical Field

[0001] The present disclosure relates to a wireless communication network including technologies for enabling communication between devices.

Background Art

[0002] As the number of mobile devices in a wireless network and the demand for mobile data traffic continue to increase, changes are made to the system requirements and architecture to better address current and anticipated demands. For example, some wireless communication networks can be developed to implement fifth-generation (5G) or new radio (NR) technologies, sixth-generation (6G) technologies, and the like. One aspect of such technologies involves addressing how wireless devices communicate with each other, which may involve direct communication between user equipment (UE) devices.

Brief Description of the Drawings

[0003] The present disclosure will be readily understood and capable of being executed by reference to the detailed description and the drawings. Like reference numerals may indicate like features and structural elements. The figures and corresponding descriptions are provided as non-limiting examples of aspects, implementations, etc. of the present disclosure, and references to "an" or "one" aspect, implementation, etc. do not necessarily refer to the same aspect, implementation, etc., and may mean at least one, one or more, etc.

[0004] [Figure 1] It is a diagram of an exemplary process of media access control (MAC) layer user equipment (UE) - to - UE cooperation (IUC).

[0005] [Figure 2] It is a diagram of an example of network resource availability and IUC messaging.

[0006] [Figure 3] It is a diagram of an example of discontinuous reception (DRX) and IUC messaging.

[0007] [Figure 4] This is a diagram illustrating an example of a network in one or more implementation forms described in this specification.

[0008] [Figure 5] This figure illustrates an example of time-domain effectiveness for one or more implementations described herein. [Figure 6] This figure illustrates an example of time-domain effectiveness for one or more implementations described herein. [Figure 7] This figure illustrates an example of time-domain effectiveness for one or more implementations described herein.

[0009] [Figure 8] This figure illustrates an example of IUC messaging using different periodicities in one or more implementations described herein. [Figure 9] This figure illustrates an example of IUC messaging using different periodicities in one or more implementations described herein. [Figure 10] This figure illustrates an example of IUC messaging using different periodicities in one or more implementations described herein.

[0010] [Figure 11] This diagram illustrates an example of latency limits for IUC messaging in one or more implementations described herein. [Figure 12] This diagram illustrates an example of latency limits for IUC messaging in one or more implementations described herein.

[0011] [Figure 13] This figure illustrates an example of IUC messaging and interaction with DRX in one or more implementations described herein. [Figure 14] This figure illustrates an example of IUC messaging and interaction with DRX in one or more implementations described herein.

[0012] [Figure 15] Another exemplary diagram of IUC messaging and interactions with DRX, according to one or more implementations described herein.

[0013] [Figure 16] A diagram of an example of components of a device, according to one or more implementations described herein.

[0014] [Figure 17] A diagram showing an exemplary interface of a baseband circuit configuration, according to one or more implementations described herein.

[0015] [Figure 18] A block diagram of an exemplary control plane protocol stack, according to one or more implementations described herein.

[0016] [Figure 19] A block diagram showing components capable of reading instructions from a machine-readable medium or a computer-readable medium (e.g., a non-transitory machine-readable storage medium) and executing any one or more of the methods described herein, according to one or more implementations described herein.

Mode for Carrying Out the Invention

[0017] The following detailed description refers to the accompanying drawings. Like reference numerals in different figures may identify the same or similar features, elements, operations, etc. Additionally, other implementations may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure, so the present disclosure is not limited to the following description.

[0018] A communication network may include user equipment (UEs) capable of communicating with base stations and other network nodes. In some implementations, UEs may also be capable of communicating directly with other UEs, which is sometimes called device-to-device (D2D) communication. This may include discovering nearby UEs, synchronizing with other UEs, establishing connections with other UEs, and using those connections to transmit and receive information. Depending on the scenario, a UE may perform one or more of these functions with or without the assistance or involvement of base stations, wireless routers, or other types of network nodes.

[0019] To communicate with each other, UEs may perform one or more operations at the Media Access Control (MAC) layer. Examples of such operations may include UEs transmitting and receiving MAC control elements (CEs) to ensure that messages and signaling between UEs are properly coordinated with respect to time, frequency, periodicity, etc., including processes for transmitting (Tx) and receiving (Rx) such messages. This may generally be referred to as inter-UE coordination (IUC). As described herein, IUC may also include coordination or combination of processes performed by UEs that support the transmission and reception of messages and signaling.

[0020] Figure 1 is a diagram of an exemplary process 100 of media access control (MAC) layer UE-to-UE (user device) coordination (IUC). As shown, process 100 may include UE 110-1 and UE 110-2. In some implementations, UE 110-2 may send a MAC CE containing a request (e.g., an IUC request) to UE 110-1 (in 120). The request may be for information indicating wireless resources (e.g., time, frequency, periodicity, etc.) that UE 110-2 may later use to communicate with UE 110-1. Accordingly, UE 110-1 may send a MAC CE containing the requested information (e.g., IUC information) to UE 110-2 (in 140). UE 110-2 may use the received information to continue communicating with UE 110-1. UE 110-1 may send IUC information to UE 110-2 upon request, but in some implementations, UE 110-1 receiving such a request may optionally be configured to send IUC information without receiving an explicit request to do so, or may be configured to do so.

[0021] Figure 2 illustrates network resource availability and IUC messaging examples 210 and 220. Example 210 includes a table having time represented along the horizontal axis and frequency represented along the vertical axis. The table also includes exemplary resources A1, A2, A3, A4, B1, B2, ..., etc. Each resource is indicated as available or as available. In such a scenario, the IUC information transmitted by UE 110-1 to UE 110-2 may include a subset of resources for inter-UE coordination. For example, the IUC information may include a subset of available resources (e.g., A3, B2, and C4) or a subset of unavailable resources (e.g., A1, A2, A4, B1, B3, B4, C1, C2, and C3).

[0022] Providing such information may enable UE 110-2 to communicate with UE 110-1 using wireless resources preferred or selected by UE 110-1, thereby facilitating or enabling coordination between devices. For the purpose of illustrating Figure 2, assume that UE 110-1 receives a MAC CE IUC request, selects resources B2 and A3 to communicate with UE 110-2, and sends IUC INFO to UE 110-2. B2 may have a periodicity of 20 milliseconds (ms), and A3 may have a periodicity of 100 ms. UE 110-2 may then use resources B2 and A3 to subsequently communicate with each other. When resource reservation intervals (or periodicity) are not used in resource selection, the selected resources are for one-time use. When resource reservation intervals are considered, resources are good for repeated use within the reservation interval. Therefore, when UE 110-2 receives instructions for preferred resources from UE 110-1 at intervals (e.g., 20ms, 100ms, etc.), the resources should be periodic.

[0023] However, currently available IUC technologies do not provide a way to define or communicate the time domain for resources indicated in the IUC information. This may be referred to herein as the validity period or validity window, and may include the duration for which resources selected by the UE for the IUC can be used. Currently available IUC technologies also cannot provide a way for IUC arrangements to be organized for different reservation periodicities. Further problems associated with currently available IUC technologies are described below with reference to Figure 3.

[0024] Figure 3 is a diagram illustrating an example of discontinuous reception (DRX) and IUC messaging. As shown, in some implementations, UEs can implement DRX communication via a sidelink (SL) interface between UEs. This may involve unidirectional communication, where the Tx UE determines the transmission time based on the DRC active state (e.g., onDuration) of the RX UE. Thus, when UE 110-2 communicates an IUC request to UE 110-1, the request may be transmitted according to the onDuration of UE 110-1 in accordance with the DRC. However, the IUC request may have a time or latency limit during which the IUC information can be received, which may not coincide with the onDuration of UE 110-2. If UE 110-1 transmits the IUC information according to its next DRX onDuration, the IUC information may be transmitted too late (e.g., after the latency limit associated with the IUC request) and therefore may be invalid. Therefore, currently available IUC technologies cannot adequately resolve the potential conflict between IUC communications and DRX procedures.

[0025] The techniques described herein include solutions for enabling IUC using MAC CE. For example, a first UE can send an IUC request to a second UE, and the second UE can respond with a MAC CE containing IUC information. The IUC information may indicate one or more wireless resources that the first UE can use to communicate with the second UE. The IUC information may also include the time-domain validity of the wireless resources, which may include instructions for single or one-time use of the wireless resources, the period during which the wireless resources may be used, or multiple periods or windows during which the wireless resources may be used.

[0026] In some implementations, a first UE can send multiple IUC requests to a second UE, and the second UE can respond to the requests using a single MAC CE containing multiple IUC information messages, a single MAC packet data unit (PDU) or single transport block (TB) with multiple MAC CEs, or collectively using one MAC CE and IUC information message per request. The first UE may also implement a latency limit for the second UE to respond with IUC information, which may be configured based on signal latency and / or processing gaps relative to resource availability (e.g., resource selection window) to ensure that the IUC information messages arrive at the first UE in time. In some implementations, discontinuous reception (DRX) may be used by the first and second UEs, and the DRX active time (e.g., onDuration time for the UEs) may be configured and / or extended to ensure that bounded IUC requests and IUC information messages are transmitted and received according to the DRX active time of each UE.

[0027] Figure 4 shows an exemplary network 400 in one or more implementations described herein. The exemplary network 400 may include UE410-1, 410-2, etc. (collectively referred to as "UE410" and individually as "UE410"), a radio access network (RAN) 420, a core network (CN) 430, an application server 440, an external network 450, and satellites 460-1, 460-2, etc. (collectively referred to as "satellite 460" and individually as "satellite 460"). As shown in the figure, the network 400 may include a non-terrestrial network (NTN) with one or more satellites 460 (e.g., of a Global Navigation Satellite System (GNSS)) communicating with the UE410 and RAN 420.

[0028] The exemplary Network 400 systems and devices may operate in accordance with one or more communication standards, such as the 2G, 3G, 4G (e.g., Long-Term Evolution (LTE)), and 5G (e.g., New Radio (NR)) communication standards of the Third Generation Partnership Project (3GPP®). Additionally or alternatively, one or more of the exemplary Network 400 systems and devices may operate in accordance with other communication standards and protocols described herein, including future versions or generations of 3GPP standards (e.g., 6G standards, 7G standards, etc.) and IEEE standards (e.g., Wireless Metropolitan Area Network (WMAN), Worldwide Interoperability for Microwave Access (WiMAX), etc.).

[0029] As illustrated, the UE410 may include a smartphone (e.g., a handheld touchscreen mobile computing device capable of connecting to one or more wireless communication networks). Additionally or alternatively, the UE410 may include other types of wirelessly communicating mobile or non-mobile computing devices, such as personal data assistants (PDAs), pagers, laptop computers, desktop computers, and wireless handsets. In some implementations, the UE410 may include an Internet of Things (IoT) device (or IoT UE) that includes a network access layer designed for low-power IoT applications that leverage short-lived UE connections. In addition, or instead, an IoT UE may utilize one or more types of technologies, such as machine-to-machine (M2M) communication, or machine-type communication (MTC) (for example, exchanging data with an MTC server or other device via a Public Land Mobile Network (PLMN)), proximity-based service (ProSe), or device-to-device (D2D) communication, sensor networks, or IoT networks. Depending on the scenario, the M2M or MTC data exchange may be machine-initiated, and the IoT network may involve interconnecting IoT UEs (which may include uniquely identifiable embedded computing devices within the internet infrastructure) with short-lived connections. In some scenarios, the IoT UE may run background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity within the IoT network.

[0030] UE 410 may communicate with one or more other UE 410s via one or more wireless channels 412, each of which may have a physical communication interface / layer, and establish connections with them. Connections may include M2M connections, MTC connections, D2D connections, etc. In some implementations, UE 410s may be configured to discover each other, negotiate wireless resources between them, and establish connections between them without intervention or communication with RAN nodes 422 or other types of network nodes. In some implementations, discovery, authentication, resource negotiation, registration, etc., may involve communication with RAN nodes 422 or other types of network nodes.

[0031] UE410 can communicate with and establish a connection with RAN 420 (e.g., be communicatively coupled), which may include one or more wireless channels 414-1 and 414-2, each of which may have a physical communication interface / layer. In some implementations, UE may be configured with dual connectivity (DC) as multi-Radio Access Technology (multi-RAT) or Multi-Radio Dual Connectivity (MR-DC), where multiple Receive and Transmit (Rx / Tx) enabled UEs can use resources provided by different network nodes (e.g., 422-1 and 422-2) that may be connected via a non-ideal backhaul (e.g., one network node provides NR access and the other provides either LTE E-UTRA or 5G NR access). In such a scenario, one network node can function as a Master Node (MN), and the other as a Secondary Node (SN). The MN and SN may be connected via a network interface, and at least the MN may be connected to the CN430. Furthermore, at least one of the MN or SN may operate using shared spectral channel access, and the functions specified for the UE410 can be used for integrated access and backhaul mobile termination (IAB-MT). Similarly, as in the case of the UE401, the IAB-MT may access the network using one network node or using either two different nodes having an Enhanced Dual Connectivity (EN-DC) architecture, a New Radio Dual Connectivity (NR-DC) architecture, etc. In some implementations, the base station (as described herein) may be an example of a network node 422.

[0032] As shown in the figure, UE410 may further, or alternatively, connect to AP416 via a connection interface 418 which may include an air interface that enables UE410 to communicate with AP416. AP416 may comprise a wireless local area network (WLAN), WLAN nodes, WLAN termination points, etc. Connection 4207 may comprise a local wireless connection such as a connection that matches any IEEE 702.11 protocol, and AP416 may comprise a Wireless Fidelity (Wi-Fi®) router or other AP. Although not explicitly shown in Figure 4, AP416 may connect to another network (e.g., the Internet) without connecting to RAN420 or CN430. In some scenarios, UE410, RAN420, and AP416 may be configured to utilize LTE-WLAN aggregation (LWA) technology or LTE-WLAN radio level integration (LWIP) operation with an IPsec tunnel. LWA may involve UE410 in RRC_CONNECTED configured by RAN420 to utilize LTE and WLAN radio resources. LWIP may involve UE410 using WLAN radio resources (e.g., connection interface 418) via IPsec protocol tunneling to authenticate and encrypt packets (e.g., Internet Protocol (IP) packets) transmitted via connection interface 418. IPsec tunneling may involve encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

[0033] RAN 420 may include one or more RAN nodes 422-1 and 422-2 (collectively referred to as RAN node 422, and individually referred to as RAN node 422) that enable channels 414-1 and 414-2 to be established between UE 410 and RAN 420. RAN node 422 may include network access points configured to provide radio baseband functionality for data and / or voice connectivity between users and the network, based on one or more of the communication technologies described herein (e.g., 2G, 3G, 4G, 5G, WiFi, etc.). Thus, as an example, RAN nodes may be E-UTRAN node B (e.g., extended node B, e-node B, eNB, 4G base station, etc.), next-generation base stations (e.g., 5G base station, NR base station, next-generation eNB (gNB), etc.). RAN node 422 may include roadside units (RSUs), transmit / receive points (TRxP or TRP), and one or more other types of ground stations (e.g., ground access points). In some scenarios, RAN node 422 may be a dedicated physical device such as a macrocell base station and / or a low-power (LP) base station to provide a smaller coverage area, smaller user capacity, or wider bandwidth compared to a macrocell. As described below, in some implementations, satellite 460 may act as a base station (e.g., RAN node 422) for UE 410. Thus, references to base stations, RAN node 422, etc. in this specification may include implementations in which the base station, RAN node 422, etc. are terrestrial network nodes, and implementations in which the base station, RAN node 422, etc. are non-terrestrial network nodes (e.g., satellite 460).

[0034] Some or all, or some of, of the RAN nodes 422 can be implemented as one or more software entities running on a server computer as part of a virtual network, which may be called a centralized RAN (CRAN) or a virtual baseband unit pool (vBBUP). In these implementations, the CRAN or vBBUP may perform RAN functional partitioning such as PDCP partitioning, where the Radio Resource Control (RRC) and Packet Data Convergence Protocol (PDCP) layers are operated by the CRAN / vBBUP and other Layer 2 (L2) protocol entities are operated by individual RAN nodes 422; MAC / PHY layer partitioning, where the RRC, PDCP, Radio Link Control (RLC), and Media Access Control (MAC) layers are operated by the CRAN / vBBUP and the Physical (PHY) layer is operated by individual RAN nodes 422; or "lower PHY" partitioning, where the upper parts of the RRC, PDCP, RLC, MAC, and PHY layers are operated by the CRAN / vBBUP and the lower parts of the PHY layer are operated by individual RAN nodes 422. This virtualized framework could free up processor cores on RAN node 422, allowing it to run other virtualized applications.

[0035] In some implementations, individual RAN nodes 422 may represent individual gNB distributed units (DUs) connected to gNB control units (CUs) via individual F1 or other interfaces. In such implementations, a gNB-DU may include one or more remote radio heads or radio frequency (RF) front-end modules (RFEMs), and a gNB-CU may be operated by a server (not shown) located in RAN 420, or by a server pool (e.g., a group of servers configured to share resources), in a manner similar to CRAN / vBBUP. Additionally or alternatively, one or more of the RAN nodes 422 may be next-generation eNBs (i.e., gNBs), which can provide evolved universal terrestrial radio access (E-UTRA) user plane and control plane protocol terminations to UE 410 and may be connected to the 5G core network (5GC) 430 via an NG interface.

[0036] Any of the RAN nodes 422 can terminate the air interface protocol and become the first contact point for the UE410. In some implementations, any of the RAN nodes 422 may perform various logical functions for the RAN420, which may include, but are not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management, data packet scheduling, and mobility management. The UE410 can be configured to communicate with each other or with any of the RAN nodes 422 using orthogonal frequency-division multiplexing (OFDM) communication signals via a multi-carrier communication channel following various communication technologies, such as, but not limited to, OFDMA communication technology (for downlink communication) or single-carrier frequency-division multiple access (SC-FDMA) communication technology (for uplink and ProSe or sidelink (SL) communication), but the scope of such implementations is not necessarily limited to these. The OFDM signal may include multiple orthogonal subcarriers.

[0037] In some implementations, the downlink resource grid can be used for downlink transmissions from any of the RAN nodes 422 to the UE410, and uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid (e.g., resource grid or time-frequency resource grid) representing the physical resources of the downlink within each slot. Such a time-frequency plane representation is a common method for OFDM systems, making the allocation of radio resources intuitive. Each column and row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in the radio frame. The smallest time-frequency unit of the resource grid is denoted as a resource element. Each resource grid contains a resource block, which represents the mapping of a specific physical channel to a resource element. Each resource block may contain a set of resource elements (REs), which in the frequency domain can represent the minimum amount of resources currently available for allocation. There are several different physical downlink channels that are transmitted using such resource blocks.

[0038] Furthermore, RAN node 422 may be configured to wirelessly communicate with or with UE410 via licensed medium (also called “licensed spectrum” and / or “licensed band”), unlicensed shared medium (also called “unlicensed spectrum” and / or “unlicensed band”), and / or a combination thereof. For example, the licensed spectrum may include channels operating in the frequency range of approximately 400 MHz to approximately 3.8 GHz, and the unlicensed spectrum may include the 5 GHz band. The licensed spectrum may correspond to channels or frequency bands selected, reserved, or regulated for certain types of wireless activity (e.g., wireless far-field communication network activity), and the unlicensed spectrum may correspond to one or more frequency bands that are not restricted for a particular type of wireless activity. Whether a particular frequency band corresponds to licensed medium or unlicensed medium may depend on one or more factors, such as frequency allocation determined by public sector organizations (e.g., government agencies, regulatory bodies, etc.) or frequency allocation determined by private sector organizations involved in the development of wireless communication standards and protocols.

[0039] To operate in the unlicensed spectrum, UE410 and RAN node 422 can operate using Licensed Assisted Access (LAA), eLAA, or feLAA mechanisms. In these implementations, UE410 and RAN node 422 may perform one or more known medium detection or carrier detection operations before transmitting in the unlicensed spectrum to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied. The medium / carrier detection operations may be performed according to the Listen Before Talk (LBT) protocol.

[0040] The LAA mechanism can be built upon the Carrier Aggregation (CA) technology of the LTE Advanced System. In CA, each aggregated carrier is called a Component Carrier (CC). In some cases, individual CCs may have different bandwidths than other CCs. In Time Division Duplex (TDD) systems, the number of CCs and the bandwidth of each CC may be the same for DL ​​and UL. CA also includes individual serving cells that provide individual CCs. For example, the coverage of serving cells may differ because CCs in different frequency bands are to experience different path losses. A primary service cell, or PCell, can provide a primary component carrier (PCC) to both UL and DL and can handle RRC and non-access layer (NAS) related activities. Other serving cells are called SCells, and each SCell can provide separate secondary component carriers (SCCs) to both UL and DL. SCCs can be added and removed as needed, while changing the PCC may require UE410 to undergo a handover. In LAA, eLAA, and feLAA, some or all SCells can operate in the unlicensed band (referred to as "LAA SCells"), and the LAA SCells are supplemented by PCells operating in the licensed band. If a UE consists of two or more LAA SCells, the UE can receive UL grants on the configured LAA SCells, indicating different PUSCH start positions within the same subframe. To operate in the unlicensed spectrum, UE 410 and RAN node 422 can also operate using standalone unlicensed operation, where the UE can be configured with PCells in addition to any SCells in the unlicensed spectrum.

[0041] The PDSCH can carry user data and upper-layer signaling to the UE410. The Physical Downlink Control Channel (PDCCH) can, among other things, carry information regarding the transport format and resource allocation for the PDSCH channel. The PDCCH can notify the UE401 of the transport format, resource allocation, and Hybrid Automatic Retransmission Request (HARQ) information for the uplink shared channel. Typically, downlink scheduling (e.g., allocating control and shared channel resource blocks to UE410-2 in a cell) may be performed on one of the RAN nodes 422 based on channel quality information fed back from one of the UE410s. Downlink resource allocation information may be transmitted on the PDCCH used for (e.g., allocated to) each of the UE410s.

[0042] A PDCCH carries control information using Control Channel Elements (CCEs), the number of CCEs (e.g., six) can be set by a Resource Element Group (REG), which is defined as a Physical Resource Block (PRB) within an OFDM symbol. Before being mapped to resource elements, the PDCCH complex-valued symbol may first be organized into, for example, quadraplets, and then swapped using subblock interleavers for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, and each CCE can correspond to nine sets of four physical resource elements known as REGs. Four Quadrature Phase Shift Keying (QPSK) symbols can be mapped to each REG. A PDCCH may be transmitted using one or more CCEs depending on the size of the DCI and the channel state. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=1, 2, 4, 8, or 46).

[0043] Some implementations may use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some implementations may utilize Extended (E)PDCCH, which uses PDSCH resources to transmit control information. EPDCCH may be transmitted using one or more ECCEs. As above, each ECCE may correspond to nine sets of four physical resource elements known as EREGs. In some situations, an ECCE may have a different number of EREGs.

[0044] RAN nodes 422 may be configured to communicate with each other via interface 423. In implementations where the system is an LTE system, interface 423 may be an X2 interface. In an NR system, interface 423 may be an Xn interface. The X2 interface may be defined between two or more RAN nodes 422 (e.g., two or more eNBs / gNBs or a combination thereof) connected to an evolved packet core (EPC) or CN430, and / or between two eNBs connected to the EPC. In some implementations, the X2 interface may include an X2 user plane interface (X2 User, X2-U) and an X2 control plane interface (X2 Control, X2-C). The X2-U may provide a flow control mechanism for user data packets forwarded via the X2 interface and may be used to communicate information regarding the distribution of user data between eNBs or gNBs. For example, X2-U can provide specific sequence number information for user data transferred from a Master eNB (MeNB) to a Secondary eNB (SeNB), information regarding the success of sequence delivery of PDCP packet data units (PDUs) for user data from the SeNB to the UE410, information regarding PDCP PDUs that were not provided to the UE410, and information regarding the current minimum desired buffer size in the SeNB for sending user data to the UE. X2-C can provide LTE in-access mobility functionality (including, for example, context transfer from source eNB to destination eNB, user plane transport control, etc.), load management functionality, and inter-cell interference coordination functionality.

[0045] As shown in the figure, RAN420 may be connected to CN430 (e.g., communicatively coupled). CN430 may comprise multiple network elements 432 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UE410) connected to CN430 via RAN420. In some implementations, CN430 may include an evolved packet core (EPC), a 5G CN, and / or one or more additional or alternative types of CNs. The components of CN430 may be implemented on a single physical node or separate physical nodes, including components for reading and executing instructions from machine-readable or computer-readable media (e.g., non-temporary machine-readable storage media). In some implementations, Network Function Virtualization (NFV) may be used to virtualize any or all of the roles or functions of the network node described above via executable instructions stored in one or more computer-readable storage media (described in more detail below). Logical instantiations of CN430 are sometimes referred to as network slices, and some logical instantiations of CN430 are sometimes referred to as network subslices. Using Network Function Virtualization (NFV) architectures and infrastructure, one or more network functions that would otherwise be performed by dedicated hardware can be virtualized on physical resources, including combinations of industry-standard server hardware, storage hardware, or switches. In other words, an NFV system can be used to run virtual or reconfigurable implementations of one or more EPC components / functions.

[0046] As shown in the figure, CN430, application server 440, and external network 450 can be connected to each other via interfaces 434, 436, and 438, which include IP network interfaces. Application server 440 is C N430 may include one or more server devices or network elements (e.g., virtual network functions (VNFs)) that provide applications using IP bearer resources (e.g., Universal Mobile Communications System Packet Services (UMTS) domains, LTE PS data services, etc.). The application server 440 may similarly, or alternatively, be configured to support one or more communication services for the UE410 via CN430 (e.g., Voice over IP (VoIP sessions, push-to-talk (PTT) sessions, group communication sessions, social networking services, etc.)). Similarly, the external network 450 may include one or more of various networks, including the Internet, thereby providing the UE410 of the mobile communication network and the network with access to various additional services, information, interoperability, and other network functions.

[0047] As shown in the figure, the exemplary network 400 may include an NTN that may have one or more satellites 460-1 and 460-2 (collectively, “Satellite 460”). Satellite 460 may communicate with UE 410 via a service link or wireless interface 462 and / or with RAN 420 via a feeder link or wireless interface 464 (indicated individually as 464-1 and 464). In some implementations, Satellite 460 may operate as a passive or transparent network relay node with respect to communication between UE 410 and the terrestrial network (e.g., RAN 420). In some implementations, Satellite 460 may operate as an active or regenerative network node with respect to communication between UE 410 and RAN 420, such that Satellite 460 can operate as a base station for UE 410 (e.g., as a gNB for RAN 420). In some implementations, satellites 460 can communicate with each other via a direct wireless interface (e.g., 466) or an indirect wireless interface (e.g., via RAN420 using interfaces 464-1 and 464-2).

[0048] Additionally or alternatively, satellite 460 may include a GEO satellite, a LEO satellite, or another type of satellite. Similarly, or alternatively, satellite 460 may relate to one or more satellite systems or architectures, such as a Global Navigation Satellite System (GNSS), a Global Positioning System (GPS), a Global Navigation Satellite System (GLONASS), or a Beidou Navigation Satellite System (BDS), in some implementations, satellite 460 may operate as a base station (e.g., RAN node 422) for UE 410. Accordingly, references to base stations, RAN nodes 422, etc. in this specification may include implementations in which base stations, RAN nodes 422, etc. are terrestrial network nodes and implementations in which base stations, RAN nodes 422, etc. are non-terrestrial network nodes (e.g., satellite 460). As described herein, UE 410 and base station 422 can communicate with each other via interface 414 to enable enhanced power saving techniques.

[0049] Figures 5 to 7 illustrate examples of time-domain validity 500, 600, and 700 in one or more implementation forms described herein. Figure 5 may include an example of a one-time validity window for one or more resources. The UE 410 may be configured to communicate MAC CE messages with IUC requests or IUC information, and the resources indicated in the message (e.g., A3, B2, etc.) may not be periodic. This may indicate that the resources are selected as one-time resources or one-time use resources. For example, as shown in Figure 5, the one-time validity period for the A3 resource may extend from the time the IUC message (e.g., an IUC request message or an IUC information message) is received until the end of the next A3 resource. Similarly, the one-time validity period for the B2 resource may extend from the time the IUC message (e.g., an IUC request message or an IUC information message) is received until the end of the next B2 resource.

[0050] Figure 6 may include an example of a validity period for one or more resources. UE 410 may be configured to communicate MAC CE messages along with IUC requests or IUC information, and resources indicated in the message (e.g., A3, B2, etc.) may include a validity period. The validity period may include the duration for which the resource can be used for IUC communication between UE 410s. The validity period may include a start time and an end time. Additionally or alternatively, the validity period may begin upon receipt of the IUC message and extend to an end time (e.g., an upper limit) indicated in the message. As shown in Figure 6, an IUC message may indicate resources A3 and B2, and may include a validity period that includes several A3 resources and multiple B2 resources, each having its own periodicity. In some implementations, when the validity period or duration includes only one instance of a resource (e.g., one instance of B2 and / or A3), the time or duration may have the same effect as a one-time validity period.

[0051] Figure 7 may include an example of an effective window for one or more resources. UE 410 may be configured to communicate MAC CE messages along with IUC requests or IUC information, and resources indicated in the message (e.g., A3, B2, etc.) may include one or more effective windows. An effective window may include the duration for which the resource can be used for IUC communication between UE 410s. An effective window may include a start time and an end time, and an IUC message may indicate multiple effective windows. As shown in Figure 6, an IUC message may indicate resources A3 and B2, each of which may include two different effective windows containing resources A3 and B2. In some implementations, an IUC message may specifically indicate each effective window. In some implementations, an IUC message may indicate the effective window duration, the periodicity of the effective window, and the amount of effective window interaction. In some implementations, an IUC message may indicate whether the effective window is periodic or aperiodic. In some implementations, when an active window contains only one instance of a resource (e.g., one instance of B2 and / or A3), the active window may have the same effect as a one-time active window.

[0052] In some implementations, the validity period or window indicated in an IUC message may differ for different resources. In some implementations, an IUC request from the UE may include a desired or preferred validity period. In some implementations, the validity period or validity window may be configured entirely or partially by RRC messaging via the Uu interface (e.g., in an SIB or another pre-configured message). When the validity period or window is explicitly given by an SL MAC CE or RRC message, the UE 410 may filter the indicated resource using a known validity period when generating an IUC information message.

[0053] In some implementations, when no validity period is introduced or configured, an IUC information message may default to a one-time use scenario (e.g., discarded when the transmitting UE 410 uses the corresponding resource). In such a scenario, the IUC information message may provide valid candidate resources (e.g., preferred resources) for a periodic sequence, and the receiving UE 410 may use one or more of the candidate resources, except that the “first” candidate resource is used as a one-time use resource. In some implementations, an IUC information message may remain valid until new IUC information is received from the same UE 410, regardless of its content (e.g., whether the new content conflicts with the content of the previous IUC information message). In some implementations, an IUC information message containing resources and / or valid information of a certain periodicity may remain valid until a new IUC information message of the same periodicity is received. In some implementations, the information in an IUC information message may remain valid until explicitly canceled in another MAC-CE signal or message.

[0054] In some implementations, when two validity periods or windows overlap, the most recently received validity period or window may be used for each resource cycle (e.g., for resources and instances where the overlap occurs). In some implementations, when UE 410 recognizes that a validity window received in a previous IUC information message is still valid, UE 410 may be prevented from using that validity window in another IUC information message unless specifically requested to do so in the IUC request message.

[0055] The validity period (e.g., duration or window) can be expressed as the start time plus the validity period. In some implementations, the start time may be the first occurrence of a resource in a periodic sequence, so that resources with different time slots may expire at different times. In some implementations, the start time may be when the IUC informational message is received, regardless of the periodicity of individual resources. In some implementations, the validity period may be explicitly indicated by a window (e.g., start and end times), and only resources within that window may be valid. In some implementations, the validity period may be expressed as an integer value representing "how many periods of the resource sequence can be extended." For example, each resource may be valid for 10 periods, and therefore, if the period is 100 ms, the validity period may be 1 second.

[0056] Figures 8 to 10 illustrate examples 800, 900, and 1000 of IUC messaging using different periodicities in one or more implementations described herein. As shown in Figure 8, UE 410-2 may be configured to send multiple MAC CE IUC request messages of different periodicities to UE 410-1 (810 and 820), and UE 410-1 may multiplex the MAC CE IUC request messages into a single MAC CE IUC information message (830). As shown in Figure 9, UE 410-2 may be configured to send multiple MAC CE IUC request messages of different periodicities to UE 410-1 (920 and 930), and UE 410-1 may place IUC information of different periodicities in different MAC CEs, or multiplex the MAC CEs in the same MAC packet data unit (PDU) transport block (TB) (930). As shown in Figure 10, UE 410-2 may be configured to send MAC CE IUC request messages of different periodicities to UE 410-1 (in 1010 and 1030), and UE 410-1 may respond to each request individually using MAC CEs with IUC information of different periodicities (in 1020 and 1040). UE 410-2 may not be permitted to send another IUC request until it has responded to the first request received or the IUC request time limit has expired. Communications 810, 820, 910, 920, 1010, and 1030 are shown in Figures 8 to 10 as optional, so that 410-1 may be configured to send communications 830, 930, 1020, and 1040 without receiving a request from UE 410-2.

[0057] Figures 11 and 12 illustrate examples of latency limits for IUC messaging in one or more implementations described herein. Figure 11 illustrates an example of a latency limit for IUC messages. As described herein, IUC request messages and IUC response messages (sometimes referred to herein as “IUC informational messages”) can be coupled or dependent on each other, for example, so that an IUC informational message responding to an IUC request message is sent and received within a specified duration. An IUC informational message received after that specified duration is invalid.

[0058] An IUC request message may include a resource selection window in which UE 410-2 can select a resource to communicate with UE 410-1 based on the IUC information message. As shown in the figure, the resource selection window may include a start time (Time_A) and an end time (Time_B). In some implementations, UE 410-2 and / or UE 410-1 may determine a latency limit or latency point endpoint based on the earliest value of the resource selection window (e.g., Time_A). In some implementations, the latency limit may be configured by RRC signaling. When latency has already been configured via RRC and the resource selection window is available, UE 410-2 and / or UE 410-1 may determine a latency limit or latency endpoint based on the duration of the configured latency measured from Time_0 and / or the start time of the selection window, depending on which is earlier or later. In some implementations, UE 410-1 may be configured to select the earlier of Time_A and Time_0 as the latency limit, so that the UE can ensure that the resources included in the IUC information message are received by UE 410-2 by the time the resource selection window begins. In some other implementations, UE 410-1 may be configured to select a value after Time_A and Time_0 as the latency limit, so that UE 410-1 has enough time to generate accurate IUC information based on sufficient detection history, which may involve waiting for the maximum allowable latency to send the IUC information message.

[0059] Figure 12 illustrates an example of a latency limit for IUC messages, including a processing gap. As described herein, IUC request messages and IUC response messages (sometimes referred to herein as “IUC informational messages”) can be coupled or dependent on each other, for example, so that an IUC informational message responding to an IUC request message is sent and received within a specified duration. An IUC informational message received after that specified duration is invalid.

[0060] The processing gap may include the duration required to request UE 410-2 to receive and process the IUC informational message, as described herein. In addition to one or more of the latency limiting techniques described above, the latency limit may include the resource window start time (Time_A) minus the processing gap. This may help ensure that the requesting UE 410-2 can receive and process the IUC informational message before the resource selection window.

[0061] Figures 13 and 14 illustrate examples 1300 and 1400 of IUC messaging and interaction with DRX in one or more implementations described herein. As shown in Figure 13, UE 410-2 can communicate a MAC CE IUC request to UE 410-1 (at 1310). If SL DRX is used in UE 410-2 to send the IUC request to UE 410-1, the reception of the IUC request may implement an additional active time for UE 410-2. The additional active time may be from the time UE 410-1 receives the IUC request (T_0) until the expiration of the IUC bound (e.g., T_0 + IUC_BOUND). Thus, since UE 410-2 is assumed to be active during the IUC limit, UE 410-1 can send a MAC CE IUC informational message (at 1320) within the IUC delay limit. Upon receiving MAC CE IUC information, UE 410-2 may transition to DRX inactive for the remainder of the IUC delay limit.

[0062] Referring to Figure 14, UE 410-2 can communicate a MAC CE IUC request to UE 410-1 (at 1410). If SL DRX is used in UE 410-2 to send the IUC request to UE 410-1, the receipt of the IUC request may implement additional active time by UE 410-2. The additional active time may be from the time UE 410-1 receives the IUC request (T_0) until the expiration of the IUC bound (e.g., T_0 + IUC_BOUND). Thus, since UE 410-2 is assumed to be active during the IUC limit, UE 410-1 can send a MAC CE IUC information message (at 1420) within the IUC delay limit. As shown in Figure 14, the IUC information may be sent together with SL DATA. Receiving SL DATA can keep UE 410-2 in the SL active state because the SL DATA may cause UE 410-2 to subsequently start the SL-DRX inactive timer.

[0063] In a scenario where UE 410-2 uses SL DRX for voluntary transmission of IUC information to UE 410-2 (for example, without a request from UE 410-2), UE 410-1 may do so when UE 410-2 is in a DRX active state (for example, without the extended DRX active state described above, see Figures 13-14). Other factors, such as a high channel busy ratio (CBR) or a high link packet error rate (PER), may also determine whether / when UE 410-1 uses voluntary transmission to send IUC information. Additionally or alternatively, when the IUC information does not exhibit periodicity, UE 410-1 may assume a single-use or one-time indicator of the resource. Additionally or alternatively, UE 410-1 may indicate only preferred resource slots that are within UE 410-2's DRX active time (for example, when the onDuration timer is running).

[0064] In a scenario where UE 410-1 uses SL DRX for transmission from UE 410-2 to UE 410-2, UE 410-1 may only share (or indicate preferred resources) resources that are within UE 410-1's DRX active time (e.g., when the onDuration timer is running). In such an implementation, UE 410-1 may only consider its active time for peer UE 410-2 in the SL-DRX unicast configuration (e.g., for transmission only to UE 410-2 instead of one or more other UEs). A unicast scenario may involve a UE sending a message or signal to a specific UE, as opposed to multiple UEs. Alternatively, when preferred resources cannot be found or are insufficient within this DRX configuration, UE 410-1 may include resources within UE 410-1's SL DRX configuration active time for other peer UEs and / or UE 410-1 for broadcast / groupcast traffic (e.g., resources that could be used to transmit to multiple UEs).

[0065] Figure 15 is a diagram of Example 1500 of IUC messaging and interaction with DRX in one or more implementation forms described herein. Mode 1 UE 410-1 support for requesting SL grants from gNB may be considered to enable one or more of the techniques described herein. Mode 1 SL may include scenarios in which a base station may allocate resources for SL communication. UE 410-1 may add an additional DRX "active time" based on the time limit of the IUC request message for the DRX active time of UE 410-2, and the serving base station 422 of UE 410-1 may not be aware of the change in the DRX active time of UE 410-2. Therefore, base station 422 may still allocate a "late" SL grant to match the old DRX active time of UE 410-2. Example 1500 includes techniques to address this problem and scenario, including an SL buffer status report (BSR) mechanism.

[0066] As shown in the diagram, base station 422 may (at 1510) provide UE 410-1 with an RRC configuration indicating that a logical channel group (LCG) (e.g., an LCG with ID "X") is DRX exempt. This may mean that the LCG can be used to override the DRX mechanism for base station 422's mode 1 resource allocation. UE 410-1 may (at 1520) receive a MAC CE IUC request from UE 410-2. UE 410-1 may (at 1530) send an SL BSR indicating the LCG ID along with an appropriate buffer size (e.g., buffer size N). The buffer size may correspond to at least the amount of data to be transmitted on the sidelink associated with the logical channel ID used by the IUC MAC CE. Then, base station 422 may (at 1540) respond to UE 410-1 with a mode 1 PDCCH:SL grant allocation message. This can be done without considering the SL destination DRX configuration, since the LCG ID is designated for "DRX exemption". The LCG ID may be configured to include the SL logical channel (LCH) priority for the SL MAC CE. Additionally or alternatively, with the SL grant received, UE 410-1 may proceed by providing UE 410-2 with a MAC CE IUC information message according to the limit delay of the IUC request message (at 1550). In some implementations, the technique described in Figure 15 may be used for issuing any mode 1 SL grant when base station 422 is unable to track the DRX active time of the SL destination, and this may not be limited to the IUC procedure.

[0067] Figure 16 is a diagram illustrating an example of the components of a device in one or more implementations described herein. In some implementations, device 1600 may include, at least as shown, a jointly coupled application circuit configuration 1602, a baseband circuit configuration 1604, an RF circuit configuration 1606, a front-end module (FEM) circuit configuration 1608, one or more antennas 1610, and a power management circuitry (PMC) 1612. The components of device 1600 shown may be included in a UE or RAN node. In some implementations, device 1600 may include fewer elements (for example, a RAN node may not utilize the application circuit configuration 1602 and instead include a processor / controller that processes IP data received from a CN such as a 5GC130 or an evolved packet core (EPC)). In some implementations, device 1600 may include additional elements such as memory / storage, a display, a camera, sensors (including one or more temperature sensors, such as a single temperature sensor or multiple temperature sensors located in different locations within device 1600), or input / output (I / O) interfaces. In other implementations, the components described below may be contained in two or more devices (for example, the above circuit configuration may be contained separately in two or more devices in a Cloud-RAN (C-RAN) implementation).

[0068] The application circuit configuration 1602 may include one or more application processors. For example, the application circuit configuration 1602 may include, but is not limited to, one or more single-core processors or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled to memory / storage or may include memory / storage, and may be configured to execute instructions stored in memory / storage to enable various applications or operating systems to run on device 1600. In some implementations, the processors of the application circuit configuration 1602 can process IP data packets received from the EPC.

[0069] The baseband circuit configuration 1604 may include, but is not limited to, one or more single-core processors or multi-core processors. The baseband circuit configuration 1604 may include one or more baseband processors or control logic that process baseband signals received from the receiving signal path of the RF circuit configuration 1606 and generate baseband signals for the transmitting signal path of the RF circuit configuration 1606. The baseband circuit configuration 1604 can interface with the application circuit configuration 1602 for generating and processing baseband signals and controlling the operation of the RF circuit configuration 1606. For example, in some implementations, the baseband circuit configuration 1604 may include a 3G baseband processor 1604A, a 4G baseband processor 1604B, a 5G baseband processor 1604C, or another baseband processor(s) 1604D for other existing, developing, or future generations (e.g., 2G, 6G, etc.). The baseband circuit configuration 1604 (for example, one or more of the baseband processors 1604A-D) can handle various radio control functions that enable communication with one or more radio networks via the RF circuit configuration 1606. In other implementations, some or all of the functions of the baseband processors 1604A-D may be contained in modules stored in memory 1604G and executed via the Central Processing Unit (CPU) 1604E. Radio control functions may include, but are not limited to, signal modulation / demodulation, coding / decoding, and radio frequency shifting. In some implementations, the modulation / demodulation circuit configuration of the baseband circuit configuration 1604 may include Fast Fourier Transform (FFT), precoding, or constellation mapping / demapping functionality. In some implementations, the encoding / decoding circuit configuration of the baseband circuit configuration 1604 may include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity check (LDPC) encoder / decoder functionality.The implementation forms of modulation / demodulation and encoder / decoder functionality are not limited to these examples, and other implementation forms may include other suitable functionalities.

[0070] In some implementations, the baseband circuit configuration 1604 may include one or more audio digital signal processors (DSPs) 1604F. The audio DSPs 1604F may include elements for compression / decompression and echo cancellation, and in other implementations, may include other suitable processing elements. The components of the baseband circuit configuration may be suitably combined within a single chip, a single chipset, or, in some implementations, arranged on the same circuit board. In some implementations, some or all of the components of the baseband circuit configuration 1604 and the application circuit configuration 1602 may be integrated on, for example, a system on a chip (SOC).

[0071] In some implementations, the baseband circuit configuration 1604 can provide communication compatible with one or more wireless technologies. For example, in some implementations, the baseband circuit configuration 1604 can support communication with NG-RAN, Evolved Universal Terrestrial Radio Access Network (EUTRAN), or other wireless metropolitan area networks (WMAN), wireless local area networks (WLAN), wireless personal area networks (WPAN), etc. An implementation in which the baseband circuit configuration 1604 is configured to support wireless communication of two or more wireless protocols can be called a multimode baseband circuit configuration.

[0072] The RF circuit configuration 1606 can enable communication with a wireless network using modulated electromagnetic radiation over a non-solid medium. In various implementations, the RF circuit configuration 1606 may include switches, filters, amplifiers, etc., to facilitate communication with the wireless network. The RF circuit configuration 1606 may include a received signal path that may include a circuit configuration that downconverts the RF signal received from the FEM circuit configuration 1608 and provides the baseband signal to the baseband circuit configuration 1604. The RF circuit configuration 1606 may also include a transmitted signal path that may include a circuit configuration that upconverts the baseband signal provided by the baseband circuit configuration 1604 and provides the RF output signal to the FEM circuit configuration 1608 for transmission.

[0073] In some implementations, the receive signal path of the RF circuit configuration 1606 may include a mixer circuit configuration 1606A, an amplifier circuit configuration 1606B, and a filter circuit configuration 1606C. In some implementations, the transmit signal path of the RF circuit configuration 1606 may include a filter circuit configuration 1606C and a mixer circuit configuration 1606A. The RF circuit configuration 1606 may also include a combiner circuit configuration 1606D that combines the frequencies used by the mixer circuit configuration 1606A of the receive signal path and the transmit signal path. In some implementations, the mixer circuit configuration 1606A of the receive signal path may be configured to downconvert the RF signal received from the FEM circuit configuration 1608 based on the combined frequency provided by the combiner circuit configuration 1606D. The amplifier circuit configuration 1606B can be configured to amplify the down-converted signal, and the filter circuit configuration 1606C may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal can be provided to the baseband circuit configuration 1604 for further processing. In some implementations, the output baseband signal may be a 0-frequency baseband signal, but this is not a requirement. In some implementations, the mixer circuit configuration 1606A in the received signal path may include a passive mixer, but the range of implementations is not limited to this.

[0074] In some implementations, the mixer circuit configuration 1606A in the transmit signal path may be configured to upconvert the input baseband signal based on the combined frequency provided by the combiner circuit configuration 1606D to generate the RF output signal for the FEM circuit configuration 1608. The baseband signal may also be provided by the baseband circuit configuration 1604 and may be filtered by the filter circuit configuration 1606C.

[0075] In some implementations, the receive signal path mixer circuit configuration 1606A and the transmit signal path mixer circuit configuration 1606A may include two or more mixers, each configured for quadrature down-conversion and quadrature up-conversion. In some implementations, the receive signal path mixer circuit configuration 1606A and the transmit signal path mixer circuit configuration 1606A may include two or more mixers, each configured for image removal (e.g., Hartley image removal). In some implementations, the receive signal path mixer circuit configuration 1606A and mixer circuit configuration 2006A may be configured for direct down-conversion and direct up-conversion, respectively. In some implementations, the receive signal path mixer circuit configuration 1606A and the transmit signal path mixer circuit configuration 1606A can be configured for superheterodyne operation.

[0076] In some implementations, the output baseband signal and input baseband signal may be analog baseband signals, but the scope of implementations is not limited to this. In some alternative implementations, the output baseband signal and input baseband signal may be digital baseband signals. In these alternative implementations, the RF circuit configuration 1606 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuit configurations, and the baseband circuit configuration 1604 may include a digital baseband interface for communicating with the RF circuit configuration 1606.

[0077] In some dual-mode implementations, separate wireless IC circuit configurations may be provided to process signals for each spectrum, but the range of implementations is not limited to this.

[0078] In some implementations, the combiner circuit configuration 1606D may be a fractional N combiner or a fractional N / N+1 combiner, and other types of frequency combiners may also be suitable, so the range of implementations is not limited in this respect. For example, the combiner circuit configuration 1606D may be a combiner equipped with a phase-locked loop having a delta-sigma combiner, a frequency multiplier, or a frequency divider.

[0079] The combiner circuit configuration 1606D can be configured to combine the output frequencies used by the mixer circuit configuration 1606A of the RF circuit configuration 1606 based on the frequency input and the frequency divider control input. In some implementations, the combiner circuit configuration 1606D may be a fractional N / N+1 combiner.

[0080] In some implementations, the frequency input may be provided by a voltage-controlled oscillator (VCO), but this is not a requirement. The divider control input can be provided by either the baseband circuit configuration 1604 or the application circuit configuration 1602, depending on the desired output frequency. In some implementations, the divider control input (e.g., N) can be determined from a lookup table based on the channel shown by the application circuit configuration 1602.

[0081] The combiner circuit configuration 1606D of the RF circuit configuration 1606 may include a frequency divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some implementations, the frequency divider may be a dual modulus divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some implementations, the DMD may be configured to divide the input signal by either N or N+1 (e.g., based on performance) to provide a fractional frequency ratio. In some exemplary implementations, the DLL may include a set of cascaded tunable delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these implementations, the delay elements may be configured to divide the VCO period into Nd packets of equal phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay across the delay lines is one VCO cycle.

[0082] In some implementations, the combiner circuit configuration 1606D can be configured to generate the carrier frequency as the output frequency, while in other implementations, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency), and can be used in conjunction with quadrature generator and frequency divider circuit configurations to generate multiple signals with multiple different carrier frequencies having multiple different phases relative to each other. In some implementations, the output frequency may be the LO frequency (fLO). In some implementations, the RF circuit configuration 1606 can include an IQ / polarity converter.

[0083] The FEM circuit configuration 1608 may include a receive signal path that includes a circuit configuration configured to operate on an RF signal received from one or more antennas 1610, amplify the received signal, and provide the amplified version of the received signal to the RF circuit configuration 1606 for further processing. The FEM circuit configuration 1608 may also include a transmit signal path that includes a circuit configuration configured to amplify a signal for transmission provided by the RF circuit configuration 1606, transmitted by one or more of the antennas 1610. In various implementations, amplification through the transmit or receive signal path may occur in the RF circuit configuration 1606 only, in the FEM circuit configuration 1608 only, or in both the RF circuit configuration 1606 and the FEM circuit configuration 1608.

[0084] In some implementations, the FEM circuit configuration 1608 may include a TX / RX switch for switching between transmit and receive mode operation. The FEM circuit configuration may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit configuration may include an LNA that amplifies the received RF signal and provides the amplified received RF signal as an output (e.g., to the RF circuit configuration 1606). The transmit signal path of the FEM circuit configuration 1608 may include a power amplifier (PA) that amplifies the input RF signal (e.g., provided by the RF circuit configuration 1606), and one or more filters that generate an RF signal for subsequent transmission (e.g., by one or more of the antennas 1610).

[0085] In some implementations, the PMC1612 can manage the power supplied to the baseband circuit configuration 1604. Specifically, the PMC1612 can control power source selection, voltage scaling, battery charging, or DC-DC conversion. When device 1600 is battery-powered, for example, when this device is included in the UE, the PMC1612 can often be included. The PMC1612 can improve power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

[0086] Figure 16 shows the PMC 1612 coupled only with the baseband circuit configuration 1604. However, in other implementations, the PMC 1612 can be coupled additionally or instead with other components, including but not limited to the application circuit configuration 1602, the RF circuit configuration 1606, or the FEM circuit configuration 1608, to perform similar power management operations.

[0087] In some implementations, the PMC1612 can control, or be part of, various power-saving mechanisms of device 1600. For example, if device 1600 is in the RRC_Connected state, still connected to a RAN node because it is expected to receive traffic soon, after a certain period of inactivity, the device can enter a state known as discontinuous receive mode (DRX). During this state, device 1600 can conserve power by cutting off power at short intervals.

[0088] If there is no data traffic activity for an extended period, device 1600 can transition to the RRC_Idle state, disconnecting from the network and not performing actions such as channel quality feedback or handover. Device 1600 enters a very low power state and periodically wakes up to listen to the network and then powers down again to perform paging. In this state, device 1600 cannot receive data. To receive data, it can transition back to the RRC_Connected state.

[0089] In additional power-saving modes, devices may be allowed to be unavailable from the network for longer periods than the paging interval (ranging from a few seconds to several hours). During this time, the device may be completely unreachable from the network and may be completely powered off. Any data transmitted during this period will experience significant delays, but these delays are considered acceptable.

[0090] The processors of application circuit configuration 1602 and baseband circuit configuration 1604 can be used to execute elements of one or more instances of the protocol stack. For example, the processors of baseband circuit configuration 1604 can be used alone or in combination to execute Layer 3, Layer 2, or Layer 1 functionality, and the processors of application circuit configuration 1604 can use the data received from these layers (e.g., packet data) to further execute Layer 4 functionality (e.g., the Transmission Communication Protocol (TCP) layer and the User Datagram Protocol (UDP) layer). As described herein above, Layer 3 may include the RRC layer, which is described in more detail below. As described herein above, Layer 2 may include the medium access control (MAC) layer, the radio link control (RLC) layer, and the packet data convergence protocol (PDCP) layer, which are described in more detail below. As described above in this specification, Layer 1 may include the physical (PHY) layer of the UE / RAN node, which is described in more detail below.

[0091] Figure 17 shows an exemplary interface of a baseband circuit configuration relating to one or more implementation forms described herein. As described above, the baseband circuit configuration 1604 of Figure 16 may comprise processors 1604A to 1604E and memory 1604G used by these processors. Each of the processors 1604A to 1604E may include memory interfaces 1704A to 1704E for sending and receiving data to and from memory 1604G.

[0092] The baseband circuit configuration 1604 may further include one or more interfaces for communicative coupling with other circuit configurations / devices, such as a memory interface 1712 (e.g., an interface for transmitting / receiving data to and from memory outside the baseband circuit configuration 1604), an application circuit configuration interface 1714 (e.g., an interface for transmitting / receiving data to and from the application circuit configuration 1602 in Figure 16), an RF circuit configuration interface 1716 (e.g., an interface for transmitting / receiving data to and from the RF circuit configuration 1606 in Figure 16), a wireless hardware connection interface 1718 (e.g., an interface for transmitting / receiving data to and from near-field communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 1720 (e.g., an interface for transmitting / receiving power or control signals to and from the PMC 1612).

[0093] Figure 18 is a diagram of a control plane protocol stack according to several embodiments. In this embodiment, the control plane 1800 is shown as a communication protocol stack between network devices or entities.

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

[0095] MAC Layer 1802 can perform mapping between logical channels and transport channels, multiplexing MAC service data units (SDUs) from one or more logical channels onto transport blocks (TBs) delivered to the PHY via transport channels, demultiplexing MAC SDUs from transport blocks (TBs) delivered to the PHY via transport channels to one or more logical channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction via hybrid automatic repeat requests (HARQs), and logical channel prioritization.

[0096] The RLC layer 1803 can operate in multiple operating modes, including Transparent Mode (TM), Unacknowledged Mode (UM), and / or Acknowledged Mode (AM). The RLC layer 1803 can perform the transfer of upper layer protocol data units (PDUs), error correction by automatic repeat requests (ARQs) for AM data transmission, and the concatenation, splitting, and reassembly of RLC SDUs for UM and AM data transmission. The RLC layer 1803 may also perform the resplification of RLC data PDUs for AM data transmission, reorder RLC data PDUs for UM and AM data transmission, detect duplicate data for UM and AM data transmission, discard RLC SDUs for UM and AM data transmission, detect protocol errors for AM data transmission, and perform RLC re-establishment.

[0097] PDCP layer 1804 can perform header compression and decompression of IP data, maintain PDCP sequence numbers (SNs), perform in-sequence delivery of upper layer PDUs in lower layer re-establishment, remove duplicate lower layer SDUs in lower layer re-establishment for radio bearers mapped on RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification of control plane data, control timer-based data discarding, and perform security operations (e.g., encryption, decryption, integrity protection, integrity verification).

[0098] The main services and functions of RRC Layer 1805 include broadcasting system information (e.g., contained in a Master Information Block (MIB) or System Information Block (SIB) relating to the non-access stratum (NAS)), broadcasting system information relating to the access stratum (AS), paging, establishing, maintaining, and releasing RRC connections (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, RRC connection release), establishing, configuring, maintaining, and releasing point-to-point wireless bearers, security functions including key management, wireless access technology (RAT) mobility, and measurement configurations for UE measurement reporting. MIBs and SIBs may each contain one or more information elements (IEs) that may contain individual data fields or data structures.

[0099] UE and RAN nodes can exchange control plane data via a protocol stack including PHY layer 1801, MAC layer 1802, RLC layer 1803, PDCP layer 1804, and RRC layer 1805 using a Uu interface (e.g., NR interface).

[0100] The Non-Access Layer (NAS) protocol 1806 forms the top layer of the control plane between the UE and the core network (CN). The NAS protocol 1806 may support UE mobility and session management procedures to establish and maintain IP connectivity between the UE and the network.

[0101] Figure 19 is a block diagram showing several exemplary implementations of a component capable of reading instructions from a machine-readable medium or computer-readable medium (e.g., a non-temporary machine-readable storage medium) and executing any one or more of the methods described herein. Specifically, Figure 19 shows a schematic representation of a hardware resource 1900, which includes one or more processors (or processor cores) 1910, one or more memory / storage devices 1920, and one or more communication resources 1930, each of which can be communicatively coupled via a bus 1940. In implementations utilizing node virtualization (e.g., NFV), a hypervisor 1902 may be run to provide execution environments for one or more network slices / subslice for utilizing the hardware resource 1900.

[0102] Processor 1910 (for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a composite instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application-specific integrated circuit (ASIC), a high-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 1912 and processor 1914.

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

[0104] The communication resource 1930 may include interconnection or network interface components or other suitable devices for communicating with one or more peripheral devices 1904 or one or more databases 1906 via the network 1908. For example, the communication resource 1930 may include wired communication components (for coupling via, for example, Universal Serial Bus (USB)), cellular communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components.

[0105] Instruction 1950 may include software, programs, applications, applets, apps, or other executable code to cause at least one of the processors 1910 to execute any one or more of the methodologies discussed herein. Instruction 1950 may reside entirely or partially within at least one of the processors 1910 (e.g., within the processor's cache memory), within the memory / storage device 1920, or within any suitable combination thereof. Furthermore, any part of instruction 1950 may be transferred to the hardware resource 1900 from any combination of peripheral devices 1904 or database 1906. Thus, the memory of processor 1910, the memory / storage device 1920, the peripheral device 1904, and the database 1906 are examples of computer-readable and machine-readable media.

[0106] The embodiments herein may include subject matter such as methods, means for performing actions or blocks of those methods, and at least one machine-readable medium containing executable instructions that, when executed by a machine (such as a processor with memory, an Application-Specific Integrated Circuit (ASIC), or a Field Programmable Gate Array (FPGA)), cause the machine to perform actions of a method or apparatus or system for simultaneous communication using the multiplexing techniques described in the embodiments and embodiments.

[0107] Example 1, which may include one or more of the examples described herein, is a baseband processor for a user's equipment (UE), comprising one or more processors, the one or more processors receiving one or more Inter-UE Coordination (IUC) Request messages via a sidelink (SL) transmission from another UE, each of the one or more IUC Request messages corresponding to a different periodicity, responding to the other UE via an SL transmission using one or more IUC Information messages corresponding to the one or more IUC Request messages, each of the one or more IUC Information messages indicating at least one wireless resource associated with time-domain validity that the other UE is permitted to use to communicate with the UE, the one or more IUC Information messages being latency limits with respect to the one or more IUC Request messages, thereby the one or more IUC Information messages being received by the other UE within the duration of the latency limits, the baseband processor.

[0108] In Example 2, which may include one or more of the examples described herein, the latency limit is based on a resource selection window received from another UE. In Example 3, which may include one or more of the examples described herein, the latency limit is based on a configured time value received via Uu Radio Resource Control (RRC) signaling by the base station or PC5 RRC signaling by another UE. In Example 4, which may include one or more of the examples described herein, the latency limit includes a processing gap corresponding to the duration for another UE to process the IUC informational message. In Example 5, which may include one or more of the examples described herein, the processing gap is configured by the base station.

[0109] Example 6, which may include one or more of the examples described herein, involves one or more IUC information messages comprising multiple IUC information messages, each IUC information message indicating a wireless resource having a different periodicity, and the multiple IUC information messages being multiplexed using a single Media Access Control (MAC) control element (CE). Example 7, which may also include one or more of the examples described herein, involves one or more IUC request messages comprising multiple IUC request messages, and one or more processors being configured to respond to the multiple IUC request messages within a single delay limit associated with the multiple IUC request messages.

[0110] Example 8, which may include one or more of the examples described herein, Time domain validity corresponds to the time domain duration request indicated in the IUC request message from another UE. Example 9, which may include one or more of the examples described herein, Time-domain validity is set by the base station communicating with the UE. In Example 10, which may include one or more of the examples described herein, time-domain validity is set by another UE via PC5 Radio Resource Control (RRC). In Example 11, which may include one or more of the examples described herein, at least one radio resource includes multiple radio resources included in the MAC CE, and each of the multiple radio resources has a different periodicity. .

[0111] Example 10, which may include one or more of the examples described herein, is configured such that one or more IUC request messages comprise multiple IUC request messages, and one or more processors respond to the first IUC request message of the multiple IUC request messages using a first MAC CE that includes a first IUC information message corresponding to the periodicity of the first IUC request message, and respond to the second IUC request message of the multiple IUC request messages using a second MAC CE that includes a second IUC information message corresponding to the periodicity of the second IUC request message which is different from the periodicity of the first IUC request message.

[0112] Example 11, which may include one or more of the examples described herein, is a user device (UE) comprising a memory device containing instructions and one or more processors, wherein when one or more processors execute an instruction, one or more processors cause one or more processors to receive one or more Inter-UE Coordination (IUC) Request messages via a sidelink (SL) transmission from another UE, each of the one or more IUC Request messages corresponding to a different periodicity, and causes the other UE to respond via an SL transmission using one or more IUC Information messages corresponding to the one or more IUC Request messages, each of the one or more IUC Information messages indicating at least one wireless resource associated with time-domain validity that the other UE is permitted to use to communicate with the UE, and one or more IUC Information messages are latency limits with respect to one or more IUC Request messages, thereby the one or more IUC Information messages are received by the other UE within the duration of the latency limits.

[0113] Example 12, which may include one or more of the examples described herein, is a method performed by a user device (UE), the method comprising: receiving one or more Inter-UE Coordination (IUC) Request messages via a Sidelink (SL) transmission from another UE, each of the one or more IUC Request messages corresponding to a different periodicity; and responding to the other UE via the SL transmission using one or more IUC Informational messages corresponding to the one or more IUC Request messages, each of the one or more IUC Informational messages indicating at least one wireless resource associated with time-domain validity that the other UE is permitted to use to communicate with the UE; and the one or more IUC Informational messages are latency limits with respect to the one or more IUC Request messages, thereby the one or more IUC Informational messages being received by the other UE within the duration of the latency limits.

[0114] The above description of the illustrated embodiments, implementations, and aspects of the disclosed subject matter, including the contents of the abstract, is not intended to be exhaustive or to limit the disclosed aspects to the exact forms disclosed. Specific embodiments, implementations, and aspects are described herein for illustrative purposes, but those skilled in the art will see that various modifications are possible within the scope of such embodiments, implementations, and aspects.

[0115] In this regard, while the disclosed subject matter has been described in relation to various embodiments, implementations, and aspects and corresponding drawings, it should be understood that other similar embodiments may be used, or modifications and additions may be made to the disclosed subject matter, in order to perform the same, similar, alternative, or substitute functions as the subject matter, without departing from the disclosed subject matter. Accordingly, the disclosed subject matter should not be limited to any single embodiment, implementation, or aspect described herein, but rather should be interpreted in accordance with the breadth and scope of the appended claims below.

[0116] Specifically, with respect to the various functions performed by the aforementioned components or structures (assemblies, devices, circuits, systems, etc.), the terms used to describe such components (including descriptions related to “means”) are intended to correspond to any component or structure that performs a particular function of the described component (e.g., functionally equivalent), even if it is not structurally equivalent to the disclosed structure that performs the function of the exemplary implementation of the Invention illustrated herein. Furthermore, while specific features may be disclosed with respect to only one of several implementations, such features may be combined with one or more other features of other implementations so as to be desirable and advantageous for any given or particular application.

[0117] As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise specified or it is clear from the context, “X uses A or B” is intended to mean any of all possible permutations. That is, “X uses A,” “X uses B,” or “X uses both A and B” all satisfy the condition “X uses A or B.” In addition, the articles “a” and “an” used in this application and the attached claims should generally be interpreted as meaning “one or more” unless otherwise specified or it is clear from the context that they refer to a singular form. Furthermore, where “including,” “includes,” “having,” “has,” “with,” or their variations are used in either the modes of carrying out the invention or the claims, these terms are intended to be inclusive, as is the term “comprising.” Furthermore, in situations where one or more numbered items (e.g., "the first X," "the second X," etc.) are being described, these one or more numbered items may generally be distinct or identical, but in some situations the context may indicate that the one or more numbered items are distinct or identical.

[0118] It is well understood that the use of personal information should adhere to privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for maintaining user privacy. In particular, personal data should be managed and handled in a manner that minimizes the risk of unintended or unauthorized access or use, and the nature of authorized use should be clearly indicated to the user.

Claims

1. A baseband processor, The system comprises one or more processors, and the one or more processors are connected to the user equipment (UE), Receiving an Inter-UE Coordination (IUC) request message transmitted by a first Media Access Control (MAC) control element (CE) via a sidelink (SL) transmission from another UE, wherein the first MAC CE includes a single resource reservation cycle. The configuration is configured to cause the second MAC CE to respond to the other UE via SL transmission using an IUC information message transmitted by the second MAC CE, wherein the IUC information message indicates at least one wireless resource that the other UE is permitted to use to communicate with the UE, The IUC information message corresponds to the single resource reservation cycle indicated by the IUC request message, based on the fact that the second MAC CE is responding to the first MAC CE. The IUC information message is reported within the latency limit for the IUC request message by a baseband processor.

2. The baseband processor according to claim 1, wherein the latency limit is based on a resource selection window received from the other UE.

3. The baseband processor according to claim 2, wherein the latency limit is based on a set time value received via Uu Radio Resource Control (RRC) signaling by a base station or PC5 RRC signaling by the other UE.

4. The baseband processor according to claim 3, wherein the latency limit includes a processing gap corresponding to the duration for the other UE to process the IUC information message.

5. The baseband processor according to claim 4, wherein the processing gap is set by the base station.

6. The baseband processor according to claim 1, wherein the UE transmits different IUC information messages for different resource reservation cycles using different MACCEs, and each MACCE is transmitted in a separate transport block such that each MACCE corresponds to only one resource reservation cycle.

7. A method performed by a user device (UE), wherein the method is Receiving an Inter-UE Coordination (IUC) request message transmitted by a first Media Access Control (MAC) control element (CE) via a sidelink (SL) transmission from another UE, wherein the first MAC CE includes a single resource reservation cycle. Responding to the other UE via SL transmission using an IUC information message transmitted by a second MAC CE in response to the IUC request message, wherein the IUC information message indicates at least one wireless resource that the other UE is permitted to use to communicate with the UE, The second MAC CE corresponds to the single resource reservation cycle indicated by the IUC request message, A method by which the IUC information message is reported within the latency limit relating to the IUC request message.

8. The method according to claim 7, wherein the UE transmits different IUC information messages for different resource reservation cycles using different MACCEs, and each MACCE is transmitted in a separate transport block such that each MACCE corresponds to only one resource reservation cycle.

9. The method according to claim 8, further comprising, when multiple IUC request messages with different resource reservation cycles are received, responding with a plurality of corresponding IUC information messages such that all of the plurality of corresponding IUC information messages are transmitted within a single delay limit common to the plurality of IUC request messages.

Images