Systems and methods for autonomous vehicle communication

By leveraging heterogeneous infrastructure and OWC technology, the problems of high cost and latency in wireless communication for autonomous vehicles have been solved, enabling efficient data transmission and real-time service access, thus ensuring the continuity and real-time nature of autonomous vehicle services.

CN113287330BActive Publication Date: 2025-11-25APPLE INC
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202080007680.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2019-03-29
Filing Date
2020-03-27
Publication Date
2025-11-25
Estimated Expiration
2040-03-27

AI Technical Summary

Technical Problem

Modern vehicles face high costs and latency issues in wireless communication during autonomous driving, especially in non-line-of-sight communication and outdoor environments. Existing wireless communication protocols cannot meet the demand for large amounts of data transmission, leading to service interruptions and a decline in real-time service quality.

Method used

By employing heterogeneous infrastructure and combining optical wireless communication (OWC) and machine learning technologies, it provides a multi-access edge computing and quality of service system, enabling efficient data transmission and real-time service access between vehicles and data sources. Through seamless connectivity between roadside devices and the cloud, it dynamically adjusts network configuration to adapt to vehicle mobility.

Benefits of technology

It improves the communication capabilities between vehicles and data sources, reduces communication latency and costs, ensures the continuity and real-time nature of autonomous vehicle services, and enhances support for real-time services.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113287330B_ABST
    Figure CN113287330B_ABST
Patent Text Reader

Abstract

The subject matter described herein presents various technical solutions to technical problems faced by autonomous vehicles (e.g., fully autonomous vehicles and semi-autonomous vehicles). To address the technical problem of wireless communication cost and latency, heterogeneous roadside infrastructure can be used to improve the ability of vehicles to communicate with data sources. To address the technical problem of vehicle services being interrupted due to sudden loss of connectivity, a quality of service system provides the ability to determine and share quality of service information such as location-based information, maps, interference data, and other quality of service information. To address the technical problem of large amounts of data upload and download between autonomous vehicles and cloud-based data services, optical wireless communication (OWC) provides higher data throughput and lower complexity and can be beneficial for short-range high-mobility wireless communication.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Some aspects of this disclosure relate to vehicle navigation. More specifically, some aspects relate to vehicle data communication during vehicle navigation. Background Technology

[0002] Modern vehicles can upload or download vast amounts of data. For example, autonomous vehicles can continuously upload data to the cloud (e.g., data centers, cloud computing environments, and other cloud-based data environments), which can be used to refine autonomous driving algorithms based on individual data points or on a fleet of test vehicles. Vehicles can also continuously download data, such as real-time surrounding vehicle data, map downloads, media downloads, or other data. While some wireless communication channels (e.g., 5G) offer high data bandwidth, these channels typically require expensive vehicle data plans. Other wireless communication protocols (such as Wi-Fi and WiGig technologies) provide data communication for large amounts of data but have significant bandwidth (e.g., bit / second throughput) constraints. The performance of each of these communication protocols can be further degraded, for example, due to non-line-of-sight communication and outdoor environmental challenges. An improved solution for transmitting vehicle data is needed. Attached Figure Description

[0003] Figure 1 It is a diagram depicting an exemplary heterogeneous infrastructure based on some aspects.

[0004] Figure 2 It is a diagram depicting a content distribution system based on some aspects of heterogeneous infrastructure.

[0005] Figure 3 It is a diagram depicting the first vehicle service access process based on some aspects.

[0006] Figure 4 It is a diagram depicting the second vehicle service access process based on some aspects.

[0007] Figure 5 It is a diagram depicting the access process for third-party vehicle services based on some aspects.

[0008] Figure 6 It is a diagram depicting a vehicle communication quality of service (QoS) system based on some aspects.

[0009] Figure 7 It is a diagram that depicts the reconfiguration of a system based on some aspects of a dynamic network.

[0010] Figure 8 It is a diagram depicting the deployment of optical wireless communication (OWC) based on some aspects.

[0011] Figure 9 It is a diagram depicting the collimation OWC configuration based on some aspects.

[0012] Figure 10 It is a diagram depicting an optical front-end design customized according to some aspects of OWC.

[0013] Figure 11A and Figure 11B It is a diagram based on the performance of a customized optical front end in several aspects.

[0014] Figure 12 It is a block diagram based on some aspects of radio architecture.

[0015] Figure 13 It shows the use of some aspects in Figure 12 The front-end module circuitry used in the radio architecture.

[0016] Figure 14 It shows the use of some aspects in Figure 12 The radio IC circuitry used in the radio architecture.

[0017] Figure 15 It shows the use of some aspects in Figure 12 The baseband processing circuitry used in the radio architecture.

[0018] Figure 16 A block diagram of an exemplary machine for performing a method is shown, according to some aspects.

[0019] Figure 17 An example of a user equipment (UE) is shown, based on some aspects.

[0020] Figure 18 Exemplary UEs and base stations (BSs) are shown according to some aspects, such as evolved Node B (eNB) or next-generation Node B (gNB).

[0021] To identify any discussion of a particular element or action, one or more of the most significant digits in the reference numerals refer to the drawing number in which the element was first introduced. Furthermore, similar digits denote similar parts. Detailed Implementation

[0022] This article presents various technical solutions to the technical challenges faced by autonomous vehicles (e.g., fully autonomous and semi-autonomous vehicles). To address the technical challenges of wireless communication costs and latency, heterogeneous roadside infrastructure can be used to enhance the ability of vehicles to communicate with data sources. To address the technical challenges of vehicle service interruptions due to sudden connection loss, Quality of Service (QoS) systems provide the ability to determine and share QoS information, such as location-based information, maps, interference data, and other QoS information. To address the technical challenges of large-scale data uploads and downloads between autonomous vehicles and cloud-based data services, Optical Wireless Communication (OWC) offers higher data throughput and lower complexity, and may be beneficial for short-range, high-mobility wireless communication.

[0023] The following description includes systems, methods, techniques, instruction sequences, and computer program products embodying exemplary aspects of this disclosure. In the following description, numerous specific details are shown for illustrative purposes to provide an understanding of various aspects of the inventive subject matter. However, it will be apparent to those skilled in the art that the inventive subject matter can be practiced without these specific details. In general, well-known examples of instructions, protocols, structures, and techniques are not necessarily shown in detail.

[0024] Figure 1 This is a diagram depicting an exemplary heterogeneous infrastructure 100 according to several aspects. To support the increasing number of autonomous vehicles, improved services are needed to be provided to these vehicles. These services may rely on communication between the vehicle and data sources such as the cloud. These services may include real-time services such as smart parking, over-the-air (OTA) updates for vehicle software, firmware, and security patches, real-time location-specific traffic and weather alerts, entertainment and work services for passengers, downloading and updating high-definition (HD) maps (e.g., high-level 3D navigation details) during driving, and others. The continuous reliance on the cloud for these services (including, for example, wide area networks (WANs), the internet, and other cloud-based data connections) increases network costs for operators. Furthermore, current wireless operators may not have sufficient bandwidth for real-time services, where even 5G access typically involves several sequential communication paths (e.g., communication hops) between the vehicle and the cloud, each adding latency.

[0025] To provide improved vehicle services, heterogeneous infrastructure 100 enhances the ability of vehicles to communicate with data sources. Specifically, heterogeneous infrastructure 100 provides heterogeneous infrastructure along roads. In some aspects, this heterogeneous infrastructure 100 allows vehicles to be seamlessly served by multiple infrastructure owners when passing through multiple access nodes implemented in roadside equipment. The infrastructure may include these access nodes implemented in roadside equipment, wherein access nodes may include edge nodes 110, streetlights 112, roadside units (RSUs) 114, traffic lights 116, or other fog or edge computing nodes. Vehicle 120 may transmit data stored in cloud server 102 via edge nodes 110 or other roadside equipment, via multi-access edge computing (MEC) equipment 108, and via content delivery network (CDN) equipment 104. In operation, each service provider can advertise existing services to vehicles through the point nearest to each vehicle. Service providers may include home operators, out-of-home operators, or out-of-home non-operator service providers for vehicles. In one aspect, service providers include over-the-top (OTT) players. Using the heterogeneous infrastructure 100, vehicles can subscribe to each desired service on demand and have seamless, direct access to services from the heterogeneous infrastructure 100, independent of the service provider. On one hand, home operators using vehicle subscriptions can maintain a point of contact for authenticating vehicles to access services from any service provider or operator.

[0026] Heterogeneous infrastructure 100 improves the operation of autonomous vehicle services by supporting regional services without requiring continuous communication with a backend cloud. Heterogeneous infrastructure 100 provides heterogeneous infrastructure because it enables vehicles to discover and access available services, and provides seamless service access to vehicles across heterogeneous infrastructure 100 and heterogeneous service providers. For example, vehicle 120 can communicate with RSU 114 back to cloud server 102, which provides information about services available at that RSU 114 and other RSUs in the vicinity or direction of travel. This sharing of information across access nodes improves the availability of information about available services provided by operators and service providers, which improves the ability of a home operator or service provider to provide its subscribers' vehicles with a list of available services from any operator or service provider at any time in any region. This information sharing between access nodes also improves real-time service and service continuity, which improves the performance of communication with connected autonomous vehicles.

[0027] From the perspective of vehicle operators, this heterogeneous infrastructure 100 provides transparent service access for autonomous vehicles with horizontal and vertical roaming. For example, the provided horizontal roaming allows continuous service access for services roaming across the infrastructure of the same provider, and the provided vertical roaming allows continuous service access for services roaming across the infrastructure of different service providers. This heterogeneous infrastructure 100 provides service providers with a multi-tenant distributed infrastructure for providing seamless service access to autonomous vehicles based on service advertising datasets and for any service provider.

[0028] In addition to improving the provision of real-time services to vehicles, the heterogeneous infrastructure 100 also enhances the ability of service or hardware providers (e.g., MEC providers, FOG node providers) to improve autonomous vehicle mapping through enhanced vehicle data collection to improve vehicle safety. The use of roadside devices also improves the ability of cities or other areas to provide other services, such as smart city and supplemental road services.

[0029] Figure 2 This is a diagram depicting a heterogeneous infrastructure content delivery system 200 based on several aspects. The content delivery system 200 includes service content sources, such as a cloud 202. The cloud 202 communicates with one or more service content trackers and storage devices (such as one or more CDNs 204 and one or more service trackers 205). Service trackers 205 for different services share information, such as information about service types and service locations within CDNs 204, through a service tracker coordinator 206. In some aspects, peer-to-peer (P2P) protocols (e.g., peer-to-peer streaming protocol (PPSP)) can be used for this information sharing.

[0030] The service tracker coordinator 206 then communicates with one or more fog node communication devices, such as eNodeB 211. Each eNodeB 211 may have an associated mobile edge computing (MEC) device 210. Each MEC device acts as an extension of each CDN 204, such as by providing a web-based content cache for services from different CDN providers. Service publishing lists 213 are distributed to vehicles, such as directly by each MEC 210 or indirectly by one or more RSUs 214. MECs 210 or RSUs 214 can be located along roads and can query the service tracker coordinator 206 about the content location of services across the various CDNs 204. This query can occur via a P2P protocol such as PPSP. In one aspect, each of the RSUs 214 can obtain information in real time from one or more of the MECs 210 or RSUs 214 on available services via a subscription protocol such as Message Queuing Telemetry Transport (MQTT) protocol. The vehicle obtains information about available services and their location across heterogeneous infrastructure from the RSU 214, MEC 210, or eNodeB 211 fog vehicle node, which is located or traveling along the road. Using this information, the vehicle can select the services it needs based on the services it has access to. The connection from the RSU 214 to the vehicle can be a vehicle-to-everything (V2X) connection via LTE or 5G communication infrastructure, or it can use other wireless connections. Connections from the RSU 214 to the eNodeB 211 fog node and to the MEC 210 can include millimeter-wave communication (mmWave communication). Connections from one or more MEC 210s to various CDN 204s can include communication via wired optical or gigabit (Gbit) Ethernet communication links.

[0031] Figure 3 This is a diagram depicting a first vehicle service access process 300 according to some aspects. The first vehicle service access process 300 illustrates an exemplary communication flow for vehicle service access from a cloud 302 (e.g., a home operator cloud). The home operator cloud 302 associated with the vehicle may include a service provider for one or more specific services required by the vehicle on the road, such as map publishing, providing over-the-air (OTA) updates, and other services.

[0032] In this regard, vehicle 320 uses on-demand subscriptions to services, such as services selected based on the needs of each location or road segment. In operation, cloud 203 pushes service content to one or more CDNs 304, which in turn push the service content to one or more eNodeB fog nodes 311 or MECs 310. Service advertisements are then made to one or more RSUs 314 and vehicle 320. If no RSU 314 exists on the road segment, service advertisements can be made directly from MEC 310. Vehicle 320 can provide service subscriptions to MEC 310 to subscribe to services on demand, such as using a publish sub-model like MQTT. Finally, MEC 310 provides service access to vehicle 320. Communication can be conducted through the operator's network infrastructure, which may include authentication and authorization of service access performed by home operator 302 based on the vehicle's service subscription.

[0033] Figure 4 This is a diagram depicting a second vehicle service access process 400 according to some aspects. The second vehicle service access process 400 illustrates an exemplary process for vehicle access to services from any service provider or external operator. In this respect, the external operator of the vehicle can be a service provider offering one or more services required by the vehicle on the road, or a service provider that the vehicle does not have a subscription to, which can cover road segments with one or more services required by the vehicle. The second vehicle service access process 400 provides access to those vehicle services.

[0034] In this regard, vehicle 420 uses on-demand subscriptions to services, such as services selected based on the needs of each location or road segment. In operation, RSU 414 has information about available services and advertises services to vehicle 420. If RSU 414 is not present on a road segment, service advertising can be made directly from one or more MECs 410. Compared to the first vehicle service access process 300, the second vehicle service access process 400 may include one or more edge nodes 410. Each edge node 410 can advertise services to vehicle 420, and the vehicle can subscribe to services from edge nodes 410. To provide authentication and authorization for vehicle access to specific services, the vehicle's home subscriber can act as a trusted party, such as using the following relative to... Figure 5 The aforementioned service access authentication and authorization.

[0035] Figure 5This is a diagram depicting a third vehicle service access process 500 according to several aspects. The third vehicle service access process 500 illustrates aspects of handling authentication and authorization for service access. In operation, vehicle 520 can identify itself on its home operator subscription, such as using an International Mobile Subscriber Identity (IMSI), during a service request. Home operator 502 can contact the service provider, such as RSU 514 or edge node 510, to verify the authentication of vehicle 520. Home operator 502 can confirm the authentication of vehicle 520 and send a one-time decryption key (OTDK) (e.g., a one-time digital cipher) to vehicle 520 separately for the service used, and can also send the one-time encryption key (OTEK) to the service provider service node, such as to edge node 510 or RSU 514. The service provider service node can use the OTEK to encrypt service messages or packets being sent to the vehicle, and vehicle 520, receiving the service messages or packets, can use the OTDK to decrypt them. This allows for trusted authentication of vehicle 520 through its home subscriber and a new key for service access on the road.

[0036] Figure 6 This is a diagram depicting a vehicle communication Quality of Service (QoS) system 600 based on several aspects. The QoS system 600 provides improved capabilities for determining and sharing communication QoS, which enhances the autonomous vehicle's ability to handle network connectivity interruptions. For example, due to a sudden loss of connection, vehicle 606 may experience an interruption in vehicle services, leading to a significant degradation in the user's Quality of Experience (QoE). This degradation may include reduced or blocked access to real-time services used by the connected autonomous vehicle, such as blocking real-time map updates. Furthermore, many real-time autonomous vehicle applications operate based on estimates of available throughput and latency, as well as service bandwidth consumption and latency requirements, to meet vehicle service delivery needs.

[0037] The QoS system 600 provides the ability to determine and share communication QoS with mobile autonomous vehicles. In vehicular environments where vehicles are moving, especially when vehicles are moving at much higher speeds than mobile users, the QoS system 600 provides the ability to determine and share communication QoS, even when the connection between the vehicle and the network may roam frequently between base stations or access points. In one aspect, the QoS system 600 provides the vehicle with the ability to anticipate connectivity options, allowing applications to be tailored to minimize or avoid service interruptions. For example, when a vehicle is about to enter a tunnel or otherwise anticipates limited bandwidth, communication QoS enables the vehicle to prioritize mapping or safe traffic communications and notify the user. The predictive QoS estimation provided by the QoS system 600 also improves the vehicle's ability to meet the data connectivity requirements set by automakers for various consumer and other vehicle-to-everything (V2X) services. These requirements may include coverage information for different communication technologies, throughput and latency requirements for each service type, and other requirements.

[0038] To improve the determination and sharing of communication QoS, various predictive QoS conditioning methods can be used. In one aspect, predictive QoS conditioning includes crowdsourcing QoS information. In the crowdsourcing aspect, multiple vehicles can collect QoS information as they move through an area and provide this information back to the application server via the network. The collected QoS information may include information about coverage, average latency, available throughput from different networks or interfaces, and other QoS information. QoS information can be explicitly collected by one or more dedicated sensors or implicitly collected by analyzing other available QoS information. Reporting QoS information from vehicles back to the application server can utilize high-overhead real-time reporting of information that impacts real-time services, such as information used for high-definition (HD) map downloads, traffic information, roadside alerts, and other real-time service information. Reporting QoS information from vehicles back to the application server can utilize low-overhead offline reporting at the end of the day, such as for persistent connectivity loss in specific areas, packet drop in known areas, seemingly permanent problems, or problems that are not of real-time importance. Reports can be distributed directly from the vehicle to other nearby vehicles using V2V communication, such as sending QoS information to following vehicles or vehicles approaching the location.

[0039] In one aspect, a single vehicle can be designated as the reporting vehicle, and other nearby vehicles associated with the reporting vehicle can receive direct QoS information from it. The QoS information reported by the vehicle can be processed at the network edge device. QoS information may include location-based information, and this location-based information can be used to generate a network QoE map for each area. The QoS map can indicate the quality level of various locations, interference areas, or other QoS information. In various aspects, the area size can be identified as a predetermined area, such as an area based on a predetermined number of square kilometers or square miles. The generated network QoE map provides a prediction of the QoE of service for each area and can be transmitted to vehicles near that location or application source, allowing other vehicles to pre-adjust bandwidth parameters to minimize or eliminate any interruptions to service, such as by pre-buffering data. The generated network QoE map can be continuously refreshed via new crowdsourcing.

[0040] like Figure 6 As shown, QoS system 600 can provide predictive QoS conditioning based on machine learning. QoS system 600 includes an application server 602 and a machine learning (ML) device 604. Machine learning device 604 can receive information from one or more vehicles 606, which can be collected and provided using crowdsourcing as described above. This information may include information about the performance of one or more autonomous navigation applications, vehicle measurements, QoE experienced at vehicle 606, information about the user, information about the vehicle, information about the vehicle's location, or other QoS information. This information can be associated as input for training a QoS machine learning model at machine learning device 604. Machine learning device 604 can provide network parameters to application server 602 and receive application information from application server 602. Machine learning device 604 can receive application information from vehicle 606 and provide QoS information back to vehicle 606, such as providing wireless communication radio configurations that instruct radio components to cache information in the event of an anticipated service disruption. In one example, application server 602 can work with machine learning device 604 to learn over time how users pass through low-throughput areas during their morning commute, and can cause data caching at edge network devices or pre-buffering at vehicle devices to reduce the impact of traveling through low-throughput areas.

[0041] In one aspect, the machine learning device 604 can train a QoS machine learning model to identify output combinations of QoS network parameters based on specific patterns of the received QoS information. In another aspect, the machine learning device 604 can train a QoS machine learning model to identify the output wireless communication radio configuration based on input patterns of the received QoS information, application information received from the application server 602, application information received from the vehicle 606, or the real-time link quality experienced by the vehicle modem. In one aspect, network parameters, application information, radio configuration, and other information can be used to generate a predictive QoS map, and this QoS map can be provided to other vehicles to improve data-driven vehicle service performance.

[0042] Although Figure 6 A machine learning device 604, separate from application server 602 and vehicles 606 and 608, is shown; however, machine learning can be performed on application server 602 or on one or more of vehicles 606 and 608. For example, vehicle 606 may include machine learning device 604 communicatively coupled to a vehicle application, and vehicle 608 may train its internal QoS machine learning model based on information such as frequent travel, frequently used vehicle services, available and required resources, and others. Information provided by the vehicle's internal QoS machine learning model can be provided back to application server 602, which can use this information to generate predictive QoS maps. For example, QoS maps can be generated at application server 602 and provided to vehicle 606, which can use the QoS maps to identify areas with reduced bandwidth and allocate additional slices of network bandwidth to vehicle 606 to increase effective bandwidth. This generation of predictive QoS information based on crowdsourcing or machine learning can be used to improve network reconfiguration, such as as described below relative to... Figure 7 As stated above.

[0043] Figure 7This is a diagram depicting a dynamic network reconfiguration system 700 based on several aspects. System 700 enables the dynamic learning of upstream and downstream traffic demands of connected autonomous vehicles, which can be used to provide dynamic network reconfiguration. System 700 includes one or more vehicle service applications 702 communicating with a vehicle modem 704. The vehicle modem 704 receives configuration information, such as service type, frequency, location dependency, performance requirements, or other check inputs, from a vehicle service check knob (e.g., device) 706. The vehicle modem 704 also receives configuration information from a machine learning knob 708, which can be used to modify machine learning parameters, such as model training iteration count, model training batch size, and other machine learning parameters. The vehicle modem 704 uses information from the vehicle service check knob 706 and the machine learning knob 708 to provide a channel adaptation knob 710. The vehicle modem 704 provides network coverage throughput to a mobile edge computing (MEC) server 716 via a roadside unit (RSU) 712 and an eNodeB 714. The vehicle modem 704 can also provide network coverage throughput directly to the MEC server 716 via the eNodeB 714. The MEC server can then transmit the network coverage throughput to one or more network and service check knobs 718.

[0044] MEC server 716 can be used to receive and store network capacity and network load knowledge, which can be used to help data carriers configure real-time parameters to meet network QoS requirements. MEC server 716 and network and service check knob 718 can use machine learning to receive and process available dynamic information regarding vehicle service demand, service consumption rates for each road segment and the time of day, the density of service consumers on the road for vehicles and roadside units, and dynamic information from vehicles. MEC server 716 and network and service check knob 718 can use deep packet inspection or intelligent traffic classification techniques applied to data provided from vehicle modem 704 to generate dynamic information describing vehicle service demand. For example, MEC server 716 and network and service check knob 718 can check traffic types and vehicle service demand in real time and can adapt network bandwidth slicing (e.g., allocation) for each vehicle service type in real time. Dynamic information about service demand can also be obtained via application interfaces or via vehicles, such as using the above-mentioned relative to... Figure 6 The techniques described are for creating predictive QoS maps based on crowdsourcing and machine learning. Predictive QoS map generation and dynamic network reconfiguration can be used individually, although using both together will improve or maximize the performance of data-driven vehicle services.

[0045] Figure 8This diagram depicts the OWC Deployment 800 from several aspects. The OWC Deployment 800 provides a technical solution to the technical challenges of large-scale data uploads and downloads between autonomous vehicles and cloud-based data services. In some aspects, Optical Wireless Communication (OWC) offers higher data throughput and lower complexity, such as being beneficial for short-range, high-mobility wireless communication. These OWC solutions provide wireless access without requiring expensive wireless data packets and reduce or eliminate interference with RF technologies such as Wi-Fi and WiGig. Table 1 summarizes the performance advantages of OWC over WiGig:

[0046] Table 1. OWC Performance and Wi-Fi

[0047]

[0048] These OWC solutions can be utilized in various ways when vehicles approach roadside units equipped with OWC on urban roads or highways. These solutions can be deployed in transportation infrastructure (e.g., traffic lights, lampposts, vehicle charging stations) to communicate with vehicles. Depending on the specific infrastructure implementation, these OWC solutions can include fixed point-to-point OWC configurations (e.g., for charging station infrastructure) or fixed point-to-mobile point OWC configurations (e.g., for traffic light or lamppost infrastructure).

[0049] OWC configuration 800 includes an exemplary OWC solution for fixed-to-mobile point OWC configuration, which may be useful, for example, in situations where large amounts of data are downloaded from the cloud to a vehicle. In one aspect, roadside environment 802 includes multiple roadside units to provide continuous coverage as the vehicle moves. In one example, a transmitter may be mounted in a roadside barrier to provide continuous coverage even at high speeds.

[0050] Roadside snapshot 804 illustrates an example of this OWC solution. More specifically, roadside snapshot 804 shows vehicle 810 communicating with an OWC roadside device 806 within a roadside environment 802. The OWC roadside device 804 includes a light source 806 that emits a light-based signal 808. The light-based signal 808 may use one or more wavelengths, wherein the wavelengths may be selected based on wavelength transmission effectiveness (e.g., minimizing the signal-to-noise ratio (SNR) level) to provide multiple simultaneous communication channels, or selected based on other criteria. The light-based signal 808 may be received by an OWC vehicle device 812 mounted on vehicle 810. Each of the OWC roadside device 806 and the OWC vehicle device 812 may include a light source emitter and a light detector receiver, such as to provide simultaneous upload and download.

[0051] Each OWC transmitter can be used to generate a light cluster (e.g., an illuminated area). Using one or more focusing lenses, as described below, the light cluster provides a substantially uniform light intensity at a predetermined distance. The predetermined distance for uniform light intensity can include a range approximating the distance between the height of the OWC roadside device 806 and the expected average height of the OWC vehicle device 812. In one example, the predetermined distance may provide a substantially uniform light intensity in the range of three to four meters, but other predetermined distances and ranges can be used. By designing these OWC transmitters to provide this substantially uniform light intensity, the receiver on the OWC vehicle device 812 receives a substantially consistent power level within the light cone (e.g., within the broadcast area of ​​the OWC roadside device 806). These substantially consistent power levels provide a substantially consistent SNR and improve the system's ability to provide high-bandwidth operation. In one aspect, this substantially uniform intensity light cluster is provided by collimated fiber outputs from the transmitters, which pass through an optical front end customized for the respective OWC device. The outputs of multiple transmitters with different wavelengths can be combined in the fiber (e.g., via a wavelength combiner). Using these features, the transmitter can provide the ability to use the same optical front end while providing dense wavelength division multiplexing (DWDM). This DWDM can include multiplexed optical signals, such as those multiplexed within the 1550nm band, to take advantage of the capability and cost of erbium-doped fiber amplifiers (EDFAs), which are effective for wavelengths between approximately 1525nm–1565nm (C-band) or 1570nm–1610nm (L-band). Bandwidth can be further increased using DWDM OWC. In one example, DWDM OWC can provide a bandwidth of 45 × 25Gbps = 1.1Tbps or higher. In some aspects, on / off keying with Manchester encoding can be used to modulate the data.

[0052] In some aspects, an OWC receiver may include focusing optics and a photodetector receiver. The focusing optics can be used to focus light, such as by focusing light directly onto a photodetector or onto an optical fiber that carries a signal to the photodetector. An OWC receiver may include one or more detectors, and the detector with the highest intensity can be selected based on which combination provides the best signal (e.g., highest power level, lowest SNR). An OWC receiver may also include multiple detectors arranged relative to each other in various configurations, such as a convex detector 814 or a concave detector 816. These non-planar configurations can be used to increase the overall field of view of each receiver unit. Each receiver or detector may be mechanically actuated, such as to track the receiver position or incident beam direction, to improve or maximize data coupling (e.g., improve or maximize SNR). In one aspect, tracking of the receiver position or beam direction may be based on current knowledge of the receiver position and prior knowledge of the transmitter position (e.g., offline download of the transmitter position). Using these positions, one or more OWC receivers or receiver optics can be adjusted to point towards the transmitter position. In one aspect, data coupling can be improved or maximized by mechanically manipulating one or all of the receiver optics, detectors, or optical fibers to obtain the highest signal. Signal processing techniques can be used to create closed-loop feedback directly from the detectors, which can then be used to automatically search for and align the optimal receiving position for the receiver and / or individual detectors within the receiver. By using analysis based on the assumption of a strong Rician channel (e.g., a channel with a strong line-of-sight component), the complexity of the decision feedback equalizer can be reduced to eliminate post-cursor inter-symbol interference. For aspects using DWDM, fiber wavelength filters can be used to separate wavelengths and deliver them to individual receivers or detectors.

[0053] Figure 9This diagram illustrates a collimated OWC configuration 900 according to several aspects. Fixed point-to-point OWC can provide robust and high-bandwidth download and upload links, such as by reducing or eliminating the effects of contact contamination failures. As shown in the collimated OWC configuration 900, a first lens 904 can be used to collimate a transmitted optical signal 902 into a collimated optical signal 906, which can be received by a second lens 908 and focused onto a receiver as a received optical signal 910. Each of the first lens 904 and the second lens 908 can include a substantially aberration-free collimating lens, which can provide substantially 100% coupling for the OWC fixed point-to-point link. Each of the first lens 904 and the second lens 908 can be used to collimate or focus light, thereby supporting bidirectional communication. Bidirectional communication can be further improved by using an optical circulator to separate the transmitted and received signals on each side. In addition, the OWC Configuration 900 provides a simplified upgrade path to higher bandwidth solutions (such as multi-wavelength MUX), such as by replacing transceiver or receiver components and reusing the fixed point-to-point collimation alignment of the OWC Configuration 900.

[0054] Figure 10 This is a diagram depicting an optical front-end design 1000 customized according to some aspects of OWC. An optical signal input 1002 can be fed to a customized OWC lens 1004. The optical signal input 1002 can include light with a collimated Gaussian intensity distribution (e.g., a brighter center, illumination following a bell curve). The customized OWC lens 1004 can refocus the optical signal input 1002 onto a substantially flat and substantially uniform intensity light distribution 1008 via a conical light cone 1006. The customized OWC lens 1004 uses the aspherical properties of the lens to generate this light distribution 1008, focusing the collimated beam at different focal points near the lens to redistribute intensity in a substantially flat area at a predetermined design distance. This customized OWC lens 1004 can be designed for various areas and distances, such as using lens modeling software to identify uniformity targets and optimize the lens's aspherical coefficient. Although Figure 10 A substantially uniform light distribution 1008 in the form of a circle or ellipse is shown, but other planar shapes can be selected for various environments and applications. For example, the OWC lens 1004 can be designed for various conical angles, such as to provide an elliptical shape that is longer in the direction of vehicle travel and narrower in the direction perpendicular to vehicle travel. These design choices can be used to further improve SNR and overall system power efficiency or to maximize SNR and overall system power efficiency.

[0055] Figure 11A and Figure 11B It is a diagram based on the performance of a customized optical front end of 1100. Figure 11AAn example of substantially uniform intensity is shown in a two-dimensional graph. Specifically, the light intensity is maximized and substantially uniform within circle 1104, but is substantially zero in the outer region 1102. Figure 11B An example of substantially uniform intensity is shown in a one-dimensional plot. Specifically, the light intensity is maximized and substantially uniform within the desired region 1106, but is substantially zero intensity in the outer region 1108. In one example, Figure 11A The center of the two-dimensional curve in the graph can correspond to Figure 11B The center line of the one-dimensional graph is shown. By using modeling in the design of the OWC-customized optical front end, the optical front end can provide substantially uniform intensity over a predetermined distance, and also substantially uniform intensity over a range of distances. For variations in communication range specific to these proposed infrastructure and vehicle communication applications, this ability to provide substantially uniform intensity over a range of distances further improves or maximizes SNR and overall system power efficiency.

[0056] These light intensity patterns and optical front-end designs can be used to detect the use of the OWC aspects described herein. For example, the specific lens configurations described above can be detected through system analysis (e.g., reverse engineering). Additionally, the wavelengths of the OWC optical signals will likely include light in the near-infrared spectral range, and the emitter output pattern can be detected using an IR card or beam scanner.

[0057] Figure 12 This is a block diagram of a radio architecture 1200 based on several aspects. The radio architecture 1200 can be used to provide radio communications, such as for heterogeneous infrastructure 100, vehicle QoS system 600, or other systems described herein. The radio architecture 1200 may include a radio front-end module (FEM) circuit 1204, a radio IC circuit 1206, and a baseband processing circuit 1208. The radio architecture 1200 shown includes wireless local area network (WLAN) functionality and Bluetooth (BT) functionality, but is not limited thereto. In this disclosure, "WLAN" and "Wi-Fi" are used interchangeably.

[0058] FEM circuit 1204 may include WLAN or Wi-Fi FEM circuit 1204A and Bluetooth (BT) FEM circuit 1204B. WLAN FEM circuit 1204A may include a receive signal path, which may include circuitry configured to operate on WLAN RF signals received from one or more antennas 1201, amplify the received signals, and provide an amplified version of the received signals to WLAN radio IC circuit 1206A for further processing. BT FEM circuit 1204B may include a receive signal path, which may include circuitry configured to operate on BT RF signals received from one or more antennas 1201, amplify the received signals, and provide an amplified version of the received signals to BT radio IC circuit 1206B for further processing. FEM circuit 1204A may also include a transmit signal path, which may include circuitry configured to amplify WLAN signals provided by radio IC circuit 1206A for wireless transmission over a wireless communication network via one or more of the antennas 1201. Furthermore, the FEM circuit 1204B may also include a transmit signal path, which may include circuitry configured to amplify BT signals provided by the radio IC circuit 1206B and wirelessly transmitted via one or more antennas. Figure 12 In this respect, although FEM circuits 1204A and 1204B are shown to be different from each other, the aspects are not limited thereto, and within their scope include the use of additional FEM circuits (not shown) including transmission or reception paths for both WLAN signals and BT signals, or the use of one or more FEM circuits (wherein at least some of these FEM circuits share transmission or reception paths for both WLAN signals and BT signals).

[0059] The radio IC circuit 1206 shown in the figure may include a WLAN radio IC circuit 1206A and a BT radio IC circuit 1206B. The WLAN radio IC circuit 1206A may include a receive signal path, which may include circuitry for down-converting a WLAN RF signal received from the FEM circuit 1204A and providing a baseband signal to the WLAN baseband processing circuit 1208A. The BT radio IC circuit 1206B may subsequently include a receive signal path, which may include circuitry for down-converting a BT RF signal received from the FEM circuit 1204B and providing a baseband signal to the BT baseband processing circuit 1208B. The WLAN radio IC circuit 1206A may also include a transmit signal path, which may include circuitry for up-converting a WLAN baseband signal provided by the WLAN baseband processing circuit 1208A and providing a WLAN RF output signal to the FEM circuit 1204A for subsequent wireless transmission by one or more antennas 1201. The BT radio IC circuit 1206B may also include a transmit signal path, which may include circuitry for up-converting the BT baseband signal provided by the BT baseband processing circuit 1208B and providing the BT RF output signal to the FEM circuit 1204B for subsequent wireless transmission by one or more antennas 1201. Figure 12 In this respect, although radio IC circuit 1206A and radio IC circuit 1206B are shown to be different from each other, the aspects are not limited thereto, and within their scope include the use of radio IC circuits (not shown) that include a transmit signal path or a receive signal path for both WLAN signals and BT signals, or the use of one or more radio IC circuits (wherein at least some of these radio IC circuits share a transmit signal path or a receive signal path for both WLAN signals and BT signals).

[0060] The baseband processing circuit 1208 may include a WLAN baseband processing circuit 1208A and a BT baseband processing circuit 1208B. The WLAN baseband processing circuit 1208A may include a memory, such as a set of RAM arrays in, for example, a Fast Fourier Transform or Inverse Fast Fourier Transform block (not shown) of the WLAN baseband processing circuit 1208A. Each of the WLAN baseband circuit 1208A and the BT baseband circuit 1208B may also include one or more processors and control logic components to process signals received from the corresponding WLAN or BT receive signal path of the radio IC circuit 1206, and to generate corresponding WLAN or BT baseband signals for the transmit signal path of the radio IC circuit 1206. Each of the baseband processing circuits 1208A and 1208B may also include physical layer (PHY) and media access control layer (MAC) circuitry, and may also interface with the application processor 1210 to generate and process baseband signals and control the operation of the radio IC circuit 1206.

[0061] Still referencing Figure 12 According to the aspects shown, the WLAN-BT coexistence circuit 1213 may include logic components that provide an interface between the WLAN baseband circuit 1208A and the BT baseband circuit 1208B to enable use cases requiring WLAN and BT coexistence. Furthermore, a switch 1203 may be provided between the WLAN FEM circuit 1204A and the BT FEM circuit 1204B to allow switching between the WLAN radio component and the BT radio component as needed for the application. Additionally, although the antenna 1201 is depicted as being connected to the WLAN FEM circuit 1204A and the BT FEM circuit 1204B respectively, aspects within their scope include sharing one or more antennas between the WLAN FEM and the BT FEM, or providing more than one antenna connected to each of the FEM circuits 1204A and 1204B.

[0062] In some aspects, the front-end module circuitry 1204, the radio IC circuitry 1206, and the baseband processing circuitry 1208 may be provided on a single radio card (such as wireless radio card 1202). In other aspects, one or more antennas 1201, FEM circuitry 1204, and radio IC circuitry 1206 may be provided on a single radio card. In still other aspects, the radio IC circuitry 1206 and the baseband processing circuitry 1208 may be provided on a single chip or integrated circuit (IC) (such as IC 1212).

[0063] In some aspects, the wireless radio card 1202 may include a WLAN radio card and may be configured for Wi-Fi communication, although the scope of the aspects is not limited in this respect. In some of these aspects, the radio architecture 1200 may be configured to receive and transmit Orthogonal Frequency Division Multiplexing (OFDM) or Orthogonal Frequency Division Multiple Access (OFDMA) communication signals via a multi-carrier communication channel. OFDM signals or OFDMA signals may include multiple orthogonal subcarriers.

[0064] In some aspects of these multi-carrier aspects, the radio architecture 1200 may be part of a Wi-Fi communication station (STA) (such as a wireless access point (AP), base station, or mobile device that includes Wi-Fi equipment). In some of these aspects, the radio architecture 1200 may be configured to transmit and receive signals according to a specific communication standard or protocol, which is any standard such as the Institute of Electrical and Electronics Engineers (IEEE) standards, including: 802.11n-2009, IEEE 802.11-2012, 802.11n-2009, 802.11ac, or 802.11ax standards or recommended specifications for WLAN, but the scope of each aspect is not limited in this respect. The radio architecture 1200 may also be adapted to transmit or receive communications according to other technologies and standards.

[0065] In some aspects, the radio architecture 1200 can be configured for high-efficiency (HE) Wi-Fi (HEW) communication according to the IEEE 802.11ax standard. In other aspects, the radio architecture 1200 can be configured for communication according to OFDMA technology, but the scope of each aspect is not limited in this respect.

[0066] In some other respects, the radio architecture 1200 can be configured to transmit and receive signals using one or more other modulation techniques, such as spread spectrum modulation (e.g., direct sequence code division multiple access (DS-CDMA) or frequency hopping code division multiple access (FH-CDMA)), time division multiplexing (TDM) modulation, or frequency division multiplexing (FDM) modulation, but the scope of each respects is not limited in this respect.

[0067] In some aspects, such as Figure 12 As further shown, the BT baseband circuit 1208B is compliant with Bluetooth (BT) connectivity standards, such as Bluetooth, Bluetooth 4.0, or Bluetooth 5.0, or any other newer version of the Bluetooth standard. (For example...) Figure 12As shown in the aspects including BT functionality, radio architecture 1200 can be configured to establish BT Synchronous Connection-Oriented (SCO) links and / or BT Low Power (BT LE) links. In some aspects including SCO functionality, radio architecture 1200 can be configured to establish extended SCO (eSCO) links for BT communication, but the scope of the aspects is not limited in this respect. In some of these aspects including BT functionality, the radio architecture can be configured to participate in BT Asynchronous Connectionless (ACL) communication, but the scope of the aspects is not limited in this respect. In some aspects, such as Figure 12 As shown, the functions of the BT radio card and the WLAN radio card can be combined into a single wireless radio card (such as a single wireless radio card 1202), although the aspects are not limited to this, and include discrete WLAN radio cards and BT radio cards within its scope.

[0068] Figure 13 The FEM circuit 1300 is shown according to some aspects. The FEM circuit 1300 can be suitable for use as a WLAN or BTFEM circuit 1204A or 1204B. Figure 12 This is an example of a circuit, but other circuit configurations may also be suitable.

[0069] In some aspects, the FEM circuit 1300 may include a TX / RX switch 1302 to switch between transmit and receive mode operation. The FEM circuit 1300 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit 1300 may include a low-noise amplifier (LNA) 1306 to amplify the received RF signal 1303 and provide the amplified received RF signal 1307 as an output (e.g., provided to the radio IC circuit 1400). Figure 14 The FEM circuit 1300 may include a power amplifier (P transmit signal path A) that amplifies the input RF signal 1309 (e.g., provided by the radio IC circuit 1400), and one or more filters 1312, such as a bandpass filter (BPF), a low-pass filter (LPF), or other types of filters, to generate subsequent transmission (through antenna 1201). Figure 12 RF signal 1315 of one or more of the following.

[0070] In some dual-mode applications for Wi-Fi communication, the FEM circuit 1300 can be configured to operate in either the 2.4 GHz or 5 GHz spectrum. In these applications, the receive signal path of the FEM circuit 1300 may include a receive signal path duplexer 1304 to separate signals from each spectrum, and a separate LNA 1306 for each spectrum, as shown. In these applications, the transmit signal path of the FEM circuit 1300 may also include a power amplifier 1310 and a filter 1312 (such as a BPF, LPF, or other type of filter) for each spectrum, and a transmit signal path duplexer 1314 for providing the signal from one spectrum in a different spectrum onto a single transmission path for transmission by antenna 1201. Figure 12 One or more of them can be used for subsequent transmission. In some aspects, BT communication can utilize a 2.4 GHz signal path and can utilize the same FEM circuit 1300 used in WLAN communication.

[0071] Figure 14 A radio IC circuit 1400 is shown according to some aspects. The radio IC circuit 1400 is suitable for use as a WLAN or BT radio IC circuit 1206A or 1206B. Figure 12 This is an example of a circuit, but other circuit configurations may also be suitable.

[0072] In some aspects, the radio IC circuit 1400 may include a receive signal path and a transmit signal path. The receive signal path of the radio IC circuit 1400 may include at least a mixer circuit 1402 (such as, for example, a down-conversion mixer circuit), an amplifier circuit 1406, and a filter circuit 1408. The transmit signal path of the radio IC circuit 1400 may include at least a filter circuit 1412 and a mixer circuit 1414 (such as, for example, an up-conversion mixer circuit). The radio IC circuit 1400 may also include a synthesizer circuit 1404 for synthesizing an output frequency 1405 for use by the mixer circuits 1402 and 1414. According to some aspects, the mixer circuit 1402 or the mixer circuit 1414 may each be configured to provide direct conversion functionality. The latter type of circuit presents a much simpler architecture compared to standard superheterodyne mixer circuits, and any flicker noise generated by this circuit can be mitigated, for example, by using OFDM modulation. Figure 14Only a simplified version of the radio IC circuitry is shown, and it may include (though not shown) aspects, wherein each of the depicted circuits may include more than one component. For example, depending on application requirements, mixer circuits 1420 or 1414 may each include one or more mixers, and filter circuits 1408 or 1412 may each include one or more filters, such as one or more BPFs or LPFs. For example, when the mixer circuits are of the direct conversion type, they may each include two or more mixers.

[0073] In some respects, mixer circuit 1402 can be configured to output frequency 1405 from FEM circuit 1300 based on synthesized output frequency 1405 provided by synthesizer circuit 1404. Figure 13 The received RF signal 1307 is down-converted. Amplifier circuit 1406 can be configured to amplify the down-converted signal, and filter circuit 1408 may include an LPF configured to remove unwanted signals from the down-converted signal to generate an output baseband signal 1407. The output baseband signal 1407 can be provided to baseband processing circuit 1208. Figure 12 This is for further processing. In some respects, although not required, the output baseband signal 1407 may be a zero-frequency baseband signal. In some respects, the mixer circuit 1402 may include a passive mixer, but the scope of each aspect is not limited in this respect.

[0074] In some aspects, mixer circuit 1414 can be configured to up-convert input baseband signal 1411 based on synthesis frequency 1405 provided by synthesizer circuit 1404 to generate RF output signal 1409 for FEM circuit 1300. Baseband signal 1411 can be provided by baseband processing circuit 1208 and can be filtered by filter circuit 1412. Filter circuit 1412 may include LPF or BPF, but the scope of each aspect is not limited in this respect.

[0075] In some aspects, mixer circuit 1402 and mixer circuit 1414 may each include two or more mixers and may be arranged to perform quadrature downconversion or quadrature upconversion respectively by means of synthesizer circuit 1404. In some aspects, mixer circuit 1402 and mixer circuit 1414 may each include two or more mixers, each of which is configured for image suppression (e.g., Hartley image suppression). In some aspects, mixer circuit 1402 and mixer circuit 1414 may be arranged to perform direct downconversion or direct upconversion respectively. In some aspects, mixer circuit 1402 and mixer circuit 1414 may be configured for superheterodyne operation, although this is not mandatory.

[0076] According to one aspect, mixer circuit 1402 may include quadrature passive mixers (e.g., for in-phase (I) and quadrature (Q) paths). In such an aspect, from Figure 14 The RF input signal 1407 can be down-converted to provide I baseband output signal and Q baseband output signal to be sent to the baseband processor.

[0077] The quadrature passive mixer can be driven by a zero-degree and ninety-degree time-varying LO switching signal provided by a quadrature circuit, which can be configured to receive the LO frequency (fLO) from a local oscillator or synthesizer, such as the LO output frequency 1405 of synthesizer circuit 1404. Figure 14 In some respects, the LO frequency can be the carrier frequency, while in others, the LO frequency can be a fraction of the carrier frequency (e.g., half or one-third of the carrier frequency). In some respects, the zero-degree and ninety-degree time-varying switching signals can be generated by a synthesizer, but the range of respects is not limited in this respect.

[0078] In some respects, the LO signal can vary in terms of duty cycle (the percentage of time the LO signal is high in a cycle) or offset (the difference between the start points of the cycles). In some respects, the LO signal can have a 25% duty cycle and a 50% offset. In some respects, each branch of the mixer circuit (e.g., the in-phase (I) path and the quadrature (Q) path) can operate with a 25% duty cycle, which can result in a significant reduction in power consumption.

[0079] RF input signal 1407 ( Figure 14 The output signal may include an equalization signal, but the range of aspects is not limited in this respect. The I-baseband output signal and the Q-baseband output signal can be provided to a low-noise amplifier (such as amplifier circuit 1406). Figure 14 Or it can be provided to the filter circuit 1408. Figure 14 ).

[0080] In some aspects, the output baseband signal 1407 and the input baseband signal 1411 can be analog baseband signals, although the range of aspects is not limited in this respect. In some alternative aspects, the output baseband signal 1407 and the input baseband signal 1411 can be digital baseband signals. In these alternative aspects, the radio IC circuitry may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry.

[0081] In some dual-mode aspects, separate radio IC circuits may be available for processing signals of each spectrum or other spectrums not mentioned here, but the range of aspects is not limited in this respect.

[0082] In some aspects, synthesizer circuit 1404 may be a fractional-N synthesizer or a fractional-N / N+1 synthesizer, but the range of aspects is not limited in this respect, as other types of frequency synthesizers may also be suitable. For example, synthesizer circuit 1404 may be a Δ-∑ synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider. According to some aspects, synthesizer circuit 1404 may include digital synthesizer circuitry. The advantage of using digital synthesizer circuitry is that, although it may still include some analog components, its footprint can be significantly smaller than that of analog synthesizer circuitry. In some aspects, the frequency input to synthesizer circuit 1404 may be provided by a voltage-controlled oscillator (VCO), although this is not mandatory. The frequency divider control input may be further controlled by baseband processing circuitry 1208 (…). Figure 12 ) or application processor 1211 ( Figure 12 The frequency divider control input (e.g., N) is provided, depending on the expected output frequency 1405. In some aspects, the frequency divider control input (e.g., N) can be determined from a lookup table (e.g., located within a Wi-Fi card) based on the channel number and channel center frequency determined or indicated by the application processor 1211.

[0083] In some respects, synthesizer circuit 1404 may be configured to generate a carrier frequency as output frequency 1405, while in other respects, output frequency 1405 may be a fraction of the carrier frequency (e.g., half or one-third of the carrier frequency). In some respects, output frequency 1405 may be the LO frequency (fLO).

[0084] Figure 15 A functional block diagram of a baseband processing circuit 1500 is shown according to some aspects. The baseband processing circuit 1500 is suitable for use as a baseband processing circuit 1208. Figure 12 This is an example of a circuit, although other circuit configurations may also be suitable. The baseband processing circuit 1500 may include circuitry for processing data generated by the radio IC circuit 1206 (…). Figure 12 The baseband processing circuit 1500 includes a receive baseband processor (RX BBP) 1502 for receiving baseband signals 1409 and a transmit baseband processor (TX BBP) 1504 for generating transmit baseband signals 1411 for the radio IC circuit 1206. The baseband processing circuit 1500 may also include a control logic unit 1506 for coordinating the operation of the baseband processing circuit 1500.

[0085] In some aspects (e.g., when exchanging analog baseband signals between baseband processing circuitry 1500 and radio IC circuitry 1206), baseband processing circuitry 1500 may include an ADC 1510 to convert analog baseband signals received from radio IC circuitry 1206 into digital baseband signals for processing by RX BBP 1502. In these aspects, baseband processing circuitry 1500 may also include a DAC 1512 to convert digital baseband signals from TX BBP 1504 into analog baseband signals.

[0086] In some aspects, such as transmitting OFDM or OFDMA signals via the WLAN baseband circuit 1208A, the TX BBP1504 can be configured to appropriately generate the OFDM or OFDMA signal for transmission by performing an inverse fast Fourier transform (IFFT). The RX BBP1502 can be configured to process the received OFDM or OFDMA signal by performing an FFT. In some aspects, the RX BBP1502 can be configured to detect the presence of the OFDM or OFDMA signal by performing autocorrelation, to detect a preamble (such as a short preamble), and to detect a long preamble by performing cross-correlation. The preamble may be part of a predetermined frame structure for Wi-Fi communication.

[0087] Re-reference Figure 12 In some respects, antenna 1201 ( Figure 12 Each antenna may include one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, slot antennas, or other types of antennas suitable for transmitting RF signals. In some multiple-input multiple-output (MIMO) aspects, the antennas may be effectively separated to take advantage of spatial diversity and the different channel characteristics that can be generated. Each antenna 1201 may include a set of phased array antennas, but is not limited thereto.

[0088] Although the radio architecture 1200 is shown as having several individual functional elements, one or more of these functional elements may be combined and implemented by a combination of software-configurable elements (such as processing elements including digital signal processors (DSPs)) or other hardware elements. For example, some elements may include one or more microprocessors, DSPs, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), radio frequency integrated circuits (RFID), and combinations of various hardware and logic circuits for at least performing the functions described herein. In some aspects, a functional element may refer to one or more processes running on one or more processing elements.

[0089] Figure 16A block diagram of an exemplary machine 1600 is shown, on which any one or more of the technologies (e.g., methods) discussed herein can be performed. Alternatively, machine 1600 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, machine 1600 may operate as a server machine, a client machine, or both in a server-client network environment. In one example, machine 1600 may act as a peer-to-peer (P2P) (or other distributed) network environment. Machine 1600 may be a user equipment (UE), a drone (UAV) or other vehicle, an evolved Node B (eNB), a next-generation evolved Node B (gNB), a next-generation access network (AN), a next-generation user plane function (UPF), a Wi-Fi access point (AP), a Wi-Fi station (STA), a personal computer (PC), a tablet computer, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a smartphone, a network device, a network router, a switch, or a bridge, or any machine capable of (sequentially or otherwise) executing instructions specifying actions to be taken by that machine. Furthermore, although only one machine is shown, the term "machine" should also be considered as any collection of machines that individually or collectively execute a set (or more sets) of instructions to perform any one or more of the methods discussed herein (such as cloud computing Software as a Service (SaaS)) and other computer cluster configurations.

[0090] Examples as described herein may include logical components or components, modules, or mechanisms, or may operate on logical components or components, modules, or mechanisms. A module is a tangible entity (e.g., hardware) capable of performing a specified operation and configured or arranged in some way. In one example, circuitry may be arranged as a module in a specified manner (e.g., internally or relative to external entities such as other circuitry). In one example, all or part of one or more computer systems (e.g., stand-alone computer systems, client computer systems, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application portions, or applications) to operate to perform a specified operation. In one example, the software may reside on a machine-readable medium. In one example, when the software is executed by the underlying hardware of the module, it causes the hardware to perform the specified operation.

[0091] Therefore, the term "module" should be understood to encompass tangible entities, that is, entities that are physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transiently) configured (e.g., programmed) to operate or perform any of the operations described herein in a specified manner. Consider the example of modules being temporarily configured, where each module does not need to be instantiated at any given time. For example, if a module includes a general-purpose hardware processor configured using software, the general-purpose hardware processor can be configured as different modules at different times. The software can accordingly configure the hardware processor, for example, to constitute a particular module at one time instance and different modules at different time instances.

[0092] Machine (e.g., computer system) 1600 may include processor 1602 (e.g., hardware processor, central processing unit (CPU), graphics processing unit (GPU), hardware processor core, or any combination thereof), main memory 1604, and static memory 1606, some or all of which may communicate with each other via interconnect links (e.g., bus) 1608. Machine 1600 may also include display unit 1610, numeric input device 1612 (e.g., keyboard), and user interface (UI) navigation device 1614 (e.g., mouse). In one example, display unit 1610, input device 1612, and UI navigation device 1614 may be a touchscreen display. Machine 1600 may additionally include storage device (e.g., drive unit) 1616, signal generation device 1618 (e.g., speaker), network interface device 1620, and one or more sensors 1621. Sensor 1621 may include onboard vehicle sensors or other types of vehicle sensors, such as speed sensors. Sensor 1621 may include a sensor capable of detecting position or utilizing services for detecting or determining position, such as a Global Positioning System (GPS) sensor, compass, accelerometer, or other sensor. Sensor 1621 may include a sensor capable of detecting altitude. Machine 1600 may include an output controller 1632, such as a serial (e.g., Universal Serial Bus (USB)) connection, a parallel connection, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection, to communicate with or control one or more peripheral devices (e.g., printer, card reader, etc.).

[0093] Storage device 1616 may include machine-readable medium 1622 on which one or more sets of data structures or instructions 1624 (e.g., software) embodied or utilized by any or more of the techniques or functions described herein are stored. During execution of instructions 1624 by machine 1600, these instructions may also reside wholly or at least partially in main memory 1604, static memory 1606, or processor 1602. In one example, one or any combination of processor 1602, main memory 1604, static memory 1606, or storage device 1616 may constitute a machine-readable medium.

[0094] Although machine-readable medium 1622 is shown as a single medium, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) configured to store one or more instructions 1624.

[0095] The term "machine-readable medium" can include any medium capable of storing, encoding, or carrying instructions for execution by machine 1600 and causing machine 1600 to perform any one or more techniques of this disclosure, or capable of storing, encoding, or carrying data structures used by or associated with such instructions. Examples of non-limiting machine-readable media can include solid-state memory, as well as optical and magnetic media. Specific examples of machine-readable media can include: non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable hard disks; magneto-optical disks; random access memory (RAM); and CD-ROM and DVD-ROM disks. In some examples, machine-readable media can include non-transitory machine-readable media. In some examples, machine-readable media can include machine-readable media that are not transient propagating signals.

[0096] Instruction 1624 may also be transmitted or received in communication network 1626 via network interface device 1620 using a transmission medium, wherein the transmission or reception is performed using any of a number of transmission protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). In one example, network interface device 1620 may include multiple antennas to perform wireless communication using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) technologies. In some examples, network interface device 1620 may use multi-user MIMO technology for wireless communication. The term "transmission medium" should be considered to include any intangible medium capable of storing, encoding, or carrying instructions for execution by machine 1600, and includes digital or analog communication signals or other intangible media used to facilitate communication of such software.

[0097] As used herein, the term "circuit" can refer to, may be part of, or may include: an application-specific integrated circuit (ASIC), electronic circuit, processor (shared, dedicated, or grouped), or memory (shared, dedicated, or grouped) that executes one or more software or firmware programs, combinational logic circuits, or other suitable hardware components that provide the described functions. In some aspects, a circuit may be implemented in one or more software or firmware modules, or the functions associated with the circuit may be implemented by one or more software or firmware modules. In some aspects, a circuit may include logic components that operate at least partially in hardware.

[0098] The aspects described herein can be implemented into a system using any appropriately configured hardware or software. For one aspect, Figure 17 Exemplary components of a user equipment (UE) device 1700 are shown. In some aspects, the UE device 1700 may include at least application circuitry 1702, baseband circuitry 1704, radio frequency (RF) circuitry 1706, front-end module (FEM) circuitry 1708, and one or more antennas 1710 coupled together as shown. In some aspects, the UE may be a drone or a UAV.

[0099] Application circuitry 1702 may include one or more application processors. For example, application circuitry 1702 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The one or more processors may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). These processors may be coupled to or may include memory / storage devices and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on the system.

[0100] Baseband circuitry 1704 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Baseband circuitry 1704 may include one or more baseband processors or control logic components to process baseband signals received from the receive signal path of RF circuitry 1706 and generate baseband signals for the transmit signal path of RF circuitry 1706. Baseband processing circuitry 1704 may interact with application circuitry 1702 to generate and process baseband signals and control the operation of RF circuitry 1706. For example, in some aspects, baseband circuitry 1704 may include a second-generation (2G) baseband processor 1704A, a third-generation (3G) baseband processor 1704B, a fourth-generation (4G) baseband processor 1704C, or other baseband processors 1704D for other existing generations of communication, communications under development, or future-developed communications (e.g., fifth-generation (5G), 6G, etc.). Baseband circuitry 1704 (e.g., one or more baseband processors among baseband processors 1704A-1704D) can handle various radio control functions that enable communication with one or more radio networks via RF circuitry 1706. Radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, RF shifting, etc. In some aspects, the modulation / demodulation circuitry of baseband circuitry 1704 may include Fast Fourier Transform (FFT), precoding, or constellation mapping / demapping functions. In some aspects, the encoding / decoding circuitry of baseband circuitry 1704 may include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity-check (LDPC) encoder / decoder functions. The aspects of modulation / demodulation and encoder / decoder functions are not limited to these examples, and other suitable functions may be included in other aspects.

[0101] In some aspects, the baseband circuitry 1704 may include elements of a protocol stack, such as, for example, elements of the Evolved Universal Terrestrial Radio Access Network (EUTRAN) protocol, including, for example, physical (PHY) elements, media access control (MAC) elements, radio link control (RLC) elements, packet data convergence protocol (PDCP) elements, or radio resource control (RRC) elements. The central processing unit (CPU) 1704 of the baseband circuitry 1704 may be configured to run elements of the protocol stack for signaling at the PHY, MAC, RLC, PDCP, or RRC layers. In some aspects, the baseband circuitry may include one or more audio digital signal processors (DSPs) 1704F. The audio DSP 1704F may include elements for compression / decompression and echo cancellation, and in other aspects may include other suitable processing elements. In some aspects, components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on the same circuit board. In some respects, some or all of the components of the baseband circuit 1704 and the application circuit 1702 may be implemented together on a system-on-a-chip (SOC).

[0102] In some aspects, baseband circuit 1704 can provide communication compatible with one or more radio technologies. For example, in some aspects, baseband circuit 1704 can support communication with the Evolved Universal Terrestrial Radio Access Network (EUTRAN) or other Wireless Metropolitan Area Networks (WMAN), Wireless Local Area Networks (WLAN), or Wireless Personal Area Networks (WPAN). The aspect in which baseband circuit 1704 is configured to support radio communication with more than one radio protocol may be referred to as a multi-mode baseband circuit.

[0103] RF circuit 1706 enables communication with a wireless network via a non-solid medium using modulated electromagnetic radiation. In various aspects, RF circuit 1706 may include switches, filters, amplifiers, etc., to facilitate communication with the wireless network. RF circuit 1706 may include a receive signal path, which may include circuitry for down-converting the RF signal received from FEM circuit 1708 and providing a baseband signal to baseband circuit 1704. RF circuit 1706 may also include a transmit signal path, which may include circuitry for up-converting the baseband signal provided by baseband circuit 1704 and providing an RF output signal for transmission to FEM circuit 1708.

[0104] In some aspects, RF circuit 1706 may include a receive signal path and a transmit signal path. The receive signal path of RF circuit 1706 may include mixer circuit 1706A, amplifier circuit 1706B, and filter circuit 1706C. The transmit signal path of RF circuit 1706 may include filter circuit 1706C and mixer circuit 1706A. RF circuit 1706 may also include synthesizer circuit 1706D for synthesizing the frequency used by mixer circuit 1706A in both the receive and transmit signal paths. In some aspects, mixer circuit 1706A in the receive signal path may be configured to down-convert the RF signal received from FEM circuit 1708 based on the synthesized frequency provided by synthesizer circuit 1706D. Amplifier circuit 1706B may be configured to amplify the down-converted signal, and filter circuit 1706C may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal can be provided to the baseband circuit 1704 for further processing. In some respects, although not required, the output baseband signal can be a zero-frequency baseband signal. In some respects, the mixer circuit 1706A for the received signal path can include a passive mixer, but the scope of each aspect is not limited in this respect.

[0105] In some aspects, the mixer circuit 1706A of the transmit signal path can be configured to up-convert the input baseband signal based on the synthesized frequency provided by the synthesizer circuit 1706D to generate an RF output signal for the FEM circuit 1708. The baseband signal can be provided by the baseband circuit 1704 and can be filtered by the filter circuit 1706C. The filter circuit 1706C may include a low-pass filter (LPF), but the scope of each aspect is not limited in this respect.

[0106] In some aspects, the mixer circuit 1706A for the receive signal path and the mixer circuit 1706A for the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion or upconversion, respectively. In some aspects, the mixer circuit 1706A for the receive signal path and the mixer circuit 1706A for the transmit signal path may include two or more mixers and may be arranged for image suppression (e.g., Hartley image suppression). In some aspects, the mixer circuit 1706A for the receive signal path and the mixer circuit 1706A for the transmit signal path may be arranged for direct downconversion and direct upconversion, respectively. In some aspects, the mixer circuit 1706A for the receive signal path and the mixer circuit 1706A for the transmit signal path may be configured for superheterodyne operation.

[0107] In some aspects, the output baseband signal and the input baseband signal can be analog baseband signals, although the range of aspects is not limited in this respect. In some alternative aspects, the output baseband signal and the input baseband signal can be digital baseband signals. In these alternative aspects, the RF circuit 1706 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and the baseband circuit 1704 may include a digital baseband interface for communication with the RF circuit 1706.

[0108] In some dual-mode applications, separate radio IC circuits can be provided to handle signals for each spectrum, but the range of applications is not limited in this respect.

[0109] In some respects, the synthesizer circuit 1706D can be a fractional-N synthesizer or a fractional-N / N+1 synthesizer, but the range of respects is not limited in this respect, as other types of frequency synthesizers may also be suitable. For example, the synthesizer circuit 1706D can be a Δ-∑ synthesizer, a frequency multiplier, or a synthesizer that includes a phase-locked loop with a frequency divider.

[0110] Synthesizer circuit 1706D can be configured to synthesize an output frequency based on the frequency input and the divider control input for use by mixer circuit 1706A of RF circuit 1706. In some aspects, synthesizer circuit 1706D can be a fractional N / N+1 synthesizer.

[0111] In some respects, the frequency input can be provided by a voltage-controlled oscillator (VCO), but this is not mandatory. The divider control input can be provided by the baseband circuit 1704 or the application circuit 1702 according to the desired output frequency. In some respects, the divider control input (e.g., N) can be determined from a lookup table based on the channel indicated by the application circuit 1702.

[0112] The synthesizer circuit 1706D of the RF circuit 1706 may include a frequency divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some aspects, the frequency divider may be a dual-mode divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some aspects, the DMD may be configured to divide the input signal by N or N+1 (e.g., based on the output) to provide a fractional division ratio. In some exemplary aspects, the DLL may include a set of cascaded tunable delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these aspects, the delay elements may be configured to decompose the VCO period into Nd equal groups of phases, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO period.

[0113] In some aspects, the synthesizer circuit 1706D can be configured to generate a carrier frequency as the output frequency, while in others, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and can be used with quadrature generator and frequency divider circuitry to generate multiple signals having multiple different phases relative to each other at that carrier frequency. In some aspects, the output frequency can be the LO frequency (fLO). In some aspects, the RF circuit 1706 may include an IQ / polarity converter.

[0114] FEM circuit 1708 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 1710, amplify the received signals, and provide an amplified version of the received signals to RF circuit 1706 for further processing. FEM circuit 1708 may also include a transmit signal path, which may include circuitry configured to amplify transmit signals provided by RF circuit 1706 for transmission by one or more of the one or more antennas 1710.

[0115] In some aspects, FEM circuit 1708 may include a TX / RX switch to switch between transmit and receive mode operation. FEM circuit 1708 may include a receive signal path and a transmit signal path. The receive signal path of FEM circuit 1708 may include a low-noise amplifier (LNA) to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., provided to RF circuit 1706). The transmit signal path of FEM circuit 1708 may include a power amplifier (PA) for amplifying the input RF signal (e.g., provided by RF circuit 1706); and one or more filters for generating RF signals for subsequent transmission (e.g., through one or more antennas in one or more antennas 1710).

[0116] In some respects, the UE device 1700 may include additional elements such as, for example, a memory / storage device, a display, a camera, a sensor, or an input / output (I / O) interface.

[0117] In Long Term Evolution (LTE) and 5G systems, mobile terminals (called User Equipment or UE) connect to the cellular network via base stations (BS; referred to as Evolved Node B or eNB in ​​LTE systems, and Next Generation Evolved Node B or gNB in ​​5G or NR systems). Figure 18 Examples of components of a UE 1804 and a base station (e.g., an eNB or gNB) 1800 are shown. The BS 1800 includes processing circuitry 1801 connected to a radio transceiver 1802 for providing an air interface. The UE 1804 includes processing circuitry 1806 connected to a radio transceiver 1808 for providing an air interface over a radio medium. Each transceiver in the device is connected to an antenna 1810. The antennas 1810 of the device form an antenna array whose directivity can be controlled by the processing circuitry. In the example, the antennas 1810 may be coupled to an electrical or mechanical device to tilt the antennas 1810 toward a target cell. In the example, the antennas 1810 may include at least two receiving antennas, and said at least two receiving antennas may include at least one omnidirectional antenna and at least one directional antenna for measuring a reference signal received power (RSRP) or similar value. The memory and processing circuitry of the UE or BS may be configured to perform functions and implement schemes for the aspects described herein. The UE may also be configured to operate as a drone or UAV.

[0118] Any radio link described herein may operate according to any one or more of the following radio communication technologies or standards, including but not limited to: Global System for Mobile Communications (GSM) radio communication technology, General Packet Radio Service (GPRS) radio communication technology, Enhanced Data Rate GSM Evolution (EDGE) radio communication technology, or 3rd Generation Partnership Project (3GPP) radio communication technologies, such as Universal Mobile Telecommunications System (UMTS), Free Mobile Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), and 3GPP Long Term Evolution Plus (LTE-3GPP Plus). Advanced, Code Division Multiple Access 2000 (CDMA2000), Cellular Digital Packet Data (CDPD), Mobitex, 3G, Circuit Switched Data (CSD), High-Speed ​​Circuit Switched Data (HSCSD), Universal Mobile Telecommunications System (3G) (UMTS(3G)), Wideband Code Division Multiple Access (W-CDMA(UMTS)), High-Speed ​​Packet Access (HSPA), High-Speed ​​Downlink Packet Access (HSDPA), High-Speed ​​Uplink Packet Access (HSUPA), Enhanced High-Speed ​​Packet Access (HSPA+), Universal Mobile Telecommunications System-Time Division Duplex (UMTS-TDD), Time Division Duplex-Code Division Multiple Access (TD-CDMA), Time Division-Synchronous Code Division Multiple Access (TD-CDMA), 3GPP Rel.8 (before 4G), 3GPP Rel.9 (3GPP Rel.9), 3GPP Rel.10 (3GPP Rel.10), 3GPP Rel.11 (3GPP Release 11), 3GPP Rel.12 (3GPP Release 12), 3GPP Rel.13 (3GPP Release 13), 3GPP Rel.14 (3GPP Release 14), 3GPP Rel.15 (3GPP Release 15), 3GPP Rel.16 (3GPP Release 16), 3GPP Rel.17 (3GPP Release 17), and subsequent versions (such as Rel.18, Rel.16).19, etc.), 3GPP 5G, 3GPP LTE Extra, LTE-Advanced Pro, LTE Licensed Assisted Access (LAA), MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), Long Term Evolution (4th Generation) (LTE Advanced (4G)), cdmaOne (2G), Code Division Multiple Access 2000 (3rd Generation) (CDMA2000 (3G)), Evolved Data Optimized or Evolved Data Dedicated (EV-DO), Advanced Mobile Telephone System (1st Generation) (AMPS (1G)), Total Access Communication System / Extended Total Access Communication System (TACS / ETACS), Digital AMPS (2nd Generation) (D-AMPS (2G)), Push-to-Talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), OLT (Offentlig Landmobile) Telefoni (Norwegian for public land mobile phone), MTD (Swedish abbreviation for Mobile Telephone System D, or Mobile Telephone System D), Autotel / PALM (Public Automatic Land Mobile), ARP (Finnish for Autoradiopuhelin, "Car Radio Telephone"), NMT (Nordic Mobile Telephone), High Capacity Version of NTT (Nippon Telegraph and Telephone) (Hicap), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular Telephone (PDC), Circuit Switched Data (CSD), Personal Handheld Telephone System (PHS), Broadband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA) (also known as 3GPP Universal Access Network or GAN standard), Zigbee, Bluetooth®, Wireless Gigabit Alliance (WiGig) standard, Millimeter Wave General Standard (Wireless systems operating in the 10GHz-300GHz and above frequency bands, such as WiGig, IEEE 802.11ad, IEEE Technologies operating in the 300GHz and THz frequency bands (based on 3GPP / LTE, or IEEE 802.11p, etc.), vehicle-to-vehicle (V2V) communication technology, vehicle-to-the-world (V2X) communication technology, vehicle-to-infrastructure (V2I) communication technology, infrastructure-to-vehicle (I2V) communication technology, 3GPP cellular V2X, DSRC (Dedicated Short Range Communication) communication systems (such as intelligent transportation systems, typically operating in the 5850MHz to 5925MHz range), and the European ITS-G5 system (i.e., the European version based on IEEE 802).DSRC for 11p includes ITS-G5A (operation of ITS-G5 in the European ITS band for safety-related applications within the frequency range of 5,875 GHz to 5,905 GHz), ITS-G5B (operation of ITS-G5B in the European ITS band for non-safety applications within the frequency range of 5,855 GHz to 5,875 GHz), ITS-G5C (operation of ITS applications within the frequency range of 5,470 GHz to 5,725 GHz), and DSRC in the Japanese 700 MHz band (including 715 MHz to 725 MHz), etc.

[0119] The terms described herein can be used in the context of any spectrum management scheme, including dedicated licensed spectrum, unlicensed spectrum, and (licensed) shared spectrum (such as LSA, i.e., licensed shared access at 2.3GHz-2.4GHz, 3.4GHz-3.6GHz, 3.6GHz-3.8GHz and other frequencies, and SAS, i.e., Spectrum Access System / CBRS, i.e., citizen broadband radio system at 3.55GHz-3.7GHz and other frequencies). Applicable spectrum bands include IMT (International Mobile Telecommunications) spectrum and other types of spectrum / bands, such as nationally allocated bands.

[0120] To better illustrate the methods and apparatus disclosed herein, a non-limiting list of embodiments is provided herein.

[0121] Example 1 is an autonomous vehicle distributed service system, which includes: a content delivery network device for receiving service content datasets from cloud devices; and a mobile edge computing device for: receiving service content datasets from the content delivery network device; generating service advertising datasets based on the service content datasets; and providing service access to autonomous vehicles based on the service advertising datasets.

[0122] In Example 2, the subject matter of Example 1 optionally includes a service content dataset comprising at least one of the following: a high-definition vehicle navigation dataset, a smart parking service dataset, a vehicle software update dataset, a vehicle firmware update dataset, a vehicle security patch dataset, a location-based traffic dataset, a location-based weather dataset, an entertainment service dataset, and an office service dataset.

[0123] In Embodiment 3, the subject matter of any one or more of Embodiments 1 to 2 optionally includes a roadside unit for: receiving a service advertising dataset from a mobile edge computing device; and receiving a service subscription dataset from an autonomous vehicle, wherein the provision of service access is based on the service subscription dataset.

[0124] In Embodiment 4, the subject matter of Embodiment 3 optionally includes the mobile edge computing device further configured to: provide a generated service advertising dataset to an autonomous vehicle; and receive a service subscription dataset from the autonomous vehicle, wherein the provision of service access is based on the service subscription dataset.

[0125] In Embodiment 5, the subject matter of any one or more of Embodiments 3 to 4 optionally includes an edge node device for: providing a service advertising dataset to an autonomous vehicle; receiving a service subscription dataset from the autonomous vehicle; and authenticating service access for the autonomous vehicle based on the service subscription dataset.

[0126] In Embodiment 6, the subject matter described in any one or more of Embodiments 3 to 5 optionally includes the roadside unit further configured to: provide a service advertising dataset to an autonomous vehicle; receive a service subscription dataset from the autonomous vehicle; and authenticate service access for the autonomous vehicle based on the service subscription dataset.

[0127] In Embodiment 7, the subject matter of any one or more of Embodiments 3-6 is optionally included, wherein the roadside unit is further configured to: provide a vehicle authentication request from the roadside unit to the cloud device; and receive vehicle authentication verification, wherein the provision of service access is based on vehicle authentication verification.

[0128] In Example 8, the subject matter of any one or more of Examples 5-7 is optionally included, wherein the edge node device is further configured to: provide a vehicle authentication request from the edge node device to the cloud device; and receive vehicle authentication verification, wherein the provision of service access includes sending multiple service data, which are encrypted based on vehicle authentication verification.

[0129] In Example 9, the subject matter of any one or more of Examples 1-8 optionally includes: a cloud device providing an autonomous vehicle with a one-time decryption key; an edge node device communicating with the autonomous vehicle based on messages encrypted with the one-time encryption key, the one-time decryption key providing decryption of the messages encrypted with the one-time encryption key; and a roadside unit communicating with the autonomous vehicle based on messages encrypted with the one-time encryption key.

[0130] Example 10 is a distributed service method for autonomous vehicles, comprising: receiving a service content dataset from a content delivery network device from a cloud device; receiving a service content dataset from a mobile edge computing device from the content delivery network device; generating a service advertisement dataset based on the service content dataset; and providing service access to autonomous vehicles based on the service advertisement dataset.

[0131] In Example 11, the subject matter of Example 10 optionally includes receiving a service advertising dataset from a mobile edge computing device at a roadside unit; and receiving a service subscription dataset from an autonomous vehicle at a roadside unit, wherein the provision of service access is based on the service subscription dataset.

[0132] In Example 12, the subject matter of Example 11 optionally includes providing the generated service advertising dataset to the autonomous vehicle; and receiving a service subscription dataset from the autonomous vehicle, wherein the provision of service access is based on the service subscription dataset.

[0133] In Example 13, the subject matter of any one or more of Examples 11 to 12 optionally includes providing a service advertising dataset from an edge node device to an autonomous vehicle; receiving a service subscription dataset from the autonomous vehicle; and authenticating service access for the autonomous vehicle based on the service subscription dataset.

[0134] In Example 14, the subject matter of any one or more of Examples 11 to 13 optionally includes providing a service advertising dataset to an autonomous vehicle; receiving a service subscription dataset from an autonomous vehicle; and authenticating service access for the autonomous vehicle based on the service subscription dataset.

[0135] In Example 15, the subject matter of any one or more of Examples 11-14 optionally includes providing a vehicle authentication request from a roadside unit to a cloud device; and receiving vehicle authentication verification, wherein the provision of service access is based on vehicle authentication verification.

[0136] In Example 16, the subject matter of any one or more of Examples 13-15 optionally includes providing a vehicle authentication request from an edge node device to a cloud device; and receiving vehicle authentication verification, wherein the provision of service access includes sending multiple service data, which are encrypted based on vehicle authentication verification.

[0137] In Example 17, the subject matter of any one or more of Examples 10-16 optionally includes providing a one-time decryption key from a cloud device to an autonomous vehicle; wherein: the edge node device communicates with the autonomous vehicle based on a message encrypted with the one-time encryption key, the one-time decryption key providing decryption of the message encrypted with the one-time encryption key; and the roadside unit communicates with the autonomous vehicle based on a message encrypted with the one-time encryption key.

[0138] Example 18 is at least one machine-readable medium including instructions that, when executed by a computing system, cause the computing system to perform any of the methods described in Examples 10 to 17.

[0139] Example 19 is an apparatus that includes means for performing any one of the methods described in Examples 10 to 17.

[0140] Example 20 is at least one non-transitory machine-readable storage medium comprising a plurality of instructions that are executed in response to processor circuitry of a computer-controlled device, causing the computer-controlled device to: receive a service content dataset from a content delivery network device at a cloud device; receive a service content dataset from a mobile edge computing device at the content delivery network device; generate a service advertising dataset based on the service content dataset; and provide service access to an autonomous vehicle based on the service advertising dataset.

[0141] In Embodiment 21, the subject matter of Embodiment 20 optionally includes instructions to further cause the computer-controlled device to perform the following operations: receive a service advertising dataset at a roadside unit from a mobile edge computing device; and receive a service subscription dataset at the roadside unit from an autonomous vehicle, wherein the provision of service access is based on the service subscription dataset.

[0142] In embodiment 22, the subject matter of embodiment 21 optionally includes instructions to further cause the computer-controlled device to perform the following operations: provide the generated service advertising dataset to the autonomous vehicle; and receive a service subscription dataset from the autonomous vehicle, wherein the provision of service access is based on the service subscription dataset.

[0143] In Example 23, the subject matter of any one or more of Examples 21 to 22 optionally includes instructions to further cause the computer-controlled device to perform the following operations: providing a service advertising dataset from the edge node device to the autonomous vehicle; receiving a service subscription dataset from the autonomous vehicle; and authenticating service access for the autonomous vehicle based on the service subscription dataset.

[0144] In Example 24, the subject matter of any one or more of Examples 21 to 23 optionally includes instructions to further cause the computer-controlled device to perform the following operations: provide a service advertising dataset to the autonomous vehicle; receive a service subscription dataset from the autonomous vehicle; and authenticate service access for the autonomous vehicle based on the service subscription dataset.

[0145] In Example 25, the subject matter of any one or more of Examples 21-24 optionally includes instructions to further cause a computer-controlled device to perform the following operations: providing a vehicle authentication request from a roadside unit to a cloud device; and receiving vehicle authentication verification, wherein the provision of service access is based on vehicle authentication verification.

[0146] In Example 26, the subject matter of any one or more of Examples 23 to 25 optionally includes the instructions that further cause the computer-controlled device to perform the following operations: providing a vehicle authentication request from the edge node device to the cloud device; and receiving vehicle authentication verification, wherein the provision of service access includes sending multiple service data, which are encrypted based on the vehicle authentication verification.

[0147] In Example 27, the subject matter of any one or more of Examples 20-26 optionally includes instructions to further cause a computer-controlled device to perform the following operations: providing a one-time decryption key from a cloud device to an autonomous vehicle; wherein: the edge node device communicates with the autonomous vehicle based on a message encrypted with the one-time encryption key, the one-time decryption key providing decryption of the message encrypted with the one-time encryption key; and the roadside unit communicates with the autonomous vehicle based on a message encrypted with the one-time encryption key.

[0148] Example 28 is an autonomous vehicle distributed service device, comprising: means for receiving a service content dataset from a content delivery network device from a cloud device; means for receiving a service content dataset from a mobile edge computing device from the content delivery network device; means for generating a service advertisement dataset based on the service content dataset; and means for providing service access to the autonomous vehicle based on the service advertisement dataset.

[0149] In embodiment 29, the subject matter of embodiment 28 optionally includes means for receiving a service advertising dataset at a roadside unit from a mobile edge computing device; and means for receiving a service subscription dataset from an autonomous vehicle at a roadside unit, wherein the provision of service access is based on the service subscription dataset.

[0150] In embodiment 30, the subject matter of embodiment 29 optionally includes means for providing a generated service advertising dataset to an autonomous vehicle; and means for receiving a service subscription dataset from an autonomous vehicle, wherein the provision of service access is based on the service subscription dataset.

[0151] In Example 31, the subject matter of any one or more of Examples 29 to 30 optionally includes means for providing a service advertising dataset from an edge node device to an autonomous vehicle; means for receiving a service subscription dataset from an autonomous vehicle; and means for authenticating service access of the autonomous vehicle based on the service subscription dataset.

[0152] In embodiment 32, the subject matter of any one or more of embodiments 29 to 31 optionally includes means for providing a service advertising dataset to an autonomous vehicle; means for receiving a service subscription dataset from an autonomous vehicle; and means for authenticating service access of the autonomous vehicle based on the service subscription dataset.

[0153] In embodiment 33, the subject matter of any one or more of embodiments 29 to 32 optionally includes means for providing a vehicle authentication request from a roadside unit to a cloud device; and means for receiving vehicle authentication verification, wherein the provision of service access is based on vehicle authentication verification.

[0154] In embodiment 34, the subject matter of any one or more of embodiments 31 to 33 optionally includes means for providing a vehicle authentication request from an edge node device to a cloud device; and means for receiving vehicle authentication verification, wherein the provision of service access includes sending a plurality of service data, which are encrypted based on vehicle authentication verification.

[0155] In embodiment 35, the subject matter of any one or more of embodiments 28 to 34 optionally includes means for providing a one-time decryption key from a cloud device to an autonomous vehicle; wherein: the edge node device communicates with the autonomous vehicle based on a message encrypted with the one-time encryption key, the one-time decryption key providing decryption of the message encrypted with the one-time encryption key; and the roadside unit communicates with the autonomous vehicle based on a message encrypted with the one-time encryption key.

[0156] Example 36 is a service quality prediction system, comprising: an application server for receiving multiple network parameters and generating multiple vehicle service application information; and an experience quality device for: receiving multiple experience quality measurements from multiple remote devices; generating multiple network parameters based on the multiple experience quality measurements; receiving multiple vehicle service application information from the application server; and generating a vehicle wireless communication service quality dataset based on the multiple vehicle service application information and the multiple experience quality measurements.

[0157] In Example 37, the subject matter of Example 36 optionally includes further experience quality equipment for receiving multiple vehicle service application information from a vehicle, wherein the generation of the vehicle wireless communication service quality dataset is also based on multiple vehicle service application information.

[0158] In Example 38, the subject matter of Example 37 optionally includes a vehicle that includes an experience quality device.

[0159] In Example 39, the subject matter of any one or more of Examples 36 to 38 optionally includes the generation of a vehicle wireless communication service quality dataset comprising: training a machine learning model based on multiple experience quality measurements; and generating a vehicle wireless communication service quality dataset based on the trained machine learning model.

[0160] In Example 40, the subject matter of any one or more of Examples 36 to 39 optionally includes multiple remote devices including multiple remote vehicles.

[0161] In Example 41, the subject matter of any one or more of Examples 36 to 40 optionally includes: the quality of experience device includes a network reconfiguration device for receiving network reconfiguration input; and the generation of the vehicle wireless communication service quality dataset is also based on the network reconfiguration input.

[0162] In Example 42, the subject matter of Example 41 optionally includes a network reconfiguration device generating network traffic analysis output based on network reconfiguration input.

[0163] In Example 43, the subject matter of Example 42 optionally includes generating network traffic analysis output including at least one of deep packet inspection and intelligent network traffic classification.

[0164] Example 44 is a service quality prediction method, comprising: receiving multiple network parameters at an application server; generating multiple vehicle service application information at the application server; receiving multiple experience quality measurements from multiple remote devices at experience quality devices; generating multiple network parameters based on the multiple experience quality measurements; receiving multiple vehicle service application information from the application server; and generating a vehicle wireless communication service quality dataset based on the multiple vehicle service application information and the multiple experience quality measurements.

[0165] In Example 45, the subject matter of Example 44 optionally includes receiving multiple vehicle service application information from a vehicle, wherein the generation of the vehicle wireless communication service quality dataset is also based on the multiple vehicle service application information.

[0166] In Example 46, the subject matter of Example 45 optionally includes a vehicle that includes an experience quality device.

[0167] In Example 47, the subject matter of any one or more of Examples 44 to 46 optionally includes the generation of a vehicle wireless communication service quality dataset comprising: training a machine learning model based on multiple experience quality measurements; and generating a vehicle wireless communication service quality dataset based on the trained machine learning model.

[0168] In Example 48, the subject matter of any one or more of Examples 44 to 47 optionally includes the plurality of remote devices comprising a plurality of remote vehicles.

[0169] In Example 49, the subject matter of any one or more of Examples 44 to 48 optionally includes: the quality of experience device includes a network reconfiguration device for receiving network reconfiguration input; and the generation of the vehicle wireless communication service quality dataset is also based on the network reconfiguration input.

[0170] In Example 50, the subject matter of Example 49 optionally includes a network reconfiguration device generating network traffic analysis output based on network reconfiguration input.

[0171] In Example 51, the subject matter of Example 50 optionally includes generating network traffic analysis output including at least one of deep packet inspection and intelligent network traffic classification.

[0172] Example 52 is at least one machine-readable medium including instructions that, when executed by a computing system, cause the computing system to perform any of the methods described in Examples 44 to 51.

[0173] Example 53 is an apparatus that includes means for performing any one of the methods described according to Examples 44 to 51.

[0174] Example 54 is at least one non-transitory machine-readable storage medium comprising a plurality of instructions responsive to execution by processor circuitry of a computer-controlled device, causing the computer-controlled device to: receive a plurality of network parameters at an application server; generate a plurality of vehicle service application information at the application server; receive a plurality of experience quality measurements from a plurality of remote devices at an experience quality device; generate a plurality of network parameters based on the plurality of experience quality measurements; receive a plurality of vehicle service application information from the application server; and generate a vehicle wireless communication service quality dataset based on the plurality of vehicle service application information and the plurality of experience quality measurements.

[0175] In Example 55, the subject matter of Example 54 optionally includes instructions to further enable a computer-controlled device to receive multiple vehicle service application information from the vehicle, wherein the generation of the vehicle wireless communication service quality dataset is also based on the multiple vehicle service application information.

[0176] In Example 56, the subject matter of Example 55 optionally includes a vehicle that includes an experience quality device.

[0177] In Example 57, the subject matter of any one or more of Examples 54 to 56 optionally includes instructions to further enable a computer-controlled device to train a machine learning model based on multiple experience quality measurements; and to generate a vehicle wireless communication service quality dataset based on the trained machine learning model.

[0178] In Example 58, the subject matter of any one or more of Examples 54 to 57 optionally includes multiple remote devices including multiple remote vehicles.

[0179] In Example 59, the subject matter of any one or more of Examples 54 to 58 optionally includes: the quality of experience device includes a network reconfiguration device for receiving network reconfiguration input; and the generation of the vehicle wireless communication service quality dataset is also based on the network reconfiguration input.

[0180] Example 60 is a service quality prediction device, comprising: means for receiving multiple network parameters at an application server; means for generating multiple vehicle service application information at the application server; means for receiving multiple experience quality measurements from multiple remote devices at an experience quality device; means for generating multiple network parameters based on the multiple experience quality measurements; means for receiving multiple vehicle service application information from the application server; and means for generating a vehicle wireless communication service quality dataset based on the multiple vehicle service application information and the multiple experience quality measurements.

[0181] In Example 61, the subject matter of Example 60 optionally includes means for receiving multiple vehicle service application information from a vehicle, wherein the generation of the vehicle wireless communication service quality dataset is also based on the multiple vehicle service application information.

[0182] In Example 62, the subject matter of Example 61 optionally includes a vehicle that includes an experience quality device.

[0183] In Example 63, the subject matter of any one or more of Examples 60 to 62 optionally includes the generation of a vehicle wireless communication service quality dataset comprising: means for training a machine learning model based on multiple experience quality measurements; and means for generating a vehicle wireless communication service quality dataset based on the trained machine learning model.

[0184] In Example 64, the subject matter of any one or more of Examples 60 to 63 optionally includes multiple remote devices including multiple remote vehicles.

[0185] In Example 65, the subject matter of any one or more of Examples 60 to 64 optionally includes: the quality of experience device includes a network reconfiguration device for receiving network reconfiguration input; and the generation of the vehicle wireless communication service quality dataset is also based on the network reconfiguration input.

[0186] Example 66 is an optical wireless communication system, comprising: an optical transducer for converting an input signal into an optical signal; and an optical wireless communication lens for focusing the optical signal onto a region of substantially uniform light intensity.

[0187] In embodiment 67, the subject matter of embodiment 66 optionally includes an optical wireless communication lens configured to focus an optical signal onto a vehicle area.

[0188] In Example 68, the subject matter of Example 67 optionally includes a vehicle area comprising average vehicle distance and vehicle distance range.

[0189] In embodiment 69, the subject matter of any one or more of embodiments 67 to 68 optionally includes a generally elliptical region that is longer in the direction of vehicle travel and narrower perpendicular to the direction of vehicle travel.

[0190] In Embodiment 70, the subject matter of any one or more of Embodiments 66 to 69 optionally includes an optical wireless communication receiver for receiving return transmissions.

[0191] In Example 71, the subject matter of any one or more of Examples 66 to 70 optionally includes a vehicle optical receiver for receiving focused light signals.

[0192] In embodiment 72, the subject matter of embodiment 71 optionally includes a vehicle optical receiver comprising a plurality of optical detectors.

[0193] In Example 73, the subject matter of any one or more of Examples 71 to 72 optionally includes a vehicle optical receiver comprising a mechanical actuator to adjust at least a portion of the vehicle optical receiver, thereby improving the reception of the focused light signal.

[0194] Example 74 is an optical wireless communication method, comprising: converting an input signal at an optical transducer into an optical signal; and focusing the optical signal at an optical wireless communication lens onto a region of substantially uniform light intensity.

[0195] In embodiment 75, the subject matter of embodiment 74 optionally includes an optical wireless communication lens configured to focus an optical signal onto a vehicle area.

[0196] In Example 76, the subject matter of Example 75 optionally includes a vehicle area comprising average vehicle distance and vehicle distance range.

[0197] In embodiment 77, the subject matter of any one or more of embodiments 75 to 76 optionally includes a vehicle region comprising a substantially elliptical region that is longer in the direction of vehicle travel and narrower perpendicular to the direction of vehicle travel.

[0198] In embodiment 78, the subject matter of any one or more of embodiments 74 to 77 optionally includes receiving a return transmission at an optical wireless communication receiver.

[0199] In Example 79, the subject matter of any one or more of Examples 74 to 78 optionally includes receiving a focused light signal at a vehicle optical receiver.

[0200] In embodiment 80, the subject matter of embodiment 79 optionally includes a vehicle optical receiver comprising a plurality of optical detectors.

[0201] In Example 81, the subject matter of any one or more of Examples 79 to 80 optionally includes a vehicle optical receiver comprising a mechanical actuator to adjust at least a portion of the vehicle optical receiver, thereby improving the reception of the focused light signal.

[0202] Example 82 is at least one machine-readable medium including instructions that, when executed by a computing system, cause the computing system to perform any of the methods described in Examples 74 to 81.

[0203] Example 83 is an apparatus that includes means for performing any one of the methods described according to Examples 74 to 81.

[0204] Example 84 is at least one non-transitory machine-readable storage medium comprising a plurality of instructions that are executed in response to processor circuitry of a computer-controlled device, causing the computer-controlled device to: convert an input signal at an optical transducer into an optical signal; and focus the optical signal at an optical wireless communication lens onto an area of ​​substantially uniform light intensity.

[0205] In embodiment 85, the subject matter of embodiment 84 optionally includes an optical wireless communication lens configured to focus an optical signal onto a vehicle area.

[0206] In Example 86, the subject matter of Example 85 optionally includes a vehicle area comprising average vehicle distance and vehicle distance range.

[0207] In embodiment 87, the subject matter of any one or more of embodiments 85 to 86 optionally includes a generally elliptical region that is longer in the direction of vehicle travel and narrower perpendicular to the direction of vehicle travel.

[0208] In embodiment 88, the subject matter of any one or more of embodiments 84 to 87 optionally includes further enabling a computer-controlled device to receive instructions for a return transmission at an optical wireless communication receiver.

[0209] In embodiment 89, the subject matter of any one or more of embodiments 84 to 88 optionally includes instructions to further enable a computer-controlled device to receive a focused light signal at a vehicle optical receiver.

[0210] In embodiment 90, the subject matter of embodiment 89 optionally includes a vehicle optical receiver comprising a plurality of optical detectors.

[0211] In Example 91, the subject matter of any one or more of Examples 89 to 90 optionally includes a vehicle optical receiver comprising a mechanical actuator to adjust at least a portion of the vehicle optical receiver, thereby improving the reception of the focused light signal.

[0212] Example 92 is an optical wireless communication device, comprising: means for converting an input signal at an optical transducer into an optical signal; and means for focusing an optical signal at an optical wireless communication lens onto a substantially uniform light intensity region.

[0213] In embodiment 93, the subject matter of embodiment 92 optionally includes an optical wireless communication lens configured to focus an optical signal onto a vehicle area.

[0214] In Example 94, the subject matter of Example 93 optionally includes a vehicle area comprising average vehicle distance and vehicle distance range.

[0215] In Example 95, the subject matter of any one or more of Examples 93 to 94 optionally includes a vehicle region comprising a substantially elliptical region that is longer in the direction of vehicle travel and narrower perpendicular to the direction of vehicle travel.

[0216] In embodiment 96, the subject matter of any one or more of embodiments 92 to 95 optionally includes means for receiving a return transmission at an optical wireless communication receiver.

[0217] In Example 97, the subject matter of any one or more of Examples 92 to 96 optionally includes means for receiving a focused light signal at a vehicle optical receiver.

[0218] In embodiment 98, the subject matter of embodiment 97 optionally includes a vehicle optical receiver comprising a plurality of optical detectors.

[0219] In Example 99, the subject matter of any one or more of Examples 97 to 98 optionally includes a vehicle optical receiver comprising a mechanical actuator to adjust at least a portion of the vehicle optical receiver, thereby improving the reception of the focused light signal.

[0220] Example 100 is at least one machine-readable medium including instructions that, when executed by a machine, cause the machine to perform any of the operations described in Examples 1 to 99.

[0221] Example 101 is an apparatus that includes means for performing any of the operations described in Examples 1 to 99.

[0222] Example 102 is a system for performing the operations of any one of Examples 1 to 99.

[0223] Example 103 is a method for performing any one of Examples 1 to 99.

[0224] The above description is intended to be illustrative, not restrictive. For example, the above examples (one or more aspects thereof) may be used in combination with each other. Other aspects may be used, as will be employed by one of ordinary skill in the art upon review of the above description. Furthermore, in the above detailed description, various features may be grouped together to simplify this disclosure. This should not be construed as expecting features disclosed in unclaimed claims to be essential to any claim. Rather, the inventive subject matter may exist in a form with fewer than all features of a particular disclosed aspect. Accordingly, the following claims are incorporated into the detailed description, each claim existing independently as a separate aspect. The scope of the aspects of this disclosure can be determined by reference to the appended claims and the full scope of their equivalents.

[0225] In this document, the terms “a” or “an” (as is common in patent documents) are used to include one or more, independent of any other instance, or the use of “at least one” or “one or more”. In this document, unless otherwise stated, the term “or” is used to indicate non-exclusivity or to make “A or B” include “A but not B”, “B but not A”, and “A and B”. In the appended claims, the terms “comprising” and “wherein” are used as common English equivalents of the corresponding terms “comprising” and “characterized by”. Similarly, in the following claims, the terms “comprising” and “comprising” are open-ended, meaning that a system, apparatus, article of manufacture, or process that includes elements other than those listed after the term in the claim is still considered to fall within the scope of the claim. Furthermore, in the following claims, the terms “first,” “second,” and “third,” etc., are used merely as labels and are not intended to impose numerical requirements on their objects.

[0226] This summary is provided to comply with Section 1.72(b) of Title 37 of the Federal Regulations, which requires a summary of the specification to enable the reader to determine the nature and purpose of the technical disclosure. It is understood that understanding the summary will not be used to limit or interpret the scope or meaning of the claims. Accordingly, the following claims are incorporated into the detailed description, wherein each claim stands independently as a separate aspect.

[0227] The above description is intended to be illustrative, not restrictive. For example, the examples (or one or more aspects thereof) described above may be used in combination with each other. Other aspects may be used, as appropriate by one of ordinary skill in the art upon review of the above description. The summary allows the reader to quickly determine the nature of the technical disclosure. This summary is provided on the understanding that the technical disclosure will not be used to interpret or limit the scope or meaning of the claims. Furthermore, in the above detailed description, various features may be grouped together to simplify this disclosure. However, the claims may not set forth every feature disclosed herein, as features of an aspect may be a subset of said features. Furthermore, an aspect may include fewer features than those disclosed in a particular example. Therefore, the following claims are incorporated herein by reference, wherein the claims stand alone as individual aspects. The scope of the subject matter disclosed herein should be determined by reference to the appended claims and the full scope of their equivalents.

Claims

1. An autonomous vehicle distributed service system, comprising: Mobile edge computing device, the mobile edge computing device being used for: Receive service content datasets from content delivery network devices; A service advertising dataset is generated based on the service content dataset, wherein the service content dataset includes at least one of a location-based traffic dataset or a location-based weather dataset. The generated service advertising dataset is provided to autonomous vehicles; Receive a service subscription dataset from the autonomous vehicle, wherein the service subscription dataset is based on the location of the autonomous vehicle; and Service access to the autonomous vehicle is provided based on the service advertising dataset, wherein the provision of service access is based on the service subscription dataset.

2. The system according to claim 1, wherein the service content dataset further includes at least one of the following: high-definition vehicle navigation dataset, intelligent parking service dataset, vehicle software update dataset, vehicle firmware update dataset, vehicle security patch dataset, entertainment service dataset, and office service dataset.

3. The system according to claim 1 further includes a roadside unit, the roadside unit being used for: Receive the service advertisement dataset from the mobile edge computing device; and The autonomous vehicle receives the service subscription dataset, wherein the provision of service access is based on the service subscription dataset.

4. The system according to claim 3 further includes an edge node device, the edge node device being used for: Provide the service advertising dataset to the autonomous vehicle; Receive the service subscription dataset from the autonomous vehicle; and Service access for the autonomous vehicle is authenticated based on the service subscription dataset.

5. The system according to claim 3, wherein the roadside unit is further configured to: Provide the service advertising dataset to the autonomous vehicle; Receive the service subscription dataset from the autonomous vehicle; and Authentication of service access for the autonomous vehicle is based on the service subscription dataset.

6. The system of claim 4, wherein the roadside unit is further configured to: The roadside unit provides a vehicle authentication request to the cloud device; and Receive vehicle authentication verification, wherein the provision of service access is based on the vehicle authentication verification.

7. The system of claim 6, wherein the edge node device is further configured to: The edge node device provides the vehicle authentication request to the cloud device; and Receive the vehicle authentication verification, wherein the provision of service access includes sending multiple service data, which are encrypted based on the vehicle authentication verification.

8. The system according to claim 4, wherein: The cloud device provides the autonomous vehicle with a one-time decryption key; The edge node device communicates with the autonomous vehicle based on messages encrypted using a one-time encryption key, the one-time decryption key providing decryption of the messages encrypted using the one-time encryption key; and The roadside unit communicates with the autonomous vehicle based on messages encrypted according to the one-time encryption key.

9. A method for delivering wireless communication to an autonomous vehicle, the method comprising: From mobile edge computing devices: Receive service content datasets from content delivery network devices; A service advertising dataset is generated based on the service content dataset, wherein the service content dataset includes at least one of a location-based traffic dataset or a location-based weather dataset. The generated service advertising dataset is provided to the autonomous vehicle; Receive a service subscription dataset from the autonomous vehicle, wherein the service subscription dataset is based on the location of the autonomous vehicle; and Service access to the autonomous vehicle is provided based on the service advertising dataset, wherein the provision of service access is based on the service subscription dataset.

10. The method of claim 9, wherein the service content dataset further comprises at least one of the following: a high-definition vehicle navigation dataset, a smart parking service dataset, a vehicle software update dataset, a vehicle firmware update dataset, a vehicle security patch dataset, an entertainment service dataset, or an office service dataset.

11. The method of claim 9, further comprising: The mobile edge computing device authenticates service access for the autonomous vehicle based on the service subscription dataset.

12. The method according to claim 9, further comprising: By the mobile edge computing device: Send a vehicle authentication request to the cloud device; as well as The cloud device receives vehicle authentication verification, wherein the provision of service access is based on the vehicle authentication verification.

13. The method of claim 12, wherein providing service access includes sending a plurality of service data, the plurality of service data being encrypted based on the vehicle authentication verification.

14. The method according to claim 9, wherein: The mobile edge computing device communicates with the autonomous vehicle based on messages encrypted with a one-time encryption key, wherein a cloud device provides the autonomous vehicle with a one-time decryption key, which can be used to decrypt messages encrypted with the one-time encryption key.

15. A mobile edge computing device for use in an autonomous vehicle distributed service system, the mobile edge computing device comprising: Millimeter-wave communication hardware, configured to communicate with roadside units; Wired communication hardware, configured to communicate with a content delivery network device; as well as Processor circuitry, the processor circuitry being configured to cause the mobile edge computing device to: Receive service content datasets from the content delivery network device via the wired communication hardware; A service advertising dataset is generated based on the service content dataset, wherein the service content dataset includes at least one of a location-based traffic dataset or a location-based weather dataset. The generated service advertising dataset is provided to autonomous vehicles; Receive a service subscription dataset from the autonomous vehicle, wherein the service subscription dataset is based on the location of the autonomous vehicle; and Service access to the autonomous vehicle is provided via the millimeter-wave communication hardware based on the service advertising dataset, wherein the provision of service access is based on the service subscription dataset.

16. The mobile edge computing device of claim 15, wherein the processor circuitry is further configured to cause the mobile edge computing device to: Provide the service advertising dataset to the autonomous vehicle; Receive service subscription dataset from the autonomous vehicle; and Service access for the autonomous vehicle is authenticated based on the service subscription dataset.

17. An apparatus for delivering wireless communication to an autonomous vehicle, comprising: One or more processors; A memory that stores one or more programs, the one or more programs comprising instructions that, when executed by the one or more processors, perform the method according to any one of claims 10-14.

18. A computer-readable storage medium storing one or more programs, said one or more programs comprising instructions that, when executed by one or more processors, perform the method according to any one of claims 10-14.

19. A computer program product comprising instructions that, when executed by a processor, perform the method according to any one of claims 10-14.

20. A method performed by a mobile edge computing device for use in an autonomous vehicle distributed service system, the method comprising: Receive service content datasets from content delivery network equipment via wired communication hardware; A service advertising dataset is generated based on the service content dataset, wherein the service content dataset includes at least one of a location-based traffic dataset or a location-based weather dataset. The generated service advertising dataset is provided to autonomous vehicles; Receive a service subscription dataset from the autonomous vehicle, wherein the service subscription dataset is based on the location of the autonomous vehicle; and Service access to the autonomous vehicle is provided via millimeter-wave communication hardware based on the service advertising dataset, wherein the provision of service access is based on the service subscription dataset.

21. The method of claim 20, further comprising: Provide the service advertising dataset to the autonomous vehicle; Receive service subscription datasets from the autonomous vehicle; as well as Service access for the autonomous vehicle is authenticated based on the service subscription dataset.

22. A computer program product comprising one or more programs, said one or more programs including instructions that, when executed by one or more processors of a mobile edge computing device, cause the mobile edge computing device to perform the method according to any one of claims 20-21.

23. A computer program product comprising instructions that, when executed by a processor, perform the method according to any one of claims 20-21.

Citation Information

Patent Citations

  • CDN (content delivery network) node and CDN service system

    CN104253838A

  • Content distribution method, content update method, and related device in internet of vehicles

    CN108650657A

  • Vehicle communication

    WO2018182732A1