Sidelink DRX optimization for RRC_CONNECTED user equipment (UE)

Abstract

SL-DRX involves both Uu and PC5 interfaces. For RRC_CONNECTED UEs (also called connected mode UEs, or simply connected UEs), several SL-DRX enhancements for triggering SL DRX and sharing configuration are described in this disclosure. Alignment of SL-DRX with Uu-DRX alignment (referred to as Uu / SL DRX alignment or simply alignment) is also described as an optional feature (as not all scheduling can be aligned in time).

Description

Technical Field

[0001] The present application generally relates to wireless communication systems, including sidelinks for User Equipment (UE) to UE communications. Background Art

[0002] Wireless mobile communication technology uses various standards and protocols to transmit data between base stations and wireless mobile devices. Wireless communication system standards and protocols may include the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., 4G) or New Radio (NR) (e.g., 5G); the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, which is generally referred to by industry organizations as Worldwide Interoperability for Microwave Access (WiMAX); and the IEEE 802.11 standard for wireless local area networks (WLANs), which is generally referred to by industry organizations as Wi-Fi. In the 3GPP radio access network (RAN) in the LTE system, the base station may include a RAN node such as an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as an evolved Node B, an enhanced Node B, an eNodeB, or an eNB) and / or a radio network controller (RNC) in the E-UTRAN, which communicates with a wireless communication device referred to as a user equipment (UE). In the fifth generation (5G) wireless RAN, the RAN nodes may include 5G nodes, NR nodes (also called next generation Node B or g NodeB (gNB)).

[0003] The RAN uses radio access technologies (RATs) to communicate between RAN nodes and UEs. The RAN may include a global system for mobile communications (GSM), an enhanced data rate for GSM evolution (EDGE) RAN (GERAN), a universal terrestrial radio access network (UTRAN), and / or an E-UTRAN, which provides access to communication services through a core network. Each RAN in the RAN operates according to a specific 3GPP RAT. For example, GERAN implements GSM and / or EDGE RAT, UTRAN implements Universal Mobile Telecommunications System (UMTS) RAT or other 3GPP RAT, E-UTRAN implements LTE RAT, and NG-RAN implements 5G RAT. In some deployments, E-UTRAN may also implement 5G RAT.

[0004] The frequency bands for 5G NR can be divided into two different frequency ranges. Frequency range 1 (FR1) may include frequency bands operating at frequencies below 6 GHz, some of which may be used by previous standards and may potentially be expanded to cover new spectrum products from 410 MHz to 7125 MHz. Frequency range 2 (FR2) may include frequency bands from 24.25 GHz to 52.6 GHz. The frequency bands in the millimeter wave (mmWave) range of FR2 may have a smaller range but potentially higher available bandwidth than the frequency bands in FR1. The skilled person will recognize that these frequency ranges, which are provided by way of example, may vary from time to time or region to region. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] To easily identify the discussion of any particular element or act, the most significant digit(s) in a reference number refers to the drawing number that first introduces the element.

[0006] Figure 1 is a block diagram of a system for wireless communications according to one embodiment.

[0007] Figure 2 is an annotated block diagram of a system for wireless communications according to one embodiment.

[0008] Figure 3 is an annotated block diagram of a system for wireless communications according to one embodiment.

[0009] Figure 4A is an annotated block diagram of a system for wireless communications according to one embodiment.

[0010] Figure 4B is an annotated timing diagram showing non-overlapping and overlapping onDurations according to one embodiment.

[0011] Figure 5A is an annotated timing diagram illustrating DRX alignment according to one embodiment.

[0012] Figure 5B is an annotated timing diagram showing two versions of adjacent DRX cycles according to one embodiment.

[0013] Figure 6 is a table showing full alignment and partial alignment according to one embodiment.

[0014] Figure 7 is an annotated timing diagram showing another example of DRX alignment, according to one embodiment.

[0015] Figure 8is a table showing drx-LongCycleStartOffset according to one embodiment.

[0016] Fig. 9 is a message flow diagram according to one embodiment.

[0017] Fig. 10A is a message flow diagram according to one embodiment.

[0018] Fig. 10B is a message flow diagram according to one embodiment.

[0019] Fig.11 is a block diagram according to one embodiment. DETAILED DESCRIPTION

[0020] Figure 1 An exemplary architecture of a system 100 of a network according to various embodiments is shown. The following description is provided for an example system 100 operating in conjunction with LTE system standards and 5G or NR system standards provided by 3GPP technical specifications. However, the exemplary embodiments are not limited in this regard, and the embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G)) systems, IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), and the like.

[0021] like Figure 1 As shown, the system 100 includes a UE 122 and a UE 120. In this example, the UE 122 and the UE 120 are illustrated as smart phones (e.g., handheld touch screen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing devices, such as consumer electronic devices, mobile phones, smart phones, feature phones, tablet computers, wearable computer devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment (IVI), in-car entertainment (ICE) devices, instrument clusters (ICs), heads-up display (HUD) devices, on-board diagnostics (OBD) devices, dashboard mobile equipment (DME), mobile data terminals (MDTs), electronic engine management systems (EEMS), electronic / engine control units (ECUs), electronic / engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMS), connected or "smart" appliances, MTC devices, M2M, IoT devices, etc.

[0022] In some embodiments, UE 122 and / or UE 120 may be an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. The IoT UE may utilize technologies such as M2M or MTC to exchange data with an MTC server or device via PLMN, ProSe or D2D communications, sensor networks, or IoT networks. M2M or MTC data exchanges may be machine-initiated data exchanges. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network.

[0023] UE 122 and UE 120 may be configured to be connected, e.g., communicatively coupled, to an access node or radio access node (shown as (R)AN 108). In an embodiment, (R)AN 108 may be an NG RAN or SG RAN, an E-UTRAN, or a traditional RAN, such as a UTRAN or GERAN. As used herein, the term "NG RAN" or the like may refer to an (R)AN 108 operating in an NR or SG system, and the term "E-UTRAN" or the like may refer to an (R)AN 108 operating in an LTE or 4G system. UE 122 and UE 120 utilize connections (or channels) (shown as connection 104 and connection 102, respectively), each connection (or channel) comprising a physical communication interface or layer (discussed in further detail below).

[0024] In this example, connection 104 and connection 102 are air interfaces for enabling communication coupling, and may conform to a cellular communication protocol, such as a GSM protocol, a CDMA network protocol, a PTT protocol, a POC protocol, a UMTS protocol, a 3GPP LTE protocol, a SG protocol, a NR protocol, and / or any other communication protocol discussed herein. In an embodiment, UE 122 and UE 120 may exchange communication data directly via a ProSe interface 110. ProSe interface 110 may alternatively be referred to as a sidelink (SL) interface 110, and may include one or more logical channels, including, but not limited to, PSCCH, PSSCH, PSDCH, and PSBCH.

[0025] UE 120 is illustrated as being configured to access AP 112 (also referred to as a "WLAN node," "WLAN," "WLAN terminal," "WT," etc.) via connection 124. Connection 124 may include a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where AP 112 would include Wireless Fidelity (WFI). ) router. In this example, AP 112 may be connected to the Internet without being connected to a core network of the wireless system (described in further detail below). In various embodiments, UE 120, (R)AN 108, and AP 112 may be configured to utilize LWA operation and / or LWIP operation. LWA operation may involve UE 120 in RRC_CONNECTED being configured by RAN node 114 or RAN node 116 to utilize radio resources of LTE and WLAN. LWIP operation may involve UE 120 using WLAN radio resources (e.g., connection 124) via an IPsec protocol tunnel to authenticate and encrypt packets (e.g., IP packets) sent over connection 124. IPsec tunneling may include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

[0026] (R)AN 108 may include one or more AN nodes, such as RAN node 114 and RAN node 116, that enable connection 104 and connection 102. As used herein, the terms "access node," "access point," and the like may describe a device that provides radio baseband functionality for data and / or voice connections between a network and one or more users. These access nodes may be referred to as BSs, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs, or TRPs, and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the terms "NG RAN nodes," and the like may refer to RAN nodes (e.g., gNBs) operating in NR or SG systems, while the terms "E-UTRAN nodes," and the like may refer to RAN nodes (e.g., eNBs) operating in LTE or 4G systems 100. According to various embodiments, the RAN node 114 or the RAN node 116 may be implemented as one or more of dedicated physical devices such as a macrocell base station and / or a low power (LP) base station for providing a femtocell, picocell or other similar cell with a smaller coverage area, smaller user capacity or higher bandwidth than a macrocell.

[0027] In some embodiments, all or part of the RAN node 114 or RAN node 116 may be implemented as one or more software entities running on a server computer as part of a virtual network that may be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP). In these embodiments, the CRAN or vBBUP may implement RAN functional splits, such as PDCP splits, where the RRC and PDCP layers are operated by the CRAN / vBBUP, while other L2 protocol entities are operated by individual RAN nodes (e.g., RAN node 114 or RAN node 116); MAC / PHY splits, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP, and the PHY layer is operated by individual RAN nodes (e.g., RAN node 114 or RAN node 116); or "lower PHY" splits, where the RRC, PDCP, RLC, MAC layers, and upper portions of the PHY layers are operated by the CRAN / vBBUP, and the lower portions of the PHY layers are operated by individual RAN nodes. This virtualization framework allows idle processor cores of the RAN node 114 or RAN node 116 to execute other virtualized applications. In some specific implementations, each RAN node may represent a node via each F1 interface ( Figure 1 In some implementations, the gNB-DUs may include one or more remote radio heads or RFEMs, and the gNB-CUs may be operated by a server (not shown) located in the (R)AN 108 or by a server pool in a manner similar to the CRAN / vBBUP. Additionally or alternatively, one or more of the RAN node 114 or the RAN node 116 may be a next generation eNB (ng-eNB), which is a RAN node that provides E-UTRA user plane and control plane protocol terminations to the UE 122 and the UE 120 and is connected to the SGC via an NG interface (discussed below). In a V2X scenario, the RAN node 114 or one or more of the RAN nodes 116 may be an RSU or act as an RSU.

[0028] The term "roadside unit" or "RSU" may refer to any traffic infrastructure entity used for V2X communications. The RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, wherein an RSU implemented in or by a UE may be referred to as a "UE-type RSU", an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU", an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU", and so on. In one example, the RSU is a computing device coupled to a radio frequency circuit located on the roadside that provides connectivity support to passing vehicle UEs (vUEs). The RSU may also include internal data storage circuits for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may operate on the 5.9 GHz direct short range communication (DSRC) band to provide extremely low latency communications required for high-speed events, such as collision avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may operate on a cellular V2X band to provide the aforementioned low-latency communications as well as other cellular communications services. Additionally or alternatively, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communications. Some or all of the computing device and the RSU's RF circuitry may be packaged in a weather-resistant enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller and / or backhaul network.

[0029] The RAN node 114 and / or the RAN node 116 may terminate the air interface protocol and may be the first point of contact for the UE 122 and the UE 120. In some embodiments, the RAN node 114 and / or the RAN node 116 may perform various logical functions of the (R)AN 108, including but not limited to radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0030] In an embodiment, UE 122 and UE 120 may be configured to communicate with each other or with RAN node 114 and / or RAN node 116 over a multi-carrier communication channel using OFDM communication signals according to various communication techniques, such as, but not limited to, OFDMA communication techniques (e.g., for downlink communications) or SC-FDMA communication techniques (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0031] In some embodiments, a downlink resource grid may be used for downlink transmissions from RAN node 114 and / or RAN node 116 to UE 122 and UE 120, while uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or a time-frequency resource grid, which is a physical resource in the downlink in each time slot. For OFDM systems, such a time-frequency plane representation is common practice, which makes radio resource allocation intuitive. Each column and each row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a set of resource elements; in the frequency domain, this may represent the minimum amount of resources that can currently be allocated. Such resource blocks are used to transmit several different physical downlink channels.

[0032] According to various embodiments, UE 122 and UE 120 and RAN node 114 and / or RAN node 116 communicate data (e.g., transmit data and receive data) through a licensed medium (also referred to as a "licensed spectrum" and / or a "licensed frequency band") and an unlicensed shared medium (also referred to as an "unlicensed spectrum" and / or an "unlicensed frequency band"). The licensed spectrum may include channels operating in a frequency range of approximately 400 MHz to approximately 3.8 GHz, and the unlicensed spectrum may include a 5 GHz frequency band.

[0033] To operate in the unlicensed spectrum, the UE 122 and the UE 120 and the RAN node 114 or the RAN node 116 may operate using LAA, eLAA, and / or feLAA mechanisms. In these specific implementations, the UE 122 and the UE 120 and the RAN node 114 or the RAN node 116 may perform one or more known medium sensing operations and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmitting in the unlicensed spectrum. The medium / carrier sensing operations may be performed according to a listen-before-talk (LBT) protocol.

[0034] LBT is a mechanism by which a device (e.g., UE 122 and UE 120, RAN node 114 or RAN node 116, etc.) senses a medium (e.g., a channel or carrier frequency) and transmits when the medium is sensed to be idle (or when a particular channel in the medium is sensed to be unoccupied). The medium sensing operation may include a CCA that utilizes at least an ED to determine whether other signals are present on the channel in order to determine whether the channel is occupied or idle. The LBT mechanism allows cellular / LAA networks to coexist with existing systems in unlicensed spectrum and with other LAA networks. ED may include sensing RF energy over a period of time on an expected transmission band and comparing the sensed RF energy to a predefined or configured threshold.

[0035] Typically, existing systems in the 5 GHz band are WLANs based on IEEE 802.11 technology. WLANs use a contention-based channel access mechanism called CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS) such as UE 122, AP 112, etc.) intends to transmit, the WLAN node may first perform CCA before transmission. In addition, in the case where more than one WLAN node senses the channel as idle and transmits at the same time, a backoff mechanism is used to avoid conflicts. The backoff mechanism may be a counter randomly introduced within the CWS that increases exponentially when a conflict occurs and is reset to a minimum value when the transmission is successful. The LBT mechanism designed for LAA is somewhat similar to the CSMA / CA of WLAN. In some specific implementations, the LBT process for a DL or UL transmission burst (including PDSCH or PUSCH transmission) may have a LAA contention window of variable length between X and Y ECCA slots, where X and Y are the minimum and maximum values ​​of the CWS of LAA. In one example, the minimum CWS for LAA transmissions may be 9 microseconds (μs); however, the size of the CWS and MCOT (eg, transmission burst) may be based on government regulatory requirements.

[0036] The LAA mechanism is built on the CA technology of the LTE-Advanced system. In CA, each aggregated carrier is called a CC. A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated, so the maximum aggregated bandwidth is 100 MHz. In an FDD system, the number of aggregated carriers can be different for DL ​​and UL, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, each CC may have a different bandwidth from other CCs. In a TDD system, the number of CCs and the bandwidth of each CC are typically the same for DL ​​and UL.

[0037] CA also includes individual serving cells to provide individual CCs. The coverage of the serving cells may be different, for example, because CCs on different frequency bands will experience different path losses. The primary serving cell or PCell may provide the PCC for both UL and DL, and may handle activities related to RRC and NAS. Other serving cells are referred to as SCells, and each SCell may provide individual SCCs for both UL and DL. SCCs may be added and removed as needed, and changing PCCs may require the UE 122 to undergo a switch. In LAA, eLAA, and feLAA, some or all of the SCells may operate in an unlicensed spectrum (referred to as "LAA SCells"), and the LAA SCells are assisted by the PCells operating in the licensed spectrum. When a UE is configured with more than one LAA SCell, the UE may receive UL grants on the configured LAA SCells, indicating different PUSCH start positions within the same subframe.

[0038] The PDSCH carries user data and higher layer signaling to UE 122 and UE 120. The PDCCH carries, among other information, information about transport formats and resource allocations related to the PDSCH channel. It may also inform UE 122 and UE 120 about transport formats, resource allocations, and HARQ information related to uplink shared channels. Typically, downlink scheduling (allocation of control and shared channel resource blocks to UE 120 within a cell) may be performed at either RAN node 114 or RAN node 116 based on channel quality information fed back from either UE 122 and UE 120. Downlink resource allocation information may be sent on the PDCCH for (e.g., allocated to) each of UE 122 and UE 120.

[0039] PDCCH uses CCE to transmit control information. Before being mapped to resource elements, the PDCCH complex-valued symbols can first be organized into quadruplets, which can then be arranged using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to nine sets of four physical resource elements, respectively, called REGs. Four quadrature phase shift keying (QPSK) symbols can be mapped to each REG. Depending on the size of the DCI and channel conditions, one or more CCEs can be used to transmit the PDCCH. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation levels, L=1, 2, 4, or 8).

[0040] Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some embodiments may utilize EPDCCH that uses PDSCH resources for control information transmission. One or more ECCEs may be used to transmit EPDCCH. Similar to the above, each ECCE may correspond to nine sets of four physical resource elements, referred to as EREG. In some cases, ECCE may have other numbers of EREGs.

[0041] The RAN node 114 or the RAN node 116 may be configured to communicate with each other via the interface 130. In an embodiment where the system 100 is an LTE system (e.g., when the CN 106 is an EPC), the interface 130 may be an X2 interface. The X2 interface may be defined between two or more RAN nodes (e.g., two or more eNBs, etc.) connected to the EPC, and / or between two eNBs connected to the EPC. In some specific implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user packets transmitted over the X2 interface, and may be used to transmit information about the delivery of user data between eNBs. For example, the X2-U may provide specific sequence number information about user data transmitted from the MeNB to the SeNB; information about the successful delivery of PDCP PDUs from the SeNB to the UE 122 in sequence for user data; information about PDCP PDUs that are not delivered to the UE 122; information about the current minimum expected buffer size at the Se NB for transmitting user data to the UE; and the like. X2-C can provide intra-LTE access mobility functions, including context transfer from source eNB to target eNB, user plane transmission control, etc.; load management functions; and inter-cell interference coordination functions.

[0042] In an embodiment where the system 100 is an SG or NR system (e.g., when the CN 106 is an SGC), the interface 130 may be an Xn interface. The Xn interface is defined between two or more RAN nodes (e.g., two or more gNBs, etc.) connected to an SGC, between a RAN node 114 (e.g., a gNB) and an eNB connected to an SGC, and / or between two eNBs connected to a 5GC (e.g., CN 106). In some specific implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U may provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and flow control functions. The Xn-C may provide management and error handling functions for managing the functions of the Xn-C interface; mobility support for UE 122 in a connected mode (e.g., CM-CONNECTED) includes functions for managing UE mobility in a connected mode between one or more RAN nodes 114 or RAN nodes 116. Mobility support may include context transfer from the old (source) service RAN node 114 to the new (target) service RAN node 116, and control of the user plane tunnel between the old (source) service RAN node 114 and the new (target) service RAN node 116. The protocol stack of Xn-U may include a transport network layer built on an Internet Protocol (IP) transport layer, and a GTP-U layer on top of a UDP and / or IP layer for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn Application Protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP may be on top of the IP layer and may provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transport is used to deliver signaling PDUs. In other specific implementations, the Xn-U protocol stack and / or the Xn-C protocol stack may be the same or similar to the user plane and / or control plane protocol stacks shown and described herein.

[0043] (R)AN 108 is illustrated as being communicatively coupled to a core network—in this embodiment, to CN 106. CN 106 may include one or more network elements 132 configured to provide various data and telecommunication services to customers / subscribers (e.g., users of UE 122 and UE 120) connected to CN 106 via (R)AN 108. Components of CN 106 may be implemented in one physical node or separate physical nodes, including components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, NFV may be used to virtualize any or all of the above-described network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). A logical instantiation of CN 106 may be referred to as a network slice, and a logical instantiation of a portion of CN 106 may be referred to as a network sub-slice. NFV architecture and infrastructure may be used to virtualize one or more network functions onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches (alternatively performed by proprietary hardware). In other words, the NFV system may be used to perform a virtual or reconfigurable implementation of one or more EPC components / functions.

[0044] In general, the application server 118 may be an element that provides applications that use IP bearer resources with the core network (e.g., UMTS PS domain, LTE PS data services, etc.). The application server 118 may also be configured to support one or more communication services for UE 122 and UE 120 via the EPC (e.g., VoIP sessions, PTT sessions, group communication sessions, social network services, etc.). The application server 118 may communicate with the CN 106 via the IP communication interface 136.

[0045] In an embodiment, CN 106 may be an SGC, and (R)AN 116 may be connected to CN 106 via an NG interface 134. In an embodiment, NG interface 134 may be divided into two parts: an NG user plane (NG-U) interface 126, which carries traffic data between RAN node 114 or RAN node 116 and UPF; and an S1 control plane (NG-C) interface 128, which is a signaling interface between RAN node 114 or RAN node 116 and access and mobility management function (AMF).

[0046] In an embodiment, CN 106 may be an SG CN, while in other embodiments, CN 106 may be an EPC. In the case where CN 106 is an EPC, (R)AN 116 may be connected to CN 106 via an S1 interface 134. In an embodiment, S1 interface 134 may be divided into two parts: an S1 user plane (S1-U) interface 126, which carries service data between RAN node 114 or RAN node 116 and S-GW; and an S1-MME interface 128, which is a signaling interface between RAN node 114 or RAN node 116 and MME.

[0047] Figure 2 An example of a wireless communication system 200 for SL operation is shown. The wireless communication system 200 includes a gNB 202 communicatively coupled to a first UE 204 and a second UE 206. The first UE 204 is communicatively coupled to a fourth UE 208. The second UE 206 is communicatively coupled to a third UE 210 and a fifth UE 212. In the present example, the UEs are shown as vehicles because SL is typically used for vehicle-to-vehicle (V2V), which is a type of vehicle-to-everything (V2X) communication.

[0048] SL-DRX involves both Uu and PC5 interfaces.For RRC_CONNECTED UE (also called connected mode UE, or simply connected UE), several SL-DRX enhancements are described in this disclosure.

[0049] In general, the first enhancement requires the gNB to be able to trigger SL-DRX based on enhanced Uu MAC control element (CE) signaling to trigger the UE to enter DRX. In the DRX command from the gNB 202, an index can be used to point to one of the predefined (i.e., Uu or SL) DRX configurations. In one embodiment, the index is a pointer to the DRX configuration, such as a lookup table. To perform the lookup, the table is predefined. And which index value corresponds to which DRX configuration is also predefined. The table can be part of the RRC configuration via Uu RRC. For example, a Uu DRX command that triggers SL DRX 214 is provided between the gNB 202 and the first UE 204 via MAC CE layer-2 signaling. A SL DRX command 216 (also layer-2 signaling) is performed between the first UE 204 and the fourth UE 208. The Uu DRX MAC CE layer-2 command includes a flag (or 2 bits) to indicate that it will be used in Uu, SL, or both.

[0050] The second enhancement requires the UE to include its desired SL-DRX configuration or selection in the UEAssistanceInformation (UAI) message to the gNB. This can include all DRX operations (common DRX, link-specific DRX) that the UE participates in. It can also establish how much traffic is expected to be generated (e.g., how busy the link will be), so a DRX schedule (e.g., how often the UE wakes up) can be established. For example, a DRX configuration via Uu218 in the form of RRC layer-3 signaling is provided from the gNB 202 to the second UE 206 (the Uu can be specified to be used in the Uu interface or the PC5 interface or both). The second UE 206 provides the UAI for SL operation 220 to the gNB202. A DRX configuration via PC5 222 (also layer-3 signaling) is provided from the second UE 206 to the third UE 210. A DRX configuration via PC5 224 is established between the fifth UE 212 and the second UE 206 via layer-3 signaling. In other embodiments, a SidelinkUEInformation (SUI) message may be used.

[0051] The alignment of SL-DRX with Uu-DRX (referred to as Uu / SL DRX alignment or simply alignment) is also described as an optional feature (since not all schedules can be aligned in time).

[0052] Figure 3 is an annotated block diagram 300 showing an overview of the RRC configuration for the sidelink. A first gNB 302 providing a first coverage area 304 communicates wirelessly with a first UE 306 to form a Uu interface 308 between the first UE 306 and the first gNB 302. Thus, the first UE 306 is in RRC connected mode and can be configured for the sidelink via an RRCReconfigure message. A second gNB 310 provides a second coverage area 312. A second UE 314 is located in the second coverage area 312 but is in idle / inactive mode. However, it receives a common DRX configuration in a system information block (SIB). A PC 5-link specific configuration is also provided between the first UE 306 and the second UE 314 which already have a PC 5-RRC connection 316. Finally, a third UE 318 is pre-configured.

[0053] Therefore, in Figure 3 In the example of , a common configuration can be configured to all sidelink UEs in or out of coverage. This provides a baseline to ensure that the sidelink UE works even when the transmitter in the SL carrier is not always connected. The PC 5 link specific configuration is between two UEs with a PC5-RRC connection.

[0054] In some embodiments, the gNB makes power saving decisions for the UE based on information provided by the UE about its SL participation. If possible, the gNB will align Uu-DRX with common and / or link-specific SL-DRX. If alignment is not feasible, the gNB may still keep the DRX configuration separate. Alignment of SL-DRX with Uu-DRX is an optional feature. Skipping monitoring of PDCCH and skipping monitoring of PSCCH can be configured independently. The gNB is able to enable / disable support for this feature.

[0055] Figure 4A An exemplary SL DRX alignment with Uu DRX use case in a SL relay system 400 is shown to explain the possible benefits of SL / Uu DRX alignment for sidelink relay. In this example, the gNB 402 has a Uu DRX link 404 with a relay UE 406. The relay UE 406 has a PC5 link 408 with a remote UE 410. In addition to saving power, alignment can reduce unnecessary buffering in the sidelink relay and reduce overall end-to-end latency. For example, for DL ​​traffic, the traffic can be buffered twice: the first buffering 412 occurs at the gNB 402 because the relay UE 406 is in DRX inactive mode; the second buffering 414 occurs at the relay UE 406 because the remote UE 410 is DRX inactive for the PC5 link.

[0056] Figure 4B Two examples are shown, where the Uu-DRX and SL-DRX cycles are each spaced apart in time 416 and overlap in terms of wake-up time "onDuration" 418. When they overlap 418, for example due to alignment, the second buffering 414 may be alleviated.

[0057] There are RX chain considerations when implementing Uu / SL DRX alignment. RAN2 aims to specify a mechanism designed to align the sidelink DRX wake-up time with the Uu DRX wake-up time in UEs within coverage. But in every scenario, completely overlapping alignment may not always be desired. For example, in LTE ProSe, if the UE uses a single RX chain for WAN and D2D communications, a discovery gap is configured for the UE to switch to monitoring D2D signals. LTE ProSe supports commercial discovery, which may not justify a dedicated RX chain for D2D. In NR SL, SL and Uu can operate in the same frequency band. For example, n38 and n79 were added by RAN4 in Rel-16, and SL communications are not limited to the n47 ITS band. If the UE shares a single RX chain in a licensed band for both V2X SL and NR DL reception, it is not suitable for alignment of Uu-DRX and SL-DRX. The UE may be able to do simultaneous DL reception and SL reception (similar to intra-band CA), but TX in SL (as triggered in onDuration) will cause problems with PDCCH monitoring for Uu-DRX.Instead of perfect alignment, TDM gaps are implemented.

[0058] The above scenario generates the following two assumptions, which are respectively Figure 5A and Figure 5B It is shown by way of example.

[0059] First, for the case of separate RX chains, Uu-DRX and SL-DRX are aligned with overlapping "onDurations". Figure 5A Uu and SL are shown overlapping in an aligned common wake-up period (eg, dedicated RX chain for SL).

[0060] Second, for the case of a single RX chain, Uu-DRX and SL-DRX are aligned but use non-overlapping adjacent durations. Figure 5B Two examples are shown where Uu and SL do non-overlapping TDM in a shared / common wake-up period (e.g., single Rx chain, shared carrier). In this case, then there is still some benefit to aligning adjacently. For example, in the case of SL relays, buffering time can be minimized for DL ​​traffic. Even when DRX cycles do not overlap, it may be desirable to have them adjacent to each other so that traffic forwarding latency can be reduced.

[0061] refer to Figure 6, describes the coordination of SL-DRX with Uu DRX for connected mode. In NR, a UE can be configured with connected mode DRX (C-DRX) in Uu (short and long DRX cycles). It may be advantageous to suspend SL activity when Uu is in DRX mode for the following reasons: First, Mode 1 UE operation will be affected by Uu C-DRX. In NR-V2X Rel-16, RAN2 agrees that the UE does not expect DRX configuration if SL Mode 1 is configured in Rel-16. Second, power savings cannot be fully achieved if SL operation is still ongoing, as Uu RRC procedures for the sidelink are used even for Connected Mode 2 UEs, and SL operation can trigger some "activity" in Uu.

[0062] Figure 6 The impact on SL RX and TX in the case of alignment with Uu-DRX is summarized. Note that the table includes SL-DRX partial alignment. The following two paragraphs describe an example for implementing this behavior.

[0063] In a first implementation, the UE avoids Mode 1 operation when Uu DRX is configured. The UE switches to Mode 2TX (Autonomous Resource Selection). Sidelink RX is not disabled (so no power saving in SL). The network will enable / disable this "mode switch" with a flag. The UE no longer initiates any RRC messages (e.g. SidelinkUEInformation). The UE delays any reporting of new / modified QoS flows to the network and adopts the default SL radio bearer SLRB mapping for any QoS flow that does not have a configuration.

[0064] In a second implementation, SL RX is turned off whenever Uu DRX is inactive, but limited TX activity is allowed in the absence of sensing. This approach achieves improved power savings. Mode 2 UEs may transmit using random TX resource selection from the configured pool. Mode 1 UE TX is dependent on the configured grant type 2. HARQ feedback may be enabled or disabled, depending on whether the DRX INACTIVE UE is still able to receive the Physical Sidelink Feedback Channel (PSFCH).

[0065] Figure 7 An example of alignment of the DRX cycle in SL-DRX for connected mode is shown. In this example, the alignment of UuDRX and SL DRX means fully aligned and partially aligned option 2 ( Figure 6 ).exist Figure 7In , the same DRX cycle is applied to both downlink and sidelink. The cycle length is the same and the UE can skip both PDCCH and PSCCH monitoring. SL DRX can also use short and long cycles. OnDurations are aligned, but they do not have to be the same length, and SL-DRX can have a shorter onDuration. The inactivity timer configuration can also be different.

[0066] The Uu DRX configuration is a UE specific configuration and is not known to other UEs and is consistent with the previous reference Figure 3 C-DRX is arbitrary with many options, since DRX can start with any offset and period (see, for example, Figure 8 drx-LongCycleStartOffset). The gNB is aware of the DRX configuration so it can delay its DL traffic accordingly, but SL traffic is not controlled by the gNB. For SL DRX, if aligned with the Uu-DRX configuration (i.e., the gNB chooses one of the configurations and forces the UE to be consistent with the SL's configuration instead of using the default commonly known DRX cycle), any possible SL TX UE may not be aware of this as it may not know if the RX UE is in RRC_CONNECTED state and it is not aware that a coordinated Uu / SL-DRX configuration is used in the RX UE. If SL traffic is destined for that UE during DRX inactivity and that UE cannot be delayed appropriately, that traffic will not be properly received by a UE that aligns its own SL DRX cycle with the configured UuC-DRX cycle. Packet loss will increase for SL-DRX UEs that deviate from the commonly known SL DRX cycle.

[0067] In order to solve the above problems, Fig. 9An example of limiting the Uu DRX configuration to that of SL-DRX is shown (matching or aligning Uu-DRX with SL-DRX). In general, the gNB will decide what the best alignment can be provided, and then the gNB shares the configuration of that alignment with UE 1 (common to both Uu and SL). More specifically, the gNB (and neighboring gNBs) will broadcast the supported DRX cycles and offsets (a limited number of choices) to all UEs in the cell. The SL UE reports its SL participation and DRX configuration to the gNB (via Uu and received via PC5). The gNB determines which SL DRX cycle is based on the SL service (QoS profile, PSID) or SL address. If possible, the Uu DRX cycle is aligned with the SL DRX. If any SL TX sender knows that the RX UE can support SLDRX, it assumes DRX is enabled and transmits only in onDuration. The gNB can enable / disable this alignment with a flag. If not aligned, the gNB can configure the Uu-DRX with a separate parameter.

[0068] In another implementation to solve the above problem, the DRX configuration is communicated to other RRC_CONNECTED UEs via dedicated RRC signaling. If any connected UE B indicates that it is attempting to transmit to a SL target address involving RX of UE A, it shares UE A's DRX configuration to UE B in the RRCReconfig message. This method is applicable to connected UEs in the same cell.

[0069] In another implementation to address the above issue, a list of each UE and its DRX configuration is announced. The gNB (and neighboring gNBs) broadcasts the SL destination list and its corresponding DRX cycle in broadcast RRC signaling (SIB). This approach takes into account inter-gNB signaling.

[0070] In another embodiment that solves the above problem, there is a SL announcement at the start of DRX. When the inactivity timer is about to expire, the UE sends a PC5-RRC broadcast message about its own "aligned" DRX configuration to neighboring UEs. This approach envisions additional reliability enhancements because the broadcast may not reach all UEs, especially when other UEs may also be in SL-DRX.

[0071] In another embodiment to solve the above problem, Fig. 9 It is also shown that a UE can use PC5-RRC unicast messages to deliver its DRX configuration to UEs with PC5-RRC connections. UE 1 can notify peer UE 2 to also align its SL-DRX with this DRX configuration. This is suitable for UEs with SL unicast traffic to be served. For bidirectional traffic, the PC5 interface can be aligned to DRX.

[0072] Fig. 10A It shows how Uu activity and SL activity are not synchronized (different applications, different traffic profiles). When Uu traffic is suspended, SL traffic may still be ongoing, or vice versa. While the UE may be aware of both Uu and SL traffic, the gNB may not be aware of the SL traffic. When the gNB incorrectly assumes that UE1 is in DRX state, the gNB may delay DL traffic unnecessarily. This may not be a substantial problem because the UE still benefits from skipping PDCCH decoding. However, there are several implementations to address this issue.

[0073] In one embodiment, a single inactivity timer is redefined to take into account both Uu activity and SL activity. Hence, the UE goes into DRX when both interfaces are inactive, and does not go into DRX when either interface is active. In the absence of Uu traffic, the sidelink UE keeps the Uu busy so that the gNB will not misinterpret the DRX state. For example, the sidelink UE may send some dummy traffic in Uu while SL traffic is ongoing.

[0074] Fig. 10B Another implementation is shown. Separate inactivity timers in Uu and SL are maintained. The gNB cannot keep track of the SL inactivity timer, so the UE sends UL signaling to keep the gNB updated on the SL activity. A new UL MAC CE is designed for this purpose and it indicates the "predicted" start time of DRX based on the SL traffic activity. The timing received from the MAC CE overrides the default drx-inactivityTimer mechanism.

[0075] Fig.11 1 is a block diagram illustrating a component 1100 capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and capable of performing any one or more of the methods discussed herein, according to some exemplary embodiments. Specifically, Fig.11 A schematic diagram of hardware resources 1102 is shown, which includes one or more processors 1106 (or processor cores), one or more memory / storage devices 1114, and one or more communication resources 1124, each of which can be communicatively coupled via a bus 1116. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 1122 can be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 1102.

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

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

[0078] The communication resources 1124 may include interconnect or network interface components or other suitable devices to communicate with one or more peripheral devices 1104 or one or more databases 1120 via the network 1118. For example, the communication resources 1124 may include wired communication components (e.g., for coupling via a universal serial bus (USB)), cellular communication components, NFC components, Parts (e.g. Low power consumption), components and other communication components.

[0079] The instructions 1112 may include software, programs, applications, applet, applications, or other executable code for causing at least any one of the processors 1106 to perform any one or more of the methods discussed herein. The instructions 1112 may reside completely or partially within at least one of the processors 1106 (e.g., within a cache memory of a processor), the memory / storage device 1114, or any suitable combination thereof. In addition, any portion of the instructions 1112 may be transmitted to the hardware resources 1102 from any combination of the peripheral device 1104 or the database 1120. Therefore, the memory of the processor 1106, the memory / storage device 1114, the peripheral device 1104, and the database 1120 are examples of computer-readable and machine-readable media.

[0080] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes and / or methods described in the following examples section. For example, the baseband circuit described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the following examples. For another example, the circuits associated with the UE, base station, network element, etc. described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples shown in the examples section below.

[0081] Examples

[0082] The following examples relate to additional embodiments.

[0083] Embodiment 1. A method for entering sidelink (SL) discontinuous reception (DRX) performed by a first user equipment (UE) in connected mode with a gNB, the method comprising: receiving a Uu DRX MAC control element (CE) layer-2 command from the gNB to trigger the first UE to enter Uu or SL DRX indicated in the Uu DRX MAC CE layer-2 command; and processing the Uu DRX MAC CE layer-2 command to determine whether to enter Uu DRX or SL DRX with a second UE.

[0084] Embodiment 2. The method of embodiment 1, wherein the Uu DRX MAC CE layer-2 command includes an index indicating one of a predefined Uu DRX configuration or a SL DRX configuration.

[0085] Embodiment 3. The method according to embodiment 1 further includes RRC signaling to configure a lookup table so that the UuDRX MAC CE layer-2 command indicates a DRX configuration.

[0086] Embodiment 4. The method of embodiment 3, wherein the Uu DRX MAC CE Layer-2 command includes a flag to indicate whether the lookup table is used in Uu, in SL, or in both.

[0087] Embodiment 5. The method of Embodiment 3, wherein the lookup table is a concatenated table for both Uu and SL DRX.

[0088] Embodiment 6. The method of Embodiment 3, wherein the lookup table comprises two different tables and the Uu DRX MAC CE Layer-2 command comprises a flag to indicate which table to use.

[0089] Embodiment 7. A method for configuring sidelink (SL) discontinuous reception (DRX) performed by a first user equipment (UE) in connected mode with a gNB, the method comprising: generating a first RRC message including a desired SL-DRX configuration for the gNB; and in response to the first RRC message, receiving a second RRC message specifying the DRX configuration for one or both of a Uu interface and a PC5 interface from the gNB via Uu.

[0090] Embodiment 8. The method of embodiment 7, wherein the first RRC message comprises a UEAssistance Information (UAI) message, wherein the UAI message comprises a desired SL-DRX configuration.

[0091] Embodiment 9. The method according to embodiment 7, wherein the first RRC message includes a Sidelink UE Information (SUI) message, and the SUI message includes the desired SL-DRX configuration.

[0092] Embodiment 10. The method of embodiment 9, wherein a SUI or RRC message includes the DRX configuration used by the peer UE.

[0093] Embodiment 11. The method of embodiment 7, wherein the first RRC message includes parameters for common DRX operation.

[0094] Embodiment 12. The method of embodiment 7, wherein the first RRC message includes parameters for link-specific DRX operation.

[0095] Embodiment 13. A method for aligning discontinuous reception (DRX) performed by a first user equipment (UE) through Uu and a side link (SL), the alignment being performed by limiting the Uu-DRX configuration to a configuration aligned with the SL-DRX, the method comprising: providing a Uu RRC message to a gNB to report SL participation and DRX configuration; and receiving an RRCReconfigure message from the gNB to align the DRX cycle.

[0096] Embodiment 14. The method of embodiment 13, wherein the Uu RRC message comprises a UEAssistance Information (UAI) message.

[0097] Embodiment 15. The method of embodiment 13, wherein the Uu RRC message comprises a SidelinkUEInformation (SUI) message.

[0098] Embodiment 16. The method according to embodiment 13 also includes receiving an initial SidelinkReconfig layer-3 message from a second UE to cause the first UE to provide the Uu RRC message to the gNB.

[0099] Embodiment 17. The method according to embodiment 13 also includes receiving a message from the gNB to disable alignment.

[0100] Embodiment 18. The method of embodiment 13 further comprises providing a SidelinkReconfig layer-3 message to a second UE having a PC5 interface with the first UE.

[0101] Embodiment 19. A non-transitory computer-readable storage medium, comprising instructions, which, when executed by a first user equipment (UE) that is in connected mode with a gNB and enters sidelink (SL) discontinuous reception (DRX), causes the first UE to perform the following operations: receive a Uu DRX MAC control element (CE) layer-2 command from the gNB to trigger the first UE to enter Uu or SL DRX indicated in the Uu DRX MAC CE layer-2 command; and process the Uu DRX MAC CE layer-2 command to determine whether to enter Uu DRX or SL DRX with a second UE.

[0102] Embodiment 20. The computer-readable storage medium of embodiment 19, wherein the Uu DRX MAC CE layer-2 command comprises an index representing one of a predefined Uu DRX configuration or a SL DRX configuration.

[0103] Embodiment 21. The computer-readable storage medium of embodiment 19, wherein the instructions further configure the first UE to RRC signal to configure a lookup table such that the Uu DRX MAC CE layer-2 command indicates a DRX configuration.

[0104] Embodiment 22. The computer-readable storage medium of Embodiment 21, wherein the Uu DRX MAC CE Layer-2 command includes a flag to indicate whether the lookup table is used in Uu, in SL, or in both.

[0105] Embodiment 23. The computer readable storage medium of Embodiment 21, wherein the lookup table is a concatenated table for both Uu and SL DRX.

[0106] Embodiment 24. The computer-readable storage medium of Embodiment 21, wherein the lookup table comprises two different tables and the Uu DRX MAC CE Layer-2 command comprises a flag to indicate which table to use.

[0107] Embodiment 25. A non-transitory computer-readable storage medium comprising instructions which, when executed by a user equipment (UE), cause the UE to perform the following operations: generate a first RRC message including a desired SL-DRX configuration for the gNB; and in response to the first RRC message, receive a second RRC message specifying a DRX configuration for one or both of a Uu interface and a PC5 interface from the gNB via Uu.

[0108] Embodiment 26. The computer-readable storage medium of embodiment 25, wherein the first RRC message comprises a UEAssistance Information (UAI) message, the UAI message comprising a desired SL-DRX configuration.

[0109] Embodiment 27. The computer-readable storage medium of embodiment 25, wherein the first RRC message comprises a Sidelink UE Information (SUI) message, the SUI message comprising the desired SL-DRX configuration.

[0110] Embodiment 28. The computer-readable storage medium of Embodiment 27, wherein a SUI or RRC message includes the DRX configuration used by a peer UE.

[0111] Embodiment 29. The computer-readable storage medium of Embodiment 25, wherein the first RRC message includes parameters for common DRX operation.

[0112] Embodiment 30. The computer-readable storage medium of Embodiment 25, wherein the first RRC message includes parameters for link-specific DRX operation.

[0113] Embodiment 31. A non-transitory computer-readable storage medium comprising instructions which, when executed by a first user equipment (UE), cause the computer to perform the following operations: provide a Uu RRC message to a gNB to report SL participation and DRX configuration; and receive an RRCReconfigure message from the gNB to align a DRX cycle.

[0114] Embodiment 32. The computer-readable storage medium of embodiment 31, wherein the Uu RRC message comprises a UEAssistance Information (UAI) message.

[0115] Embodiment 33. The computer-readable storage medium of embodiment 31, wherein the Uu RRC message comprises a Sidelink UE Information (SUI) message.

[0116] Embodiment 34. A computer-readable storage medium according to embodiment 31, wherein the instructions further configure the UE to receive an initial SidelinkReconfig layer-3 message from a second UE to cause the first UE to provide the Uu RRC message to the gNB.

[0117] Embodiment 35. A computer-readable storage medium according to embodiment 31, wherein the instructions further configure the first UE to receive a message from the gNB to disable alignment.

[0118] Embodiment 36. The computer-readable storage medium of Embodiment 31, wherein the instructions further configure the first UE to provide a SidelinkReconfig layer-3 message to a second UE having a PC5 interface with the first UE.

[0119] Embodiment 37 may include an apparatus comprising means for performing one or more elements of a method described in or related to any of the above embodiments or any other method or process described herein.

[0120] Embodiment 38 may include one or more non-transitory computer-readable media, which include instructions that, when executed by one or more processors of the electronic device, cause the electronic device to perform one or more elements of a method described in or related to any of the above embodiments or any other method or process described herein.

[0121] Embodiment 39 may include a device comprising logic components, modules, or circuits for performing one or more elements of the method described in or related to any of the above embodiments or any other method or process described herein.

[0122] Embodiment 40 may include any of the methods, techniques or processes described in or related to the above embodiments, or parts or components thereof.

[0123] Embodiment 41 may include a device comprising: one or more processors and one or more computer-readable media, wherein the one or more computer-readable media include instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process, or portion thereof, described in any one of the above embodiments or related thereto.

[0124] Embodiment 42 may include signals or parts or components thereof as described in or related to any of the above embodiments.

[0125] Embodiment 43 may include a datagram, packet, frame, segment, protocol data unit (PDU) or message or a portion or component thereof as described in any of the above embodiments or related thereto, or as otherwise described in the present disclosure.

[0126] Embodiment 44 may include any of the above embodiments or related thereto, or a signal encoded with data or a portion or component thereof described in other ways in this disclosure.

[0127] Embodiment 45 may include a signal or a portion or component thereof encoded with a datagram, packet, frame, segment, PDU or message as described in any of the above embodiments or in connection therewith, or otherwise in the present disclosure.

[0128] Embodiment 46 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process, or a portion thereof, described in or related to any of the above embodiments.

[0129] Embodiment 47 may include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform a method, technique, or process, or a portion thereof, described in or related to any of the above embodiments.

[0130] Embodiment 48 may include signals in a wireless network as shown and described herein.

[0131] Embodiment 49 may include a method of communicating in a wireless network as shown and described herein.

[0132] Embodiment 50 may include a system for providing wireless communications as shown and described herein.

[0133] Embodiment 51 may include an apparatus for providing wireless communications as shown and described herein.

[0134] Unless explicitly stated otherwise, any of the above embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. Modifications and variations are possible in view of the above teachings or may be obtained from the practice of the various embodiments.

[0135] Embodiments and implementations of the systems and methods described herein may include various operations that may be embodied in machine executable instructions to be executed by a computer system. A computer system may include one or more general or special purpose computers (or other electronic devices). A computer system may include hardware components that include specific logic components for performing operations, or may include a combination of hardware, software, and / or firmware.

[0136] It should be appreciated that the systems described herein include descriptions of specific embodiments. These embodiments may be combined into a single system, partially incorporated into other systems, separated into multiple systems, or otherwise divided or combined. In addition, it is contemplated that parameters, attributes, aspects, etc. of one embodiment may be used in another embodiment. For clarity, these parameters, attributes, aspects, etc. are described only in one or more embodiments, and it should be appreciated that unless otherwise stated herein, these parameters, attributes, aspects, etc. may be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment.

[0137] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

[0138] Although the foregoing has been described in considerable detail for the sake of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles of the invention. It should be noted that there are many alternative ways to implement both the processes and the apparatus described herein. Therefore, the embodiments of the present invention are to be regarded as illustrative rather than restrictive, and the specification is not limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1. A method for entering sidelink SL discontinuous reception DRX performed by a first user equipment UE in a connected mode with a base station, the method comprising: receiving a Uu DRX MAC control element layer-2 command, i.e., a Uu DRX MAC CE layer-2 command, from the base station to trigger the first UE to enter Uu or SL DRX indicated in the Uu DRX MAC CE layer-2 command; as well as The Uu DRX MAC CE layer-2 command is processed to determine whether to enter Uu DRX or SL DRX with the second UE.

2. The method of claim 1, wherein the Uu DRX MAC CE layer-2 command comprises an index representing one of a predefined Uu DRX configuration or a SL DRX configuration.

3. The method of claim 1 , further comprising RRC signaling to configure a lookup table so that the Uu DRX MAC CE layer-2 command indicates a DRX configuration in the configured table.

4. The method of claim 3, wherein the Uu DRX MAC CE Layer-2 command includes a flag for indicating whether the DRX configuration is to be used in Uu, in SL, or in both.

5. The method of claim 3, wherein the lookup table is a concatenated table for both Uu and SL DRX.

6. The method of claim 3, wherein the lookup table comprises two different tables and the Uu DRXMAC CE Layer-2 command comprises a flag for indicating which table to use.

7. A non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium comprising instructions, which, when executed by a first user equipment UE in a connected mode with a base station to enter a sidelink SL discontinuous reception DRX, cause the first UE to: receiving a Uu DRX MAC control element layer-2 command, i.e., a Uu DRX MAC CE layer-2 command, from the base station to trigger the first UE to enter Uu or SL DRX indicated in the Uu DRX MAC CE layer-2 command; and The Uu DRX MAC CE layer-2 command is processed to determine whether to enter Uu DRX or SL DRX with the second UE.

8. The computer-readable storage medium of claim 7, wherein the Uu DRX MAC CE layer-2 command comprises an index representing one of a predefined Uu DRX configuration or a SL DRX configuration.

9. The computer-readable storage medium of claim 7, wherein the instructions further configure the first UE to RRC signal to configure a lookup table such that the Uu DRX MAC CE Layer-2 command indicates a DRX configuration.

10. The computer-readable storage medium of claim 9, wherein the Uu DRX MAC CE Layer-2 command includes a flag to indicate whether the lookup table is used in Uu, in SL, or in both.

11. The computer readable storage medium of claim 9, wherein the lookup table is a concatenated table for both Uu and SL DRX.

12. The computer-readable storage medium of claim 9, wherein the lookup table comprises two different tables and the Uu DRX MAC CE Layer-2 command comprises a flag to indicate which table to use.

Images