Adaptive operational design domain computation

Abstract

A user equipment (UE) may be associated with a vehicle, for example, the UE may be a vehicle or may be a wireless device connectively coupled (e.g., wired or wireless connected) to the vehicle. The UE may receive a set of attributes associated with a route of the UE. The UE may calculate a predicted number of operational design domain (ODD) handover along the route based on the set of attributes. In one aspect, the UE may notify a driver associated with the UE of an ODD condition based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. In another aspect, the UE may deactivate an ODD mode associated with the UE based on the calculated predicted number of ODD handovers being greater than or equal to a threshold.

Description

Cross-reference to related applications

[0001] This application claims the benefit of U.S. non-provisional patent application No. 18 / 467,571, filed on September 14, 2023, entitled “ADAPTIVE OPERATIONAL DESIGNDOMAIN CALCULATIONS,” the entire contents of which are expressly incorporated herein by reference. Technical Field

[0002] This disclosure relates generally to communication systems, and more specifically to driver assistance systems. Background Technology

[0003] Wireless communication systems are widely deployed to provide a variety of telecommunications services, such as telephone, video, data, messaging, and broadcasting. Typical wireless communication systems employ multiple access technologies that enable communication with multiple users by sharing available system resources. Examples of such multiple access technologies include Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single Carrier Frequency Division Multiple Access (SC-FDMA) systems, and Time Division Synchronous Code Division Multiple Access (TD-SCDMA) systems.

[0004] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol that enables different wireless devices to communicate at the city, national, regional, and even global levels. An example telecommunications standard is 5G New Radio (NR). 5G NR is part of the Continuous Evolution of Mobile Broadband (CWB) program issued by the 3rd Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., with the Internet of Things (IoT),) and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable low-latency communications (URLLC). Some aspects of 5G NR are based on the 4G Long Term Evolution (LTE) standard. Further improvements to 5G NR technology are needed. Furthermore, these improvements can also be applied to other multiple access technologies and telecommunications standards that adopt them. Summary of the Invention

[0005] The following is a simplified summary of one or more aspects to provide a basic understanding of these aspects. This summary is not a comprehensive overview of all conceived aspects. It neither identifies key or essential elements of all aspects nor describes the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed descriptions that follow.

[0006] In one aspect of this disclosure, a method, computer-readable medium, and apparatus are provided. The apparatus may be user equipment (UE). The apparatus may be associated with a vehicle, for example, the apparatus may be the vehicle itself or a wireless device connected to the vehicle in a connected manner (e.g., wired or wireless connection). The apparatus may receive a set of attributes associated with a route of the vehicle. The apparatus may calculate a predicted number of Operational Design Domain (ODD) switching along the route based on the set of attributes. In one aspect, the apparatus may notify a driver associated with the apparatus of an ODD status based on the calculated predicted number of ODD switching being greater than or equal to a threshold. In another aspect, the apparatus may deactivate an ODD mode associated with the apparatus based on the calculated predicted number of ODD switching being greater than or equal to a threshold.

[0007] To achieve the foregoing and related objectives, one or more aspects may include the features fully described below and specifically pointed out in the claims. The following description and drawings set forth some exemplary features of one or more aspects in detail. However, these features indicate only a few of the various ways in which the principles of the various aspects may be employed. Attached Figure Description

[0008] Figure 1 This is a diagram illustrating an example of a wireless communication system and an access network.

[0009] Figure 2A This is an illustration of an example of the first frame according to various aspects of this disclosure.

[0010] Figure 2B This is a diagram illustrating examples of downlink (DL) channels within a subframe according to various aspects of this disclosure.

[0011] Figure 2C This is an illustration of an example of a second frame according to various aspects of this disclosure.

[0012] Figure 2D This is a diagram illustrating examples of uplink (UL) channels within a subframe according to various aspects of this disclosure.

[0013] Figure 3 This is a diagram illustrating examples of base stations and user equipment (UEs) in an access network.

[0014] Figure 4 An example aspect of the side link time slot structure is illustrated.

[0015] Figure 5 This is a diagram illustrating an example of a first and a second device involved in wireless communication based, for example, a side link.

[0016] Figure 6Examples of sidelink communication between devices are illustrated according to the aspects presented in this article.

[0017] Figure 7 An example of resource reservation for sidelink communication is shown.

[0018] Figure 8 An example of communication between devices used by an autonomous driving system to dynamically adjust to the calculated ODD condition is illustrated.

[0019] Figure 9 Examples of communication between devices for dynamically adjusting to the calculated ODD status, based on the aspects presented herein, are illustrated.

[0020] Figure 10 An example communication flowchart of a wireless device configured to dynamically adjust to the calculated ODD status is shown.

[0021] Figure 11 This is a flowchart of a wireless communication method.

[0022] Figure 12 This is a flowchart of a wireless communication method.

[0023] Figure 13 This is a flowchart of a wireless communication method.

[0024] Figure 14 These are illustrations illustrating specific hardware implementations used for example devices and / or network entities.

[0025] Figure 15 This is a diagram illustrating an example of a hardware implementation used for an example network entity.

[0026] Figure 16 This is a diagram illustrating an example of a hardware implementation used for an example network entity. Detailed Implementation

[0027] The following description relates to examples intended to illustrate the innovative aspects of this disclosure. However, those skilled in the art will recognize that the teachings herein can be applied in numerous ways. Some or all of the examples described can be applied in Bluetooth systems that meet the requirements of the Institute of Electrical and Electronics Engineers (IEEE) 802.11, IEEE 802.15, or Bluetooth as defined by the Bluetooth Special Interest Group (SIG). ®The described examples can be implemented in any device, system, or network that transmits and receives radio frequency (RF) signals using one or more of the following standards, or those published by the 3rd Generation Partnership Project (3GPP): Long Term Evolution (LTE), 3G, 4G, or 5G (New Radio (NR)). The examples described can be implemented in any device, system, or network capable of transmitting and receiving RF signals according to one or more of the following technologies or techniques: Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Space Division Multiple Access (SDMA), Rate Split Multiple Access (RSMA), Multi-User Shared Access (MUSA), Single-User (SU) Multiple-Input Multiple-Output (MIMO), and Multi-User (MU) MIMO. The examples described can also be implemented using other wireless communication protocols or RF signals suitable for use in one or more of the following wireless personal area networks (WPAN), wireless local area networks (WLAN), wireless wide area networks (WWAN), wireless metropolitan area networks (WMAN), or Internet of Things (IoT) networks.

[0028] Various aspects generally relate to driver assistance systems. Some aspects more specifically relate to vehicles with autonomous driving (AD) or advanced driver assistance systems (ADAS). In some examples, a user equipment (UE) can receive a set of attributes associated with the UE's route. The UE can calculate a predicted number of Operational Design Domain (ODD) handovers along the route based on this set of attributes. In one aspect, the UE can notify the driver associated with the UE of the ODD status based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. In another aspect, the UE can deactivate the ODD mode associated with the UE based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. The UE can be associated with a vehicle; for example, the UE can be the vehicle itself or a wireless device connected to the vehicle in a connected manner (e.g., wired or wireless connection).

[0029] In some aspects, autonomous driving systems can be configured to operate within a specific ODD (e.g., within a speed range, within a road lane). Such systems can be configured to activate when a vehicle enters an ODD and deactivate when the vehicle leaves an ODD. If a vehicle with an autonomous driving system repeatedly activates and deactivates its autonomous driving features while traveling on a route with many boundaries between ODDs and non-ODDs, the vehicle may become inefficient. In some aspects, the UE can calculate predictions of increased ODD variability for the ego vehicle based on dynamic detection of ODD-influencing variables on the route, based on a set of attributes received by the UE, for example, from navigation maps, traffic data, and / or weather data. In some aspects, the UE can inform the driver of recommendations based on calculations, such as by making a recommendation to deactivate or not deactivate the autonomous driving system. Such recommendations can be made to the driver of the vehicle, the system controlling the vehicle, and / or other vehicles sharing the same route as the vehicle. In some aspects, such recommendations can be sent to other devices via the cloud or via vehicle-to-everything (V2X) messaging. In some respects, cloud entities can collect attribute sets from a set of devices associated with a route (e.g., vehicles, roadside units (RSUs), information databases), which may affect the performance of autonomous driving systems activated within the ODD. Such cloud entities can send attribute sets to the UE associated with the vehicle via V2X messages.

[0030] Specific aspects of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages. In some examples, by configuring the UE to calculate the predicted number of ODD switching along a route, the described techniques can be used to optimize the use of autonomous driving systems by reducing the number of ODD switching on a route. Such a UE can improve driving comfort within a vehicle and can minimize switching over a period of time. The UE can inform the driver of the vehicle that there will be a large number of ODD switching on a portion of the route, effectively recommending that the driver turn off the autonomous driving system to minimize ODD switching. In some aspects, the frequent turning on and off of the autonomous driving system can be communicated (e.g., via a cloud network) to other devices that can use the frequent turning on and off of the autonomous driving system to recommend activation / deactivation of the autonomous driving system to other drivers traveling along the same route.

[0031] The detailed descriptions following, illustrated with reference to the accompanying drawings, describe various configurations and do not represent the only configurations in which the concepts described herein can be practiced. To provide a thorough understanding of the various concepts, the detailed descriptions include specific details. However, these concepts can be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring these concepts.

[0032] Various apparatuses and methods are presented with reference to several aspects of a telecommunications system. These apparatuses and methods are described in detail below and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively, “elements”). These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole.

[0033] As an example, an element, any part of an element, or any combination of elements may be implemented as a "processing system" including one or more processors. When multiple processors are implemented, the multiple processors may perform functions individually or in combination. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, system-on-a-chip (SoCs), baseband processors, field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gate logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionalities described throughout this disclosure. One or more processors in the processing system can execute software. Whether referred to as software, firmware, middleware, microcode, hardware description language, or other terms, software should be broadly interpreted as instructions, instruction sets, code, code segments, program code, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, or any combination thereof.

[0034] Therefore, in one or more example aspects, specific implementations, and / or use cases, the described functionality may be implemented in hardware, software, or any combination thereof. If implemented in software, the functionality may be stored or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media can be any available medium that can be accessed by a computer. By way of example, such computer-readable media may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disc storage devices, magnetic disk storage devices, other magnetic storage devices, combinations of these types of computer-readable media, or any other medium that can be used to store computer-executable code in the form of instructions or data structures accessible by a computer.

[0035] While aspects, implementations, and / or use cases are described herein by way of example, additional or different aspects, implementations, and / or use cases may arise in many different arrangements and scenarios. The aspects, implementations, and / or use cases described herein can be implemented across many different platform types, devices, systems, shapes, sizes, and package arrangements. For example, aspects, implementations, and / or use cases may arise via integrated chip implementations and other devices based on non-modular components (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / purchasing devices, medical devices, AI-enabled devices, etc.). While some examples may or may not be specific to a use case or application, the described examples may exhibit broad applicability. Aspects, implementations, and / or use cases can range from chip-level or modular components to non-modular, non-chip-level implementations, and further to aggregated, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more of the technologies described herein. In some practical settings, devices incorporating the described aspects and features may also include additional components and features for implementing and practicing the claimed and described aspects. For example, the transmission and reception of wireless signals necessarily involve multiple components for analog and digital purposes (e.g., hardware components including antennas, RF chains, power amplifiers, modulators, buffers, processors, interleavers, adders / summers, etc.). The techniques described herein can be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, aggregated or decomposed components, end-user equipment, etc., of various sizes, shapes, and configurations.

[0036] Communication systems, such as 5G NR systems, can be deployed in various ways with a variety of components or parts. In a 5G NR system or network, network nodes, network entities, network mobility elements, radio access network (RAN) nodes, core network nodes, network elements or network equipment (such as base stations (BS)) or one or more units (or components) performing base station functions can be implemented in aggregated or decomposed architectures. For example, BSs (such as Node B (NB), evolved NB (eNB), NR BS, 5G NB, access point (AP), transmit / receive point (TRP), or cell, etc.) can be implemented as aggregated base stations (also known as standalone BS or monolithic BS) or decomposed base stations.

[0037] Aggregated base stations can be configured to utilize a radio protocol stack that is physically or logically integrated within a single RAN node. Decentralized base stations can be configured to utilize a protocol stack that is physically or logically distributed across two or more units, such as one or more central or centralized units (CUs), one or more distributed units (DUs), or one or more radio units (RUs). In some respects, the CU may be implemented within a RAN node, and one or more DUs may co-located with the CU, or alternatively, may be geographically or virtually distributed across one or more other RAN nodes. DUs may be implemented to communicate with one or more RUs. Each of the CUs, DUs, and RUs may be implemented as a virtual unit, namely a virtual central unit (VCU), a virtual distributed unit (VDU), or a virtual radio unit (VRU).

[0038] Base station operation or network design can take into account the aggregation characteristics of base station functionality. For example, decomposed base stations can be utilized in Integrated Access Backhaul (IAB) networks, Open Radio Access Networks (O-RAN (such as network configurations initiated by the O-RAN Alliance)), or Virtualized Radio Access Networks (vRAN, also known as Cloud Radio Access Networks (C-RAN)). Decomposition can include distributing functionality across two or more units in various physical locations, as well as virtually distributing the functionality of at least one unit, which enables flexibility in network design. The various units of a decomposed base station or decomposed RAN architecture can be configured to communicate wirelessly with at least one other unit.

[0039] Figure 1Figure 100 illustrates an example of a wireless communication system and access network. The illustrated wireless communication system includes a decomposed base station architecture. The decomposed base station architecture may include one or more CUs 110, which may communicate directly with the core network 120 via a backhaul link, or indirectly with the core network 120 via one or more decomposed base station units, such as a near real-time (near-RT) RAN Intelligent Controller (RIC) 125 via an E2 link, or a non-real-time (non-RT) RIC 115 associated with a Service Management and Orchestration (SMO) framework 105, or both. CUs 110 may communicate with one or more DUs 130 via a corresponding midhaul link (such as an F1 interface). DUs 130 may communicate with one or more RUs 140 via a corresponding fronthaul link. RUs 140 may communicate with a corresponding UE 104 via one or more radio frequency (RF) access links. In some implementations, a UE 104 may be served simultaneously by multiple RUs 140.

[0040] Each of the units (i.e., CU 110, DU 130, RU 140, and near-RT RIC 125, non-RT RIC 115, and SMO frame 105) may include or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via wired or wireless transmission media. Each of the units, or an associated processor or controller providing instructions to the communication interfaces of these units, may be configured to communicate with one or more other units via transmission media. For example, these units may include wired interfaces configured to receive signals or transmit signals to one or more other units via wired transmission media. Additionally, these units may include wireless interfaces that may include receivers, transmitters, or transceivers (such as RF transceivers) configured to receive and / or transmit signals to one or more other units via wireless transmission media.

[0041] In some aspects, the CU 110 can host one or more higher-level control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Serving Data Adaptation Protocol (SDAP), etc. Each control function can be implemented using an interface configured to signal to other control functions hosted by the CU 110. The CU 110 can be configured to handle user plane functionality (i.e., Central Unit-User Plane (CU-UP)), control plane functionality (i.e., Central Unit-Control Plane (CU-CP)), or a combination thereof. In some implementations, the CU 110 can be logically divided into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units can communicate bidirectionally with the CU-CP units via an interface such as an E1 interface. The CU 110 can be implemented to communicate with the DU 130 for network control and signaling, as needed.

[0042] DU 130 may correspond to a logical unit that includes one or more base station functions for controlling the operation of one or more RU 140s. In some aspects, DU 130 may at least partially host one or more of the Radio Link Control (RLC) layer, Media Access Control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) according to functional splits (such as those defined by 3GPP). In some aspects, DU 130 may also host one or more low PHY layers. Each layer (or module) may be implemented using an interface configured to communicate signals with other layers (and modules) hosted by DU 130 or with control functions hosted by CU 110.

[0043] Lower-layer functionality can be implemented by one or more RU 140s. In some deployments, the RU140 controlled by the DU 130 may correspond to a logical node that at least partially hosts RF processing functions or low-PHY layer functions (such as performing Fast Fourier Transform (FFT), Inverse FFT (iFFT), digital beamforming, Physical Random Access Channel (PRACH) extraction and filtering, etc.) based on functional decomposition such as lower-layer functional decomposition, or both. In this architecture, the RU 140 can be implemented to handle over-the-air (OTA) communications with one or more UE 104s. In some specific implementations, the real-time and non-real-time aspects of communication with the control plane and user plane of the RU 140 may be controlled by the corresponding DU 130. In some scenarios, this configuration allows the DU130 and CU 110 to be implemented in cloud-based RAN architectures such as vRAN architectures.

[0044] SMO framework 105 can be configured to support RAN deployment and provisioning of both non-virtualized and virtualized network elements. For non-virtualized network elements, SMO framework 105 can be configured to support the deployment of dedicated physical resources for RAN coverage conditions, which can be managed via operation and maintenance interfaces such as the O1 interface. For virtualized network elements, SMO framework 105 can be configured to interact with a cloud computing platform such as Open Cloud (O-Cloud) 190 to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface such as the O2 interface. Such virtualized network elements may include, but are not limited to, CU 110, DU 130, RU 140, and near-RT RIC 125. In some implementations, SMO framework 105 can communicate with hardware aspects of the 4G RAN, such as Open eNB (O-eNB) 111, via the O1 interface. Additionally, in some implementations, SMO framework 105 can communicate directly with one or more RU 140s via the O1 interface. SMO framework 105 may also include a non-RT RIC 115 configured to support the functionality of SMO framework 105.

[0045] The non-RT RIC 115 can be configured to include logical functions enabling non-real-time control and optimization of RAN elements and resources, including artificial intelligence (AI) / machine learning (ML) workflows for model training and updates, or policy-based guidance for applications / features in the near-RT RIC 125. The non-RT RIC 115 can be coupled to or communicate with the near-RT RIC 125, such as via an A1 interface. The near-RT RIC 125 can be configured to include logical functions enabling near real-time control and optimization of RAN elements and resources via data collection and actions through an interface such as an E2 interface, connecting one or more CU 110s, one or more DU 130s, or both, and O-eNBs to the near-RT RIC 125.

[0046] In some implementations, to generate AI / ML models to be deployed in the near-RT RIC 125, the non-RT RIC 115 may receive parameters or external enrichment information from an external server. This information can be utilized by the near-RT RIC 125 and can be received from non-network data sources or network functions at the SMO framework 105 or the non-RT RIC 115. In some examples, the non-RT RIC 115 or the near-RT RIC 125 may be configured to tune RAN behavior or performance. For example, the non-RT RIC 115 may monitor long-term trends and patterns in performance and employ AI / ML models to perform corrective actions via the SMO framework 105 (such as reconfiguration via O1) or by creating RAN management policies (such as A1 policies).

[0047] At least one of CU 110, DU 130, and RU 140 may be referred to as base station 102. Therefore, base station 102 may include one or more of CU 110, DU 130, and RU 140 (each component is indicated by a dashed line to indicate that each component may or may not be included in base station 102). Base station 102 provides UE 104 with an access point to core network 120. Base station 102 may include macro cells (high-power cellular base stations) and / or small cells (low-power cellular base stations). Small cells include femtocells, picocells, and microcells. A network that includes both small cells and macro cells may be referred to as a heterogeneous network. A heterogeneous network may also include an evolved home node B (eNB) (HeNB), which can provide service to a restricted group referred to as a closed subscriber group (CSG). The communication link between RU 140 and UE 104 may include uplink (UL) transmission (also known as reverse link) from UE 104 to RU 140 and / or downlink (DL) transmission (also known as forward link) transmission from RU 140 to UE 104. The communication link may utilize multiple-input multiple-output (MIMO) antenna techniques, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link may use one or more carriers. For each carrier allocated in a carrier aggregation of up to Yx MHz (x component carriers) for transmission in each direction, base station 102 / UE 104 may use a spectrum with a bandwidth of up to Y MHz (e.g., 5MHz, 10MHz, 15MHz, 20MHz, 100MHz, 400MHz, etc.). Carriers may be adjacent to each other or may not be adjacent to each other. Carrier allocation may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated to DL compared to UL). Component carriers may include primary component carriers and one or more secondary component carriers. The primary component carrier can be referred to as the primary cell (PCell) and the secondary component carrier can be referred to as the secondary cell (SCell).

[0048] The link between UE 104 and base station 102 can be established as an access link, for example, using the UE Universal Terrestrial Radio Access Network (UTRAN) (Uu) interface. Some UEs 104 may communicate with each other using device-to-device (D2D) communication link 158. D2D communication link 158 may use DL / UL Wireless Wide Area Network (WWAN) spectrum. D2D communication link 158 may use one or more sidelink channels, such as Physical Sidelink Broadcast Channel (PSBCH), Physical Sidelink Discovery Channel (PSDCH), Physical Sidelink Shared Channel (PSSCH), and Physical Sidelink Control Channel (PSCCH). D2D communication can be performed through various wireless D2D communication systems, such as, for example, Bluetooth. ™ (Bluetooth is a trademark of the Bluetooth Special Interest Group (SIG), and is based on the IEEE 802.11 standard for Wi-Fi.) ™ (Wi-Fi is a trademark of the Wi-Fi Alliance), LTE, or NR.

[0049] Examples of sidelink communication may include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) (e.g., from a vehicle-based communication device to a road infrastructure node such as a roadside unit (RSU), vehicle-to-network (V2N) (e.g., from a vehicle-based communication device to one or more network nodes such as a base station), vehicle-to-pedestrian (V2P), cellular vehicle-to-everything (C-V2X), and / or combinations thereof, and / or vehicle-based communication devices communicating with other devices; these communications can be collectively referred to as vehicle-to-everything (V2X) communication. Sidelink communication may be based on V2X or other D2D communication, such as Proximity Services (ProSe). In addition to the UE, sidelink communication via D2D communication link 158 may also be transmitted and received by other transmitting and receiving devices (such as roadside unit (RSU) 107). The PC5 interface can be used to exchange sidelink communication, such as in combination with... Figure 4 The examples described in [the document] are as follows. Although including [other examples]... Figure 4 The following description of an example time slot structure provides an example of sidelink communication in conjunction with 5G NR, but the concepts described herein are applicable to other similar fields such as LTE, LTE-A, CDMA, GSM, and other wireless technologies.

[0050] The wireless communication system may also include a Wi-Fi AP 150, which communicates with the UE 104 (also referred to as a Wi-Fi station (STA)) via a communication link 154, for example, in an unlicensed spectrum such as 5 GHz. When communicating in unlicensed spectrum, the UE 104 / AP 150 may perform a free channel assessment (CCA) to determine whether a channel is available before communication.

[0051] The electromagnetic spectrum is typically subdivided into various categories, bands, channels, etc., based on frequency / wavelength. In 5G NR, two initial operating bands have been designated as frequency ranges FR1 (410MHz-7.125GHz) and FR2 (24.25GHz-52.6GHz). Although a portion of FR1 is greater than 6GHz, in various documents and articles, FR1 is often (interchangeably) referred to as the "sub-6GHz" band. Similar naming issues sometimes occur with FR2, which is often (interchangeably) referred to as the "millimeter wave" band in documents and articles, although this is distinct from the Extremely High Frequency (EHF) band (30GHz to 300GHz) designated as "millimeter wave" by the International Telecommunication Union (ITU).

[0052] The frequencies between FR1 and FR2 are generally referred to as mid-band frequencies. Recent 5G NR studies have identified the operating bands used for these mid-band frequencies as the frequency range designation FR3 (7.125 GHz to 24.25 GHz). Bands falling within FR3 can inherit FR1 and / or FR2 characteristics, thus effectively extending the features of FR1 and / or FR2 to mid-band frequencies. Additionally, higher frequency bands are currently being explored to extend 5G NR operation beyond 52.6 GHz. For example, three higher operating bands have been identified as the frequency range designations FR2-2 (52.6 GHz to 71 GHz), FR4 (71 GHz to 114.25 GHz), and FR5 (114.25 GHz to 300 GHz). Each of these higher frequency bands falls within the EHF band.

[0053] In view of the above, unless otherwise specified, the term "below 6 GHz" as used herein can broadly refer to frequencies less than 6 GHz, within FR1, or including intermediate frequency band frequencies. Furthermore, unless otherwise specified, the term "millimeter wave" as used herein can broadly refer to frequencies that can include intermediate frequency band frequencies, within FR2, FR4, FR2-2 and / or FR5, or within the EHF band.

[0054] Base station 102 and UE 104 may each include multiple antennas (such as antenna elements, antenna panels, and / or antenna arrays) to facilitate beamforming. Base station 102 may transmit beamformed signals 182 to UE 104 in one or more transmit directions. UE 104 may receive beamformed signals from base station 102 in one or more receive directions. UE 104 may also transmit beamformed signals 184 to base station 102 in one or more transmit directions. Base station 102 may receive beamformed signals from UE 104 in one or more receive directions. Base station 102 / UE 104 may perform beamforming training to determine the optimal receive and transmit directions for each of base station 102 / UE 104. The transmit and receive directions of base station 102 may be the same or different. The transmit and receive directions of UE 104 may be the same or different.

[0055] Base station 102 may include and / or be referred to as gNB, Node B, eNB, access point, transceiver base station, radio base station, radio transceiver, transceiver function, basic service set (BSS), extended service set (ESS), TRP, network node, network entity, network equipment, or some other suitable terminology. Base station 102 may be implemented as an integrated access and backhaul (IAB) node, relay node, sidelink node, aggregated (monolithic) base station with baseband units (BBU) (including CU and DU) and RU, or may be implemented as a decomposed base station including one or more of CU, DU, and / or RU. A collection of base stations that may include decomposed base stations and / or aggregated base stations may be referred to as Next Generation (NG) RAN (NG-RAN).

[0056] The core network 120 may include Access and Mobility Management Function (AMF) 161, Session Management Function (SMF) 162, User Plane Function (UPF) 163, Unified Data Management (UDM) 164, one or more location servers 168, and other functional entities. AMF 161 is the control node that handles signaling between UE 104 and the core network 120. AMF 161 supports registration management, connection management, mobility management, and other functions. SMF 162 supports session management and other functions. UPF 163 supports packet routing, packet forwarding, and other functions. UDM 164 supports authentication and key agreement (AKA) credential generation, user identity processing, access authorization, and subscription management. One or more location servers 168 are exemplified as including a Gateway Mobile Location Center (GMLC) 165 and a Location Management Function (LMF) 166. However, generally, one or more location servers 168 may include one or more location / positioning servers, which may include one or more of GMLC 165, LMF 166, Position Determination Entity (PDE), Serving Mobile Location Center (SMLC), Mobile Location Center (MPC), etc. GMLC 165 and LMF 166 support UE location services. GMLC 165 provides an interface for clients / applications (e.g., emergency services) to access UE location information. LMF 166 receives measurement and auxiliary information from NG-RAN and UE 104 via AMF 161 to calculate the location of UE 104. NG-RAN may use one or more positioning methods to determine the location of UE 104. Positioning UE 104 may involve signal measurement, location estimation, and optional rate calculation based on these measurements. Signal measurement may be performed by UE 104 and / or base station 102 serving UE 104. The measured signals may be based on one or more of the following: Satellite Positioning System (SPS) 170 (e.g., one or more of Global Navigation Satellite System (GNSS), Global Positioning System (GPS), Non-Terrestrial Network (NTN) or other satellite positioning / location systems), LTE signals, Wireless Local Area Network (WLAN) signals, Bluetooth signals, Terrestrial Beacon System (TBS), sensor-based information (e.g., barometric pressure sensor, motion sensor), NR Enhanced Cell ID (NR E-CID) method, NR signals (e.g., multiple round-trip time (multiple RTT), DL departure angle (DL-AoD), DL time difference of arrival (DL-TDOA), UL time difference of arrival (UL-TDOA), and UL angle of arrival (UL-AoA) positioning) and / or other systems / signals / sensors.

[0057] Examples of UE 104 include cellular phones, smartphones, Session Initiation Protocol (SIP) phones, laptops, personal digital assistants (PDAs), satellite radios, GPS devices, multimedia devices, video devices, digital audio players (e.g., MP3 players), cameras, game consoles, tablets, smart devices, wearable devices, vehicles, electricity meters, air pumps, large or small kitchen appliances, healthcare devices, implants, sensors / actuators, displays, or any other similarly functional device. Some UEs in UE 104 may be referred to as IoT devices (e.g., parking meters, air pumps, toasters, vehicles, heart monitors, etc.). UE 104 may also be referred to as a station, mobile station, subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, mobile phone, user agent, mobile client, client, or some other suitable terminology. In some scenarios, the term UE may also be applied to one or more companion devices, such as in a device constellation arrangement. One or more of these devices may access the network together and / or individually.

[0058] Refer again Figure 1 In some aspects, UE 104 may have an ODD handover calculation component 198, which is configured to receive a set of attributes associated with the route of UE 104. The ODD handover calculation component 198 may be configured to calculate a predicted number of Operational Design Domain (ODD) handovers along the route based on the attribute set. The ODD handover calculation component 198 may be configured to notify the driver associated with UE 104 of the ODD status based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. The ODD handover calculation component 198 may be configured to disable the ODD mode associated with UE 104 based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. In some aspects, base station 102 may have a route attribute aggregation component 199, which is configured to receive an attribute set from each UE in a set of UEs (e.g., UEs similar to UE 104 with ODD handover calculation component 198). Each attribute in the attribute set may be associated with a route. The route attribute aggregation component 199 may aggregate the attribute set to generate multiple attributes associated with the route. The route attribute aggregation component 199 can send multiple attributes to a UE (such as UE 104). The route attribute aggregation component 199 can send multiple sets of attributes to each of multiple UEs, where each set of attributes is associated with a route. The ODD handover calculation component 198 can use the multiple attributes to calculate the predicted number of ODD handovers associated with the route of UE 104.

[0059] Figure 2A Figure 200 illustrates an example of the first subframe within a 5G NR frame structure. Figure 2B Figure 230 illustrates an example of a DL channel within a 5G NR subframe. Figure 2C Figure 250 is an example of a second subframe within a 5G NR frame structure. Figure 2D Figure 280 illustrates an example of a UL channel within a 5G NR subframe. The 5G NR frame structure can be Frequency Division Duplex (FDD) (where subframes within a specific set of subcarriers (carrier system bandwidth) are dedicated to either DL or UL) or Time Division Duplex (TDD) (where subframes within a specific set of subcarriers (carrier system bandwidth) are dedicated to both DL and UL). Figure 2A , Figure 2C In the provided example, the 5G NR frame structure is assumed to be TDD, where subframe 4 is configured with slot format 28 (most of which are DL), where D is DL, U is UL, and F is flexible and can be used between DL / UL, and subframe 3 is configured with slot format 1 (all of which are UL). Although subframes 3 and 4 are shown as having slot formats 1 and 28 respectively, any particular subframe can be configured with any of the various available slot formats 0-61. Slot formats 0 and 1 are both DL and UL, respectively. Other slot formats 2-61 include a mixture of DL, UL, and flexible symbols. The UE is configured using the slot format via the received Slot Format Indicator (SFI) (dynamically configured via DL Control Information (DCI) or semi-statically / statically configured via Radio Resource Control (RRC) signaling). Note that the following description also applies to the 5G NR frame structure as TDD.

[0060] Figures 2A to 2DThe frame structure is illustrated, and aspects of this disclosure are applicable to other wireless communication technologies that may have different frame structures and / or different channels. A frame (10 ms) can be divided into 10 equal-sized subframes (1 ms). Each subframe may include one or more time slots. Subframes may also include micro-time slots, which may include 7, 4, or 2 symbols. Each time slot may include 14 or 12 symbols, depending on whether the cyclic prefix (CP) is normal or extended. For normal CP, each time slot may include 14 symbols, and for extended CP, each time slot may include 12 symbols. Symbols on the DL can be CP Orthogonal Frequency Division Multiplexing (OFDM) (CP-OFDM) symbols. Symbols on the UL can be CP-OFDM symbols (for high-throughput scenarios) or Discrete Fourier Transform (DFT) Extended OFDM (DFT-s-OFDM) symbols (for power-constrained scenarios; limited to single-stream transmission). The number of time slots within a subframe is based on the CP and a parameter set. The parameter set defines the subcarrier spacing (SCS) (see Table 1). The symbol length / duration can be scaled by 1 / SCS.

[0061]

[0062] Table 1: Parameter Set, SCS, and CP

[0063] For a normal CP (14 symbols / slot), different parameter sets µ 0 through 4 allow 1, 2, 4, 8, and 16 slots per subframe, respectively. For an extended CP, parameter set 2 allows 4 slots per subframe. Therefore, for a normal CP and parameter set µ, there are 14 symbols / slot and 2... µ One time slot / subframe. Subcarrier spacing can be equal to ,in The parameter sets are 0 to 4. Therefore, the subcarrier spacing is 15 kHz for parameter set µ=0 and 240 kHz for parameter set µ=4. The symbol length / duration is negatively correlated with the subcarrier spacing. Figures 2A to 2D Examples of a normal frequency division multiplexing (CP) with 14 symbols per time slot and a parameter set of µ=2 with 4 time slots per subframe are provided. The time slot duration is 0.25 ms, the subcarrier spacing is 60 kHz, and the symbol duration is approximately 16.67 μs. Within the frame set, there may be one or more distinct bandwidth portions (BWPs) of frequency division multiplexing (see [link to relevant documentation]). Figure 2B Each BWP can have a specific set of parameters and CP (normal or extended).

[0064] A resource grid can be used to represent the frame structure. Each time slot consists of a resource block (RB) extending for 12 consecutive subcarriers (also known as a physical RB (PRB)). The resource grid is divided into multiple resource elements (REs). The number of bits carried by each RE depends on the modulation scheme.

[0065] like Figure 2A As illustrated, some REs carry reference (pilot) signals (RS) for the UE. RS may include demodulation RS (DM-RS) (indicated as R for a particular configuration, but other DM-RS configurations are possible) and channel state information reference signals (CSI-RS) for channel estimation at the UE. RS may also include beam measurement RS (BRS), beam refinement RS (BRRS), and phase tracking RS (PT-RS).

[0066] Figure 2B Examples of various DL channels within a subframe of a frame are illustrated. The Physical Downlink Control Channel (PDCCH) carries the DCI within one or more Control Channel Elements (CCEs) (e.g., 1, 2, 4, 8, or 16 CCEs), each CCE comprising six RE Groups (REGs), each REG comprising 12 consecutive REs in an OFDM symbol of an RB. A PDCCH within a BWP may be referred to as a Control Resource Set (CORESET). The UE is configured to monitor PDCCH candidates in a PDCCH search space (e.g., a common search space, a UE-specific search space) during PDCCH monitoring timing on a CORESET, where PDCCH candidates have different DCI formats and different aggregation levels. Additional BWPs may be located at higher and / or lower frequencies on the channel bandwidth. The Primary Synchronization Signal (PSS) may be located within symbol 2 of a specific subframe of the frame. The PSS is used by the UE 104 to determine subframe / symbol timing and physical layer identification. The Secondary Synchronization Signal (SSS) may be located within symbol 4 of a specific subframe of the frame. The SSS is used by the UE to determine the Physical Layer Cell Identifier Group Number and radio frame timing. Based on the Physical Layer Identifier and the Physical Layer Cell Identifier Group Number, the UE can determine the Physical Cell Identifier (PCI). Based on the PCI, the UE can determine the location of the DM-RS. The Physical Broadcast Channel (PBCH), carrying the Master Information Block (MIB), can be logically grouped with the PSS and SSS to form a Synchronization Signal (SS) / PBCH block (also known as an SS block (SSB)). The MIB provides the number of RBs in the system bandwidth and the System Frame Number (SFN). The Physical Downlink Shared Channel (PDSCH) carries user data, broadcast system information not transmitted via the PBCH (such as System Information Block (SIB)), and paging messages.

[0067] like Figure 2CAs illustrated, some REs in the REs carry DM-RS (indicated as R for one particular configuration, but other DM-RS configurations are possible) for channel estimation at the base station. The UE can transmit DM-RS for the Physical Uplink Control Channel (PUCCH) and DM-RS for the Physical Uplink Shared Channel (PUSCH). The PUSCH DM-RS can be transmitted in the first or first two symbols of the PUSCH. Depending on whether a short or long PUCCH is transmitted and depending on the specific PUCCH format used, the PUCCH DM-RS can be transmitted in different configurations. The UE can transmit a Sounding Reference Signal (SRS). The SRS can be transmitted in the last symbol of a subframe. The SRS can have a comb structure, and the UE can transmit the SRS on one of the comb teeth. The SRS can be used by the base station for channel quality estimation to enable frequency-dependent scheduling of the UL.

[0068] Figure 2D Examples of various UL channels within a subframe of a frame are illustrated. The PUCCH may be located as indicated in one configuration. The PUCCH carries uplink control information (UCI), such as scheduling requests, channel quality indicators (CQI), pre-decoding matrix indicators (PMI), rank indicators (RI), and hybrid automatic repeat request (HARQ) acknowledgment (ACK) (HARQ-ACK) feedback (i.e., one or more HARQ ACK bits indicating one or more ACKs and / or negative ACKs (NACKs)). The PUCCH carries data and may additionally be used to carry buffer status reports (BSR), power clearance reports (PHR), and / or UCIs.

[0069] Figure 3This is a block diagram illustrating communication between base station 310 and UE 350 in the access network. In the DL, Internet Protocol (IP) packets can be provided to controller / processor 375. Controller / processor 375 implements Layer 3 and Layer 2 functionality. Layer 3 includes the Radio Resource Control (RRC) layer, and Layer 2 includes the Service Data Adaptation Protocol (SDAP) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, and Media Access Control (MAC) layer. The controller / processor 375 provides RRC layer functionality associated with broadcasting system information (e.g., MIB, SIB), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-Radio Access Technology (RAT) mobility, and measurement configuration for UE measurement reporting; PDCP layer functionality associated with header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functionality associated with the delivery of upper-layer packet data units (PDUs), error correction via ARQ, concatenation, segmentation, and reassembly of RLC service data units (SDUs), resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority handling, and logical channel priority ordering.

[0070] Transmit (TX) processor 316 and receive (RX) processor 370 implement Layer 1 functionality associated with various signal processing functions. Layer 1 (which includes the physical (PHY) layer) may include error detection on the transport channel, forward error correction (FEC) decoding / decoding of the transport channel, interleaving, rate matching, mapping to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. TX processor 316 processes the mapping to the signal constellation based on various modulation schemes (e.g., binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), M-order phase shift keying (M-PSK), M-order quadrature amplitude modulation (M-QAM)). The decoded and modulated symbols can then be split into parallel streams. Each stream can then be mapped to OFDM subcarriers, multiplexed with a reference signal (e.g., a pilot) in the time and / or frequency domains, and then combined using inverse fast Fourier transform (IFFT) to produce a physical channel carrying a stream of time-domain OFDM symbols. The OFDM stream is spatially pre-decoded to generate multiple spatial streams. Channel estimates from channel estimator 374 are used to determine the decoding and modulation scheme, as well as for spatial processing. Channel estimates can be derived from reference signals transmitted by UE 350 and / or channel condition feedback. Each spatial stream can then be provided to a different antenna 320 via a separate transmitter 318Tx. Each transmitter 318Tx can use the corresponding spatial stream to modulate a radio frequency (RF) carrier for transmission.

[0071] At UE 350, each receiver 354Rx receives signals via its corresponding antenna 352. Each receiver 354Rx recovers the information modulated onto the RF carrier and provides that information to the receive (RX) processor 356. The TX processor 368 and RX processor 356 implement Layer 1 functionality associated with various signal processing functions. The RX processor 356 can perform spatial processing on the information to recover any spatial stream destined for UE 350. If multiple spatial streams are destined for UE 350, the RX processor 356 can combine them into a single OFDM symbol stream. The RX processor 356 then uses a Fast Fourier Transform (FFT) to transform the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal consists of a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, along with the reference signal, are recovered and demodulated by determining the most probable signal constellation points transmitted by base station 310. These soft decisions can be based on channel estimates calculated by channel estimator 358. The soft decision is then decoded and deinterleaved to recover the data and control signals originally transmitted by base station 310 on the physical channel. The data and control signals are then provided to controller / processor 359, which implements layer 3 and layer 2 functionality.

[0072] The controller / processor 359 may be associated with at least one memory 360 storing program code and data. The at least one memory 360 may be referred to as a computer-readable medium. In the UL, the controller / processor 359 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between transport and logical channels to recover IP packets. The controller / processor 359 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0073] Similar to the functionality described in conjunction with DL transmission performed by base station 310, controller / processor 359 provides RRC layer functionality associated with system information (e.g., MIB, SIB) acquisition, RRC connectivity, and measurement reporting; PDCP layer functionality associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functionality associated with upper-layer PDU delivery, error correction via ARQ, concatenation, segmentation and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs to TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority handling, and logical channel priority ordering.

[0074] The TX processor 368 can use the reference signal transmitted from the base station 310 or the channel estimate derived from feedback by the channel estimator 358 to select an appropriate decoding and modulation scheme and facilitate spatial processing. The spatial stream generated by the TX processor 368 can be provided to different antennas 352 via individual transmitters 354Tx. Each transmitter 354Tx can use the corresponding spatial stream to modulate an RF carrier for transmission.

[0075] UL transmission is processed at base station 310 in a manner similar to that described in conjunction with the receiver function at UE 350. Each receiver 318Rx receives signals via its corresponding antenna 320. Each receiver 318Rx recovers the information modulated onto the RF carrier and provides that information to RX processor 370.

[0076] The controller / processor 375 may be associated with at least one memory 376 storing program code and data. The at least one memory 376 may be referred to as a computer-readable medium. In the UL, the controller / processor 375 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets between transport and logical channels. The controller / processor 375 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0077] At least one of the TX processor 368, RX processor 356, and controller / processor 359 can be configured to perform and Figure 1 The ODD switching computing component 198 combines various aspects.

[0078] At least one of the TX processor 316, RX processor 370, and controller / processor 375 can be configured to perform and Figure 1 The route attribute aggregation component 199 combines various aspects.

[0079] Figure 4 Figures 400 and 410 illustrate example aspects of time slot structures that can be used for sidelink communication (e.g., between UE 104, RSU 107, etc.). In some examples, the time slot structure may be within a 5G / NR frame structure. In other examples, the time slot structure may be within an LTE frame structure. While the following description may focus on 5G NR, the concepts described herein may be applicable to other similar domains such as LTE, LTE-A, CDMA, GSM, and other wireless technologies. Figure 4 The example time slot structure in the diagram is merely an example, and other sidelink communications may have different frame structures and / or different channels for sidelink communication. A frame (10 ms) can be divided into 10 equally sized subframes (1 ms). Each subframe may include one or more time slots. Subframes may also include micro-time slots, which may include 7, 4, or 2 symbols. Each time slot may include 7 or 14 symbols, depending on the time slot configuration. For time slot configuration 0, each time slot may include 14 symbols, and for time slot configuration 1, each time slot may include 7 symbols. Figure 400 illustrates, for example, a single resource block that may correspond to a single time slot of a 0.5 ms transmission time interval (TTI). The physical sidelink control channel may be configured to occupy multiple physical resource blocks (PRBs), for example, 10, 12, 15, 20, or 25 PRBs. The PSCCH may be limited to a single subchannel. The PSCCH duration may be configured, for example, 2 or 3 symbols. Subchannels may include, for example, 10, 15, 20, 25, 50, 75, or 100 PRBs. Resources for sidelink transmission can be selected from a resource pool comprising one or more subchannels. As a non-limiting example, a resource pool may include between 1 and 27 subchannels. A PSCCH size may be established for the resource pool, for example, set to be between 10% and 100% of a subchannel over a duration of 2 or 3 symbols. Figure 4Figure 410 illustrates an example where the PSCCH occupies approximately 50% of the subchannel, serving as an example to illustrate the concept of the PSCCH occupying a portion of a subchannel. The Physical Sidelink Shared Channel (PSSCH) occupies at least one subchannel. In some examples, the PSCCH may include a first portion of the Sidelink Control Information (SCI), and the PSSCH may include a second portion of the SCI.

[0080] A resource grid can be used to represent frame structure. Each time slot may include a resource block (RB) extending for 12 consecutive subcarriers (also known as a physical RB (PRB)). The resource grid is divided into multiple resource elements (REs). The number of bits carried by each RE depends on the modulation scheme. Figure 4 As illustrated, some REs in the REs may include control information from the PSCCH, and some REs may include demodulation RS (DMRS). At least one symbol may be used for feedback. Figure 4 An example of a two-symbol Physical Side Link Feedback Channel (PSFCH) with adjacent gap symbols is illustrated. The symbols before and / or after the feedback can be used for the transition between data reception and feedback transmission. This gap allows the device to switch from operating as a transmitting device to preparing to operate as a receiving device, for example, in a subsequent time slot. As illustrated, data can be transmitted in the remaining RE. This data may include the data messages described herein. The positioning of any of the data, DMRS, SCI, feedback, gap symbols, and / or LBT symbols may differ. Figure 4 The example shown illustrates this. In some respects, multiple time slots can be aggregated together.

[0081] Figure 5 This is a block diagram illustrating communication between wireless communication device 510 and wireless communication device 550 via a sidelink. Wireless communication device 510 can be a UE, RSU, or base station. Wireless communication device 550 can be a UE, RSU, or base station. In some examples, wireless communication device 510 and wireless communication device 550 can communicate based on V2X or other D2D communication. This communication can be based on a sidelink using a PC5 interface. Packets can be provided to a controller / processor 575 implementing layer 3 and layer 2 functionality. Layer 3 includes the RRC layer, and layer 2 includes the PDCP layer, RLC layer, and MAC layer.

[0082] TX processor 516 and RX processor 570 implement Layer 1 functionality associated with various signal processing functions. Layer 1, including the PHY layer, may include error detection of the transport channel, FEC decoding / decoding of the transport channel, interleaving, rate matching, mapping to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. TX processor 516 handles the mapping to the signal constellation based on various modulation schemes (e.g., BPSK, QPSK, M-PSK, M-QAM). The decoded and modulated symbols can then be split into parallel streams. Each stream can then be mapped to OFDM subcarriers, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domains, and then combined using IFFT to generate a physical channel carrying a stream of time-domain OFDM symbols. The OFDM streams are spatially pre-decoded to generate multiple spatial streams. Channel estimates from channel estimator 574 can be used to determine the decoding and modulation schemes, as well as for spatial processing. Channel estimates can be derived from reference signals and / or channel condition feedback transmitted by wireless communication device 550. Each spatial stream can then be provided to a different antenna 520 via a separate transmitter 518Tx. Each transmitter 518Tx can use the corresponding spatial stream to modulate an RF carrier for transmission.

[0083] At the wireless communication device 550, each receiver 554Rx receives a signal via its corresponding antenna 552. Each receiver 554Rx recovers the information modulated onto the RF carrier and provides this information to the RX processor 556. The TX processor 568 and the RX processor 556 implement Layer 1 functionality associated with various signal processing functions. The RX processor 556 can perform spatial processing on the information to recover any spatial stream destined for the wireless communication device 550. If multiple spatial streams are destined for the wireless communication device 550, the RX processor 556 can combine them into a single OFDM symbol stream. The RX processor 556 then uses FFT to transform the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal consists of a separate OFDM symbol stream for each subcarrier of the OFDM signal. The reference signal and the symbols on each subcarrier are recovered and demodulated by determining the signal constellation points most likely to be transmitted by the wireless communication device 510. These soft decisions can be based on a channel estimate calculated by the channel estimator 558. The soft decision is then decoded and deinterleaved to recover the data and control signals originally transmitted by the wireless communication device 510 on the physical channel. The data and control signals are then provided to the controller / processor 559, which implements layer 3 and layer 2 functionality.

[0084] The controller / processor 559 may be associated with at least one memory 560 storing program code and data. The at least one memory 560 may be referred to as a computer-readable medium. In the UL, the controller / processor 559 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between transport and logical channels to recover IP packets. The controller / processor 559 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0085] Similar to the functionality described in conjunction with the transmissions performed by the wireless communication device 510, the controller / processor 559 can provide RRC layer functionality associated with system information (e.g., MIB, SIB) acquisition, RRC connectivity, and measurement reporting; PDCP layer functionality associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functionality associated with the transmission of upper-layer PDUs, error correction via ARQ, concatenation, segmentation, and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority handling, and logical channel priority ordering.

[0086] The channel estimate derived by the channel estimator 558 from the reference signal or feedback transmitted by the wireless communication device 510 can be used by the TX processor 568 to select an appropriate decoding and modulation scheme, as well as to facilitate spatial processing. The spatial stream generated by the TX processor 568 can be provided to different antennas 552 via individual transmitters 554Tx. Each transmitter 554Tx can use the corresponding spatial stream to modulate an RF carrier for transmission.

[0087] Transmission is processed at wireless communication device 510 in a manner similar to that described in conjunction with the receiver function at wireless communication device 550. Each receiver 518Rx receives signals via its corresponding antenna 520. Each receiver 518Rx recovers the information modulated onto the RF carrier and provides that information to the RX processor 570.

[0088] The controller / processor 575 may be associated with at least one memory 576 storing program code and data. The at least one memory 576 may be referred to as a computer-readable medium. The controller / processor 575 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets between the transport channel and the logical channel. The controller / processor 575 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0089] At least one of the TX processor 568, RX processor 556, and controller / processor 559 can be configured to perform and Figure 1 The ODD switching computing component 198 combines various aspects.

[0090] At least one of the TX processor 516, RX processor 570, and controller / processor 575 can be configured to perform operations related to... Figure 1 The ODD switching computing component 198 combines various aspects.

[0091] Figure 6 Example 600 illustrates sidelink communication between devices. Communication can be based on, including, a combination of... Figure 4 The time slot structure of the described aspects. For example, UE 602 can transmit, for example, a transmission 614 including a control channel (e.g., PSCCH) and / or a corresponding data channel (e.g., PSSCH), which can be received by UEs 604, 606, and 608. The control channel may include information for decoding the data channel (e.g., sidelink control information (SCI)), which includes reservation information, such as information about time and / or frequency resources reserved for data channel transmission. For example, the SCI may indicate the number of TTIs and RBs to be occupied by data transmission. The SCI can also be used by the receiving device to avoid interference by avoiding transmission on reserved resources. UEs 602, 604, 606, and 608 are each capable of sidelink transmission in addition to sidelink reception. Therefore, UEs 604, 606, and 608 are illustrated as transmissions 613, 615, 616, and 620. Transmissions 613, 614, 615, 616, and 620 can be unicast, broadcast, or multicast to nearby devices. For example, UE 604 can transmit transmissions 613 and 615 intended to be received by other UEs within range 601 of UE 604, and UE 606 can transmit transmission 616. In some aspects, RSU 607 can receive communications from UEs 602, 604, 606, and 608, and / or transmit communications 618 to these UEs. One or more of UEs 602, 604, 606, and 608 may include, for example, a combination of... Figure 1 The described ODD switching calculation component 198. RSU 607 may include, for example, in combination with Figure 1 The described route attribute aggregation component is 199.

[0092] Sidelink communication can be based on different types or modes of resource allocation mechanisms. In a first resource allocation mode (which may be referred to herein as "Mode 1"), centralized resource allocation can be provided by a network entity. For example, base station 102 can determine resources for sidelink communication and allocate these resources to different UEs 104 for sidelink transmission. In this first mode, the UE receives the sidelink resource allocation from base station 102. In a second resource allocation mode (which may be referred to herein as "Mode 2"), distributed resource allocation can be provided. In Mode 2, each UE can autonomously determine the resources for sidelink transmission. To coordinate the selection of sidelink resources by each UE, each UE can use sensing technology to monitor the resource reservations of other sidelink UEs and can select resources for sidelink transmission from unreserved resources. Devices communicating based on sidelinks can determine one or more radio resources used by other devices in the time and frequency domains to select transmission resources that avoid conflicts with other devices.

[0093] Sidelink transmission and / or resource reservation can be periodic or aperiodic, whereby the UE can reserve resources for transmission in the current time slot and up to two future time slots (as discussed below).

[0094] Therefore, in this second mode (e.g., mode 2), each UE can autonomously select resources for sidelink transmission, for example, in the absence of a central entity (such as a base station indicating resources for a device). The first UE can reserve the selected resources to notify other UEs about the resources that the first UE intends to use for sidelink transmission.

[0095] In some examples, resource selection for sidelink communication can be based on sensing mechanisms. For instance, before selecting resources for data transmission, the UE can first determine whether the resources have already been reserved by other UEs.

[0096] For example, as part of the sensing mechanism for resource allocation mode 2, the UE can determine (e.g., sense) whether the selected sidelink resource has been reserved by another UE before selecting it for data transmission. If the UE determines that the sidelink resource has not been reserved by another UE, the UE can use the selected sidelink resource for data transmission, for example, in PSSCH transmission. The UE can estimate or determine which radio resources (e.g., sidelink resources) are in use and / or reserved by other UEs by detecting and decoding sidelink control information (SCI) transmitted by other UEs. The UE can use a sensing-based resource selection algorithm to estimate or determine which radio resources are in use and / or reserved by other UEs. The UE can receive an SCI from another UE, which includes reservation information based on the resource reservation field of that SCI. The UE continuously monitors (e.g., senses) and decodes SCIs from peer UEs. The SCI may include reservation information, such as a time slot and RB indicating that a particular UE has selected for future transmission. The UE can exclude resources used and / or reserved by other UEs from a candidate resource set used by the UE for sidelink transmission, and the UE can select / reserve resources from unused resources that thus form the candidate resource set for sidelink transmission. The UE can continuously sense SCIs with resource reservations to maintain a candidate resource set from which it can select one or more resources for sidelink transmission. Once the UE selects candidate resources, it can transmit an SCI indicating its own reservation of resources for sidelink transmission. The amount of resources reserved by the UE (e.g., sub-channels per subframe) can depend on the size of the data to be transmitted by the UE. Although this example is described with respect to the UE receiving reservation information from another UE, reservation information can also be received from the RSU or other devices communicating via the sidelink.

[0097] In some aspects, UE 602 may have a sensor set 603 (e.g., a barometer / altimeter; motion sensors such as an inertial measurement unit (IMU), gyroscope, and / or accelerometer; light detection and ranging (LIDAR), radio-assisted detection and ranging (RADAR), sound navigation and ranging (SONAR), magnetometer, audio, and / or other technologies for positioning) configured to sense a set of attributes relating to a vehicle associated with UE 602. Sensor set 603 may sense the vehicle's speed (e.g., mph, kph), weather patterns (e.g., humidity, wind speed, rainfall), road features (e.g., the presence / absence of physical obstacles along the road), and / or road attributes (e.g., how many lanes are in the road and which lane the vehicle is in). UE 602 can adjust the autonomous driving system based on sensor information from sensor set 603, such as determining whether UE 602 is within the ODD associated with the autonomous driving system, activating the autonomous driving system when UE 602 is within the ODD, and deactivating the autonomous driving system when UE 602 is not within the ODD.

[0098] Figure 7 Example 700 illustrates reserved time and frequency resources for sidelink transmission. For example, resources may be included in a sidelink resource pool. Resource allocation for each UE may be in units of one or more sub-channels (e.g., sub-channels SC1 to SC4) in the frequency domain and may be based on a timeslot in the time domain. UEs may also use resources in the current timeslot to perform initial transmission and may reserve resources in future timeslots for retransmission. In this example, UE1 and UE2 are reserving two different future timeslots for retransmission. Resource reservation may be limited to a predefined window of timeslots and sub-channels, such as an 8-timeslot multiplied by 4-sub-channel window as shown in Example 700, which provides a total of 32 available resource blocks. This window may also be referred to as a resource selection window.

[0099] The first UE (“UE1”) may reserve a sub-channel (e.g., SC 1) in the current time slot (e.g., time slot 1) for data transmission 702, and may reserve additional future time slots within this window for data retransmission (e.g., data retransmission 704 and data retransmission 706). For example, UE1 may reserve sub-channel SC 3 in time slot 3 and sub-channel SC2 in time slot 4 for future retransmissions, as follows: Figure 4 As shown. Then, UE1 sends information to other UEs about which resources it is using and / or reserving. UE1 can do this by including the reservation information in the reserved resource field of the SCI (e.g., the Phase 1 SCI).

[0100] Figure 7Example: A second UE (“UE2”) reserves resources in sub-channels SC3 and SC4 in time slot 1 for data transmission 708, and reserves resources in time slot 4 for data transmission using sub-channels SC3 and SC4 710, and reserves resources in time slot 7 for data transmission using sub-channels SC1 and SC2 712, as shown. Figure 7 As shown. Similarly, UE2 can use, for example, the reserved resource field in SCI to send resource usage and reservation information to other UEs.

[0101] The third UE may consider selecting resources reserved by other UEs within a resource selection window to transmit its data. The third UE may first decode the SCI within a time period to identify which resources are available (e.g., candidate resources). For example, the third UE may exclude resources reserved by UE1 and UE2 and may select other available sub-channels and time slots from the candidate resources for its transmission and retransmission, based on the number of adjacent sub-channels that the data to be transmitted (e.g., packets) can be adapted to.

[0102] Although Figure 7 The example illustrates that resources are reserved for the initial transmission and two retransmissions, but this reservation can be for the initial transmission and a single transmission or for the initial transmission only.

[0103] The UE can determine associated signal measurements (such as RSRP) for each resource reservation received by another UE. The UE can consider resources reserved in transmissions for which it measures an RSRP below a threshold to be available for its use. The UE can perform signal / channel measurements on sidelink resources already reserved and / or used by other UEs, such as by measuring the RSRP of messages (e.g., SCIs) for reserving sidelink resources. Based at least in part on signal / channel measurements, the UE can consider using / reusing sidelink resources already reserved by other UEs. For example, if the measured RSRP reaches or exceeds a threshold, the UE can exclude the reserved resource from the candidate resource set, and if the measured RSRP of the message used to reserve the resource is below the threshold, the UE can consider the reserved resource to be available. When a message reserving a resource has an RSRP below a threshold, the UE can include these resources in the candidate resource set and use / reuse such reserved resources because a low RSRP indicates that the other UE is far away, and reusing these resources is unlikely to interfere with that UE. A higher RSRP indicates that the transmitting UE, which has reserved resources, is potentially closer to the UE, and if the UE selects the same resources, the transmitting UE may experience a higher level of interference.

[0104] For example, in the first step, the UE can determine a candidate resource set (e.g., by monitoring SCIs from other UEs and removing resources reserved by other UEs from this candidate resource set for signals for which the UE measures an RSRP above a threshold). In the second step, the UE can select N resources for transmission and / or retransmission of TB. For example, the UE can randomly select N resources from the candidate resource set determined in the first step. In the third step, for each transmission, the UE can reserve future time and frequency resources for the initial transmission and up to two retransmissions. The UE can reserve resources by transmitting an SCI indicating resource reservation. For example, in Figure 7 In the example, the UE can send SCIs for reserved resources for data transmission 708, 710, and 712.

[0105] Figure 8 Figure 800 illustrates a wireless device 802 configured to dynamically adjust the ODD status of an autonomous driving system 804. The wireless device 802 can send queries to the autonomous driving system 804 to determine the set of ODD attributes associated with the ODD status of the autonomous driving system 804. For example, the autonomous driving system 804 may have an autonomous driving (AD) system or an advanced driver assistance system (ADAS) that defines the set of ODD attributes associated with the ODD of the autonomous driving system 804. The ODD attribute set may include, for example, a speed range associated with the vehicle (e.g., between 20 mph and 60 mph), road attributes associated with the vehicle (e.g., at least three lanes along the route in a single direction), road location associated with the vehicle (e.g., not located in the rightmost or leftmost lane of a road with at least three lanes traveling in a single direction along the route), proximity to road features (e.g., not within 100m of a pedestrian crossing, traffic signal, or stop sign), weather attributes (e.g., no rain, no fog), or road features (e.g., a physical divider separating the lane where the vehicle is located from lanes with oncoming traffic). In response to receiving the ODD attribute set, the wireless device 802 can determine which attributes define what is and is not the ODD of the autonomous driving system 804. The wireless device 802 may communicate with the autonomous driving system 804 via a wired connection (e.g., a Universal Serial Bus (USB) plug) or a wireless connection (e.g., a Bluetooth connection).

[0106] Wireless device 802 can wirelessly communicate with remote system collection 810 to retrieve a set of attributes associated with its route. For example, wireless device 802 can connect to other vehicles to obtain the set of attributes associated with its route. In another example, wireless device 802 can connect to other infrastructure (e.g., weather database, map database, RSU) to obtain the set of attributes associated with its route. In yet another example, wireless device 802 can connect to a cloud server (e.g., a data aggregator) to obtain the set of attributes associated with its route. In one aspect, wireless device 802 can receive a navigation map from a map aggregation server. The navigation map may include a set of attributes associated with vehicles in the area, such as the average speed of vehicles on the road, the number of vehicles on the road, road conditions (e.g., road closures, road construction), traffic accident conditions, and / or emergencies (e.g., floods, lane closures). In another aspect, wireless device 802 can receive a weather report map from a weather monitoring server. Weather reports may include a set of attributes associated with weather conditions in the area, such as current or predicted temperature or weather patterns (e.g., fog, rain, humidity, chance of precipitation). In some aspects, wireless device 802 may aggregate data from multiple remote systems to obtain a set of attributes associated with the route of wireless device 802, and may ignore attributes associated with timestamps falling outside the range, such as data older than half an hour or one hour. The set of attributes may be associated with timestamps to determine whether information is considered "real-time" (e.g., less than 10 minutes, less than 30 minutes). In some aspects, wireless device 802 may retrieve data from a set of remote systems 810 via a side link (e.g., a V2X system), via a Uu (e.g., a base station), or via Wi-Fi (e.g., an AP or STA).

[0107] Wireless device 802 can query a driver selection set associated with the driver of the vehicle associated with it from a driver selection database 806. The driver selection database 806 can be configured to retrieve a set of driver selections / attributes associated with the driver of the vehicle, for example, by selecting whether wireless device 802 notifies the driver of an ODD status in response to a calculated number of ODD switching events being greater than or equal to a threshold, or by selecting whether wireless device 802 deactivates an ODD mode associated with wireless device 802 in response to a calculated number of ODD switching events being greater than or equal to a threshold. In some aspects, wireless device 802 can be configured to retrieve the driver selection / attribute set from the driver selection database based on vehicle sensors (e.g., cameras (e.g., applying images to facial recognition software) or RFID sensors (e.g., retrieving the ID of an RFID chip associated with the driver)). Wireless device 802 may include a state machine or artificial intelligence (AI) model that calculates a predicted number of ODD switching events along the route associated with wireless device 802 based on the attribute set and the driver selections associated with the driver of the vehicle. The wireless device 802 can then make a recommendation to the driver of the vehicle via the driver interface 808 (e.g., a touchscreen device or speaker and microphone of the vehicle), thereby notifying the driver that an ODD condition has been detected. The wireless device 802 can receive a response from the driver, such as an instruction to deactivate the autonomous driving system 804 for a period of time, or an instruction to activate the autonomous driving system 804 for a period of time. In some aspects, the wireless device 802 can automatically deactivate the autonomous driving system 804 for a period of time based on determining that the predicted number of calculated ODD switching is greater than or equal to a threshold for a portion of the route of the wireless device 802.

[0108] Figure 9 Figure 900 illustrates an example of communication between devices used to implement dynamic calculation of the ODD status for UE 902. Although UE 902 is shown as a vehicle, UE 902 can be a wireless device associated with a vehicle having an Autonomous Driving System (ADS) or Advanced Driver Assistance System (ADAS), connected to the vehicle via a wireless connection (e.g., Wi-Fi, Bluetooth) or a wired connection (e.g., a Universal Serial Bus (USB) connector). Communication between devices can be based on including... Figures 2A to 2D and / or Figure 4 The time slot structure described in various aspects.

[0109] UE 902 may have a sensor set 904 configured to acquire a set of attributes associated with UE 902, such as UE 902 speed, UE 902 orientation, lane in which UE 902 is located, UE 902 position, number of vehicles in the area surrounding UE 902 (e.g., in the left lane, in the right lane, in front of UE 902), weather conditions regarding UE 902 (e.g., temperature, humidity, whether windshield wipers are on), etc. Sensor set 904 may include, for example, motion sensors, pressure sensors, cameras, microphones, altimeters, IMUs, accelerometers, LiDAR devices, RADAR devices, SONAR devices, magnetometers, and / or GNSS devices. In some aspects, UE 902 may store the set of attributes from the sensors for a period of time (e.g., 5 minutes, 10 minutes, or 30 minutes) to collect route information. For example, UE 902 can incrementally save its speed while traveling along a route, which can instruct UE 902 to increase its speed above or below a threshold speed a certain number of times as it travels from a first point to a second point. This allows UE 902, or another UE receiving the saved attribute set, to calculate the number of ODD handovers along the route. In some aspects, UE 902 can receive the attribute set from another UE (e.g., UE 910) via a transmission set 912. The transmission set 912 can be, for example, a V2X signal (such as a sidelink transmission), or it can be other radio signals (e.g., Wi-Fi, Bluetooth, or radio transmission). In some aspects, UE 902 can receive the attribute set from RSU 914 via a transmission set 916. The transmission set 916 can be, for example, a sidelink transmission, a Uu transmission, Wi-Fi, or Bluetooth transmission. RSU 914 can be configured to communicate with UEs within area 901 associated with RSU 914. In some aspects, RSU 914 can be configured to aggregate a set of attributes associated with area 901 from UEs within the area (e.g., from UE 910 via transmission set 912 and from UE 902 via transmission set 906), and can be configured to transmit the aggregated set of attributes as transmission set 916. In some aspects, one or more UEs can be configured to periodically transmit the set of attributes to RSU 914 for aggregation, for example, every 10 seconds or every 30 seconds, thereby allowing RSU 914 to aggregate the set of attributes from multiple UEs within RSU 914's area. In some aspects, RSU 914 can be configured to periodically transmit the aggregated set of attributes to UEs within area 901, for example, every 10 seconds, 30 seconds, or 60 seconds. In some aspects, UEs can be configured to transmit attributes in response to receiving periodic transmissions from RSU 914.For example, in response to receiving a periodic transmission of aggregated attributes as a transmission set 916 from RSU 914, UE 910 may periodically transmit a set of attributes associated with its route to RSU 914 for aggregation and distribution to other UEs within area 901. In some aspects, UE 902 may receive an attribute set from base station 918 via transmission set 920. Base station 918 may aggregate attributes from multiple UEs (e.g., from UE 902 via transmission set 908 and from UE 910 via transmission set 913). Transmission set 908 may be of a different type than transmission set 906. For example, transmission set 906 may include sidelink transmissions, while transmission set 908 may include Uu transmissions. Transmission set 913 may be of a different type than transmission set 912. For example, transmission set 912 may include sidelink transmissions, while transmission set 913 may include Uu transmissions. In other words, the UE can send a set of attributes associated with its route to the device via a first type, a second type, or both types for aggregation by a distributed entity (such as RSU 914 or base station 918). Base station 918 can aggregate attribute sets from multiple UEs (e.g., UEs served by base station 918) and can send the aggregated attribute set as a transmission set 920. Base station 918 can periodically send the aggregated attribute set as transmission set 920. UE 902 and / or UE 910 can periodically send a set of attributes associated with its route as transmission set 908 and / or transmission set 913, respectively. In some aspects, the UE can send attributes associated with its route in response to receiving transmission set 920 from base station 918. In some aspects, UE 902 can retrieve the attribute set from data store 922. Data store 922 can be, for example, a map aggregation server with traffic information associated with the area surrounding UE 902, or a weather monitoring server with weather information associated with the area surrounding UE 902. The data storage 922 can be accessed via a network connection (e.g., via an Internet connection, a Uu connection to base station 918, or a side link connection to RSU 914).

[0110] UE 902 can obtain attributes associated with its route via any combination of the methods described above (e.g., by obtaining attributes using sensor set 904, by receiving attributes from transmission set 912 from UE 910, by receiving attributes from transmission set 916 from RSU 914, by receiving attributes from transmission set 920 from base station 918, or by receiving attributes from data storage 922 (e.g., via Internet connection)). UE 902 can send queries for attributes associated with a specific route, or UE 902 can receive a set of attributes associated with the area surrounding UE 902 (e.g., area 901 of RSU 914, serving cell of base station 918), and can filter out attributes not associated with UE 902's route. UE 902 can calculate the predicted number of ODD handovers along its route based on a set of attributes associated with UE 902's route, thereby allowing UE 902 to take appropriate actions, such as notifying the driver of UE 902 of the ODD status (e.g., UE 902 is predicted to handover its ODD more than a threshold number of times over a distance or time period) or by deactivating the ODD mode associated with UE 902. In some aspects, UE 902 can be configured to reactivate the ODD mode associated with UE 902 in response to calculating that the predicted number of ODD handovers along a second route of UE 902 is less than or equal to a threshold. In some aspects, UE 902 can be configured to notify the driver of a second ODD status (e.g., UE 902 is predicted not to handover its ODD more than a threshold number of times over a distance or time period).

[0111] Figure 10This is a communication flowchart 1000 for wireless device 1002, which is configured to dynamically adjust the ODD status based on a set of attributes associated with the route of wireless device 1002. Wireless device 1002 may be a vehicle or a UE associated with a vehicle (e.g., connected to the vehicle via a wired or wireless connection). In some aspects, wireless device 1002 may be configured to activate or deactivate the vehicle's ODD mode (e.g., disable the vehicle's ability to enable or disable ODD). In some aspects, wireless device 1002 may be configured to notify the driver of the vehicle's ODD status, for example, by displaying the ODD status on the vehicle's screen or by announcing the ODD status to the vehicle's loudspeaker. Wireless device set 1004 may include other UEs that collect a set of attributes associated with their routes. For example, wireless device set 1004 may include a vehicle with a set of sensors that collect the vehicle's speed and GPS coordinates of the vehicle over time. A vehicle may transmit a set of attributes associated with its route via one or more transmission formats (e.g., transmission via Uu (e.g., PUSCH) or sidelink transmission (e.g., PSSCH)). Network node 1006 may include a base station, TRP, or RSU. Network node 1006 may be configured to aggregate attribute sets from multiple devices (e.g., a subset of the wireless device set 1004, a data repository) for transmission to wireless device 1002. Network node 1006 may transmit the attribute set to wireless device 1002 via one or more transmission formats (e.g., transmission via Uu (e.g., PDSCH) or sidelink transmission (e.g., PSSCH)).

[0112] Network node 1006 can send a request 1005 for an attribute set to radio device set 1004. Radio device set 1004 can receive request 1005 from network node 1006. Request 1005 can be broadcast or unicast. Network node 1006 can send request 1005 as a sidelink transmission (e.g., PSSCH transmission) to UE set. Network node 1006 can send request 1005 as a Uu transmission (e.g., PDSCH transmission) to UE set.

[0113] Request 1005 may include an indicator of a set of radio devices (e.g., a set of UE IDs) or an indicator of location (e.g., a district ID, a cell ID, or a route identifier). The set of radio devices 1004 may send an attribute set 1007 to the network node 1006. The network node 1006 may receive the attribute set 1007 from the set of radio devices 1004. In some aspects, the set of radio devices 1004 may send the attribute set 1007 based on request 1005. For example, the set of radio devices 1004 may select a subset of the collected attributes based on request 1005 (e.g., sending attributes associated with the route indicated by request 1005, sending attributes associated with the district indicated by request 1005). In some aspects, the set of radio devices 1004 may send the attribute set 1007 periodically, for example, by sending an attribute set associated with its route (e.g., sending attributes of its route within the previous 5 minutes every 5 minutes). The attribute set 1007 may include attributes collected by the wireless device set 1004, such as speed metrics (e.g., how fast a vehicle travels over a period of time or while traveling on a route), ODD switching metrics (e.g., how many times a vehicle's ODD is switched over over a period of time or while traveling on a route), driver takeover metrics (e.g., how many times a driver takes control of the vehicle when the ODD is on over a period of time or while traveling on a route), weather metrics (e.g., whether fog lights are activated, whether windshield wipers are activated, atmospheric pressure metrics, humidity metrics), road attributes (e.g., whether a lane is closed, road bump metrics, speed while traveling along a section of road), and road features (e.g., whether the road has pedestrian crossings, whether the road has traffic lights).

[0114] In other words, attribute set 1007 may include a set of vehicle movement attributes (location, speed, weather conditions, road conditions, and / or the number of ODD handovers) that the UE has collected and that are associated with the route the UE has traveled. Radio device set 1004 may send attribute set 1007 as a sidelink transmission (e.g., PSSCH transmission) to the RSU. Radio device set 1004 may also send attribute set 1007 as a Uu transmission (e.g., PUSCH transmission) to the TRP. Network node 1006 may aggregate attribute set 1007.

[0115] In some respects, wireless device 1002 can send request 1008 to network node 1006. Network node 1006 can receive request 1008 from wireless device 1002. Request 1008 can be broadcast (e.g., to all RSUs or all TRPs that can receive request 1008) or unicast (to a specific RSU or to a specific TRP). Wireless device 1002 can send request 1008 as a sidelink transmission (e.g., PSSCH transmission) to RSUs. Wireless device 1002 can send request 1008 as a Uu transmission (e.g., PUSCH transmission) to TRPs.

[0116] Request 1008 may include an indicator of the location associated with wireless device 1002 (e.g., area ID, cell ID, route identifier). Network node 1006 may send attribute set 1010 to wireless device 1002. Wireless device 1002 may receive attribute set 1010 from network node 1006. In some aspects, network node 1006 may send attribute set 1010 based on request 1008. For example, network node 1006 may select a subset of the collected attributes based on request 1008 (e.g., sending attributes associated with the route indicated by request 1008, sending attributes associated with the area indicated by request 1008). In some aspects, network node 1006 may send attribute set 1010 periodically, for example by periodically sending an aggregated attribute set from wireless device set 1004 (e.g., every 5 minutes, every 10 minutes). In some respects, network node 1006 can act as a gateway to a data repository, such as an internet gateway to a map aggregation server or a weather monitoring server. Request 1008 may include a route indicator for wireless device 1002, and attribute set 1010 may include attributes from the data repository (e.g., road conditions, traffic conditions, weather conditions).

[0117] Network node 1006 can send attribute set 1010 to the UE as a sidelink transmission (e.g., PSSCH transmission). Network node 1006 can also send attribute set 1010 to the UE as a Uu transmission (e.g., PDSCH transmission).

[0118] In some aspects, wireless device 1002 may request an attribute set directly from wireless device set 1004, for example, via a sidelink. Wireless device 1002 may send request 1012 to wireless device set 1004. Wireless device set 1004 may receive request 1012 from wireless device 1002. Request 1012 may be broadcast (e.g., to all UEs that can receive request 1012) or unicast (to a specific UE identified by a UE ID). Wireless device 1002 may send request 1012 as a sidelink transmission (e.g., PSSCH transmission) to wireless device set 1004.

[0119] Request 1012 may include an indicator of the location associated with wireless device 1002 (e.g., area ID, cell ID, route identifier). Wireless device set 1004 may send attribute set 1014 to wireless device 1002. Wireless device 1002 may receive attribute set 1014 from wireless device set 1004. In some aspects, wireless device set 1004 may send attribute set 1014 based on request 1012. For example, wireless device set 1004 may select a subset of collected attributes based on request 1012 (e.g., sending attributes associated with a route indicated by request 1012, sending attributes associated with a time period indicated by request 1012, sending attributes associated with a driving direction indicated by request 1012). In some aspects, wireless device set 1004 may send attribute set 1014 periodically, for example by periodically sending attribute set 1014 (e.g., every 5 minutes, every 10 minutes). Wireless device set 1004 can send attribute set 1014 as a sidelink transmission (e.g., PSSCH transmission) to wireless device 1002.

[0120] At 1016, wireless device 1002 can calculate the predicted number of ODD switching events along its route based on attribute set 1010, attribute set 1014, and / or attributes collected by wireless device 1002 (e.g., collected by sensors of wireless device 1002). For example, wireless device 1002 can calculate the predicted number of ODD switching events that a vehicle associated with wireless device 1002 may have during a portion of its route that is greater than or equal to a threshold. Wireless device 1002 can query ADS or ADAS to determine what conditions could trigger an ODD switching event, such as if the vehicle switches to a lane that is not the middle lane, or if the vehicle decelerates to less than 10 mph, or if a threshold amount of precipitation or rainfall is detected. ADS or ADAS can indicate to wireless device 1002 indicators of ODD thresholds that affect the ODD state of the vehicle (e.g., ODD state dependence of the physical separation of the route between the vehicle's lane and oncoming traffic lanes, minimum speed threshold, and maximum speed threshold). Wireless device 1002 can calculate the predicted number of ODD switchings based on one or more ODD thresholds received from ADS / ADAS. Vehicles can switch ODD modes based on one or more state dependencies, such as vehicle speed (e.g., maximum speed, minimum speed), vehicle lane location (e.g., center lane location, left lane location, carpool lane location), proximity to road features (e.g., more than 500m from traffic lights, physical barriers between the vehicle and oncoming traffic), weather attributes (e.g., humidity below a threshold, no fog on the route), and / or road attributes (e.g., no pedestrian crossings along the route, no stop signs along the route, no traffic lights along the route). In some aspects, wireless device 1002 can select the attribute to use at 1016 based on a delay threshold. For example, wireless device 1002 can use an attribute with a timestamp within 10 minutes or 30 minutes of the current time.

[0121] At point 1018, based on determining that the predicted number of calculated ODD switching is greater than or equal to a threshold, wireless device 1002 can notify the driver or deactivate the autonomous driving system. For example, wireless device 1002 can display a visual notification (e.g., "More than 10 ODD switching detected in the next 10 miles," "A large number of ODD switching detected in the next 2 miles") via a touchscreen display associated with the driver. In another example, wireless device 1002 can play an audio notification via a speaker associated with the driver indicating that the predicted number of calculated ODD switching is greater than or equal to the threshold. The driver can respond to the notification, for example, by turning off the vehicle's ODD mode. In some aspects, wireless device 1002 can provide prompts based on calculations; for example, wireless device 1002 can display a button on the touchscreen indicating that the vehicle's ODD feature will be deactivated for 10 miles based on the predicted number of ODD switching exceeding the threshold for the vehicle in the next 10 miles. After wireless device 1002 detects that the vehicle has left the route area, wireless device 1002 can reactivate the vehicle's ODD feature. In some respects, wireless device 1002 can automatically deactivate the ODD characteristics of a vehicle in response to determining that the predicted number of calculated ODD switching is greater than or equal to a threshold.

[0122] Wireless device 1002 may send a set of attributes 1020 associated with the ODD status of wireless device 1002 to network node 1006. Network node 1006 may receive the set of attributes 1020 associated with the ODD status of wireless device 1002. The set of attributes 1020 may include vehicle movement attributes, such as the speed and location of wireless device 1002. The set of attributes 1020 may include ODD attributes, such as the number of ODD switching or driver takeovers over a period of time or during a portion of a route. Similarly, wireless device 1002 may send a set of attributes 1022 associated with the ODD status of wireless device 1002 to a set of wireless devices 1004, thereby allowing the set of wireless devices 1004 to calculate a predicted number of ODD switching based on the set of attributes 1022.

[0123] Figure 11 This is a flowchart 1100 of a wireless communication method. This method can be performed by a UE (e.g., UE 104, UE 350, UE 602, UE 902; wireless communication device 510, wireless communication device 550; wireless device 802, wireless device 1002; device 1404). At 1102, the UE can obtain a set of attributes associated with the UE's route. For example, 1102 can be performed by... Figure 10The wireless device 1002 in the network node 1006 performs this action, receiving a set of attributes 1010 associated with the route of the wireless device 1002. In another example, 1102 may be... Figure 10 The wireless device 1002 in the set can receive a set of attributes 1014 associated with the route of the wireless device 1002 from the set of wireless devices 1004. In another example, 1102 may be performed by... Figure 10 The wireless device 1002 in the middle performs this action, which can be performed from a collection of sensors (e.g., such as Figure 9 The sensor set 904 in the wireless device 1002 receives a set of attributes 1014 associated with the route of the wireless device 1002. Furthermore, 1102 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0124] At point 1104, the UE can calculate the predicted number of ODD handovers along the route based on the attribute set. For example, 1104 can be calculated by... Figure 10 The wireless device 1002 performs this function, which can calculate the predicted number of ODD switching along the route at 1016 based on attribute set 1010, attribute set 1014, and / or attribute set obtained from the sensors of the wireless device 1002. Furthermore, 1104 can be performed by… Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0125] At point 1106, the UE can notify the driver associated with the UE of the ODD status based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. For example, 1106 can be... Figure 10 The wireless device 1002 in the system can, at 1018, notify the driver associated with the wireless device 1002 of the ODD status based on a calculated predicted number of ODD switching events being greater than or equal to a threshold (e.g., via a display, touchscreen, or speaker). Furthermore, 1106 can be performed by... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0126] At point 1108, the UE can deactivate the ODD mode associated with the UE based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. For example, 1108 can be... Figure 10The wireless device 1002 performs this action, which can deactivate the ODD pattern associated with the wireless device 1002 (i.e., deactivate the ODD characteristics of the vehicle for a period of time or during a portion of the route) at 1018 based on a calculated predicted number of ODD switchings being greater than or equal to a threshold. Furthermore, 1108 can be performed by... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0127] Figure 12 This is a flowchart 1200 of a wireless communication method. This method can be performed by a UE (e.g., UE 104, UE 350, UE 602, UE 902; wireless communication device 510, wireless communication device 550; wireless device 802, wireless device 1002; device 1404). At 1202, the UE can obtain a set of attributes associated with the UE's route. For example, 1202 can be performed by... Figure 10 The wireless device 1002 in the network node 1006 performs this action, receiving a set of attributes 1010 associated with the route of the wireless device 1002. In another example, 1202 may be performed by... Figure 10 The wireless device 1002 in the set can receive a set of attributes 1014 associated with the route of the wireless device 1002 from the set of wireless devices 1004. In another example, 1202 may be performed by... Figure 10 The wireless device 1002 in the middle performs this action, which can be performed from a collection of sensors (e.g., such as Figure 9 The sensor set 904 in the wireless device 1002 receives a set of attributes 1014 associated with the route of the wireless device 1002. Furthermore, 1202 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0128] At point 1204, the UE can calculate the predicted number of ODD handovers along the route based on the attribute set. For example, point 1204 can be calculated by... Figure 10 The wireless device 1002 performs this function, which can calculate the predicted number of ODD switching along the route at 1016 based on attribute set 1010, attribute set 1014, and / or attribute set obtained from the sensors of the wireless device 1002. Furthermore, 1204 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0129] At point 1206, the UE can notify the driver associated with the UE of the ODD status based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. For example, point 1206 can be... Figure 10The wireless device 1002 in the system can, at 1018, notify the driver associated with the wireless device 1002 of the ODD status based on a calculated predicted number of ODD switching events being greater than or equal to a threshold (e.g., via a display, touchscreen, or speaker). Furthermore, 1206 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0130] At point 1208, the UE can deactivate the ODD mode associated with the UE based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. For example, point 1208 can be... Figure 10 The wireless device 1002 in the process can deactivate the ODD pattern associated with the wireless device 1002 (i.e., deactivate the ODD characteristics of the vehicle for a period of time or during a portion of the route) at 1018 based on a calculated predicted number of ODD switchings being greater than or equal to a threshold. Furthermore, 1208 can be performed by... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0131] At point 1210, the UE can obtain a set of attributes associated with its route by receiving a navigation map from the map aggregation server. For example, 1210 can be obtained by... Figure 10 The wireless device 1002 performs this action, and this wireless device can receive the navigation map as an attribute set 1010 from the map aggregation server via network node 1006. Furthermore, 1210 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0132] At point 1212, the UE can obtain a set of attributes associated with its route by receiving a weather report map from the weather monitoring server. For example, 1212 can be obtained by... Figure 10 The wireless device 1002 in the network can receive weather report maps as attribute sets 1010 from the weather monitoring server via network node 1006. Furthermore, 1212 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0133] At point 1214, the UE can obtain a set of attributes associated with its route by receiving a set of vehicle movement attributes from a second radio device. For example, 1214 can be obtained by... Figure 10The wireless device 1002 performs this action, receiving a set of vehicle movement attributes as attribute set 1014 from at least one wireless device in the set of wireless devices 1004. Furthermore, 1014 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0134] At point 1216, the UE can obtain the attribute set by receiving a sidelink message that includes a subset of the attribute set associated with the UE's route. For example, 1216 can be obtained by... Figure 10 The wireless device 1002 performs this action, and can receive sidelink messages including attribute set 1014. Attribute set 1014 may be a subset of the attribute set collected and used by wireless device 1002 at 1016. Furthermore, 1216 may be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0135] At point 1218, the UE can obtain the attribute set by acquiring a subset of the attribute set associated with the UE's route from the sensor set associated with the ODD state dependency. For example, 1218 can be obtained by... Figure 10 The wireless device 1002 in the middle performs this action, which can obtain data from a set of sensors associated with the ODD state dependency (e.g., similar to...). Figure 9 904 / ) in the middle obtains a subset of the attribute set. Furthermore, 1218 can be obtained from... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0136] At position 1220, the UE can send a subset of the attribute set. For example, position 1220 can be sent by... Figure 10 The wireless device 1002 performs this action, and can send attribute set 1020 to network node 1006. Attribute set 1020 can be a subset of the attribute set collected by wireless device 1002. In another example, wireless device 1002 can send attribute set 1022 to wireless device set 1004. Attribute set 1022 can also be a subset of the attribute set collected by wireless device 1002. Furthermore, 1220 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0137] Figure 13This is a flowchart 1300 of a wireless communication method. This method can be performed by a UE (e.g., UE 104, UE 350, UE 602, UE 902; wireless communication device 510, wireless communication device 550; wireless device 802, wireless device 1002; device 1404). At 1302, the UE can obtain a set of attributes associated with the UE's route. For example, 1302 can be performed by... Figure 10 The wireless device 1002 in the network node 1006 performs this action, receiving a set of attributes 1010 associated with the route of the wireless device 1002. In another example, 1302 may be... Figure 10 The wireless device 1002 in the set can receive a set of attributes 1014 associated with the route of the wireless device 1002 from the set of wireless devices 1004. In another example, 1302 may be performed by... Figure 10 The wireless device 1002 in the middle performs this action, which can be performed from a collection of sensors (e.g., such as Figure 9 The sensor set 904 in the wireless device 1002 receives a set of attributes 1014 associated with the route of the wireless device 1002. Furthermore, 1302 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0138] At point 1304, the UE can calculate the predicted number of ODD handovers along the route based on the attribute set. For example, point 1304 can be calculated by... Figure 10 The wireless device 1002 performs this function, which can calculate the predicted number of ODD switching along the route at 1016 based on attribute set 1010, attribute set 1014, and / or attribute set obtained from the sensors of the wireless device 1002. Furthermore, 1304 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0139] At point 1306, the UE can notify the driver associated with the UE of the ODD status based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. For example, point 1306 can be... Figure 10 The wireless device 1002 in the middle performs the function of informing the driver associated with the wireless device 1002 of the ODD status at 1018 based on the calculated predicted number of ODD switching being greater than or equal to a threshold (e.g., via a display, touchscreen, speaker). Furthermore, 1306 can be performed by... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0140] At point 1308, the UE can deactivate the ODD mode associated with the UE based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. For example, point 1308 can be... Figure 10 The wireless device 1002 in the process executes a function that can, at 1018, deactivate the ODD pattern associated with the wireless device 1002 (i.e., deactivate the ODD characteristics of the vehicle for a period of time or during a portion of the route) based on a calculated predicted number of ODD switching events being greater than or equal to a threshold. Furthermore, 1308 can be performed by... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0141] At point 1310, the UE can receive a command from the driver to disable the UE's ODD mode after being notified of the ODD status. For example, point 1310 can be... Figure 10 The wireless device 1002 in the vehicle executes a command to deactivate the ODD mode of the wireless device 1002 after the ODD status is notified at 1018 (e.g., via a touchscreen, via a microphone command, or via a button on the vehicle's dashboard). Furthermore, 1310 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0142] At point 1314, the UE can disable its ODD mode. For example, 1314 can be configured by... Figure 10 The wireless device 1002 in the middle can be executed, and the wireless device can disable the ODD mode of the wireless device 1002 in response to a command received from the driver. Furthermore, 1314 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0143] At point 1316, the UE can query at least one of the AD systems or ADAS associated with the ODD state dependency. For example, point 1316 can be... Figure 10 The wireless device 1002 performs this action, and the wireless device can query at least one of the ADS or ADAS associated with the ODD state dependency of the vehicle associated with the wireless device 1002. Furthermore, 1316 can be performed by... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0144] At point 1318, the UE can receive an indicator of the ODD threshold from at least one of the AD system or ADAS system. For example, point 1318 can be... Figure 10The wireless device 1002 in the system performs this function, and the wireless device can receive an indicator of an ODD threshold (e.g., minimum speed, maximum speed) from at least one of the ADS or ADAS systems. Furthermore, 1318 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0145] At point 1320, the UE can calculate the predicted number of ODD handovers based on the attribute set by further calculating the predicted number of ODD handovers along the route based on the ODD threshold. For example, 1320 can be calculated by... Figure 10 The wireless device 1002 performs this action, and at 1018, the wireless device can further calculate the predicted number of ODD handovers based on the ODD threshold. Furthermore, 1320 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0146] At point 1322, the UE can select a subset of the attribute set based on a latency threshold. For example, 1322 can be determined by... Figure 10 The wireless device 1002 performs this action, and can select a subset of the set of attributes collected by the wireless device 1002 (e.g., attributes associated with timestamps within the last 30 minutes) based on a latency threshold. Furthermore, 1322 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0147] At point 1324, the UE can calculate the predicted number of ODD handovers along the route by further calculating the predicted number of ODD handovers based on a subset of the attribute set. For example, 1324 can be calculated by... Figure 10 The wireless device 1002 performs this action, and at 1018, this wireless device can further calculate the predicted number of ODD switchings based on a subset of the attribute threshold set (e.g., attributes associated with timestamps within the last 30 minutes). Furthermore, 1324 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0148] At point 1326, the UE can notify the driver associated with the UE of the ODD status by displaying a visual notification via a touchscreen display associated with the driver, based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. For example, 1326 can be... Figure 10 The wireless device 1002 performs this function, and the wireless device can display visual notifications at 1018 via a touchscreen display associated with the driver. Additionally, 1326 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0149] At point 1328, the UE can notify the driver associated with the UE of the ODD status by playing an audio notification via a speaker associated with the driver, based on the calculated predicted number of ODD handovers being greater than or equal to a threshold. For example, 1328 can be... Figure 10 The wireless device 1002 performs this function, and the wireless device can play audio notifications at 1018 via a speaker associated with the driver. Additionally, 1328 can be... Figure 1 , Figure 3 and Figure 14 Component 198 is executed.

[0150] Figure 14Figure 1400 illustrates an example of a hardware implementation for device 1404. Device 1404 may be a UE, a component of a UE, or implement UE functionality. In some aspects, device 1404 may include at least one cellular baseband processor 1424 (also referred to as a modem) coupled to one or more transceivers 1422 (e.g., cellular RF transceivers). Cellular baseband processor 1424 may include at least one on-chip memory 1424'. In some aspects, device 1404 may also include one or more Subscriber Identity Module (SIM) cards 1420 and at least one application processor 1406 coupled to a Secure Digital Card (SD) card 1408 and a screen 1410. Application processor 1406 may include on-chip memory 1406'. In some aspects, device 1404 may also include a Bluetooth module 1412, a WLAN module 1414, an SPS module 1416 (e.g., a GNSS module), one or more sensor modules 1418 (e.g., a barometric pressure sensor / altimeter; motion sensors such as an inertial measurement unit (IMU), a gyroscope, and / or an accelerometer; light detection and ranging (LIDAR), radio-assisted detection and ranging (RADAR), sound navigation and ranging (SONAR), a magnetometer, audio, and / or other technologies for positioning), an additional memory module 1426, a power supply 1430, and / or a camera 1432. Bluetooth module 1412, WLAN module 1414, and SPS module 1416 may include on-chip transceivers (TRX) (or in some cases, only receivers (RX)). Bluetooth module 1412, WLAN module 1414, and SPS module 1416 may include their own dedicated antennas and / or communicate using antenna 1480. Cellular baseband processor 1424 communicates with UE 104 and / or RU associated with network entity 1402 via transceiver 1422 through one or more antennas 1480. Cellular baseband processor 1424 and application processor 1406 may each include computer-readable media / memory 1424', 1406'. Additional memory module 1426 may also be considered computer-readable media / memory. Each computer-readable media / memory 1424', 1406', 1426 may be non-transitory. Cellular baseband processor 1424 and application processor 1406 are each responsible for general processing, including the execution of software stored on the computer-readable media / memory. When executed by cellular baseband processor 1424 / application processor 1406, the software causes cellular baseband processor 1424 / application processor 1406 to perform the various functions described above. Cellular baseband processor 1424 and application processor 1406 are configured to perform the various functions described above based at least in part on information stored in memory.In other words, the cellular baseband processor 1424 and application processor 1406 can be configured to perform a first subset of the various functions described above without information stored in memory, and can be configured to perform a second subset of the various functions described above based on information stored in memory. The computer-readable medium / memory can also be used to store data manipulated by the cellular baseband processor 1424 / application processor 1406 during software execution. The cellular baseband processor 1424 / application processor 1406 can be a component of the UE 350 and can include at least one memory 360 and / or at least one of the following: a TX processor 368, an RX processor 356, and a controller / processor 359. In one configuration, the device 1404 can be at least one processor chip (modem and / or application) and includes only the cellular baseband processor 1424 and / or application processor 1406, while in another configuration, the device 1404 can be the entire UE (e.g., see [link]). Figure 3 The UE350 includes an additional module of device 1404.

[0151] As discussed above, component 198 may be configured to receive a set of attributes associated with the UE's route. Component 198 may be within cellular baseband processor 1424, application processor 1406, or both cellular baseband processor 1424 and application processor 1406. Component 198 may be one or more hardware components specifically configured to perform the stated process / algorithm, implemented by one or more processors configured to execute the stated process / algorithm, stored in a computer-readable medium for implementation by one or more processors, or some combination thereof. When multiple processors are implemented, the multiple processors may execute the stated process / algorithm individually or in combination. As shown, device 1404 may include a variety of components configured for various functions. In one configuration, device 1404 (and particularly cellular baseband processor 1424 and / or application processor 1406) may include components for obtaining a set of attributes associated with the route of device 1404. Device 1404 may include components for calculating a predicted number of ODD handovers along the route based on the attribute set. Apparatus 1404 may include components for calculating a predicted number of ODD switchings along a route based on a set of attributes. Apparatus 1404 may include components for notifying a driver associated with apparatus 1404 of an ODD status (e.g., informing the driver that apparatus 1404 can switch ODDs at least a threshold number of times within a threshold distance) based on a predicted number of calculated ODD switchings being greater than or equal to a threshold. Apparatus 1404 may include components for deactivating an ODD mode associated with apparatus 1404 based on a predicted number of calculated ODD switchings being greater than or equal to a threshold. Apparatus 1404 may include components for obtaining a set of attributes by receiving a navigation map from a map aggregation server. Apparatus 1404 may include components for obtaining a set of attributes by receiving a weather report map from a weather monitoring server. Apparatus 1404 may include components for obtaining a set of attributes by receiving a set of vehicle movement attributes from a second radio device. The second radio device may include at least one of a second UE or RSU. Apparatus 1404 may include components for obtaining a set of attributes by receiving a sidelink message including the set of attributes. The set of attributes may include at least one of the following: (a) a speed metric associated with a portion of the route, (b) an ODD switching metric associated with a portion of the route, (c) a driver takeover metric associated with a portion of the route, (d) a weather metric associated with a portion of the route, and / or (e) a road attribute associated with a portion of the route; or a road feature associated with a portion of the route.Device 1404 may include components for calculating a predicted number of ODD switching events by: querying at least one of an AD system or ADAS associated with ODD state dependency; receiving an indicator of an ODD threshold from at least one of the AD system or ADAS; and further calculating a predicted number of ODD switching events based on the ODD threshold. ODD state dependency may include at least one of the following: (a) vehicle speed, (b) vehicle lane positioning, (c) proximity to road features, (d) weather attributes, and / or (e) road attributes. Device 1404 may include components for obtaining a subset of an attribute set from a set of sensors associated with ODD state dependency. Device 1404 may include components for transmitting a second set of attributes. Device 1404 may include components for calculating a predicted number of ODD switching events by selecting a subset of the attribute set based on a time delay threshold and by further calculating a predicted number of ODD switching events based on the subset of the attribute set. Device 1404 may include components for informing a driver of the ODD status by displaying a visual notification via a touchscreen display associated with the driver. Device 1404 may include components for notifying a driver of an ODD status by playing an audio notification via a speaker associated with the driver. Device 1404 may include components for receiving a command from the driver to deactivate the ODD mode of device 1404 after notifying the ODD status. Device 1404 may include components for deactivating the ODD mode of device 1404 after receiving the command. Device 1404 may include a vehicle. Device 1404 may include a wireless device communicatively coupled to the vehicle. Components may be components 198 of device 1404 configured to perform functions described therein. As described above, device 1404 may include a TX processor 368, an RX processor 356, and a controller / processor 359. Therefore, in one configuration, components may be the TX processor 368, the RX processor 356, and / or the controller / processor 359 configured to perform functions described therein.

[0152] Figure 15Figure 1500 illustrates an example of a hardware implementation for network entity 1502. Network entity 1502 may be a BS, a component of a BS, or implement BS functionality. Network entity 1502 may include at least one of CU 1510, DU 1530, or RU 1540. For example, depending on the layer functionality handled by component 199, network entity 1502 may include CU 1510; both CU 1510 and DU 1530; each of CU 1510, DU 1530, and RU 1540; DU 1530; both DU 1530 and RU 1540; or RU 1540. CU 1510 may include at least one CU processor 1512. CU processor 1512 may include on-chip memory 1512'. In some aspects, CU 1510 may also include an additional memory module 1514 and a communication interface 1518. CU1510 communicates with DU 1530 via a midhaul link, such as an F1 interface. DU 1530 may include at least one DU processor 1532. DU processor 1532 may include on-chip memory 1532'. In some aspects, DU 1530 may also include an additional memory module 1534 and a communication interface 1538. DU 1530 communicates with RU 1540 via a fronthaul link. RU 1540 may include at least one RU processor 1542. RU processor 1542 may include on-chip memory 1542'. In some aspects, RU 1540 may also include an additional memory module 1544, one or more transceivers 1546, an antenna 1580, and a communication interface 1548. RU 1540 communicates with UE 104. On-chip memories 1512', 1532', 1542' and additional memory modules 1514, 1534, 1544 may each be considered as computer-readable media / memory. Each computer-readable medium / memory can be non-transitory. Each of processors 1512, 1532, and 1542 is responsible for general processing, including executing software stored on the computer-readable medium / memory. When executed by the corresponding processor, the software causes that processor to perform the various functions described above. The computer-readable medium / memory can also be used to store data manipulated by the processor while executing the software.

[0153] As discussed above, component 199 may be configured to receive a set of attributes associated with the UE's route. Component 199 may be configured to transmit the set of attributes associated with the UE's route. In other words, component 199 may be configured to aggregate attributes from one or more UEs to transmit to the UE for calculating the ODD status associated with the UE's vehicle. Component 199 may be located within one or more processors of one or more of CU 1510, DU 1530, and RU 1540. Component 199 may be one or more hardware components specifically configured to perform the stated process / algorithm, implemented by one or more processors configured to execute the stated process / algorithm, stored in a computer-readable medium for implementation by one or more processors, or some combination thereof. When multiple processors are implemented, the multiple processors may execute the stated process / algorithm individually or in combination. Network entity 1502 may include a variety of components configured for various functions. In one configuration, network entity 1502 may include a component for receiving a set of attributes associated with the UE's route. Network entity 1502 may include components for transmitting a set of attributes associated with the UE's route. A component may be a component 199 of network entity 1502 configured to perform the functions described therein. As described above, network entity 1502 may include a TX processor 316, an RX processor 370, and a controller / processor 375. Therefore, in one configuration, a component may be the TX processor 316, the RX processor 370, and / or the controller / processor 375 configured to perform the functions described therein.

[0154] Figure 16 Figure 1600 illustrates an example of a hardware implementation for network entity 1660. In one example, network entity 1660 may be within core network 120. Network entity 1660 may include at least one network processor 1612. Network processor 1612 may include on-chip memory 1612'. In some aspects, network entity 1660 may also include an additional memory module 1614. Network entity 1660 communicates with CU 1602 directly (e.g., via a backhaul link) or indirectly (e.g., via RIC) through network interface 1680. On-chip memory 1612' and additional memory module 1614 may each be considered as computer-readable media / memory. Each computer-readable media / memory may be non-transitory. Network processor 1612 is responsible for general processing, including executing software stored on the computer-readable media / memory. This software, when executed by a corresponding processor, causes that processor to perform the various functions described above. The computer-readable media / memory may also be used to store data manipulated by the processor while executing the software.

[0155] As discussed above, component 199 may be configured to receive a set of attributes associated with the UE's route. Component 199 may be configured to transmit the set of attributes associated with the UE's route. In other words, component 199 may be configured to aggregate attributes from one or more UEs and transmit them to the UE for calculating the ODD status associated with the UE's vehicle. Component 199 may be within network processor 1612. Component 199 may be one or more hardware components specifically configured to perform the stated process / algorithm, implemented by one or more processors configured to execute the stated process / algorithm, stored in a computer-readable medium for implementation by one or more processors, or some combination thereof. When multiple processors are implemented, the multiple processors may execute the stated process / algorithm individually or in combination. Network entity 1660 may include various components configured for various functions. In one configuration, network entity 1660 may include components for receiving a set of attributes associated with the UE's route. Network entity 1660 may include components for transmitting the set of attributes associated with the UE's route. The component can be a component 199 of network entity 1660 configured to perform the functions described by the component.

[0156] It should be understood that the specific order or hierarchy of the boxes in the disclosed process / flowcharts is merely an example of the exemplary method. It should be understood that the specific order or hierarchy of the boxes in the process / flowcharts may be rearranged based on design preferences. Furthermore, some boxes may be combined or omitted. The appended method claims present the elements of various boxes in a sample order, but are not limited to the given specific order or hierarchy.

[0157] The foregoing description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not limited to the aspects described herein but should be given the full scope consistent with the language of the claims. Unless specifically stated otherwise, references to elements in the singular form do not mean “one and only one” but rather “one or more.” Terms such as “if,” “when,” and “simultaneously” do not imply a direct temporal relationship or reaction. That is, these phrases, such as “when…”, do not imply an immediate action in response to the occurrence of an action or during the occurrence of an action, but simply suggest that if a condition is met, then the action will occur, without requiring a specific or immediate time limit for the occurrence of the action. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or superior to other aspects. Unless otherwise specifically stated, the term “some” refers to one or more. Combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" include any combination of A, B, and / or C, and may include multiple A, multiple B, or multiple C. Specifically, combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" can be only A, only B, only C, A and B, A and C, B and C, or A and B and C, where any such combination may contain one or more members of A, B, or C. A set should be interpreted as a group of elements, where the elements are numbered one or more. Therefore, for a set of X, X will include one or more elements. When at least one processor is configured to execute a set of functions, that at least one processor is configured to execute that set of functions individually or in any combination. Therefore, each of the at least one processor can be configured to perform a specific subset of the set of functions, wherein the subset is the complete set, a suitable subset of the set, or an empty subset of the set. If the first device receives data from or sends data to the second device, data can be received / sent directly between the first and second devices, or indirectly between the first and second devices via a set of devices. A device configured to "output" data (such as transmission, signaling, or messages) can, for example, transmit data using a transceiver, transmit data to the device that transmits the data, or transmit data to a component of the device.A device configured to "acquire" data (such as transmission, signaling, or messaging) may, for example, receive data using a transceiver, obtain data from a receiving device, or obtain data from a component of the device. Information stored in memory includes instructions and / or data. All structural and functional equivalents of the elements throughout the various aspects described herein that are known to those skilled in the art or will later be known are expressly incorporated herein by reference and are covered by the claims. Furthermore, nothing disclosed herein is intended to be offered to the public, whether or not such disclosure is explicitly recited in the claims. Words such as "module," "mechanism," "element," and "device" may not replace the word "part." Therefore, no claim element will be construed as a functional part unless the element is explicitly recited using the phrase "part for..."

[0158] As used in this article, the phrase “based on” should not be interpreted as referring to a closed set of information, one or more conditions, one or more factors, etc. In other words, the phrase “based on A” (where “A” can be information, conditions, factors, etc.) should be interpreted as “based on at least A”, unless specifically stated differently.

[0159] The following aspects are merely illustrative and may be combined with other aspects or teachings described herein without limitation.

[0160] Aspect 1 is a method for wireless communication at a user equipment (UE), the method comprising: obtaining a set of attributes associated with a route of the UE; calculating a predicted number of Operational Design Domain (ODD) handovers along the route based on the set of attributes; and notifying a driver associated with the UE of an ODD status or disabling an ODD mode associated with the UE based on the calculated predicted number of ODD handovers being greater than or equal to a threshold.

[0161] Aspect 2 is the method according to aspect 1, wherein obtaining the attribute set includes at least one of the following: receiving a navigation map from a map aggregation server; receiving a weather report map from a weather monitoring server; or receiving a set of vehicle movement attributes from a second wireless device.

[0162] Aspect 3 is the method according to aspect 2, wherein the second wireless device includes at least one of a second UE or a roadside unit (RSU).

[0163] Aspect 4 is the method according to any one of aspects 1 to 3, wherein obtaining the attribute set includes receiving a sidelink message that includes a subset of the attribute set.

[0164] Aspect 5 is a method according to any one of Aspects 1 to 4, wherein the set of attributes includes at least one of the following: a speed metric associated with a portion of the route; an ODD switching metric associated with the portion of the route; a driver takeover metric associated with the portion of the route; a weather metric associated with the portion of the route; a road attribute associated with the portion of the route; or a road feature associated with the portion of the route.

[0165] Aspect 6 is a method according to any one of Aspects 1 to 5, wherein calculating the predicted number of ODD switching comprises: querying at least one of an autonomous driving (AD) system or an advanced driver assistance system (ADAS) associated with ODD state dependency; receiving an indicator of an ODD threshold from at least one of the AD system or the ADAS system; and further calculating the predicted number of ODD switching based on the ODD threshold.

[0166] Aspect 7 is the method according to aspect 6, wherein the ODD state dependency includes at least one of the following: vehicle speed; vehicle lane location; proximity to road features; weather attributes; or road attributes.

[0167] Aspect 8 is the method according to any one of Aspects 6 or 7, wherein obtaining the set of attributes includes receiving a subset of the set of attributes from a set of sensors associated with the ODD state dependency. The method may further include transmitting the subset of the set of attributes.

[0168] Aspect 9 is the method according to any one of Aspects 1 to 8, wherein calculating the predicted number of ODD switching comprises: selecting a subset of the attribute set based on a delay threshold; and further calculating the predicted number of ODD switching based on the subset of the attribute set.

[0169] Aspect 10 is the method according to any one of aspects 1 to 9, wherein notifying the driver of the ODD status includes at least one of the following: displaying a visual notification via a touchscreen display associated with the driver; or playing an audio notification via a speaker associated with the driver.

[0170] Aspect 11 is a method according to any one of aspects 1 to 10, the method further comprising: receiving from the driver a command to disable the ODD mode of the UE after notifying the ODD status; and disabling the ODD mode of the UE after receiving the command.

[0171] Aspect 12 is a method according to any one of aspects 1 to 11, wherein the UE includes at least one of a vehicle or a wireless device communicatively coupled to the vehicle.

[0172] Aspect 13 is the method according to aspect 8, the method further comprising sending a second set of attributes.

[0173] Aspect 14 is a method according to any one of aspects 1 to 13, wherein notifying the driver associated with the UE of the ODD status includes: outputting an indication of the ODD status to the driver associated with the UE.

[0174] Aspect 15 is the method according to aspect 14, wherein the instruction on the ODD condition output to the driver associated with the UE comprises: sending the instruction on the ODD condition to the driver associated with the UE.

[0175] Aspect 16 is an apparatus for wireless communication, the apparatus comprising: at least one memory; and at least one processor coupled to the at least one memory and based at least in part on information stored in the at least one memory, the at least one processor being configured individually or in any combination to perform the method according to any one of aspects 1 to 15.

[0176] Aspect 17 is an apparatus for wireless communication, the apparatus comprising components for performing each step of the method according to any one of aspects 1 to 15.

[0177] Aspect 18 is an apparatus according to any one of aspects 1 to 15, the apparatus further comprising a transceiver (e.g., a transceiver coupled to at least one processor in aspect 16), the transceiver being configured to receive or transmit in association with the method according to any one of aspects 1 to 15.

[0178] Aspect 19 is a computer-readable medium (e.g., a non-transitory computer-readable medium) storing computer-executable code that, when executed by at least one processor, causes the at least one processor to perform the method according to any one of aspects 1 to 15.

Claims

1. An apparatus for wireless communication at a user equipment (UE), the apparatus comprising: At least one memory; as well as At least one processor, coupled to the at least one memory, and configured individually or in any combination, based at least in part on information stored in the at least one memory, to: Obtain the set of attributes associated with the route of the UE; The predicted number of Operational Design Domain (ODD) switches along the route is calculated based on the set of attributes. as well as Based on the calculated predicted number of ODD switching being greater than or equal to a threshold, the driver associated with the UE is notified of the ODD status or the ODD mode associated with the UE is deactivated.

2. The apparatus of claim 1, wherein, in order to obtain the set of attributes, the at least one processor is configured individually or in any combination to: Receive navigation maps from the map aggregation server; Receive weather report maps from the weather monitoring server; or Receive a set of vehicle movement attributes from a second wireless device.

3. The apparatus of claim 2, wherein the second wireless device comprises at least one of a second UE or a roadside unit (RSU).

4. The apparatus of claim 1, wherein, in order to obtain the set of attributes, the at least one processor is configured individually or in any combination to: Receive sidelink messages that include a subset of the attribute set.

5. The apparatus of claim 1, wherein the set of attributes includes at least one of the following: A speed metric associated with a portion of the route; ODD switching metrics associated with the aforementioned portion of the route; Driver takeover metrics associated with the aforementioned portion of the route; Weather measurements associated with the aforementioned portion of the route; Road attributes associated with the portion of the route; or Road features associated with the portion of the route.

6. The apparatus of claim 1, wherein, in order to calculate the predicted number of ODD switching, the at least one processor is configured individually or in any combination to: Queries at least one of the autonomous driving (AD) systems or advanced driver assistance systems (ADAS) associated with ODD state dependency; Receive an indicator of the ODD threshold from at least one of the AD system or the ADAS system; and The predicted number of ODD switchings is further calculated based on the ODD threshold.

7. The apparatus of claim 6, wherein the ODD state dependency includes at least one of the following: Vehicle speed; Vehicle lane positioning; Proximity to road features; Weather attributes; or Road attributes.

8. The apparatus of claim 6, wherein, in order to obtain the set of attributes, the at least one processor is configured individually or in any combination to: A subset of the attribute set is obtained from the set of sensors associated with the ODD state dependency.

9. The apparatus of claim 8, wherein the at least one processor is further configured, alone or in any combination, to: Send the subset of the attribute set.

10. The apparatus of claim 1, wherein, in order to calculate the predicted number of ODD switching, the at least one processor is configured individually or in any combination to: A subset of the attribute set is selected based on a latency threshold; and The predicted number of ODD switchings is further calculated based on the subset of the attribute set.

11. The apparatus of claim 1, wherein, in order to notify the driver of the ODD status, the at least one processor is configured individually or in any combination to: Visual notifications are displayed via a touchscreen display associated with the driver; or An audio notification is played via a speaker associated with the driver.

12. The apparatus of claim 1, wherein the at least one processor is further configured, alone or in any combination, to: After notifying the ODD status, a command is received from the driver to disable the ODD mode of the UE; and The ODD mode of the UE is deactivated after the command is received.

13. The apparatus of claim 1, wherein the UE comprises at least one of a vehicle or a wireless device communicatively coupled to the vehicle.

14. The apparatus of claim 1, further comprising a transceiver coupled to the at least one processor, wherein, in order to receive the set of attributes associated with the route of the UE, the at least one processor is configured individually or in any combination to: The transceiver receives the set of attributes associated with the route of the UE.

15. The apparatus of claim 1, wherein, in order to notify the driver associated with the UE of the ODD status, the at least one processor is configured individually or in any combination to: The driver outputs an indication of the ODD status to the UE associated with it.

16. The apparatus of claim 15, wherein, in order to output the indication of the ODD status to the driver associated with the UE, the at least one processor is configured individually or in any combination to: The instruction regarding the ODD status is sent to the driver associated with the UE.

17. A method for conducting wireless communication at a user equipment (UE), the method comprising: Obtain the set of attributes associated with the route of the UE; The predicted number of Operational Design Domain (ODD) switches along the route is calculated based on the set of attributes. as well as Based on the calculated predicted number of ODD switching being greater than or equal to a threshold, perform at least one of the following: notify the driver associated with the UE of the ODD status, or disable the ODD mode associated with the UE.

18. The method of claim 17, wherein obtaining the set of attributes comprises at least one of the following: Receive navigation maps from the map aggregation server; Receive weather report maps from the weather monitoring server; or Receive a set of vehicle movement attributes from a second wireless device.

19. The method of claim 18, wherein the second wireless device comprises at least one of a second UE or a roadside unit (RSU).

20. The method of claim 17, wherein obtaining the attribute set comprises: Receive sidelink messages that include the set of attributes.

21. The method of claim 17, wherein the set of attributes includes at least one of the following: A speed metric associated with a portion of the route; ODD switching metrics associated with the aforementioned portion of the route; Driver takeover metrics associated with the aforementioned portion of the route; Weather measurements associated with the aforementioned portion of the route; Road attributes associated with the portion of the route; or Road features associated with the portion of the route.

22. The method of claim 17, wherein calculating the predicted number of ODD switching comprises: Queries at least one of the autonomous driving (AD) systems or advanced driver assistance systems (ADAS) associated with ODD state dependency; Receive an indicator of the ODD threshold from at least one of the AD system or the ADAS system; as well as The predicted number of ODD switchings is further calculated based on the ODD threshold.

23. The method of claim 22, wherein the ODD state dependency includes at least one of the following: Vehicle speed; Vehicle lane positioning; Proximity to road features; Weather attributes; or Road attributes.

24. The method of claim 22, wherein obtaining the attribute set comprises: A subset of the attribute set is received from the set of sensors associated with the ODD state dependency.

25. The method according to claim 24, further comprising: Send the subset of the attribute set.

26. The method of claim 17, wherein calculating the predicted number of ODD switching comprises: A subset of the attribute set is selected based on a time delay threshold; as well as The predicted number of ODD switchings is further calculated based on the subset of the attribute set.

27. The method of claim 17, wherein notifying the driver of the ODD status comprises at least one of the following: Visual notifications are displayed via a touchscreen display associated with the driver; or An audio notification is played via a speaker associated with the driver.

28. The method according to claim 17, further comprising: After notifying the ODD status, a command to disable the ODD mode of the UE is received from the driver; as well as The ODD mode of the UE is deactivated after the command is received.

29. An apparatus for wireless communication at a user equipment (UE), the apparatus comprising: transceiver; A component for obtaining a set of attributes associated with the route of the UE via the transceiver; Components for calculating the predicted number of Operational Design Domain (ODD) switches along the route based on the set of attributes; as well as A component for performing at least one of the following based on a calculated predicted number of ODD switchings being greater than or equal to a threshold: notifying the driver associated with the UE of the ODD status, or disabling the ODD mode associated with the UE.

30. A computer-readable medium storing computer-executable code at a user equipment (UE), said code causing said at least one processor, when executed, to: Obtain the set of attributes associated with the route of the UE; The predicted number of Operational Design Domain (ODD) switches along the route is calculated based on the attribute set; and Based on the calculated predicted number of ODD switching being greater than or equal to a threshold, the driver associated with the UE is notified of the ODD status or the ODD mode associated with the UE is deactivated.

Images