Patent Description:
The subject matter disclosed herein relates generally to wireless communications and more particularly relates to user equipment power saving for V2X communications.

In wireless networks, for broadcast and groupcast communications, a receiving user equipment ("UE") may not know the PC5 quality of service ("QoS") parameters for reception and therefore may not be able to determine which PC5 discontinuous reception ("DRX") to apply for reception.

<NUM>; Architecture enhancements for <NUM> System (5GS) to support Vehicle-to-Everything (V2X) services (3GPP TS <NUM> version <NUM>. <NUM> Release <NUM>) discloses architecture enhancements to the <NUM> System to facilitate vehicular communications for Vehicle-to-Everything (V2X) services, over PC5 reference points NR PC5 RAT and LTE PC5 RAT and Uu reference points NR and E-UTRA, based on service requirements defined in TS <NUM> and TS <NUM>.

According to aspects of the present disclosure, there are provided a user equipment according to claim <NUM>, a method according to claim <NUM>, and a user equipment according to claim <NUM>.

Disclosed are procedures for supporting power saving for v2x communications over groupcast and broadcast for receiving UEs.

In one embodiment, a first apparatus includes a processor that determines one or more destination layer-<NUM> IDs for reception within vehicle-to-everything ("V2X") configuration information received from the network, determines one or more quality of service ("QoS") requirements for reception for each determined one or more destination layer-<NUM> IDs, and provides the determined one or more QoS requirements for each determined one or more destination layer-<NUM> IDs for reception to the application service ("AS") layer.

In one embodiment, a first method determines one or more destination layer-<NUM> IDs for reception within vehicle-to-everything ("V2X") configuration information received from the network, determines one or more quality of service ("QoS") requirements for reception for each determined one or more destination layer-<NUM> IDs, and provides the determined one or more QoS requirements for each determined one or more destination layer-<NUM> IDs for reception to the application service ("AS") layer.

In one embodiment, a second apparatus includes a processor that receives, from a vehicle-to-everything ("V2X") layer, one or more quality of service ("QoS") requirements for one or more destination layer-<NUM> IDs for reception of one of groupcast and broadcast transmissions and determines information for an applied PC5 discontinuous reception ("DRX") based on the QoS requirements.

In one embodiment, a second method receives, from a vehicle-to-everything ("V2X") layer, one or more quality of service ("QoS") requirements for one or more destination layer-<NUM> IDs for reception of one of groupcast and broadcast transmissions and determines information for an applied PC5 discontinuous reception ("DRX") based on the QoS requirements.

Code for carrying out operations for embodiments may be any number of lines and may be written in any combination of one or more programming languages including an object-oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the "C" programming language, or the like, and/or machine languages such as assembly languages. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network ("LAN"), wireless LAN ("WLAN"), or a wide area network ("WAN"), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider ("ISP")).

The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart diagrams and/or block diagrams.

Generally, the present disclosure describes systems, methods, and apparatuses for supporting power saving for vehicle-to-everything ("V2X") communications over groupcast and/or broadcast for receiving UEs. In certain embodiments, the methods may be performed using computer code embedded on a computer-readable medium. In certain embodiments, an apparatus or system may include a computer-readable medium containing computer-readable code which, when executed by a processor, causes the apparatus or system to perform at least a portion of the below described solutions.

The <NUM>rd generation partnership project ("3GPP") is studying, in Release <NUM>, enhancements to support sidelink communication over PC5 (e.g., a reference point where the UE directly communicates with another UE over the direct channel) for pedestrians supporting sidelink communication with power efficiency, e.g., according to vehicular services requirements defined in TS <NUM> and TS <NUM>.

In conventional solutions, a V2X UE transmits a message for sidelink communication over PC5 at a constant rate. For example, a Cooperative Awareness Message ("CAM") is sent over PC5 every <NUM>. Such constant operation reduces the power efficiency of the UE. However, V2X UEs (e.g., cars or road side units ("RSUs")) have a battery capacity that allows such constant operation. On the other hand, pedestrian UEs (e.g., smartphones, smart watches) have limited battery capacity or available radio resources and thus a new mechanism is needed to ensure power efficient operations over PC5. One of the key issues agreed to in Release <NUM> V2X TR <NUM> is to study how to support the DRX mechanism defined over Uu to communication over PC5.

For the transmitting UE, it was agreed that the application service ("AS") layer in the UE determines the PC5 DRX based on the QoS requirements provided by the V2X layer. The agreed procedure is as follows:.

One problem is that, for broadcast and groupcast communications, a receiving UE does not know the PC5 QoS parameters for reception and therefore is not able to determine which PC5 DRX to apply for reception.

In one embodiment, this disclosure solves the problem of how a V2X Pedestrian UE determines what DRX over PC5 to apply for reception of broadcast and/or groupcast V2X messages.

In one embodiment, the V2X layer in the UE determines the V2X service type for reception by checking the V2X configuration information. What is additionally proposed is that the V2X layer in the UE determines the QoS requirements for each determined V2X service type by checking the V2X configuration information. The UE then provides this information to the AS layer in the UE. The AS layer determines the PC5 DRX for reception for each V2X service type based on the QoS requirements.

<FIG> depicts a wireless communication system <NUM> supporting user equipment power saving for V2X communications, according to embodiments of the disclosure. In one embodiment, the wireless communication system <NUM> includes at least one remote unit <NUM>, a radio access network ("RAN") <NUM>, and a mobile core network <NUM>. The RAN <NUM> and the mobile core network <NUM> form a mobile communication network. The RAN <NUM> may be composed of a base unit <NUM> with which the remote unit <NUM> communicates using wireless communication links <NUM>. Even though a specific number of remote units <NUM>, base units <NUM>, wireless communication links <NUM>, RANs <NUM>, and mobile core networks <NUM> are depicted in <FIG>, one of skill in the art will recognize that any number of remote units <NUM>, base units <NUM>, wireless communication links <NUM>, RANs <NUM>, and mobile core networks <NUM> may be included in the wireless communication system <NUM>.

In one implementation, the RAN <NUM> is compliant with the <NUM> system specified in the Third Generation Partnership Project ("3GPP") specifications. For example, the RAN <NUM> may be a New Generation Radio Access Network ("NG-RAN"), implementing NR RAT and/or 3GPP Long-Term Evolution ("LTE") RAT. In another example, the RAN <NUM> may include non-3GPP RAT (e.g., Wi-Fi® or Institute of Electrical and Electronics Engineers ("IEEE") <NUM>-family compliant WLAN). In another implementation, the RAN <NUM> is compliant with the LTE system specified in the 3GPP specifications. More generally, however, the wireless communication system <NUM> may implement some other open or proprietary communication network, for example Worldwide Interoperability for Microwave Access ("WiMAX") or IEEE <NUM>-family standards, among other networks.

In one embodiment, the remote units <NUM> may include computing devices, such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), smart appliances (e.g., appliances connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), or the like. Moreover, the remote units <NUM> may be referred to as the UEs, subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, user terminals, wireless transmit/receive unit ("WTRU"), a device, or by other terminology used in the art. In various embodiments, the remote unit <NUM> includes a subscriber identity and/or identification module ("SIM") and the mobile equipment ("ME") providing mobile termination functions (e.g., radio transmission, handover, speech encoding and decoding, error detection and correction, signaling and access to the SIM). In certain embodiments, the remote unit <NUM> may include a terminal equipment ("TE") and/or be embedded in an appliance or device (e.g., a computing device, as described above).

The remote units <NUM> may communicate directly with one or more of the base units <NUM> in the RAN <NUM> via uplink ("UL") and downlink ("DL") communication signals. Furthermore, the UL and DL communication signals may be carried over the wireless communication links <NUM>. Here, the RAN <NUM> is an intermediate network that provides the remote units <NUM> with access to the mobile core network <NUM>.

In various embodiments, the remote units <NUM> may communicate directly with each other (e.g., device-to-device communication) using V2X communication signals <NUM>. Here, V2X transmissions may occur on V2X resources. As discussed above, a remote unit <NUM> may be provided with different V2X communication resources for different V2X modes. Mode-<NUM> corresponds to a NR-based network-scheduled V2X communication mode. Mode-<NUM> corresponds to an NR-based UE-scheduled V2X communication mode.

In some embodiments, the remote units <NUM> communicate with an application server via a network connection with the mobile core network <NUM>. For example, an application <NUM> (e.g., web browser, media client, telephone and/or Voice-over-Internet-Protocol ("VoIP") application) in a remote unit <NUM> may trigger the remote unit <NUM> to establish a protocol data unit ("PDU") session (or other data connection) with the mobile core network <NUM> via the RAN <NUM>. The mobile core network <NUM> then relays traffic between the remote unit <NUM> and the application server (e.g., the content server <NUM> in the packet data network <NUM>) using the PDU session. The PDU session represents a logical connection between the remote unit <NUM> and the User Plane Function ("UPF") <NUM>.

In order to establish the PDU session (or PDN connection), the remote unit <NUM> must be registered with the mobile core network <NUM> (also referred to as '"attached to the mobile core network" in the context of a Fourth Generation ("<NUM>") system). Note that the remote unit <NUM> may establish one or more PDU sessions (or other data connections) with the mobile core network <NUM>. As such, the remote unit <NUM> may have at least one PDU session for communicating with the packet data network <NUM>, e.g., representative of the Internet. The remote unit <NUM> may establish additional PDU sessions for communicating with other data networks and/or other communication peers.

In the context of a <NUM> system ("5GS"), the term "PDU Session" a data connection that provides end-to-end ("E2E") user plane ("UP") connectivity between the remote unit <NUM> and a specific Data Network ("DN") through the UPF <NUM>. A PDU Session supports one or more Quality of Service ("QoS") Flows. In certain embodiments, there may be a one-to-one mapping between a QoS Flow and a QoS profile, such that all packets belonging to a specific QoS Flow have the same <NUM> QoS Identifier ("5QI").

In the context of a <NUM>/LTE system, such as the Evolved Packet System ("EPS"), a Packet Data Network ("PDN") connection (also referred to as EPS session) provides E2E UP connectivity between the remote unit and a PDN. The PDN connectivity procedure establishes an EPS Bearer, i.e., a tunnel between the remote unit <NUM> and a Packet Gateway ("PGW", not shown) in the mobile core network <NUM>. In certain embodiments, there is a one-to-one mapping between an EPS Bearer and a QoS profile, such that all packets belonging to a specific EPS Bearer have the same QoS Class Identifier ("QCI").

The base units <NUM> may be distributed over a geographic region. In certain embodiments, a base unit <NUM> may also be referred to as an access terminal, an access point, a base, a base station, a Node-B ("NB"), an Evolved Node B (abbreviated as eNodeB or "eNB," also known as Evolved Universal Terrestrial Radio Access Network ("E-UTRAN") Node B), a <NUM>/NR Node B ("gNB"), a Home Node-B, a relay node, a RAN node, or by any other terminology used in the art. The base units <NUM> are generally part of a RAN, such as the RAN <NUM>, that may include one or more controllers communicably coupled to one or more corresponding base units <NUM>. These and other elements of radio access network are not illustrated but are well known generally by those having ordinary skill in the art. The base units <NUM> connect to the mobile core network <NUM> via the RAN <NUM>.

The base units <NUM> may serve a number of remote units <NUM> within a serving area, for example, a cell or a cell sector, via a wireless communication link <NUM>. The base units <NUM> may communicate directly with one or more of the remote units <NUM> via communication signals. Generally, the base units <NUM> transmit DL communication signals to serve the remote units <NUM> in the time, frequency, and/or spatial domain. Furthermore, the DL communication signals may be carried over the wireless communication links <NUM>. The wireless communication links <NUM> may be any suitable carrier in licensed or unlicensed radio spectrum. The wireless communication links <NUM> facilitate communication between one or more of the remote units <NUM> and/or one or more of the base units <NUM>. Note that during NR-U operation, the base unit <NUM> and the remote unit <NUM> communicate over unlicensed radio spectrum.

In one embodiment, the mobile core network <NUM> is a 5GC or an Evolved Packet Core ("EPC"), which may be coupled to a packet data network <NUM>, like the Internet and private data networks, among other data networks. A remote unit <NUM> may have a subscription or other account with the mobile core network <NUM>. Each mobile core network <NUM> belongs to a single public land mobile network ("PLMN").

The mobile core network <NUM> includes several network functions ("NFs"). As depicted, the mobile core network <NUM> includes at least one UPF <NUM>. The mobile core network <NUM> also includes multiple control plane ("CP") functions including, but not limited to, an Access and Mobility Management Function ("AMF") <NUM> that serves the RAN <NUM>, a Session Management Function ("SMF") <NUM>, a Network Exposure Function ("NEF") <NUM>, a Policy Control Function ("PCF") <NUM>, a Unified Data Management function ("UDM") and a User Data Repository ("UDR").

The UPF(s) <NUM> is responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU session for interconnecting Data Network (DN), in the <NUM> architecture. The AMF <NUM> is responsible for termination of NAS signaling, NAS ciphering & integrity protection, registration management, connection management, mobility management, access authentication and authorization, security context management. The SMF <NUM> is responsible for session management (i.e., session establishment, modification, release), remote unit (i.e., UE) IP address allocation & management, DL data notification, and traffic steering configuration for UPF for proper traffic routing.

The NEF <NUM> is responsible for making network data and resources easily accessible to customers and network partners. Service providers may activate new capabilities and expose them through APIs. These APIs allow third-party authorized applications to monitor and configure the network's behavior for a number of different subscribers (i.e., connected devices with different applications). The PCF <NUM> is responsible for unified policy framework, providing policy rules to CP functions, access subscription information for policy decisions in UDR.

The UDM is responsible for generation of Authentication and Key Agreement ("AKA") credentials, user identification handling, access authorization, subscription management. The UDR is a repository of subscriber information and can be used to service a number of network functions. For example, the UDR may store subscription data, policy-related data, subscriber-related data that is permitted to be exposed to third party applications, and the like. In some embodiments, the UDM is co-located with the UDR, depicted as combined entity "UDM/UDR" <NUM>.

In various embodiments, the mobile core network <NUM> may also include an Authentication Server Function ("AUSF") (which acts as an authentication server), a Network Repository Function ("NRF") (which provides NF service registration and discovery, enabling NFs to identify appropriate services in one another and communicate with each other over Application Programming Interfaces ("APIs")), or other NFs defined for the 5GC. In certain embodiments, the mobile core network <NUM> may include an authentication, authorization, and accounting ("AAA") server.

In various embodiments, the mobile core network <NUM> supports different types of mobile data connections and different types of network slices, wherein each mobile data connection utilizes a specific network slice. Here, a "network slice" refers to a portion of the mobile core network <NUM> optimized for a certain traffic type or communication service. A network instance may be identified by a single-network slice selection assistance information ("S-NSSAI,") while a set of network slices for which the remote unit <NUM> is authorized to use is identified by network slice selection assistance information ("NSSAI").

Here, "NSSAI" refers to a vector value including one or more S-NSSAI values. In certain embodiments, the various network slices may include separate instances of network functions, such as the SMF <NUM> and UPF <NUM>. In some embodiments, the different network slices may share some common network functions, such as the AMF <NUM>. The different network slices are not shown in <FIG> for ease of illustration, but their support is assumed. Where different network slices are deployed, the mobile core network <NUM> may include a Network Slice Selection Function ("NSSF") which is responsible for selecting of the Network Slice instances to serve the remote unit <NUM>, determining the allowed NSSAI, determining the AMF set to be used to serve the remote unit <NUM>.

Although specific numbers and types of network functions are depicted in <FIG>, one of skill in the art will recognize that any number and type of network functions may be included in the mobile core network <NUM>. Moreover, in an LTE variant where the mobile core network <NUM> comprises an EPC, the depicted network functions may be replaced with appropriate EPC entities, such as a Mobility Management Entity ("MME"), a Serving Gateway ("SGW"), a PGW, a Home Subscriber Server ("HSS"), and the like. For example, the AMF <NUM> may be mapped to an MME, the SMF <NUM> may be mapped to a control plane portion of a PGW and/or to an MME, the UPF <NUM> may be mapped to an SGW and a user plane portion of the PGW, the UDM/UDR <NUM> may be mapped to an HSS, etc..

While <FIG> depicts components of a <NUM> RAN and a <NUM> core network, the described embodiments apply to other types of communication networks and RATs, including IEEE <NUM> variants, Global System for Mobile Communications ("GSM", i.e., a <NUM> digital cellular network), General Packet Radio Service ("GPRS"), UMTS, LTE variants, CDMA <NUM>, Bluetooth, ZigBee, Sigfox, and the like.

In the following descriptions, the term "gNB" is used for the base station but it is replaceable by any other radio access node, e.g., RAN node, eNB, Base Station ("BS"), Access Point ("AP"), NR, etc. Further the operations are described mainly in the context of <NUM> NR. However, the proposed solutions/methods are also equally applicable to other mobile communication systems supporting CSI enhancements for higher frequencies.

A method has been disclosed in S2-<NUM> for a QoS aware power efficient PC5 communication for pedestrian UEs. The method proposes that the UEs derive the DRX based on the active applications running in the UE and negotiate the DRX with other UEs running the same application, as shown in <FIG>.

A disadvantage with the procedure shown in <FIG> is that DRX can only be synchronized for unicast V2X operations and is not supported for groupcast or broadcast communications. In addition, certain methods involve an AMF that provides the default PC5 DRX configuration to the UE. If the UE determines that the default PC5 DRX configuration cannot be supported based on the QoS requirements of an application, the UE determines an offset extending the active time of the DRX to support such QoS requirements.

In addition, a method has been disclosed where an application function ("AF")/policy control function ("PCF") provides a PC5 DRX configuration on per V2X service. The V2X layer in the UE provides the PC5 DRX configuration to the AS layer that the AS layer uses to determine the PC5 DRX to apply.

The solution for applying PC5 DRX at the receiver UE is as follows:.

The receiving UE either applies the default PC5 DRX provided by the AMF (if provided), or determines the PC5 DRX from V2X configuration information as follows:.

There are two options disclosed on how PC5 DRX for reception is determined.

In a first embodiment, PC5 DRX per V2X service type determined at AS layer, the V2X layer determines the PC5 QoS parameters based on the mapping of V2X service types to PC5 QoS parameters e.g., as specified in clause <NUM>. <NUM> of TS <NUM> or based on QoS requirements provided by the application. The V2X layer then passes the QoS parameters per V2X service type to the AS layer for reception. The AS layer determines the PC5 DRX to apply for reception according to the QoS requirements e.g., using a (pre)configuration, for example, RRC signaling.

In a second embodiment, PC5 DRX per V2X service type determined at V2X layer, the V2X layer determines the PC5 DRX configuration of each V2X service type based on V2X configuration information provided by the AF or the PCF. In one embodiment, the V2X configuration information includes default PQI per V2X service type and PC5 DRX per PQI. The V2X layer determines the default PQI (if no QoS requirement has been provided by the application) and determines the PC5 DRX based on the PQI. In an alternative embodiment the V2X layer determines the PC5 DRX for reception based on PC5 DRX configuration per V2X service type included within the V2X configuration information. The V2X layer then provides the PC5 DRX configuration for each determined V2X service type for reception to the AS layer. The AS layer then applies the PC5 DRX configuration.

The procedure for user equipment power saving for V2X communications is illustrated in <FIG> and <FIG>.

In one embodiment, at step <NUM> (see block <NUM>), the UE <NUM> receives a PC5 DRX configuration from the AF/PCF and/or AMF <NUM>.

In one embodiment, at step <NUM> (see messaging <NUM>), the V2X application <NUM> requests to transmit a message via V2X and provides its application requirements, which may include QoS requirements.

In one embodiment, at step <NUM> (see messaging <NUM>), the V2X layer <NUM> determines the V2X service type for reception for broadcast and groupcast based on the V2X configuration information, e.g., as described in 3GPP TS <NUM>.

In a first embodiment (see block <NUM>) a PC5 DRX per V2X service type is determined at the AS layer <NUM>.

In one embodiment, at step 4a (see block <NUM>), the receiving UE <NUM> determines the PC5 QoS parameters based on the mapping of V2X service types to PC5 QoS parameters, e.g., as specified in clause <NUM>. <NUM> of TS <NUM> or based on QoS requirements provided by the application.

In one embodiment, at step 5a (see messaging <NUM>), the V2X layer <NUM> provides the QoS requirements for each determined V2X service type to the AS layer <NUM>.

In one embodiment, at step 6a (see block <NUM>), the AS layer <NUM> determines the PC5 DRX based on the QoS requirements of each V2X service type.

In a second embodiment (see block <NUM>) a PC5 DRX per V2X service type is determined at the V2X layer <NUM>.

In one embodiment, at step 4b (see block <NUM>), the V2X layer <NUM> determines the PC5 DRX configuration of each V2X service type from the V2X configuration information, e.g., as described in the first embodiment (see block <NUM>) above.

In one embodiment, at step 5b (see messaging <NUM>), the V2X layer <NUM> provides a PC5 DRX configuration for each V2X service type to the AS layer <NUM>.

In one embodiment, at step 6b (see block <NUM>), the AS layer <NUM> in the UE <NUM> applies the PC5 DRX configuration.

In one embodiment, at step <NUM> (see messaging <NUM>), the AS layer <NUM> may provide information on the applied PC5 DRX per V2X service type to the V2X layer <NUM>.

<FIG> depicts a user equipment apparatus <NUM> that may be used for user equipment power saving for V2X communications, according to embodiments of the disclosure. In various embodiments, the user equipment apparatus <NUM> is used to implement one or more of the solutions described above. The user equipment apparatus <NUM> may be one embodiment of a UE, such as the remote unit <NUM> and/or the UE <NUM>, as described above. Furthermore, the user equipment apparatus <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, an output device <NUM>, and a transceiver <NUM>. In some embodiments, the input device <NUM> and the output device <NUM> are combined into a single device, such as a touchscreen. In certain embodiments, the user equipment apparatus <NUM> may not include any input device <NUM> and/or output device <NUM>. In various embodiments, the user equipment apparatus <NUM> may include one or more of: the processor <NUM>, the memory <NUM>, and the transceiver <NUM>, and may not include the input device <NUM> and/or the output device <NUM>.

As depicted, the transceiver <NUM> includes at least one transmitter <NUM> and at least one receiver <NUM>. Here, the transceiver <NUM> communicates with one or more base units <NUM>. Additionally, the transceiver <NUM> may support at least one network interface <NUM> and/or application interface <NUM>. The application interface(s) <NUM> may support one or more APIs. The network interface(s) <NUM> may support 3GPP reference points, such as Uu and PC5. Other network interfaces <NUM> may be supported, as understood by one of ordinary skill in the art.

For example, the processor <NUM> may be a microcontroller, a microprocessor, a central processing unit ("CPU"), a graphics processing unit ("GPU"), an auxiliary processing unit, a field programmable gate array ("FPGA"), a digital signal processor ("DSP"), a co-processor, an application-specific processor, or similar programmable controller. In certain embodiments, the processor <NUM> may include an application processor (also known as "main processor") which manages application-domain and operating system ("OS") functions and a baseband processor (also known as "baseband radio processor") which manages radio functions.

In some embodiments, the memory <NUM> stores data related to CSI enhancements for higher frequencies. For example, the memory <NUM> may store parameters, configurations, resource assignments, policies, and the like as described above. In certain embodiments, the memory <NUM> also stores program code and related data, such as an operating system or other controller algorithms operating on the user equipment apparatus <NUM>, and one or more software applications.

As another, nonlimiting, example, the output device <NUM> may include a wearable display separate from, but communicatively coupled to, the rest of the user equipment apparatus <NUM>, such as a smart watch, smart glasses, a heads-up display, or the like.

The transceiver <NUM> includes at least transmitter <NUM> and at least one receiver <NUM>. The transceiver <NUM> may be used to provide UL communication signals to a base unit <NUM> and to receive DL communication signals from the base unit <NUM>, as described herein. Similarly, the transceiver <NUM> may be used to transmit and receive SL signals (e.g., V2X communication), as described herein. Although only one transmitter <NUM> and one receiver <NUM> are illustrated, the user equipment apparatus <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>. Further, the transmitter(s) <NUM> and the receiver(s) <NUM> may be any suitable type of transmitters and receivers. In one embodiment, the transceiver <NUM> includes a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum.

In various embodiments, one or more transmitters <NUM> and/or one or more receivers <NUM> may be implemented and/or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an ASIC, or other type of hardware component. In certain embodiments, one or more transmitters <NUM> and/or one or more receivers <NUM> may be implemented and/or integrated into a multi-chip module. In some embodiments, other components such as the network interface <NUM> or other hardware components/circuits may be integrated with any number of transmitters <NUM> and/or receivers <NUM> into a single chip. In such embodiment, the transmitters <NUM> and receivers <NUM> may be logically configured as a transceiver <NUM> that uses one more common control signals or as modular transmitters <NUM> and receivers <NUM> implemented in the same hardware chip or in a multi-chip module.

In one embodiment, the processor <NUM> determines one or more destination layer-<NUM> IDs for reception within vehicle-to-everything ("V2X") configuration information received from the network, determines one or more quality of service ("QoS") requirements for reception for each determined one or more destination layer-<NUM> IDs, and provides the determined one or more QoS requirements for each determined one or more destination layer-<NUM> IDs for reception to the application service ("AS") layer.

In one embodiment, the processor <NUM> determines the one or more QoS requirements for reception for each determined one or more destination layer-<NUM> IDs by determining associated V2X service types for each of the one or more destination layer-<NUM> IDs and the associated PC5 QoS parameters for each V2X service type.

In one embodiment, the transceiver <NUM> receives, over a first radio interface, the V2X configuration, the V2X configuration comprising one or more destination layer-<NUM> IDs for each V2X service type and one or more QoS requirements for each determined V2X service type for communication over a second radio interface.

In one embodiment, the transceiver <NUM> receives, from an application, a request to receive data over the second radio interface, the request comprising the one or more QoS requirements.

In one embodiment, the processor <NUM> determines the one or more QoS requirements based on at least one of the V2X configuration and the request from the application.

In one embodiment, the V2X configuration is received from a policy control function ("PCF") or an application function.

In one embodiment, the processor <NUM> receives information for an applied PC5 discontinuous reception ("DRX") for each determined V2X service type from the AS layer.

In one embodiment, the processor <NUM> receives, from a vehicle-to-everything ("V2X") layer, one or more quality of service ("QoS") requirements for one or more destination layer-<NUM> IDs for reception of one of groupcast and broadcast transmissions and determines information for an applied PC5 discontinuous reception ("DRX") based on the QoS requirements.

In one embodiment, the processor <NUM> determines the information for the applied PC5 DRX based on V2X configuration information.

<FIG> depicts one embodiment of a network apparatus <NUM> that may be used for user equipment power saving for V2X communications, according to embodiments of the disclosure. In some embodiments, the network apparatus <NUM> may be one embodiment of a RAN node and its supporting hardware, such as the base unit <NUM> and/or gNB, described above. Furthermore, network apparatus <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, an output device <NUM>, and a transceiver <NUM>. In certain embodiments, the network apparatus <NUM> does not include any input device <NUM> and/or output device <NUM>.

As depicted, the transceiver <NUM> includes at least one transmitter <NUM> and at least one receiver <NUM>. Here, the transceiver <NUM> communicates with one or more remote units <NUM>. Additionally, the transceiver <NUM> may support at least one network interface <NUM> and/or application interface <NUM>. The application interface(s) <NUM> may support one or more APIs. The network interface(s) <NUM> may support 3GPP reference points, such as Uu, N1, N2, N3, N5, N6 and/or N7 interfaces. Other network interfaces <NUM> may be supported, as understood by one of ordinary skill in the art.

For example, the processor <NUM> may be a microcontroller, a microprocessor, a central processing unit ("CPU"), a graphics processing unit ("GPU"), an auxiliary processing unit, a field programmable gate array ("FPGA"), a digital signal processor ("DSP"), a co-processor, an application-specific processor, or similar programmable controller. In certain embodiments, the processor <NUM> may include an application processor (also known as "main processor") which manages application-domain and operating system ("OS") functions and a baseband processor (also known as "baseband radio processor") which manages radio function. In various embodiments, the processor <NUM> controls the network apparatus <NUM> to implement the above-described network entity behaviors (e.g., of the gNB) for user equipment power saving for V2X communications.

In some embodiments, the memory <NUM> stores data relating to CSI enhancements for higher frequencies. For example, the memory <NUM> may store parameters, configurations, resource assignments, policies, and the like as described above. In certain embodiments, the memory <NUM> also stores program code and related data, such as an operating system ("OS") or other controller algorithms operating on the network apparatus <NUM>, and one or more software applications.

The output device <NUM>, in one embodiment, may include any known electronically controllable display or display device. The output device <NUM> may be designed to output visual, audible, and/or haptic signals. In some embodiments, the output device <NUM> includes an electronic display capable of outputting visual data to a user.

In other embodiments, all or portions of the output device <NUM> may be located near the input device <NUM>.

As discussed above, the transceiver <NUM> may communicate with one or more remote units and/or with one or more interworking functions that provide access to one or more PLMNs. The transceiver <NUM> may also communicate with one or more network functions (e.g., in the mobile core network <NUM>). The transceiver <NUM> operates under the control of the processor <NUM> to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor <NUM> may selectively activate the transceiver (or portions thereof) at particular times in order to send and receive messages.

The transceiver <NUM> may include one or more transmitters <NUM> and one or more receivers <NUM>. In certain embodiments, the one or more transmitters <NUM> and/or the one or more receivers <NUM> may share transceiver hardware and/or circuitry. For example, the one or more transmitters <NUM> and/or the one or more receivers <NUM> may share antenna(s), antenna tuner(s), amplifier(s), filter(s), oscillator(s), mixer(s), modulator/demodulator(s), power supply, and the like. In one embodiment, the transceiver <NUM> implements multiple logical transceivers using different communication protocols or protocol stacks, while using common physical hardware.

<FIG> is a flowchart diagram of a method <NUM> for user equipment power saving for V2X communications. The method <NUM> may be performed by a UE as described herein, for example, the remote unit <NUM> and/or the user equipment apparatus <NUM>. In some embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the method <NUM> begins and determines <NUM> one or more destination layer-<NUM> IDs for reception within vehicle-to-everything ("V2X") configuration information received from the network. In one embodiment, the method <NUM> determines <NUM> one or more V2X service types for reception of one of groupcast and broadcast transmissions based on the one or more destination layer <NUM> IDs. In one embodiment, the method <NUM> determines <NUM> one or more quality of service ("QoS") requirements for reception for each determined one or more destination layer-<NUM> IDs. In one embodiment, the method <NUM> provides <NUM> the determined one or more QoS requirements for each determined one or more destination layer-<NUM> IDs for reception to the application service ("AS") layer, and the method <NUM> ends.

A first apparatus is disclosed for user equipment power saving for V2X communications. The first apparatus may be performed by a UE as described herein, for example, the remote unit <NUM> and/or the user equipment apparatus <NUM>. In some embodiments, the first apparatus may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the first apparatus includes a processor that determines one or more destination layer-<NUM> IDs for reception within vehicle-to-everything ("V2X") configuration information received from the network, determines one or more quality of service ("QoS") requirements for reception for each determined one or more destination layer-<NUM> IDs, and provides the determined one or more QoS requirements for each determined one or more destination layer-<NUM> IDs for reception to the application service ("AS") layer.

In one embodiment, the processor determines the one or more QoS requirements for reception for each determined one or more destination layer-<NUM> IDs by determining associated V2X service types for each of the one or more destination layer-<NUM> IDs and the associated PC5 QoS parameters for each V2X service type.

In one embodiment, the first apparatus includes a transceiver that receives, over a first radio interface, the V2X configuration, the V2X configuration comprising one or more destination layer-<NUM> IDs for each V2X service type and one or more QoS requirements for each determined V2X service type for communication over a second radio interface.

In one embodiment, the transceiver receives, from an application, a request to receive data over the second radio interface, the request comprising the one or more QoS requirements.

In one embodiment, the processor determines the one or more QoS requirements based on at least one of the V2X configuration and the request from the application.

In one embodiment, the processor receives information for an applied PC5 discontinuous reception ("DRX") for each determined V2X service type from the AS layer.

A first method is disclosed for user equipment power saving for V2X communications. The first method may be performed by a UE as described herein, for example, the remote unit <NUM> and/or the user equipment apparatus <NUM>. In some embodiments, the first method may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the first method determines one or more destination layer-<NUM> IDs for reception within vehicle-to-everything ("V2X") configuration information received from the network, determines one or more quality of service ("QoS") requirements for reception for each determined one or more destination layer-<NUM> IDs, and provides the determined one or more QoS requirements for each determined one or more destination layer-<NUM> IDs for reception to the application service ("AS") layer.

In one embodiment, the first method determines the one or more QoS requirements for reception for each determined one or more destination layer-<NUM> IDs by determining associated V2X service types for each of the one or more destination layer-<NUM> IDs and the associated PC5 QoS parameters for each V2X service type.

In one embodiment, the first method receives, over a first radio interface, the V2X configuration, the V2X configuration comprising one or more destination layer-<NUM> IDs for each V2X service type and one or more QoS requirements for each determined V2X service type for communication over a second radio interface.

In one embodiment, the first method receives, from an application, a request to receive data over the second radio interface, the request comprising the one or more QoS requirements.

In one embodiment, the first method determines the one or more QoS requirements based on at least one of the V2X configuration and the request from the application.

A second apparatus is disclosed for user equipment power saving for V2X communications. The second apparatus may be performed by a UE as described herein, for example, the remote unit <NUM> and/or the user equipment apparatus <NUM>. In some embodiments, the second apparatus may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the second apparatus includes a processor that receives, from a vehicle-to-everything ("V2X") layer, one or more quality of service ("QoS") requirements for one or more destination layer-<NUM> IDs for reception of one of groupcast and broadcast transmissions and determines information for an applied PC5 discontinuous reception ("DRX") based on the QoS requirements.

In one embodiment, the processor determines the information for the applied PC5 DRX based on V2X configuration information.

A second method is disclosed for user equipment power saving for V2X communications. The second method may be performed by a UE as described herein, for example, the remote unit <NUM> and/or the user equipment apparatus <NUM>. In some embodiments, the second method may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the second method receives, from a vehicle-to-everything ("V2X") layer, one or more quality of service ("QoS") requirements for one or more destination layer-<NUM> IDs for reception of one of groupcast and broadcast transmissions and determines information for an applied PC5 discontinuous reception ("DRX") based on the QoS requirements.

In one embodiment, the second method determines the information for the applied PC5 DRX based on V2X configuration information.

Claim 1:
A user equipment (<NUM>), UE for wireless communication, comprising:
at least one memory (<NUM>); and
at least one processor (<NUM>) coupled with at least one memory and configured to cause the UE to:
receive vehicle-to-everything, V2X, configuration information that comprises one or more destination layer-<NUM> identifiers, IDs, for reception;
determine (<NUM>) the one or more destination layer-<NUM> IDs for reception according to the V2X configuration information; characterized by further:
determine (<NUM>), at a first layer of the UE, one or more quality of service, QoS, requirements for reception for each determined one or more destination layer-<NUM> IDs; and
provide (<NUM>), to a second layer of the UE, the determined one or more QoS requirements for each determined one or more destination layer-<NUM> IDs for reception.