WO2023202594A1 - 基于空中平台的路侧系统 - Google Patents

基于空中平台的路侧系统 Download PDF

Info

Publication number
WO2023202594A1
WO2023202594A1 PCT/CN2023/089092 CN2023089092W WO2023202594A1 WO 2023202594 A1 WO2023202594 A1 WO 2023202594A1 CN 2023089092 W CN2023089092 W CN 2023089092W WO 2023202594 A1 WO2023202594 A1 WO 2023202594A1
Authority
WO
WIPO (PCT)
Prior art keywords
vrsu
sub
roadside
virtual
vrsi
Prior art date
Application number
PCT/CN2023/089092
Other languages
English (en)
French (fr)
Inventor
郁春波
崔焘
Original Assignee
索尼集团公司
郁春波
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 索尼集团公司, 郁春波 filed Critical 索尼集团公司
Publication of WO2023202594A1 publication Critical patent/WO2023202594A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/18—Network planning tools
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices

Definitions

  • the present disclosure relates generally to communications technology, and more specifically to aerial platform-based roadside systems and associated methods, electronic devices, virtual infrastructure management units, and computer program media.
  • C-V2X Cellular Vehicle-to-Everything
  • 4G/5G cellular network communication technologies
  • 4G/5G cellular network communication technologies
  • Roadside infrastructure is generally fixedly installed on traffic facilities on both sides of the road. However, in the event of earthquakes, large-scale power outages and other disasters, roadside infrastructure may be completely paralyzed. In addition, in some remote areas, such as mountainous areas and forest areas, there is often no roadside infrastructure.
  • Unmanned self-driving vehicles such as unmanned fire trucks, unmanned ambulances, unmanned food delivery vehicles, unmanned emergency rescue vehicles, etc.
  • unmanned fire trucks such as unmanned fire trucks, unmanned ambulances, unmanned food delivery vehicles, unmanned emergency rescue vehicles, etc.
  • unmanned emergency rescue vehicles such as unmanned fire trucks, unmanned ambulances, unmanned food delivery vehicles, unmanned emergency rescue vehicles, etc.
  • emergency roadside infrastructure is needed to ensure the orderly operation of unmanned vehicles in these cities.
  • an electronic device 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: At least within the coverage area of the aerial platform-based Road Side System (RSS) When within the first sub-area in a sub-area, from the first virtual road side unit (VRSU) in the first virtual road side infrastructure (VRSI) serving the first sub-area ) receives the first VRSU identifier.
  • RSS Road Side System
  • a VRSI is deployed for each sub-region 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 of the at least one sub-region.
  • each VRSI includes a VRSU
  • each VRSU includes at least a part of the hardware resources and software resources of a virtualized road side unit (Road Side Unit, RSU)
  • each VRSU has a corresponding VRSU identifier
  • the at least one The sub-region includes the first sub-region.
  • the first VRSU identifier is associated with a first VRSI identifier of a first VRSI and a first virtual road side computing control unit (VRSCCU) identifier, the first VRSI comprising a first VRSCCU, the first VRSCCU includes at least a part of the hardware resources and software resources of the virtualized roadside computing control unit, the first VRSU identifier, the first VRSI identifier and the first VRSCCU identifier are virtualized by the RSS Assigned by the Virtual Infrastructure Management Unit (VIMU).
  • VIP Virtual Infrastructure Management Unit
  • the resource configuration associated with the first VRSU identifier or the resource configuration associated with the first VRSCCU identifier allocated by VIMU includes at least one of the following: virtual CPU configuration, virtual memory configuration, virtual disk configuration and virtual network configuration.
  • the first VRSI identifier, the first VRSU identifier and the first VRSCCU identifier are reported by VIMU to the Internet of Vehicles cloud control platform via a first interface message on the interface between VIMU and the Internet of Vehicles cloud control platform. .
  • the at least one sub-area is determined by the VIMU through the following operations: determining the at least one sub-area within the coverage area of the RSS where VRSI needs to be deployed based on at least map information related to the location of the RSS.
  • the map information is received by VIMU from the Internet of Vehicles cloud control platform via a second interface message on the interface between VIMU and the Internet of Vehicles cloud control platform.
  • allocating at least a portion of virtualized physical resources to each of the at least one sub-region to deploy a VRSI for each sub-region includes the following operations performed by the VIMU: based on the at least one sub-region The application scenario of each sub-area allocates VRSI resources for that sub-area.
  • allocating at least a portion of virtualized physical resources to each of the at least one sub-region to deploy a VRSI for each sub-region includes the following operations performed by the VIMU: based on the at least one sub-region Each sub-region's historical data is allocated resources for the VRSI of that sub-region.
  • the first VRSU identifier is associated with a first VRSI identifier of the first VRSI and a first virtual roadside infrastructure resource slice type, the first VRSU identifier, the first VRSI identifier and the first virtual
  • the roadside infrastructure resource slicing type is allocated by VIMU, and the virtual roadside infrastructure resource slicing type is allocated based on the resource demand characteristics of the first sub-region.
  • the VRSI identifier, the VRSU identifier, and the virtual roadside infrastructure resource slice type are reported by VIMU to the Internet of Vehicles cloud control platform via a third interface message on the interface between VIMU and the Internet of Vehicles cloud control platform.
  • the resource requirement characteristics of the first sub-area include at least one of the following: delay requirements, bandwidth requirements, computing power requirements, and storage capacity requirements.
  • the virtual roadside infrastructure resource slicing type includes one of the following: balanced slicing, low-latency slicing, large-bandwidth slicing, intelligent computing slicing, large storage slicing, and high positioning accuracy slicing. and high-reliability slicing.
  • the processor is further configured to perform the following operations: sending travel information of the vehicle carrying the electronic device to the first VRSU; and receiving a traffic scheduling message from the first VRSU, wherein the traffic scheduling message includes The first VRSU identifier, the traffic scheduling message includes the traveling information of other vehicles based on the traveling information sent by the electronic device and based on the traveling information of other vehicles sent by other electronic devices, roadside sensing information from the first VRSI, and traffic light information of the target intersection. Traffic scheduling information for at least one of the
  • the processor is further configured to perform the following operations: send a detection result to the first VRSU, the detection result including the driving environment information detected by the electronic device via the sensing device; and receive from the first VRSU A driving assistance message, 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 a detection result sent by another electronic device and a detection result of the first VRSU.
  • the processor is further configured to send a message including the first VRSU identifier to the first VRSU.
  • the first VRSU communicates with the vehicle network cloud control platform via the RSU associated with the first VRSU.
  • the V2X.RSU.INFO.UP message and the V2X.RSU.RunningInfo.UP message on the interface between them report business data and running information respectively.
  • a roadside system based on an aerial platform
  • an aerial roadside infrastructure bearing platform including an aerial bearing facility and a roadside infrastructure carried on the aerial bearing facility , the APRSI is configured to virtualize physical resources of the roadside infrastructure; and a virtual infrastructure management unit (VIMU) is configured to allocate virtualized resources to each of at least one sub-area within the coverage of the RSS. At least part of the physical resources are used to deploy a VRSI for each sub-area.
  • Each VRSI includes at least one virtual roadside unit (VRSU).
  • Each VRSU includes at least the hardware resources and software resources of the virtualized roadside unit (RSU). part.
  • each VRSI also includes a virtual roadside computing control unit (VRSCCU) that includes at least a portion of the hardware resources and software resources of the virtualized roadside computing control unit.
  • VRSCCU virtual roadside computing control unit
  • each VRSI includes a VRSU, a virtual roadside computing control unit (VRSCCU), a traffic control device, and a roadside sensing device, where the VRSCCU is used to provide access to the traffic control device and the roadside sensing device.
  • VRSCCU virtual roadside computing control unit
  • the aerial carrying facilities include tethered balloons and supporting facilities.
  • 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.
  • the VIMU is further configured to: determine the at least one sub-area within the coverage area of the RSS where VRSI needs to be deployed based on at least map information related to the location of the RSS.
  • the VIMU is further configured to: report the first basic system information to the Internet of Vehicles cloud control platform via a first interface message on the interface between VIMU and the Internet of Vehicles cloud control platform.
  • the first basic system information Including the location information, operating form and operating mode of the RSS, where the operating form indicates whether the RSS is in a virtual state; and receiving map information from the Internet of Vehicles cloud control platform via a second interface message on the interface between VIMU and the Internet of Vehicles cloud control platform.
  • the map information is determined based at least on the location information of RSS.
  • the VIMU is further configured to: determine a virtual roadside infrastructure resource slice type for each sub-region based on resource demand characteristics of the at least one sub-region.
  • the VIMU is further configured to report second basic system information via a third interface message on the interface between VIMU and the Internet of Vehicles cloud control platform, where the second basic system information includes a VRSI identifier and and the virtual roadside infrastructure resource slice type and VRSU identifier associated with the VRSI identifier.
  • the VIMU is further configured to: allocate resources for VRSI of each sub-region in the at least one sub-region based on an application scenario of the sub-region.
  • the VIMU is further configured to: receive each of the at least one sub-region from the Internet of Vehicles cloud control platform via a fourth interface message on the interface between VIMU and the Internet of Vehicles cloud control platform. historical data; and allocating VRSI resources for each sub-region of the at least one sub-region based on historical data of the sub-region.
  • the VIMU is further configured to: report third system basic information via a 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, related The associated VRSU identifier, the associated VRSCCU identifier, the associated roadside sensing device identifier, and the associated traffic control device identifier.
  • the basic information of the third system also includes VRSU resource configuration and VRSCCU resource configuration.
  • VRSU resource Each of the configuration and VRSCCU resource configuration includes at least one of the following: virtual CPU configuration, virtual memory configuration, virtual disk configuration, and virtual network configuration.
  • the VRSU is configured to send the V2X.RSU.INFO.UP message and the V2X.RSU.RunningInfo.UP message respectively to the Internet of Vehicles via the interface between the RSU associated with the VRSU and the Internet of Vehicles cloud control platform.
  • the cloud control platform reports business data and operational information.
  • a VRSU is configured to send the VRSU's VRSU identifier to electronic devices within the sub-region it serves.
  • the VRSU is configured to: receive travel information about the vehicle carrying the electronic device from the electronic device within the sub-area it serves; based on the received travel information and based on the travel information within the sub-area it serves Generate traffic scheduling information from at least one of the driving information of other vehicles sent by other electronic devices, the roadside sensing information from the first VRSI, and the traffic light information of the target intersection; and send a VRSU containing the VRSU to the electronic device. identifier and the traffic scheduling information of the traffic scheduling message.
  • 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 the sensing device; based on the received Detect the results and generate driving assistance information based on at least one of the detection results sent by other electronic devices within the sub-area served by the VRSU and the detection results of the VRSU; and send to the electronic device a VRSU identifier including the VRSU and The driving assistance message of the driving assistance information.
  • a VRSU is configured to receive messages including the VRSU identifier of the VRSU from electronic devices within the sub-region it serves.
  • a virtual infrastructure management unit 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: allocate for each sub-area in at least one sub-area within the coverage area of the air-based platform road-side system (RSS) at least a portion of the physical resources of the RSS's virtualized road-side infrastructure for the sub-area.
  • a virtual roadside infrastructure (VRSI) is deployed regionally, each VRSI includes at least a virtual roadside unit (VRSU), and each VRSU includes at least a portion of hardware resources and software resources of a virtualized roadside unit (RSU).
  • a method performed by an electronic device comprising: while within a first sub-area of at least one sub-area within the coverage of an aerial platform-based roadside system (RSS), A first VRSU identifier is received from a first virtual roadside unit (VRSU) in a first virtual roadside infrastructure (VRSI) serving the first sub-region.
  • RSS aerial platform-based roadside system
  • VRSU virtual roadside unit
  • VRSI virtual roadside infrastructure
  • an aerial platform-based roadside system comprising: an aerial roadside infrastructure including an aerial platform and a roadside infrastructure carried on the aerial platform.
  • the facility hosting platform (APRSI) virtualizes the physical resources of the roadside infrastructure; and the virtual infrastructure management unit (VIMU) allocates the virtualized physical resources to each sub-area in at least one sub-area within the coverage of the RSS.
  • At least part of the VRSI is deployed for each sub-region, each VRSI includes at least a virtual roadside unit (VRSU), and each VRSU includes at least a portion of hardware resources and software resources of the virtualized roadside unit (RSU).
  • VRSU virtual roadside unit
  • RSU virtualized roadside unit
  • a method performed by a virtual infrastructure management unit including: The region allocates at least a portion of the physical resources of the virtualized roadside infrastructure of the RSS to deploy a virtual roadside infrastructure (VRSI) for the subregion, 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 Roadside Unit (RSU) are virtualized.
  • VSU virtual infrastructure management unit
  • a computer storage medium storing computer-executable instructions that, when executed by a processor, perform the method as described above.
  • a computer program product including computer-executable instructions, The computer-executable instructions, when executed by the processor, perform the methods described above.
  • FIG. 1 is an exemplary overview diagram illustrating an aerial platform-based roadside system according to an embodiment of the present disclosure.
  • FIG. 2A is a schematic deployment diagram illustrating an aerial platform-based roadside system according to an embodiment of the present disclosure.
  • 2B and 2C illustrate a schematic diagram of providing virtual infrastructure services based on virtual RSUs according to an embodiment of the present disclosure.
  • FIG. 3 shows a schematic system architecture diagram of an aerial platform-based roadside system according to an embodiment of the present disclosure.
  • Figure 4 illustrates an exemplary messaging mechanism of an aerial platform-based roadside system according to an embodiment of the present disclosure.
  • Figure 5 shows a virtual resource slice deployment architecture diagram according to an embodiment of the present disclosure.
  • FIG. 6 shows an exemplary flowchart of a resource allocation method of a roadside system according to an embodiment of the present disclosure.
  • Figure 7 shows a fork intersection traffic scenario assisted by a roadside subsystem according to an embodiment of the present disclosure.
  • FIG. 8 shows an exemplary flowchart of a method performed by an electronic device according to an embodiment of the present disclosure.
  • Figure 9 illustrates a perception data sharing scenario assisted by a roadside subsystem according to an embodiment of the present disclosure.
  • FIG. 10 shows an exemplary flowchart of a method performed by an electronic device according to an embodiment of the present disclosure.
  • FIG. 11 illustrates an exemplary flowchart of a method performed by an aerial platform-based roadside system (RSS) according to an embodiment of the present disclosure.
  • RSS roadside system
  • Figure 12 shows an exemplary flowchart of a method performed by VIMU according to an embodiment of the present disclosure.
  • 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 may be applied.
  • 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 may be applied.
  • 15 is a block diagram showing an example of a schematic configuration of a smartphone to which the technology of the present disclosure can be applied.
  • 16 is a block diagram showing an example of a schematic configuration of a car navigation device to which the technology of the present disclosure can be applied.
  • a unit/circuit/component used with the "configured to” language includes hardware - such as circuitry, memory storing program instructions executable to perform operations, etc.
  • “configured to” may include general-purpose structures (e.g., general-purpose circuitry) manipulated by software and/or firmware (e.g., an FPGA or a general-purpose processor executing software) to enable the performance of one or more tasks to be solved. way to operate. "Configured to” may also include adapting a manufacturing process (eg, a semiconductor fabrication facility) to fabricate a device (eg, an integrated circuit) suitable for implementing or performing one or more tasks.
  • a manufacturing process eg, a semiconductor fabrication facility
  • a device eg, an integrated circuit
  • the term "based on” is used to describe the factor or factors that influence the determination. This term does not exclude additional factors that may affect the determination. That is, the determination may be based solely on these factors or at least in part on these factors.
  • B is a factor that affects the determination of A. This phrase does not exclude that it can also be determined based on C. A. In other cases, A may be determined based on B alone.
  • Embodiments of the present disclosure consider arranging a roadside system based on an aerial platform to carry roadside infrastructure (such as roadside units, roadside computing control units, roadside traffic control equipment, roadside sensing equipment, etc.) on, for example, tethered balloons On such airborne equipment, it provides an airborne 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.
  • roadside infrastructure such as roadside units, roadside computing control units, roadside traffic control equipment, roadside sensing equipment, etc.
  • Embodiments of the present disclosure also consider virtualizing the physical resources (including hardware resources, software resources, etc.) of the roadside infrastructure of the air platform-based roadside system, and allocating the virtualized physical resources on demand.
  • the physical resources of RSU including hardware resources and software resources, etc.
  • the physical resources of RSCCU including hardware resources and software resources, etc.
  • This can provide more flexible and efficient resource allocation and improve resource utilization.
  • embodiments of the present disclosure consider determining sub-areas in which virtual road-side infrastructure needs to be deployed within the coverage of the aerial platform-based road-side system, and deploying a virtual road-side infrastructure for each determined sub-area.
  • the virtual roadside infrastructure is deployed for each determined sub-area by allocating at least a part of the virtualized resources to the sub-area according to application scenarios, historical data, etc. of each sub-area. That is, the virtual roadside infrastructure deployed for a sub-area includes at least a part of the virtualized resources allocated for 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 devices and roadside sensing devices. This means that the resources of the same RSU or RSCCU can be used for corresponding multiple virtual roadside infrastructures in multiple sub-regions, thereby providing flexible resource configuration and efficient resource utilization.
  • Embodiments of the present disclosure also propose the concept of virtual roadside infrastructure resource slicing, that is, virtualized resources are provided in different types of virtual roadside infrastructure resource slicing. For example, according to the resource demand characteristics of the sub-region (for example, delay requirements, bandwidth requirements, computing power requirements, storage capacity requirements, etc.), an appropriate virtual roadside infrastructure resource slicing type can be selected for it. This can provide more granular resource allocation and improve overall resource utilization.
  • Embodiments of the present disclosure also propose to provide map information for the roadside system at least according to the location of the roadside system, and determine the sub-area in which virtual roadside infrastructure needs to be deployed based on the map information.
  • the map information includes, for example, road intersection information, and the sub-area where the virtual roadside infrastructure needs to be deployed can be determined based on the intersection where the virtual roadside infrastructure needs to be deployed. This can provide more granular resource allocation and improve overall resource utilization. This is especially important in resource-constrained situations.
  • Embodiments of the present disclosure also provide a virtual infrastructure management unit, which is used to perform the determination of the above-mentioned sub-areas, management and allocation of virtualized resources, and the like.
  • the disclosed embodiment also proposes to add a new communication interface and a corresponding message set between the virtual infrastructure management unit and the Internet of Vehicles cloud control platform, and expand the corresponding roadside unit and the corresponding message set between the virtual roadside unit and the Internet of Vehicles cloud control platform.
  • Embodiments of the present disclosure also consider sending the identifier of the virtual roadside unit by the virtual roadside unit to the vehicle-mounted unit.
  • the identifier of the virtual roadside unit is used to communicate between the virtual roadside unit and the vehicle-mounted unit to implement, for example, roadside system-assisted intersection traffic, roadside system-assisted sensing data sharing, and roadside system-assisted vehicle payment services. wait.
  • FIG. 1 is an exemplary overview diagram illustrating an aerial platform-based roadside system according to an embodiment of the present disclosure.
  • the roadside system 101 is arranged above urban roads or highways, and the roadside system 102 is arranged in wild areas such as sectors, forests, and deserts. Over the road.
  • each roadside system uses tethered balloons as aerial carrying equipment to form its aerial carrying platform.
  • the tethered balloon can include a sphere, power subsystem, pressure regulation subsystem, measurement and control subsystem, communication subsystem, lightning protection subsystem and ground tethered subsystem, etc.
  • aerial carrying equipment including but not limited to: airships, mid- to high-altitude balloons, low-altitude/ultra-low-altitude tethered balloons, drones, etc.
  • the airborne equipment can carry the roadside infrastructure of the roadside system.
  • Roadside infrastructure can include roadside units, roadside computing control units, roadside sensing equipment, traffic control equipment, etc.
  • Roadside sensing devices may include, but are not limited to, cameras (such as laser cameras), sensors, and radars (such as lidar, millimeter wave radar).
  • Traffic control devices may include, but are not limited to, traffic lights and traffic warning signs.
  • each roadside system can communicate with the ground-based Internet of Vehicles remote cloud control platform via satellite relay links.
  • the roadside system can use the C-V2X interface to communicate with the ground-based Internet of Vehicles remote cloud control platform, and can use the C-V2X interface to communicate with ground-based vehicles (for example, vehicle-mounted units).
  • tethered balloons as aerial carrying equipment as an example, different tethered balloons can be used according to different scene requirements.
  • Table 1 shows an exemplary tethered balloon classification.
  • Table 1 Classification table of tethered balloons
  • Table 2 shows an exemplary mounted device coverage classification table.
  • Table 2 Mounted device coverage classification table
  • ultra-low-altitude (height ⁇ 50 meters) micro-tethered balloons can be used to mount ordinary RSUs, roadside traffic control equipment such as air traffic lights, and laser radars. Roadside sensing equipment, etc., thereby providing refined roadside infrastructure services for vehicles.
  • low-altitude (height ⁇ 500 meters) small tethered balloons can be used to mount enhanced aerial RSU and roadside sensing equipment such as PTZ laser cameras, while supporting coverage of 3 to 4 to reduce deployment and usage costs.
  • Low-altitude (height ⁇ 3000 meters) medium and large tethered balloons are equipped with enhanced RSUs and roadside equipment such as ultra-long-range pan-tilt laser cameras, which can cover dozens of intersections, further reducing deployment and use costs.
  • mounting solutions that combine the above different heights can be used.
  • small tethered balloons are used at low altitudes to mount enhanced RSUs and roadside sensing equipment such as PTZ laser cameras, while partially Micro-tethered balloons are used to carry aerial signals, aerial lidar, etc. at fork-in-the-road intersections to provide enhanced roadside infrastructure services.
  • the aerial platform of a roadside system may include one or more aerial devices.
  • These airborne devices may be different types of airborne devices. These airborne equipment can be dispersed in different locations and mount different equipment respectively. These airborne devices can support wireless communications with each other.
  • An airborne device may provide an interface for coupling and communicating with devices mounted thereon.
  • roadside infrastructure in the air allows roadside systems to have greater coverage and be less susceptible to the terrestrial communication environment.
  • roadside systems based on aerial platforms are low-cost, easy to deploy, and more flexible.
  • FIG. 2A is a schematic deployment diagram illustrating an aerial platform-based roadside system 2000 according to an embodiment of the present disclosure.
  • the roadside system 2000 is set up in a certain geographical location and provides a certain coverage area. Under this coverage, there may be multiple sub-areas that require centralized provision of roadside infrastructure services, such as the sub-area 2001 where the intersection is located and the sub-area 2003 where the curve blind area is located as shown in Figure 2A.
  • a virtual roadside infrastructure can be deployed for each sub-region. As shown in Figure 2A, VRSI 2005 is deployed for subregion 2001, and VRSI 2007 is deployed for subregion 2003.
  • the VRSI may include physical resources of the roadside system 2000 allocated for the corresponding sub-area, including hardware resources and software resources.
  • physical resources of the roadside system 2000 may be virtualized, and at least a part of the virtualized physical resources may be allocated to each sub-area where VRSI needs to be deployed, thereby deploying corresponding VRSI for each sub-area.
  • the physical resources of an RSU (including hardware resources and software resources) can be divided into multiple virtual RSUs, and the multiple virtual RSUs can be allocated to different sub-areas.
  • Each virtual roadside infrastructure may include at least one virtual RSU.
  • Each virtual RSU may include at least a portion of the physical resources (including hardware resources and software resources) of the corresponding roadside unit (RSU) that are virtualized.
  • the resource configuration associated with a virtual RSU includes, for example, virtual CPU configuration, virtual memory configuration, virtual disk configuration, virtual network configuration, etc.
  • FIG. 2B and 2C illustrate a schematic diagram of providing virtual infrastructure services based on virtual RSUs according to an embodiment of the present disclosure.
  • Figure 2B shows an aerial platform-based roadside system deployed over a city, which includes four virtual RSUs to provide roadside infrastructure services for different areas within its coverage.
  • Figure 2C shows an aerial platform-based roadside system deployed over a forest, which includes three virtual RSUs to provide roadside infrastructure services for different areas of its coverage.
  • the physical resources of the RSCCU can be virtualized and divided into multiple virtual RSCCUs, and the multiple virtual RSCCUs can be allocated to different sub-regions.
  • Each virtual roadside infrastructure may also include a virtual RSCCU and associated roadside sensing devices and/or roadside traffic control devices.
  • Each VRSCCU may include at least a portion of the physical resources of the corresponding roadside computing control unit that are virtualized.
  • the virtual RSCCU is used to provide access to associated roadside sensing equipment and/or roadside traffic control equipment.
  • Each virtual roadside infrastructure may also include corresponding airborne equipment.
  • the roadside system 2000 includes four airborne equipment 201 - 204 , where the airborne equipment 201 is, for example, a low-altitude small tethered balloon, and the airborne equipment 202 - 204 is, for example, an ultra-low-altitude micro-tethered balloon.
  • the airborne equipment 201 is, for example, a low-altitude small tethered balloon
  • the airborne equipment 202 - 204 is, for example, an ultra-low-altitude micro-tethered balloon.
  • the airborne equipment 201 can mount an RSU (not shown), an RSCCU (not shown) and two PTZ laser cameras E and F.
  • the airborne equipment 202 may carry the traffic light A.
  • the airborne equipment 203 can mount the lidar B.
  • the airborne equipment 204 can carry the lidar C.
  • RSUs can be virtualized and provide two different virtual RSUs (with different virtual RSU identifiers) for VRSI 2005 and VRSI 2007 respectively.
  • RSCCU can be virtualized and provide two different virtual RSCCUs (with different virtual RSCCU identifiers) for VRSI 2005 and VRSI 2007 respectively.
  • VRSI 2005 may include a virtual RSU, an RSCCU, airborne equipment 202 and 203, traffic light A, lidar B and PTZ laser camera E.
  • VRSI 2007 may include a virtual RSU, an RSCCU, airborne equipment 204, lidar C and PTZ laser camera F.
  • the determination of the sub-area in which 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 Figure 2A).
  • the sub-area where VRSI needs to be deployed may be manually specified based on map information related to the deployment location of the roadside system.
  • the VRSI may be manually assigned to the determined sub-region, which may include, for example, assigning a VRSI identifier or the like.
  • the roadside system 2000 may determine the location of the roadside system based on a map related to the deployment location of the roadside system. information to automatically determine the sub-region where VRSI needs to be deployed.
  • the roadside system can allocate VRSI identifiers and corresponding resources to the determined sub-area.
  • the map information can come from the vehicle network cloud control platform or from the map pre-stored by the roadside system 2000.
  • the deployment location of the roadside system can come from user input.
  • the deployment location of the roadside system can be determined by the positioning device included in the roadside system itself.
  • FIG. 3 shows a schematic system architecture diagram of an aerial platform-based roadside system 2000 according to an embodiment of the present disclosure.
  • the roadside system may include various roadside infrastructure, including airborne equipment and roadside units (RSU) carried on the airborne equipment, computing control units, traffic control equipment and roadside sensing equipment.
  • RSU roadside units
  • virtual infrastructure resources are formed by virtualizing the physical resources (including hardware resources and software resources, etc.) of the roadside system 2000.
  • virtual infrastructure resources can 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). Signal lights A and M), two PTZ laser cameras (i.e. PTZ laser cameras E and F) and two lidars (i.e. lidars B and C).
  • Virtual infrastructure resources may also include physical resources of airborne equipment (eg, tethered balloons) not shown.
  • physical resources include both hardware devices and software configurations, as well as physical capabilities (such as bandwidth, computing power, frequency bands, etc.) supported by the hardware devices and software configurations, and so on.
  • roadside system 2000 may also include a virtual infrastructure management unit (VIMU).
  • VIMU is configured to provide functions such as management allocation and fault handling of virtual resources, and is responsible for life cycle management (such as instantiation and configuration) of virtual infrastructure (VRSI), virtual roadside unit (VRSU), and virtual computing control unit (VRSCCU). , close, etc.).
  • VRSI virtual infrastructure
  • VRSU virtual roadside unit
  • VRSCCU virtual computing control unit
  • 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 the VRSI is to be deployed, thereby deploying the corresponding virtual roadside infrastructure for the sub-area. (VRSI).
  • VIMU can deploy virtual roadside infrastructure 2005 and 2007 respectively for sub-area 2001 and sub-area 2003 shown in Figure 2A.
  • 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), and a PTZ laser camera (PTZ laser camera E shown in Figure 2A ), 1 lidar (Lidar B shown in Figure 2A), 1 traffic light (Traffic light A shown in Figure 2A), two ultra-low-altitude tethered balloons (airborne carrier shown in Figure 2A Devices 202 and 203).
  • a virtual RSU i.e., virtual RSU 1
  • a virtual computing control unit i.e., virtual computing control unit 1
  • PTZ laser camera PTZ laser camera
  • 1 lidar Lidar B shown in Figure 2A
  • 1 traffic light Traffic light
  • two ultra-low-altitude tethered balloons airborne carrier shown in Figure 2A Devices 202 and 203.
  • the virtual roadside infrastructure 2007 may include 1 virtual RSU (i.e., virtual RSU 2), 1 virtual computing control unit (i.e., virtual computing control unit 2), and 1 PTZ laser camera (the PTZ laser shown in Figure 2A Camera F), 1 lidar (lidar C shown in Figure 2A) and 1 ultra-low altitude tethered balloon (airborne equipment 204 shown in Figure 2A).
  • 1 virtual RSU i.e., virtual RSU 2
  • 1 virtual computing control unit i.e., virtual computing control unit 2
  • PTZ laser camera the PTZ laser shown in Figure 2A Camera F
  • lidar lidar C shown in Figure 2A
  • 1 ultra-low altitude tethered balloon airborne equipment 204 shown in Figure 2A
  • the virtual computing control unit 3 and the traffic light M in the virtual infrastructure resources in Figure 3 can be assigned to other VRSIs.
  • the virtual infrastructure management unit may receive map information and identify sub-areas that need to provide services, such as a sub-area 2001 containing an intersection or a sub-area 2003 containing a blind spot on a curve as shown in Figure 2A.
  • the virtual infrastructure management unit may also directly receive the specified information for the sub-region, such as the location information of the sub-region and the geographical characteristics of the sub-region.
  • the virtual infrastructure management unit can receive information related to resource demand characteristics associated with the sub-area, such as latency, bandwidth, computing, storage, positioning accuracy, reliability requirements, etc. determined by application scenarios.
  • the virtual infrastructure management unit can select an appropriate virtual resource slice type for each sub-area based on the resource demand characteristics of the sub-area and allocate appropriate resources.
  • the virtual infrastructure management unit may be implemented as a software program. In other embodiments, the virtual infrastructure management unit may be implemented as a separate hardware device that may be wired/wirelessly coupled and communicated with various roadside infrastructures. In some embodiments, the virtual infrastructure management unit can also be integrated into the air bearer equipment, RSU, RSCCU or other equipment.
  • the roadside system can communicate with the relay satellite via the C-V2X Uu interface, and the relay satellite communicates with the Internet of Vehicles cloud control platform via the C-V2X Uu interface.
  • Roadside systems can communicate with onboard units via the C-V2X PC5 interface.
  • the vehicle-mounted unit can communicate with the Internet of Vehicles cloud control platform via the C-V2X Uu interface.
  • the roadside system 2000 may also include a satellite communication unit for communicating with relay satellites.
  • the satellite communications unit may be integrated into the airborne equipment.
  • VRSIs By virtualizing the physical resources of the roadside system 2000, different VRSIs can be deployed according to different resource requirements in different sub-regions, which can provide more accurate roadside infrastructure services and improve roadside infrastructure. Flexibility in infrastructure deployment and improved resource utilization of the entire roadside system.
  • FIG. 4 illustrates an exemplary messaging mechanism of an aerial platform-based roadside system 2000 according to an embodiment of the present disclosure.
  • 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, and is responsible for life cycle management (instantiation) of VRSU, VRSCCU, and VRSI. , configuration, shutdown, etc.).
  • VIP virtual infrastructure management unit
  • Roadside System 2000 also includes Virtual Roadside Infrastructure VRSI 2005 and VRSI 2007.
  • VRSI2005 includes a set of virtual RSU (i.e. VRSU 1), virtual RSCCU (i.e. VRSCCU 1), traffic control equipment (i.e. traffic light A) and roadside sensing equipment (i.e. PTZ laser camera E and lidar B).
  • VRSI2007 includes a set of virtual RSU (i.e. VRSU 2), virtual RSCCU (i.e. VRSCCU 2) and roadside sensing equipment (i.e. lidar C).
  • the roadside system 2000 also includes the Air Platform for Road Side Infrastructure (APRSI), which is configured to provide the operating environment of VRSU and VRSCCU, including the required hardware and software, and is configured to transport the road
  • API Air Platform for Road Side Infrastructure
  • the physical resources of the roadside infrastructure of the side system 2000 are virtualized into virtual resources for use by VRSU and VRSCCU.
  • Aerial carrier platforms can provide carrier functions, such as including tethered balloons to provide equipment levitation.
  • the airborne platform may provide communication functions and/or interface functions, for example, including various communication components (such as satellite communication, Wifi communication), including power interfaces, communication interfaces, etc. to couple with roadside infrastructure.
  • the airborne 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, such as the hardware resources, OS Linux and virtualization layer in Figure 5 below. These three parts are shown.
  • Figure 5 shows a virtual resource slice deployment architecture diagram according to an embodiment of the present disclosure.
  • Figure 5 shows that the roadside system 2000 may include hardware resources, such as CPU, GPU, memory, storage devices, network devices, etc., and be used to support satellite positioning, real-time differential (Real time kinematic, RTK) positioning, LET/5G communication, WiFi Communication, C-2VX communication, etc. equipment.
  • the roadside system also includes the OS operating system and virtualization layer.
  • the virtualization layer virtualizes the physical resources of the roadside system.
  • Table 3 shows an exemplary resource slice classification table according to an embodiment of the present disclosure.
  • balanced slices represent balanced capabilities such as latency/bandwidth/computing/storage.
  • the bandwidth is between 10 and 100 Mbps
  • the processing latency is between 20 and 100 ms
  • low-latency slicing supports latency reduced to less than 20ms
  • large-bandwidth slicing supports bandwidth of more than 100Mbps
  • intelligent computing slicing supports intelligent decision-making and video encoding and decoding , Big data analysis computing power
  • large storage slices support EB level or support massive unstructured databases
  • high positioning accuracy slices support sub-meter positioning accuracy
  • high reliability slices support reliability reaching 99.99%.
  • Table 3 Resource slice classification table
  • VIMU can select appropriate resource slicing types for VRSI based on the resource demand characteristics of different scenarios, and deploy virtual RSU, virtual RSCCU, corresponding sensing equipment and traffic control equipment.
  • a balanced resource slice can be selected for an intersection scenario (for example, as shown in sub-area 2001 in Figure 2A).
  • This slice can be used to deploy, for example: 1 virtual RSU, which includes C-V2X intersection vehicle guidance algorithm applications and C-V2X related protocol stacks; and 1 virtual RSCCU, which is used for sensing device access and traffic control Equipment access, such as the access of PTZ laser camera equipment E shown in Figure 2, laser The access of radar equipment B and the access of traffic light A.
  • This slice can support vehicles passing through intersections in an orderly manner.
  • resource slicing By providing virtualized physical resources with different types of resource slices, appropriate types can be selected based on the resource demand characteristics of different sub-regions (such as different latency, bandwidth, computing, storage, positioning accuracy, reliability requirements, etc.) Resource slicing. This can provide flexible resource deployment and improve overall resource utilization.
  • the virtual infrastructure management unit can communicate via the new interface between RSS-VIUM and the central subsystem of the vehicle network cloud control platform, for example, the V2X.VIMU.INFO.UP interface is sent uplink from VIUM to the central subsystem. message, the V2X.VIMU.INTERSECTION.DOWN interface message is sent from the central subsystem to VIMU in the downstream.
  • the V2X.VIMU.INFO.UP interface message and the V2X.VIMU.INTERSECTION.DOWN interface message are new messages.
  • 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 uplink sends V2X.RSU from the VRSU to the central subsystem.
  • INFO.UP the V2X.RSU.RunningInfo.UP interface message is sent from the central subsystem to VRSU in the downlink. This is an extension to the existing interface between the central subsystem and RSS-RSU and the messages transmitted on this interface.
  • the VRSU can communicate with the onboard unit via the existing C-V2X PC5 interface.
  • the onboard unit can communicate with the central subsystem via the C-V2X Uu interface.
  • FIG. 6 shows an exemplary flowchart of a resource allocation method 6000 for a roadside system according to an embodiment of the present disclosure.
  • method 6000 includes step 6001.
  • 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. .
  • the roadside system information table can be reported by VIMU through the V2X.VIMU.INFO.UP message on the newly added interface between RSS-VIMU and the central subsystem of the vehicle network cloud control platform.
  • Table 4 shows an exemplary roadside system basic information table according to an embodiment of the present disclosure.
  • the basic information table may include timestamp, system identifier (RSS identifier), RSS location (such as latitude and longitude), operating state (indicating whether the roadside system is in a resource virtualization state) and operating mode ( Normal mode, disaster recovery mode, or temporary emergency mode).
  • RSS identifier system identifier
  • RSS location such as latitude and longitude
  • operating state indicating whether the roadside system is in a resource virtualization state
  • operating mode Normal mode, disaster recovery mode, or temporary emergency mode
  • Table 4 Basic information table of roadside system
  • the central subsystem can select road map information within the appropriate coverage area and deliver it according to different operating modes.
  • the distributed map information can cover different radii and different numbers of intersections. Table 5 below shows an exemplary correspondence between the operating mode and the map coverage radius and the number of forks.
  • Step 6001 also includes obtaining map information.
  • 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 vehicle network cloud control platform central subsystem.
  • the map information can be based on the location information (such as latitude and longitude) reported by RSS.
  • the map information is the information of all map slices within a certain coverage area centered on the position of the RSS.
  • Map information can also be based on the operation mode reported by RSS. For example, for different operating modes, the map information is the information of all map slices in different coverage areas centered on the position of the RSS.
  • Table 6 shows an exemplary regional road information table according to an embodiment of the present disclosure.
  • the regional road information table may include an intersection information list DF_IntersectionList.
  • the regional road information table can contain timestamps, RSS identifiers, the number of intersections, and the list of intersection information.
  • intersection information list DF_IntersectionList can list the intersection identifier and bit of each intersection. Location information (such as latitude and longitude), junction type (crossroads, three-way intersection, sharp turn, etc.) and the identifier of the map slice to which the junction belongs.
  • Table 6 Regional road information table
  • method 6000 may also include step 6002.
  • VIMU determines the sub-areas in which the virtual roadside infrastructure (VRSI) is to be deployed, deploys a VRSI for each determined sub-area, and reports the results related to the determined sub-areas.
  • Regional VRSI related information may also include step 6002.
  • VIMU can determine the sub-area where virtual roadside infrastructure needs to be deployed based on map information associated with the location of the RSS. For example, all forks in the received map information are set as separate sub-areas in which corresponding VRSI is to be deployed.
  • VIMU can also determine the sub-areas where virtual roadside infrastructure needs to be deployed based on application scenarios.
  • VRSI does not need to be deployed for some forks indicated in the map information.
  • application scenarios are not limited to the intersections and curve blind areas illustrated in this disclosure.
  • application scenarios may also include but are not limited to: autonomous parking based on roadside sensing, collaborative ramp merging, collaborative fork traffic, differential data services, dynamic lane management, station route guidance services, floating car data collection, Slow traffic warning, vehicle numbering Fleet management, road toll services and more.
  • VIMU can determine the number of VRSIs to deploy based on the determined number of sub-areas.
  • VIMU can also assign a VRSI identifier, VRSU identifier, and specify the location of the VRSU to each VRSI.
  • the location of the VRSU may be the latitude and longitude coordinates of the fork corresponding to the VRSU.
  • VIMU can select the appropriate virtual drive test infrastructure resource slice type for the VRSI of the sub-area based on the resource demand characteristics of each sub-area.
  • Resource demand characteristics include, but are not limited to, delay requirements, bandwidth requirements, computing power requirements, storage capacity requirements, etc.
  • the virtual drive test infrastructure resource slice type is selected from Table 3, for example.
  • Resource demand characteristics can be associated with application scenarios.
  • Different C-V2X application scenarios put forward different requirements for roadside infrastructure in terms of latency, bandwidth, computing, storage, positioning accuracy, reliability, etc.
  • autonomous driving and sensor sharing scenarios require a minimum latency of 3ms
  • sensor sharing scenarios require a bandwidth of up to 1Gbps
  • global road condition analysis scenarios place higher requirements on computing power, and must be able to quickly analyze video and radar data. Signals and other sensory content are accurately analyzed and processed.
  • VRSI 2005 for the intersection scenario shown in Figure 2A can select balanced resource slicing as shown in Table 3.
  • VIUM can report the roadside system basic information table containing information related to the VRSI of the determined sub-area through the V2X.VIMU.INFO.UP message on the new interface between VIUM and the central subsystem of the vehicle network cloud control platform. .
  • 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 timestamp, RSS identifier, RSS location, number of VRSI to be deployed and VRSI information list DF_VrsiList.
  • DF_VrsiList lists, for each VRSI, the VRSI identifier, VRSI slice type, associated fork-in-the-road identifier, assigned VRSU identifier, and VRSU deployment location.
  • Table 7 Basic information table of roadside system
  • Method 6000 may also include step 6003, in which the VIMU receives historical data related to the sub-region.
  • VIMU may receive information related to the determined sub-region from the Internet of Vehicles cloud control platform central subsystem via the V2X.VIMU.INTERSECTION.DOWN message on the newly added interface between VIMU and the Internet of Vehicles cloud control platform central subsystem.
  • Regional road information table with associated historical data may be utilized.
  • the historical data includes, for example, the determined historical road traffic volume of each sub-area, historical accident frequency, and so on. Historical data is sent to VIMU in the form of a regional road information table, for example.
  • Table 8 shows an exemplary regional road information table including exemplary historical data according to an embodiment of the present disclosure.
  • the table may include timestamps, RSS identifiers, the number of forks in the road, and a list of fork-in-the-road historical information.
  • intersection history information list DF_IntersectionHistoryList for each intersection in the sub-region, the intersection identifier, intersection traffic flow (such as monthly traffic volume) and intersection accident frequency (such as the average number of traffic accidents per month) are listed ).
  • Table 8 Regional road information table
  • Method 6000 may also include step 6004, in which VIMU allocates virtualized physical resources to each VRSI and reports the resource allocation results.
  • the physical resources of the RSS's roadside infrastructure are virtualized and allocated. At least a portion of the virtualized resources may be allocated to each VRSI based on the VRSI slice type and/or historical data of the respective sub-region. This may include allocating a virtual RSU for each VRSI, and may also include allocating a virtual RSCCU and associated traffic control device and/or roadside sensing device for each VRSI. It may also include allocating air bearer equipment for each VRSI.
  • VRSU resources and/or VRSCCU resources can be deployed to support the deployment of more roadside sensing equipment and/or traffic control equipment.
  • VIMU can report the roadside system basic information table containing resource configuration results through the V2X.VIMU.INFO.UP message on the new interface between VIMU and the central subsystem of the Internet of Vehicles cloud control platform.
  • Table 9 shows a roadside system basic information table including exemplary resource configuration results according to an embodiment of the present disclosure.
  • the basic information table may include timestamp, RSS identifier, RSS location, VRSI number and VRSI information list.
  • 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 position is, for example, the latitude and longitude coordinates of the intersection corresponding to the VRSU.
  • RSU resource configuration and VRSCCU resource configuration configure associated virtual CPU configuration, virtual memory configuration, virtual disk configuration and virtual network configuration for each VRSU and VRSCCU.
  • Roadside sensing device configuration and traffic control device configuration are specific to each sensing device. For each traffic control device, the device identifier, device name, and device address are listed.
  • Table 9 Basic information table of roadside system
  • Method 6000 may also include step 6005.
  • VIMU starts each VRSI to provide air roadside infrastructure services, and VRSU reports business data and operation information.
  • VIMU can activate VRSU and VRSCCU of each VRSI to provide air roadside infrastructure services.
  • Each VRSU can report business data and running information respectively through 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.
  • Each VRSU can report regularly according to a predetermined cycle, or can trigger a report in response to a predetermined event.
  • Table 10 shows an exemplary RSU information table including exemplary service data according to an embodiment of the present disclosure.
  • Table 10 RSU information table (including RSU business data)
  • RSU service data may include RSU identifier, VRSU identifier, RSU location information, configuration data, operating form, operating mode, etc.
  • Table 11 shows an RSU operating information table including exemplary RSU operating information according to an embodiment of the present disclosure.
  • the RSU running information table may include timestamp, RSU identifier, VRSU identifier and device running status information.
  • Device running status information includes virtual CPU running information, virtual memory running information, virtual disk running information and virtual network running information.
  • Table 11 RSU operation information table (RSU operation and maintenance management)
  • FIG. 6 is only an exemplary resource allocation method of the roadside system according to an embodiment of the present disclosure. Variations of various roadside system resource allocation methods are contemplated without departing from the teachings of the present disclosure.
  • RSS equipment After the RSS equipment arrives at the scene, its position is determined through the positioning module of the RSS and the determined position is reported to the central subsystem together with the operating form and operating mode of the RSS.
  • RSS receives the distributed map information and automatically determines sub-areas, deploys VRSI, and allocates virtual resources.
  • the operator can pre-specify the location where the RSS is to be deployed and the sub-area where the VRSI is to be deployed, and specify for each sub-area the location to be allocated to the VRSI. resource. Then software and hardware resources are deployed to the site to provide services according to the pre-planned plan.
  • resource allocation may be re-performed based on changes in available resources during actual operation. For example, when some equipment of a VRSI fails during the operation of RSS, appropriate resources can be re-allocated to each VRSI based on the resource demand characteristics of each VRSI and the total amount of available resources.
  • resource allocation may be re-performed based on changes in resource requirements during actual operation. For example, when the resource demand of a certain VRSI increases during the operation of RSS, appropriate resources can be re-allocated to each VRSI based on the resource demand characteristics of each VRSI and the total amount of available resources. For example, more VRSU resources and/or VRSCCU resources are allocated to a VRSI with increased resource requirements, and less VRSU resources and/or VRSCCU resources are allocated to a VRSI with reduced resource requirements.
  • step 6003 it is not necessary to collect historical data of the sub-region, that is, step 6003 can be omitted.
  • the cloud control platform can provide associated historical data when providing map information.
  • the aerial platform-based roadside system can be applied to various scenarios.
  • Figure 7 illustrates a fork intersection traffic scenario assisted by the roadside subsystem 7000 according to an embodiment of the present disclosure.
  • the roadside subsystem based on the aerial platform can be used to assist autonomous driving vehicles in a safe and efficient manner. Go through the forks in sequence.
  • the roadside subsystem 7000 may be, for example, the part of the road test system 2000 shown in FIG. 2A that relates to the subarea 2001 (i.e., VRSI 2005). As shown in Figure 7, this part includes: a low-altitude tethered balloon 201, which carries an airborne RSU (more specifically, virtual RSU 1) and camera E; two ultra-low-altitude tethered balloons 202 and 203 near the intersection, where The tethered balloon 202 carries air traffic lights, and the tethered balloon 203 carries aerial lidar.
  • the roadside subsystem 7000 can be used to assist autonomous vehicles EV 1 and EV 2 to pass intersections safely and orderly.
  • the vehicles EV1 and EV2 can send vehicle driving information to the air RSU (more specifically, the virtual RSU 1), and the air RSU (more specifically, the virtual RSU 1) determines the vehicle driving information based on the vehicle driving information, the air traffic light information of the target intersection,
  • the driving information reported by other vehicles and the roadside sensing information of the air lidar generate traffic scheduling information for dispatching EV1 and EV2 to pass through the intersection, and send the traffic dispatching information to EV1 and EV2 to dispatch EV1 and EV2 to pass safely. crossroads.
  • FIG. 8 shows an exemplary flowchart of a method performed by an electronic device according to an embodiment of the present disclosure.
  • the electronic device is, for example, a vehicle-mounted device.
  • the electronic device may also be a separate device capable of coupling and communicating with the vehicle.
  • the electronic device is, for example, the vehicle-mounted device of the vehicle EV 1 or EV 2 in FIG. 7 .
  • method 8000 may include step 8001 , in which, while within a first sub-area of at least one sub-area within the coverage of an aerial platform-based roadside system (RSS), the electronic device is from A first VRSU identifier is received by a first virtual roadside unit (VRSU) in a first virtual roadside infrastructure (VRSI) serving the first sub-region.
  • RSS aerial platform-based roadside system
  • VRSU virtual roadside unit
  • VRSI virtual roadside infrastructure
  • the first VRSI is, for example, VRSI 2005 in Figure 2A
  • the first VRSU identifier is, for example, the identifier of the VRSU assigned to VRSI 2005.
  • the VRSU identifier may be associated with a VRSI identifier identifying the corresponding VRSI and the virtual infrastructure resource slice type selected for that VRSI.
  • the VRSU identifier may 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 allocated by VIMU for the VRSI of the corresponding sub-area.
  • VRSU identifiers and VRSCCU identifiers have associated resource configurations, including virtual At least one of CPU configuration, virtual memory configuration, virtual disk configuration and virtual network configuration.
  • New messages such as VRSI identifier, VRSU identifier, virtual infrastructure resource slice type, VRSCCU identifier and associated resource configuration are sent by VIMU via the new interface between VIMU and the Internet of Vehicles operation and control platform (for example, V2X .VIMU.INFO.UP interface message) is reported to the Internet of Vehicles operation and control platform.
  • the configuration of VRSI, virtual infrastructure resource slice type, VRSU and VRSCCU is configured by VIMU based on one or more of the map information, application scenarios, resource demand characteristics, historical data and other factors associated with the deployment location of the roadside system. of.
  • the method 8000 may also include step 8003, in which the electronic device sends the traveling information of the vehicle carrying the electronic device to the first VRSU.
  • Driving information may include driving speed, driving direction, navigation route information, etc.
  • Method 8000 may further include step 8005, in which the electronic device receives a traffic scheduling message from the first VRSU, wherein the traffic scheduling message includes the first VRSU identifier, and the traffic scheduling message includes the traffic scheduling message sent based on the electronic device.
  • the driving information is also traffic scheduling information based on at least one of the driving information of other vehicles sent by other electronic devices, the roadside sensing information from the first VRSI, and the traffic light information of the target intersection.
  • the roadside sensing information from the first VRSI is, for example, obtained by a roadside sensing device of the first VRSI.
  • Figure 9 illustrates a perception data sharing scenario assisted by a roadside subsystem 9000 according to an embodiment of the present disclosure.
  • Perceptual data sharing scenarios refer to areas without roadside infrastructure implementation such as wild rescue, forest disaster relief, geological exploration, wild adventure, and wild vehicle training competitions, where short-term (e.g., several days) roadside infrastructure services need to be provided. For example, when a forest fire occurs, a temporary road infrastructure service based on an airborne disaster recovery platform is launched for fire-fighting vehicles, material transport vehicles, etc.
  • the roadside subsystem 9000 may be, for example, the part of the road test system 2000 shown in FIG. 2A that relates to the subarea 2005 (i.e., VRSI 2007). As shown in Figure 9, this part includes: a low-altitude tethered balloon 201, which carries an airborne RSU (more specifically, the virtual RSU 2) and a camera F; an ultra-low-altitude tethered balloon 204 near the bend, which carries an airborne lidar C.
  • the roadside subsystem 9000 can be used to assist the sharing of perception data of autonomous vehicles EV 1 and EV 2.
  • Vehicle EV1 and aerial RSU can detect other surrounding traffic participants (including but not limited to vehicles, pedestrians, cyclists and other targets) or roads through their own or networked sensing devices (aerial pan-tilt cameras, aerial lidar and other sensors).
  • Abnormal situation information such as: road traffic incidents (such as traffic accidents, etc.), abnormal vehicle behavior (speeding, leaving the lane, driving in the wrong direction, irregular driving, abnormal stationarity, etc.), road obstacles (such as falling rocks, information such as scattered objects, dead branches, etc.) and road conditions (such as water accumulation, ice, etc.).
  • the air RSU (more specifically, virtual RSU 2) can receive the information sensed by EV1, process the received information sensed by EV1 and/or the information sensed by itself to obtain driving assistance information, and convert the driving assistance information Sent to other vehicles near EV1, such as the following vehicle EV2. Based on the received driving assistance information, the vehicle EV2 can sense in advance traffic participants or abnormal road conditions that are not within its own field of view, and assist itself in making correct driving decisions.
  • FIG. 10 shows an exemplary flowchart of a method 1000 performed by an electronic device according to an embodiment of the present disclosure.
  • the electronic device is, for example, a vehicle-mounted device.
  • the electronic device may also be a separate device capable of coupling and communicating with the vehicle.
  • the electronic device may be an on-board device of the vehicle EV 1 or EV 2 in Figure 9.
  • 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 is configured to serve the first sub-area.
  • a first virtual roadside unit (VRSU) in a first virtual roadside infrastructure (VRSI) receives a first VRSU identifier.
  • the first VRSI is, for example, VRSI 2007 in Figure 2A
  • the first VRSU identifier is, for example, the identifier of the VRSU allocated for VRSI 2007.
  • the method 1000 may include step 1003, in which the electronic device sends a detection result to the first VRSU, the detection result including the driving environment information detected by the electronic device via the sensing device.
  • the electronic device can perform detection and report detection results according to a certain time period.
  • the electronic device may also only send the detection result to the first VRSU when it is determined that the detection result shows abnormality.
  • the electronic device may also send detection results in response to a request from the RSU (more specifically, the virtual RSU 2).
  • 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 the first VRSU identifier, the driving assistance message includes based on detection results sent by other electronic devices and Driving assistance information of at least one of the detection results of the first VRSU.
  • the first VRSU may send the driving assistance information only when necessary (for example, only when the first VRSU determines that abnormal environment 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.
  • step 1003 can be performed if the electronic device has sensing capabilities. If the electronic device does not have sensing capabilities, step 1003 may not be performed.
  • the electronic device itself has the ability to communicate with the RSU (more specifically, the virtual RSU), But another electronic device around it does not have the ability to communicate with the RSU, but can only communicate with this electronic device. In such a case, the electronic device may send the driving assistance information received from the RSU or its own detection result to the other electronic device.
  • the electronic device may also send a message containing the first VRSU identifier to the first VRSU.
  • the electronic device may receive a payment request message (Action-Request) from the first VRSU, where the payment request message includes the first VRSU identifier.
  • the electronic device may send a vehicle payment message to the first VRSU, and the vehicle payment message may include the first VRSU identifier.
  • the vehicle payment message may include an action-response message (Action-Response).
  • the action-response message may define the vehicle's response message to the payment request message initiated by the first VRSU, including the own vehicle identifier and the first VRSU identifier. characters, payment information, and the operation status of payment request messages, etc.
  • the vehicle payment message may include a vehicle service indication (VSI), and the vehicle service indication includes the first VRSU identifier.
  • VSI vehicle service indication
  • FIG. 11 illustrates an exemplary flowchart of a method 1100 performed by an aerial platform-based roadside system (RSS) in accordance with an embodiment of the present disclosure.
  • RSS roadside system
  • method 1100 includes operation 1101, in which an airborne roadside infrastructure carrier platform (APRSI) including an airborne carrier platform and roadside infrastructure carried on the airborne carrier platform connects the roadside infrastructure to the airborne carrier platform.
  • API airborne roadside infrastructure carrier platform
  • Method 1100 may further include operation 1103 in which allocating, by a virtual infrastructure management unit (VIMU), at least a portion of virtualized physical resources to each of the at least one sub-region within the coverage of the RSS.
  • VIP virtual infrastructure management unit
  • a VRSI is deployed in a region, each VRSI includes at least one virtual roadside unit (VRSU), and each VRSU includes at least a part of the physical resources (including hardware resources and software resources) of the virtualized roadside unit (RSU).
  • FIG. 12 illustrates an exemplary flowchart of a method 1200 performed by a VIMU according to an embodiment of the present disclosure.
  • the method 1200 includes step 1201 , in which a virtualized roadside base of the RSS is allocated for each sub-area in at least one sub-area within the coverage area of the aerial platform-based Roadside System (RSS). At least part of the physical resources of the infrastructure is used to deploy a virtual roadside infrastructure (VRSI) for the sub-area.
  • Each VRSI includes at least a virtual roadside unit (VRSU).
  • Each VRSU includes a virtualized roadside unit (RSU). ) of at least part of the physical resources (including hardware resources and software resources).
  • An electronic device including:
  • a processor coupled to the memory, configured to execute the computer-executable instructions to perform the following operations:
  • RSS aerial platform-based roadside system
  • VRSI virtual roadside infrastructure
  • VRSU receives a first VRSU identifier.
  • each VRSI includes a VRSU
  • each VRSU includes at least a part of the hardware resources and software resources of the virtualized roadside unit (RSU)
  • each VRSU has a corresponding VRSU identifier
  • the first VRSI includes a first VRSCCU, and the first VRSCCU includes at least a part of the hardware resources and software resources of the virtualized roadside computing control unit,
  • the first VRSU identifier, the first VRSI identifier and the first VRSCCU identifier are allocated by the virtual infrastructure management unit (VIMU) of the RSS.
  • VIP virtual infrastructure management unit
  • the resource configuration associated with the first VRSU identifier or the resource configuration associated with the first VRSCCU identifier allocated by 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.
  • the at least one sub-area within the coverage area of the RSS where VRSI needs to be deployed is determined based on at least map information related to the location of the RSS.
  • allocating at least a portion of virtualized physical resources to each of the at least one sub-region to deploy a VRSI for each sub-region includes the following operations performed by the VIMU:
  • Allocate resources for VRSI of each sub-area in the at least one sub-area based on an application scenario of the sub-area.
  • allocating at least a portion of the virtualized physical resources to each of the at least one sub-region to deploy a VRSI for each sub-region includes the following operations performed by the VIMU:
  • Resources for VRSI of each of the at least one sub-region are allocated based on historical data of the sub-region.
  • the first VRSU identifier, the first VRSI identifier and the first virtual roadside infrastructure resource slice type are allocated by VIMU,
  • the virtual roadside infrastructure resource slice type is allocated based on the resource demand characteristics of the first sub-region.
  • resource demand characteristics of the first sub-region include at least one of the following:
  • virtual roadside infrastructure resource slice type includes one of the following:
  • the traffic scheduling message includes the first VRSU identifier
  • the traffic scheduling message includes travel information based on the travel information sent by the electronic device and based on travel information of other vehicles sent by other electronic devices.
  • traffic scheduling information from at least one of the roadside sensing information of the first VRSI and the traffic light information of the target intersection.
  • a driving assistance message is received from the first VRSU, wherein the driving assistance message includes a first VRSU identifier, the driving assistance message includes driving assistance based on at least one of a detection result sent by the other electronic device and a detection result of the first VRSU information.
  • a message including the first VRSU identifier is sent to the first VRSU.
  • the RunningInfo.UP message reports business data and running information respectively.
  • a roadside system (RSS) based on an aerial platform including:
  • an airborne roadside infrastructure bearing platform including an airborne bearing facility and a roadside infrastructure carried on the airborne bearing facility, the APRSI being configured to virtualize the physical resources of the roadside infrastructure;
  • a virtual infrastructure management unit configured to allocate at least a portion of virtualized physical resources to each sub-area in at least one sub-area within the coverage of the RSS to deploy a VRSI for each sub-area, each VRSI at least includes A virtual roadside unit (VRSU), each VRSU including at least a portion of the hardware resources and software resources of the virtualized roadside unit (RSU).
  • VIP virtual infrastructure management unit
  • each VRSI further includes a virtual roadside computing control unit (VRSCCU), and the VRSCCU includes hardware resources and software resources of the virtualized roadside computing control unit. At least part of it.
  • VRSCCU virtual roadside computing control unit
  • 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 traffic control equipment and roadside sensing equipment. Access to sensing devices.
  • VRSCCU virtual roadside computing control unit
  • the RSS of item 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.
  • the at least one sub-area within the coverage area of the RSS where VRSI needs to be deployed is determined based on at least map information related to the location of the RSS.
  • the first system basic information is reported to the Internet of Vehicles cloud control platform via the first interface message on the interface between VIMU and the Internet of Vehicles cloud control platform.
  • the basic information of the first system includes the location information, operation form and operation mode of RSS, where the operation The shape indicates whether the RSS is virtual;
  • a virtual roadside infrastructure resource slice type is determined for the sub-area.
  • the basic information of the second system is reported through the third interface message on the interface between VIMU and the Internet of Vehicles cloud control platform.
  • the basic information of the second system includes the VRSI identifier and the virtual roadside infrastructure associated with the VRSI identifier. Specify resource slice type and VRSU identifier.
  • Allocate resources for VRSI of each sub-area in the at least one sub-area based on an application scenario of the sub-area.
  • VRSI resources for each of the at least one sub-region are allocated based on historical data of the sub-region.
  • the basic information of the third system is reported through 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 sensing 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 VRSU resource configuration and VRSCCU resource configuration includes at least one of the following: virtual CPU configuration, virtual memory configuration, virtual disk configuration and virtual network configuration.
  • the UP message reports business data and operating information to the Internet of Vehicles cloud control platform respectively.
  • a pass is generated based on the received travel information and based on at least one of travel information of other vehicles sent by other electronic devices within the sub-area served by it, roadside sensing information from the first VRSI, and traffic light information of the target intersection. Scheduling information;
  • a virtual infrastructure management unit including:
  • a processor coupled to the memory, configured to execute the computer-executable instructions to perform the following operations:
  • 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).
  • RSU aerial platform-based road-side system
  • a method performed by an electronic device comprising:
  • RSS aerial platform-based roadside system
  • VRSI virtual roadside infrastructure
  • VRSU virtual A roadside unit
  • the physical resources of the roadside infrastructure are virtualized by the Airborne Roadside Infrastructure Carrier Platform (APRSI), which includes the airborne carrier platform and the roadside infrastructure hosted on the airborne carrier platform; and
  • API Airborne Roadside Infrastructure Carrier Platform
  • the virtual infrastructure management unit allocates at least part of the virtualized physical resources to each sub-area in at least one sub-area within the coverage of the RSS to deploy a VRSI for each sub-area.
  • Each VRSI at least includes a virtual Roadside units (VRSU), each VRSU including at least a portion of the hardware resources and software resources of a virtualized roadside unit (RSU).
  • VRSU virtual Roadside units
  • RSU virtualized roadside unit
  • 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).
  • RSU aerial platform-based road-side system
  • a computer storage medium storing computer-executable instructions that, when executed by a processor, perform the method of any one of items 36-38.
  • a computer program product comprising computer-executable instructions that, when executed by a processor, perform the method of any one of items 36-38.
  • the technology of the present disclosure can be applied to a variety of products.
  • the roadside unit of the present disclosure can be implemented, for example, by using a roadside unit (RSU, Road Side Unit) in the Internet of Vehicles.
  • RSU Road Side Unit
  • the electronic device of the present disclosure can be implemented using a terminal device, for example.
  • the terminal device may be implemented as a mobile terminal such as a smartphone, a tablet personal computer (PC), Notebook PCs, portable game terminals, portable/dongle-type mobile routers and digital camera devices) or vehicle-mounted terminals (such as car navigation equipment).
  • the terminal device may also be implemented as a terminal that performs machine-to-machine (M2M) communication (also called a machine type communication (MTC) terminal).
  • M2M machine-to-machine
  • MTC machine type communication
  • the terminal device may be a wireless communication module (such as an integrated circuit module including a single chip) installed on each of the above-mentioned terminals.
  • RSU 800 includes one or more antennas 810 and roadside equipment 820.
  • Roadside device 820 and each antenna 810 may be connected to each other via RF cables.
  • Antennas 810 each include a single or multiple antenna elements, such as multiple antenna elements included in a multiple-input multiple-output (MIMO) antenna, and are used by roadside device 820 to transmit and receive wireless signals.
  • RSU 800 may include multiple antennas 810.
  • multiple antennas 810 may be compatible with multiple frequency bands used by RSU 800.
  • the roadside device 820 includes a controller 821, a memory 822, a network interface 823, and a wireless communication interface 825.
  • the controller 821 may be, for example, a CPU or a DSP, and operates various functions of higher layers of the roadside device 820 . For example, the controller 821 generates data packets based on the data in the signal processed by the wireless communication interface 825 and delivers the generated packets via the network interface 823 .
  • the controller 821 may bundle data from multiple baseband processors to generate bundled packets, and deliver the generated bundled packets.
  • the controller 821 may have logical functions to perform controls such as radio resource control, radio bearer control, mobility management, admission control, and scheduling. This control can be performed in conjunction with nearby RSUs or core network nodes (such as Access and Mobility Management Function (AMF)).
  • the memory 822 includes RAM and ROM, and stores programs executed by the controller 821 and various types of control data such as terminal lists, transmission power data, and scheduling data.
  • the network interface 823 is a communication interface used to connect the roadside device 820 to the core network 824 . Controller 821 may communicate with core network nodes or additional RSUs via network interface 823. In this case, the RSU 800 and the core network node or other RSUs may be connected to each other through a logical interface (such as C-V2X uu interface, C-V2X PC5).
  • the network interface 823 may 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 may use a higher frequency band for wireless communication than the frequency band used by the wireless communication interface 825 .
  • the wireless communication interface 825 supports any cellular communication scheme and provides wireless connectivity via the antenna 810 to terminals located in the cell of the RSU 800.
  • Wireless communication interface 825 may generally include, for example, a baseband (BB) processor 826 and RF circuitry 827.
  • the BB processor 826 may perform, for example, encoding/decoding, modulation/demodulation, and multiplexing/demultiplexing, and perform layers such as L1, Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Convergence Protocol ( Various types of signal processing for PDCP)).
  • the BB processor 826 may have some or all of the above-mentioned logical functions.
  • the BB processor 826 may be a memory that stores a communication control program, or a module including a processor and related circuitry configured to execute the program.
  • the update program can cause the functionality of the BB processor 826 to change.
  • the module may be a card or blade that is inserted into a slot in the roadside device 820. Alternatively, the module may be a chip mounted on a card or blade.
  • the RF circuit 827 may include, for example, a mixer, filter, and amplifier, and transmit and receive wireless signals via the antenna 810.
  • the wireless communication interface 825 may include multiple BB processors 826.
  • multiple BB processors 826 may be compatible with multiple frequency bands used by RSU 800.
  • wireless communication interface 825 may include a plurality of RF circuits 827.
  • multiple RF circuits 827 may be compatible with multiple antenna elements.
  • FIG. 13 shows an example in which the wireless communication interface 825 includes a plurality of BB processors 826 and a plurality of RF circuits 827, the wireless communication interface 825 may also include a single BB processor 826 or a single RF circuit 827.
  • the RSU includes one or more antennas 840, roadside equipment 850, and RRH 860.
  • the RRH 860 and each antenna 840 may be connected to each other via RF cables.
  • Roadside equipment 850 and RRH 860 may be connected to each other via high speed lines such as fiber optic cables.
  • Antennas 840 each include a single or multiple antenna elements (such as multiple antenna elements included in a MIMO antenna) and are used by RRH 860 to transmit and receive wireless signals.
  • RSU 830 may include multiple antennas 840.
  • multiple antennas 840 may be compatible with multiple frequency bands used by RSU 830.
  • the roadside device 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 FIG. 13 .
  • 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 a BB processor 856, for example.
  • BB processor 856 is the same as BB processor 826 described with reference to FIG. 13 .
  • the wireless communication interface 855 may include multiple BB processors 856.
  • multiple BB processors 856 may be compatible with multiple frequency bands used by RSU 830.
  • FIG. 14 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.
  • 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 used to connect the roadside device 850 (wireless communication interface 855) to the communication in the above-mentioned high-speed line of the RRH 860.
  • RRH 860 includes a connection interface 861 and a wireless communication interface 863.
  • connection interface 861 is an interface for connecting the RRH 860 (wireless communication interface 863) to the roadside device 850.
  • the connection interface 861 may also be a communication module used for communication in the above-mentioned high-speed line.
  • Wireless communication interface 863 transmits and receives wireless signals via antenna 840.
  • Wireless communication interface 863 may generally include RF circuitry 864, for example.
  • RF circuitry 864 may include, for example, mixers, filters, and amplifiers, and transmits and receives wireless signals via antenna 840 .
  • wireless communication interface 863 may include a plurality of RF circuits 864.
  • multiple RF circuits 864 may support multiple antenna elements.
  • FIG. 14 shows an example in which the wireless communication interface 863 includes a plurality of RF circuits 864, the wireless communication interface 863 may also include a single RF circuit 864.
  • one or more components included in the processing circuit 1310 described with reference to FIG. 13 and the processing circuit 1610 described with reference to FIG. 16 may be implemented in the wireless communication interface 912 . Alternatively, at least some of these components may also be implemented by controller 821 and controller 851.
  • the smart phone 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 switch 915, one or more antennas 916, bus 917, battery 918, and auxiliary controller 919.
  • the processor 901 may be, for example, a CPU or a system on a chip (SoC), and controls 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 memory and hard disk.
  • External connection Port 904 is an interface for connecting external devices, such as memory cards and Universal Serial Bus (USB) devices, to smartphone 900 .
  • 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.
  • Sensors 907 may include a group of sensors such as measurement sensors, gyroscope sensors, geomagnetic sensors, and acceleration sensors.
  • 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 a 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.
  • 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 a BB processor 913 and an RF circuit 914, for example.
  • the BB processor 913 can perform, for example, encoding/decoding, modulation/demodulation, and multiplexing/demultiplexing, and perform various types of signal processing for wireless communication.
  • RF circuitry 914 may include, for example, mixers, filters, and amplifiers, and transmit and receive wireless signals via 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 FIG.
  • the wireless communication interface 912 may include multiple BB processors 913 and multiple RF circuits 914 .
  • FIG. 15 shows an example in which the wireless communication interface 912 includes a plurality of BB processors 913 and a plurality of RF circuits 914, the wireless communication interface 912 may also include a single BB processor 913 or a single RF circuit 914.
  • the wireless communication interface 912 may support other types of wireless communication schemes, such as short-range wireless communication schemes, near field communication schemes, and wireless local area network (LAN) schemes.
  • the wireless communication interface 912 may include a BB processor 913 and an RF circuit 914 for each wireless communication scheme.
  • Each of the antenna switches 915 switches the connection destination of the antenna 916 between a plurality of circuits included in the wireless communication interface 912 (for example, circuits for different wireless communication schemes).
  • Antennas 916 each include a single or multiple antenna elements (such as multiple antenna elements included in a MIMO antenna) and are used by wireless communication interface 912 to transmit and receive wireless signals.
  • smartphone 900 may include multiple antennas 916.
  • FIG. 15 shows an example in which smartphone 900 includes multiple antennas 916
  • smartphone 900 may also include a single antenna 916 .
  • smartphone 900 may include an antenna 916 for each wireless communication scheme.
  • the antenna switch 915 may be omitted from the configuration of the smartphone 900 .
  • 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 to each other. connect.
  • the battery 918 provides power to the various blocks of the smartphone 900 shown in Figure 15 via feeders, which are partially shown in the figure as dotted lines.
  • the auxiliary controller 919 operates the minimum necessary functions of the smartphone 900 in the sleep mode, for example.
  • one or more components included in the processing circuit 1310 described with reference to FIG. 13 and the processing circuit 1610 described with reference to FIG. 16 may be implemented in the wireless communication interface 912 .
  • at least some of these components may also be implemented by processor 901 or auxiliary controller 919.
  • FIG. 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 media 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 battery 938.
  • GPS global positioning system
  • the processor 921 may be, for example, a CPU or an SoC, and controls the navigation function and other functions of the car navigation device 920 .
  • the memory 922 includes RAM and ROM, and stores data and programs executed by the processor 921 .
  • the GPS module 924 measures the location (such as latitude, longitude, and altitude) of the car navigation device 920 using GPS signals received from GPS satellites.
  • Sensors 925 may include a group of sensors such as gyroscope sensors, geomagnetic sensors, and air pressure sensors.
  • the data interface 926 is connected to, for example, the vehicle-mounted network 941 via a terminal not shown, and acquires data generated by the vehicle (such as vehicle speed data).
  • the content player 927 reproduces content stored in storage media, such as CDs and DVDs, which are inserted into the storage media interface 928 .
  • the input device 929 includes, for example, a touch sensor, a button, or a switch configured to detect a touch on the screen of the display device 930, and receives an operation or information input from a user.
  • the display device 930 includes a screen such as an LCD or an 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.
  • the wireless communication interface 933 supports any cellular communication scheme such as LTE and LTE-Advanced, and performs wireless communication.
  • Wireless communication interface 933 may generally include, for example, BB processor 934 and RF circuitry 935.
  • the processor 934 may perform, for example, encoding/decoding, modulation/demodulation, and multiplexing/demultiplexing, and perform various types of signal processing for wireless communications.
  • the RF circuit 935 may include, for example, a mixer, filter, and amplifier, and transmit and receive wireless signals via the 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 FIG.
  • the wireless communication interface 933 may include multiple BB processors 934 and multiple RF circuits 935 .
  • FIG. 16 shows an example in which the wireless communication interface 933 includes a plurality of BB processors 934 and a plurality of RF circuits 935, the wireless communication interface 933 may also include a single BB processor 934 or a single RF circuit 935.
  • the wireless communication interface 933 may support other types of wireless communication schemes, such as short-range wireless communication schemes, near field communication schemes, and wireless LAN schemes.
  • the wireless communication interface 933 may include a BB processor 934 and an RF circuit 935 for each wireless communication scheme.
  • Each of the antenna switches 936 switches the 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.
  • the antennas 937 each include a single or multiple antenna elements (such as multiple antenna elements included in a MIMO antenna) and are used by the wireless communication interface 933 to transmit and receive wireless signals.
  • the car navigation device 920 may include a plurality of antennas 937 .
  • FIG. 16 shows an example in which the car navigation device 920 includes a plurality of antennas 937, the car navigation device 920 may also include a single antenna 937.
  • the car navigation device 920 may include an antenna 937 for each wireless communication scheme.
  • the antenna switch 936 may be omitted from the configuration of the car navigation device 920.
  • the battery 938 provides power to the various blocks of the car navigation device 920 shown in FIG. 16 via feeders, which are partially shown in the figure as dotted lines. Battery 938 accumulates power provided from the vehicle.
  • one or more components included in the processing circuit 1910 described with reference to FIG. 19 may be implemented in the wireless communication interface 912 .
  • at least some of these components may be implemented by processor 921.
  • the technology of the present disclosure may 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 .
  • 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 .
  • the present disclosure is implemented as a system, apparatus, method or as a computer program product in a computer-readable storage medium (eg, a non-transitory storage medium). Therefore, the present disclosure can be implemented in various forms, such as a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microprogram code, etc.), or it can also be implemented as a software and hardware implementation form. The following will be referred to as "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.
  • each block in the flowchart or block diagrams may represent a module, section, or portion of program code, which includes one or more executable instructions to implement the specified logical functions.
  • the functions described in the blocks may occur out of the order depicted in the figures. For example, two blocks illustrated as linked may actually be executed simultaneously, or in some cases also in the reverse order depending on the functionality involved.
  • each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations may be implemented by systems based on special purpose hardware, or combinations of special purpose hardware and computer instructions. to perform a specific function or operation.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Traffic Control Systems (AREA)

Abstract

本公开涉及基于空中平台的路侧系统。根据实施例，提供一种电子设备，包括：存储器，存储计算机可执行指令；和处理器，其与存储器耦接，被配置为执行所述计算机可执行指令来执行如下操作：在处于基于空中平台的路侧系统的覆盖范围内的至少一个子区域中的第一子区域内时，从服务于第一子区域的第一虚拟路侧基础设施中的第一虚拟路侧单元接收第一虚拟路侧单元标识符。

Description

基于空中平台的路侧系统 技术领域
本公开总体上涉及通信技术，更具体而言，本公开涉及基于空中平台的路侧系统和相关联的方法、电子设备、虚拟基础设施管理单元和计算机程序介质。
背景技术
C-V2X(Cellular Vehicle-to-Everything)蜂窝车联网是基于4G/5G等蜂窝网通信技术演进形成的车用无线通信技术，包括车载单元之间通讯、车载单元与路侧单元通讯、车载单元与行人设备通讯、车载单元与网络之间通讯。
路侧基础设施一般固定安装在道路两侧的交通设施上，但在发生地震、大面积停电等灾害时，路侧基础设施可能会全部瘫痪。此外，在一些偏远地区，诸如山区、森林地带，往往没有设置路侧基础设施。
无人自动驾驶车辆(例如维持城市基本运行的无人消防车、无人救护车、无人食品运输车、无人应急抢险车等)越来越普及，在全部或部分地面路侧基础设施瘫痪时，需要应急路侧基础设施来保障这些城市无人车辆的有序运行。
另外，在野外救援探险、森林救灾、地质勘探等无路侧基础设施的情况下，也会需要临时应急的路侧基础设施。
发明内容
在此部分给出了关于本公开的简要概述，以便提供关于本公开的一些方面的基本理解。但是，应当理解，这个概述并不是关于本公开的穷举性概述。它并不是意图用来确定本公开的关键性部分或重要部分，也不是意图用来限定本公开的范围。其目的仅仅是以简化的形式给出关于本公开的某些概念，以此作为稍后给出的更详细描述的前序。
根据本公开的一个方面，提供一种电子设备，包括：存储器，存储计算机可执行指令；和处理器，其与存储器耦接，被配置为执行所述计算机可执行指令来执行如下操作：在处于基于空中平台的路侧系统(Road Side System，RSS)的覆盖范围内的至少 一个子区域中的第一子区域内时，从服务于第一子区域的第一虚拟路侧基础设施(Virtual Road Side Infrastructure，VRSI)中的第一虚拟路侧单元(Virtual Road Side Unit，VRSU)接收第一VRSU标识符。
在一些实施例中，通过将RSS的路侧基础设施的物理资源进行虚拟化并为所述至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI，每个VRSI包括一VRSU，每个VRSU包括被虚拟化的路侧单元(Road Side Unit，RSU)的硬件资源和软件资源的至少一部分，每个VRSU具有相应的VRSU标识符，所述至少一个子区域包括第一子区域。
在一些实施例中，第一VRSU标识符与第一VRSI的第一VRSI标识符和第一虚拟路侧计算控制单元(Road Side Computing Control Unit，VRSCCU)标识符相关联，第一VRSI包括第一VRSCCU，第一VRSCCU包括被虚拟化的路侧计算控制单元的硬件资源和软件资源的至少一部分，第一VRSU标识符、第一VRSI标识符和第一VRSCCU标识符是由所述RSS的虚拟基础设施管理单元(Virtual Infrastructure Manangement Unit,VIMU)分配的。
在一些实施例中，由VIMU分配的与第一VRSU标识符相关联的资源配置或与第一VRSCCU标识符相关联的资源配置包括以下中至少一者：虚拟CPU配置，虚拟内存配置，虚拟磁盘配置和虚拟网络配置。
在一些实施例中，第一VRSI标识符、第一VRSU标识符和第一VRSCCU标识符由VIMU经由VIMU与车联网云控平台之间的接口上的第一接口消息上报给车联网云控平台。
在一些实施例中，所述至少一个子区域是由VIMU通过如下操作确定的：至少基于与RSS的位置有关的地图信息确定RSS的覆盖范围内需要部署VRSI的所述至少一个子区域。
在一些实施例中，所述地图信息是由VIMU经由VIMU与车联网云控平台之间的接口上的第二接口消息从车联网云控平台接收的。
在一些实施例中，为所述至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI包括由VIMU执行的以下操作：基于所述至少一个子区域中每个子区域的应用场景分配用于该子区域的VRSI的资源。
在一些实施例中，为所述至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI包括由VIMU执行的以下操作：基于所述至少一个子区域中的每个子区域的历史数据分配用于该子区域的VRSI的资源。
在一些实施例中，第一VRSU标识符与第一VRSI的第一VRSI标识符和第一虚拟路侧基础设施资源切片类型相关联，第一VRSU标识符、第一VRSI标识符和第一虚拟路侧基础设施资源切片类型是由VIMU分配的，所述虚拟路侧基础设施资源切片类型是基于第一子区域的资源需求特征分配的。
在一些实施例中，VRSI标识符、VRSU标识符和虚拟路侧基础设施资源切片类型由VIMU经由VIMU与车联网云控平台之间的接口上的第三接口消息上报给车联网云控平台。
在一些实施例中，第一子区域的资源需求特征包括以下中的至少一者：时延要求，带宽要求，计算能力要求，和存储能力要求。
在一些实施例中，虚拟路侧基础设施资源切片类型包括以下之一：均衡性切片，低时延型切片，大带宽型切片，智能计算型切片，大存储型切片，高定位精度型切片，和高可靠型切片。
在一些实施例中，处理器还被配置为执行如下操作：向第一VRSU发送装载所述电子设备的车辆的行驶信息；和接收来自第一VRSU的通行调度消息，其中，该通行调度消息包括第一VRSU标识符，所述通行调度消息包括基于所述电子设备发送的行驶信息并且基于其它电子设备发送的其它车辆的行驶信息、来自第一VRSI的路侧感知信息、目标路口的交通信号灯信息中的至少一者的通行调度信息。
在一些实施例中，处理器还被配置为执行如下操作：向第一VRSU发送探测结果，所述探测结果包括由所述电子设备经由感知设备探测到的驾驶环境信息；和从第一VRSU接收驾驶辅助消息，其中，该驾驶辅助消息包括第一VRSU标识符，该驾驶辅助消息包括基于其它电子设备发送的探测结果和第一VRSU的探测结果中的至少一者的驾驶辅助信息。
在一些实施例中，处理器还被配置为执行如下操作：向第一VRSU发送包括第一VRSU标识符的消息。
在一些实施例中，第一VRSU经由与第一VRSU相关联的RSU与车辆网云控平台 之间的接口上的V2X.RSU.INFO.UP消息和V2X.RSU.RunningInfo.UP消息分别上报业务数据和运行信息。
根据本公开另一个方面，提供一种基于空中平台的路侧系统(RSS)，包括：空中路侧基础设施承载平台(APRSI)，包括空中承载设施和承载于空中承载设施上的路侧基础设施，所述APRSI被配置为将路侧基础设施的物理资源虚拟化；和虚拟基础设施管理单元(VIMU)，配置为为RSS的覆盖范围内的至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI，每个VRSI至少包括一虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分。
在一些实施例中，每个VRSI还包括一虚拟路侧计算控制单元(VRSCCU)，VRSCCU包括被虚拟化的路侧计算控制单元的硬件资源和软件资源的至少一部分。
在一些实施例中，每个VRSI包括VRSU、虚拟路侧计算控制单元(VRSCCU)、交通控制设备和路侧传感设备，其中VRSCCU用于提供交通控制设备和路侧传感设备的接入。
在一些实施例中，所述空中承载设施包括系留气球及其配套设施。
在一些实施例中，路侧基础设施包括路侧单元、路侧计算控制单元、交通控制设备和路侧传感设备中的一个或多个。
在一些实施例中，所述VIMU还被配置为：至少基于与RSS的位置有关的地图信息确定RSS的覆盖范围内需要部署VRSI的所述至少一个子区域。
在一些实施例中，所述VIMU还被配置为：经由VIMU与车联网云控平台之间的接口上的第一接口消息向车联网云控平台上报第一系统基本信息，第一系统基本信息包括RSS的位置信息、运行形态和运行模式，其中运行形态指示RSS是否为虚拟态；和经由VIMU与车联网云控平台之间的接口上的第二接口消息从车联网云控平台接收地图信息，地图信息是至少基于RSS的位置信息确定的。
在一些实施例中，所述VIMU还被配置为：基于所述至少一个子区域中的每个子区域的资源需求特征，为该子区域确定虚拟路侧基础设施资源切片类型。
在一些实施例中，所述VIMU还被配置为：经由VIMU与车联网云控平台之间的接口上的第三接口消息上报第二系统基本信息，第二系统基本信息包括VRSI标识符以 及与VRSI标识符相关联的虚拟路侧基础设施资源切片类型和VRSU标识符。
在一些实施例中，所述VIMU还被配置为：基于所述至少一个子区域中每个子区域的应用场景分配用于该子区域的VRSI的资源。
在一些实施例中，所述VIMU还被配置为：经由VIMU与车联网云控平台之间的接口上的第四接口消息从车联网云控平台接收所述至少一个子区域中的每个子区域的历史数据；和基于所述至少一个子区域中的每个子区域的历史数据分配用于该子区域的VRSI资源。
在一些实施例中，所述VIMU还被配置为：经由VIMU与车联网云控平台之间的接口上的第五接口消息上报第三系统基本信息，第三系统基本信息包括VRSI标识符、相关联的VRSU标识符、相关联的VRSCCU标识符、相关联的路侧传感设备标识符以及相关联的交通控制设备标识符，第三系统基本信息还包括VRSU资源配置和VRSCCU资源配置，VRSU资源配置和VRSCCU资源配置中的每一个包括以下中至少一者：虚拟CPU配置，虚拟内存配置，虚拟磁盘配置和虚拟网络配置。
在一些实施例中，VRSU被配置为经由与VRSU相关联的RSU与车联网云控平台之间的接口上的V2X.RSU.INFO.UP消息和V2X.RSU.RunningInfo.UP消息分别向车联网云控平台上报业务数据和运行信息。
在一些实施例中，VRSU被配置为向在其服务的子区域内的电子设备发送该VRSU的VRSU标识符。
在一些实施例中，VRSU被配置为：从在其服务的子区域内的电子设备接收有关装载所述电子设备的车辆的行驶信息；基于所接收的行驶信息并且基于在其服务的子区域内的其它电子设备发送的其它车辆的行驶信息、来自第一VRSI的路侧感知信息和目标路口的交通信号灯信息中的至少一者生成通行调度信息；和向所述电子设备发送包含该VRSU的VRSU标识符和所述通行调度信息的通行调度消息。
在一些实施例中，VRSU被配置为：从在其服务的子区域内的电子设备接收探测结果，所述探测结果包括由所述电子设备经由感知设备探测到的驾驶环境信息；基于所接收的探测结果并且基于在其服务的子区域内的其它电子设备发送的探测结果和该VRSU的探测结果中的至少一者生成驾驶辅助信息；和向所述电子设备发送包含该VRSU的VRSU标识符和所述驾驶辅助信息的驾驶辅助消息。
在一些实施例中，VRSU被配置为：从其服务的子区域内的电子设备接收包括该VRSU的VRSU标识符的消息。
根据本公开的另一个方面，提供一种虚拟基础设施管理单元(VIMU)，包括：存储器，存储计算机可执行指令；和处理器，其与存储器耦接，被配置为执行所述计算机可执行指令来执行如下操作：为基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的每个子区域分配RSS的虚拟化的路侧基础设施的物理资源的至少一部分来为该子区域部署一虚拟路侧基础设施(VRSI)，每个VRSI至少包括虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分。
根据本公开的另一个方面，提供一种由电子设备执行的方法，包括：在处于基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的第一子区域内时，从服务于第一子区域的第一虚拟路侧基础设施(VRSI)中的第一虚拟路侧单元(VRSU)接收第一VRSU标识符。
根据本公开的另一个方面，提供一种由基于空中平台的路侧系统(RSS)执行的方法，包括：由包括空中承载平台和承载于空中承载平台上的路侧基础设施的空中路侧基础设施承载平台(APRSI)将路侧基础设施的物理资源虚拟化；和由虚拟基础设施管理单元(VIMU)为RSS的覆盖范围内的至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI，每个VRSI至少包括一虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分。
根据本公开的另一个方面，提供一种由虚拟基础设施管理单元(VIMU)执行的方法，包括：为基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的每个子区域分配RSS的虚拟化的路侧基础设施的物理资源的至少一部分来为该子区域部署一虚拟路侧基础设施(VRSI)，每个VRSI至少包括虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分。
根据本公开的另一个方面，提供一种计算机存储介质，存储计算机可执行指令，所述计算机可执行指令在被处理器执行时执行如上所述的方法。
根据本公开的另一个方面，提供一种计算机程序产品，包括计算机可执行指令， 所述计算机可执行指令在被处理器执行时执行如上所述的方法。
附图说明
本公开可以通过参考下文中结合附图所给出的详细描述而得到更好的理解，其中在所有附图中使用了相同或相似的附图标记来表示相同或者相似的要素。所有附图连同下面的详细说明一起包含在本说明书中并形成说明书的一部分，用来进一步举例说明本公开的实施例和解释本公开的原理和优点。其中：
图1是示出根据本公开实施例的基于空中平台的路侧系统的示例性概览图。
图2A是示出根据本公开实施例的基于空中平台的路侧系统的示意性部署图。
图2B和图2C示出根据本公开实施例的基于虚拟RSU来提供虚拟基础设施服务的示意图。
图3示出根据本公开实施例的基于空中平台的路侧系统的示意性系统架构图。
图4示出根据本公开实施例的基于空中平台的路侧系统的示例性消息机制。
图5示出根据本公开实施例的虚拟资源切片部署架构图。
图6示出根据本公开实施例的路侧系统的资源分配方法的示例性流程图。
图7示出根据本公开实施例的路侧子系统所辅助的岔路口通行场景。
图8示出根据本公开实施例的电子设备所执行的方法的示例性流程图。
图9示出根据本公开实施例的路侧子系统所辅助的感知数据共享场景。
图10示出根据本公开实施例的电子设备所执行的方法的示例性流程图。
图11示出根据本公开实施例的基于空中平台的路侧系统(RSS)执行的方法的示例性流程图。
图12示出根据本公开实施例的VIMU执行的方法的示例性流程图。
图13是示出可以应用本公开内容的技术的RSU的示意性配置的第一示例的框图。
图14是示出可以应用本公开内容的技术的RSU的示意性配置的第二示例的框图。
图15是示出可以应用本公开内容的技术的智能电话的示意性配置的示例的框图。
图16是示出可以应用本公开内容的技术的汽车导航设备的示意性配置的示例的框图。
通过参照附图阅读以下详细描述，本公开的特征和方面将得到清楚的理解。
具体实施方式
在下文中将参照附图来详细描述本公开的各种示例性实施例。为了清楚和简明起见，在本说明书中并未描述实施例的所有实现方式。然而应注意，在实现本公开的实施例时可以根据特定需求做出很多特定于实现方式的设置，以便实现开发人员的具体目标。此外，还应该了解，虽然开发工作有可能是较复杂和费事的，但对得益于本公开内容的本领域技术人员来说，这种开发公开仅仅是例行的任务。
此外，还应注意，为了避免因不必要的细节而模糊了本公开，在附图中仅仅示出了与本公开的技术方案密切相关的处理步骤和/或设备结构。以下对于示例性实施例的描述仅仅是说明性的，不意在作为对本公开及其应用的任何限制。
本说明书包括对“一个实施方案”或“实施方案”的参考。出现短语“在一个实施方案中”或“在实施方案中”并不一定是指同一个实施方案。特定特征、结构或特性可以与本公开一致的任何适当的方式被组合。
术语“包括”是开放式的。如在所附权利要求书中所使用的，该术语不排除附加结构或步骤。考虑描述如下的权利要求：“一种装置，所述装置包括一个或多个处理器单元...”此类权利要求不排除该装置包括附加部件(例如，网络接口单元、图形电路等)。
各种单元、电路或其他部件可被描述为或叙述为“被配置为”执行一项或多项任务。在此类上下文中，“被配置为”用于通过指示单元/电路/部件包括在操作期间执行这一项或多项任务的结构(例如，电路)来暗指该结构。如此，单元/电路/部件可被配置为即使在指定的单元/电路/部件当前不可操作(例如，未接通)时也执行该任务。与“被配置为”语言一起使用的单元/电路/部件包括硬件-例如电路、存储可执行以实现操作的程序指令的存储器等。此外，“被配置为”可包括由软件和/或固件(例如，FPGA或执行软件的通用处理器)操纵的通用结构(例如，通用电路)以能够执行待解决的一项或多项任务的方式操作。“被配置为”还可包括调整制造过程(例如，半导体制作设施)，以制造适用于实现或执行一项或多项任务的设备(例如，集成电路)。
在本文中，“第一”“第二”等术语充当它们所在之前的名词的标签，并且不暗指任何类型的排序(例如，空间的、时间的、逻辑的等)。
术语“基于”用于描述影响确定的一个或多个因素。该术语不排除可能影响确定的附加因素。即，确定可仅基于这些因素或至少部分地基于这些因素。考虑短语“基于B来确定A”。在这种情况下，B为影响确定A的因素，该短语不排除也可基于C来确定 A。在其他情况下，可仅基于B来确定A。
本公开实施例考虑布置基于空中平台的路侧系统，将路侧基础设施(例如路侧单元、路侧计算控制单元、路侧交通控制设备和路侧传感设备等)承载于诸如系留气球之类的空中承载设备上，提供了一种低成本、易部署、覆盖范围较大且不易受地面环境变化影响的空中路侧系统。
本公开实施例还考虑将基于空中平台的路侧系统的路侧基础设施的物理资源(包括硬件资源、软件资源等)进行虚拟化，并将虚拟化的物理资源按需分配。例如，RSU的物理资源(包括硬件资源和软件资源等)可以被虚拟化并划分为一个或多个虚拟RSU，RSCCU的物理资源(包括硬件资源和软件资源等)可以被虚拟化并划分为一个或多个虚拟RSCCU。这可以提供更为灵活和高效的资源配置，提高资源利用率。
更具体地，本公开实施例考虑确定在基于空中平台的路侧系统的覆盖范围内需要部署虚拟路侧基础设施的子区域，为每个确定的子区域部署一虚拟路侧基础设施。通过根据每个子区域的应用场景、历史数据等为每个确定的子区域分配虚拟化的资源的至少一部分来为该子区域部署虚拟路侧基础设施。即为一子区域部署的虚拟路侧基础设施包括为该子区域分配的虚拟化的资源的至少一部分。每个虚拟路侧基础设施可以包括一虚拟RSU。每个虚拟路侧基础设施还可以包括一虚拟RSCCU和相关联的路侧交通控制设备和路侧传感设备。这意味着同一个RSU或RSCCU的资源可以用于多个子区域的相应多个虚拟路侧基础设施，从而提供灵活的资源配置和高效的资源利用。
本公开实施例还提出了虚拟路侧基础设施资源切片的概念，即，将虚拟化的资源以不同类型的虚拟路侧基础设施资源切片提供。例如，针对子区域的资源需求特征(例如，时延要求、带宽要求、计算能力要求、存储能力要求等)，可以为其选择适当的虚拟路侧基础设施资源切片类型。这可以提供更为精细的资源配置，提高整体资源利用率。
本公开实施例还提出了至少根据路侧系统的位置为路侧系统提供地图信息，基于地图信息来确定需要部署虚拟路侧基础设施的子区域。地图信息例如包含道路岔路口信息，可以基于需要部署虚拟路侧基础设施的岔路口来确定需要部署虚拟路侧基础设施的子区域。这可以提供更为精细的资源配置，提高整体资源利用率。这在资源受限的情况下尤其重要。
本公开实施例还提出了虚拟基础设施管理单元，该单元用于执行上述子区域的确定、虚拟化的资源的管理和分配等。本公开实施例还提出了在虚拟基础设施管理单元和车联网云控平台之间新增通信接口和相应的消息集，在虚拟路侧单元和车联网云控平台之间扩展相应路侧单元与车联网云控平台之间现有的通信接口和消息集。
本公开实施例还考虑了由虚拟路侧单元向车载单元发送虚拟路侧单元的标识符。虚拟路侧单元和车载单元之间利用该虚拟路侧单元的标识符执行通信，来实现例如路侧系统辅助的岔路口通行，路侧系统辅助的感知数据共享、路侧系统辅助的车辆支付服务等。
图1是示出根据本公开实施例的基于空中平台的路侧系统的示例性概览图。
如图1所示，示出两个基于空中平台的路侧系统101和102，其中，路侧系统101布置在城市道路或者高速公路上空，路侧系统102布置在扇区、森林、荒漠等野外道路上空。
在图1中，每个路侧系统使用系留气球作为空中承载设备，来形成其空中承载平台。
系留气球可以包括球体、电源分系统、压力调节分系统、测控分系统、通信分系统、防雷分系统和地面系留分系统等。
本领域技术人员可以理解，可以使用各种能够实现空中悬浮的设施作为空中承载设备，包括但不限于：飞艇、中高空气球、低空/超低空系留气球、无人机等。
空中承载设备可以承载该路侧系统的路侧基础设施。路侧基础设施可以包括路侧单元，路侧计算控制单元、路侧传感设备和交通控制设备等。路侧传感设备可以包括但不限于摄像机(例如激光摄像机)、传感器、雷达(例如激光雷达、毫米波雷达)。交通控制设备可以包括但不限于交通信号灯和交通警示牌。
如图1所示，每个路侧系统可以经由卫星中继链路与地面的车联网远程云控平台通信。路侧系统可以使用C-V2X接口与地面的车联网远程云控平台通信，并且可以使用C-V2X接口与地面的车辆(例如，车载单元)通信。
以使用系留气球作为空中承载设备为例，针对不同的场景需求，可以使用不同的系留气球。
表1示出示例性的系留气球分类。
表1：系留气球分类表
不同类型的系留气球可以挂载不同覆盖范围的设备。表2示出示例性的挂载设备覆盖范围分类表。
表2：挂载设备覆盖范围分类表
根据表1和表2，针对不同应用场景的需求，可以选择不同类型的系留气球并挂载不同的设备。
例如，针对覆盖半径500米以内的单个岔路口，可以使用超低空(高度<50米)微型系留气球挂载普通RSU、诸如空中信号灯之类的路侧交通控制设备、诸如激光雷达之类的路侧传感设备等，从而为车辆提供精细化的路侧基础设施服务。
针对覆盖半径2公里以内的城市街区，可以使用低空(高度<500米)小型系留气球挂载增强型空中RSU、诸如云台激光摄像机之类的路侧传感设备，同时支持覆盖3～4个岔路口，以降低部署和使用成本。
针对覆盖半径2公里以上的郊区、山区、荒漠等临时应急服务场景，可以使用中 低空(高度<3000米)中大型系留气球挂载增强型RSU、诸如超远距云台激光摄像机之类的路侧设备，支持覆盖数10个岔路口，进一步降低部署和使用成本。
在一些实施例中，可以采用以上不同高度组合的挂载方案，例如，在低空使用小型系留气球来挂载增强型RSU和诸如云台激光摄像机之类的路侧传感设备，同时在部分岔路口使用微型系留气球挂载空中信号灯、空中激光雷达等，以提供增强的路侧基础设施服务。
换言之，一个路侧系统的空中承载平台可以包括一个或多个空中承载设备。这些空中承载设备可以是不同类型的空中承载设备。这些空中承载设备可以分散在不同的位置并分别挂载不同的设备。这些空中承载设备可以支持彼此之间的无线通信。空中承载设备可以提供用于与挂载在其上的设备耦接和通信的接口。
将路侧基础设施布置在空中可以使得路侧系统有更大的覆盖范围并且不易受地面通信环境的影响。此外，相比于通过在地面搭设高架等来布置地面路侧系统的方式相比，基于空中平台的路侧系统成本低、易于部署、并且更加灵活。
图2A是示出根据本公开实施例的基于空中平台的路侧系统2000的示意性部署图。
路侧系统2000设置在一定的地理位置，并提供一定的覆盖范围。在该覆盖范围下，可能存在多个需要集中提供路侧基础设施服务的子区域，例如图2A中所示的十字路口所处的子区域2001和弯道盲区所处的子区域2003。
针对每个子区域可以部署一个虚拟路侧基础设施(VRSI)。如图2A所示，为子区域2001部署了VRSI 2005，并且为子区域2003部署了VRSI 2007。VRSI可以包含路侧系统2000的被分配用于相应子区域的物理资源，包括硬件资源和软件资源等。
根据本公开的实施例，可以将路侧系统2000的物理资源进行虚拟化，并为需要部署VRSI的各个子区域分配虚拟化的物理资源的至少一部分，从而为每个子区域部署相应的VRSI。例如，可以将RSU的物理资源(包括硬件资源和软件资源)划分为多个虚拟RSU，并将多个虚拟RSU分配给不同的子区域。
每个虚拟路侧基础设施可以至少包括一个虚拟RSU。每个虚拟RSU可以包括被虚拟化的相应路侧单元(RSU)的物理资源(包括硬件资源和软件资源)的至少一部分。与一虚拟RSU相关联的资源配置例如包括虚拟CPU配置、虚拟内存配置、虚拟磁盘配置、虚拟网络配置等。
图2B和图2C示出根据本公开实施例的基于虚拟RSU来提供虚拟基础设施服务的示意图。图2B示出在城市上空部署的一个基于空中平台的路侧系统，其包括四个虚拟RSU来针对其覆盖范围的不同区域提供路侧基础设施服务。图2C示出在森林上空部署的一个基于空中平台的路侧系统，其包括三个虚拟RSU来针对其覆盖范围的不同区域提供路侧基础设施服务。
类似地，可以将RSCCU的物理资源(包括硬件资源和软件资源)虚拟化并划分为多个虚拟RSCCU，并将多个虚拟RSCCU分配给不同的子区域。
每个虚拟路侧基础设施还可以包括一个虚拟RSCCU以及相关联的路侧传感设备和/或路侧交通控制设备。每个VRSCCU可以包括被虚拟化的相应路侧计算控制单元的物理资源的至少一部分。虚拟RSCCU用于提供相关联的路侧传感设备和/或路侧交通控制设备的接入。
每个虚拟路侧基础设施还可以包括相应的空中承载设备。
在图2A中，路侧系统2000包括4个空中承载设备201-204，其中，空中承载设备201是例如低空小型系留气球，空中承载设备202-204例如是超低空微型系留气球。
空中承载设备201可以挂载RSU(未示出)、RSCCU(未示出)和两个云台激光摄像机E和F。空中承载设备202可以挂载交通信号灯A。空中承载设备203可以挂载激光雷达B。空中承载设备204可以挂载激光雷达C。
RSU可以被虚拟化并分别为VRSI 2005和VRSI 2007提供两个不同的虚拟RSU(具有不同的虚拟RSU标识符)。RSCCU可以被虚拟化并分别为VRSI 2005和VRSI 2007提供两个不同的虚拟RSCCU(具有不同的虚拟RSCCU标识符)。
相应地，VRSI 2005可以包括一个虚拟RSU、一个RSCCU、空中承载设备202和203、交通信号灯A、激光雷达B和云台激光摄像机E。VRSI 2007可以包括一个虚拟RSU、一个RSCCU、空中承载设备204、激光雷达C和云台激光摄像机F。
在一些实施例中，需要部署VRSI的子区域的确定可以基于与路侧系统的部署位置有关的地图信息(如图2A中的“道路地图”所示)。
在一些实施例中，可以根据与路侧系统的部署位置有关的地图信息来人工指定需要部署VRSI的子区域。换言之，可以人工为确定的子区域分配VRSI，这例如可以包括分配VRSI标识符等。
在另一些实施例中，可以由路侧系统2000根据与路侧系统的部署位置有关的地图 信息来自动确定需要部署VRSI的子区域。路侧系统可以为确定的子区域分配VRSI标识符和相应的资源。
地图信息可以来自车辆网云控平台，也可以来自路侧系统2000预先存储的地图。
路侧系统的部署位置可以来自用户输入。路侧系统的部署位置可以由路侧系统自身包含的定位设备确定。
通过基于与路侧系统的部署位置相关联的地图信息确定需要部署VRSI的子区域，并将路侧系统的物理资源按照需要进行虚拟化分配，可以提供精准适配需求的灵活的路侧基础设施服务，并且可以提高资源利用率。
图3示出根据本公开实施例的基于空中平台的路侧系统2000的示意性系统架构图。
如图3所示，路侧系统可以包括各种路侧基础设施，包括空中承载设备和承载于空中承载设备的路侧单元(RSU)、计算控制单元、交通控制设备和路侧传感设备。
如图3所示，通过将路侧系统2000的物理资源(包括硬件资源和软件资源等)进行虚拟化，形成虚拟基础设施资源。如图所示，虚拟基础设施资源可以包括两个虚拟RSU(即虚拟RSU 1和虚拟RSU 2)，三个虚拟计算控制单元(即虚拟计算控制单元1-3)，两个交通信号灯(即交通信号灯A和M)，两个云台激光摄像机(即云台激光摄像机E和F)和两个激光雷达(即激光雷达B和C)。虚拟基础设施资源还可以包括未示出的空中承载设备(例如系留气球)的物理资源。
在本申请中，物理资源既包括硬件设备，也包括软件配置，还包括硬件设备和软件配置所支持的物理能力(诸如带宽、计算能力、频段等)等等。
如图3所示，路侧系统2000还可以包括虚拟基础设施管理单元(VIMU)。VIMU被配置为提供虚拟资源的管理分配、故障处理等功能，负责对虚拟基础设施(VRSI)、虚拟路侧单元(VRSU)、虚拟计算控制单元(VRSCCU)进行生命周期管理(诸如实例化、配置、关闭等)。
VIMU被配置为为路侧系统的覆盖范围内的要部署VRSI的每个子区域分配RSS的虚拟化的路侧基础设施的物理资源的至少一部分，从而为该子区域部署相应的虚拟路侧基础设施(VRSI)。
如图3所示，VIMU可以为图2A所示的子区域2001和子区域2003分别部署虚拟路侧基础设施2005和2007。
虚拟路侧基础设施2005包括一个虚拟RSU(即虚拟RSU 1)、1个虚拟计算控制单元(即虚拟计算控制单元1)、1个云台激光摄像机(图2A中所示的云台激光摄像机E)、1个激光雷达(图2A中所示的激光雷达B)、1个交通信号灯(图2A中所示的交通信号灯A)、两个超低空系留气球(图2A中所示的空中承载设备202和203)。
虚拟路侧基础设施2007可以包括1个虚拟RSU(即虚拟RSU 2)、1个虚拟计算控制单元(即虚拟计算控制单元2)、1个云台激光摄像机(图2A中所示的云台激光摄像机F)、1个激光雷达(图2A中所示的激光雷达C)和1个超低空系留气球(图2A中所示的空中承载设备204)。
图3中虚拟基础设施资源中的虚拟计算控制单元3和交通信号灯M可以被分配给其它的VRSI。
虚拟基础设施管理单元可以接收地图信息，并识别需要提供服务的子区域，例如如图2A所示的包含十字路口的子区域2001或包含弯道盲区的子区域2003。在一些实施例中，虚拟基础设施管理单元也可以直接接收对子区域的指定信息，例如子区域的位置信息和子区域的地理特征。
虚拟基础设施管理单元可以接收与子区域相关联的资源需求特征相关的信息，诸如由应用场景等决定的时延、带宽、计算、存储、定位精度、可靠性要求等。虚拟基础设施管理单元可以基于每个子区域的资源需求特征来为该子区域选择适当的虚拟资源切片类型，并分配适当的资源。
在一些实施例中，虚拟基础设施管理单元可以实现为软件程序。在另一些实施例中，虚拟基础设施管理单元可以实现为单独的硬件设备，其可以与各种路侧基础设施有线/无线耦接和通信。在又一些实施例中，虚拟基础设施管理单元也可以集成到空中承载设备、RSU、RSCCU或其它设备中。
如图3所示，路侧系统可以经由C-V2X Uu接口与中继卫星通信，中继卫星经由C-V2X Uu接口与车联网云控平台通信。路侧系统可以经由C-V2X PC5接口与车载单元通信。车载单元可以经由C-V2X Uu接口与车联网云控平台通信。
如图3所示，路侧系统2000还可以包括用于与中继卫星通信的卫星通讯单元。在一些实施例中，卫星通讯单元可以集成到空中承载设备。
通过将路侧系统2000的物理资源进行虚拟化分配，可以针对不同子区域的不同资源需求，部署不同的VRSI，这可以提供更精准的路侧基础设施服务，并且提高路侧基 础设施部署的灵活性以及提高整个路侧系统的资源利用率。
图4示出根据本公开实施例的基于空中平台的路侧系统2000的示例性消息机制。
如图4所示，路侧系统2000包括虚拟基础设施管理单元(VIMU)，其被配置为提供虚拟资源的管理分配、故障处理等功能，负责对VRSU、VRSCCU、VRSI进行生命周期管理(实例化、配置、关闭等)。
路侧系统2000还包括虚拟路侧基础设施VRSI 2005和VRSI 2007。VRSI2005包括一组虚拟RSU(即VRSU 1)、虚拟RSCCU(即VRSCCU 1)、交通控制设备(即交通信号灯A)和路侧传感设备(即云台激光摄像机E和激光雷达B)。VRSI2007包括一组虚拟RSU(即VRSU 2)、虚拟RSCCU(即VRSCCU 2)和路侧传感设备(即激光雷达C)。
路侧系统2000还包括空中路侧基础设施承载平台(Air Platform for Road Side Infrastructure，APRSI)，其被配置为提供VRSU、VRSCCU的运行环境，包括所需的硬件及软件，并且被配置为将路侧系统2000的路侧基础设施的物理资源虚拟化为虚拟资源，供VRSU、VRSCCU使用。
空中承载平台可以提供承载功能，例如包括系留气球来提供设备悬浮。空中承载平台可以提供通信功能和/或接口功能，例如包括各种通信部件(例如卫星通信、Wifi通信)，包括电源接口、通信接口等来与路侧基础设施耦接。空中承载平台还可以提供虚拟化功能，将该平台所承载的路侧基础设施的物理资源(包括硬件资源和软件资源等)进行虚拟化，如下图5中的硬件资源、OS Linux和虚拟化层这三部分示出的。
图5示出根据本公开实施例的虚拟资源切片部署架构图。
图5示出路侧系统2000可以包括硬件资源，诸如CPU、GPU、内存、存储设备、网络设备等，以及用于支持卫星定位、实时差分(Real time kinematic，RTK)定位、LET/5G通信、WiFi通信、C-2VX通信等的设备。路侧系统还包括OS操作系统和虚拟化层。虚拟化层将路侧系统的物理资源进行虚拟化。
如图5所示，虚拟化的资源可以以各种类型的资源切片进行部署。表3示出根据本公开实施例的示例性资源切片分类表。
如表3所示，均衡型切片表示时延/带宽/计算/存储等能力均衡，带宽在10～100Mbps之间，处理时延在20～100ms，支持图像处理级计算能力，TB级存储或支 持内存数据库，定位精度达到米级，可靠性达到99％；低时延型切片支持时延降低到20ms以下；大带宽型切片支持带宽达到100Mbps以上；智能计算型切片支持智能决策、视频编解码、大数据分析类计算能力；大存储型切片支持EB级或支持海量非结构性数据库；高定位精度型切片支持亚米级定位精度；高可靠性型切片支持可靠性达到99.99％。
表3：资源切片分类表
VIMU可以根据不同场景的资源需求特征为VRSI选择合适的资源切片类型，部署虚拟RSU、虚拟RSCCU、相应的传感设备和交通控制设备。
如图5所示，例如针对十字路口场景(例如图2A中的子区域2001所示)可以选择均衡型资源切片。该切片例如可以用于部署：1个虚拟RSU，其包括C-V2X十字路口车辆引导算法应用程序和C-V2X相关协议栈；以及1个虚拟RSCCU，其用于传感设备接入和交通控制设备接入，例如图2中所示的云台激光摄像机设备E的接入、激光 雷达设备B的接入、交通信号灯A的接入。该切片可以支持车辆有序通过十字路口。
通过以不同类型的资源切片来提供虚拟化的物理资源，可以针对不同子区域的资源需求特征(例如不同的时延、带宽、计算、存储、定位精度、可靠性需求等)，选择适当类型的资源切片。这可以提供灵活的资源部署方式，提高整体资源的利用率。
回到图4，虚拟基础设施管理单元可以经由RSS-VIUM和车辆网云控平台的中心子系统之间的新增接口通信，例如上行从VIUM向中心子系统发送V2X.VIMU.INFO.UP接口消息，下行从中心子系统向VIMU发送V2X.VIMU.INTERSECTION.DOWN接口消息。V2X.VIMU.INFO.UP接口消息和V2X.VIMU.INTERSECTION.DOWN接口消息都是新增的消息。
如图4所示，各个虚拟路侧单元可以经由中心子系统与RSS-RSU(与虚拟路侧单元相应的路侧单元)间的接口通信，例如上行从VRSU向中心子系统发送V2X.RSU.INFO.UP，下行从中心子系统向VRSU发送V2X.RSU.RunningInfo.UP接口消息。这是对现有的中心子系统与RSS-RSU间的接口以及该接口上传输的消息的扩展。
如图4所示，VRSU可以经由现有的C-V2X PC5接口与车载单元通信。车载单元可以经由C-V2X Uu接口与中心子系统通信。
图6示出根据本公开实施例的路侧系统的资源分配方法6000的示例性流程图。
如图6所示，方法6000包括步骤6001，在该步骤，路侧系统向车联网云控平台中心子系统上报路侧系统的位置信息(例如，该路侧系统部署到的位置的经纬度)等。
具体地，可以由VIMU经由RSS-VIMU与车辆网云控平台中心子系统之间的新增接口上的V2X.VIMU.INFO.UP消息上报路侧系统信息表。
表4示出根据本公开实施例的示例性路侧系统基本信息表。如表4所示，该基本信息表可以包括时间戳、系统标识符即RSS标识符、RSS位置(例如经纬度)、运行形态(指示该路侧系统是否处于资源虚拟化的形态)以及运行模式(正常模式、灾备模式，还是临时应急模式)。
表4：路侧系统基本信息表
中心子系统在接收到RSS基本信息表之后，可以根据不同的运行模式选取合适覆盖范围内的道路地图信息下发。针对不同的运行模式，下发的地图信息可以覆盖不同的半径和不同数量的岔路口。下表5示出运行模式与地图覆盖半径和岔路口数量之间的示例性对应关系。
表5：运行模式与地图信息对应关系
步骤6001还包括获取地图信息。
具体地，VIMU可以经由RSS-VIMU与车辆网云控平台中心子系统之间的新增接口上的V2X.VIMU.INTERSECTION.DOWN消息接收包含地图信息的区域道路信息表。
地图信息可以基于RSS上报的位置信息(例如经纬度)。例如地图信息是以RSS的位置为中心的一定覆盖面积内的所有地图切片的信息。
地图信息还可以基于RSS上报的运行模式。例如，针对不同的运行模式，地图信息是以RSS的位置为中心的不同覆盖面积内的所有地图切片的信息。
表6示出根据本公开实施例的示例性区域道路信息表。如表6所示，区域道路信息表可以包含岔路口信息列表DF_IntersectionList。
区域道路信息表可以包含时间戳、RSS标识符、岔路口数量和岔路口信息列表。
岔路口信息列表DF_IntersectionList中可以列出每个岔路口的岔路口标识符、位 置信息(例如经纬度)、岔路口类型(十字路口、三岔路口、急拐弯路口等)以及该岔路口所属的地图切片的标识符。
表6：区域道路信息表
DF_IntersectionList
本领域技术人员可以理解，以上仅仅是RSS系统基本信息和地图信息的一些示例，本领域技术人员可以根据需要设想更多、更少或不同的信息。
如图6所示，方法6000还可以包括步骤6002，在该步骤，VIMU确定要部署虚拟路侧基础设施(VRSI)的子区域，为确定的每个子区域部署一VRSI，并上报与确定的子区域的VRSI有关的信息。
VIMU可以根据与RSS的位置相关联的地图信息来确定需要部署虚拟路侧基础设施的子区域。例如，将接收的地图信息中的全部岔路口都设置为要部署相应VRSI的单独子区域。
VIMU还可以根据应用场景来确定需要部署虚拟路侧基础设施的子区域。
例如，对于协作式岔路口通行的应用场景时，对于地图信息中所指示的某些岔路口可以不必部署VRSI。
例如，对于基于路侧感知的自主泊车这样的应用场景，仅将可以泊车的停车场等确定为子区域，而不考虑十字路口之类的岔路口。
应用场景不限于本公开例示的十字路口和弯道盲区。应用场景例如还可以包括但不限于：基于路侧感知的自主泊车、协作式匝道汇入、协作式岔路口通行、差分数据服务、动态车道管理、场站路径引导服务、浮动车数据采集、慢行交通预警、车辆编 队管理、道路收费服务等等。VIMU可以基于确定的子区域的数量来确定要部署的VRSI的数量。
VIMU还可以为每个VRSI分配VRSI标识符、VRSU标识符和指定VRSU的位置。VRSU的位置可以是与VRSU对应的岔路口的经纬度坐标。
VIMU可以针对每个子区域的资源需求特征，来为该子区域的VRSI选择适当的虚拟路测基础设施资源切片类型。资源需求特征例如包括但不限于时延要求、带宽要求、计算能力要求和存储能力要求等。虚拟路测基础设施资源切片类型例如选自表3。
资源需求特征可以与应用场景相关联。不同的C-V2X应用场景从时延、带宽、计算、存储、定位精度、可靠性等方面对路侧基础设施提出了不同要求。例如，自动驾驶和传感器共享场景对时延的要求最低达到了3ms；传感器共享场景对带宽的要求最高达到了1Gbps；全局路况分析场景对计算能力提出了更高要求，要能快速对视频、雷达信号等感知内容进行精准分析和处理。
例如，针对图2A中所示的十字路口场景的VRSI 2005可以选择如表3所示的均衡型资源切片。
VIUM可以经由VIUM与车辆网云控平台中心子系统之间的新增接口上的V2X.VIMU.INFO.UP消息来上报包含与所确定的子区域的VRSI有关的信息的路侧系统基本信息表。
表7示出根据本公开实施例的示例性路侧系统基本信息表。如表7所示，该基本信息表包括时间戳、RSS标识符、RSS位置、要部署的VRSI的数量和VRSI信息列表DF_VrsiList。
DF_VrsiList针对每个VRSI，列出了VRSI标识符、VRSI切片类型、相关联的岔路口标识符、所分配的VRSU标识符以及VRSU的部署位置。
表7：路侧系统基本信息表
DF_VrsiList
方法6000还可以包括步骤6003，在该步骤，VIMU接收与子区域有关的历史数据。
具体地，VIMU可以经由VIMU与车联网云控平台中心子系统之间的新增接口上的V2X.VIMU.INTERSECTION.DOWN消息从车联网云控平台中心子系统接收包含与所确定的子区域相关联的历史数据的区域道路信息表。
历史数据例如包括所确定的每个子区域的历史道路交通流量、历史事故发生频率等等。历史数据例如以区域道路信息表的形式发送给VIMU。
表8示出根据本公开实施例的包含示例性历史数据的示例性区域道路信息表。
该表可以包括时间戳、RSS标识符、岔路口的数量和岔路口历史信息列表。在岔路口历史信息列表DF_IntersectionHistoryList中，针对每个子区域的岔路口，列出岔路口标识符、岔路口交通流量(例如每月车流量)和岔路口事故频率(例如平均每月发生交通事故的次数)。
表8：区域道路信息表
DF_IntersectionHistoryList
方法6000还可以包括步骤6004，在该步骤，VIMU为各个VRSI分配虚拟化的物理资源并上报资源分配结果。
如上所述，RSS的路侧基础设施的物理资源被虚拟化并被分配。可以基于各个子区域的VRSI切片类型和/或历史数据向各个VRSI分配虚拟化的资源中的至少一部分。这可以包括为每个VRSI分配虚拟RSU，还可以包括为每个VRSI分配虚拟RSCCU以及相关联的交通控制设备和/或路侧传感设备。还可以包括为每个VRSI分配空中承载设备。
对于交通流量大、事故发生频率高的岔路口可以部署更多的VRSU资源和/或VRSCCU资源，以支持部署更多的路侧传感设备和/或交通控制设备。
VIMU可以经由VIMU与车联网云控平台中心子系统之间的新增接口上的V2X.VIMU.INFO.UP消息上报包含资源配置结果的路侧系统基本信息表。
表9示出根据本公开实施例的包含示例性资源配置结果的路侧系统基本信息表。
如表9所示，该基本信息表可以包括时间戳、RSS标识符、RSS位置、VRSI数量和VRSI信息列表。
VRSI信息列表DF_VrsiList针对每个VRSI，列出VRSI标识符、岔路口标识符、VRSU标识符、VRSU位置、VRSU资源配置、VRSCCU标识符、VRSCCU资源配置、传感器设备配置和交通控制设备配置。VRSU位置例如是与VRSU相应的岔路口的经纬度坐标。
RSU资源配置和VRSCCU资源配置针对每个VRSU和VRSCCU，配置相关联的虚拟CPU配置、虚拟内存配置、虚拟磁盘配置和虚拟网络配置。
路侧传感设备配置和交通控制设备配置(DF_DeviceConfigList)针对每个传感设 备和每个交通控制设备，列出了设备标识符、设备名称和设备地址。
表9：路侧系统基本信息表
DF_VrsiList
DF_VResConfigList
DF_DeviceConfigList
方法6000还可以包括步骤6005，在该步骤，VIMU启动各VRSI来提供空中路侧基础设施服务，VRSU上报业务数据和运行信息。
具体地，VIMU可以启动各个VRSI的VRSU和VRSCCU来提供空中路侧基础设施服务。
每个VRSU可以分别经由相应RSU与车联网云控平台中心子系统的接口上的扩展的V2X.RSU.INFO.UP消息和V2X.RSU.RunningInfo.UP消息来分别上报业务数据和运行信息。
每个VRSU可以按照预定周期进行定期的上报，也可以响应于预定事件触发上报。
表10示出根据本公开实施例的包括示例性业务数据的示例性RSU信息表。
表10：RSU信息表(包含RSU业务数据)
如表10所示，RSU业务数据可以包括RSU标识符、VRSU标识符、RSU的位置信息、配置数据、运行形态、运行模式等。
表11示出根据本公开实施例的包括示例性RSU运行信息的RSU运行信息表。
如表11所示，RSU运行信息表可以包括时间戳、RSU标识符、VRSU标识符和设备运行状态信息。设备运行状态信息包括虚拟CPU运行信息、虚拟内存运行信息、虚拟磁盘运行信息和虚拟网络运行信息。
表11：RSU运行信息表(RSU运维管理)
DF_RunningInfo
图6仅仅是根据本公开实施例的路侧系统的示例性资源分配方法。在不偏离本公开教导的情况下，可以构想到各种路侧系统的资源分配方法的变形例。
在一些实施例中，在RSS的设备抵达现场之后，通过RSS的定位模块确定自身的位置并将确定的位置连同RSS的运行形态和运行模式上报给中心子系统。RSS接收下发的地图信息，自动进行子区域的确定、VRSI的部署和虚拟资源的分配。
在另一些实施例中，可以在RSS的设备还没有抵达现场之前，例如由操作员经由VIMU预先指定要部署RSS的位置和要部署VRSI的子区域，并针对每个子区域指定要分配给VRSI的资源。然后软硬件资源被调配到现场来按照预先的规划提供服务。
在又一些实施例中，可以根据实际运行过程中可用资源的变化来重新执行资源分配。例如，当在RSS的运行过程中，某个VRSI的部分设备出现故障时，此时可以根据各个VRSI的资源需求特征和总的可用资源量，重新为各个VRSI调配适当的资源。
在有一些实施例中，可以根据实际运行过程中资源需求变化来重新执行资源分配。例如，当在RSS的运行过程中，某个VRSI的资源需求增大时，此时可以根据各个VRSI的资源需求特征和总的可用资源量，重新为各个VRSI调配适当的资源。例如为资源需求增大的VRSI分配更多的VRSU资源和/或VRSCCU资源，并为资源需求减小的VRSI减少分配的VRSU资源和/或VRSCCU资源。
在一些实施例中，可以不必搜集子区域的历史数据，即可以省略步骤6003。在另一些实施例中，云控平台可以在提供地图信息时一并提供相关联的历史数据。
根据本公开实施例的基于空中平台的路侧系统可以应用于各种场景。
图7示出根据本公开实施例的路侧子系统7000所辅助的岔路口通行场景。
当发生地震、大面积停电等灾害时，会导致交叉路口路侧基础设施全部瘫痪，进而造成交通混乱，根据本公开实施例的基于空中平台的路侧子系统可以用于辅助自动驾驶车辆安全有序地通过岔路口。
路侧子系统7000可以是例如图2A所示的路测系统2000中涉及子区域2001(即VRSI 2005)的部分。如图7所示，这部分包括：低空系留气球201，其承载空中RSU(更具体地，虚拟RSU 1)和摄像机E；在十字路口附近的两个超低空系留气球202和203，其中系留气球202承载空中交通信号灯，系留气球203承载空中激光雷达。
路侧子系统7000可以用于辅助自动驾驶车辆EV 1和EV 2安全有序地通过岔路口。
具体地，车辆EV1和EV2可以向空中RSU(更具体地，虚拟RSU 1)发送车辆行驶信息，空中RSU(更具体地，虚拟RSU 1)根据车辆行驶信息、目标交叉路口的空中交通信号灯信息、其他车辆上报的行驶信息、以及空中激光雷达的路侧感知信息，生成用于调度EV1和EV2通过该十字路口的通行调度信息，并将通行调度信息发送给EV1和EV2，调度EV1和EV2安全通过十字路口。
图8示出根据本公开实施例的电子设备所执行的方法的示例性流程图。电子设备例如是车载设备。电子设备也可以是能够与车辆耦接和通信的单独的设备。电子设备例如是图7中的车辆EV 1或EV 2的车载设备。
如图8所述，方法8000可以包括步骤8001，在该步骤，在处于基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的第一子区域内时，电子设备从服务于第一子区域的第一虚拟路侧基础设施(VRSI)中的第一虚拟路侧单元(VRSU)接收第一VRSU标识符。
第一VRSI例如是图2A中的VRSI 2005，第一VRSU标识符例如是为VRSI 2005分配的VRSU的标识符。
如以上参考图2A-6所述，VRSU标识符可以与标识相应VRSI的VRSI标识符以及为该VRSI选择的虚拟基础设施资源切片类型相关联。VRSU标识符还可以与标识相应虚拟路侧计算控制单元(VRSCCU)的VRSCCU标识符相关联。VRSI标识符、VRSU标识符、虚拟基础设施资源切片类型和VRSCCU标识符由VIMU为相应的子区域的VRSI分配。VRSU标识符和VRSCCU标识符具有相关联的资源配置，包括虚拟 CPU配置，虚拟内存配置，虚拟磁盘配置和虚拟网络配置中的至少一者。VRSI标识符、VRSU标识符、虚拟基础设施资源切片类型和VRSCCU标识符以及相关联的资源配置等由VIMU经由VIMU与车联网运控平台之间的新增接口上的新增消息(例如，V2X.VIMU.INFO.UP接口消息)上报给车联网运控平台。VRSI、虚拟基础设施资源切片类型、VRSU和VRSCCU的配置是由VIMU基于与路侧系统的部署位置相关联的地图信息、应用场景、资源需求特征、历史数据等因素中的一个或多个来配置的。
方法8000还可以包括步骤8003，在该步骤，电子设备向第一VRSU发送装载所述电子设备的车辆的行驶信息。行驶信息可以包括行驶速度、行驶方向、导航路线信息等。
方法8000还可以包括步骤8005，在该步骤，电子设备接收来自第一VRSU的通行调度消息，其中，该通行调度消息包括第一VRSU标识符，所述通行调度消息包括基于所述电子设备发送的行驶信息并且基于其它电子设备发送的其它车辆的行驶信息、来自第一VRSI的路侧感知信息、目标路口的交通信号灯信息中的至少一者的通行调度信息。来自第一VRSI的路侧感知信息例如是由第一VRSI的路侧传感设备获得的。
图9示出根据本公开实施例的路侧子系统9000所辅助的感知数据共享场景。
感知数据共享场景是指在野外救援、森林救灾、地质勘探、野外探险、野外车辆拉练赛等无路侧基础实施的区域，需要提供短时间(如，几天)的路侧基础设施服务。如，发生森林火灾时，为灭火车辆、物资运输车辆等启动一种基于空中灾备平台的临时道路基础设施服务。
路侧子系统9000可以是例如图2A所示的路测系统2000中涉及子区域2005(即VRSI 2007)的部分。如图9所示，这部分包括：低空系留气球201，其承载空中RSU(更具体地，虚拟RSU 2)和摄像机F；在弯道附近的超低空系留气球204，其承载空中激光雷达C。路侧子系统9000可以用于辅助自动驾驶车辆EV 1和EV 2的感知数据共享。
车辆EV1以及空中RSU可以通过自身搭载或联网的感知设备(空中云台摄像机、空中激光雷达等传感器)探测到周围其他交通参与者(包括但不限于车辆、行人、骑行者等目标物)或道路异常状况信息，如：道路交通事件(如交通事故等)、车辆异常行为(超速、驶离车道、逆行、非常规行驶和异常静止等)、道路障碍物(如落石、 遗撒物、枯枝等)及路面状况(如积水、结冰等)等信息。
空中RSU(更具体地，虚拟RSU 2)可以接收EV1感测的信息，将接收到的EV1感测到的信息和/或自身感测到的信息进行处理后获得驾驶辅助信息，将驾驶辅助信息发送给EV1附近的其它车辆，例如后续车辆EV2。基于接收的驾驶辅助信息，车辆EV2可提前感知到不在自身视野范围内的交通参与者或道路异常状况，辅助自身做出正确的驾驶决策。
图10示出根据本公开实施例的电子设备所执行的方法1000的示例性流程图。电子设备例如是车载设备。电子设备也可以是能够与车辆耦接和通信的单独的设备。电子设备可以是图9中的车辆EV 1或EV 2的车载设备。
方法1000可以包括步骤1001，在该步骤，在处于基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的第一子区域内时，电子设备从服务于第一子区域的第一虚拟路侧基础设施(VRSI)中的第一虚拟路侧单元(VRSU)接收第一VRSU标识符。
第一VRSI例如是图2A中的VRSI 2007，第一VRSU标识符例如是为VRSI 2007分配的VRSU的标识符。
方法1000可以包括步骤1003，在该步骤，电子设备向第一VRSU发送探测结果，所述探测结果包括由所述电子设备经由感知设备探测到的驾驶环境信息。
电子设备可以按照一定的时间周期执行探测和探测结果的上报。电子设备也可以在确定探测结果显示异常时才向第一VRSU发送探测结果。电子设备也可以响应于RSU(更具体地，虚拟RSU 2)的请求发送探测结果。
方法1000还可以包括步骤1005，在该步骤，电子设备从第一VRSU接收驾驶辅助消息，其中，该驾驶辅助消息包括第一VRSU标识符，该驾驶辅助消息包括基于其它电子设备发送的探测结果和第一VRSU的探测结果中的至少一者的驾驶辅助信息。
第一VRSU可以仅在必要的情况下(例如仅在第一VRSU判定出现影响车辆行驶的异常环境信息时)才发送驾驶辅助信息。第一VRSU可以仅在电子设备请求驾驶辅助信息时向请求的电子设备提供该信息。
本领域技术人员可以理解，在电子设备具有感知能力的情况下，可以执行步骤1003。在电子设备不具有感知能力的情况下，可以不执行步骤1003。
在一些情况下，电子设备本身具备与RSU(更具体地，虚拟RSU)通信的能力， 但是其周围的另一电子设备不具备与RSU通信的能力，而仅能与该电子设备通信。在这样的情况下，电子设备可以将从RSU接收的驾驶辅助信息或其自身的探测结果发送给该另一电子设备。
在一些实施例中，电子设备还可以向第一VRSU发送包含第一VRSU标识符的消息。
例如，在路侧系统辅助的车辆支付服务应用场景下，电子设备可以从第一VRSU接收支付请求消息(Action-Request)，该支付请求消息包括第一VRSU标识符。响应于此，电子设备可以向第一VRSU发送车辆支付消息，该车辆支付消息可以包括第一VRSU标识符。
在一些实施例中，车辆支付消息可以包括动作响应消息(Action-Response)，该动作响应消息可以定义车辆对第一VRSU发起的支付请求消息的响应消息，包括本车标识符、第一VRSU标识符、支付信息以及支付请求消息的操作状态等。
在一些实施例中，车辆支付消息可以包括车辆服务指示(Vehicle Service Indication，VSI)，车辆服务指示包括第一VRSU标识符。
图11示出根据本公开实施例的基于空中平台的路侧系统(RSS)执行的方法1100的示例性流程图。
如图11所示，方法1100包括操作1101，在该操作，由包括空中承载平台和承载于空中承载平台上的路侧基础设施的空中路侧基础设施承载平台(APRSI)将路侧基础设施的物理资源虚拟化。
方法1100还可以包括操作1103，在该操作，由虚拟基础设施管理单元(VIMU)为RSS的覆盖范围内的至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI，每个VRSI至少包括一虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的物理资源(包括硬件资源和软件资源)的至少一部分。
图12示出根据本公开实施例的VIMU执行的方法1200的示例性流程图。
如图12所示，方法1200包括步骤1201，在该步骤，为基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的每个子区域分配RSS的虚拟化的路侧基 础设施的物理资源的至少一部分来为该子区域部署一虚拟路侧基础设施(VRSI)，每个VRSI至少包括虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的物理资源(包括硬件资源和软件资源)的至少一部分。
【本公开的示例性实现】
根据本公开的实施例，可以想到各种实现本公开的概念的实现方式，包括但不限于：
1、一种电子设备，包括：
存储器，存储计算机可执行指令；和
处理器，其与存储器耦接，被配置为执行所述计算机可执行指令来执行如下操作：
在处于基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的第一子区域内时，从服务于第一子区域的第一虚拟路侧基础设施(VRSI)中的第一虚拟路侧单元(VRSU)接收第一VRSU标识符。
2、如项1所述的电子设备，其中，通过将RSS的路侧基础设施的物理资源进行虚拟化并为所述至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI，每个VRSI包括一VRSU，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分，每个VRSU具有相应的VRSU标识符，所述至少一个子区域包括第一子区域。
3、如项2所述的电子设备，其中，第一VRSU标识符与第一VRSI的第一VRSI标识符和第一虚拟路侧计算控制单元(VRSCCU)标识符相关联，
其中，第一VRSI包括第一VRSCCU，第一VRSCCU包括被虚拟化的路侧计算控制单元的硬件资源和软件资源的至少一部分，
其中，第一VRSU标识符、第一VRSI标识符和第一VRSCCU标识符是由所述RSS的虚拟基础设施管理单元(VIMU)分配的。
4、如项3所述的电子设备，其中：
由VIMU分配的与第一VRSU标识符相关联的资源配置或与第一VRSCCU标识符相关联的资源配置包括以下中至少一者：虚拟CPU配置，虚拟内存配置，虚拟磁盘配置和虚拟网络配置。
5、如项3所述的电子设备，其中，第一VRSI标识符、第一VRSU标识符和第一VRSCCU标识符由VIMU经由VIMU与车联网云控平台之间的接口上的第一接口消息上报给车联网云控平台。
6、如项2所述的电子设备，其中，所述至少一个子区域是由VIMU通过如下操作确定的：
至少基于与RSS的位置有关的地图信息确定RSS的覆盖范围内需要部署VRSI的所述至少一个子区域。
7、如项6所述的电子设备，其中，所述地图信息是由VIMU经由VIMU与车联网云控平台之间的接口上的第二接口消息从车联网云控平台接收的。
8、如项2所述的电子设备，其中，为所述至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI包括由VIMU执行的以下操作：
基于所述至少一个子区域中每个子区域的应用场景分配用于该子区域的VRSI的资源。
9、如项2所述的电子设备，其中，为所述至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI包括由VIMU执行的以下操作：
基于所述至少一个子区域中的每个子区域的历史数据分配用于该子区域的VRSI的资源。
10、如项2所述的电子设备，其中，第一VRSU标识符与第一VRSI的第一VRSI 标识符和第一虚拟路侧基础设施资源切片类型相关联，
第一VRSU标识符、第一VRSI标识符和第一虚拟路侧基础设施资源切片类型是由VIMU分配的，
其中，所述虚拟路侧基础设施资源切片类型是基于第一子区域的资源需求特征分配的。
11、如项10所述的电子设备，其中，VRSI标识符、VRSU标识符和虚拟路侧基础设施资源切片类型由VIMU经由VIMU与车联网云控平台之间的接口上的第三接口消息上报给车联网云控平台。
12、如项10所述的电子设备，其中，第一子区域的资源需求特征包括以下中的至少一者：
时延要求，
带宽要求，
计算能力要求，和
存储能力要求。
13、如项10所述的电子设备，其中，虚拟路侧基础设施资源切片类型包括以下之一：
均衡性切片，
低时延型切片，
大带宽型切片，
智能计算型切片，
大存储型切片，
高定位精度型切片，和
高可靠型切片。
14、如项1所述的电子设备，其中，处理器还被配置为执行如下操作：
向第一VRSU发送装载所述电子设备的车辆的行驶信息；和
接收来自第一VRSU的通行调度消息，其中，该通行调度消息包括第一VRSU标识符，所述通行调度消息包括基于所述电子设备发送的行驶信息并且基于其它电子设备发送的其它车辆的行驶信息、来自第一VRSI的路侧感知信息、目标路口的交通信号灯信息中的至少一者的通行调度信息。
15、如项1所述的电子设备，其中，处理器还被配置为执行如下操作：
向第一VRSU发送探测结果，所述探测结果包括由所述电子设备经由感知设备探测到的驾驶环境信息；和
从第一VRSU接收驾驶辅助消息，其中，该驾驶辅助消息包括第一VRSU标识符，该驾驶辅助消息包括基于其它电子设备发送的探测结果和第一VRSU的探测结果中的至少一者的驾驶辅助信息。
16、如项1所述的电子设备，其中，处理器还被配置为执行如下操作：
向第一VRSU发送包括第一VRSU标识符的消息。
17、如项1所述的电子设备，其中，第一VRSU经由与第一VRSU相关联的RSU与车辆网云控平台之间的接口上的V2X.RSU.INFO.UP消息和V2X.RSU.RunningInfo.UP消息分别上报业务数据和运行信息。
18、一种基于空中平台的路侧系统(RSS)，包括：
空中路侧基础设施承载平台(APRSI)，包括空中承载设施和承载于空中承载设施上的路侧基础设施，所述APRSI被配置为将路侧基础设施的物理资源虚拟化；和
虚拟基础设施管理单元(VIMU)，配置为为RSS的覆盖范围内的至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI，每个VRSI至少包括一虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分。
19、如项18所述的RSS，其中，每个VRSI还包括一虚拟路侧计算控制单元(VRSCCU)，VRSCCU包括被虚拟化的路侧计算控制单元的硬件资源和软件资源的 至少一部分。
20、如项18所述的RSS，其中，每个VRSI包括VRSU、虚拟路侧计算控制单元(VRSCCU)、交通控制设备和路侧传感设备，其中VRSCCU用于提供交通控制设备和路侧传感设备的接入。
21、如项18所述的RSS，其中，所述空中承载设施包括系留气球及其配套设施。
22、如项19所述的RSS，其中，路侧基础设施包括路侧单元、路侧计算控制单元、交通控制设备和路侧传感设备中的一个或多个。
23、如项18所述的RSS，其中，所述VIMU还被配置为：
至少基于与RSS的位置有关的地图信息确定RSS的覆盖范围内需要部署VRSI的所述至少一个子区域。
24、如项23所述的RSS，其中，所述VIMU还被配置为：
经由VIMU与车联网云控平台之间的接口上的第一接口消息向车联网云控平台上报第一系统基本信息，第一系统基本信息包括RSS的位置信息、运行形态和运行模式，其中运行形态指示RSS是否为虚拟态；和
经由VIMU与车联网云控平台之间的接口上的第二接口消息从车联网云控平台接收地图信息，地图信息是至少基于RSS的位置信息确定的。
25、如项23所述的RSS，其中，所述VIMU还被配置为：
基于所述至少一个子区域中的每个子区域的资源需求特征，为该子区域确定虚拟路侧基础设施资源切片类型。
26、如项25所述的RSS，其中，所述VIMU还被配置为：
经由VIMU与车联网云控平台之间的接口上的第三接口消息上报第二系统基本信息，第二系统基本信息包括VRSI标识符以及与VRSI标识符相关联的虚拟路侧基础设 施资源切片类型和VRSU标识符。
27、如项18所述的RSS，其中，所述VIMU还被配置为：
基于所述至少一个子区域中每个子区域的应用场景分配用于该子区域的VRSI的资源。
28、如项18所述的RSS，其中，所述VIMU还被配置为：
经由VIMU与车联网云控平台之间的接口上的第四接口消息从车联网云控平台接收所述至少一个子区域中的每个子区域的历史数据；
基于所述至少一个子区域中的每个子区域的历史数据分配用于该子区域的VRSI资源。
29、如项25所述的RSS，其中，所述VIMU还被配置为：
经由VIMU与车联网云控平台之间的接口上的第五接口消息上报第三系统基本信息，
第三系统基本信息包括VRSI标识符、相关联的VRSU标识符、相关联的VRSCCU标识符、相关联的路侧传感设备标识符以及相关联的交通控制设备标识符，
第三系统基本信息还包括VRSU资源配置和VRSCCU资源配置，VRSU资源配置和VRSCCU资源配置中的每一个包括以下中至少一者：虚拟CPU配置，虚拟内存配置，虚拟磁盘配置和虚拟网络配置。
30、如项25所述的RSS，其中，VRSU被配置为经由与VRSU相关联的RSU与车联网云控平台之间的接口上的V2X.RSU.INFO.UP消息和V2X.RSU.RunningInfo.UP消息分别向车联网云控平台上报业务数据和运行信息。
31、如项25所述的RSS，其中，VRSU被配置为向在其服务的子区域内的电子设备发送该VRSU的VRSU标识符。
32、如项31所述的RSS，其中，VRSU被配置为：
从在其服务的子区域内的电子设备接收有关装载所述电子设备的车辆的行驶信息；
基于所接收的行驶信息并且基于在其服务的子区域内的其它电子设备发送的其它车辆的行驶信息、来自第一VRSI的路侧感知信息和目标路口的交通信号灯信息中的至少一者生成通行调度信息；和
向所述电子设备发送包含该VRSU的VRSU标识符和所述通行调度信息的通行调度消息。
33、如项31所述的RSS，其中，VRSU被配置为：
从在其服务的子区域内的电子设备接收探测结果，所述探测结果包括由所述电子设备经由感知设备探测到的驾驶环境信息；
基于所接收的探测结果并且基于在其服务的子区域内的其它电子设备发送的探测结果和该VRSU的探测结果中的至少一者生成驾驶辅助信息；和
向所述电子设备发送包含该VRSU的VRSU标识符和所述驾驶辅助信息的驾驶辅助消息。
34、如项31所述的RSS，其中，VRSU被配置为：
从其服务的子区域内的电子设备接收包括该VRSU的VRSU标识符的消息。
35、一种虚拟基础设施管理单元(VIMU)，包括：
存储器，存储计算机可执行指令；和
处理器，其与存储器耦接，被配置为执行所述计算机可执行指令来执行如下操作：
为基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的每个子区域分配RSS的虚拟化的路侧基础设施的物理资源的至少一部分来为该子区域部署一虚拟路侧基础设施(VRSI)，每个VRSI至少包括虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分。
36、一种由电子设备执行的方法，包括：
在处于基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的第一子区域内时，从服务于第一子区域的第一虚拟路侧基础设施(VRSI)中的第一虚拟 路侧单元(VRSU)接收第一VRSU标识符。
37、一种由基于空中平台的路侧系统(RSS)执行的方法，包括：
由包括空中承载平台和承载于空中承载平台上的路侧基础设施的空中路侧基础设施承载平台(APRSI)将路侧基础设施的物理资源虚拟化；和
由虚拟基础设施管理单元(VIMU)为RSS的覆盖范围内的至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI，每个VRSI至少包括一虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分。
38、一种由虚拟基础设施管理单元(VIMU)执行的方法，包括：
为基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的每个子区域分配RSS的虚拟化的路侧基础设施的物理资源的至少一部分来为该子区域部署一虚拟路侧基础设施(VRSI)，每个VRSI至少包括虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分。
39、一种计算机存储介质，存储计算机可执行指令，所述计算机可执行指令在被处理器执行时执行如项36-38中任一项所述的方法。
40、一种计算机程序产品，包括计算机可执行指令，所述计算机可执行指令在被处理器执行时执行如项36-38中任一项所述的方法。
下面将介绍根据本公开的应用示例。
下面将介绍根据本公开的应用示例。
本公开内容的技术能够应用于各种产品。
本公开的路侧单元例如可以利用车联网中的路侧单元(RSU,Road Side Unit)来实现。
本公开的电子设备例如可以利用终端设备来实现。
例如，终端设备可以被实现为移动终端(诸如智能电话、平板个人计算机(PC)、 笔记本式PC、便携式游戏终端、便携式/加密狗型移动路由器和数字摄像装置)或者车载终端(诸如汽车导航设备)。终端设备还可以被实现为执行机器对机器(M2M)通信的终端(也称为机器类型通信(MTC)终端)。此外，终端设备可以为安装在上述终端中的每个终端上的无线通信模块(诸如包括单个晶片的集成电路模块)。
[关于RSU的应用示例]
(第一应用示例)
图13是示出可以应用本公开内容的技术的RSU的示意性配置的第一示例的框图。RSU 800包括一个或多个天线810以及路侧设备820。路侧设备820和每个天线810可以经由RF线缆彼此连接。
天线810中的每一个均包括单个或多个天线元件(诸如包括在多输入多输出(MIMO)天线中的多个天线元件)，并且用于路侧设备820发送和接收无线信号。如图13所示，RSU 800可以包括多个天线810。例如，多个天线810可以与RSU 800使用的多个频带兼容。路侧设备820包括控制器821、存储器822、网络接口823以及无线通信接口825。
控制器821可以为例如CPU或DSP，并且操作路侧设备820的较高层的各种功能。例如，控制器821根据由无线通信接口825处理的信号中的数据来生成数据分组，并经由网络接口823来传递所生成的分组。控制器821可以对来自多个基带处理器的数据进行捆绑以生成捆绑分组，并传递所生成的捆绑分组。控制器821可以具有执行如下控制的逻辑功能：该控制诸如为无线资源控制、无线承载控制、移动性管理、接纳控制和调度。该控制可以结合附近的RSU或核心网节点(例如接入与移动性管理功能AMF(Access and Mobility Management Function))来执行。存储器822包括RAM和ROM，并且存储由控制器821执行的程序和各种类型的控制数据(诸如终端列表、传输功率数据以及调度数据)。
网络接口823为用于将路侧设备820连接至核心网824的通信接口。控制器821可以经由网络接口823而与核心网节点或另外的RSU进行通信。在此情况下，RSU 800与核心网节点或其它RSU可以通过逻辑接口(诸如C-V2X uu接口、C-V2X PC5)而彼此连接。网络接口823还可以为有线通信接口或用于无线回程线路的无线通信接口。如果网络接口823为无线通信接口，则与由无线通信接口825使用的频带相比，网络接口823可以使用较高频带用于无线通信。
无线通信接口825支持任何蜂窝通信方案，并且经由天线810来提供到位于RSU800的小区中的终端的无线连接。无线通信接口825通常可以包括例如基带(BB)处理器826和RF电路827。BB处理器826可以执行例如编码/解码、调制/解调以及复用/解复用，并且执行层(例如L1、介质访问控制(MAC)、无线链路控制(RLC)和分组数据汇聚协议(PDCP))的各种类型的信号处理。代替控制器821，BB处理器826可以具有上述逻辑功能的一部分或全部。BB处理器826可以为存储通信控制程序的存储器，或者为包括被配置为执行程序的处理器和相关电路的模块。更新程序可以使BB处理器826的功能改变。该模块可以为插入到路侧设备820的槽中的卡或刀片。可替代地，该模块也可以为安装在卡或刀片上的芯片。同时，RF电路827可以包括例如混频器、滤波器和放大器，并且经由天线810来传送和接收无线信号。
如图13所示，无线通信接口825可以包括多个BB处理器826。例如，多个BB处理器826可以与RSU 800使用的多个频带兼容。如图13所示，无线通信接口825可以包括多个RF电路827。例如，多个RF电路827可以与多个天线元件兼容。虽然图13示出其中无线通信接口825包括多个BB处理器826和多个RF电路827的示例，但是无线通信接口825也可以包括单个BB处理器826或单个RF电路827。
(第二应用示例)
图14是示出可以应用本公开内容的技术的RSU的示意性配置的第二示例的框图。RSU包括一个或多个天线840、路侧设备850和RRH 860。RRH 860和每个天线840可以经由RF线缆而彼此连接。路侧设备850和RRH 860可以经由诸如光纤线缆的高速线路而彼此连接。
天线840中的每一个均包括单个或多个天线元件(诸如包括在MIMO天线中的多个天线元件)并且用于RRH 860发送和接收无线信号。如图14所示，RSU 830可以包括多个天线840。例如，多个天线840可以与RSU 830使用的多个频带兼容。路侧设备850包括控制器851、存储器852、网络接口853、无线通信接口855以及连接接口857。控制器851、存储器852和网络接口853与参照图13描述的控制器821、存储器822和网络接口823相同。
无线通信接口855支持任何蜂窝通信方案，并且经由RRH 860和天线840来提供到位于与RRH 860对应的扇区中的终端的无线通信。无线通信接口855通常可以包括例如BB处理器856。除了BB处理器856经由连接接口857连接到RRH 860的RF电 路864之外，BB处理器856与参照图13描述的BB处理器826相同。如图14所示，无线通信接口855可以包括多个BB处理器856。例如，多个BB处理器856可以与RSU 830使用的多个频带兼容。虽然图14示出其中无线通信接口855包括多个BB处理器856的示例，但是无线通信接口855也可以包括单个BB处理器856。
连接接口857为用于将路侧设备850(无线通信接口855)连接至RRH 860的接口。连接接口857还可以为用于将路侧设备850(无线通信接口855)连接至RRH 860的上述高速线路中的通信的通信模块。
RRH 860包括连接接口861和无线通信接口863。
连接接口861为用于将RRH 860(无线通信接口863)连接至路侧设备850的接口。连接接口861还可以为用于上述高速线路中的通信的通信模块。
无线通信接口863经由天线840来传送和接收无线信号。无线通信接口863通常可以包括例如RF电路864。RF电路864可以包括例如混频器、滤波器和放大器，并且经由天线840来传送和接收无线信号。如图14所示，无线通信接口863可以包括多个RF电路864。例如，多个RF电路864可以支持多个天线元件。虽然图14示出其中无线通信接口863包括多个RF电路864的示例，但是无线通信接口863也可以包括单个RF电路864。
在图13和图14所示的RSU 800和RSU 830中，参考图13描述的处理电路1310和参考图16描述的处理电路1610中包括的一个或多个组件可被实现在无线通信接口912中。可替代地，这些组件中的至少一部分也可以由控制器821和控制器851实现。
[关于终端设备的应用示例]
(第一应用示例)
图15是示出可以应用本公开内容的技术的智能电话900的示意性配置的示例的框图。智能电话900包括处理器901、存储器902、存储装置903、外部连接接口904、摄像装置906、传感器907、麦克风908、输入装置909、显示装置910、扬声器911、无线通信接口912、一个或多个天线开关915、一个或多个天线916、总线917、电池918以及辅助控制器919。
处理器901可以为例如CPU或片上系统(SoC)，并且控制智能电话900的应用层和另外层的功能。存储器902包括RAM和ROM，并且存储数据和由处理器901执行的程序。存储装置903可以包括存储介质，诸如半导体存储器和硬盘。外部连接接 口904为用于将外部装置(诸如存储卡和通用串行总线(USB)装置)连接至智能电话900的接口。
摄像装置906包括图像传感器(诸如电荷耦合器件(CCD)和互补金属氧化物半导体(CMOS))，并且生成捕获图像。传感器907可以包括一组传感器，诸如测量传感器、陀螺仪传感器、地磁传感器和加速度传感器。麦克风908将输入到智能电话900的声音转换为音频信号。输入装置909包括例如被配置为检测显示装置910的屏幕上的触摸的触摸传感器、小键盘、键盘、按钮或开关，并且接收从用户输入的操作或信息。显示装置910包括屏幕(诸如液晶显示器(LCD)和有机发光二极管(OLED)显示器)，并且显示智能电话900的输出图像。扬声器911将从智能电话900输出的音频信号转换为声音。
无线通信接口912支持任何蜂窝通信方案(诸如LTE和LTE-先进)，并且执行无线通信。无线通信接口912通常可以包括例如BB处理器913和RF电路914。BB处理器913可以执行例如编码/解码、调制/解调以及复用/解复用，并且执行用于无线通信的各种类型的信号处理。同时，RF电路914可以包括例如混频器、滤波器和放大器，并且经由天线916来传送和接收无线信号。无线通信接口912可以为其上集成有BB处理器913和RF电路914的一个芯片模块。如图15所示，无线通信接口912可以包括多个BB处理器913和多个RF电路914。虽然图15示出其中无线通信接口912包括多个BB处理器913和多个RF电路914的示例，但是无线通信接口912也可以包括单个BB处理器913或单个RF电路914。
此外，除了蜂窝通信方案之外，无线通信接口912可以支持另外类型的无线通信方案，诸如短距离无线通信方案、近场通信方案和无线局域网(LAN)方案。在此情况下，无线通信接口912可以包括针对每种无线通信方案的BB处理器913和RF电路914。
天线开关915中的每一个在包括在无线通信接口912中的多个电路(例如用于不同的无线通信方案的电路)之间切换天线916的连接目的地。
天线916中的每一个均包括单个或多个天线元件(诸如包括在MIMO天线中的多个天线元件)，并且用于无线通信接口912传送和接收无线信号。如图15所示，智能电话900可以包括多个天线916。虽然图15示出其中智能电话900包括多个天线916的示例，但是智能电话900也可以包括单个天线916。
此外，智能电话900可以包括针对每种无线通信方案的天线916。在此情况下，天线开关915可以从智能电话900的配置中省略。
总线917将处理器901、存储器902、存储装置903、外部连接接口904、摄像装置906、传感器907、麦克风908、输入装置909、显示装置910、扬声器911、无线通信接口912以及辅助控制器919彼此连接。电池918经由馈线向图15所示的智能电话900的各个块提供电力，馈线在图中被部分地示为虚线。辅助控制器919例如在睡眠模式下操作智能电话900的最小必需功能。
在图15所示的智能电话900中，参考图13描述的处理电路1310和参考图16描述的处理电路1610中包括的一个或多个组件可被实现在无线通信接口912中。可替代地，这些组件中的至少一部分也可以由处理器901或辅助控制器919实现。
(第二应用示例)
图16是示出可以应用本公开内容的技术的汽车导航设备920的示意性配置的示例的框图。汽车导航设备920包括处理器921、存储器922、全球定位系统(GPS)模块924、传感器925、数据接口926、内容播放器927、存储介质接口928、输入装置929、显示装置930、扬声器931、无线通信接口933、一个或多个天线开关936、一个或多个天线937以及电池938。
处理器921可以为例如CPU或SoC，并且控制汽车导航设备920的导航功能和另外的功能。存储器922包括RAM和ROM，并且存储数据和由处理器921执行的程序。
GPS模块924使用从GPS卫星接收的GPS信号来测量汽车导航设备920的位置(诸如纬度、经度和高度)。传感器925可以包括一组传感器，诸如陀螺仪传感器、地磁传感器和空气压力传感器。数据接口926经由未示出的终端而连接到例如车载网络941，并且获取由车辆生成的数据(诸如车速数据)。
内容播放器927再现存储在存储介质(诸如CD和DVD)中的内容，该存储介质被插入到存储介质接口928中。输入装置929包括例如被配置为检测显示装置930的屏幕上的触摸的触摸传感器、按钮或开关，并且接收从用户输入的操作或信息。显示装置930包括诸如LCD或OLED显示器的屏幕，并且显示导航功能的图像或再现的内容。扬声器931输出导航功能的声音或再现的内容。
无线通信接口933支持任何蜂窝通信方案(诸如LTE和LTE-先进)，并且执行无线通信。无线通信接口933通常可以包括例如BB处理器934和RF电路935。BB处 理器934可以执行例如编码/解码、调制/解调以及复用/解复用，并且执行用于无线通信的各种类型的信号处理。同时，RF电路935可以包括例如混频器、滤波器和放大器，并且经由天线937来传送和接收无线信号。无线通信接口933还可以为其上集成有BB处理器934和RF电路935的一个芯片模块。如图16所示，无线通信接口933可以包括多个BB处理器934和多个RF电路935。虽然图16示出其中无线通信接口933包括多个BB处理器934和多个RF电路935的示例，但是无线通信接口933也可以包括单个BB处理器934或单个RF电路935。
此外，除了蜂窝通信方案之外，无线通信接口933可以支持另外类型的无线通信方案，诸如短距离无线通信方案、近场通信方案和无线LAN方案。在此情况下，针对每种无线通信方案，无线通信接口933可以包括BB处理器934和RF电路935。
天线开关936中的每一个在包括在无线通信接口933中的多个电路(诸如用于不同的无线通信方案的电路)之间切换天线937的连接目的地。
天线937中的每一个均包括单个或多个天线元件(诸如包括在MIMO天线中的多个天线元件)，并且用于无线通信接口933传送和接收无线信号。如图16所示，汽车导航设备920可以包括多个天线937。虽然图16示出其中汽车导航设备920包括多个天线937的示例，但是汽车导航设备920也可以包括单个天线937。
此外，汽车导航设备920可以包括针对每种无线通信方案的天线937。在此情况下，天线开关936可以从汽车导航设备920的配置中省略。
电池938经由馈线向图16所示的汽车导航设备920的各个块提供电力，馈线在图中被部分地示为虚线。电池938累积从车辆提供的电力。
在图16示出的汽车导航设备920中，参考图19描述的处理电路1910中包括的一个或多个组件可被实现在无线通信接口912中。可替代地，这些组件中的至少一部分也可以由处理器921实现。
本公开内容的技术也可以被实现为包括汽车导航设备920、车载网络941以及车辆模块942中的一个或多个块的车载系统(或车辆)940。车辆模块942生成车辆数据(诸如车速、发动机速度和故障信息)，并且将所生成的数据输出至车载网络941。
应当理解，本说明书中“实施例”或类似表达方式的引用是指结合该实施例所述的特定特征、结构、或特性系包括在本公开的至少一具体实施例中。因此，在本说明书中，“在本公开的实施例中”及类似表达方式的用语的出现未必指相同的实施例。
本领域技术人员应当知道，本公开被实施为一系统、装置、方法或作为计算机程序产品的计算机可读存储介质(例如非瞬态存储介质)。因此，本公开可以实施为各种形式，例如完全的硬件实施例、完全的软件实施例(包括固件、常驻软件、微程序代码等)，或者也可实施为软件与硬件的实施形式，在以下会被称为“电路”、“模块”或“系统”。此外，本公开也可以任何有形的媒体形式实施为计算机程序产品，其具有计算机可使用程序代码存储于其上。
本公开的相关叙述参照根据本公开具体实施例的系统、装置、方法及计算机程序产品的流程图和/或框图来进行说明。可以理解每一个流程图和/或框图中的每一个块，以及流程图和/或框图中的块的任何组合，可以使用计算机程序指令来实施。这些计算机程序指令可供通用型计算机或特殊计算机的处理器或其它可编程数据处理装置所组成的机器来执行，而指令经由计算机或其它可编程数据处理装置处理以便实施流程图和/或框图中所说明的功能或操作。
在附图中显示根据本公开各种实施例的系统、装置、方法及计算机程序产品可实施的架构、功能及操作的流程图及框图。因此，流程图或框图中的每个块可表示一模块、区段、或部分的程序代码，其包括一个或多个可执行指令，以实施指定的逻辑功能。另外应当注意，在某些其它的实施例中，块所述的功能可以不按图中所示的顺序进行。举例来说，两个图示相连接的块事实上也可以同时执行，或根据所涉及的功能在某些情况下也可以按图标相反的顺序执行。此外还需注意，每个框图和/或流程图的块，以及框图和/或流程图中块的组合，可藉由基于专用硬件的系统来实施，或者藉由专用硬件与计算机指令的组合，来执行特定的功能或操作。
以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场技术的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (40)

  1. 一种电子设备，包括：
    存储器，存储计算机可执行指令；和
    处理器，其与存储器耦接，被配置为执行所述计算机可执行指令来执行如下操作：
    在处于基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的第一子区域内时，从服务于第一子区域的第一虚拟路侧基础设施(VRSI)中的第一虚拟路侧单元(VRSU)接收第一VRSU标识符。
  2. 如权利要求1所述的电子设备，其中，通过将RSS的路侧基础设施的物理资源进行虚拟化并为所述至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI，每个VRSI包括一VRSU，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分，每个VRSU具有相应的VRSU标识符，所述至少一个子区域包括第一子区域。
  3. 如权利要求2所述的电子设备，其中，第一VRSU标识符与第一VRSI的第一VRSI标识符和第一虚拟路侧计算控制单元(VRSCCU)标识符相关联，
    其中，第一VRSI包括第一VRSCCU，第一VRSCCU包括被虚拟化的路侧计算控制单元的硬件资源和软件资源的至少一部分，
    其中，第一VRSU标识符、第一VRSI标识符和第一VRSCCU标识符是由所述RSS的虚拟基础设施管理单元(VIMU)分配的。
  4. 如权利要求3所述的电子设备，其中：
    由VIMU分配的与第一VRSU标识符相关联的资源配置或与第一VRSCCU标识符相关联的资源配置包括以下中至少一者：虚拟CPU配置，虚拟内存配置，虚拟磁盘配置和虚拟网络配置。
  5. 如权利要求3所述的电子设备，其中，第一VRSI标识符、第一VRSU标识符和第一VRSCCU标识符由VIMU经由VIMU与车联网云控平台之间的接口上的第一接口消息上报给车联网云控平台。
  6. 如权利要求2所述的电子设备，其中，所述至少一个子区域是由VIMU通过如下操作确定的：
    至少基于与RSS的位置有关的地图信息确定RSS的覆盖范围内需要部署VRSI的所述至少一个子区域。
  7. 如权利要求6所述的电子设备，其中，所述地图信息是由VIMU经由VIMU与车联网云控平台之间的接口上的第二接口消息从车联网云控平台接收的。
  8. 如权利要求2所述的电子设备，其中，为所述至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI包括由VIMU执行的以下操作：
    基于所述至少一个子区域中每个子区域的应用场景分配用于该子区域的VRSI的资源。
  9. 如权利要求2所述的电子设备，其中，为所述至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI包括由VIMU执行的以下操作：
    基于所述至少一个子区域中的每个子区域的历史数据分配用于该子区域的VRSI的资源。
  10. 如权利要求2所述的电子设备，其中，第一VRSU标识符与第一VRSI的第一VRSI标识符和第一虚拟路侧基础设施资源切片类型相关联，
    第一VRSU标识符、第一VRSI标识符和第一虚拟路侧基础设施资源切片类型是由VIMU分配的，
    其中，所述虚拟路侧基础设施资源切片类型是基于第一子区域的资源需求特征分配的。
  11. 如权利要求10所述的电子设备，其中，VRSI标识符、VRSU标识符和虚拟路侧基础设施资源切片类型由VIMU经由VIMU与车联网云控平台之间的接口上的第 三接口消息上报给车联网云控平台。
  12. 如权利要求10所述的电子设备，其中，第一子区域的资源需求特征包括以下中的至少一者：
    时延要求，
    带宽要求，
    计算能力要求，和
    存储能力要求。
  13. 如权利要求10所述的电子设备，其中，虚拟路侧基础设施资源切片类型包括以下之一：
    均衡性切片，
    低时延型切片，
    大带宽型切片，
    智能计算型切片，
    大存储型切片，
    高定位精度型切片，和
    高可靠型切片。
  14. 如权利要求1所述的电子设备，其中，处理器还被配置为执行如下操作：
    向第一VRSU发送装载所述电子设备的车辆的行驶信息；和
    接收来自第一VRSU的通行调度消息，其中，该通行调度消息包括第一VRSU标识符，所述通行调度消息包括基于所述电子设备发送的行驶信息并且基于其它电子设备发送的其它车辆的行驶信息、来自第一VRSI的路侧感知信息、目标路口的交通信号灯信息中的至少一者的通行调度信息。
  15. 如权利要求1所述的电子设备，其中，处理器还被配置为执行如下操作：
    向第一VRSU发送探测结果，所述探测结果包括由所述电子设备经由感知设备探测到的驾驶环境信息；和
    从第一VRSU接收驾驶辅助消息，其中，该驾驶辅助消息包括第一VRSU标识符，该驾驶辅助消息包括基于其它电子设备发送的探测结果和第一VRSU的探测结果中的至少一者的驾驶辅助信息。
  16. 如权利要求1所述的电子设备，其中，处理器还被配置为执行如下操作：
    向第一VRSU发送包括第一VRSU标识符的消息。
  17. 如权利要求1所述的电子设备，其中，第一VRSU经由与第一VRSU相关联的RSU与车辆网云控平台之间的接口上的V2X.RSU.INFO.UP消息和V2X.RSU.RunningInfo.UP消息分别上报业务数据和运行信息。
  18. 一种基于空中平台的路侧系统(RSS)，包括：
    空中路侧基础设施承载平台(APRSI)，包括空中承载设施和承载于空中承载设施上的路侧基础设施，所述APRSI被配置为将路侧基础设施的物理资源虚拟化；和
    虚拟基础设施管理单元(VIMU)，配置为为RSS的覆盖范围内的至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI，每个VRSI至少包括一虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分。
  19. 如权利要求18所述的RSS，其中，每个VRSI还包括一虚拟路侧计算控制单元(VRSCCU)，VRSCCU包括被虚拟化的路侧计算控制单元的硬件资源和软件资源的至少一部分。
  20. 如权利要求18所述的RSS，其中，每个VRSI包括VRSU、虚拟路侧计算控制单元(VRSCCU)、交通控制设备和路侧传感设备，其中VRSCCU用于提供交通控制设备和路侧传感设备的接入。
  21. 如权利要求18所述的RSS，其中，所述空中承载设施包括系留气球及其配套设施。
  22. 如权利要求19所述的RSS，其中，路侧基础设施包括路侧单元、路侧计算控制单元、交通控制设备和路侧传感设备中的一个或多个。
  23. 如权利要求18所述的RSS，其中，所述VIMU还被配置为：
    至少基于与RSS的位置有关的地图信息确定RSS的覆盖范围内需要部署VRSI的所述至少一个子区域。
  24. 如权利要求23所述的RSS，其中，所述VIMU还被配置为：
    经由VIMU与车联网云控平台之间的接口上的第一接口消息向车联网云控平台上报第一系统基本信息，第一系统基本信息包括RSS的位置信息、运行形态和运行模式，其中运行形态指示RSS是否为虚拟态；和
    经由VIMU与车联网云控平台之间的接口上的第二接口消息从车联网云控平台接收地图信息，地图信息是至少基于RSS的位置信息确定的。
  25. 如权利要求23所述的RSS，其中，所述VIMU还被配置为：
    基于所述至少一个子区域中的每个子区域的资源需求特征，为该子区域确定虚拟路侧基础设施资源切片类型。
  26. 如权利要求25所述的RSS，其中，所述VIMU还被配置为：
    经由VIMU与车联网云控平台之间的接口上的第三接口消息上报第二系统基本信息，第二系统基本信息包括VRSI标识符以及与VRSI标识符相关联的虚拟路侧基础设施资源切片类型和VRSU标识符。
  27. 如权利要求18所述的RSS，其中，所述VIMU还被配置为：
    基于所述至少一个子区域中每个子区域的应用场景分配用于该子区域的VRSI的资源。
  28. 如权利要求18所述的RSS，其中，所述VIMU还被配置为：
    经由VIMU与车联网云控平台之间的接口上的第四接口消息从车联网云控平台接 收所述至少一个子区域中的每个子区域的历史数据；
    基于所述至少一个子区域中的每个子区域的历史数据分配用于该子区域的VRSI资源。
  29. 如权利要求25所述的RSS，其中，所述VIMU还被配置为：
    经由VIMU与车联网云控平台之间的接口上的第五接口消息上报第三系统基本信息，
    第三系统基本信息包括VRSI标识符、相关联的VRSU标识符、相关联的VRSCCU标识符、相关联的路侧传感设备标识符以及相关联的交通控制设备标识符，
    第三系统基本信息还包括VRSU资源配置和VRSCCU资源配置，VRSU资源配置和VRSCCU资源配置中的每一个包括以下中至少一者：虚拟CPU配置，虚拟内存配置，虚拟磁盘配置和虚拟网络配置。
  30. 如权利要求25所述的RSS，其中，VRSU被配置为经由与VRSU相关联的RSU与车联网云控平台之间的接口上的V2X.RSU.INFO.UP消息和V2X.RSU.RunningInfo.UP消息分别向车联网云控平台上报业务数据和运行信息。
  31. 如权利要求25所述的RSS，其中，VRSU被配置为向在其服务的子区域内的电子设备发送该VRSU的VRSU标识符。
  32. 如权利要求31所述的RSS，其中，VRSU被配置为：
    从在其服务的子区域内的电子设备接收有关装载所述电子设备的车辆的行驶信息；
    基于所接收的行驶信息并且基于在其服务的子区域内的其它电子设备发送的其它车辆的行驶信息、来自第一VRSI的路侧感知信息和目标路口的交通信号灯信息中的至少一者生成通行调度信息；和
    向所述电子设备发送包含该VRSU的VRSU标识符和所述通行调度信息的通行调度消息。
  33. 如权利要求31所述的RSS，其中，VRSU被配置为：
    从在其服务的子区域内的电子设备接收探测结果，所述探测结果包括由所述电子设备经由感知设备探测到的驾驶环境信息；
    基于所接收的探测结果并且基于在其服务的子区域内的其它电子设备发送的探测结果和该VRSU的探测结果中的至少一者生成驾驶辅助信息；和
    向所述电子设备发送包含该VRSU的VRSU标识符和所述驾驶辅助信息的驾驶辅助消息。
  34. 如权利要求31所述的RSS，其中，VRSU被配置为：
    从其服务的子区域内的电子设备接收包括该VRSU的VRSU标识符的消息。
  35. 一种虚拟基础设施管理单元(VIMU)，包括：
    存储器，存储计算机可执行指令；和
    处理器，其与存储器耦接，被配置为执行所述计算机可执行指令来执行如下操作：
    为基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的每个子区域分配RSS的虚拟化的路侧基础设施的物理资源的至少一部分来为该子区域部署一虚拟路侧基础设施(VRSI)，每个VRSI至少包括虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分。
  36. 一种由电子设备执行的方法，包括：
    在处于基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的第一子区域内时，从服务于第一子区域的第一虚拟路侧基础设施(VRSI)中的第一虚拟路侧单元(VRSU)接收第一VRSU标识符。
  37. 一种由基于空中平台的路侧系统(RSS)执行的方法，包括：
    由包括空中承载平台和承载于空中承载平台上的路侧基础设施的空中路侧基础设施承载平台(APRSI)将路侧基础设施的物理资源虚拟化；和
    由虚拟基础设施管理单元(VIMU)为RSS的覆盖范围内的至少一个子区域中的每个子区域分配虚拟化的物理资源的至少一部分来为每个子区域部署一VRSI，每个VRSI至少包括一虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元 (RSU)的硬件资源和软件资源的至少一部分。
  38. 一种由虚拟基础设施管理单元(VIMU)执行的方法，包括：
    为基于空中平台的路侧系统(RSS)的覆盖范围内的至少一个子区域中的每个子区域分配RSS的虚拟化的路侧基础设施的物理资源的至少一部分来为该子区域部署一虚拟路侧基础设施(VRSI)，每个VRSI至少包括虚拟路侧单元(VRSU)，每个VRSU包括被虚拟化的路侧单元(RSU)的硬件资源和软件资源的至少一部分。
  39. 一种计算机存储介质，存储计算机可执行指令，所述计算机可执行指令在被处理器执行时执行如权利要求36-38中任一项所述的方法。
  40. 一种计算机程序产品，包括计算机可执行指令，所述计算机可执行指令在被处理器执行时执行如项36-38中任一项所述的方法。
PCT/CN2023/089092 2022-04-22 2023-04-19 基于空中平台的路侧系统 WO2023202594A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210430292.7 2022-04-22
CN202210430292.7A CN116980858A (zh) 2022-04-22 2022-04-22 基于空中平台的路侧系统

Publications (1)

Publication Number Publication Date
WO2023202594A1 true WO2023202594A1 (zh) 2023-10-26

Family

ID=88419205

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/089092 WO2023202594A1 (zh) 2022-04-22 2023-04-19 基于空中平台的路侧系统

Country Status (2)

Country Link
CN (1) CN116980858A (zh)
WO (1) WO2023202594A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107683613A (zh) * 2015-06-24 2018-02-09 英特尔Ip公司 增强型支持车辆到万物（v2x）通信
CN110072749A (zh) * 2016-12-29 2019-07-30 英特尔公司 自主驾驶中交通动态与道路变化的检测
US20190297600A1 (en) * 2016-11-29 2019-09-26 Lg Electronics Inc. Resource allocation method for v2x communication in wireless communication system and device therefor
KR102103823B1 (ko) * 2019-08-28 2020-04-24 (주)세스트 V2x 통신 시스템 및 그 처리 방법
CN112585658A (zh) * 2018-06-18 2021-03-30 R·A·艾勒森 路侧单元系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107683613A (zh) * 2015-06-24 2018-02-09 英特尔Ip公司 增强型支持车辆到万物（v2x）通信
US20190297600A1 (en) * 2016-11-29 2019-09-26 Lg Electronics Inc. Resource allocation method for v2x communication in wireless communication system and device therefor
CN110072749A (zh) * 2016-12-29 2019-07-30 英特尔公司 自主驾驶中交通动态与道路变化的检测
CN112585658A (zh) * 2018-06-18 2021-03-30 R·A·艾勒森 路侧单元系统
KR102103823B1 (ko) * 2019-08-28 2020-04-24 (주)세스트 V2x 통신 시스템 및 그 처리 방법

Also Published As

Publication number Publication date
CN116980858A (zh) 2023-10-31

Similar Documents

Publication Publication Date Title
EP3504513B9 (en) Navigation assistance data and route planning for drones
US9866313B1 (en) UAV cellular communication service delivery
CN104584593B (zh) 用于传达安全消息信息的方法和装置
US10354521B2 (en) Facilitating location positioning service through a UAV network
WO2017114496A1 (en) Facilitating location positioning service through a uav network
Lu et al. Toward uav-based airborne computing
CN109756572B (zh) 一种分布式计算网络系统与方法
EP3764062A1 (en) Method and apparatus for routing an aerial vehicle based on a relative noise impact
TW201838360A (zh) 航空機器人飛行器天線切換
US20150294396A1 (en) Item location indication in indoor environment
US11699348B2 (en) Air traffic tolling system
JP2017073023A (ja) 交通事象情報提供システム、中央装置、無人飛行体および交通事象情報提供プログラム
CN111091333A (zh) 快递投放方法、装置及存储介质
EP3950499A1 (en) Communication management device, communication management system, communication management method, and communication management program
CN115550860A (zh) 一种无人机组网通信系统及方法
JP2021190951A (ja) システム、無人航空機、管理装置、プログラム、及び管理方法
US11653126B2 (en) Method and system for moving status detection for a sensor apparatus
WO2019026179A1 (ja) 飛行情報収集システム、無線通信装置、中継機、飛行情報収集方法
EP4221321A1 (en) Data transmitting device, data transmitting method, and data transmitting program
WO2023202594A1 (zh) 基于空中平台的路侧系统
WO2022135253A1 (zh) 用于无线通信的电子设备和方法、计算机可读存储介质
Bassoo et al. 5G Connectivity in the Transport Sector: Vehicles and Drones Use Cases
EP4198945A1 (en) Vehicle navigation assistance
US12017767B2 (en) Communication management device, communication management system, communication management method, and communication management program
Owaid et al. Survey on UAV Communications: Systems, Communication Technologies, Networks, Application

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23791249

Country of ref document: EP

Kind code of ref document: A1