Roadside system based on aerial platform

Abstract

The invention relates to a roadside system based on an air platform. According to an embodiment, there is provided an electronic device comprising: a memory storing computer executable instructions; and a processor coupled to the memory and configured to execute the computer executable instructions to execute the following operations: when in a first sub-region of at least one sub-region within the coverage of the roadside system based on the air platform, executing the computer executable instructions; a first virtual roadside unit identifier is received from a first virtual roadside unit in a first virtual roadside infrastructure serving the first sub-region.

Description

Roadside system based on aerial platform Technical Field

[0001] The present disclosure relates generally to communication technology and, more particularly, to an aerial platform-based roadside system and associated methods, electronic devices, virtual infrastructure management units, and computer program media. Background Art

[0002] C-V2X (Cellular Vehicle-to-Everything) is a vehicle wireless communication technology based on the evolution of cellular network communication technologies such as 4G / 5G. It includes communication between on-board units, communication between on-board units and roadside units, communication between on-board units and pedestrian devices, and communication between on-board units and the network.

[0003] Roadside infrastructure is typically installed on traffic facilities on both sides of the road. However, in the event of a disaster such as an earthquake or a large-scale power outage, this infrastructure may be completely paralyzed. Furthermore, in some remote areas, such as mountainous areas and forested areas, roadside infrastructure is often not available.

[0004] Unmanned autonomous vehicles (such as unmanned fire trucks, unmanned ambulances, unmanned food transport vehicles, unmanned emergency rescue vehicles, etc. that maintain the basic operation of the city) are becoming more and more popular. When all or part of the ground roadside infrastructure is paralyzed, emergency roadside infrastructure is needed to ensure the orderly operation of these unmanned vehicles in the city.

[0005] In addition, temporary emergency roadside infrastructure will also be needed in situations where there is no roadside infrastructure, such as field rescue expeditions, forest disaster relief, geological exploration, etc.

[0006] Summary of the Invention

[0007] This section provides a brief overview of the present disclosure in order to provide a basic understanding of some aspects of the present disclosure. However, it should be understood that this overview is not an exhaustive overview of the present disclosure. It is not intended to identify key or important parts of the present disclosure, nor is it intended to limit the scope of the present disclosure. Its purpose is simply to provide some concepts of the present disclosure in a simplified form as a prelude to the more detailed description that will be given later.

[0008] According to one aspect of the present disclosure, an electronic device is provided, including: a memory storing computer-executable instructions; and a processor coupled to the memory and configured to execute the computer-executable instructions to perform the following operations: when in a first sub-area of ​​at least one sub-area within the coverage area of ​​an aerial platform-based roadside system (RSS), receiving a first virtual roadside unit (VRSU) in a first virtual roadside infrastructure (VRSI) serving the first sub-area. VRSU identifier.

[0009] In some embodiments, a VRSI is deployed for each sub-area by virtualizing the physical resources of the roadside infrastructure of the RSS and allocating at least a portion of the virtualized physical resources to each sub-area in the at least one sub-area, each VRSI includes a VRSU, each VRSU includes at least a portion of the hardware resources and software resources of a virtualized roadside unit (RSU), each VRSU has a corresponding VRSU identifier, and the at least one sub-area includes a first sub-area.

[0010] In some embodiments, the first VRSU identifier is associated with a first VRSI identifier and a first virtual road side computing control unit (VRSCCU) identifier of a first VRSI, the first VRSI includes a first VRSCCU, the first VRSCCU includes at least a portion of the hardware resources and software resources of a virtualized road side computing control unit, and the first VRSU identifier, the first VRSI identifier, and the first VRSCCU identifier are assigned by a virtual infrastructure management unit (VIMU) of the RSS.

[0011] In some embodiments, the resource configuration associated with the first VRSU identifier or the resource configuration associated with the first VRSCCU identifier allocated by the VIMU includes at least one of the following: a virtual CPU configuration, a virtual memory configuration, a virtual disk configuration, and a virtual network configuration.

[0012] In some embodiments, the first VRSI identifier, the first VRSU identifier, and the first VRSCCU identifier are reported by the VIMU to the Internet of Vehicles cloud control platform via a first interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform.

[0013] In some embodiments, the at least one sub-area is determined by the VIMU by: determining the at least one sub-area within the coverage of the RSS where the VRSI needs to be deployed based on at least map information related to the location of the RSS.

[0014] In some embodiments, the map information is received by the VIMU from the Internet of Vehicles cloud control platform via a second interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform.

[0015] In some embodiments, allocating at least a portion of virtualized physical resources to each sub-area of ​​the at least one sub-area to deploy a VRSI for each sub-area includes the following operations performed by the VIMU: allocating resources for the VRSI of each sub-area based on an application scenario of the at least one sub-area.

[0016] In some embodiments, allocating at least a portion of virtualized physical resources to each sub-area of ​​the at least one sub-area to deploy a VRSI for each sub-area includes the following operations performed by the VIMU: allocating resources for the VRSI of each sub-area based on historical data of the at least one sub-area.

[0017] In some embodiments, the first VRSU identifier is associated with the first VRSI identifier of the first VRSI and the first virtual roadside infrastructure resource slice type, and the first VRSU identifier, the first VRSI identifier and the first virtual roadside infrastructure resource slice type are allocated by the VIMU, and the virtual roadside infrastructure resource slice type is allocated based on the resource demand characteristics of the first sub-area.

[0018] In some embodiments, the VRSI identifier, VRSU identifier and virtual roadside infrastructure resource slice type are reported by the VIMU to the Internet of Vehicles cloud control platform via a third interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform.

[0019] In some embodiments, the resource requirement characteristics of the first sub-area include at least one of the following: latency requirement, bandwidth requirement, computing power requirement, and storage capacity requirement.

[0020] In some embodiments, the virtual roadside infrastructure resource slice type includes one of the following: balanced slice, low latency slice, large bandwidth slice, intelligent computing slice, large storage slice, high positioning accuracy slice, and high reliability slice.

[0021] In some embodiments, the processor is further configured to perform the following operations: sending driving information of a vehicle carrying the electronic device to a first VRSU; and receiving a traffic scheduling message from the first VRSU, wherein the traffic scheduling message includes a first VRSU identifier, and the traffic scheduling message includes traffic scheduling information based on the driving information sent by the electronic device and based on at least one of driving information of other vehicles sent by other electronic devices, roadside perception information from the first VRSI, and traffic light information at a target intersection.

[0022] In some embodiments, the processor is further configured to perform the following operations: sending a detection result to a first VRSU, wherein the detection result includes driving environment information detected by the electronic device via the perception device; and receiving a driving assistance message from the first VRSU, wherein the driving assistance message includes a first VRSU identifier, and the driving assistance message includes driving assistance information based on at least one of the detection result sent by the other electronic device and the detection result of the first VRSU.

[0023] In some embodiments, the processor is further configured to perform the following operations: sending a message including the first VRSU identifier to the first VRSU.

[0024] In some embodiments, the first VRSU reports service data and operation information via a V2X.RSU.INFO.UP message and a V2X.RSU.RunningInfo.UP message on an interface between an RSU associated with the first VRSU and the vehicle network cloud control platform, respectively.

[0025] According to another aspect of the present disclosure, an aerial platform-based roadside system (RSS) is provided, comprising: an aerial roadside infrastructure carrying platform (APRSI), comprising an aerial carrying facility and a roadside infrastructure carried on the aerial carrying facility, wherein the APRSI is configured to virtualize the physical resources of the roadside infrastructure; and a virtual infrastructure management unit (VIMU), configured to allocate at least a portion of the virtualized physical resources to each sub-area of ​​at least one sub-area within the coverage area of ​​the RSS to deploy a VRSI for each sub-area, each VRSI including at least a virtual roadside unit (VRSU), and each VRSU including at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).

[0026] In some embodiments, each VRSI further includes a virtual roadside computing control unit (VRSCCU), which includes at least a portion of the hardware resources and software resources of a virtualized roadside computing control unit.

[0027] In some embodiments, each VRSI includes a VRSU, a virtual roadside computing control unit (VRSCCU), traffic control equipment, and roadside sensing equipment, wherein the VRSCCU is used to provide access to the traffic control equipment and the roadside sensing equipment.

[0028] In some embodiments, the aerial carrying facility includes a tethered balloon and its supporting facilities.

[0029] In some embodiments, the roadside infrastructure includes one or more of a roadside unit, a roadside computing control unit, a traffic control device, and a roadside sensing device.

[0030] In some embodiments, the VIMU is further configured to determine, based at least on map information related to the location of the RSS, the at least one sub-area within the coverage area of ​​the RSS where the VRSI needs to be deployed.

[0031] In some embodiments, the VIMU is further configured to: report first system basic information to the Internet of Vehicles cloud control platform via a first interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform, the first system basic information including the location information, operation form and operation mode of the RSS, wherein the operation form indicates whether the RSS is in a virtual state; and receive map information from the Internet of Vehicles cloud control platform via a second interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform, the map information being determined at least based on the location information of the RSS.

[0032] In some embodiments, the VIMU is further configured to determine a virtual roadside infrastructure resource slice type for each sub-area in the at least one sub-area based on resource demand characteristics of the sub-area.

[0033] In some embodiments, the VIMU is further configured to report the second system basic information via a third interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform, where the second system basic information includes a VRSI identifier and a virtual roadside infrastructure resource slice type and a VRSU identifier associated with the VRSI identifier.

[0034] In some embodiments, the VIMU is further configured to allocate resources for the VRSI of each sub-area based on an application scenario of the at least one sub-area.

[0035] In some embodiments, the VIMU is further configured to: receive historical data of each sub-area in the at least one sub-area from the Internet of Vehicles cloud control platform via a fourth interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform; and allocate VRSI resources for the sub-area based on the historical data of each sub-area in the at least one sub-area.

[0036] In some embodiments, the VIMU is further configured to: report the third system basic information via the fifth interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform, the third system basic information includes a VRSI identifier, an associated VRSU identifier, an associated VRSCCU identifier, an associated roadside sensor device identifier, and an associated traffic control device identifier, the third system basic information also includes a VRSU resource configuration and a VRSCCU resource configuration, each of the VRSU resource configuration and the VRSCCU resource configuration includes at least one of the following: a virtual CPU configuration, a virtual memory configuration, a virtual disk configuration, and a virtual network configuration.

[0037] In some embodiments, the VRSU is configured to report service data and operation information to the Internet of Vehicles cloud control platform via a V2X.RSU.INFO.UP message and a V2X.RSU.RunningInfo.UP message on the interface between the RSU associated with the VRSU and the Internet of Vehicles cloud control platform, respectively.

[0038] In some embodiments, the VRSU is configured to transmit a VRSU identifier of the VRSU to electronic devices within the sub-area served by the VRSU.

[0039] In some embodiments, the VRSU is configured to: receive driving information about a vehicle carrying the electronic device from an electronic device within the sub-area it serves; generate traffic scheduling information based on the received driving information and based on at least one of driving information of other vehicles sent by other electronic devices within the sub-area it serves, roadside perception information from a first VRSI, and traffic light information at a target intersection; and send a traffic scheduling message containing a VRSU identifier of the VRSU and the traffic scheduling information to the electronic device.

[0040] In some embodiments, the VRSU is configured to: receive detection results from electronic devices within the sub-area it serves, the detection results including driving environment information detected by the electronic devices via a sensing device; generate driving assistance information based on the received detection results and based on at least one of the detection results sent by other electronic devices within the sub-area it serves and the detection results of the VRSU; and send a driving assistance message to the electronic device including a VRSU identifier of the VRSU and the driving assistance information.

[0041] In some embodiments, the VRSU is configured to receive a message including the VRSU identifier of the VRSU from an electronic device within the sub-area served by the VRSU.

[0042] According to another aspect of the present disclosure, a virtual infrastructure management unit (VIMU) is provided, comprising: a memory storing computer-executable instructions; and a processor coupled to the memory and configured to execute the computer-executable instructions to perform the following operations: allocating at least a portion of the physical resources of the virtualized roadside infrastructure of an aerial platform-based roadside system (RSS) to each sub-area within the coverage area of ​​the RSS to deploy a virtual roadside infrastructure (VRSI) for the sub-area, each VRSI including at least a virtual roadside unit (VRSU), and each VRSU including at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).

[0043] According to another aspect of the present disclosure, a method performed by an electronic device is provided, including: when within a first sub-area of ​​at least one sub-area within the coverage area of ​​an aerial platform-based roadside system (RSS), receiving a first virtual roadside unit (VRSU) in a first virtual roadside infrastructure (VRSI) serving the first sub-area. The VRSU identifier is received from the first virtual roadside unit (VRSU).

[0044] According to another aspect of the present disclosure, a method performed by an aerial platform-based roadside system (RSS) is provided, comprising: virtualizing the physical resources of the roadside infrastructure by an aerial roadside infrastructure carrier platform (APRSI) comprising an aerial carrier platform and the roadside infrastructure carried on the aerial carrier platform; and deploying a VRSI for each sub-area by allocating at least a portion of the virtualized physical resources to each sub-area in at least one sub-area within the coverage area of ​​the RSS by a virtual infrastructure management unit (VIMU), each VRSI comprising at least a virtual roadside unit (VRSU), and each VRSU comprising at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).

[0045] According to another aspect of the present disclosure, a method performed by a virtual infrastructure management unit (VIMU) is provided, including: allocating at least a portion of the physical resources of the virtualized roadside infrastructure of an aerial platform-based roadside system (RSS) to each sub-area within the coverage area of ​​the RSS to deploy a virtual roadside infrastructure (VRSI) for the sub-area, each VRSI including at least a virtual roadside unit (VRSU), and each VRSU including at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).

[0046] According to another aspect of the present disclosure, a computer storage medium is provided, storing computer executable instructions, which, when executed by a processor, perform the method described above.

[0047] According to another aspect of the present disclosure, a computer program product is provided, comprising computer-executable instructions, which, when executed by a processor, perform the method described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The present disclosure may be better understood by referring to the detailed description given below in conjunction with the accompanying drawings, wherein the same or similar reference numerals are used throughout the drawings to represent the same or similar elements. All drawings, together with the following detailed description, are incorporated into and form a part of this specification and are used to further illustrate the embodiments of the present disclosure and to explain the principles and advantages of the present disclosure. Among them:

[0049] FIG1 is an exemplary overview diagram illustrating a roadside system based on an aerial platform according to an embodiment of the present disclosure.

[0050] FIG2A is a schematic deployment diagram illustrating a roadside system based on an aerial platform according to an embodiment of the present disclosure.

[0051] 2B and 2C are schematic diagrams illustrating providing virtual infrastructure services based on virtual RSUs according to an embodiment of the present disclosure.

[0052] FIG3 shows a schematic system architecture diagram of a roadside system based on an aerial platform according to an embodiment of the present disclosure.

[0053] FIG4 illustrates an exemplary message mechanism of an aerial platform-based roadside system according to an embodiment of the present disclosure.

[0054] FIG5 shows a diagram of a virtual resource slice deployment architecture according to an embodiment of the present disclosure.

[0055] FIG6 shows an exemplary flowchart of a resource allocation method for a roadside system according to an embodiment of the present disclosure.

[0056] FIG7 illustrates a fork-in-road traffic scenario assisted by a roadside subsystem according to an embodiment of the present disclosure.

[0057] FIG8 shows an exemplary flowchart of a method executed by an electronic device according to an embodiment of the present disclosure.

[0058] FIG9 illustrates a perception data sharing scenario assisted by a roadside subsystem according to an embodiment of the present disclosure.

[0059] FIG. 10 shows an exemplary flowchart of a method executed by an electronic device according to an embodiment of the present disclosure.

[0060] FIG11 shows an exemplary flowchart of a method performed by an aerial platform-based roadside system (RSS) according to an embodiment of the present disclosure.

[0061] FIG12 shows an exemplary flowchart of a method performed by a VIMU according to an embodiment of the present disclosure.

[0062] FIG. 13 is a block diagram illustrating a first example of a schematic configuration of an RSU to which the technology of the present disclosure can be applied.

[0063] FIG. 14 is a block diagram illustrating a second example of a schematic configuration of an RSU to which the technology of the present disclosure can be applied.

[0064] FIG. 15 is a block diagram illustrating an example of a schematic configuration of a smartphone to which the technology of the present disclosure can be applied.

[0065] FIG. 16 is a block diagram illustrating an example of a schematic configuration of a car navigation device to which the technology of the present disclosure can be applied.

[0066] The features and aspects of the present disclosure will be clearly understood by reading the following detailed description with reference to the accompanying drawings. DETAILED DESCRIPTION

[0067] Various exemplary embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. For the sake of clarity and conciseness, not all implementations of the embodiments are described in this specification. However, it should be noted that when implementing the embodiments of the present disclosure, many implementation-specific settings can be made according to specific needs in order to achieve the developer's specific goals. In addition, it should be understood that although the development work may be complex and laborious, for those skilled in the art who benefit from the content of this disclosure, such development and disclosure are merely routine tasks.

[0068] In addition, it should be noted that in order to avoid obscuring the present disclosure with unnecessary details, only the processing steps and / or device structures closely related to the technical solutions of the present disclosure are shown in the accompanying drawings. The following description of the exemplary embodiments is merely illustrative and is not intended to limit the present disclosure and its applications.

[0069] This specification includes references to "one embodiment" or "an embodiment." The appearance of the phrase "in one embodiment" or "in an embodiment" does not necessarily refer to the same embodiment. The particular features, structures, or characteristics may be combined in any suitable manner consistent with the present disclosure.

[0070] The term "comprising" is open-ended. As used in the appended claims, the term does not exclude additional structures or steps. Consider a claim that states: "An apparatus comprising one or more processor units..." Such a claim does not exclude the apparatus from including additional components (e.g., a network interface unit, graphics circuitry, etc.).

[0071] Various units, circuits, or other components may be described or stated as being “configured to” perform one or more tasks. In such contexts, “configured to” is used to imply a structure (e.g., circuitry) that performs the one or more tasks during operation by indicating that the unit / circuit / component includes that structure. Thus, the unit / circuit / component may be configured to perform the task even when the specified unit / circuit / component is not currently operational (e.g., not turned on). Units / circuits / components used with the “configured to” language include hardware—e.g., circuitry, memory storing program instructions executable to implement the operation, etc. Additionally, “configured to” may include a general-purpose structure (e.g., a general-purpose circuit) manipulated by software and / or firmware (e.g., an FPGA or a general-purpose processor executing software) to operate in a manner capable of performing the one or more tasks to be solved. “Configured to” may also include adjusting a manufacturing process (e.g., a semiconductor fabrication facility) to manufacture a device (e.g., an integrated circuit) suitable for implementing or performing the one or more tasks.

[0072] In this document, the terms "first," "second," etc. serve as labels for the nouns that precede them and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.).

[0073] The term "based on" is used to describe one or more factors that influence a determination. This term does not exclude additional factors that may influence the determination. That is, the determination may be based solely on these factors, or at least in part on these factors. Consider the phrase "determine A based on B." In this case, B is a factor that influences the determination of A, and the phrase does not exclude that A may also be determined based on C. In other cases, A may be determined based solely on B.

[0074] The embodiments of the present disclosure consider arranging a roadside system based on an aerial platform, carrying the roadside infrastructure (such as roadside units, roadside computing and control units, roadside traffic control equipment and roadside sensing equipment, etc.) on aerial carrying equipment such as tethered balloons, providing an aerial roadside system that is low-cost, easy to deploy, has a large coverage area and is not easily affected by changes in the ground environment.

[0075] The disclosed embodiments also consider virtualizing the physical resources (including hardware resources, software resources, etc.) of the roadside infrastructure of the aerial platform-based roadside system and allocating the virtualized physical resources on demand. For example, the physical resources (including hardware resources and software resources, etc.) of the RSU can be virtualized and divided into one or more virtual RSUs, and the physical resources (including hardware resources and software resources, etc.) of the RSCCU can be virtualized and divided into one or more virtual RSCCUs. This can provide more flexible and efficient resource allocation and improve resource utilization.

[0076] More specifically, the embodiments of the present disclosure consider determining sub-areas within the coverage of the roadside system based on the aerial platform where virtual roadside infrastructure needs to be deployed, and deploying a virtual roadside infrastructure for each determined sub-area. Virtual roadside infrastructure is deployed for each determined sub-area by allocating at least a portion of virtualized resources to the sub-area based on the application scenario, historical data, etc. of each sub-area. That is, the virtual roadside infrastructure deployed for a sub-area includes at least a portion of the virtualized resources allocated to the sub-area. Each virtual roadside infrastructure may include a virtual RSU. Each virtual roadside infrastructure may also include a virtual RSCCU and associated roadside traffic control equipment and roadside sensing equipment. This means that the resources of the same RSU or RSCCU can be used for corresponding multiple virtual roadside infrastructures in multiple sub-areas, thereby providing flexible resource configuration and efficient resource utilization.

[0077] The disclosed embodiments also propose the concept of virtual roadside infrastructure resource slicing, which involves providing virtualized resources as different types of virtual roadside infrastructure resource slices. For example, based on the resource requirements of a sub-region (e.g., latency, bandwidth, computing power, storage capacity, etc.), an appropriate virtual roadside infrastructure resource slice type can be selected. This allows for more refined resource allocation and improves overall resource utilization.

[0078] The disclosed embodiments also propose providing the roadside system with map information based at least on the roadside system's location, and using this map information to determine sub-areas where virtual roadside infrastructure deployment is required. For example, the map information may include information about road intersections, and sub-areas where virtual roadside infrastructure deployment is required can be determined based on the intersections where the virtual roadside infrastructure is required. This allows for more refined resource allocation and improves overall resource utilization, which is particularly important in resource-constrained situations.

[0079] The disclosed embodiments also propose a virtual infrastructure management unit, which is used to perform the aforementioned sub-area determination, virtualized resource management, and allocation. The disclosed embodiments also propose adding a new communication interface and corresponding message set between the virtual infrastructure management unit and the connected vehicle cloud control platform, and expanding the existing communication interface and message set between the virtual roadside unit and the connected vehicle cloud control platform.

[0080] The disclosed embodiments also contemplate the virtual roadside unit sending its identifier to the onboard unit (OVU). The virtual roadside unit and the OVU communicate using this identifier to implement services such as roadside-assisted intersection navigation, roadside-assisted perception data sharing, and roadside-assisted vehicle payment services.

[0081] FIG1 is an exemplary overview diagram illustrating a roadside system based on an aerial platform according to an embodiment of the present disclosure.

[0082] As shown in FIG1 , two roadside systems 101 and 102 based on aerial platforms are shown, wherein the roadside system 101 is arranged above urban roads or highways, and the roadside system 102 is arranged above outdoor roads such as sectors, forests, and deserts.

[0083] In Figure 1, each roadside system uses a tethered balloon as an aerial carrying device to form its aerial carrying platform.

[0084] The tethered balloon may include a sphere, a power supply subsystem, a pressure regulation subsystem, a measurement and control subsystem, a communication subsystem, a lightning protection subsystem and a ground tethering subsystem.

[0085] Those skilled in the art will appreciate that various facilities capable of achieving aerial suspension can be used as aerial carrying equipment, including but not limited to: airships, medium- and high-altitude balloons, low-altitude / ultra-low-altitude tethered balloons, drones, etc.

[0086] The aerial carrier can carry the roadside infrastructure of the roadside system. Roadside infrastructure can include roadside units, roadside computing and control units, roadside sensing equipment, and traffic control equipment. Roadside sensing equipment can include, but is not limited to, cameras (e.g., laser cameras), sensors, and radars (e.g., lidar and millimeter-wave radar). Traffic control equipment can include, but is not limited to, traffic lights and traffic warning signs.

[0087] As shown in Figure 1, each roadside system can communicate with the ground-based remote cloud control platform via a satellite relay link. The roadside system can use the C-V2X interface to communicate with the ground-based remote cloud control platform, and can also use the C-V2X interface to communicate with ground-based vehicles (e.g., onboard units).

[0088] Taking the use of tethered balloons as aerial carrying equipment as an example, different tethered balloons can be used to meet different scenario requirements.

[0089] Table 1 shows an exemplary classification of tethered balloons.

[0090] Table 1: Classification of tethered balloons

[0091] Different types of tethered balloons can carry equipment with different coverage ranges. Table 2 shows an exemplary classification table of the coverage range of the carried equipment.

[0092] Table 2: Mounted device coverage classification

[0093] According to Table 1 and Table 2, different types of tethered balloons can be selected and mounted with different equipment to meet the needs of different application scenarios.

[0094] For example, for a single intersection within a coverage radius of 500 meters, ultra-low altitude (altitude <50 meters) micro tethered balloons can be used to carry ordinary RSUs, roadside traffic control equipment such as aerial traffic lights, roadside sensing equipment such as lidar, etc., thereby providing vehicles with refined roadside infrastructure services.

[0095] For urban blocks within a coverage radius of less than 2 kilometers, small tethered balloons at low altitude (altitude <500 meters) can be used to carry enhanced aerial RSUs and roadside sensing equipment such as pan-tilt laser cameras, while supporting coverage of 3 to 4 intersections to reduce deployment and usage costs.

[0096] For temporary emergency service scenarios in suburban areas, mountainous areas, deserts, etc. with a coverage radius of more than 2 kilometers, medium and large tethered balloons at medium and low altitudes (altitude <3000 meters) can be used to mount enhanced RSUs and roadside equipment such as ultra-long-range pan-tilt laser cameras, supporting coverage of dozens of intersections, further reducing deployment and usage costs.

[0097] In some embodiments, the above mounting solutions with different combinations of altitudes can be adopted. For example, small tethered balloons are used at low altitudes to mount enhanced RSUs and roadside sensing equipment such as pan-tilt laser cameras, while micro tethered balloons are used at some intersections to mount aerial traffic lights, aerial lidars, etc. to provide enhanced roadside infrastructure services.

[0098] In other words, a roadside system's aerial carrier platform may include one or more aerial carrier devices. These aerial carrier devices may be of different types. These aerial carrier devices may be distributed in different locations and carry different devices. These aerial carrier devices may support wireless communication between each other. The aerial carrier devices may provide interfaces for coupling and communicating with the devices mounted thereon.

[0099] Deploying roadside infrastructure in the air allows for greater coverage and reduces the impact of terrestrial communication environments. Furthermore, compared to deploying roadside systems on the ground, such as via elevated platforms, aerial platforms offer lower costs, easier deployment, and greater flexibility.

[0100] FIG2A is a schematic deployment diagram illustrating a roadside system 2000 based on an aerial platform according to an embodiment of the present disclosure.

[0101] Roadside system 2000 is located at a specific geographic location and provides a specific coverage area. Within this coverage area, there may be multiple sub-areas where concentrated roadside infrastructure services are required, such as sub-area 2001 at the intersection and sub-area 2003 at the blind spot of a curve shown in FIG2A .

[0102] A virtual roadside infrastructure (VRSI) can be deployed for each sub-area. As shown in Figure 2A, VRSI 2005 is deployed for sub-area 2001, and VRSI 2007 is deployed for sub-area 2003. The VRSI may include the physical resources of the roadside system 2000 allocated to the corresponding sub-area, including hardware resources and software resources.

[0103] According to embodiments of the present disclosure, the physical resources of the roadside system 2000 can be virtualized, and at least a portion of the virtualized physical resources can be allocated to each sub-area where a VRSI is required, thereby deploying a corresponding VRSI for each sub-area. For example, the physical resources of an RSU (including hardware and software resources) can be divided into multiple virtual RSUs, and the multiple virtual RSUs can be allocated to different sub-areas.

[0104] Each virtual roadside infrastructure can include at least one virtual RSU. Each virtual RSU can include at least a portion of the physical resources (including hardware and software resources) of the corresponding roadside unit (RSU) virtualized. Resource configurations associated with a virtual RSU include, for example, virtual CPU configuration, virtual memory configuration, virtual disk configuration, and virtual network configuration.

[0105] Figures 2B and 2C illustrate schematic diagrams of providing virtual infrastructure services based on virtual RSUs according to embodiments of the present disclosure. Figure 2B illustrates a roadside system based on an aerial platform deployed over a city, including four virtual RSUs to provide roadside infrastructure services for different areas within its coverage area. Figure 2C illustrates a roadside system based on an aerial platform deployed over a forest, including three virtual RSUs to provide roadside infrastructure services for different areas within its coverage area.

[0106] Similarly, the physical resources (including hardware resources and software resources) of the RSCCU can be virtualized and divided into multiple virtual RSCCUs, and the multiple virtual RSCCUs are allocated to different sub-areas.

[0107] Each virtual roadside infrastructure may also include a virtual RSCCU and associated roadside sensing equipment and / or roadside traffic control equipment. Each VRSCCU may include at least a portion of the physical resources of the corresponding roadside computing control unit, virtualized. The virtual RSCCU is used to provide access to the associated roadside sensing equipment and / or roadside traffic control equipment.

[0108] Each virtual roadside infrastructure may also include corresponding airborne equipment.

[0109] In FIG2A , the roadside system 2000 includes four aerial carriers 201 - 204 , wherein the aerial carrier 201 is, for example, a low-altitude small tethered balloon, and the aerial carriers 202 - 204 are, for example, ultra-low-altitude micro tethered balloons.

[0110] Airborne device 201 can carry an RSU (not shown), an RSCCU (not shown), and two PTZ laser cameras E and F. Airborne device 202 can carry a traffic light A. Airborne device 203 can carry a laser radar B. Airborne device 204 can carry a laser radar C.

[0111] The RSU may be virtualized and two different virtual RSUs (with different virtual RSU identifiers) may be provided for the VRSI 2005 and the VRSI 2007. The RSCCU may be virtualized and two different virtual RSCCUs (with different virtual RSCCU identifiers) may be provided for the VRSI 2005 and the VRSI 2007.

[0112] Accordingly, VRSI 2005 may include a virtual RSU, an RSCCU, airborne devices 202 and 203, traffic light A, lidar B, and pan-tilt laser camera E. VRSI 2007 may include a virtual RSU, an RSCCU, airborne device 204, lidar C, and pan-tilt laser camera F.

[0113] In some embodiments, the determination of the sub-area where the VRSI needs to be deployed may be based on map information related to the deployment location of the roadside system (as shown in the “road map” in FIG. 2A ).

[0114] In some embodiments, the sub-area where the VRSI needs to be deployed can be manually designated based on map information related to the deployment location of the roadside system. In other words, the VRSI can be manually assigned to the determined sub-area, which may include, for example, assigning a VRSI identifier.

[0115] In other embodiments, the roadside system 2000 may automatically determine the sub-area where the VRSI needs to be deployed based on map information related to the deployment location of the roadside system. The roadside system may allocate a VRSI identifier and corresponding resources to the determined sub-area.

[0116] The map information can come from the vehicle network cloud control platform or from the map pre-stored by the roadside system 2000.

[0117] The deployment location of the roadside system can be input by the user or determined by the positioning device included in the roadside system itself.

[0118] By determining the sub-areas where VRSIs need to be deployed based on map information associated with the deployment location of the roadside system, and virtually allocating the physical resources of the roadside system as needed, flexible roadside infrastructure services that precisely adapt to needs can be provided, and resource utilization can be improved.

[0119] FIG3 shows a schematic system architecture diagram of an aerial platform-based roadside system 2000 according to an embodiment of the present disclosure.

[0120] As shown in FIG3 , the roadside system may include various roadside infrastructures, including airborne carrier equipment and roadside units (RSUs) carried by the airborne carrier equipment, computing control units, traffic control equipment, and roadside sensing equipment.

[0121] As shown in Figure 3, the physical resources (including hardware and software resources) of roadside system 2000 are virtualized to form virtual infrastructure resources. As shown in the figure, the virtual infrastructure resources may include two virtual RSUs (i.e., virtual RSU 1 and virtual RSU 2), three virtual computing control units (i.e., virtual computing control units 1-3), two traffic lights (i.e., traffic lights A and M), two pan-tilt laser cameras (i.e., pan-tilt laser cameras E and F), and two lidars (i.e., lidars B and C). Virtual infrastructure resources may also include the physical resources of unillustrated aerial carrier equipment (e.g., tethered balloons).

[0122] In this application, physical resources include both hardware devices and software configurations, as well as the physical capabilities supported by the hardware devices and software configurations (such as bandwidth, computing power, frequency bands, etc.).

[0123] As shown in Figure 3, the roadside system 2000 may also include a virtual infrastructure management unit (VIMU). The VIMU is configured to provide functions such as virtual resource management and allocation, fault handling, and is responsible for lifecycle management (such as instantiation, configuration, and shutdown) of the virtual infrastructure (VRSI), virtual roadside unit (VRSU), and virtual computing control unit (VRSCCU).

[0124] The VIMU is configured to allocate at least a portion of the physical resources of the virtualized roadside infrastructure of the RSS to each sub-area within the coverage area of ​​the roadside system where a VRSI is to be deployed, thereby deploying a corresponding virtual roadside infrastructure (VRSI) for the sub-area.

[0125] As shown in FIG3 , the VIMU may deploy virtual roadside infrastructures 2005 and 2007 for the sub-area 2001 and the sub-area 2003 shown in FIG2A , respectively.

[0126] The virtual roadside infrastructure 2005 includes a virtual RSU (i.e., virtual RSU 1), a virtual computing control unit (i.e., virtual computing control unit 1), a pan-tilt laser camera (pan-tilt laser camera E shown in Figure 2A), a laser radar (laser radar B shown in Figure 2A), a traffic light (traffic light A shown in Figure 2A), and two ultra-low-altitude tethered balloons (airborne carriers 202 and 203 shown in Figure 2A).

[0127] The virtual roadside infrastructure 2007 can include 1 virtual RSU (i.e., virtual RSU 2), 1 virtual computing control unit (i.e., virtual computing control unit 2), 1 pan-tilt laser camera (pan-tilt laser camera F shown in Figure 2A), 1 laser radar (laser radar C shown in Figure 2A) and 1 ultra-low altitude tethered balloon (airborne carrier device 204 shown in Figure 2A).

[0128] The virtual computing control unit 3 and the traffic light M in the virtual infrastructure resources in FIG3 can be allocated to other VRSIs.

[0129] The virtual infrastructure management unit can receive map information and identify sub-areas requiring service, such as sub-area 2001 including an intersection or sub-area 2003 including a blind spot along a curve, as shown in FIG2A . In some embodiments, the virtual infrastructure management unit can also directly receive information specifying the sub-area, such as location information and geographic features of the sub-area.

[0130] The virtual infrastructure management unit may receive information related to resource requirement characteristics associated with the sub-areas, such as latency, bandwidth, computing, storage, positioning accuracy, and reliability requirements determined by the application scenario. Based on the resource requirement characteristics of each sub-area, the virtual infrastructure management unit may select an appropriate virtual resource slice type for the sub-area and allocate appropriate resources.

[0131] In some embodiments, the virtual infrastructure management unit can be implemented as a software program. In other embodiments, the virtual infrastructure management unit can be implemented as a separate hardware device that can connect to and communicate with various roadside infrastructures via wired or wireless connections. In still other embodiments, the virtual infrastructure management unit can also be integrated into airborne equipment, RSUs, RSCCUs, or other devices.

[0132] As shown in Figure 3, the roadside system can communicate with the relay satellite via the C-V2X Uu interface, and the relay satellite can communicate with the IoV cloud control platform via the C-V2X Uu interface. The roadside system can communicate with the onboard unit (OBU) via the C-V2X PC5 interface, and the OBU can communicate with the IoV cloud control platform via the C-V2X Uu interface.

[0133] As shown in Figure 3, the roadside system 2000 may further include a satellite communication unit for communicating with a relay satellite. In some embodiments, the satellite communication unit may be integrated into the airborne device.

[0134] By virtualizing and allocating the physical resources of the roadside system 2000, different VRSIs can be deployed to meet the different resource requirements of different sub-areas. This can provide more precise roadside infrastructure services, improve the flexibility of roadside infrastructure deployment, and improve the resource utilization of the entire roadside system.

[0135] FIG4 illustrates an exemplary message mechanism of an aerial platform-based roadside system 2000 according to an embodiment of the present disclosure.

[0136] As shown in Figure 4, the roadside system 2000 includes a virtual infrastructure management unit (VIMU), which is configured to provide functions such as management and allocation of virtual resources, fault handling, etc., and is responsible for lifecycle management (instantiation, configuration, shutdown, etc.) of VRSU, VRSCCU, and VRSI.

[0137] Roadside system 2000 also includes virtual roadside infrastructure VRSI 2005 and VRSI 2007. VRSI 2005 includes a set of virtual RSUs (i.e., VRSU 1), a virtual RSCCU (i.e., VRSCCU 1), traffic control equipment (i.e., traffic light A), and roadside sensing equipment (i.e., pan-tilt laser camera E and lidar B). VRSI 2007 includes a set of virtual RSUs (i.e., VRSU 2), a virtual RSCCU (i.e., VRSCCU 2), and roadside sensing equipment (i.e., lidar C).

[0138] The roadside system 2000 also includes an air platform for roadside infrastructure (APRSI), which is configured to provide an operating environment for VRSU and VRSCCU, including the required hardware and software, and is configured to virtualize the physical resources of the roadside infrastructure of the roadside system 2000 into virtual resources for use by VRSU and VRSCCU.

[0139] The aerial bearer platform can provide bearer functions, such as tethered balloons to provide equipment suspension. The aerial bearer platform can provide communication functions and / or interface functions, such as various communication components (such as satellite communication and Wi-Fi communication), including power interfaces and communication interfaces to couple with roadside infrastructure. The aerial bearer platform can also provide virtualization functions to virtualize the physical resources (including hardware resources and software resources, etc.) of the roadside infrastructure carried by the platform, as shown in the three parts of hardware resources, OS Linux, and virtualization layer in Figure 5 below.

[0140] FIG5 shows a diagram of a virtual resource slice deployment architecture according to an embodiment of the present disclosure.

[0141] Figure 5 shows that a roadside system 2000 may include hardware resources such as a CPU, GPU, memory, storage devices, network equipment, and devices supporting satellite positioning, real-time kinematic (RTK) positioning, LTE / 5G communication, WiFi communication, and C-2VX communication. The roadside system also includes an operating system (OS) and a virtualization layer. The virtualization layer virtualizes the physical resources of the roadside system.

[0142] As shown in Figure 5, virtualized resources can be deployed in various types of resource slices. Table 3 shows an exemplary resource slice classification table according to an embodiment of the present disclosure.

[0143] As shown in Table 3, balanced slices offer balanced latency, bandwidth, computing, and storage capabilities, with bandwidth ranging from 10 to 100 Mbps, processing latency from 20 to 100 ms, support for image processing-level computing capabilities, terabyte-level storage or in-memory databases, meter-level positioning accuracy, and 99% reliability. Low-latency slices support latency below 20 ms; high-bandwidth slices support bandwidth exceeding 100 Mbps; intelligent computing slices support intelligent decision-making, video encoding and decoding, and big data analysis computing capabilities; large storage slices support exabytes or massive unstructured databases; high-positioning-accuracy slices support sub-meter positioning accuracy; and high-reliability slices support reliability of 99.99%.

[0144] Table 3: Resource Slice Classification

[0145] VIMU can select appropriate resource slice types for VRSI based on the resource demand characteristics of different scenarios, and deploy virtual RSU, virtual RSCCU, corresponding sensor equipment and traffic control equipment.

[0146] As shown in Figure 5, for example, for intersection scenarios (e.g., sub-area 2001 in Figure 2A), a balanced resource slice can be selected. This slice can be used to deploy, for example: one virtual RSU, which includes the C-V2X intersection vehicle guidance algorithm application and the C-V2X-related protocol stack; and one virtual RSCCU, which is used to access sensor devices and traffic control equipment, such as the pan-tilt laser camera device E, the lidar device B, and the traffic light A shown in Figure 2. This slice can support the orderly passage of vehicles through the intersection.

[0147] By providing virtualized physical resources with different types of resource slices, appropriate resource slice types can be selected based on the resource requirements of different sub-regions (such as different latency, bandwidth, computing, storage, positioning accuracy, reliability requirements, etc.). This provides flexible resource deployment and improves overall resource utilization.

[0148] Returning to Figure 4, the virtual infrastructure management unit can communicate via the newly added interface between the RSS-VIUM and the central subsystem of the vehicle network cloud control platform. For example, the VIUM sends the V2X.VIMU.INFO.UP interface message to the central subsystem, and the central subsystem sends the V2X.VIMU.INTERSECTION.DOWN interface message to the VIMU. Both the V2X.VIMU.INFO.UP interface message and the V2X.VIMU.INTERSECTION.DOWN interface message are newly added.

[0149] As shown in Figure 4, each virtual roadside unit can communicate via the interface between the central subsystem and the RSS-RSU (the roadside unit corresponding to the virtual roadside unit). For example, the VRSU sends the V2X.RSU.INFO.UP interface message to the central subsystem in the uplink, and the V2X.RSU.RunningInfo.UP interface message is sent from the central subsystem to the VRSU in the downlink. This is an extension of the existing interface between the central subsystem and the RSS-RSU and the messages transmitted on this interface.

[0150] As shown in Figure 4, the VRSU can communicate with the OBU via the existing C-V2X PC5 interface. The OBU can communicate with the central subsystem via the C-V2X Uu interface.

[0151] FIG6 shows an exemplary flowchart of a resource allocation method 6000 for a roadside system according to an embodiment of the present disclosure.

[0152] As shown in FIG6 , method 6000 includes step 6001 , in which the roadside system reports the location information of the roadside system (for example, the longitude and latitude of the location where the roadside system is deployed) to the central subsystem of the Internet of Vehicles cloud control platform.

[0153] Specifically, the VIMU may report the roadside system information table via the V2X.VIMU.INFO.UP message on the newly added interface between the RSS-VIMU and the central subsystem of the vehicle network cloud control platform.

[0154] Table 4 shows an exemplary roadside system basic information table according to an embodiment of the present disclosure. As shown in Table 4, the basic information table may include a timestamp, a system identifier (i.e., an RSS identifier), an RSS location (e.g., latitude and longitude), an operating state (indicating whether the roadside system is in a resource virtualization state), and an operating mode (normal mode, disaster recovery mode, or temporary emergency mode).

[0155] Table 4: Basic information of roadside system

[0156] After receiving the RSS basic information table, the central subsystem can select and distribute road map information within the appropriate coverage area based on different operating modes. The distributed map information can cover different radii and numbers of intersections for different operating modes. Table 5 below shows an exemplary correspondence between operating modes, map coverage radius, and number of intersections.

[0157] Table 5: Correspondence between operating modes and map information

[0158] Step 6001 also includes obtaining map information.

[0159] Specifically, VIMU can receive the regional road information table containing map information via the V2X.VIMU.INTERSECTION.DOWN message on the newly added interface between RSS-VIMU and the central subsystem of the vehicle network cloud control platform.

[0160] The map information may be based on the location information (eg, longitude and latitude) reported by the RSS. For example, the map information is information about all map slices within a certain coverage area centered on the location of the RSS.

[0161] The map information may also be based on the operating mode reported by the RSS. For example, for different operating modes, the map information is information about all map slices within different coverage areas centered around the location of the RSS.

[0162] Table 6 shows an exemplary regional road information table according to an embodiment of the present disclosure. As shown in Table 6, the regional road information table may include a fork road information list DF_IntersectionList.

[0163] The regional road information table may include a timestamp, an RSS identifier, the number of fork roads, and a fork road information list.

[0164] The intersection information list DF_IntersectionList may list the intersection identifier, location information (such as longitude and latitude), intersection type (crossroads, three-way intersection, sharp turn intersection, etc.) of each intersection, and the identifier of the map slice to which the intersection belongs.

[0165] Table 6: Regional road information table

[0166] DF_IntersectionList

[0167] Those skilled in the art will appreciate that the above are merely some examples of basic information and map information of the RSS system, and those skilled in the art may envision more, less or different information as needed.

[0168] As shown in FIG6 , method 6000 may further include step 6002 , in which the VIMU determines a sub-area where a virtual roadside infrastructure (VRSI) is to be deployed, deploys a VRSI for each determined sub-area, and reports information related to the VRSI of the determined sub-area.

[0169] The VIMU can determine the sub-areas where virtual roadside infrastructure needs to be deployed based on the map information associated with the location of the RSS. For example, all the intersections in the received map information are set as separate sub-areas where the corresponding VRSI is to be deployed.

[0170] VIMU can also determine the sub-areas where virtual roadside infrastructure needs to be deployed based on application scenarios.

[0171] For example, in an application scenario of cooperative fork-in-road traffic, it is not necessary to deploy VRSI for certain forks indicated in the map information.

[0172] For example, for an application scenario such as autonomous parking based on roadside perception, only parking lots where parking is possible are determined as sub-areas, without considering intersections such as crossroads.

[0173] Application scenarios are not limited to the intersections and blind spots at curves exemplified in this disclosure. Application scenarios may also include, but are not limited to, roadside sensing-based autonomous parking, coordinated ramp merging, coordinated intersection traffic flow, differential data services, dynamic lane management, station routing guidance services, floating vehicle data collection, slow-moving traffic warnings, vehicle platoon management, and road toll collection services. The VIMU can determine the number of VRSIs to deploy based on the number of sub-areas determined.

[0174] The VIMU may also assign a VRSI identifier, a VRSU identifier, and a location of a designated VRSU to each VRSI. The location of the VRSU may be the latitude and longitude coordinates of the fork in the road corresponding to the VRSU.

[0175] The VIMU can select an appropriate virtual drive test infrastructure resource slice type for the VRSI in each sub-area based on the resource requirements of that sub-area. Resource requirements include, but are not limited to, latency requirements, bandwidth requirements, computing power requirements, and storage capacity requirements. For example, the virtual drive test infrastructure resource slice type is selected from Table 3.

[0176] Resource requirements can be correlated with application scenarios. Different C-V2X application scenarios place varying demands on roadside infrastructure in terms of latency, bandwidth, computing, storage, positioning accuracy, and reliability. For example, autonomous driving and sensor sharing scenarios require latency as low as 3ms; sensor sharing scenarios require bandwidth as high as 1Gbps; and global road condition analysis scenarios place even higher demands on computing power, requiring rapid and accurate analysis and processing of sensory content such as video and radar signals.

[0177] For example, the VRSI 2005 for the intersection scenario shown in FIG. 2A may select balanced resource slices as shown in Table 3.

[0178] VIUM can report the roadside system basic information table containing information related to the VRSI of the determined sub-area via the V2X.VIMU.INFO.UP message on the newly added interface between VIUM and the vehicle network cloud control platform central subsystem.

[0179] Table 7 shows an exemplary roadside system basic information table according to an embodiment of the present disclosure. As shown in Table 7, the basic information table includes a timestamp, an RSS identifier, an RSS location, the number of VRSIs to be deployed, and a VRSI information list DF_VrsiList.

[0180] DF_VrsiList lists, for each VRSI, the VRSI identifier, VRSI slice type, associated fork identifier, allocated VRSU identifier, and the deployment location of the VRSU.

[0181] Table 7: Basic information of roadside system

[0182] DF_VrsiList

[0183] The method 6000 may further include step 6003, in which the VIMU receives historical data related to the sub-region.

[0184] Specifically, the VIMU may receive a regional road information table containing historical data associated with the determined sub-area from the vehicle network cloud control platform central subsystem via a V2X.VIMU.INTERSECTION.DOWN message on a newly added interface between the VIMU and the vehicle network cloud control platform central subsystem.

[0185] The historical data includes, for example, the historical road traffic volume, the historical accident frequency, etc. of each determined sub-region. The historical data is sent to the VIMU in the form of a regional road information table, for example.

[0186] Table 8 shows an exemplary regional road information table containing exemplary historical data according to an embodiment of the present disclosure.

[0187] The table may include a timestamp, RSS identifier, number of intersections, and a list of intersection history information. In the intersection history information list DF_IntersectionHistoryList, for each intersection in the sub-area, the intersection identifier, intersection traffic volume (e.g., monthly traffic volume), and intersection accident frequency (e.g., average number of traffic accidents per month) are listed.

[0188] Table 8: Regional road information table

[0189] DF_IntersectionHistoryList

[0190] The method 6000 may further include step 6004, in which the VIMU allocates virtualized physical resources to each VRSI and reports the resource allocation result.

[0191] As described above, the physical resources of the RSS's roadside infrastructure are virtualized and allocated. At least a portion of the virtualized resources can be allocated to each VRSI based on the VRSI slice type and / or historical data of each sub-region. This can include allocating a virtual RSU to each VRSI, as well as a virtual RSCCU and associated traffic control equipment and / or roadside sensing equipment. It can also include allocating airborne bearer equipment to each VRSI.

[0192] For intersections with heavy traffic volume and high accident frequency, more VRSU resources and / or VRSCCU resources can be deployed to support the deployment of more roadside sensing equipment and / or traffic control equipment.

[0193] VIMU can report the roadside system basic information table containing resource configuration results via the V2X.VIMU.INFO.UP message on the newly added interface between VIMU and the central subsystem of the Internet of Vehicles cloud control platform.

[0194] Table 9 shows a roadside system basic information table including exemplary resource configuration results according to an embodiment of the present disclosure.

[0195] As shown in Table 9, the basic information table may include a timestamp, an RSS identifier, an RSS position, a VRSI number, and a VRSI information list.

[0196] The VRSI information list DF_VrsiList lists, for each VRSI, the VRSI identifier, intersection identifier, VRSU identifier, VRSU location, VRSU resource configuration, VRSCCU identifier, VRSCCU resource configuration, sensor device configuration, and traffic control device configuration. The VRSU location is, for example, the latitude and longitude coordinates of the intersection corresponding to the VRSU.

[0197] RSU resource configuration and VRSCCU resource configuration configure the associated virtual CPU configuration, virtual memory configuration, virtual disk configuration, and virtual network configuration for each VRSU and VRSCCU.

[0198] The roadside sensing device configuration and traffic control device configuration (DF_DeviceConfigList) lists the device identifier, device name, and device address for each sensing device and each traffic control device.

[0199] Table 9: Basic information of roadside system

[0200] DF_VrsiList

[0201] DF_VResConfigList

[0202] DF_DeviceConfigList

[0203] The method 6000 may further include step 6005, in which the VIMU activates each VRSI to provide aerial roadside infrastructure services, and the VRSU reports service data and operation information.

[0204] Specifically, the VIMU can activate the VRSU and VRSCCU of each VRSI to provide aerial roadside infrastructure services.

[0205] Each VRSU can report business data and operation information respectively via the extended V2X.RSU.INFO.UP message and V2X.RSU.RunningInfo.UP message on the interface between the corresponding RSU and the central subsystem of the Internet of Vehicles cloud control platform.

[0206] Each VRSU may perform reporting periodically according to a predetermined period, or may trigger reporting in response to a predetermined event.

[0207] Table 10 shows an exemplary RSU information table including exemplary service data according to an embodiment of the present disclosure.

[0208] Table 10: RSU information table (including RSU business data)

[0209] As shown in Table 10, RSU service data may include an RSU identifier, a VRSU identifier, RSU location information, configuration data, operating form, operating mode, etc.

[0210] Table 11 shows an RSU operation information table including exemplary RSU operation information according to an embodiment of the present disclosure.

[0211] As shown in Table 11, the RSU operation information table may include a timestamp, an RSU identifier, a VRSU identifier, and device operation status information. The device operation status information includes virtual CPU operation information, virtual memory operation information, virtual disk operation information, and virtual network operation information.

[0212] Table 11: RSU operation information table (RSU operation and maintenance management)

[0213] DF_RunningInfo

[0214] FIG6 is merely an exemplary resource allocation method for a roadside system according to an embodiment of the present disclosure. Various variations of the resource allocation method for a roadside system may be conceived without departing from the teachings of the present disclosure.

[0215] In some embodiments, after the RSS device arrives on-site, it uses its positioning module to determine its location and reports it, along with the RSS's operational form and mode, to the central subsystem. The RSS receives the distributed map information and automatically determines sub-regions, deploys VRSIs, and allocates virtual resources.

[0216] In other embodiments, before the RSS equipment arrives on-site, an operator can pre-specify the location where the RSS will be deployed and the sub-regions where the VRSI will be deployed, for example, via the VIMU. The operator can also specify the resources to be allocated to the VRSI for each sub-region. Software and hardware resources are then deployed to the site to provide services according to the pre-planned plan.

[0217] In yet other embodiments, resource allocation can be re-allocated based on changes in available resources during actual operation. For example, if some equipment in a VRSI fails during RSS operation, appropriate resources can be re-allocated to each VRSI based on their resource requirements and the total available resources.

[0218] In some embodiments, resource allocation can be re-allocated based on changes in resource requirements during actual operation. For example, if the resource requirements of a VRSI increase during RSS operation, appropriate resources can be reallocated to each VRSI based on the resource requirements of each VRSI and the total available resources. For example, more VRSU resources and / or VRSCCU resources can be allocated to the VRSI with increased resource requirements, while the VRSI with decreased resource requirements can have fewer VRSU resources and / or VRSCCU resources allocated.

[0219] In some embodiments, it is not necessary to collect historical data of the sub-regions, that is, step 6003 can be omitted. In other embodiments, the cloud control platform can provide associated historical data when providing map information.

[0220] The roadside system based on the aerial platform according to the embodiment of the present disclosure can be applied to various scenarios.

[0221] FIG7 illustrates a fork-in-road traffic scenario assisted by a roadside subsystem 7000 according to an embodiment of the present disclosure.

[0222] When disasters such as earthquakes and large-scale power outages occur, the roadside infrastructure at the intersection will be completely paralyzed, causing traffic chaos. According to the roadside subsystem based on the aerial platform of the embodiment of the present disclosure, it can be used to assist autonomous driving vehicles to pass through the intersection safely and orderly.

[0223] Roadside subsystem 7000 can be, for example, the portion of drive test system 2000 shown in FIG2A that involves subarea 2001 (i.e., VRSI 2005). As shown in FIG7 , this portion includes: a low-altitude tethered balloon 201, which carries an aerial RSU (more specifically, virtual RSU 1) and camera E; and two ultra-low-altitude tethered balloons 202 and 203 near the intersection, where tethered balloon 202 carries an aerial traffic light, and tethered balloon 203 carries an aerial lidar.

[0224] The roadside subsystem 7000 can be used to assist the autonomous driving vehicles EV 1 and EV 2 to pass through the intersection safely and orderly.

[0225] Specifically, vehicles EV1 and EV2 can send vehicle driving information to the airborne RSU (more specifically, virtual RSU 1). The airborne RSU (more specifically, virtual RSU 1) generates traffic scheduling information for scheduling EV1 and EV2 to pass through the intersection based on the vehicle driving information, the airborne traffic light information of the target intersection, the driving information reported by other vehicles, and the roadside perception information of the airborne lidar, and sends the traffic scheduling information to EV1 and EV2 to schedule EV1 and EV2 to pass through the intersection safely.

[0226] FIG8 illustrates an exemplary flow chart of a method performed by an electronic device according to an embodiment of the present disclosure. The electronic device may be, for example, an in-vehicle device. The electronic device may also be a separate device capable of coupling and communicating with a vehicle. The electronic device may be, for example, an in-vehicle device of vehicle EV 1 or EV 2 in FIG7 .

[0227] As shown in Figure 8, method 8000 may include step 8001, in which the electronic device receives a first virtual roadside unit (VRSU) in a first virtual roadside infrastructure (VRSI) serving the first sub-area when the electronic device is in a first sub-area of ​​at least one sub-area within the coverage area of ​​the aerial platform-based roadside system (RSS). A first VRSU identifier is received from the first virtual roadside unit (VRSU) in the first virtual roadside infrastructure (VRSI) serving the first sub-area.

[0228] The first VRSI is, for example, VRSI 2005 in FIG. 2A , and the first VRSU identifier is, for example, an identifier of a VRSU assigned to VRSI 2005 .

[0229] As described above with reference to Figures 2A-6, a VRSU identifier can be associated with a VRSI identifier identifying a corresponding VRSI and a virtual infrastructure resource slice type selected for the VRSI. The VRSU identifier can also be associated with a VRSCCU identifier identifying a corresponding virtual roadside computing control unit (VRSCCU). The VRSI identifier, VRSU identifier, virtual infrastructure resource slice type, and VRSCCU identifier are assigned by the VIMU to the VRSI of the corresponding sub-area. The VRSU identifier and VRSCCU identifier are associated with resource configurations, including at least one of a virtual CPU configuration, a virtual memory configuration, a virtual disk configuration, and a virtual network configuration. The VRSI identifier, VRSU identifier, virtual infrastructure resource slice type, VRSCCU identifier, and associated resource configurations are reported to the connected vehicle operation and control platform by the VIMU via a newly added message (e.g., the V2X.VIMU.INFO.UP interface message) on a newly added interface between the VIMU and the connected vehicle operation and control platform. The VRSI, virtual infrastructure resource slice type, VRSU, and VRSCCU configurations are configured by the VIMU based on one or more factors, such as map information associated with the roadside system's deployment location, application scenarios, resource demand characteristics, and historical data.

[0230] Method 8000 may further include step 8003, in which the electronic device transmits driving information of the vehicle carrying the electronic device to the first VRSU. The driving information may include driving speed, driving direction, navigation route information, etc.

[0231] Method 8000 may further include step 8005, in which the electronic device receives a traffic schedule message from the first VRSU, wherein the traffic schedule message includes the first VRSU identifier, and the traffic schedule message includes traffic schedule information based on at least one of driving information transmitted by the electronic device and driving information of other vehicles transmitted by other electronic devices, roadside awareness information from the first VRSI, and traffic light information at a target intersection. The roadside awareness information from the first VRSI is, for example, obtained by a roadside sensing device of the first VRSI.

[0232] FIG9 illustrates a perception data sharing scenario assisted by a roadside subsystem 9000 according to an embodiment of the present disclosure.

[0233] Perception data sharing scenarios involve providing short-term (e.g., a few days) roadside infrastructure services in areas without roadside infrastructure, such as field rescue, forest disaster relief, geological exploration, field exploration, and field vehicle training competitions. For example, in the event of a forest fire, a temporary road infrastructure service based on the airborne disaster recovery platform can be activated for firefighting vehicles and material transport vehicles.

[0234] Roadside subsystem 9000 can be, for example, the portion of drive test system 2000 related to subarea 2005 (i.e., VRSI 2007) shown in Figure 2A . As shown in Figure 9 , this portion includes: a low-altitude tethered balloon 201 carrying an airborne RSU (more specifically, virtual RSU 2) and camera F; and an ultra-low-altitude tethered balloon 204 near a curve carrying an airborne lidar C. Roadside subsystem 9000 can assist in sharing perception data between autonomous vehicles EV 1 and EV 2.

[0235] The vehicle EV1 and the aerial RSU can detect other traffic participants (including but not limited to vehicles, pedestrians, cyclists and other targets) or abnormal road conditions in the surrounding area through their own or networked sensing devices (aerial pan-tilt camera, aerial lidar and other sensors), such as: road traffic events (such as traffic accidents), abnormal vehicle behavior (speeding, leaving the lane, driving in the wrong direction, unconventional driving and abnormal stationary state), road obstacles (such as fallen rocks, scattered objects, dead branches, etc.) and road conditions (such as water accumulation, ice, etc.).

[0236] The airborne RSU (more specifically, virtual RSU 2) receives information sensed by EV1, processes it and / or its own sensed information to generate driving assistance information, and transmits this driving assistance information to other vehicles near EV1, such as the following vehicle EV2. Based on this received driving assistance information, EV2 can proactively detect traffic participants or road anomalies outside its field of view, assisting it in making correct driving decisions.

[0237] FIG10 illustrates an exemplary flow chart of a method 1000 performed by an electronic device according to an embodiment of the present disclosure. The electronic device may be, for example, an in-vehicle device. The electronic device may also be a separate device capable of coupling and communicating with a vehicle. The electronic device may be an in-vehicle device of the vehicle EV 1 or EV 2 in FIG9 .

[0238] Method 1000 may include step 1001, in which, while within a first sub-area of ​​at least one sub-area within coverage of an aerial platform-based roadside system (RSS), the electronic device receives a first virtual roadside unit (VRSU) identifier from a first virtual roadside infrastructure (VRSI) serving the first sub-area.

[0239] The first VRSI is, for example, VRSI 2007 in FIG. 2A , and the first VRSU identifier is, for example, the identifier of the VRSU allocated to VRSI 2007 .

[0240] The method 1000 may include step 1003 , in which the electronic device sends a detection result to the first VRSU, where the detection result includes driving environment information detected by the electronic device via the sensing device.

[0241] The electronic device may perform detection and report detection results at a certain time period. The electronic device may also send the detection results to the first VRSU only when it determines that the detection results show an abnormality. The electronic device may also send the detection results in response to a request from an RSU (more specifically, virtual RSU 2).

[0242] Method 1000 may further include step 1005, in which the electronic device receives a driving assistance message from the first VRSU, wherein the driving assistance message includes a first VRSU identifier and includes driving assistance information based on at least one of a detection result sent by another electronic device and a detection result of the first VRSU.

[0243] The first VRSU may send driving assistance information only when necessary (eg, only when the first VRSU determines that abnormal environmental information affecting vehicle driving occurs). The first VRSU may provide driving assistance information to the requesting electronic device only when the electronic device requests the information.

[0244] Those skilled in the art will appreciate that, when the electronic device has a sensing capability, step 1003 may be performed, and when the electronic device does not have a sensing capability, step 1003 may not be performed.

[0245] In some cases, an electronic device may be able to communicate with an RSU (more specifically, a virtual RSU), but another electronic device nearby may not be able to communicate with the RSU and can only communicate with the electronic device. In such cases, the electronic device may transmit driving assistance information received from the RSU or its own detection results to the other electronic device.

[0246] In some embodiments, the electronic device may further send a message including the first VRSU identifier to the first VRSU.

[0247] For example, in a roadside assisted vehicle payment service scenario, the electronic device may receive a payment request message (Action-Request) from a first VRSU, the payment request message including the first VRSU identifier. In response, the electronic device may send a vehicle payment message to the first VRSU, the vehicle payment message including the first VRSU identifier.

[0248] In some embodiments, the vehicle payment message may include an action response message (Action-Response), which may define the vehicle's response message to the payment request message initiated by the first VRSU, including the vehicle identifier, the first VRSU identifier, payment information, and the operation status of the payment request message.

[0249] In some embodiments, the vehicle payment message may include a vehicle service indication (VSI), the vehicle service indication including the first VRSU identifier.

[0250] FIG11 shows an exemplary flowchart of a method 1100 performed by an aerial platform-based roadside system (RSS) according to an embodiment of the present disclosure.

[0251] As shown in FIG11 , method 1100 includes operation 1101 , in which an aerial roadside infrastructure hosting platform (APRSI) including an aerial hosting platform and roadside infrastructure hosted on the aerial hosting platform virtualizes physical resources of the roadside infrastructure.

[0252] Method 1100 may also include operation 1103, in which the virtual infrastructure management unit (VIMU) allocates at least a portion of virtualized physical resources to each sub-area within the coverage area of ​​the RSS to deploy a VRSI for each sub-area, each VRSI including at least a virtual roadside unit (VRSU), and each VRSU including at least a portion of the physical resources (including hardware resources and software resources) of the virtualized roadside unit (RSU).

[0253] FIG12 shows an exemplary flow chart of a method 1200 performed by a VIMU according to an embodiment of the present disclosure.

[0254] As shown in Figure 12, method 1200 includes step 1201, in which a virtual roadside infrastructure (VRSI) is deployed for each sub-area of ​​at least one sub-area within the coverage area of ​​an aerial platform-based roadside system (RSS) by allocating at least a portion of the physical resources of the virtualized roadside infrastructure of the RSS to the sub-area, each VRSI includes at least a virtual roadside unit (VRSU), and each VRSU includes at least a portion of the physical resources (including hardware resources and software resources) of the virtualized roadside unit (RSU).

[0255] [Exemplary Implementation of the Present Disclosure]

[0256] According to the embodiments of the present disclosure, various implementations of the concepts of the present disclosure can be envisioned, including but not limited to:

[0257] 1. An electronic device comprising:

[0258] a memory storing computer-executable instructions; and

[0259] The processor, coupled to the memory, is configured to execute the computer-executable instructions to perform the following operations:

[0260] While within a first sub-area of ​​at least one sub-area within coverage of an aerial platform-based roadside system (RSS), a first virtual roadside unit (VRSU) identifier is received from a first virtual roadside infrastructure (VRSI) serving the first sub-area.

[0261] 2. An electronic device as described in item 1, wherein a VRSI is deployed for each sub-area by virtualizing the physical resources of the roadside infrastructure of the RSS and allocating at least a portion of the virtualized physical resources to each sub-area of ​​the at least one sub-area, each VRSI includes a VRSU, each VRSU includes at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU), each VRSU has a corresponding VRSU identifier, and the at least one sub-area includes the first sub-area.

[0262] 3. The electronic device of clause 2, wherein the first VRSU identifier is associated with a first VRSI identifier of the first VRSI and a first virtual roadside computing control unit (VRSCCU) identifier,

[0263] The first VRSI includes a first VRSCCU, and the first VRSCCU includes at least a portion of hardware resources and software resources of a virtualized roadside computing control unit.

[0264] The first VRSU identifier, the first VRSI identifier, and the first VRSCCU identifier are allocated by a virtual infrastructure management unit (VIMU) of the RSS.

[0265] 4. The electronic device according to claim 3, wherein:

[0266] The resource configuration associated with the first VRSU identifier or the resource configuration associated with the first VRSCCU identifier allocated by the VIMU includes at least one of the following: a virtual CPU configuration, a virtual memory configuration, a virtual disk configuration, and a virtual network configuration.

[0267] 5. The electronic device as described in item 3, wherein the first VRSI identifier, the first VRSU identifier and the first VRSCCU identifier are reported by the VIMU to the Internet of Vehicles cloud control platform via a first interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform.

[0268] 6. The electronic device of item 2, wherein the at least one sub-area is determined by the VIMU through the following operations:

[0269] The at least one sub-area where the VRSI needs to be deployed within the coverage area of ​​the RSS is determined based at least on map information related to the location of the RSS.

[0270] 7. The electronic device according to item 6, wherein the map information is received by the VIMU from the Internet of Vehicles cloud control platform via a second interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform.

[0271] 8. The electronic device of clause 2, wherein allocating at least a portion of the virtualized physical resources to each sub-area of ​​the at least one sub-area to deploy a VRSI for each sub-area comprises the following operations performed by the VIMU:

[0272] Resources for the VRSI of each sub-area are allocated based on an application scenario of the at least one sub-area.

[0273] 9. The electronic device of clause 2, wherein allocating at least a portion of the virtualized physical resources to each sub-area of ​​the at least one sub-area to deploy a VRSI for each sub-area comprises the following operations performed by the VIMU:

[0274] Resources for the VRSI of each sub-region of the at least one sub-region are allocated based on the historical data of the sub-region.

[0275] 10. The electronic device of clause 2, wherein the first VRSU identifier is associated with a first VRSI identifier of the first VRSI and a first virtual roadside infrastructure resource slice type,

[0276] The first VRSU identifier, the first VRSI identifier and the first virtual roadside infrastructure resource slice type are allocated by the VIMU,

[0277] The virtual roadside infrastructure resource slice type is allocated based on the resource demand characteristics of the first sub-area.

[0278] 11. An electronic device as described in item 10, wherein the VRSI identifier, VRSU identifier and virtual roadside infrastructure resource slice type are reported to the Internet of Vehicles cloud control platform by the VIMU via a third interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform.

[0279] 12. The electronic device according to item 10, wherein the resource requirement characteristic of the first sub-area comprises at least one of the following:

[0280] Latency requirements,

[0281] Bandwidth requirements,

[0282] Computing power requirements, and

[0283] Storage capacity requirements.

[0284] 13. The electronic device according to item 10, wherein the virtual roadside infrastructure resource slice type includes one of the following:

[0285] Balanced slices,

[0286] Low-latency slicing,

[0287] Large bandwidth slice,

[0288] Intelligent computing slices,

[0289] Large storage slice,

[0290] High positioning accuracy slices, and

[0291] High-reliability slicing.

[0292] 14. The electronic device according to item 1, wherein the processor is further configured to perform the following operations:

[0293] sending driving information of a vehicle carrying the electronic device to a first VRSU; and

[0294] A traffic scheduling message is received from a first VRSU, wherein the traffic scheduling message includes a first VRSU identifier, and the traffic scheduling message includes traffic scheduling information based on driving information sent by the electronic device and based on at least one of driving information of other vehicles sent by other electronic devices, roadside perception information from the first VRSI, and traffic light information at a target intersection.

[0295] 15. The electronic device according to item 1, wherein the processor is further configured to perform the following operations:

[0296] sending a detection result to a first VRSU, the detection result including driving environment information detected by the electronic device via the sensing device; and

[0297] A driving assistance message is received from the first VRSU, wherein the driving assistance message includes a first VRSU identifier and includes driving assistance information based on at least one of a detection result transmitted by another electronic device and a detection result of the first VRSU.

[0298] 16. The electronic device of item 1, wherein the processor is further configured to perform the following operations:

[0299] A message including a first VRSU identifier is sent to the first VRSU.

[0300] 17. The electronic device of item 1, wherein the first VRSU reports service data and operation information via a V2X.RSU.INFO.UP message and a V2X.RSU.RunningInfo.UP message respectively on an interface between an RSU associated with the first VRSU and a vehicle network cloud control platform.

[0301] 18. A roadside system (RSS) based on an aerial platform, comprising:

[0302] An aerial roadside infrastructure hosting platform (APRSI), comprising an aerial hosting facility and a roadside infrastructure hosted on the aerial hosting facility, the APRSI being configured to virtualize physical resources of the roadside infrastructure; and

[0303] A virtual infrastructure management unit (VIMU) is configured to allocate at least a portion of virtualized physical resources to each sub-area in at least one sub-area within the coverage area of ​​the RSS to deploy a VRSI for each sub-area, each VRSI including at least a virtual roadside unit (VRSU), and each VRSU including at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).

[0304] 19. The RSS of item 18, wherein each VRSI further comprises a virtual roadside computing control unit (VRSCCU), the VRSCCU comprising at least a portion of the hardware resources and software resources of the virtualized roadside computing control unit.

[0305] 20. The RSS of item 18, wherein each VRSI comprises a VRSU, a virtual roadside computing control unit (VRSCCU), traffic control equipment, and roadside sensing equipment, wherein the VRSCCU is used to provide access to the traffic control equipment and the roadside sensing equipment.

[0306] 21. The RSS as described in item 18, wherein the aerial carrying facilities include tethered balloons and their supporting facilities.

[0307] 22. The RSS of item 19, wherein the roadside infrastructure comprises one or more of a roadside unit, a roadside computing control unit, a traffic control device, and a roadside sensing device.

[0308] 23. The RSS of clause 18, wherein the VIMU is further configured to:

[0309] The at least one sub-area where the VRSI needs to be deployed within the coverage area of ​​the RSS is determined based at least on map information related to the location of the RSS.

[0310] 24. The RSS of clause 23, wherein the VIMU is further configured to:

[0311] Reporting first system basic information to the Internet of Vehicles cloud control platform via a first interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform, where the first system basic information includes location information, operating form, and operating mode of the RSS, where the operating form indicates whether the RSS is in a virtual state; and

[0312] Map information is received from the vehicle networking cloud control platform via a second interface message on the interface between the VIMU and the vehicle networking cloud control platform, where the map information is determined based on at least the RSS location information.

[0313] 25. The RSS of clause 23, wherein the VIMU is further configured to:

[0314] Based on the resource demand characteristics of each sub-area in the at least one sub-area, a virtual roadside infrastructure resource slice type is determined for the sub-area.

[0315] 26. The RSS of clause 25, wherein the VIMU is further configured to:

[0316] The second system basic information is reported via the third interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform. The second system basic information includes the VRSI identifier and the virtual roadside infrastructure resource slice type and VRSU identifier associated with the VRSI identifier.

[0317] 27. The RSS of clause 18, wherein the VIMU is further configured to:

[0318] Resources for the VRSI of each sub-area are allocated based on an application scenario of the at least one sub-area.

[0319] 28. The RSS of clause 18, wherein the VIMU is further configured to:

[0320] Receiving historical data of each sub-area in the at least one sub-area from the connected vehicle cloud control platform via a fourth interface message on the interface between the VIMU and the connected vehicle cloud control platform;

[0321] VRSI resources for each sub-region of the at least one sub-region are allocated based on historical data of the sub-region.

[0322] 29. The RSS of clause 25, wherein the VIMU is further configured to:

[0323] Report the basic information of the third system via the fifth interface message on the interface between VIMU and the Internet of Vehicles cloud control platform,

[0324] The third system basic information includes a VRSI identifier, an associated VRSU identifier, an associated VRSCCU identifier, an associated roadside sensor device identifier, and an associated traffic control device identifier.

[0325] The third system basic information also includes VRSU resource configuration and VRSCCU resource configuration, each of the VRSU resource configuration and the VRSCCU resource configuration includes at least one of the following: virtual CPU configuration, virtual memory configuration, virtual disk configuration and virtual network configuration.

[0326] 30. The RSS of item 25, wherein the VRSU is configured to report service data and operation information to the IoV cloud control platform via a V2X.RSU.INFO.UP message and a V2X.RSU.RunningInfo.UP message on an interface between an RSU associated with the VRSU and the IoV cloud control platform, respectively.

[0327] 31. The RSS of clause 25, wherein the VRSU is configured to transmit a VRSU identifier of the VRSU to electronic devices within the sub-area served by the VRSU.

[0328] 32. The RSS of clause 31, wherein the VRSU is configured to:

[0329] receiving, from electronic devices in the sub-area served by the electronic devices, driving information of vehicles carrying the electronic devices;

[0330] Generate traffic scheduling information based on the received driving information and based on at least one of driving information of other vehicles sent by other electronic devices in the sub-area served by the VRSI, roadside awareness information from the first VRSI, and traffic light information of the target intersection; and

[0331] A traffic schedule message including a VRSU identifier of the VRSU and the traffic schedule information is sent to the electronic device.

[0332] 33. The RSS of clause 31, wherein the VRSU is configured to:

[0333] receiving a detection result from an electronic device within the sub-area served by the electronic device, the detection result including driving environment information detected by the electronic device via the sensing device;

[0334] generating driving assistance information based on the received detection results and based on at least one of detection results transmitted by other electronic devices within the sub-area served by the VRSU and the detection results of the VRSU; and

[0335] A driving assistance message including a VRSU identifier of the VRSU and the driving assistance information is sent to the electronic device.

[0336] 34. The RSS of clause 31, wherein the VRSU is configured to:

[0337] A message including a VRSU identifier of the VRSU is received from an electronic device within the sub-area served by the VRSU.

[0338] 35. A virtual infrastructure management unit (VIMU), comprising:

[0339] a memory storing computer-executable instructions; and

[0340] The processor, coupled to the memory, is configured to execute the computer-executable instructions to perform the following operations:

[0341] A virtual roadside infrastructure (VRSI) is deployed for each of at least one sub-area within the coverage area of ​​an aerial platform-based roadside system (RSS) by allocating at least a portion of the physical resources of the virtualized roadside infrastructure of the RSS to the sub-area, each VRSI including at least a virtual roadside unit (VRSU), and each VRSU including at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).

[0342] 36. A method performed by an electronic device, comprising:

[0343] While within a first sub-area of ​​at least one sub-area within coverage of an aerial platform-based roadside system (RSS), a first virtual roadside unit (VRSU) identifier is received from a first virtual roadside infrastructure (VRSI) serving the first sub-area.

[0344] 37. A method performed by an aerial platform-based roadside system (RSS), comprising:

[0345] Virtualizing physical resources of the roadside infrastructure by an aerial roadside infrastructure hosting platform (APRSI) including an aerial hosting platform and roadside infrastructure hosted on the aerial hosting platform; and

[0346] A virtual infrastructure management unit (VIMU) allocates at least a portion of virtualized physical resources to each sub-area within the coverage area of ​​the RSS to deploy a VRSI for each sub-area, each VRSI includes at least a virtual roadside unit (VRSU), and each VRSU includes at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).

[0347] 38. A method performed by a virtual infrastructure management unit (VIMU), comprising:

[0348] A virtual roadside infrastructure (VRSI) is deployed for each of at least one sub-area within the coverage area of ​​an aerial platform-based roadside system (RSS) by allocating at least a portion of the physical resources of the virtualized roadside infrastructure of the RSS to the sub-area, each VRSI including at least a virtual roadside unit (VRSU), and each VRSU including at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).

[0349] 39. A computer storage medium storing computer executable instructions which, when executed by a processor, perform the method of any one of items 36-38.

[0350] 40. A computer program product comprising computer executable instructions which, when executed by a processor, perform the method of any one of items 36-38.

[0351] Application examples according to the present disclosure will be described below.

[0352] Application examples according to the present disclosure will be described below.

[0353] The technology of the present disclosure can be applied to various products.

[0354] The roadside unit disclosed herein can be implemented, for example, using a roadside unit (RSU) in a vehicle network.

[0355] The electronic device disclosed herein may be implemented using, for example, a terminal device.

[0356] For example, the terminal device can be implemented as a mobile terminal (such as a smart phone, a tablet personal computer (PC), a notebook PC, a portable game terminal, a portable / dongle-type mobile router, and a digital camera) or an in-vehicle terminal (such as a car navigation device). The terminal device can also be implemented as a terminal that performs machine-to-machine (M2M) communication (also known as a machine type communication (MTC) terminal). In addition, the terminal device can be a wireless communication module (such as an integrated circuit module including a single chip) installed on each of the above-mentioned terminals.

[0357] [Application examples of RSU]

[0358] (First application example)

[0359] 13 is a block diagram showing a first example of a schematic configuration of an RSU to which the technology of the present disclosure can be applied. The RSU 800 includes one or more antennas 810 and a roadside device 820. The roadside device 820 and each antenna 810 can be connected to each other via an RF cable.

[0360] Each antenna 810 includes a single or multiple antenna elements (such as the multiple antenna elements included in a multiple-input, multiple-output (MIMO) antenna) and is used for transmitting and receiving wireless signals for the roadside device 820. As shown in FIG13 , the RSU 800 may include multiple antennas 810. For example, the multiple antennas 810 may be compatible with multiple frequency bands used by the RSU 800. The roadside device 820 includes a controller 821, a memory 822, a network interface 823, and a wireless communication interface 825.

[0361] The controller 821 may be, for example, a CPU or a DSP, and operates various functions of the higher layers of the roadside device 820. For example, the controller 821 generates data packets based on data in the signal processed by the wireless communication interface 825, and transmits the generated packets via the network interface 823. The controller 821 may bundle data from a plurality of baseband processors to generate bundled packets, and transmit the generated bundled packets. The controller 821 may have logic functions for performing controls such as radio resource control, radio bearer control, mobility management, admission control, and scheduling. The control may be performed in conjunction with a nearby RSU or core network node (e.g., an access and mobility management function AMF (Access and Mobility Management Function)). The memory 822 includes RAM and ROM, and stores programs executed by the controller 821 and various types of control data (such as a terminal list, transmission power data, and scheduling data).

[0362] The network interface 823 is a communication interface for connecting the roadside device 820 to the core network 824. The controller 821 can communicate with the core network node or another RSU via the network interface 823. In this case, the RSU 800 and the core network node or other RSU can be connected to each other through a logical interface (such as a C-V2X uu interface or a C-V2X PC5). The network interface 823 can also be a wired communication interface or a wireless communication interface for a wireless backhaul line. If the network interface 823 is a wireless communication interface, the network interface 823 can use a higher frequency band for wireless communication than the frequency band used by the wireless communication interface 825.

[0363] The wireless communication interface 825 supports any cellular communication scheme and provides wireless connectivity to terminals located in the cell of the RSU 800 via the antenna 810. The wireless communication interface 825 may typically include, for example, a baseband (BB) processor 826 and an RF circuit 827. The BB processor 826 may perform various types of signal processing, such as encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and may perform various types of signal processing for layers such as L1, medium access control (MAC), radio link control (RLC), and packet data convergence protocol (PDCP). In place of the controller 821, the BB processor 826 may have some or all of the aforementioned logical functions. The BB processor 826 may be a memory that stores communication control programs, or a module that includes a processor configured to execute programs and associated circuitry. Updating the program may modify the functionality of the BB processor 826. The module may be a card or blade inserted into a slot of the roadside equipment 820. Alternatively, the module may be a chip mounted on the card or blade. Meanwhile, the RF circuit 827 may include, for example, a mixer, a filter, and an amplifier, and transmit and receive wireless signals via the antenna 810 .

[0364] As shown in FIG13 , the wireless communication interface 825 may include multiple BB processors 826. For example, multiple BB processors 826 may be compatible with multiple frequency bands used by the RSU 800. As shown in FIG13 , the wireless communication interface 825 may include multiple RF circuits 827. For example, multiple RF circuits 827 may be compatible with multiple antenna elements. Although FIG13 illustrates an example in which the wireless communication interface 825 includes multiple BB processors 826 and multiple RF circuits 827, the wireless communication interface 825 may also include a single BB processor 826 or a single RF circuit 827.

[0365] (Second application example)

[0366] FIG14 is a block diagram illustrating a second example of a schematic configuration of an RSU to which the techniques of the present disclosure may be applied. The RSU includes one or more antennas 840, a roadside device 850, and an RRH 860. The RRH 860 and each antenna 840 may be connected to each other via an RF cable. The roadside device 850 and the RRH 860 may be connected to each other via a high-speed line such as an optical fiber cable.

[0367] Each of the antennas 840 includes a single or multiple antenna elements (such as multiple antenna elements included in a MIMO antenna) and is used for the RRH 860 to transmit and receive wireless signals. As shown in FIG14 , the RSU 830 may include multiple antennas 840. For example, the multiple antennas 840 may be compatible with multiple frequency bands used by the RSU 830. The roadside equipment 850 includes a controller 851, a memory 852, a network interface 853, a wireless communication interface 855, and a connection interface 857. The controller 851, the memory 852, and the network interface 853 are the same as the controller 821, the memory 822, and the network interface 823 described with reference to FIG13 .

[0368] The wireless communication interface 855 supports any cellular communication scheme and provides wireless communication to terminals located in the sector corresponding to the RRH 860 via the RRH 860 and the antenna 840. The wireless communication interface 855 may generally include, for example, a BB processor 856. The BB processor 856 is the same as the BB processor 826 described with reference to FIG13, except that the BB processor 856 is connected to the RF circuit 864 of the RRH 860 via the connection interface 857. As shown in FIG14, the wireless communication interface 855 may include multiple BB processors 856. For example, multiple BB processors 856 may be compatible with multiple frequency bands used by the RSU 830. Although FIG14 shows an example in which the wireless communication interface 855 includes multiple BB processors 856, the wireless communication interface 855 may also include a single BB processor 856.

[0369] The connection interface 857 is an interface for connecting the roadside device 850 (wireless communication interface 855) to the RRH 860. The connection interface 857 may also be a communication module for connecting the roadside device 850 (wireless communication interface 855) to the RRH 860 for communication in the high-speed line.

[0370] The RRH 860 includes a connection interface 861 and a wireless communication interface 863 .

[0371] The connection interface 861 is an interface for connecting the RRH 860 (wireless communication interface 863) to the roadside apparatus 850. The connection interface 861 may also be a communication module for communication in the above-mentioned high-speed line.

[0372] The wireless communication interface 863 transmits and receives wireless signals via the antenna 840. The wireless communication interface 863 may generally include, for example, an RF circuit 864. The RF circuit 864 may include, for example, a mixer, a filter, and an amplifier, and transmits and receives wireless signals via the antenna 840. As shown in FIG14 , the wireless communication interface 863 may include multiple RF circuits 864. For example, the multiple RF circuits 864 may support multiple antenna elements. Although FIG14 shows an example in which the wireless communication interface 863 includes multiple RF circuits 864, the wireless communication interface 863 may also include a single RF circuit 864.

[0373] In the RSUs 800 and 830 shown in Figures 13 and 14 , one or more components included in the processing circuit 1310 described with reference to Figure 13 and the processing circuit 1610 described with reference to Figure 16 may be implemented in the wireless communication interface 912. Alternatively, at least some of these components may also be implemented by the controller 821 and the controller 851.

[0374] [Application examples for terminal devices]

[0375] (First application example)

[0376] 15 is a block diagram showing an example of a schematic configuration of a smartphone 900 to which the technology of the present disclosure can be applied. The smartphone 900 includes a processor 901, a memory 902, a storage device 903, an external connection interface 904, a camera 906, a sensor 907, a microphone 908, an input device 909, a display device 910, a speaker 911, a wireless communication interface 912, one or more antenna switches 915, one or more antennas 916, a bus 917, a battery 918, and an auxiliary controller 919.

[0377] The processor 901 may be, for example, a CPU or a system on a chip (SoC), and controls the functions of the application layer and other layers of the smartphone 900. The memory 902 includes RAM and ROM, and stores data and programs executed by the processor 901. The storage device 903 may include storage media such as semiconductor memories and hard disks. The external connection interface 904 is an interface for connecting external devices (such as memory cards and universal serial bus (USB) devices) to the smartphone 900.

[0378] The camera 906 includes an image sensor such as a charge coupled device (CCD) and a complementary metal oxide semiconductor (CMOS) and generates a captured image. The sensor 907 may include a group of sensors such as a measurement sensor, a gyroscope sensor, a geomagnetic sensor, and an acceleration sensor. The microphone 908 converts the sound input to the smartphone 900 into an audio signal. The input device 909 includes, for example, a touch sensor, a keypad, a keyboard, a button, or a switch configured to detect a touch on the screen of the display device 910, and receives an operation or information input from the user. The display device 910 includes a screen such as a liquid crystal display (LCD) and an organic light emitting diode (OLED) display and displays an output image of the smartphone 900. The speaker 911 converts the audio signal output from the smartphone 900 into sound.

[0379] The wireless communication interface 912 supports any cellular communication scheme (such as LTE and LTE-Advanced) and performs wireless communication. The wireless communication interface 912 may generally include, for example, a BB processor 913 and an RF circuit 914. The BB processor 913 may perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and perform various types of signal processing for wireless communication. Meanwhile, the RF circuit 914 may include, for example, a mixer, a filter, and an amplifier, and transmit and receive wireless signals via an antenna 916. The wireless communication interface 912 may be a chip module on which the BB processor 913 and the RF circuit 914 are integrated. As shown in FIG15 , the wireless communication interface 912 may include multiple BB processors 913 and multiple RF circuits 914. Although FIG15 shows an example in which the wireless communication interface 912 includes multiple BB processors 913 and multiple RF circuits 914, the wireless communication interface 912 may also include a single BB processor 913 or a single RF circuit 914.

[0380] In addition, in addition to the cellular communication scheme, the wireless communication interface 912 can support other types of wireless communication schemes, such as a short-range wireless communication scheme, a near-field communication scheme, and a wireless local area network (LAN) scheme. In this case, the wireless communication interface 912 may include a BB processor 913 and an RF circuit 914 for each wireless communication scheme.

[0381] Each of the antenna switches 915 switches a connection destination of the antenna 916 between a plurality of circuits (eg, circuits for different wireless communication schemes) included in the wireless communication interface 912 .

[0382] Each of the antennas 916 includes a single or multiple antenna elements (such as multiple antenna elements included in a MIMO antenna) and is used for transmitting and receiving wireless signals via the wireless communication interface 912. As shown in FIG15 , the smartphone 900 may include multiple antennas 916. Although FIG15 shows an example in which the smartphone 900 includes multiple antennas 916, the smartphone 900 may also include a single antenna 916.

[0383] In addition, the smartphone 900 may include an antenna 916 for each wireless communication scheme. In this case, the antenna switch 915 may be omitted from the configuration of the smartphone 900.

[0384] The bus 917 connects the processor 901, the memory 902, the storage device 903, the external connection interface 904, the camera 906, the sensor 907, the microphone 908, the input device 909, the display device 910, the speaker 911, the wireless communication interface 912, and the auxiliary controller 919. The battery 918 supplies power to the various blocks of the smartphone 900 shown in FIG15 via feeders, which are partially shown as dotted lines in the figure. The auxiliary controller 919 operates the minimum necessary functions of the smartphone 900, for example, in sleep mode.

[0385] In the smartphone 900 shown in FIG15 , one or more components included in the processing circuit 1310 described with reference to FIG13 and the processing circuit 1610 described with reference to FIG16 may be implemented in the wireless communication interface 912. Alternatively, at least a portion of these components may also be implemented by the processor 901 or the auxiliary controller 919.

[0386] (Second application example)

[0387] 16 is a block diagram showing an example of a schematic configuration of a car navigation device 920 to which the technology of the present disclosure can be applied. The car navigation device 920 includes a processor 921, a memory 922, a global positioning system (GPS) module 924, a sensor 925, a data interface 926, a content player 927, a storage medium interface 928, an input device 929, a display device 930, a speaker 931, a wireless communication interface 933, one or more antenna switches 936, one or more antennas 937, and a battery 938.

[0388] The processor 921 may be, for example, a CPU or an SoC, and controls a navigation function and other functions of the car navigation apparatus 920. The memory 922 includes a RAM and a ROM, and stores data and programs executed by the processor 921.

[0389] The GPS module 924 measures the position (such as latitude, longitude, and altitude) of the car navigation device 920 using GPS signals received from GPS satellites. The sensor 925 may include a group of sensors such as a gyroscope sensor, a geomagnetic sensor, and an air pressure sensor. The data interface 926 is connected to, for example, the in-vehicle network 941 via an unillustrated terminal and acquires data generated by the vehicle (such as vehicle speed data).

[0390] The content player 927 reproduces content stored in a storage medium (such as a CD or DVD) inserted into the storage medium interface 928. The input device 929 includes, for example, a touch sensor, button, or switch configured to detect a touch on the screen of the display device 930, and receives an operation or information input from the user. The display device 930 includes a screen such as an LCD or OLED display and displays an image of a navigation function or reproduced content. The speaker 931 outputs the sound of the navigation function or the reproduced content.

[0391] The wireless communication interface 933 supports any cellular communication scheme (such as LTE and LTE-Advanced) and performs wireless communication. The wireless communication interface 933 may generally include, for example, a BB processor 934 and an RF circuit 935. The BB processor 934 may perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and perform various types of signal processing for wireless communication. Meanwhile, the RF circuit 935 may include, for example, a mixer, a filter, and an amplifier, and transmit and receive wireless signals via an antenna 937. The wireless communication interface 933 may also be a chip module on which the BB processor 934 and the RF circuit 935 are integrated. As shown in Figure 16, the wireless communication interface 933 may include multiple BB processors 934 and multiple RF circuits 935. Although Figure 16 shows an example in which the wireless communication interface 933 includes multiple BB processors 934 and multiple RF circuits 935, the wireless communication interface 933 may also include a single BB processor 934 or a single RF circuit 935.

[0392] In addition, in addition to the cellular communication scheme, the wireless communication interface 933 can support other types of wireless communication schemes, such as a short-range wireless communication scheme, a near field communication scheme, and a wireless LAN scheme. In this case, for each wireless communication scheme, the wireless communication interface 933 can include a BB processor 934 and an RF circuit 935.

[0393] Each of the antenna switches 936 switches a connection destination of the antenna 937 between a plurality of circuits included in the wireless communication interface 933 , such as circuits for different wireless communication schemes.

[0394] Each of the antennas 937 includes a single or multiple antenna elements (such as multiple antenna elements included in a MIMO antenna) and is used for transmitting and receiving wireless signals via the wireless communication interface 933. As shown in FIG16, the car navigation device 920 may include multiple antennas 937. Although FIG16 shows an example in which the car navigation device 920 includes multiple antennas 937, the car navigation device 920 may also include a single antenna 937.

[0395] Furthermore, the car navigation device 920 may include an antenna 937 for each wireless communication scheme. In this case, the antenna switch 936 may be omitted from the configuration of the car navigation device 920.

[0396] The battery 938 supplies power to the respective blocks of the car navigation apparatus 920 shown in Fig. 16 via a feeder line, which is partially shown as a dotted line in the figure. The battery 938 accumulates the power supplied from the vehicle.

[0397] 16 , one or more components included in the processing circuit 1910 described with reference to FIG19 may be implemented in the wireless communication interface 912. Alternatively, at least a portion of these components may also be implemented by the processor 921.

[0398] The technology of the present disclosure can also be implemented as an in-vehicle system (or vehicle) 940 including a car navigation device 920, an in-vehicle network 941, and one or more blocks of a vehicle module 942. The vehicle module 942 generates vehicle data (such as vehicle speed, engine speed, and fault information) and outputs the generated data to the in-vehicle network 941.

[0399] It should be understood that references to "an embodiment" or similar expressions throughout this specification mean that the specific features, structures, or characteristics described in connection with that embodiment are included in at least one specific embodiment of the present disclosure. Therefore, the appearance of phrases such as "in an embodiment of the present disclosure" or similar expressions throughout this specification does not necessarily refer to the same embodiment.

[0400] Those skilled in the art will appreciate that the present disclosure is implemented as a system, apparatus, method, or computer-readable storage medium (e.g., a non-transitory storage medium) as a computer program product. Thus, the present disclosure may be implemented in various forms, such as a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microprogram code, etc.), or a combination of software and hardware, hereinafter referred to as a "circuit," "module," or "system." Furthermore, the present disclosure may also be implemented as a computer program product in any tangible media form having computer-usable program code stored thereon.

[0401] The relevant description of the present disclosure is described with reference to the flowcharts and / or block diagrams of the systems, devices, methods and computer program products according to specific embodiments of the present disclosure. It is understood that each block in each flowchart and / or block diagram, as well as any combination of blocks in the flowchart and / or block diagram, can be implemented using computer program instructions. These computer program instructions can be executed by a machine composed of a processor of a general-purpose computer or a special computer or other programmable data processing device, and the instructions are processed by the computer or other programmable data processing device to implement the functions or operations described in the flowchart and / or block diagram.

[0402] The accompanying drawings show flowcharts and block diagrams of the architecture, functions and operations that can be implemented by the systems, devices, methods and computer program products according to various embodiments of the present disclosure. Therefore, each block in the flowchart or block diagram can represent a module, segment, or portion of program code, which includes one or more executable instructions to implement the specified logical function. It should also be noted that in certain other embodiments, the functions described by the blocks may not be performed in the order shown in the figures. For example, two blocks connected in the figures can actually be executed simultaneously, or in some cases can be executed in the opposite order of the icons depending on the functions involved. It should also be noted that each block of the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can be implemented by a system based on dedicated hardware, or by a combination of dedicated hardware and computer instructions to perform specific functions or operations.

[0403] While various embodiments of the present disclosure have been described above, the foregoing description is intended to be illustrative, non-exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or technical improvements to marketed technologies, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. An electronic device comprising: Memory, storing computer-executable instructions; and The processor, coupled to the memory, is configured to execute the computer-executable instructions to perform the following operations: While within a first sub-area of ​​at least one sub-area within coverage of an aerial platform-based roadside system (RSS), a first virtual roadside unit (VRSU) identifier is received from a first virtual roadside infrastructure (VRSI) serving the first sub-area.

2. The electronic device according to claim 1, wherein A VRSI is deployed for each sub-area by virtualizing physical resources of a roadside infrastructure of an RSS and allocating at least a portion of the virtualized physical resources to each sub-area in the at least one sub-area, each VRSI includes a VRSU, each VRSU includes at least a portion of the virtualized hardware resources and software resources of a roadside unit (RSU), each VRSU has a corresponding VRSU identifier, and the at least one sub-area includes a first sub-area.

3. The electronic device according to claim 2, wherein: The first VRSU identifier is associated with a first VRSI identifier of the first VRSI and a first virtual roadside computing control unit (VRSCCU) identifier, The first VRSI includes a first VRSCCU, and the first VRSCCU includes at least a portion of hardware resources and software resources of a virtualized roadside computing control unit. The first VRSU identifier, the first VRSI identifier, and the first VRSCCU identifier are allocated by a virtual infrastructure management unit (VIMU) of the RSS.

4. The electronic device according to claim 3, wherein: The resource configuration associated with the first VRSU identifier or the resource configuration associated with the first VRSCCU identifier allocated by the VIMU includes at least one of the following: a virtual CPU configuration, a virtual memory configuration, a virtual disk configuration, and a virtual network configuration.

5. The electronic device according to claim 3, wherein: The first VRSI identifier, the first VRSU identifier, and the first VRSCCU identifier are reported by the VIMU to the Internet of Vehicles cloud control platform via a first interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform.

6. The electronic device according to claim 2, wherein: The at least one sub-area is determined by the VIMU through the following operations: The at least one sub-area where the VRSI needs to be deployed within the coverage area of ​​the RSS is determined based at least on map information related to the location of the RSS.

7. The electronic device according to claim 6, wherein: The map information is received by the VIMU from the Internet of Vehicles cloud control platform via a second interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform.

8. The electronic device according to claim 2, wherein: Allocating at least a portion of the virtualized physical resources for each sub-area of ​​the at least one sub-area to deploy a VRSI for each sub-area includes the following operations performed by the VIMU: Resources for the VRSI of each sub-area are allocated based on an application scenario of the at least one sub-area.

9. The electronic device according to claim 2, wherein: Allocating at least a portion of the virtualized physical resources for each sub-area of ​​the at least one sub-area to deploy a VRSI for each sub-area includes the following operations performed by the VIMU: Resources for the VRSI of each sub-region of the at least one sub-region are allocated based on the historical data of the sub-region.

10. The electronic device according to claim 2, wherein: The first VRSU identifier is associated with the first VRSI identifier of the first VRSI and the first virtual roadside infrastructure resource slice type, The first VRSU identifier, the first VRSI identifier and the first virtual roadside infrastructure resource slice type are allocated by the VIMU, The virtual roadside infrastructure resource slice type is allocated based on the resource demand characteristics of the first sub-area.

11. The electronic device according to claim 10, wherein: The VRSI identifier, VRSU identifier and virtual roadside infrastructure resource slice type are reported by the VIMU to the Internet of Vehicles cloud control platform via the third interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform.

12. The electronic device according to claim 10, wherein: The resource demand characteristics of the first sub-region include at least one of the following: Latency requirements, Bandwidth requirements, Computing power requirements, and Storage capacity requirements.

13. The electronic device according to claim 10, wherein: The virtual roadside infrastructure resource slice type includes one of the following: Balanced slices, Low-latency slicing, Large bandwidth slice, Intelligent computing slices, Large storage slice, High positioning accuracy slices, and High-reliability slicing.

14. The electronic device according to claim 1, wherein The processor is further configured to perform the following operations: sending driving information of a vehicle carrying the electronic device to a first VRSU; and A traffic scheduling message is received from a first VRSU, wherein the traffic scheduling message includes a first VRSU identifier, and the traffic scheduling message includes traffic scheduling information based on driving information sent by the electronic device and based on at least one of driving information of other vehicles sent by other electronic devices, roadside perception information from the first VRSI, and traffic light information at a target intersection.

15. The electronic device according to claim 1, wherein The processor is further configured to perform the following operations: sending a detection result to a first VRSU, the detection result including driving environment information detected by the electronic device via the sensing device; and A driving assistance message is received from the first VRSU, wherein the driving assistance message includes a first VRSU identifier and includes driving assistance information based on at least one of a detection result transmitted by another electronic device and a detection result of the first VRSU.

16. The electronic device according to claim 1, wherein The processor is further configured to perform the following operations: A message including a first VRSU identifier is sent to the first VRSU.

17. The electronic device according to claim 1, wherein The first VRSU reports service data and operation information via the V2X.RSU.INFO.UP message and the V2X.RSU.RunningInfo.UP message on the interface between the RSU associated with the first VRSU and the vehicle network cloud control platform, respectively.

18. A roadside system (RSS) based on an aerial platform, comprising: An aerial roadside infrastructure hosting platform (APRSI), comprising an aerial hosting facility and a roadside infrastructure hosted on the aerial hosting facility, wherein the APRSI is configured to virtualize physical resources of the roadside infrastructure; and A virtual infrastructure management unit (VIMU) is configured to allocate at least a portion of virtualized physical resources to each sub-area in at least one sub-area within the coverage area of ​​the RSS to deploy a VRSI for each sub-area, each VRSI including at least a virtual roadside unit (VRSU), and each VRSU including at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).

19. The RSS according to claim 18, wherein Each VRSI also includes a virtual roadside computing control unit (VRSCCU), which includes at least a portion of the hardware resources and software resources of the virtualized roadside computing control unit.

20. The RSS of claim 18, wherein Each VRSI includes a VRSU, a virtual roadside computing control unit (VRSCCU), traffic control equipment and roadside sensing equipment, where the VRSCCU is used to provide access to traffic control equipment and roadside sensing equipment.

21. The RSS of claim 18, wherein The aerial carrying facilities include tethered balloons and their supporting facilities.

22. The RSS of claim 19, wherein: The roadside infrastructure includes one or more of a roadside unit, a roadside computing control unit, a traffic control device, and a roadside sensing device.

23. The RSS of claim 18, wherein The VIMU is also configured to: The at least one sub-area where the VRSI needs to be deployed within the coverage area of ​​the RSS is determined based at least on map information related to the location of the RSS.

24. The RSS of claim 23, wherein: The VIMU is also configured to: Reporting the first system basic information to the Internet of Vehicles cloud control platform via a first interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform, where the first system basic information includes the location information, operation form, and operation mode of the RSS, where the operation form indicates whether the RSS is in a virtual state; and Map information is received from the vehicle networking cloud control platform via a second interface message on the interface between the VIMU and the vehicle networking cloud control platform, where the map information is determined based on at least the RSS location information.

25. The RSS of claim 23, wherein The VIMU is also configured to: Based on the resource demand characteristics of each sub-area in the at least one sub-area, a virtual roadside infrastructure resource slice type is determined for the sub-area.

26. The RSS of claim 25, wherein: The VIMU is also configured to: The second system basic information is reported via the third interface message on the interface between the VIMU and the Internet of Vehicles cloud control platform. The second system basic information includes the VRSI identifier and the virtual roadside infrastructure resource slice type and VRSU identifier associated with the VRSI identifier.

27. The RSS of claim 18, wherein The VIMU is also configured to: Resources for the VRSI of each sub-area are allocated based on an application scenario of the at least one sub-area.

28. The RSS of claim 18, wherein The VIMU is also configured to: The fourth interface message on the interface between VIMU and the Internet of Vehicles cloud control platform is received from the Internet of Vehicles cloud control platform. collecting historical data of each sub-region in the at least one sub-region; VRSI resources for each sub-region of the at least one sub-region are allocated based on historical data of the sub-region.

29. The RSS of claim 25, wherein The VIMU is also configured to: Report the basic information of the third system via the fifth interface message on the interface between VIMU and the Internet of Vehicles cloud control platform, The third system basic information includes a VRSI identifier, an associated VRSU identifier, an associated VRSCCU identifier, an associated roadside sensor device identifier, and an associated traffic control device identifier. The third system basic information also includes VRSU resource configuration and VRSCCU resource configuration, each of the VRSU resource configuration and the VRSCCU resource configuration includes at least one of the following: virtual CPU configuration, virtual memory configuration, virtual disk configuration and virtual network configuration.

30. The RSS of claim 25, wherein The VRSU is configured to report service data and operation information to the Internet of Vehicles cloud control platform via the V2X.RSU.INFO.UP message and V2X.RSU.RunningInfo.UP message on the interface between the RSU associated with the VRSU and the Internet of Vehicles cloud control platform, respectively.

31. The RSS of claim 25, wherein: The VRSU is configured to transmit a VRSU identifier of the VRSU to electronic devices within the sub-area served by the VRSU.

32. The RSS of claim 31, wherein The VRSU is configured as follows: receiving, from electronic devices in the sub-area served by the electronic devices, driving information of vehicles carrying the electronic devices; Generate traffic scheduling information based on the received driving information and based on at least one of driving information of other vehicles sent by other electronic devices in the sub-area served by the VRSI, roadside perception information from the first VRSI, and traffic light information of the target intersection; and A traffic schedule message including a VRSU identifier of the VRSU and the traffic schedule information is sent to the electronic device.

33. The RSS of claim 31, wherein The VRSU is configured as follows: receiving a detection result from an electronic device within the sub-area served by the electronic device, the detection result including driving environment information detected by the electronic device via the sensing device; generating driving assistance information based on the received detection results and based on at least one of detection results transmitted by other electronic devices within the sub-area served by the VRSU and the detection results of the VRSU; and A driving assistance message including a VRSU identifier of the VRSU and the driving assistance information is sent to the electronic device.

34. The RSS of claim 31, wherein The VRSU is configured as follows: A message including a VRSU identifier of the VRSU is received from an electronic device within the sub-area served by the VRSU.

35. A virtual infrastructure management unit (VIMU), comprising: Memory, storing computer-executable instructions; and The processor, coupled to the memory, is configured to execute the computer-executable instructions to perform the following operations: A virtual roadside infrastructure (VRSI) is deployed for each of at least one sub-area within the coverage area of ​​an aerial platform-based roadside system (RSS) by allocating at least a portion of the physical resources of the virtualized roadside infrastructure of the RSS to the sub-area, each VRSI including at least a virtual roadside unit (VRSU), and each VRSU including at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).

36. A method performed by an electronic device, comprising: While within a first sub-area of ​​at least one sub-area within coverage of an aerial platform-based roadside system (RSS), a first virtual roadside unit (VRSU) identifier is received from a first virtual roadside infrastructure (VRSI) serving the first sub-area.

37. A method performed by an aerial platform-based roadside system (RSS), comprising: The physical resources of the roadside infrastructure are virtualized by an aerial roadside infrastructure hosting platform (APRSI) including an aerial hosting platform and roadside infrastructure hosted on the aerial hosting platform; and A virtual infrastructure management unit (VIMU) allocates at least a portion of virtualized physical resources to each sub-area in at least one sub-area within the coverage area of ​​the RSS to deploy a VRSI for each sub-area, each VRSI including at least a virtual roadside unit (VRSU), each VRSU including a virtualized roadside unit (RSU) hardware resources and at least a portion of the software resources.

38. A method performed by a virtual infrastructure management unit (VIMU), comprising: A virtual roadside infrastructure (VRSI) is deployed for each of at least one sub-area within the coverage area of ​​an aerial platform-based roadside system (RSS) by allocating at least a portion of the physical resources of the virtualized roadside infrastructure of the RSS to the sub-area, each VRSI including at least a virtual roadside unit (VRSU), and each VRSU including at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).

39. A computer storage medium storing computer executable instructions, which when executed by a processor perform the method of any one of claims 36 to 38.

40. A computer program product comprising computer executable instructions which, when executed by a processor, perform the method of any one of items 36-38.

Images