Flow-latency geographic information fetching for autonomous vehicles

Abstract

An apparatus and method enable efficient delivery of geographic information to autonomous vehicles. A network node receives high-definition (HD) map packets associated with predicted vehicle locations and determines storage durations based on traffic statistics or vehicle route information. The node maintains these packets in a shared memory accessible to multiple vehicles. Upon receiving a request from an autonomous vehicle, which includes a road segment identifier, the node transmits the appropriate HD map packet. The system supports persistent connections for ongoing data exchange during a vehicle's trip. This approach enables proactive caching of geographic data, reducing transmission latency and optimizing network resource utilization. Implementations are applicable to various types of geographic information beyond HD maps, supporting diverse autonomous vehicle operations.

Description

FLOW-LATENCY GEOGRAPHIC INFORMATION FETCHING FOR AUTONOMOUS VEHICLESTECHNICAL FIELD

[0001] This disclosure relates generally to driver-operated or driver-assisted vehicles, and more specifically, to low-latency geographic information fetching for autonomous vehicles to deliver high-definition map data and other location-specific information to autonomous vehicles with minimal delay.BACKGROUND

[0002] Autonomous vehicles rely heavily on accurate and up-to-date geographic information for safe and efficient operation. As autonomous driving technology advances, the demand for real-time access to detailed geographic data has increased significantly.

[0003] Traditional methods of transmitting this information often involve multiple network hops, resulting in latencies that can exceed 100 milliseconds, which is suboptimal for critical driving decisions. Also, existing systems typically require autonomous vehicles to establish new connections and request map data on-demand, which leads to delays in data retrieval. Delays can be particularly problematic in scenarios such as driving on unfamiliar roads, navigating areas with frequent traffic incidents, or when immediate arbitration is needed to resolve conflicts in vehicle-to-everything (V2X) communications or the like.

[0004] Current network infrastructures are not optimized for low-latency requirements of autonomous vehicles, which need round-trip latencies of 30 to 50 milliseconds for reliable and timely access to geographic information. Even existing edge caching technologies have struggled to consistently meet latency requirements without significant infrastructure investment. This results in unnecessary data transmissions and suboptimal use of network resources, particularly in the context of the limited bandwidth.

[0005] Therefore, as the adoption of autonomous vehicles continues to grow, there is an increasing need for more efficient and responsive systems for delivering critical geographic information. This necessitates novel approaches to network design, data transmission protocols, and caching strategies tailored to requirements of autonomous vehicle communications.SUMMARY

[0006] The following summarizes some aspects of the present disclosure to provide a basic understanding of the discussed technology. This summary is not an extensive overview of all contemplated features of the disclosure and is intended neither to identify key or critical elements of all aspects of the disclosure nor to delineate the scope of any or all aspects of the disclosure. Its sole purpose is to present some concepts of one or more aspects of the disclosure in summary form as a prelude to the more detailed description that is presented later.

[0007] One innovative aspect of the subject matter described in this disclosure can be implemented in an apparatus for wireless communication at a network node. The apparatus includes a processing system configured to receive HD map packets associated with a predicted location of an autonomous vehicle, determine a storage duration for the packets based on traffic statistics or vehicle route information, receive a request from the autonomous vehicle including a road segment identifier, and transmit a stored HD map packet to the autonomous vehicle associated with the road segment identifier.

[0008] In some implementations, a method for wireless communication at a network node includes receiving HD map packets associated with a predicted location of an autonomous vehicle, determining a storage duration for the packets based on traffic statistics or vehicle route information, receiving a request from the autonomous vehicle including a road segment identifier, and transmitting a stored HD map packet to the autonomous vehicle associated with the road segment identifier.

[0009] In some examples, the apparatus or method involves delaying transmission of HD map packets based on the determined storage duration, predicting a likelihood of use for the HD map packets, and selecting a storage duration accordingly. The memory storing the HD map packets may be shared across multiple autonomous vehicles. HD map packets may be removed based on updated vehicle location information, or ordered according to road segment or lane identifiers. Some implementations involve identifying a caching field in the packet headers and reserving packets from immediate transmission based on this field. A persistent connection may be maintained with the autonomous vehicle for ongoing data exchange.

[0010] One innovative aspect of the subject matter described in this disclosure can be implemented in an apparatus for wireless communication at an autonomous vehicle. The apparatus includes a processing system configured to receive an indication of available geographic data in a network node’s memory, identify an upcoming zone along a  predicted path, transmit a request for geographic data associated with the upcoming zone including a road segment identifier, and receive the requested geographic data from the network node.

[0011] In some implementations, a method for wireless communication at an autonomous vehicle includes receiving an indication of available geographic data in a network node’s memory, identifying an upcoming zone along a predicted path, transmitting a request for geographic data associated with the upcoming zone including a road segment identifier, and receiving the requested geographic data from the network node.

[0012] In some examples, the geographic data comprises geographic information tiles. Location information may be transmitted to select which tiles to maintain in memory. The request may be transmitted via PUCCH or PUSCH and may include additional identifiers such as application, zone, or vehicle identifiers. Notifications about unavailable data may be received, and a need for higher object detection accuracy may be determined before requesting geographic information.

[0013] One innovative aspect of the subject matter described in this disclosure can be implemented in an apparatus for wireless communication at an autonomous vehicle. The apparatus includes a processing system configured to establish a connection to a network node for exchanging HD map packets, receive packets via this connection, and maintain the connection for at least a portion of a trip.

[0014] In some implementations, a method for wireless communication at an autonomous vehicle includes establishing a connection to a network node for exchanging HD map packets, receiving packets via this connection, and maintaining the connection for at least a portion of a trip.

[0015] In some examples, the apparatus or method may involve transmitting periodic location updates, dropping the connection when exiting autonomous driving mode, and maintaining the connection without using TCP timeout or ACK / NACK feedback. Radio link control for the connection may not be in acknowledged mode.

[0016] Other aspects, features, and embodiments of the present disclosure will become apparent to those of ordinary skill in the art, upon reviewing the following description of specific, exemplary embodiments of the present disclosure in conjunction with the accompanying figures. While features of the present disclosure may be discussed relative to certain embodiments and figures below, all embodiments of the present disclosure can include one or more of the advantageous features discussed herein. In other words, while one or more embodiments may be discussed as having certain advantageous features, one or  more of such features may also be used in accordance with the various embodiments of the disclosure discussed herein. In similar fashion, while exemplary embodiments may be discussed below as device, system, or method embodiments it should be understood that such exemplary embodiments can be implemented in various devices, systems, and methods.BRIEF DESCRIPTION OF THE DRAWINGS

[0017] A further understanding of the nature and advantages of the present disclosure may be realized by reference to the following drawings. In the appended figures, similar components or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If just the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

[0018] FIG. 1 is a block diagram illustrating details of an example wireless communication system according to one or more aspects..

[0019] FIG. 2 shows a block diagram of an example base station and UE according to one or more aspects.

[0020] FIG. 3 shows a block diagram of an example image processing configuration for an autonomous vehicle according to one or more aspects.

[0021] FIG. 4 is a block diagram illustrating a system to facilitate low latency communications for autonomous vehicles according to one or more aspects.

[0022] FIG. 5 is a flow diagram illustrating an example process that supports low latency communications for autonomous vehicles according to one or more aspects.

[0023] FIG. 6 is a flow diagram illustrating an example process that supports low latency communications for autonomous vehicles according to one or more aspects.

[0024] FIG. 7 is a flow diagram illustrating an example process that supports low latency communications for autonomous vehicles according to one or more aspects.

[0025] FIG. 8 is a ladder diagram illustrating an example process that supports low latency communication according to one or more aspects.

[0026] Like reference numbers and designations in the various drawings indicate like elements.DETAILED DESCRIPTION

[0027] The detailed description set forth below, in connection with the appended drawings, is intended as a description of various configurations and is not intended to limit the scope of the disclosure. Rather, the detailed description includes specific details for the purpose of providing a thorough understanding of the inventive subject matter. It will be apparent to those skilled in the art that these specific details are not required in every case and that, in some instances, well-known structures and components are shown in block diagram form for clarity of presentation.

[0028] Implementations discussed herein address the challenge of efficiently delivering high-definition (HD) map data to autonomous vehicles with minimal latency. In conventional systems, downloading geographic information for autonomous vehicles involves multiple network hops, which results in significant latency. This typically includes the vehicle building a TCP connection and requesting HD map data from a server, which in some cases may be an edge server. The information travels through the network, often including multiple hops between the vehicle, base station (gNB) , and server. The server then transmits the HD map back through the network to the vehicle. This multi-hop process, involving steps such as connection establishment, request transmission, server processing, and data transmission, leads to latencies that often exceed 100 milliseconds. Such latency is suboptimal for critical driving decisions in autonomous vehicles.

[0029] In view of the foregoing, according to one aspect, a network node, such as a next-generation Node B (gNB) , employs an intelligent caching mechanism for HD map packets. In some instances, receiving and storing these packets associated with predicted vehicle locations occurs in a shared memory accessible to multiple vehicles. This approach involves the server sending HD map packets to the gNB in advance according to predicted vehicle locations. When a vehicle needs an HD map, it sends a request directly to the gNB using, e.g., PHY MAC signaling, allowing the gNB to transmit the requested HD map from its memory (e.g., a map data buffer) . This approach reduces transmission latency by eliminating intermediate hops in the network.

[0030] The caching mechanism’s importance is underscored by the stringent latency requirements for autonomous vehicles. Instantaneous geometric-and-geographic-information fetching, such as HD maps for object-detection related applications, requires round-trip latency smaller than 30 to 50 milliseconds. Existing network solutions have not effectively met these stringent requirements. However, implementations discussed herein utilize a cross-layer solution that utilizes a vehicle’s route and location information  to redesign the gNB’s storage or buffering mechanism. Doing so enables instantaneous data fetching without additional hardware costs. Also, this approach is beneficial for scenarios requiring higher object detection accuracy, such as driving on unfamiliar roads with frequent traffic incidents or when immediate arbitration is needed in vehicle-to-everything (V2X) communications.

[0031] A dynamic determination of storage duration for each packet can be involved in certain implementations. Factors like traffic patterns and route information inform this process and enable network components to anticipate and prepare for potential data requests from autonomous vehicles. When a vehicle needs specific geographic data, it sends a request to the network node, including a road segment identifier. Rapid location and transmission of the relevant HD map packet follows.

[0032] Some implementations can include a dedicated connection protocol for HD map packet exchange to maintain seamless data transfer throughout a vehicle’s trip. Mechanisms for periodic location updates from the vehicle can adapt to changes in operational mode, such as transitioning in or out of autonomous driving. Maintaining a persistent connection reduces overhead associated with repeatedly establishing new connections and leads to efficient and reliable data transmission. Persistent connections between nodes and vehicles facilitate continuous data exchange during a vehicle’s trip. Ongoing communication allows for real-time updates and ensures that vehicles have access to the most current geographic information as they navigate.

[0033] One aspect enables reception of indicators about available geographic data from network nodes on the vehicle side. Autonomous vehicles can identify upcoming zones along their predicted paths and proactively request specific data for these areas. A forward-looking approach ensures that needed information is available before the vehicle enters a new zone.

[0034] One or more of the following advantages can be realized by the concepts described herein. For instance, a proactive caching strategy implemented at the network node reduces latency in delivering geographic information to autonomous vehicles. Here, a reduction in delay benefits real-time decision-making processes for the autonomous vehicle. Improved access to up-to-date map data allows vehicles to respond more quickly to changing road conditions-which improves safety and efficiency of the vehicle’s autonomous operations.

[0035] Shared memory for storing HD map packets allows for more efficient use of network resources. That is, enabling multiple vehicles to access the same cached data reduces  redundant data transmissions and optimizes bandwidth usage. And efficiency gains are beneficial in densely populated urban areas where numerous autonomous vehicles may operate simultaneously.

[0036] A dynamic determination of storage durations based on traffic statistics and vehicle routes enables intelligent resource allocation. Prioritizing storage and updates of the most frequently accessed or important map data ensures that relevant information remains readily available. This adaptive approach reduces data retrieval time for the autonomous vehicles and improves responsiveness of the entire system.

[0037] Forward-looking data retrieval enhances the vehicle’s ability to plan routes and make decisions in advance of encountering new areas or potential obstacles. Consequently, autonomous vehicles can navigate more smoothly and efficiently, and adjust their paths based on up-to-date geographic information.

[0038] Establishing persistent connections for data exchange eliminates the need for repeated connection procedures. This is beneficial for maintain a consistent data flow during a portion of or for the entire vehicle’s journey. Continuous connection also allows for immediate transmission of critical updates or alerts, thereby enhancing the vehicle’s ability to respond to sudden changes in road conditions or emergency situations.

[0039] Flexibility in transmission channels and the inclusion of various identifiers (such as application, zone, or vehicle IDs) allows for versatile and context-aware data retrieval. Such adaptability satisfies diverse operational scenarios and specific needs of different autonomous driving systems. For instance, a vehicle navigating a complex urban environment might require more frequent, detailed updates compared to one traveling on a highway. Adjusting the data delivery approach accordingly optimizes performance across various use cases.

[0040] The techniques disclosed herein can be implemented through various systems, apparatus, methods, and computer-readable media. These implementations may work in concert to facilitate efficient HD map data delivery to autonomous vehicles. A network node, such as a next-generation Node B (gNB) , can be equipped with a processing system to manage an intelligent caching mechanism. This caching system may employ algorithms to predict which map packets will be needed, based on analysis of traffic patterns and vehicle routes. Autonomous vehicles can be configured to anticipate their data needs. By analyzing planned routes and identifying upcoming zones, these vehicles may proactively request specific map data before entering new areas. This approach can enhance navigational capabilities and safety performance.

[0041] The system may also include a dedicated connection protocol for HD map packet exchange. This protocol can incorporate adaptive mechanisms that respond to changes in a vehicle’s operational mode. For instance, the system may adjust its behavior when a vehicle transitions between manual and autonomous driving modes to maintain optimal data delivery across various scenarios.

[0042] The system’s network resource management can be dynamic. Rather than treating all map data uniformly, the system may employ prioritization based on assessed importance. It can subsequently reassess which data is most crucial based on current traffic conditions and vehicle movements. Doing so helps ensure that relevant and frequently accessed information remains readily available to optimize data access speed and network resource utilization.

[0043] The system can incorporate the use of various identifiers-such as application IDs, zone IDs, and vehicle IDs-in data requests and transmissions to allow for contextualized data retrieval. This adaptability can enable the system to address a range of scenarios, e.g., from urban environments requiring frequent updates to highway driving where updates may be less frequent.

[0044] In some implementations, the combination of predictive caching, proactive map data requests, adaptive connections, prioritization, and flexible identification inform a strategy that allows autonomous vehicles to maintain performance and safety standards across various driving conditions and network environments. This strategy can be particularly advantageous in areas with variable network coverage or rapidly changing road conditions. Such implementations may dynamically adjust data delivery methods based on real-time feedback from vehicles and network nodes.

[0045] In various implementations, the techniques and apparatus may be used for wireless communication networks such as code division multiple access (CDMA) networks, time division multiple access (TDMA) networks, frequency division multiple access (FDMA) networks, orthogonal FDMA (OFDMA) networks, single-carrier FDMA (SC-FDMA) ng networks, LTE networks, GSM networks, 5th Generation (5G) or new radio (NR) networks (sometimes referred to as “5G NR” networks, systems, or devices) , as well as other communications networks. As described herein, the terms “networks” and “systems” may be used interchangeably.

[0046] A CDMA network, for example, may implement a radio technology such as universal terrestrial radio access (UTRA) , cdma2000, and the like. UTRA includes wideband- CDMA (W-CDMA) and low chip rate (LCR) . CDMA2000 covers IS-2000, IS-95, and IS-856 standards.

[0047] A TDMA network may, for example implement a radio technology such as Global System for Mobile Communication (GSM) . The 3rd Generation Partnership Project (3GPP) defines standards for the GSM EDGE (enhanced data rates for GSM evolution) radio access network (RAN) , also denoted as GERAN. GERAN is the radio component of GSM / EDGE, together with the network that joins the base stations (for example, the Ater and Abis interfaces) and the base station controllers (Ainterfaces, etc. ) . The radio access network represents a component of a GSM network, through which phone calls and packet data are routed from and to the public switched telephone network (PSTN) and Internet to and from subscriber handsets, also known as user terminals or user equipments (UEs) . A mobile phone operator’s network may comprise one or more GERANs, which may be coupled with UTRANs in the case of a UMTS / GSM network. Additionally, an operator network may also include one or more LTE networks, or one or more other networks. The various different network types may use different radio access technologies (RATs) and RANs.

[0048] An OFDMA network may implement a radio technology such as evolved UTRA (E-UTRA) , Institute of Electrical and Electronics Engineers (IEEE) 802.11, IEEE 802.16, IEEE 802.20, flash-OFDM and the like. UTRA, E-UTRA, and GSM are part of universal mobile telecommunication system (UMTS) . In particular, long term evolution (LTE) is a release of UMTS that uses E-UTRA. UTRA, E-UTRA, GSM, UMTS and LTE are described in documents provided from an organization named “3rd Generation Partnership Project” (3GPP) , and cdma2000 is described in documents from an organization named “3rd Generation Partnership Project 2” (3GPP2) . 5G networks include diverse deployments, diverse spectrum, and diverse services and devices that may be implemented using an OFDM-based unified, air interface.

[0049] The present disclosure may describe certain aspects with reference to LTE, 4G, or 5G NR technologies; however, the description is not intended to be limited to a specific technology or application, and one or more aspects described with reference to one technology may be understood to be applicable to another technology. Additionally, one or more aspects of the present disclosure may be related to shared access to wireless spectrum between networks using different radio access technologies or radio air interfaces.

[0050] Devices, networks, and systems may be configured to communicate via one or more portions of the electromagnetic spectrum. The electromagnetic spectrum is often subdivided, based on frequency or wavelength, into various classes, bands, channels, etc. In 5G NR two initial operating bands have been identified as frequency range designations FR1 (410 MHz –7.125 GHz) and FR2 (24.25 GHz –52.6 GHz) . The frequencies between FR1 and FR2 are often referred to as mid-band frequencies. Although a portion of FR1 is greater than 6 GHz, FR1 is often referred to (interchangeably) as a “sub-6 GHz” band in various documents and articles. A similar nomenclature issue sometimes occurs with regard to FR2, which is often referred to (interchangeably) as a “millimeter wave” (mmWave) band in documents and articles, despite being different from the extremely high frequency (EHF) band (30 GHz –300 GHz) which is identified by the International Telecommunications Union (ITU) as a “mmWave” band.

[0051] With the above aspects in mind, unless specifically stated otherwise, it should be understood that the term “sub-6 GHz” or the like if used herein may broadly represent frequencies that may be less than 6 GHz, may be within FR1, or may include mid-band frequencies. Further, unless specifically stated otherwise, it should be understood that the term “mmWave” or the like if used herein may broadly represent frequencies that may include mid-band frequencies, may be within FR2, or may be within the EHF band.

[0052] 5G NR devices, networks, and systems may be implemented to use optimized OFDM-based waveform features. These features may include scalable numerology and transmission time intervals (TTIs) ; a common, flexible framework to efficiently multiplex services and features with a dynamic, low-latency time division duplex (TDD) design or frequency division duplex (FDD) design; and advanced wireless technologies, such as massive multiple input, multiple output (MIMO) , robust mmWave transmissions, advanced channel coding, and device-centric mobility. Scalability of the numerology in 5G NR, with scaling of subcarrier spacing, may efficiently address operating diverse services across diverse spectrum and diverse deployments. For example, in various outdoor and macro coverage deployments of less than 3 GHz FDD or TDD implementations, subcarrier spacing may occur with 15 kHz, for example over 1, 5, 10, 20 MHz, and the like bandwidth. For other various outdoor and small cell coverage deployments of TDD greater than 3 GHz, subcarrier spacing may occur with 30 kHz over 80 / 100 MHz bandwidth. For other various indoor wideband implementations, using a TDD over the unlicensed portion of the 5 GHz band, the subcarrier spacing may occur  with 60 kHz over a 160 MHz bandwidth. Finally, for various deployments transmitting with mmWave components at a TDD of 28 GHz, subcarrier spacing may occur with 120 kHz over a 500 MHz bandwidth.

[0053] For clarity, certain aspects of the apparatus and techniques may be described below with reference to example 5G NR implementations or in a 5G-centric way, and 5G terminology may be used as illustrative examples in portions of the description below; however, the description is not intended to be limited to 5G applications.

[0054] Moreover, it should be understood that, in operation, wireless communication networks adapted according to the concepts herein may operate with any combination of licensed or unlicensed spectrum depending on loading and availability. Accordingly, it will be apparent to a person having ordinary skill in the art that the systems, apparatus and methods described herein may be applied to other communications systems and applications than the particular examples provided.

[0055] FIG. 1 is a block diagram illustrating details of an example wireless communication system according to one or more aspects. Wireless network 100 may, for example, include a 5G wireless network, which is particularly suitable for the low-latency communications required for efficient HD map data delivery to autonomous vehicles. As appreciated by those skilled in the art, components appearing in FIG. 1 are likely to have related counterparts in other network arrangements including, for example, cellular-style network arrangements and non-cellular-style-network arrangements (e.g., device-to-device or peer-to-peer or ad-hoc network arrangements, etc. ) .

[0056] Wireless network 100 illustrated in FIG. 1 includes nodes (e.g., communication nodes) , such as base stations 105 and other network entities. A base station may be a station that communicates with the UEs and may also be referred to as an evolved node B (eNB) , a next generation eNB (gNB) , an access point, a node, and the like. Each base station 105 may provide communication coverage for a particular geographic area. In 3GPP, the term “cell” may refer to this particular geographic coverage area of a base station or a base station subsystem serving the coverage area, depending on the context in which the term is used. In implementations of wireless network 100 herein, base stations 105 may be associated with a same operator or different operators (e.g., wireless network 100 may include a plurality of operator wireless networks) . Additionally, in implementations of wireless network 100 herein, base station 105 may provide wireless communications using one or more of the same frequencies (e.g., one or more frequency bands in licensed spectrum, unlicensed spectrum, or a combination thereof) as a neighboring cell. In some  examples, an individual base station 105 or UE 115 may be operated by more than one network operating entity. In some other examples, each base station 105 and UE 115 may be operated by a single network operating entity. At least one of the base stations, such as base station 105d, may act as the gNB that implements the intelligent caching mechanism for HD map packets, while another network entity may represent the server that provides HD map data to the gNB.

[0057] A base station may provide communication coverage for a macro cell or a small cell, such as a pico cell or a femto cell, or other types of cell. A macro cell generally covers a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access by UEs with service subscriptions with the network provider. A small cell, such as a pico cell, would generally cover a relatively smaller geographic area and may allow unrestricted access by UEs with service subscriptions with the network provider. A small cell, such as a femto cell, would also generally cover a relatively small geographic area (e.g., a home) and, in addition to unrestricted access, may also provide restricted access by UEs having an association with the femto cell (e.g., UEs in a closed subscriber group (CSG) , UEs for users in the home, and the like) . A base station for a macro cell may be referred to as a macro base station. A base station for a small cell may be referred to as a small cell base station, a pico base station, a femto base station or a home base station. In the example shown in FIG. 1, base stations 105d and 105e are regular macro base stations, while base stations 105a-105c are macro base stations enabled with one of three-dimension (3D) , full dimension (FD) , or massive MIMO. Base stations 105a-105c take advantage of their higher dimension MIMO capabilities to exploit 3D beamforming in both elevation and azimuth beamforming to increase coverage and capacity. Base station 105f is a small cell base station which may be a home node or portable access point. A base station may support one or multiple (e.g., two, three, four, and the like) cells. Base station 105d, acting as the gNB, could be a macro base station covering a large area to allow it to serve multiple autonomous vehicles efficiently with HD map data.

[0058] Wireless network 100 may support synchronous or asynchronous operation. For synchronous operation, the base stations may have similar frame timing, and transmissions from different base stations may be approximately aligned in time. For asynchronous operation, the base stations may have different frame timing, and transmissions from different base stations may not be aligned in time. In some scenarios, networks may be enabled or configured to handle dynamic switching between  synchronous or asynchronous operations. Flexibility in operation can be leveraged to ensure optimal delivery of HD map data to autonomous vehicles under various network conditions.

[0059] UEs 115 are dispersed throughout the wireless network 100, and each UE may be stationary or mobile. It should be appreciated that, although a mobile apparatus is commonly referred to as a UE in standards and specifications promulgated by the 3GPP, such apparatus may additionally or otherwise be referred to by those skilled in the art as a mobile station (MS) , a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal (AT) , a mobile terminal, a wireless terminal, a remote terminal, a handset, a terminal, a user agent, a mobile client, a client, a gaming device, an augmented reality device, vehicular component, vehicular device, or vehicular module, or some other suitable terminology. UEs representing autonomous vehicles can be capable of requesting and receiving HD map data from the gNB, as well as communicating with the server through the gNB.

[0060] Some non-limiting examples of a mobile apparatus, such as may include implementations of one or more of UEs 115, include a mobile, a cellular (cell) phone, a smart phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a laptop, a personal computer (PC) , a notebook, a netbook, a smart book, a tablet, a personal digital assistant (PDA) , and a vehicle. Although UEs 115a-j are specifically shown as vehicles, a vehicle may employ the communication configuration described with reference to any of the UEs 115a-115k. Any of these vehicles can represent autonomous vehicles capable of establishing persistent connections with the gNB for ongoing exchange of HD map data during their trips.

[0061] In one aspect, a UE may be a device that includes a Universal Integrated Circuit Card (UICC) . In another aspect, a UE may be a device that does not include a UICC. In some aspects, UEs that do not include UICCs may also be referred to as IoE devices. UEs 115a-115d of the implementation illustrated in FIG. 1 are examples of mobile smart phone-type devices accessing wireless network 100. A UE may also be a machine specifically configured for connected communication, including machine type communication (MTC) , enhanced MTC (eMTC) , narrowband IoT (NB-IoT) and the like. UEs 115e-115k illustrated in FIG. 1 are examples of various machines configured for communication that access wireless network 100. UEs representing autonomous vehicles  would be specifically configured to handle the exchange of HD map data with the gNB and the server.

[0062] A mobile apparatus, such as UEs 115, may be able to communicate with any type of the base stations, whether macro base stations, pico base stations, femto base stations, relays, and the like. In FIG. 1, a communication link (represented as a lightning bolt) indicates wireless transmissions between a UE and a serving base station, which is a base station designated to serve the UE on the downlink or uplink, or desired transmission between base stations, and backhaul transmissions between base stations. UEs may operate as base stations or other network nodes in some scenarios. Backhaul communication between base stations of wireless network 100 may occur using wired or wireless communication links. Such communication links can include the transmission of HD map requests and data between autonomous vehicles and the gNB, as well as between the gNB and the server providing HD map data.

[0063] In operation at wireless network 100, base stations 105a-105c serve UEs 115a and 115b using 3D beamforming and coordinated spatial techniques, such as coordinated multipoint (CoMP) or multi-connectivity. Macro base station 105d performs backhaul communications with base stations 105a-105c, as well as small cell, base station 105f. Macro base station 105d also transmits multicast services which are subscribed to and received by UEs 115c and 115d. Such multicast services may include mobile television or stream video, or may include other services for providing community information, such as weather emergencies or alerts, such as Amber alerts or gray alerts. In an implementation, base station 105d, acting as the gNB, can also be responsible for caching HD map data received from the server and efficiently delivering it to autonomous vehicles.

[0064] Wireless network 100 supports mission critical communications with ultra-reliable and redundant links for mission critical devices, such UE 115e, which is a drone. Redundant communication links with UE 115e include from macro base stations 105d and 105e, as well as small cell base station 105f. Other machine type devices, such as UE 115f (thermometer) , UE 115g (smart meter) , and UE 115h (wearable device) may communicate through wireless network 100 either directly with base stations, such as small cell base station 105f, and macro base station 105e, or in multi-hop configurations by communicating with another user device which relays its information to the network, such as UE 115f communicating temperature measurement information to the smart meter, UE 115g, which is then reported to the network through small cell base station  105f. Wireless network 100 may also provide additional network efficiency through dynamic, low-latency TDD communications or low-latency FDD communications, such as in a vehicle-to-vehicle (V2V) mesh network between UEs 115i-115k communicating with macro base station 105e. Low-latency communication capability can be important for efficiently delivering HD map data to autonomous vehicles. Base station 105d, acting as the gNB, can implement the intelligent caching mechanism for HD map packets, serving autonomous vehicles (such as those represented by UEs 115i-115k) with cached geographic data. The V2V mesh network capabilities can potentially be leveraged for sharing or relaying HD map data between vehicles when direct communication with the gNB is not optimal.

[0065] FIG. 2 depicts aspects of an example BS 110 and UE 120 that support low-latency geographic information packet fetching for autonomous vehicles. Generally, BS 110 includes various processors (e.g., 220, 230, 238, and 240) , antennas 234a-t (collectively 234) , transceivers 232a-t (collectively 232) , which include modulators and demodulators, and other aspects, which enable wireless transmission of data (e.g., data source 212) and wireless reception of data (e.g., data sink 239) . For example, BS 110 may send and receive data between BS 110 and UE 120, including HD map packets and related requests. BS 110 includes controller / processor 240, which may be configured to implement various functions described herein related to wireless communications, including the intelligent caching mechanism for HD map packets.

[0066] Generally, UE 120 includes various processors (e.g., 258, 264, 266, and 280) , antennas 252a-r (collectively 252) , transceivers 254a-r (collectively 254) , which include modulators and demodulators, and other aspects, which enable wireless transmission of data (e.g., retrieved from data source 262) and wireless reception of data (e.g., provided to data sink 260) . UE 120 includes controller / processor 280, which may be configured to implement various functions described herein related to wireless communications, including requesting and processing HD map data for autonomous vehicle operation.

[0067] For an example downlink transmission, BS 110 (e.g., any network node) includes a transmit processor 220 that may receive data from a data source 212 and control information from a controller / processor 240. The control information may be for the physical broadcast channel (PBCH) , the physical control format indicator channel (PCFICH) , the physical hybrid automatic repeat request (HARQ) indicator channel (PHICH) , the physical downlink control channel (PDCCH) , the group common PDCCH (GC PDCCH) , and / or other channels. The data may be for the physical downlink shared  channel (PDSCH) , in some examples, including HD map packets for autonomous vehicles.

[0068] Transmit processor 220 may process (e.g., encode and symbol map) the data and control information to obtain data symbols and control symbols, respectively. Transmit processor 220 may also generate reference symbols, such as for the primary synchronization signal (PSS) , the secondary synchronization signal (SSS) , the PBCH demodulation reference signal (DMRS) , or the channel state information reference signal (CSI-RS) . Transmit processor 220 can facilitate transmitting a waveform to a UE or the like, and further facilitate transmitting frequency resource configuration information and / or time resource configuration information. These can be associated with HD map data transmission and the UE's capabilities for processing such data.

[0069] Transmit (TX) multiple-input multiple-output (MIMO) processor 230 may perform spatial processing (e.g., precoding) on the data symbols, the control symbols, and / or the reference symbols, if applicable, and may provide output symbol streams to the modulators (MODs) in transceivers 232a-232t. Each modulator in transceivers 232a-232t may process a respective output symbol stream to obtain an output sample stream. Each modulator may further process (e.g., convert to analog, amplify, filter, and upconvert) the output sample stream to obtain a downlink signal. Downlink signals from the modulators in transceivers 232a-232t may be transmitted via the antennas 234a-234t, respectively, and may include HD map data for autonomous vehicles.

[0070] UE 120 includes antennas 252a-252r that may receive the downlink signals from BS 110 and may provide received signals to the demodulators (DEMODs) in transceivers 254a-254r, respectively. Each demodulator in transceivers 254a-254r may condition (e.g., filter, amplify, downconvert, and digitize) a respective received signal to obtain input samples. Each demodulator may further process the input samples to obtain received symbols.

[0071] MIMO detector 256 may obtain received symbols from all the demodulators in transceivers 254a-254r, perform MIMO detection on the received symbols if applicable, and provide detected symbols. Receive processor 258 may process (e.g., demodulate, deinterleave, and decode) the detected symbols, provide decoded data for UE 120 to a data sink 260, and provide decoded control information to a controller / processor 280. Receive processor 258 can facilitate the UE receiving frequency resource configuration information and / or time resource configuration information. Such configuration  information can be associated with HD map data reception and processing for autonomous vehicle operation.

[0072] For an example uplink transmission, UE 120 further includes a transmit processor 264 that may receive and process data (e.g., for the physical uplink shared channel (PUSCH) ) from a data source 262 and control information (e.g., for the physical uplink control channel (PUCCH) ) from the controller / processor 280. Transmit processor 264 may also generate reference symbols for a reference signal (e.g., for the sounding reference signal (SRS) ) . The symbols from the transmit processor 264 may be precoded by a TX MIMO processor 266 if applicable, further processed by the modulators in transceivers 254a-254r (e.g., for single-carrier frequency division multiplexing (SC-FDM) ) , and transmitted to BS 110. Further, transmit processor 264 can facilitate transmitting requests for HD map data and location updates to a network node.

[0073] At BS 110, the uplink signals from UE 120 may be received by antennas 234a-234t, processed by the demodulators in transceivers 232a-232t, detected by a MIMO detector 236 if applicable, and further processed by a receive processor 238 to obtain decoded data and control information sent by UE 120. Receive processor 238 may provide the decoded data to a data sink 239 and the decoded control information to the controller / processor 240. Memories 242 and 282 may store data and program codes (e.g., processor-executable instructions, computer-executable instructions) for BS 110 and UE 120, respectively. Scheduler 244 may schedule UEs for data transmission on the downlink and / or uplink, including scheduling the transmission of HD map data to autonomous vehicles.

[0074] In various aspects, BS 110 may be described as transmitting and receiving various types of data associated with the methods described herein. In these contexts, “transmitting” may refer to various mechanisms of outputting data, such as outputting data from data source 212, scheduler 244, memory 242, transmit processor 220, controller / processor 240, TX MIMO processor 230, transceivers 232a-t, antenna 234a-t, and / or other aspects described herein. Similarly, “receiving” may refer to various mechanisms of obtaining data, such as obtaining data from antennas 234a-t, transceivers 232a-t, receive (RX) MIMO detector 236, controller / processor 240, receive processor 238, scheduler 244, memory 242, a network interface, and / or other aspects described herein.

[0075] In various aspects, UE 120 may likewise be described as transmitting and receiving various types of data associated with the methods described herein. In these contexts, “transmitting” may refer to various mechanisms of outputting data, such as outputting  data from data source 262, memory 282, transmit processor 264, controller / processor 280, TX MTMO processor 266, transceivers 254a-t, antenna 252a-t, and / or other aspects described herein. Similarly, “receiving” may refer to various mechanisms of obtaining data, such as obtaining data from antennas 252a-t, transceivers 254a-t, RX MIMO detector 256, controller / processor 280, receive processor 258, memory 282, and / or other aspects described herein.

[0076] In some aspects, a processor may be configured to perform various operations, such as those associated with the methods described herein, and transmit (output) data to or receive (obtain) data from another interface that is configured to transmit or receive, respectively, the data.

[0077] While blocks in FIG. 2 are illustrated as distinct components, the functions described above with respect to the blocks may be implemented in a single hardware, software, or combination component or in various combinations of components. For example, the functions described with respect to the transmit processor 264, the receive processor 258, and / or the TX MTMO processor 266 may be performed by or under the control of the controller / processor 280.

[0078] Deployment of communication systems, such as 5G NR systems, may be arranged in multiple manners with various components or constituent parts. In a 5G NR system, or network, a network node, a network entity, a mobility element of a network, a RAN node, a core network node, a network element, a base station network node, or a network equipment may be implemented in an aggregated or disaggregated architecture. For example, a network node (such as a Node B (NB) , an evolved NB (eNB) , an NR BS, a 5G NB, an AP, a TRP, or a cell, among other examples) , or one or more units (or one or more components) performing network node functionality, may be implemented as an aggregated network node (also known as a standalone network node or a monolithic network node) or a disaggregated network node. “Network entity” or “network node” may refer to a disaggregated network node, or to one or more units of a disaggregated network node (such as one or more CUs, one or more DUs, one or more RUs, or a combination thereof) .

[0079] An aggregated network node (e.g., an aggregated network node) may be configured to utilize a radio protocol stack that is physically or logically integrated within a single RAN node (e.g., within a single device or unit) . A disaggregated network node (e.g., a disaggregated network node) may be configured to utilize a protocol stack that is physically or logically distributed among two or more units (such as one or more CUs,  one or more DUs, or one or more RUs) . In some examples, a CU may be implemented within a network node, and one or more DUs may be co-located with the CU, or alternatively, may be geographically or virtually distributed throughout one or multiple other network nodes. The DUs may be implemented to communicate with one or more RUs. Each of the CU, DU and RU also can be implemented as virtual units, such as a virtual central unit (VCU) , a virtual distributed unit (VDU) , or a virtual radio unit (VRU) , among other examples.

[0080] Network node-type operation or network design may consider aggregation characteristics of network node functionality. For example, disaggregated network nodes may be utilized in an IAB network, an open radio access network (O-RAN (such as the network configuration sponsored by the O-RAN Alliance) ) , or a virtualized radio access network (vRAN, also known as a cloud radio access network (C-RAN) ) to facilitate scaling of communication systems by separating network node functionality into one or more units that can be individually deployed. A disaggregated network node may include functionality implemented across two or more units at various physical locations, as well as functionality implemented for at least one unit virtually, which can enable flexibility in network design. The various units of the disaggregated network node can be configured for wired or wireless communication with at least one other unit of the disaggregated network node.

[0081] FIG. 3 shows a block diagram of an example processing system 384 associated with autonomous vehicles 115i-115k. Processing system 384 includes one or more processors (collectively “processor 304” ) , one or more memories (collectively “memory 306” ) , image signal processor 312, sensor hub 350, and Input / Output (I / O) components 316. Autonomous vehicles 115i-115k may include, or otherwise be coupled to, image signal processor 312 for processing image frames from one or more image sensors, such as first image sensor 301, second image sensor 302, and depth sensor 340. These sensors can contribute to the autonomous navigation capabilities and HD map data processing. In some implementations, autonomous vehicles 115i-115k also include or are coupled to a processor (e.g., CPU) 304 and memory 306 storing instructions 308. Autonomous vehicles 115i-115k may also include or be coupled to display 314 and input / output (I / O) components 316. I / O components 316 may be used for interacting with a user, such as a touch screen interface and / or physical buttons. I / O components 316 may also include network interfaces for communicating with other devices, such as other vehicles, an operator's mobile devices, and / or a remote monitoring system. The network interfaces  may include one or more of wide area network (WAN) adaptor 352, local area network (LAN) adaptor 353, and / or personal area network (PAN) adaptor 354. An example WAN adaptor 352 is a 4G LTE or a 5G NR wireless network adaptor, which can be used for low-latency HD map data retrieval. An example LAN adaptor 353 is an IEEE 802.11 WiFi wireless network adapter. An example PAN adaptor 354 is a Bluetooth wireless network adaptor. Each of adaptors 352, 353, and / or 354 may be coupled to an antenna, including multiple antennas configured for primary and diversity reception and / or configured for receiving specific frequency bands. Autonomous vehicles 115i-115k may further include or be coupled to power supply 318, such as a battery or an alternator. Autonomous vehicles 115i-115k may also include or be coupled to additional features or components that are not shown in FIG. 3. In one example, a wireless interface, which may include one or more transceivers and associated baseband processors, may be coupled to or included in WAN adaptor 352 for a wireless communication device. In a further example, an analog front end (AFE) to convert analog image frame data to digital image frame data may be coupled between the image sensors 301 and 302 and the image signal processor 312.

[0082] Autonomous vehicles 115i-115k may include sensor hub 350 for interfacing with sensors to receive data regarding movement of autonomous vehicles 115i-115k, data regarding an environment around autonomous vehicles 115i-115k, and / or other non-camera sensor data. One example non-camera sensor is a gyroscope, a device configured for measuring rotation, orientation, and / or angular velocity to generate motion data. Another example non-camera sensor is an accelerometer, a device configured for measuring acceleration, which may also be used to determine velocity and distance traveled by appropriately integrating the measured acceleration, and one or more of the acceleration, velocity, and or distance may be included in generated motion data. In further examples, a non-camera sensor may be a global positioning system (GPS) receiver, a light detection and ranging (LiDAR) system, a radio detection and ranging (RADAR) system, or other ranging systems. Such sensors can provide critical data for autonomous navigation and HD map data processing. For example, sensor hub 350 may interface to a vehicle bus for sending configuration commands and / or receiving information from vehicle sensors 372, such as distance (e.g., ranging) sensors or vehicle-to-vehicle (V2V) sensors (e.g., sensors for receiving information from nearby vehicles) .

[0083] Image signal processor (ISP) 312 may receive image data, such as used to form image frames. In one embodiment, a local bus connection couples image signal processor 312  to image sensors 301 and 302 of first camera 303 and second camera 305. In another embodiment, a wire interface may couple image signal processor 312 to an external image sensor. In a further embodiment, a wireless interface may couple image signal processor 312 to image sensor 301, 302.

[0084] First camera 303 may include first image sensor 301 and corresponding first lens 331. Second camera 305 may include second image sensor 302 and corresponding second lens 232. Each of lenses 331 and 332 may be controlled by associated autofocus (AF) algorithm 333 executing in ISP 312, which adjust lenses 331 and 332 to focus on a particular focal plane at a certain scene depth from image sensors 301 and 302. AF algorithm 233 may be assisted by depth sensor 340. In some embodiments, lenses 331 and 232 may have a fixed focus.

[0085] First image sensor 301 and second image sensor 302 are configured to capture one or more image frames. Lenses 331 and 332 focus light at image sensors 301 and 302, respectively, through one or more apertures for receiving light, one or more shutters for blocking light when outside an exposure window, one or more color filter arrays (CFAs) for filtering light outside of specific frequency ranges, one or more analog front ends for converting analog measurements to digital information, and / or other suitable components for imaging.

[0086] In some embodiments, image signal processor 312 may execute instructions from a memory, such as instructions 308 from memory 306, instructions stored in a separate memory coupled to or included in image signal processor 312, or instructions provided by processor 304. In addition, or in the alternative, image signal processor 312 may include specific hardware (such as one or more integrated circuits (ICs) ) configured to perform one or more operations described in the present disclosure. For example, image signal processor 312 may include one or more image front ends (IFEs) 335, one or more image post-processing engines (IPEs) 336, and or one or more auto exposure compensation (AEC) 334 engines. AF 333, AEC 334, IFE 335, IPE 336 may each include application-specific circuitry, may be embodied as software code executed by ISP 312, and / or a combination of hardware within and software code executing on ISP 312.

[0087] In some implementations, memory 306 may include a non-transient or non-transitory computer readable medium storing computer-executable instructions 308 to perform all or a portion of one or more operations described in this disclosure. In some implementations, instructions 308 include a camera application (or other suitable application) to be executed during operation of autonomous vehicles 115i-115k for  generating images or videos. Instructions 308 may also include other applications or programs executed for autonomous vehicles 115i-115k, such as an operating system, mapping applications, or entertainment applications. Execution of the camera application, such as by processor 304, may cause autonomous vehicles 115i-115k to generate images using image sensors 301 and 302 and image signal processor 312. Memory 306 may also be accessed by image signal processor 312 to store processed frames or may be accessed by processor 304 to obtain the processed frames. In some embodiments, autonomous vehicles 115i-115k include a system on chip (SoC) that incorporates image signal processor 312, processor 304, sensor hub 350, memory 306, and input / output components 316 into a single package.

[0088] In some embodiments, at least one of image signal processor 312 or processor 304 executes instructions to perform various operations described herein, including object detection, risk map generation, driver monitoring, and driver alert operations. For example, execution of the instructions can instruct image signal processor 312 to begin or end capturing an image frame or a sequence of image frames. In some embodiments, processor 304 may include one or more general-purpose processor cores 304A capable of executing scripts or instructions of one or more software programs, such as instructions 308 stored within the memory 306. For example, processor 304 may include one or more application processors configured to execute the camera application (or other suitable application for generating images or video) stored in memory 306.

[0089] In executing the camera application, processor 304 may be configured to instruct image signal processor 312 to perform one or more operations with reference to the image sensors 301 or 302. For example, the camera application may receive a command to begin a video preview display upon which a video comprising a sequence of image frames is captured and processed from one or more image sensors 301 or 302 and displayed on informational display on display 314 in a cabin of the autonomous vehicles 115i-115k.

[0090] In some embodiments, processor 304 may include ICs or other hardware (e.g., an artificial intelligence (AI) engine 334) in addition to the ability to execute software to cause autonomous vehicles 115i-115k to perform a number of functions or operations, such as the operations described herein. In some other embodiments, autonomous vehicles 115i-115k do not include processor 304, such as when all of the described functionality is configured in image signal processor 312.

[0091] In some embodiments, display 314 may include one or more suitable displays or screens allowing for user interaction and / or to present items to the user, such as a preview of the  image frames being captured by image sensors 301 and 302. In some embodiments, display 314 is a touch-sensitive display. I / O components 316 may be or include any suitable mechanism, interface, or device to receive input (such as commands) from the user and to provide output to the user through display 314. For example, I / O components 316 may include (but are not limited to) a graphical user interface (GUI) , a keyboard, a mouse, a microphone, speakers, a squeezable bezel, one or more buttons (such as a power button) , a slider, a switch, and so on. In some embodiments involving autonomous driving, I / O components 316 may include an interface to a vehicle's bus for providing commands and information to and receiving information from vehicle systems 370 including propulsion (e.g., commands to increase or decrease speed or apply brakes) and steering systems (e.g., commands to turn wheels, change a route, or change a final destination) .

[0092] While shown to be coupled to each other via processor 304, components (such as processor 304, memory 306, image signal processor 312, display 314, and I / O components 316) may be coupled to each another in other various arrangements, such as via one or more local buses, which are not shown for simplicity. While image signal processor 312 is illustrated as separate from processor 304, image signal processor 312 may be a core of processor 304 that is an application processor unit (APU) , included in a system on chip (SoC) , or otherwise included with processor 304. While autonomous vehicles 115i-115k are referred to in the examples herein for including aspects of the present disclosure, some device components may not be shown in FIG. 3 to prevent obscuring aspects of the present disclosure. Additionally, other components, numbers of components, or combinations of components may be included in suitable autonomous vehicles for performing aspects of the present disclosure. As such, the present disclosure is not limited to a specific device or configuration of components, including autonomous vehicles 115i-115k.

[0093] FIG. 4 is a block diagram illustrating a system 400 to facilitate low-latency geographic information packet fetching for autonomous vehicles according to one or more aspects. System 400 includes an autonomous vehicle 402, autonomous vehicles 420, 436, and network node 438 (e.g., a base station) . While two autonomous vehicles 420, 436 are depicted, system 400 may include additional autonomous vehicles.

[0094] Autonomous vehicle 402 includes processing system 404 and communication interface 416. Processing system 404 may include or correspond to the vehicle’s onboard computer system. Processing system includes one or more processors 406 (hereinafter referred to  as “processor 406” ) and one or more memories 408 (hereinafter referred to as “memory 408” ) . Communication interface 416 may include one or more antennas, one or more transceivers, or the like.

[0095] Memory 408 is configured to store instructions 410, data 412, and parameters 414. Processor 406, when executing instructions 410, may be configured to implement the functionality described herein to facilitate low-latency geographic information packet fetching. Data 412 may include or correspond to geographic data to enable autonomous vehicle 402 to perform autonomous operations. Parameters 414 may include or correspond to a set of parameters (e.g., a first set of parameters, a second set of parameters, etc. ) .

[0096] Parameters 414 may include an index indicating implementation of a low-latency geographic information packet fetching protocol. Additionally, parameters 414 may include an identifier indicating an identity of a requesting autonomous vehicle. Further, parameters 414 may include a travel indicator indicating a travel direction of the requesting autonomous vehicle. Moreover, parameters 414 may include a locator indicating a position of the requesting autonomous vehicle. The position may identify a path traveled by the requesting autonomous vehicle (e.g., a road ID) , a segment of the path at which the requesting autonomous vehicle is located (e.g., a road segment ID) , or both. Further, parameters 414 may include a request direction indicator indicating a direction of the request. Additionally, parameters 414 may include a hop indicator indicating a maximum allowed quantity of hops. Further, parameters 414 may include a distance indicator indicating a maximum permissible distance between a receiving autonomous vehicle and the requesting autonomous vehicle.

[0097] UE 420 includes processing system 422 and communication interface 434. Processing system 422 may be analogous to processing system 404. Additionally, processing system 422 includes one or more processors 424 (hereinafter referred to as “processor 424” ) and one or more memories 426 (hereinafter referred to as “memory 426” ) . Processor 424 may be analogous to processor 406, and memory 426 may be analogous to memory 408. Further, communication interface 434 may be analogous to communication interface 416.

[0098] Memory 426 includes instructions 430 and parameters 432. Instructions 430 may be analogous to instructions 410 and, when executed by processor 424, may implement one or more functionalities described herein with reference to low-latency geographic information packet fetching. Parameters 432 may include or correspond to parameters  414. UE 436 may include components similar to those described with reference to autonomous vehicles 402, 420.

[0099] Network node 438 (e.g., a base station) may include processing system 440 and communication interface 450. Processing system 440 includes one or more processors 442 (hereinafter referred to as “processor 442” ) and one or more memories (hereinafter referred to as “memory 444” ) . Processing system 440 and its components may be configured to perform functionality similar to functionalities described with reference to processing systems 404, 422 and their respective components. Memory 444 includes instructions 446 and parameters 448. Instructions 446 and parameters 448 may correspond to (e.g., may be analogous to) instructions 410, 430. Parameters 448 may correspond to (e.g., may be analogous to) parameters 414, 432.

[0100] Memory 444 may be configured to store instructions 446, parameters 448, and data 452. Instructions 446, when executed by processor 442, may configure network node 438 to perform the functionality described herein with reference to low-latency geographic information packet fetching. Parameters 448 may include, correspond to, or be analogous with parameters 414, 432. Data 452 may include or correspond to one or more instances of geographic data, such as HD map packets, that facilitate autonomous vehicle operations.

[0101] Server 490 includes a processing system 480 and a communication interface 494. Processing system 480 includes a processor 482 and a memory 484. Memory 484 is configured to store instructions 486, parameters 488, and data 492. Processor 482, when executing instructions 486, may be configured to implement the functionality described herein to support low-latency geographic information packet fetching. Data 492 may include or correspond to HD map packets and other geographic information to be sent to network nodes and autonomous vehicles. Parameters 488 may include configuration settings and operational parameters for managing the distribution of geographic data. Communication interface 494 enables server 490 to communicate with other network infrastructure, such as network nodes and, in some cases, directly with autonomous vehicles.

[0102] During operation, processing system 404 of autonomous vehicle 402 may determine a need for updated geographic data. Accordingly, processing system 404 may generate request message 452. Request message includes first set of parameters 454. First set of parameters 454 may include or correspond to one or more of parameters 414. Further, first set of parameters 454 may include a first parameter indicating at least a first criterion  for a receiving autonomous vehicle, such as UE 420, to initiate broadcast of a relay message, such as data 460, generated in accordance with request message 452. The at least the first criterion may include or correspond to a condition that the receiving autonomous vehicle travels on a same road (e.g., having the same road ID) and in a same direction as autonomous vehicle 402. However, the at least first criterion may include other or different conditions. For instance, the at least first criterion may additionally indicate that a distance separating an autonomous vehicle that receives the request message (e.g., UE 420) from the autonomous vehicle that broadcasts the request message (e.g., autonomous vehicle 402) may not exceed a threshold distance, such as indicated by the first parameter.

[0103] During operation, system 400 implements an approach to low-latency geographic information packet fetching. In some implementations, this approach may improve upon conventional methods. In a conventional system, geographic information downloading may involve multiple hops and potentially increased latency. Such a process may begin with an autonomous vehicle (which may be represented by UE 402) establishing a connection and requesting a high definition (HD) map from a server 490, which may be, e.g., an edge server. This request may travel through multiple network nodes, including a gNodeB (which may be represented by network node 438) and potentially other network infrastructure, before reaching the server 490. The server 490 may then transmit the HD map back through the network, again potentially passing through multiple nodes before reaching the autonomous vehicle.

[0104] In contrast, system 400 may implement a proactive caching strategy. In this approach, the server 490 (e.g., another network node or edge server) may send HD map packets to the gNodeB (network node 438) in advance, based on predicted vehicle locations. Network node 438 may store these packets in its memory 422, which in some implementations is an HD buffer. When UE 402 needs an HD map, it may send a request directly to network node 438 using PHY MAC signaling. Network node 438 may then transmit the requested HD map from its buffer 422.

[0105] System 400 may implement HD map buffering at network node 438. Based on predicted vehicle locations, another network node may send HD map packets to network node 438 for buffering. A field in the packet header may indicate that the packet should be cached but reserved from immediate PHY layer downlink transmission. The road segment ID and optionally the lane ID of the HD map tile may be included in the packet headers, allowing network node 438 to organize the packets in its buffer 422.

[0106] This approach may provide several benefits. For instance, the memory 422 or MAC buffer in network node 438 may not always be flushed, as the HD map packets may be transmitted to multiple vehicles in the same area. In some implementations, system 400 may implement an HD map pool buffer at the MAC layer of network node 438, which may be accessed by HD map location ID, such as zone ID, lane ID, or road segment ID. The HD map pool buffer in network node 438 may be accessible by multiple vehicles, e.g., associated with the same OEM. Network node 438 may wait for PHY MAC signaling from the vehicle before transmitting, rather than immediately scheduling transmission upon packet arrival. Network node 438 may associate location information with each HD map packet in its buffer (e.g., memory 422) , potentially allowing for more efficient packet management. System 400 may maintain a connection throughout a vehicle’s trip to enable faster data fetching.

[0107] In some implementations, UE 402 may periodically report its location (e.g., road segment ID) to the server 490. HD map data may be organized into “tiles, ” which are discrete, manageable units of geographic information. These tiles may correspond to specific areas or road segments, allowing for efficient storage, transmission, and updates of map data. The size and scope of each tile may vary based on factors such as road density, update frequency requirements, or typical vehicle speeds in the area. Based on the location information received from UE 402, server 490 may determine which HD map tile packets to send to memory 422 of network node 438. This predictive caching approach allows system 400 to anticipate the HD map data that UE 402 and other nearby vehicles may need in the near future. By sending these tiles to network node 438 in advance, system 400 can significantly reduce latency when UE 402 actually requests the data.

[0108] UE 402 may also send route information to server 490, which may enable even more precise prediction of required map tiles. For instance, if UE 402 indicates it will be taking a specific route, server 490 can preemptively send the tiles covering that entire route to network node 438. These location and route messages may be included in TCP headers, PDCP headers, or other appropriate protocols, depending on the specific implementation and network configuration.

[0109] Similarly, UE 402 may periodically report its location to network node 438. This allows the node to manage its memory 422 efficiently by determining which HD map packets (tiles) to keep and which to remove. For example, as UE 402 moves away from a particular area, network node 438 may remove tiles covering that area if no other nearby vehicles are likely to need them soon. These location updates from UE 402 to network  node 438 may be included in Buffer Status Report (BSR) , MAC Control Element (MAC-CE) , or MAC headers, leveraging existing cellular protocols for efficient communication.

[0110] Consistent with the foregoing, the use of tiles in system 400 offers several benefits. It allows for granular updates to the HD map data, as only changed tiles need to be transmitted rather than entire map sets. This approach can significantly reduce data transmission requirements and ensure that vehicles have the most up-to-date information for their immediate surroundings. Additionally, utilizing tiles facilitates efficient caching and memory management at both server 490 and network node 438, enabling them to store and transmit only the most relevant data for vehicles in their respective coverage areas.

[0111] System 400 may implement a specific HD map PHY layer transmission process. When UE 402 needs an HD map tile, it may send a message in the uplink control or data channel to network node 438. This message may include one or more of the following: road segment ID, application ID, zone ID, and vehicle ID. The message may be transmitted via PUCCH or PUSCH. Upon receiving this message, network node 438 may locate the correct packet in its memory (e.g., an HD buffer) 422 using the road segment ID and zone ID, form it into transport blocks (TBs) , and send it to UE 402.

[0112] If the requested HD map packet is not available in buffer 422 of network node 438, system 400 may implement an alternative approach. In a first alternative, network node 438 may send a message to the server 490 requesting the missing packet. Once received, network node 438 may add it to its buffer 422 and send it to UE 402. In a second alternative, network node 438 may signal to UE 402 that the required packet is not in memory 422, using a format of DCI distinct from NACK / ACK. UE 402 may then implement other solutions to obtain the needed data.

[0113] System 400 may also implement a dedicated connection for HD map exchange. To address latency requirements for autonomous vehicle operation, UE 402 may message the server 490 to establish a dedicated connection. This connection may be maintained throughout the vehicle’s trip. An application ID field may be added to the packet header in the upper layer connection establishment messages. Also, this dedicated connection may be a TCP connection to provide communication quality assurance, but TCP timeout and ACK / NACK feedback from UE 402 may not be needed, as not all packets may need to be delivered. TCP retransmissions may occur from network node 438 to the server 490, rather than from UE 402 to the server 490. Similarly, Radio Link Control (RLC) for this connection may not be in acknowledged mode (AM) . When UE 402 exits  autonomous driving mode, it may signal to terminate the connection. After establishing the connection, the server 490 may send a message to network node 438 to add UE 402 to a list of vehicles granted memory or buffer access. This message may include the vehicle ID or physical layer ID of UE 402.

[0114] In operation, when UE 402 determines a need for updated geographic data, its processing system 404 may generate a request message 452. This request message may include a first set of parameters 454, which may include an index indicating the use of this protocol, an identifier for UE 402, a travel direction indicator, a locator (e.g., road ID or road segment ID) , a request direction indicator, a hop indicator, and / or a distance indicator. The request may also include a data request 480 identifying the specific geographic data needed.

[0115]

[0021] UE 402 may broadcast the request message 452 via sidelink channels. Other autonomous vehicles in range, such as UE 420, may receive this message. The processing system 422 of UE 420 may decode the message and determine if it meets the criteria specified in the first set of parameters 454 to relay the message. These criteria may include traveling in the same direction, on the same road, and being within a specified distance of UE 402.

[0116] If UE 420 meets the criteria, its processing system 422 may generate a relay message 456. This relay message may include a second set of parameters 458, which may be modified from the first set (e.g., decrementing the hop count) , and the original data request 482. Before broadcasting this relay message, UE 420 may check if it is484 within range of network node 438. If not, it may broadcast the relay message.

[0117] This process may repeat with other UEs until one is within range of network node 438. When UE 436 determines it is within range, it may transmit the data 460 to network node 438 via, e.g., a PUCCH or PUSCH.

[0118] Network node 438 may decode data 460 and identify the requested data 452. It may then generate a response message 464 containing the requested data 468 and a fourth set of parameters 470. These parameters may include instructions for routing the response back to autonomous vehicle 402, such as a broadcast direction indicator pointing in the opposite direction of the original request.

[0119] Network node 438 may transmit response message 464 to UE 436 via PDCCH or PDSCH. UE 436 may then initiate a broadcast of a second response message 472, which may include the data 474 and a fifth set of parameters 476. This process may continue, with  autonomous vehicles like 420 relaying the response until it reaches the original requester, autonomous vehicle 402.

[0120] When autonomous vehicle 402 receives the response message 478, its processing system 404 may extract the data 460 and use it for autonomous operations. It may also broadcast a suppression message to stop further relay of this particular request or response. Response message 478 may include the data 460 and a sixth set of parameters 462.

[0121] System 400 reduces latency by proactively caching data close to where it may be needed and by using direct vehicle-to-vehicle communication to relay requests and responses when necessary. It may also select relay vehicles based on their position and direction, potentially ensuring efficient message propagation. System 400 may also include mechanisms to manage network traffic. By selecting which vehicles should relay messages and using suppression messages to stop unnecessary transmissions, it may address potential network congestion issues that could occur in multi-hop relay systems. Finally, system 400 may enable UEs to obtain geographic data for operation, even in areas with limited direct network coverage. By utilizing the positions and movements of other vehicles, it may create a network that can transmit information where needed.

[0122] FIG. 5 is a flow diagram illustrating an example process 500 that supports low-latency geographic information packet fetching for autonomous vehicles according to one or more aspects. Operations of process 500 may be performed by a network node, such as network node 438 described above with reference to FIG. 4. Example operations (also referred to as “blocks” ) of process 500 may enable network nodes as described in this disclosure to support efficient delivery of HD map data to autonomous vehicles.

[0123] At step 502, a network node receives, from server, one or more HD map packets associated with a predicted location of an autonomous vehicle. For example, network node 438 may receive HD map packets from server 490. These HD map packets may be associated with a predicted location of UE 402, which represents an autonomous vehicle.

[0124] In this context, HD map data can be organized into “tiles, ” which are discrete, manageable units of geographic information. Each tile may represent a specific area or road segment, allowing for efficient storage, transmission, and updates of map data. The size and scope of each tile may vary based on factors such as road density, update frequency requirements, or typical vehicle speeds in the area. For instance, a tile in a densely populated urban area might cover a smaller geographic area but contain more detailed information compared to a tile covering a stretch of highway. The HD map packets received by the network node may contain one or more of these tiles. Each packet may  include metadata such as the tile’s geographic coordinates, road segment IDs covered by the tile, version information, and other relevant data to help the network node efficiently manage and retrieve the information.

[0125] At step 504, the network node determines a storage duration for the one or more HD map packets based on at least one of a traffic statistic or vehicle route information. For instance, network node 438 may analyze traffic patterns and known vehicle routes to determine how long to keep specific HD map packets in memory 444. This determination may be made on a per-tile basis, allowing the network node to prioritize storage of tiles that are more likely to be needed in the near future.

[0126] In some implementations, the network node may predict a likelihood of use of the one or more HD map packets based on the at least one of the traffic statistic or vehicle route information. It may then select a duration of storing the one or more HD map packets in the memory based on this predicted likelihood. For example, network node 438 might predict that tiles covering a popular commuter route will be needed frequently during rush hours and decide to keep these tiles in memory 444 for a longer duration.

[0127] The network node may also implement a tile versioning system. When new HD map packets are received, the network node may compare the version of the newly received tiles with those already in storage. If a newer version of a tile is received, the network node may update its storage, replacing the older version with the newer one. This ensures that the autonomous vehicles always have access to the most up-to-date map information.

[0128] In some implementations, the network node may order the one or more HD map packets in the memory according to at least one of the road segment ID or a lane ID indicated in a header of the one or more HD map packets. This ordering may allow for more efficient retrieval of requested data. For example, tiles covering adjacent road segments may be stored contiguously in memory, allowing for faster access when an autonomous vehicle is moving along a particular route.

[0129] The network node may identify, in a header of each of the one or more HD map packets, a field indicating that the packet should be cached. This field may comprise one or more bits, and the network node may be configured to reserve the one or more HD map packets from immediate physical layer downlink transmission to the autonomous vehicle according to this field. This caching mechanism allows the network node to proactively store tiles that may be needed in the near future, reducing latency when the data is actually requested.

[0130] In some implementations, the network node may associate the received one or more HD map packets with the predicted location of the autonomous vehicle. This association may help in efficiently managing and retrieving the stored data. For instance, the network node may maintain an index that maps geographic areas or road segments to specific tiles, allowing for quick lookup when a request is received from an autonomous vehicle.

[0131] The tile-based approach to HD map data management offers several advantages in the context of autonomous vehicle navigation. It allows for granular updates to the map data, as only changed tiles need to be transmitted rather than entire map sets. This can significantly reduce data transmission requirements while ensuring that vehicles have the most up-to-date information for their immediate surroundings. Additionally, the tile system facilitates efficient caching and memory management at both the server and the network node, enabling them to store and transmit only the most relevant data for vehicles in their respective coverage areas.

[0132] At step 506, the network node receives, from the autonomous vehicle, a request for an HD map packet. This request includes a road segment identifier (ID) associated with the predicted location of the autonomous vehicle. For example, network node 438 may receive a request from UE 402 that includes a road segment ID corresponding to the vehicle’s current or anticipated location.

[0133] At step 508, the network node transmits an HD map packet stored in a memory to the autonomous vehicle associated with the road segment ID. For instance, network node 438 may retrieve the requested HD map packet from memory 444 and transmit it to UE 402.

[0134] In some implementations, the network node may delay transmission of the one or more HD map packets based on the determined storage duration. This delay may help optimize network resources by ensuring that data is transmitted only when it’s most likely to be needed.

[0135] In some implementations, the network node may predict a likelihood of use of the one or more HD map packets based on the at least one of the traffic statistic or vehicle route information. It may then select a duration of storing the one or more HD map packets in the memory based on this predicted likelihood. For example, network node 438 might predict that a particular HD map packet will be needed frequently in the near future based on current traffic patterns, and thus decide to keep it in memory 444 for a longer duration.

[0136] In some implementations, the memory may be shared across a plurality of autonomous vehicles. For instance, memory 444 of network node 438 might store HD map packets  that can be accessed by multiple UEs representing different autonomous vehicles in the area.

[0137] In some implementations, the network node may order the one or more HD map packets in the memory according to at least one of the road segment ID or a lane ID indicated in a header of the one or more HD map packets. This ordering may allow for more efficient retrieval of requested data. The network node may also remove one or more HD map packets from the memory based on updated location information of the autonomous vehicle. For example, as UE 402 moves away from a particular area, network node 438 might remove HD map packets related to that area from memory 444. The network node may identify, in a header of each of the one or more HD map packets, a field indicating that the packet should be cached. This field may comprise one or more bits, and the network node may be configured to reserve the one or more HD map packets from immediate physical layer downlink transmission to the autonomous vehicle according to this field.

[0138] In some implementations, the network node may associate the received one or more HD map packets with the predicted location of the autonomous vehicle. This association may help in efficiently managing and retrieving the stored data.

[0139] The network node may identify a road segment ID in a header of each of the one or more HD map packets and select the HD map packet to transmit to the autonomous vehicle by mapping the road segment ID in the request with the identified road segment ID.

[0140] In some implementations, the network node may maintain a persistent connection with the autonomous vehicle for exchanging HD map packets for at least a portion of a trip associated with the autonomous vehicle. This persistent connection may allow for more efficient data exchange throughout the vehicle’s journey.

[0141] The network node may receive one or more location updates from the autonomous vehicle via the connection and identify one or more HD map packet requirements of the autonomous vehicle associated with the one or more location updates. This proactive approach may allow the network node to anticipate and prepare for future data requests.

[0142] In some implementations, the one or more HD map packets may be received from the edge server in response to a change in a road condition associated with predicted route of the autonomous vehicle. This allows the system to quickly adapt to changing road conditions.

[0143] The request from the autonomous vehicle may further include at least one of an application identifier, a zone identifier, or a vehicle identifier. These additional identifiers  may help in more precisely determining which HD map data is needed. If the requested HD map packet is unavailable in the memory, the network node may request it from the server and then transmit it to the autonomous vehicle upon receipt. Alternatively, the network node may transmit a notification to the vehicle indicating that the requested HD map packet is unavailable.

[0144] In some implementations, the network node may receive, from the server, a list of authorized vehicle identifiers. It may then identify an identifier associated with the autonomous vehicle in the request for the HD map packet and grant access to the memory if the identified identifier maps to an authorized vehicle identifier in the received list. This helps ensure that only authorized vehicles can access the HD map data.

[0145] The network node may selectively remove one or more HD map packets from the memory based on a criterion, which may include at least one of: a least frequently used (LFU) policy, a least recently used (LRU) policy, or a reported location of the autonomous vehicle. This helps manage the memory efficiently. Finally, the network node may maintain the one or more HD map packets in the memory when determining that the one or more HD map packets will likely be transmitted to other vehicles in a same area. This approach can reduce redundant data transmissions and improve overall system efficiency.

[0146] FIG. 6 is a flow diagram illustrating an example process 600 that supports low-latency geographic information packet fetching for autonomous vehicles according to one or more aspects. Operations of process 600 may be performed by an autonomous vehicle that may include or otherwise comprise a UE, such as UE 402 described with reference to FIG. 4. Example operations of process 600 may enable autonomous vehicles as described in this disclosure to efficiently obtain and utilize HD map data for navigation and other autonomous operations.

[0147] At step 602, an autonomous vehicle receives an indication of availability of geographic data in a memory of a network node. For example, UE 402, representing or otherwise integrated with or operating at an autonomous vehicle, may receive a notification from network node 438 that certain HD map tiles are available in memory 444. This indication may be sent proactively by the network node based on the vehicle’s current location or predicted route, allowing the vehicle to prepare for upcoming data needs.

[0148] At step 604, the autonomous vehicle identifies an upcoming zone along a predicted path. For instance, processing system 404 of UE 402 may analyze its current location, speed, and planned route to determine which areas it will be entering in the near future. This step anticipates the vehicle’s data needs and ensuring smooth, uninterrupted operation.

[0149] At step 606, the autonomous vehicle transmits, to the network node, a request for geographic data associated with the upcoming zone. This request includes a road segment identifier (ID) associated with the geographic data. For example, UE 402 may send a request to network node 438 for HD map tiles covering the identified upcoming zone, including the relevant road segment ID in the request.

[0150] At step 608, the autonomous vehicle receives, from the network node, the requested geographic data. For instance, UE 402 may receive the requested HD map tiles from network node 438 via communication interface 416.

[0151] In some implementations, the geographic data comprises one or more geographic information tiles. These tiles represent discrete units of map data, each covering a specific area or road segment. The use of tiles allows for efficient data management and transmission, as only the necessary portions of the map need to be sent to the vehicle.

[0152] The autonomous vehicle may transmit location information, which is used to select which of the one or more geographic information tiles to maintain in the memory of the network node. For example, UE 402 may periodically send its current location to network node 438, allowing the node to anticipate which tiles the vehicle might need next and manage its memory 444 accordingly.

[0153] In some implementations, the request for the geographic information is transmitted via a physical uplink control channel (PUCCH) or a physical uplink shared channel (PUSCH) . This utilizes existing cellular network protocols for efficient communication between the vehicle and the network node. The request may further include at least one of an application identifier, a zone identifier, or a vehicle identifier. These additional identifiers can help the network node more precisely determine which geographic data is needed and ensure that only authorized vehicles receive sensitive map information. The road segment identifier used in the request is typically associated with a current or predicted location of the autonomous vehicle. This allows the network node to quickly locate and transmit the most relevant geographic data.

[0154] In some implementations, UE 402 may receive a notification that data associated with the requested geographic information is not available in memory 444 of network node 438. This situation may occur due to various factors, such as recent changes in road conditions that have not been updated in memory 444, or if UE 402 is entering an area with limited map coverage. In such instances, UE 402 may implement alternative strategies to maintain operation.

[0155] One approach may involve increased reliance on onboard sensors of UE 402, such as LiDAR, cameras, and radar, to generate a real-time representation of the environment. Processing system 404 of UE 402 may allocate additional resources to sensor data processing and real-time mapping. UE 402 may also adjust operational parameters, such as speed or safety margins, to account for increased uncertainty about its environment.

[0156] Another strategy may involve UE 402 requesting data from alternative sources. For example, UE 402 might attempt communication with nearby vehicles using vehicle-to-vehicle (V2V) communication protocols to exchange local map information. Alternatively, UE 402 could transmit requests to different network nodes or servers to obtain the necessary geographic data. In some implementations, UE 402 may include a backup onboard database of map data that it can utilize when high-definition data is unavailable from network node 438.

[0157] In some implementations, processing system 404 of UE 402 may determine a need for higher object detection accuracy. This determination may be triggered by various factors. For example, when UE 402 enters an urban environment with dense traffic, numerous pedestrians, and complex road layouts, the standard level of map detail may be insufficient for optimal operation. Similarly, when UE 402 approaches a construction zone or an area known for frequent changes, it may require more up-to-date and detailed information. Other scenarios that may trigger a need for higher accuracy may include weather conditions that reduce sensor effectiveness, or when UE 402 is performing certain maneuvers like merging onto a highway or navigating a complex intersection. Processing system 404 may also consider factors such as the time of day or events in the area that could affect traffic patterns.

[0158] In such case, UE 402 may transmit the request for geographic information to network node 438 in response to determining this need for higher accuracy. This request may specify the need for higher resolution map tiles, more frequent updates, or additional layers of information such as real-time traffic data or temporary road closure information. The request may also include data from the onboard sensors of UE 402 to assist network node 438 in understanding the current conditions and providing relevant data.

[0159] Upon receipt of the geographic data at step 608, UE 402 may utilize it for various operations related to autonomous vehicle functionality. This utilization of the received geographic data may be considered an extension of step 608 in process 600.

[0160] For path planning, processing system 404 may use the high-definition map data received in step 608 to calculate routes. This calculation may consider not only the road layout,  but also lane-specific information, turn restrictions, and road gradient data. This route calculation aligns with the low-latency geographic information packet fetching concept as implemented in process 600.

[0161] For obstacle avoidance, which may also be part of the autonomous operations enabled by process 600, processing system 404 may combine the detailed map data received in step 608 with real-time sensor information. This combination creates a comprehensive representation of the vehicle’s surroundings by leveraging both the proactively fetched geographic data and onboard sensor capabilities of UE 402. Further, the navigation functions of UE 402 may be further improved by the high-definition map data received through process 600. Such data may provide UE 402 with environmental information beyond what its onboard sensors alone can detect, including data about road surface conditions, speed limits, and temporary changes like construction zones.

[0162] The low-latency nature of the geographic data system implemented in process 600 may enable UE 402 to adapt to changing conditions in near real-time. For example, if a road closure occurs ahead, the process of receiving this update may follow steps similar to 602-608, allowing UE 402 to adjust its route promptly. Furthermore, the efficient data exchange facilitated by process 600 may enable anticipatory operation. UE 402 may prepare for upcoming conditions based on the geographic data received in step 608. This preparation might involve adjusting vehicle parameters or activating specific systems in anticipation of upcoming road conditions or traffic situations.

[0163] It should be appreciated that process 600 enables a geographic data system that serves as an extended sensing capability for UE 402. UE 402 can maintain a detailed understanding of its environment that would not be possible with onboard sensors alone. This enhanced environmental awareness, achieved through the low-latency geographic information packet fetching process, may contribute to the operational effectiveness of UE 402 in its autonomous driving functions.

[0164] FIG. 7 is a flow diagram illustrating an example process 700 that supports low-latency geographic information packet fetching for autonomous vehicles according to one or more aspects. Operations of process 700 may be performed by an autonomous vehicle that may include or otherwise comprise a UE, such as UE 402 described with reference to FIG. 4. Example operations of process 700 may enable autonomous vehicles as described in this disclosure to maintain a persistent connection for efficient exchange of HD map data.

[0165] At step 702, an autonomous vehicle establishes a connection to a network node for exchanging HD map packets. For example, UE 402, representing or otherwise integrated with or operating at an autonomous vehicle, may establish a connection with network node 438. This connection is configured such that packets exchanged via the connection include an application identifier field. This field may help in efficiently routing and processing the HD map packets within the network infrastructure.

[0166] At step 704, the autonomous vehicle receives one or more HD map packets via the established connection. For instance, UE 402 may receive HD map packets from network node 438 through communication interface 416. These packets may contain updated geographic information relevant to the vehicle’s current or predicted location.

[0167] At step 706, the autonomous vehicle maintains the connection for at least a portion of a trip associated with the autonomous vehicle. This step is important to the low-latency concepts discussed herein because, as easily seen, it allows for rapid exchange of geographic information without the overhead of repeatedly establishing new connections.

[0168] In some implementations, UE 402 may transmit periodic location updates via the established connection. These updates may be sent from UE 402 to network node 438, allowing the network to anticipate the vehicle’s geographic data needs and prepare relevant HD map packets in advance. This proactive approach aligns with the low-latency goals of the system. The periodic location updates transmitted by UE 402 may include at least one of a road segment identifier or a zone identifier. This information helps network node 438 to precisely determine which HD map packets are most relevant to UE 402’s current and upcoming location, further enhancing the efficiency of the data exchange.

[0169] In some implementations, processing system 404 of UE 402 may be configured to drop the connection when exiting an autonomous driving mode. This feature allows the system to conserve resources when the high-precision, low-latency HD map data is not required, such as when a human driver takes control of the vehicle.

[0170] The connection established in step 702 and maintained in step 706 may be implemented without using transmission control protocol (TCP) timeout or acknowledgment / negative acknowledgment (ACK / NACK) feedback from the autonomous vehicle. This approach reduces overhead in the communication process, contributing to the low-latency characteristics of the system. Furthermore, in some implementations, radio link control (RLC) for the connection is not in acknowledged mode (AM) . This configuration further streamlines the communication process, reducing latency in the exchange of HD map packets between UE 402 and network node 438.

[0171] The persistent connection established and maintained through process 700 enables UE 402 to quickly receive updates to geographic information as they become available. For example, if there’s a sudden change in road conditions along the vehicle’s route, network node 438 can promptly send this information to UE 402 without the delay of establishing a new connection. This persistent connection also facilitates a more predictive and anticipatory approach to geographic data distribution. Based on the periodic location updates sent by UE 402, network node 438 can preemptively send relevant HD map packets before UE 402 explicitly requests them. Proactively pushing data can further reduce latency in the autonomous vehicle’s access to critical geographic information.

[0172] Process 700 establishes and maintains a dedicated, low-overhead connection between UE 402 and network node 438, specifically optimized for the exchange of HD map data. This approach reduces latency in geographic information packet fetching, thereby enhancing the autonomous vehicle’s ability to navigate effectively in dynamic environments.

[0173] FIG. 8 is a ladder diagram illustrating an example process that supports low-latency geographic information packet fetching for autonomous vehicles according to one or more aspects. Depicted in FIG. 8 are server 890, network node 838, and UE 802. Server 890 may include or correspond to another network node as described in FIG. 4. Network node 838 may include or correspond to network node 438 as described in FIG. 4. UE 802 may include or correspond to UE 402, representing an autonomous vehicle, as described in FIG. 4.

[0174] At block 802, server 890 sends one or more HD map packets to network node 838. These packets are associated with a predicted location of UE 802. At block 804, UE 802 establishes a connection with network node 838 for exchanging HD map packets. This connection includes an application identifier field in the exchanged packets. At block 806, UE 802 transmits its current location information to network node 838. At block 808, network node 838 sends an indication of availability of geographic data to UE 802. At block 810, UE 802 transmits a request for geographic data associated with an upcoming zone to network node 838. This request includes a road segment identifier associated with the geographic data and is sent via PUCCH or PUSCH. At block 812, network node 838 transmits the requested HD map packet to UE 802. At block 814, UE 802 transmits another request for geographic information to network node 838, potentially in response to determining a need for higher accuracy. At block 816, network node 838 sends a request to server 890 for an HD map packet that is unavailable in its memory. At block 818, server 890 sends the requested HD map packet to network node  838. At block 820, network node 838 transmits the newly received HD map packet to UE 802. At block 822, UE 802 transmits periodic location updates to network node 838 via the established connection. These updates include at least one of a road segment identifier or a zone identifier. At block 824, UE 802 signals network node 838 to drop the connection, potentially due to exiting autonomous driving mode. At block 826, network node 838 acknowledges the connection termination to UE 802.

[0175] In one or more aspects, techniques for supporting vehicular operations may include additional aspects, such as any single aspect or any combination of aspects described below or in connection with one or more other processes or devices described elsewhere herein. In a first aspect, an apparatus for wireless communication at a network node, comprises: a processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system configured to: receive, from another network node, one or more HD map packets associated with a predicted location of an autonomous vehicle; receive, from the autonomous vehicle, a request for an HD map packet, wherein the request includes a road segment identifier (ID) associated with the predicted location of the autonomous vehicle; transmit an HD map packet stored in a memory to the autonomous vehicle associated with the road segment ID.

[0176] In a second aspect, in combination with the first aspect, the processing system is further configured to: determine a storage duration for the one or more HD map packets based on at least one of a traffic statistic or vehicle route information.

[0177] In a third aspect, in combination with the second aspect, the processing system is further configured to: delay transmission of the one or more HD map packets based on the determined storage duration.

[0178] In a fourth aspect, in combination with one or more of the first aspect through the third aspect, the processing system is further configured to: predict a likelihood of use of the one or more HD map packets based on the at least one of the traffic statistic or vehicle route information; and select a duration of storing the one or more HD map packets in a memory based on the predicted likelihood.

[0179] In a fifth aspect, in combination with one or more of the first aspect through the fourth aspect, the memory is shared across a plurality of autonomous vehicles.

[0180] In a sixth aspect, in combination with one or more of the first aspect through the fifth aspect, the processing system is further configured to: remove one or more HD map  packets from the memory based on updated location information of the autonomous vehicle.

[0181] In a seventh aspect, in combination with one or more of the first aspect through the sixth aspect, the processing system is further configured to: order the one or more HD map packets in the memory according to at least one of the road segment ID or a lane ID indicated in a header of the one or more HD map packets.

[0182] In an eighth aspect, in combination with one or more of the first aspect through the seventh aspect, the processing system is further configured to: identify, in a header of each of the one or more HD map packets, a field indicating that the packet should be cached.

[0183] In a ninth aspect, in combination with the eighth aspect, the field comprises one or more bits, and wherein the processing system is further configured to: reserve the one or more HD map packets from immediate physical layer downlink transmission to the autonomous vehicle according to the field.

[0184] In a tenth aspect, in combination with one or more of the first aspect through the ninth aspect, the processing system is further configured to: associate the received one or more HD map packets with the predicted location of the autonomous vehicle.

[0185] In an eleventh aspect, in combination with one or more of the first aspect through the tenth aspect, the processing system is further configured to: identify a road segment ID in a header of each of the one or more HD map packets; and select the HD map packet to transmit to the autonomous vehicle by mapping the road segment ID in the request with the identified road segment ID.

[0186] In a twelfth aspect, in combination with one or more of the first aspect through the eleventh aspect, the processing system is further configured to: maintain a persistent connection with the autonomous vehicle for exchanging HD map packets for at least a portion of a trip associated with the autonomous vehicle.

[0187] In a thirteenth aspect, in combination with the twelfth aspect, the processing system is further configured to: receive one or more location updates from the autonomous vehicle via the connection; and identify one or more HD map packet requirements of the autonomous vehicle associated with the one or more location updates.

[0188] a fourteenth aspect, in combination with one or more of the first aspect through the thirteenth aspect, the one or more HD map packets are received from the another network node in response to a change in a road condition associated with predicted route of the autonomous vehicle.

[0189] In a fifteenth aspect, in combination with one or more of the first aspect through the fourteenth aspect, the request from the autonomous vehicle further includes at least one of an application identifier, a zone identifier, or a vehicle identifier.

[0190] In a sixteenth aspect, in combination with one or more of the first aspect through the fifteenth aspect, the processing system is further configured to: identify the requested HD map packet as unavailable in the memory; request, from the another network node, the unavailable HD map packet; and transmit the unavailable HD map packet to the autonomous vehicle.

[0191] In a seventeenth aspect, in combination with one or more of the first aspect through the sixteenth aspect, the processing system is further configured to: identify that the requested HD map packet as unavailable in the memory; and transmit a notification to the vehicle indicating that the requested HD map packet is unavailable.

[0192] In an eighteenth aspect, in combination with one or more of the first aspect through the seventeenth aspect, the processing system is further configured to: receive, from the another network node, a list of authorized vehicle identifiers; identify an identifier associated with the autonomous vehicle in the request for the HD map packet; grant access to the memory if the identified identifier maps to an authorized vehicle identifier in the received list.

[0193] In a nineteenth aspect, in combination with one or more of the first aspect through the eighteenth aspect, the processing system is further configured to: selectively remove one or more HD map packets from the memory based on a criterion, wherein the criterion includes at least one of: a least frequently used (LFU) policy; a least recently used (LRU) policy; or a reported location of the autonomous vehicle.

[0194] In a twentieth aspect, in combination with one or more of the first aspect through the nineteenth aspect, the processing system is further configured to: maintain the one or more HD map packets in the memory when determining that the one or more HD map packets will likely be transmitted to other vehicles in a same area.

[0195] In a twenty-first aspect, an apparatus for wireless communication at an autonomous vehicle comprising: a processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system configured to: receive an indication of availability of geographic data in a memory of a network node; identify an upcoming zone along a predicted path of the autonomous vehicle; transmit, to the network node, a request for geographic data associated with the upcoming zone, wherein the request includes a road segment identifier (ID) associated  with the geographic data; and receive, from the network node, the requested geographic data.

[0196] In a twenty-second aspect, in combination with the twenty-first aspect, the geographic data comprises one or more geographic information tiles.

[0197] In a twenty-third aspect, in combination with the twenty-second aspect, the processing system is further configured to: transmit location information, wherein the location information is used to select which of the one or more geographic information tiles to maintain in the memory.

[0198] In a twenty-fourth aspect, in combination with one or more of the twenty-first aspect through the twenty-third aspect, the request for the geographic information is transmitted via a physical uplink control channel (PUCCH) or a physical uplink shared channel (PUSCH) .

[0199] In a twenty-fifth aspect, in combination with one or more of the twenty-first aspect through the twenty-fourth aspect, the request further includes at least one of an application identifier, a zone identifier, or a vehicle identifier.

[0200] In a twenty-sixth aspect, in combination with one or more of the twenty-first aspect through the twenty-fifth aspect, the processing system is further configured to: receive a notification that data associated with the requested geographic information is not available in the memory.

[0201] In a twenty-seventh aspect, in combination with one or more of the twenty-first aspect through the twenty-sixth aspect, the road segment identifier is associated with a current or predicted location of the autonomous vehicle.

[0202] In a twenty-eighth aspect, in combination with one or more of the twenty-first aspect through the twenty-seventh aspect, the processing system is further configured to: determine a need for higher object detection accuracy; and transmit the request for the geographic information in response to determining the need for higher object detection accuracy.

[0203] In a twenty-ninth aspect, an apparatus for wireless communication at an autonomous vehicle comprising: a processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system configured to: establish a connection to a network node for exchanging HD map packets, wherein packets exchanged via the connection include an application identifier field; receive one or more HD map packets via the connection; and maintain the connection for at least a portion of a trip associated with the autonomous vehicle.

[0204] In a thirtieth aspect, in combination with the twenty-ninth aspect, the processing system is further configured to: transmit periodic location updates via the connection.

[0205] [In a thirty-first aspect, in combination with the thirtieth aspect, the periodic location updates include at least one of a road segment identifier or a zone identifier.

[0206] In a thirty-second aspect, in combination with one or more of the twenty-ninth aspect through the thirty-first aspect, the processing system is further configured to: drop the connection when exiting an autonomous driving mode.

[0207] In a thirty-third aspect, in combination with one or more of the twenty-ninth aspect through the thirty-second aspect, the dedicated connection is maintained without using transmission control protocol (TCP) timeout or acknowledgment / negative acknowledgment (ACK / NACK) feedback from the autonomous vehicle.

[0208] In a thirty-fourth aspect, in combination with one or more of the twenty-ninth aspect through the thirty-third aspect, radio link control (RLC) for the connection is not in acknowledged mode (AM) .

[0209] In a thirty-fifth aspect, a method for wireless communication at a network node, comprising: receiving, from another network node, one or more HD map packets associated with a predicted location of an autonomous vehicle; receiving, from the autonomous vehicle, a request for an HD map packet, wherein the request includes a road segment identifier (ID) associated with the predicted location of the autonomous vehicle; transmitting an HD map packet stored in a memory to the autonomous vehicle associated with the road segment ID.

[0210] In a thirty-sixth aspect, in combination with the thirty-fifth aspect, the method further comprises: determining a storage duration for the one or more HD map packets based on at least one of a traffic statistic or vehicle route information.

[0211] In a thirty-seventh aspect, in combination with the thirty-sixth aspect, the method further comprises: delaying transmission of the one or more HD map packets based on the determined storage duration.

[0212] In a thirty-eighth aspect, in combination with one or more of the thirty-fifth aspect through the thirty-seventh aspect, the method further comprises: predicting a likelihood of use of the one or more HD map packets based on the at least one of the traffic statistic or vehicle route information; and selecting a duration of storing the one or more HD map packets in a memory based on the predicted likelihood.

[0213] In a thirty-ninth aspect, in combination with one or more of the thirty-fifth aspect through the thirty-eighth aspect, the memory is shared across a plurality of autonomous vehicles.

[0214] In a fortieth aspect, in combination with one or more of the thirty-fifth aspect through the thirty-ninth aspect, the method further comprises: removing one or more HD map packets from the memory based on updated location information of the autonomous vehicle.

[0215] In a forty-first aspect, in combination with one or more of the thirty-fifth aspect through the fortieth aspect, the method further comprises: ordering the one or more HD map packets in the memory according to at least one of the road segment ID or a lane ID indicated in a header of the one or more HD map packets.

[0216] In a forty-second aspect, in combination with one or more of the thirty-fifth aspect through the forty-first aspect, the method further comprises: identifying, in a header of each of the one or more HD map packets, a field indicating that the packet should be cached.

[0217] In a forty-third aspect, in combination with the forty-second aspect, the field comprises one or more bits, and the method further comprises: reserving the one or more HD map packets from immediate physical layer downlink transmission to the autonomous vehicle according to the field.

[0218] In a forty-fourth aspect, in combination with one or more of the thirty-fifth aspect through the forty-third aspect, the method further comprises: associating the received one or more HD map packets with the predicted location of the autonomous vehicle.

[0219] In a forty-fifth aspect, in combination with one or more of the thirty-fifth aspect through the forty-fourth aspect, the method further comprises: identifying a road segment ID in a header of each of the one or more HD map packets; and selecting the HD map packet to transmit to the autonomous vehicle by mapping the road segment ID in the request with the identified road segment ID.

[0220] In a forty-sixth aspect, in combination with one or more of the thirty-fifth aspect through the forty-fifth aspect, the method further comprises: maintaining a persistent connection with the autonomous vehicle for exchanging HD map packets for at least a portion of a trip associated with the autonomous vehicle.

[0221] In a forty-seventh aspect, in combination with the forty-sixth aspect, the method further comprises: receiving one or more location updates from the autonomous vehicle via the connection; and identifying one or more HD map packet requirements of the autonomous vehicle associated with the one or more location updates.

[0222] In a forty-eighth aspect, in combination with one or more of the thirty-fifth aspect through the forty-seventh aspect, the one or more HD map packets are received from the another  network node in response to a change in a road condition associated with predicted route of the autonomous vehicle.

[0223] In a forty-ninth aspect, in combination with one or more of the thirty-fifth aspect through the forty-eighth aspect, the request from the autonomous vehicle further includes at least one of an application identifier, a zone identifier, or a vehicle identifier.

[0224] In a fiftieth aspect, in combination with one or more of the thirty-fifth aspect through the forty-ninth aspect, the method further comprises: identifying the requested HD map packet as unavailable in the memory; requesting, from the another network node, the unavailable HD map packet; and transmitting the unavailable HD map packet to the autonomous vehicle.

[0225] In a fifty-first aspect, in combination with one or more of the thirty-fifth aspect through the fiftieth aspect, the method further comprises: identifying that the requested HD map packet as unavailable in the memory; and transmitting a notification to the vehicle indicating that the requested HD map packet is unavailable.

[0226] In a fifty-second aspect, in combination with one or more of the thirty-fifth aspect through the fifty-first aspect, the method further comprises: receiving, from the another network node, a list of authorized vehicle identifiers; identifying an identifier associated with the autonomous vehicle in the request for the HD map packet; granting access to the memory if the identified identifier maps to an authorized vehicle identifier in the received list.

[0227] In a fifty-third aspect, in combination with one or more of the thirty-fifth aspect through the fifty-second aspect, the method further comprises: selectively removing one or more HD map packets from the memory based on a criterion, wherein the criterion includes at least one of: a least frequently used (LFU) policy; a least recently used (LRU) policy; or a reported location of the autonomous vehicle.

[0228] In a fifty-fourth aspect, in combination with one or more of the thirty-fifth aspect through the fifty-third aspect, the method further comprises: maintaining the one or more HD map packets in the memory when determining that the one or more HD map packets will likely be transmitted to other vehicles in a same area.

[0229] In a fifty-fifth aspect, a method for wireless communication at an autonomous vehicle, comprising: receiving an indication of availability of geographic data in a memory of a network node; identifying an upcoming zone along a predicted path of the autonomous vehicle; transmitting, to the network node, a request for geographic data associated with the upcoming zone, wherein the request includes a road segment identifier (ID) associated  with the geographic data; and receiving, from the network node, the requested geographic data.

[0230] In a fifty-sixth aspect, in combination with the fifty-fifth aspect, the geographic data comprises one or more geographic information tiles.

[0231] In a fifty-seventh aspect, in combination with the fifty-sixth aspect, the method further comprises: transmitting location information, wherein the location information is used to select which of the one or more geographic information tiles to maintain in the memory.

[0232] In a fifty-eighth aspect, in combination with one or more of the fifty-fifth aspect through the fifty-seventh aspect, the request for the geographic information is transmitted via a physical uplink control channel (PUCCH) or a physical uplink shared channel (PUSCH) .

[0233] In a fifty-ninth aspect, in combination with one or more of the fifty-fifth aspect through the fifty-eighth aspect, the request further includes at least one of an application identifier, a zone identifier, or a vehicle identifier.

[0234] In a sixtieth aspect, in combination with one or more of the fifty-fifth aspect through the fifty-ninth aspect, the method further comprises: receiving a notification that data associated with the requested geographic information is not available in the memory.

[0235] In a sixty-first aspect, in combination with one or more of the fifty-fifth aspect through the sixtieth aspect, the road segment identifier is associated with a current or predicted location of the autonomous vehicle.

[0236] In a sixty-second aspect, in combination with one or more of the fifty-fifth aspect through the sixty-first aspect, the method further comprises: determining a need for higher object detection accuracy; and transmitting the request for the geographic information in response to determining the need for higher object detection accuracy.

[0237] In a sixty-third aspect, a method for wireless communication at an autonomous vehicle, comprising: establishing a connection to a network node for exchanging HD map packets, wherein packets exchanged via the connection include an application identifier field; receiving one or more HD map packets via the connection; and maintaining the connection for at least a portion of a trip associated with the autonomous vehicle.

[0238] In a sixty-fourth aspect, in combination with the sixty-third aspect, the method further comprises: transmitting periodic location updates via the connection.

[0239] In a sixty-fifth aspect, in combination with the sixty-fourth aspect, the periodic location updates include at least one of a road segment identifier or a zone identifier.

[0240] In a sixty-sixth aspect, in combination with one or more of the sixty-third aspect through the sixty-fifth aspect, the method further comprises: dropping the connection when exiting an autonomous driving mode.

[0241] In a sixty-seventh aspect, in combination with one or more of the sixty-third aspect through the sixty-sixth aspect, the dedicated connection is maintained without using transmission control protocol (TCP) timeout or acknowledgment / negative acknowledgment (ACK / NACK) feedback from the autonomous vehicle.

[0242] In a sixty-eighth aspect, in combination with one or more of the sixty-third aspect through the sixty-seventh aspect, radio link control (RLC) for the connection is not in acknowledged mode (AM) .

[0243] In a sixty-ninth aspect, an apparatus for wireless communication at a network node, comprising: means for receiving, from another network node, one or more HD map packets associated with a predicted location of an autonomous vehicle; means for determining a storage duration for the one or more HD map packets based on at least one of a traffic statistic or vehicle route information; means for receiving, from the autonomous vehicle, a request for an HD map packet, wherein the request includes a road segment identifier (ID) associated with the predicted location of the autonomous vehicle; means for transmitting an HD map packet stored in a memory to the autonomous vehicle associated with the road segment ID.

[0244] In a seventieth aspect, a non-transitory computer-readable medium storing computer-executable instructions that, when executed by a processor, cause the processor to perform operations comprising: receiving, from another network node, one or more HD map packets associated with a predicted location of an autonomous vehicle; determining a storage duration for the one or more HD map packets based on at least one of a traffic statistic or vehicle route information; receiving, from the autonomous vehicle, a request for an HD map packet, wherein the request includes a road segment identifier (ID) associated with the predicted location of the autonomous vehicle; transmitting an HD map packet stored in a memory to the autonomous vehicle associated with the road segment ID.

[0245] In a seventy-first aspect, a network node, comprising: at least one transceiver; at least one memory including instructions; and one or more processors, individually or collectively, configured to: receive, from another network node, one or more HD map packets associated with a predicted location of an autonomous vehicle; determine a storage duration for the one or more HD map packets based on at least one of a traffic statistic or  vehicle route information; receive, from the autonomous vehicle, a request for an HD map packet, wherein the request includes a road segment identifier (ID) associated with the predicted location of the autonomous vehicle; transmit an HD map packet stored in a memory to the autonomous vehicle associated with the road segment ID.

[0246] In a seventy-second aspect, an apparatus for wireless communication at an autonomous vehicle, comprising: means for receiving an indication of availability of geographic data in a memory of a network node; means for identifying an upcoming zone along a predicted path of the autonomous vehicle; means for transmitting, to the network node, a request for geographic data associated with the upcoming zone, wherein the request includes a road segment identifier (ID) associated with the geographic data; and means for receiving, from the network node, the requested geographic data.

[0247] In a seventy-third aspect, a non-transitory computer-readable medium storing computer-executable instructions that, when executed by a processor, cause the processor to perform operations comprising: receiving an indication of availability of geographic data in a memory of a network node; identifying an upcoming zone along a predicted path of the autonomous vehicle; transmitting, to the network node, a request for geographic data associated with the upcoming zone, wherein the request includes a road segment identifier (ID) associated with the geographic data; and receiving, from the network node, the requested geographic data.

[0248] In a seventy-fourth aspect, an autonomous vehicle, comprising: at least one transceiver; at least one memory including instructions; and one or more processors, individually or collectively, configured to: receive an indication of availability of geographic data in a memory of a network node; identify an upcoming zone along a predicted path of the autonomous vehicle; transmit, to the network node, a request for geographic data associated with the upcoming zone, wherein the request includes a road segment identifier (ID) associated with the geographic data; and receive, from the network node, the requested geographic data.

[0249] In a seventy-fifth aspect, an apparatus for wireless communication at an autonomous vehicle, comprising: means for establishing a connection to a network node for exchanging HD map packets, wherein packets exchanged via the connection include an application identifier field; means for receiving one or more HD map packets via the connection; and means for maintaining the connection for at least a portion of a trip associated with the autonomous vehicle.

[0250] In a seventy-sixth aspect, a non-transitory computer-readable medium storing computer-executable instructions that, when executed by a processor, cause the processor to perform operations comprising: establishing a connection to a network node for exchanging HD map packets, wherein packets exchanged via the connection include an application identifier field; receiving one or more HD map packets via the connection; and maintaining the connection for at least a portion of a trip associated with the autonomous vehicle.

[0251] In a seventy-seventh aspect, an autonomous vehicle, comprising: at least one transceiver; at least one memory including instructions; and one or more processors, individually or collectively, configured to: establish a connection to a network node for exchanging HD map packets, wherein packets exchanged via the connection include an application identifier field; receive one or more HD map packets via the connection; and maintain the connection for at least a portion of a trip associated with the autonomous vehicle.

[0252] Components, the functional blocks, and the modules described herein with respect to FIGs. 1-4 include processors, electronics devices, hardware devices, electronics components, logical circuits, memories, software codes, firmware codes, among other examples, or any combination thereof. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, application, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, and / or functions, among other examples, whether referred to as software, firmware, middleware, microcode, hardware description language or otherwise. In addition, features discussed herein may be implemented via specialized processor circuitry, via executable instructions, or combinations thereof.

[0253] Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure. Skilled  artisans will also readily recognize that the order or combination of components, methods, or interactions that are described herein are merely examples and that the components, methods, or interactions of the various aspects of the present disclosure may be combined or performed in ways other than those illustrated and described herein.

[0254] The various illustrative logics, logical blocks, modules, circuits and algorithm processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. The interchangeability of hardware and software has been described generally, in terms of functionality, and illustrated in the various illustrative components, blocks, modules, circuits and processes described above. Whether such functionality is implemented in hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0255] The hardware and data processing apparatus used to implement the various illustrative logics, logical blocks, modules and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose single-or multi-chip processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, or, any conventional processor, controller, microcontroller, or state machine. In some implementations, a processor may be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some implementations, particular processes and methods may be performed by circuitry that is specific to a given function.

[0256] In one or more aspects, the functions described may be implemented in hardware, digital electronic circuitry, computer software, firmware, including the structures disclosed in this specification and their structural equivalents thereof, or in any combination thereof. Implementations of the subject matter described in this specification also may be implemented as one or more computer programs, that is one or more modules of computer program instructions, encoded on a computer storage media for execution by, or to control the operation of, data processing apparatus.

[0257] If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. The processes of a method or algorithm disclosed herein may be implemented in a processor-executable software module which may reside on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that may be enabled to transfer a computer program from one place to another. A storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may include random-access memory (RAM) , read-only memory (ROM) , electrically erasable programmable read-only memory (EEPROM) , CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Also, any connection may be properly termed a computer-readable medium. Disk and disc, as used herein, includes compact disc (CD) , laser disc, optical disc, digital versatile disc (DVD) , floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and instructions on a machine readable medium and computer-readable medium, which may be incorporated into a computer program product.

[0258] Various modifications to the implementations described in this disclosure may be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to some other implementations without departing from the spirit or scope of this disclosure. Thus, the claims are not intended to be limited to the implementations shown herein, but are to be accorded the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.

[0259] Certain features that are described in this specification in the context of separate implementations also may be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation also may be implemented in multiple implementations separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination may in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0260] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Further, the drawings may schematically depict one more example processes in the form of a flow diagram. However, other operations that are not depicted may be incorporated in the example processes that are schematically illustrated. For example, one or more additional operations may be performed before, after, simultaneously, or between any of the illustrated operations. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products. Additionally, some other implementations are within the scope of the following claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve desirable results.

[0261] While aspects and implementations are described in this application by illustration to some examples, those skilled in the art will understand that additional implementations and use cases may come about in many different arrangements and scenarios. Innovations described herein may be implemented across many differing platform types, devices, systems, shapes, sizes, packaging arrangements. For example, implementations or uses may come about via integrated chip implementations or other non-module-component based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail devices or purchasing devices, medical devices, AI-enabled devices, etc. ) . While some examples may or may not be specifically directed to use cases or applications, a wide assortment of applicability of described innovations may occur.

[0262] Implementations may 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 described aspects. In some practical settings, devices incorporating described aspects and features may also necessarily include additional components and features for implementation and practice of claimed and described aspects. It is intended that innovations described herein may be practiced in a wide variety of implementations, including both large devices or  small devices, chip-level components, multi-component systems (e.g., radio frequency (RF) -chain, communication interface, processor) , distributed arrangements, end-user devices, etc. of varying sizes, shapes, and constitution.

[0263] In the following description, numerous specific details are set forth, such as examples of specific components, circuits, and processes to provide a thorough understanding of the present disclosure. The term “coupled” as used herein means connected directly to or connected through one or more intervening components or circuits. Also, in the following description and for purposes of explanation, specific nomenclature is set forth to provide a thorough understanding of the present disclosure. However, it will be apparent to one skilled in the art that these specific details may not be required to practice the teachings disclosed herein. In other instances, well known circuits and devices are shown in block diagram form to avoid obscuring teachings of the present disclosure.

[0264] Some portions of the detailed descriptions which follow are presented in terms of procedures, logic blocks, processing, and other symbolic representations of operations on data bits within a computer memory. In the present disclosure, a procedure, logic block, process, or the like, is conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, although not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system.

[0265] In the figures, a single block may be described as performing a function or functions. The function or functions performed by that block may be performed in a single component or across multiple components, and / or may be performed using hardware, software, or a combination of hardware and software. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps are described below generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure. Also, the example devices may include components other than those shown, including well-known components such as a processor, memory, and the like.

[0266] Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present application, discussions utilizing the terms such as “accessing, ” “receiving, ” “sending, ” “using, ” “selecting, ” “determining, ” “normalizing, ” “multiplying, ” “averaging, ” “monitoring, ” “comparing, ” “applying, ” “updating, ” “measuring, ” “deriving, ” “settling, ” “generating” or the like, refer to the actions and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system’s registers and memories into other data similarly represented as physical quantities within the computer system’s registers, memories, or other such information storage, transmission, or display devices.

[0267] The terms “device” and “apparatus” are not limited to one or a specific number of physical objects (such as one smartphone, one camera controller, one processing system, and so on) . As used herein, a device may be any electronic device with one or more parts that may implement at least some portions of the disclosure. While the below description and examples use the term “device” to describe various aspects of the disclosure, the term “device” is not limited to a specific configuration, type, or number of objects. As used herein, an apparatus may include a device or a portion of the device for performing the described operations.

[0268] As used herein, including in the claims, the term “or, ” when used in a list of two or more items, means that any one of the listed items may be employed by itself, or any combination of two or more of the listed items may be employed. For example, if a composition is described as containing components A, B, or C, the composition may contain A alone; B alone; C alone; A and B in combination; A and C in combination; B and C in combination; or A, B, and C in combination.

[0269] Also, as used herein, including in the claims, “or” as used in a list of items prefaced by “at least one of” indicates a disjunctive list such that, for example, a list of “at least one of A, B, or C” means A or B or C or AB or AC or BC or ABC (that is A and B and C) or any of these in any combination thereof.

[0270] Also, as used herein, the term “substantially” is defined as largely but not necessarily wholly what is specified (and includes what is specified; for example, substantially 90 degrees includes 90 degrees and substantially parallel includes parallel) , as understood by a person of ordinary skill in the art. In any disclosed implementations, the term “substantially” may be substituted with “within [apercentage] of” what is specified, where the percentage includes . 1, 1, 5, or 10 percent.

[0271] Also, as used herein, relative terms, unless otherwise specified, may be understood to be relative to a reference by a certain amount. For example, terms such as “higher” or “lower” or “more” or “less” may be understood as higher, lower, more, or less than a reference value by a threshold amount.

[0272] The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1.An apparatus for wireless communication at a network node, comprising:a processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system configured to:receive, from another network node, one or more HD map packets associated with a predicted location of an autonomous vehicle;receive, from the autonomous vehicle, a request for an HD map packet, wherein the request includes a road segment identifier (ID) associated with the predicted location of the autonomous vehicle;transmit an HD map packet stored in a memory to the autonomous vehicle associated with the road segment ID.2.The apparatus of claim 1, wherein the processing system is further configured to: determine a storage duration for the one or more HD map packets based on at least one of a traffic statistic or vehicle route information.3.The apparatus of claim 2, wherein the processing system is further configured to:delay transmission of the one or more HD map packets based on the determined storage duration.4.The apparatus of claim 1, wherein the processing system is further configured to:predict a likelihood of use of the one or more HD map packets based on the at least one of the traffic statistic or vehicle route information; andselect a duration of storing the one or more HD map packets in a memory based on the predicted likelihood.5.The apparatus of claim 1, wherein the memory is shared across a plurality of autonomous vehicles.6.The apparatus of claim 1, wherein the processing system is further configured to:remove one or more HD map packets from the memory based on updated location information of the autonomous vehicle.7.The apparatus of claim 1, wherein the processing system is further configured to:order the one or more HD map packets in the memory according to at least one of the road segment ID or a lane ID indicated in a header of the one or more HD map packets.8.The apparatus of claim 1, wherein the processing system is further configured to:identify, in a header of each of the one or more HD map packets, a field indicating that the packet should be cached.9.The apparatus of claim 8, wherein the field comprises one or more bits, and wherein the processing system is further configured to:reserve the one or more HD map packets from immediate physical layer downlink transmission to the autonomous vehicle according to the field.10.The apparatus of claim 1, wherein the processing system is further configured to:associate the received one or more HD map packets with the predicted location of the autonomous vehicle.11.The apparatus of claim 1, wherein the processing system is further configured to:identify a road segment ID in a header of each of the one or more HD map packets; andselect the HD map packet to transmit to the autonomous vehicle by mapping the road segment ID in the request with the identified road segment ID.12.The apparatus of claim 1, wherein the processing system is further configured to:maintain a persistent connection with the autonomous vehicle for exchanging HD map packets for at least a portion of a trip associated with the autonomous vehicle.13.The apparatus of claim 12, wherein the processing system is further configured to:receive one or more location updates from the autonomous vehicle via the connection; andidentify one or more HD map packet requirements of the autonomous vehicle associated with the one or more location updates.14.The apparatus of claim 1, wherein the one or more HD map packets are received from the another network node in response to a change in a road condition associated with predicted route of the autonomous vehicle.15.The apparatus of claim 1, wherein the request from the autonomous vehicle further includes at least one of an application identifier, a zone identifier, or a vehicle identifier.16.The apparatus of claim 1, wherein the processing system is further configured to:identify the requested HD map packet as unavailable in the memory;request, from the another network node, the unavailable HD map packet; andtransmit the unavailable HD map packet to the autonomous vehicle.17.The apparatus of claim 1, wherein the processing system is further configured to:identify that the requested HD map packet as unavailable in the memory; andtransmit a notification to the vehicle indicating that the requested HD map packet is unavailable.18.The apparatus of claim 1, wherein the processing system is further configured to:receive, from the another network node, a list of authorized vehicle identifiers;identify an identifier associated with the autonomous vehicle in the request for the HD map packet;grant access to the memory if the identified identifier maps to an authorized vehicle identifier in the received list.19.The apparatus of claim 1, wherein the processing system is further configured to:selectively remove one or more HD map packets from the memory based on a criterion, wherein the criterion includes at least one of:a least frequently used (LFU) policy;a least recently used (LRU) policy; ora reported location of the autonomous vehicle.20.The apparatus of claim 1, wherein the processing system is further configured to:maintain the one or more HD map packets in the memory when determining that the one or more HD map packets will likely be transmitted to other vehicles in a same area.21.An apparatus for wireless communication at an autonomous vehicle comprising:a processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system configured to:receive an indication of availability of geographic data in a memory of a network node;identify an upcoming zone along a predicted path of the autonomous vehicle;transmit, to the network node, a request for geographic data associated with the upcoming zone, wherein the request includes a road segment identifier (ID) associated with the geographic data; andreceive, from the network node, the requested geographic data.22.The apparatus of claim 21, wherein the geographic data comprises one or more geographic information tiles.23.The apparatus of claim 22, wherein the processing system is further configured to:transmit location information, wherein the location information is used to select which of the one or more geographic information tiles to maintain in the memory.24.The apparatus of claim 21, wherein the request for the geographic information is transmitted via a physical uplink control channel (PUCCH) or a physical uplink shared channel (PUSCH) .25.The apparatus of claim 21, wherein the request further includes at least one of an application identifier, a zone identifier, or a vehicle identifier.26.The apparatus of claim 21, wherein the processing system is further configured to:receive a notification that data associated with the requested geographic information is not available in the memory.27.The apparatus of claim 21, wherein the road segment identifier is associated with a current or predicted location of the autonomous vehicle.28.The apparatus of claim 21, wherein the processing system is further configured to:determine a need for higher object detection accuracy; andtransmit the request for the geographic information in response to determining the need for higher object detection accuracy.29.An apparatus for wireless communication at an autonomous vehicle comprising:a processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system configured to:establish a connection to a network node for exchanging HD map packets, wherein packets exchanged via the connection include an application identifier field;receive one or more HD map packets via the connection; andmaintain the connection for at least a portion of a trip associated with the autonomous vehicle.30.The apparatus of claim 29, wherein the processing system is further configured to:transmit periodic location updates via the connection.31.The apparatus of claim 30, wherein the periodic location updates include at least one of a road segment identifier or a zone identifier.32.The apparatus of claim 29, wherein the processing system is further configured to:drop the connection when exiting an autonomous driving mode.33.The apparatus of claim 29, wherein the dedicated connection is maintained without using transmission control protocol (TCP) timeout or acknowledgment / negative acknowledgment (ACK / NACK) feedback from the autonomous vehicle.34.The apparatus of claim 29, wherein radio link control (RLC) for the connection is not in acknowledged mode (AM) .

Images