U.S. patent application number 16/283717 was filed with the patent office on 2020-08-27 for managing regionalized vehicular communication.
The applicant listed for this patent is Toyota Jidosha Kabushiki Kaisha. Invention is credited to Shalini Keshavamurthy.
Application Number | 20200275286 16/283717 |
Document ID | / |
Family ID | 1000005016795 |
Filed Date | 2020-08-27 |
![](/patent/app/20200275286/US20200275286A1-20200827-D00000.png)
![](/patent/app/20200275286/US20200275286A1-20200827-D00001.png)
![](/patent/app/20200275286/US20200275286A1-20200827-D00002.png)
![](/patent/app/20200275286/US20200275286A1-20200827-D00003.png)
![](/patent/app/20200275286/US20200275286A1-20200827-D00004.png)
![](/patent/app/20200275286/US20200275286A1-20200827-D00005.png)
![](/patent/app/20200275286/US20200275286A1-20200827-D00006.png)
![](/patent/app/20200275286/US20200275286A1-20200827-D00007.png)
![](/patent/app/20200275286/US20200275286A1-20200827-D00008.png)
![](/patent/app/20200275286/US20200275286A1-20200827-D00009.png)
![](/patent/app/20200275286/US20200275286A1-20200827-D00010.png)
United States Patent
Application |
20200275286 |
Kind Code |
A1 |
Keshavamurthy; Shalini |
August 27, 2020 |
Managing Regionalized Vehicular Communication
Abstract
A method determines a topology modification for a geographical
area; determines a set of coverage region(s) in the geographical
area that are adjacent to a target coverage region, the target
coverage region being associated with a first regionalized server
configured to communicate with vehicular traffic in the target
coverage region, the set of coverage region(s) being respectively
associated with a set of second regionalized server(s), each second
regionalized server being configured to communicate with vehicular
traffic in a corresponding coverage region of the set of coverage
region(s); determines that a region count of the set of coverage
region(s) satisfies a region count threshold; responsive to
determining that the region count of the set of coverage region(s)
satisfies the region count threshold, determines a morphing portion
for each coverage region in the set of coverage region(s); and
morphs the set of coverage region(s) based on the corresponding
morphing portions.
Inventors: |
Keshavamurthy; Shalini;
(Sunnyvale, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Toyota Jidosha Kabushiki Kaisha |
Toyota-shi |
|
JP |
|
|
Family ID: |
1000005016795 |
Appl. No.: |
16/283717 |
Filed: |
February 22, 2019 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 41/12 20130101;
H04W 16/24 20130101; H04W 4/44 20180201 |
International
Class: |
H04W 16/24 20060101
H04W016/24; H04L 12/24 20060101 H04L012/24; H04W 4/44 20060101
H04W004/44 |
Claims
1. A method comprising: determining a topology modification for a
geographical area; determining a set of one or more coverage
regions in the geographical area that are adjacent to a target
coverage region, the target coverage region being associated with a
first regionalized server configured to communicate with vehicular
traffic in the target coverage region, the set of one or more
coverage regions being respectively associated with a set of one or
more second regionalized servers, each second regionalized server
of the set of one or more second regionalized servers being
configured to communicate with vehicular traffic in a corresponding
coverage region of the set of one or more coverage regions;
determining that a region count of the set of one or more coverage
regions satisfies a region count threshold; responsive to
determining that the region count of the set of one or more
coverage regions satisfies the region count threshold, determining
a morphing portion for each coverage region in the set of one or
more coverage regions; and morphing the set of one or more coverage
regions associated with the set of one or more second regionalized
servers based on corresponding morphing portions.
2. The method of claim 1, wherein: the topology modification of the
geographical area includes one of a creation of the target coverage
region for the first regionalized server, the first regionalized
server being initiated; and an expansion of a first coverage region
associated with the first regionalized server to the target
coverage region; and determining the morphing portion of a coverage
region of the set of one or more coverage regions to include an
area where the coverage region associated with a second
regionalized server overlaps with the target coverage region of the
first regionalized server.
3. The method of claim 2, wherein morphing the set of one or more
coverage regions associated with the set of one or more second
regionalized servers includes: reducing the coverage region
associated with the second regionalized server to exclude the
morphing portion corresponding to the coverage region; transmitting
data associated with the morphing portion from the second
regionalized server to the first regionalized server; and
instructing a plurality of vehicles located within the morphing
portion to communicate with the first regionalized server.
4. The method of claim 1, wherein: the topology modification of the
geographical area includes one of: an elimination of a first
coverage region associated with the first regionalized server, the
first regionalized server being removed; and a reduction of the
first coverage region associated with the first regionalized server
to the target coverage region; and determining the set of one or
more coverage regions in the geographical area includes:
determining a difference region between the first coverage region
associated with the first regionalized server and the target
coverage region; and determining that a resource amount of the set
of one or more second regionalized servers satisfies a resource
amount to accommodate a plurality of vehicles located within the
set of one or more coverage regions associated with the set of one
or more second regionalized servers and the difference region.
5. The method of claim 4, wherein determining the morphing portion
for each coverage region in the set of one or more coverage regions
includes: determining, from the difference region, a morphing
portion for a coverage region associated with a second regionalized
server based on a resource amount of the second regionalized server
and a traffic condition in the difference region.
6. The method of claim 5, wherein morphing the set of one or more
coverage regions associated with the set of one or more second
regionalized servers includes: expanding the coverage region
associated with the second regionalized server to include the
morphing portion corresponding to the coverage region; transmitting
data associated with the morphing portion from the first
regionalized server to the second regionalized server; and
instructing a plurality of vehicles located within the morphing
portion to communicate with the second regionalized server.
7. The method of claim 1, further comprising: determining that the
region count of the set of one or more coverage regions does not
satisfy the region count threshold; responsive to determining that
the region count of the set of one or more coverage regions does
not satisfy the region count threshold, determining, from the first
regionalized server and the set of one or more second regionalized
servers, a set of one or more third regionalized servers based on
the topology modification of the geographical area; determining a
set of one or more third coverage regions in the geographical area
for the set of one or more third regionalized servers; and
respectively assigning the set of one or more third coverage
regions to the set of one or more third regionalized servers.
8. The method of claim 7, wherein determining the set of one or
more third coverage regions in the geographical area includes:
determining a third coverage region for a third regionalized server
based on a resource amount of the third regionalized server and a
traffic condition in the third coverage region.
9. The method of claim 7, further comprising: classifying the first
regionalized server and the set of one or more second regionalized
servers into one or more physical regionalized servers and one or
more virtual regionalized servers; initiating one or more temporary
virtual regionalized servers corresponding to the one or more
physical regionalized servers; transmitting data associated with
each physical regionalized server to a temporary virtual
regionalized server corresponding to the physical regionalized
server; and responsive to respectively assigning the set of one or
more third coverage regions to the set of one or more third
regionalized servers, transmitting, from the one or more virtual
regionalized servers and the one or more temporary virtual
regionalized servers, data associated with each third coverage
region to a third regionalized server associated with the third
coverage region.
10. The method of claim 9, further comprising: responsive to
transmitting the data associated with each third coverage region to
the third regionalized server associated with the third coverage
region, instructing a plurality of vehicles located within the
third coverage region associated with the third regionalized server
to communicate with the third regionalized server; and removing the
one or more temporary virtual regionalized servers.
11. The method of claim 1, wherein the topology modification of the
geographical area is associated with a trigger event, the trigger
event including one or more of: a change of roadway condition, a
change of traffic condition, and a change of traffic condition
reflected in a traffic pattern of a road segment in the
geographical area; an implementation of a vehicle application that
is temporarily accessible in an application accessible area within
the geographical area; and an unavailability of a regionalized
server associated with a coverage region in the geographical
area.
12. The method of claim 1, wherein determining the topology
modification for the geographical area includes: determining a road
segment in the geographical area that has a vehicle density of the
road segment satisfying a vehicle density threshold; and
determining the target coverage region for the first regionalized
server based on the road segment.
13. The method of claim 1, wherein determining the topology
modification for the geographical area includes: determining an
application accessible area for a vehicle application temporarily
implemented on the first regionalized server; and determining the
target coverage region for the first regionalized server based on
the application accessible area of the vehicle application.
14. The method of claim 1, wherein determining the topology
modification for the geographical area includes: estimating a
number of vehicles that are accommodatable by the first
regionalized server based on a resource amount of the first
regionalized server and operation requirements of a vehicle
application; determining a vehicle density of a road segment that
includes a first coverage region associated with the first
regionalized server; and determining the target coverage region for
the first regionalized server based on the number of vehicles that
are accommodatable by the first regionalized server and the vehicle
density of the road segment.
15. A system comprising: one or more processors; and one or more
memories storing instructions that, when executed by the one or
more processors, cause the system to: determine a topology
modification for a geographical area; determine a set of one or
more coverage regions in the geographical area that are adjacent to
a target coverage region, the target coverage region being
associated with a first regionalized server configured to
communicate with vehicular traffic in the target coverage region,
the set of one or more coverage regions being respectively
associated with a set of one or more second regionalized servers,
each second regionalized server of the set of one or more second
regionalized servers being configured to communicate with vehicular
traffic in a corresponding coverage region of the set of one or
more coverage regions; determine that a region count of the set of
one or more coverage regions satisfies a region count threshold;
responsive to determining that the region count of the set of one
or more coverage regions satisfies the region count threshold,
determine a morphing portion for each coverage region in the set of
one or more coverage regions; and morph the set of one or more
coverage regions associated with the set of one or more second
regionalized servers based on[[ the]] corresponding morphing
portions.
16. The system of claim 15, wherein: the topology modification of
the geographical area includes one of: a creation of the target
coverage region for the first regionalized server, the first
regionalized server being initiated; and an expansion of a first
coverage region associated with the first regionalized server to
the target coverage region; and determining the morphing portion of
a coverage region of the set of one or more coverage regions to
include an area where the coverage region associated with a second
regionalized server overlaps with the target coverage region of the
first regionalized server.
17. The system of claim 16, wherein to morph the set of one or more
coverage regions associated with the set of one or more second
regionalized servers includes: reducing the coverage region
associated with the second regionalized server to exclude the
morphing portion corresponding to the coverage region; transmitting
data associated with the morphing portion from the second
regionalized server to the first regionalized server; and
instructing a plurality of vehicles located within the morphing
portion to communicate with the first regionalized server.
18. The system of claim 15, wherein: the topology modification of
the geographical area includes one of: an elimination of a first
coverage region associated with the first regionalized server, the
first regionalized server being removed; and a reduction of the
first coverage region associated with the first regionalized server
to the target coverage region; and determining the set of one or
more coverage regions in the geographical area includes:
determining a difference region between the first coverage region
associated with the first regionalized server and the target
coverage region; and determining that a resource amount of the set
of one or more second regionalized servers satisfies a resource
amount to accommodate a plurality of vehicles located within the
set of one or more coverage regions associated with the set of one
or more second regionalized servers and the difference region.
19. The system of claim 18, wherein to determine the morphing
portion for each coverage region in the set of one or more coverage
regions includes: determining, from the difference region, a
morphing portion for a coverage region associated with a second
regionalized server based on a resource amount of the second
regionalized server and a traffic condition in the difference
region.
20. The system of claim 19, wherein to morph the set of one or more
coverage regions associated with the set of one or more second
regionalized servers includes: expanding the coverage region
associated with the second regionalized server to include the
morphing portion corresponding to the coverage region; transmitting
data associated with the morphing portion from the first
regionalized server to the second regionalized server; and
instructing a plurality of vehicles located within the morphing
portion to communicate with the second regionalized server.
21. The system of claim 15, wherein the instructions, when executed
by the one or more processors, further cause the system to:
determine that the region count of the set of one or more coverage
regions does not satisfy the region count threshold; responsive to
determining that the region count of the set of one or more
coverage regions does not satisfy the region count threshold,
determine, from the first regionalized server and the set of one or
more second regionalized servers, a set of one or more third
regionalized servers based on the topology modification of the
geographical area; determine a set of one or more third coverage
regions in the geographical area for the set of one or more third
regionalized servers; and respectively assign the set of one or
more third coverage regions to the set of one or more third
regionalized servers.
22. The system of claim 21, wherein to determine the set of one or
more third coverage regions in the geographical area includes:
determining a third coverage region for a third regionalized server
based on a resource amount of the third regionalized server and a
traffic condition in the third coverage region.
23. The system of claim 21, wherein the instructions, when executed
by the one or more processors, further cause the system to:
classify the first regionalized server and the set of one or more
second regionalized servers into one or more physical regionalized
servers and one or more virtual regionalized servers; initiate one
or more temporary virtual regionalized servers corresponding to the
one or more physical regionalized servers; transmit data associated
with each physical regionalized server to a temporary virtual
regionalized server corresponding to the physical regionalized
server; and responsive to respectively assigning the set of one or
more third coverage regions to the set of one or more third
regionalized servers, transmit, from the one or more virtual
regionalized servers and the one or more temporary virtual
regionalized servers, data associated with each third coverage
region to a third regionalized server associated with the third
coverage region.
24. The system of claim 23, wherein the instructions, when executed
by the one or more processors, further cause the system to:
responsive to transmitting the data associated with each third
coverage region to the third regionalized server associated with
the third coverage region, instruct a plurality of vehicles located
within the third coverage region associated with the third
regionalized server to communicate with the third regionalized
server; and remove the one or more temporary virtual regionalized
servers.
25. The system of claim 15, wherein the topology modification of
the geographical area is associated with a trigger event, the
trigger event including one or more of: a change of roadway
condition, a change of traffic condition, and a change of traffic
condition reflected in a traffic pattern of a road segment in the
geographical area; an implementation of a vehicle application that
is temporarily accessible in an application accessible area within
the geographical area; and an unavailability of a regionalized
server associated with a coverage region in the geographical
area.
26. The system of claim 15, wherein to determine the topology
modification for the geographical area includes: determining a road
segment in the geographical area that has a vehicle density of the
road segment satisfying a vehicle density threshold; and
determining the target coverage region for the first regionalized
server based on the road segment.
27. The system of claim 15, wherein to determine the topology
modification for the geographical area includes: determining an
application accessible area for a vehicle application temporarily
implemented on the first regionalized server; and determining the
target coverage region for the first regionalized server based on
the application accessible area of the vehicle application.
28. The system of claim 15, wherein to determine the topology
modification for the geographical area includes: estimating a
number of vehicles that are accommodatable by the first
regionalized server based on a resource amount of the first
regionalized server and operation requirements of a vehicle
application; determining a vehicle density of a road segment that
includes a first coverage region associated with the first
regionalized server; and determining the target coverage region for
the first regionalized server based on the number of vehicles that
are accommodatable by the first regionalized server and the vehicle
density of the road segment.
29. A method comprising: detecting a traffic trigger event
associated with a geographical area, the geographical area
including a set of one or more coverage regions that are
respectively associated with a set of one or more regionalized
servers; determining a topology modification for the geographical
area based on a traffic condition associated with the traffic
trigger event; and modifying a coverage region topology of the
geographical area based on the topology modification by one or more
of: creating an additional coverage region for the geographical
area and associating the additional coverage region with an
additional regionalized server; and morphing one or more coverage
regions in the set of one or more coverage regions.
30. The method of claim 29, wherein: the traffic trigger event
includes one or more of a change of roadway condition, a change of
traffic condition, and a change of traffic condition reflected in a
traffic pattern of a road segment in the geographical area; and the
traffic condition associated with the traffic trigger event
includes one or more of a vehicle density, a traffic flow rate, an
average vehicle speed, and an average following distance associated
with the road segment.
31. The method of claim 29, wherein: determining the topology
modification for the geographical area includes determining a
target coverage region in the geographical area for a first
regionalized server based on the traffic condition associated with
the traffic trigger event; and modifying the coverage region
topology of the geographical area based on the topology
modification includes modifying the coverage region topology by one
or more of: creating the target coverage region in the geographical
area and associating the target coverage region with the first
regionalized server, the first regionalized server being initiated;
morphing a first coverage region associated with the first
regionalized server into the target coverage region; and
eliminating the first coverage region associated with the first
regionalized server, the first regionalized server being
removed.
32. The method of claim 31, further comprising: determining, from
the set of one or more coverage regions associated with the set of
one or more regionalized servers, a set of one or more second
coverage regions that are adjacent to the target coverage region of
the first regionalized server, the set of one or more second
coverage regions being respectively associated with a set of one or
more second regionalized servers; and morphing the set of one or
more second coverage regions associated with the set of one or more
second regionalized servers based on the target coverage region of
the first regionalized server.
33. The method of claim 31, wherein determining the target coverage
region in the geographical area for the first regionalized server
based on the traffic condition associated with the traffic trigger
event includes one or more of: determining the target coverage
region for the first regionalized server based on a road segment in
the geographical area that has a vehicle density of the road
segment satisfying a vehicle density threshold; and determining the
target coverage region for the first regionalized server based on a
number of vehicles that are accommodatable by the first
regionalized server and a vehicle density of a road segment that
includes the first coverage region associated with the first
regionalized server.
Description
BACKGROUND
[0001] The present disclosure relates to server management. In a
more particular example, the disclosure relates managing
regionalized vehicular communication.
[0002] Today, some modern computing systems rely on servers to
provide vehicle applications to vehicles. However, in these
computing systems, the areas covered by the servers usually cannot
be adjusted while the traffic condition in these areas often
drastically change over time. As a result, a server assigned to a
particular area may not have sufficient computational resources to
provide the vehicle applications to a large number of vehicles
located within its coverage area in heavy traffic condition.
[0003] On the other hand, the computational resources of the server
may not be efficiently utilized when the traffic in the area
covered is low. In addition, as the area of the server is generally
fixed, the data received from the vehicles located within the area
of the area may be irrelevant or inadequate for the vehicle
applications implemented on the server to accurately operate given
the specific traffic condition. Furthermore, it is generally
impractical or impossible for these existing solutions to flexibly
provide a particular vehicle application to the vehicles located
within a specific area during a certain time period, because the
areas of the servers on which the vehicle application can be
implemented typically remain unchanged.
SUMMARY
[0004] The subject matter described in this disclosure overcomes
the deficiencies and limitations of the existing solutions by
providing novel technology for efficiently managing electronic
vehicular communication.
[0005] According to one innovative aspect of the subject matter
described in this disclosure, a computer-implemented method
comprises: determining a topology modification for a geographical
area; determining a set of one or more coverage regions in the
geographical area that are adjacent to a target coverage region,
the target coverage region being associated with a first
regionalized server configured to communicate with vehicular
traffic in the target coverage region, the set of one or more
coverage regions being respectively associated with a set of one or
more second regionalized servers, each second regionalized server
of the set of one or more second regionalized servers being
configured to communicate with vehicular traffic in a corresponding
coverage region of the set of one or more coverage regions;
determining that a region count of the set of one or more coverage
regions satisfies a region count threshold; responsive to
determining that the region count of the set of one or more
coverage regions satisfies the region count threshold, determining
a morphing portion for each coverage region in the set of one or
more coverage regions; and morphing the set of one or more coverage
regions associated with the set of one or more second regionalized
servers based on the corresponding morphing portions.
[0006] In general, another innovative aspect of the subject matter
described in this disclosure may be embodied in
computer-implemented methods comprising: detecting a traffic
trigger event associated with a geographical area, the geographical
area including a set of one or more coverage regions that are
respectively associated with a set of one or more regionalized
servers; determining a topology modification for the geographical
area based on a traffic condition associated with the traffic
trigger event; modifying a coverage region topology of the
geographical area based on the topology modification by one or more
of creating an additional coverage region for the geographical area
and associating the additional coverage region with an additional
regionalized server, and morphing one or more coverage regions in
the set of one or more coverage regions.
[0007] In general, another innovative aspect of the subject matter
described in this disclosure may be embodied in systems comprising:
one or more processors; and one or more memories storing
instructions that, when executed by the one or more processors,
cause the system to: determine a topology modification for a
geographical area; determine a set of one or more coverage regions
in the geographical area that are adjacent to a target coverage
region, the target coverage region being associated with a first
regionalized server configured to communicate with vehicular
traffic in the target coverage region, the set of one or more
coverage regions being respectively associated with a set of one or
more second regionalized servers, each second regionalized server
of the set of one or more second regionalized servers being
configured to communicate with vehicular traffic in a corresponding
coverage region of the set of one or more coverage regions;
determine that a region count of the set of one or more coverage
regions satisfies a region count threshold; responsive to
determining that the region count of the set of one or more
coverage regions satisfies the region count threshold, determine a
morphing portion for each coverage region in the set of one or more
coverage regions; and morph the set of one or more coverage regions
associated with the set of one or more second regionalized servers
based on the corresponding morphing portions.
[0008] These and other implementations may each optionally include
one or more of the following features: that the topology
modification of the geographical area includes a creation of the
target coverage region for the first regionalized server, the first
regionalized server being initiated, or an expansion of a first
coverage region associated with the first regionalized server to
the target coverage region, and determining the morphing portion of
a coverage region of the set of one or more coverage regions to
include an area where the coverage region associated with a second
regionalized server overlaps with the target coverage region of the
first regionalized server; that morphing the set of one or more
coverage regions associated with the set of one or more second
regionalized servers includes reducing the coverage region
associated with the second regionalized server to exclude the
morphing portion corresponding to the coverage region, transmitting
data associated with the morphing portion from the second
regionalized server to the first regionalized server, and
instructing a plurality of vehicles located within the morphing
portion to communicate with the first regionalized server; that the
topology modification of the geographical area includes an
elimination of a first coverage region associated with the first
regionalized server, the first regionalized server being removed,
or a reduction of the first coverage region associated with the
first regionalized server to the target coverage region, and
determining the set of one or more coverage regions in the
geographical area includes determining a difference region between
the first coverage region associated with the first regionalized
server and the target coverage region, and determining that a
resource amount of the set of one or more second regionalized
servers satisfies a resource amount to accommodate a plurality of
vehicles located within the set of one or more coverage regions
associated with the set of one or more second regionalized servers
and the difference region; that determining the morphing portion
for each coverage region in the set of one or more coverage regions
includes determining, from the difference region, a morphing
portion for a coverage region associated with a second regionalized
server based on a resource amount of the second regionalized server
and a traffic condition in the difference region; that morphing the
set of one or more coverage regions associated with the set of one
or more second regionalized servers includes expanding the coverage
region associated with the second regionalized server to include
the morphing portion corresponding to the coverage region,
transmitting data associated with the morphing portion from the
first regionalized server to the second regionalized server, and
instructing a plurality of vehicles located within the morphing
portion to communicate with the second regionalized server; that
determining that the region count of the set of one or more
coverage regions does not satisfy the region count threshold,
responsive to determining that the region count of the set of one
or more coverage regions does not satisfy the region count
threshold, determining, from the first regionalized server and the
set of one or more second regionalized servers, a set of one or
more third regionalized servers based on the topology modification
of the geographical area, determining a set of one or more third
coverage regions in the geographical area for the set of one or
more third regionalized servers, and respectively assigning the set
of one or more third coverage regions to the set of one or more
third regionalized servers; that determining the set of one or more
third coverage regions in the geographical area includes
determining a third coverage region for a third regionalized server
based on a resource amount of the third regionalized server and a
traffic condition in the third coverage region; that classifying
the first regionalized server and the set of one or more second
regionalized servers into one or more physical regionalized servers
and one or more virtual regionalized servers, initiating one or
more temporary virtual regionalized servers corresponding to the
one or more physical regionalized servers, transmitting data
associated with each physical regionalized server to a temporary
virtual regionalized server corresponding to the physical
regionalized server, and responsive to respectively assigning the
set of one or more third coverage regions to the set of one or more
third regionalized servers, transmitting, from the one or more
virtual regionalized servers and the one or more temporary virtual
regionalized servers, data associated with each third coverage
region to a third regionalized server associated with the third
coverage region; that responsive to transmitting the data
associated with each third coverage region to the third
regionalized server associated with the third coverage region,
instructing a plurality of vehicles located within the third
coverage region associated with the third regionalized server to
communicate with the third regionalized server, and removing the
one or more temporary virtual regionalized servers; that the
topology modification of the geographical area is associated with a
trigger event, the trigger event including one or more of a change
of roadway condition, a change of traffic condition, and a change
of traffic condition reflected in a traffic pattern of a road
segment in the geographical area, an implementation of a vehicle
application that is temporarily accessible in an application
accessible area within the geographical area, and an unavailability
of a regionalized server associated with a coverage region in the
geographical area; that determining the topology modification for
the geographical area includes determining a road segment in the
geographical area that has a vehicle density of the road segment
satisfying a vehicle density threshold, and determining the target
coverage region for the first regionalized server based on the road
segment; that determining the topology modification for the
geographical area includes determining an application accessible
area for a vehicle application temporarily implemented on the first
regionalized server, and determining the target coverage region for
the first regionalized server based on the application accessible
area of the vehicle application; that determining the topology
modification for the geographical area includes estimating a number
of vehicles that are accommodatable by the first regionalized
server based on a resource amount of the first regionalized server
and operation requirements of a vehicle application, determining a
vehicle density of a road segment that includes a first coverage
region associated with the first regionalized server, and
determining the target coverage region for the first regionalized
server based on the number of vehicles that are accommodatable by
the first regionalized server and the vehicle density of the road
segment.
[0009] These and other implementations may each optionally include
one or more of the following features: that the traffic trigger
event includes one or more of a change of roadway condition, a
change of traffic condition, and a change of traffic condition
reflected in a traffic pattern of a road segment in the
geographical area, and the traffic condition associated with the
traffic trigger event includes one or more of a vehicle density, a
traffic flow rate, an average vehicle speed, an average following
distance associated with the road segment; that determining the
topology modification for the geographical area includes
determining a target coverage region in the geographical area for a
first regionalized server based on the traffic condition associated
with the traffic trigger event, and modifying the coverage region
topology of the geographical area based on the topology
modification includes modifying the coverage region topology by one
or more of creating the target coverage region in the geographical
area and associating the target coverage region with the first
regionalized server, the first regionalized server being initiated,
morphing a first coverage region associated with the first
regionalized server into the target coverage region, and
eliminating the first coverage region associated with the first
regionalized server, the first regionalized server being removed;
that determining, from the set of one or more coverage regions
associated with the set of one or more regionalized servers, a set
of one or more second coverage regions that are adjacent to the
target coverage region of the first regionalized server, the set of
one or more second coverage regions being respectively associated
with a set of one or more second regionalized servers, and morphing
the set of one or more second coverage regions associated with the
set of one or more second regionalized servers based on the target
coverage region of the first regionalized server; that determining
the target coverage region in the geographical area for the first
regionalized server based on the traffic condition associated with
the traffic trigger event includes one or more of determining the
target coverage region for the first regionalized server based on a
road segment in the geographical area that has a vehicle density of
the road segment satisfying a vehicle density threshold, and
determining the target coverage region for the first regionalized
server based on a number of vehicles that are accommodatable by the
first regionalized server and a vehicle density of a road segment
that includes a first coverage region associated with the first
regionalized server.
[0010] Other implementations of one or more of these and other
aspects include corresponding systems, apparatus, and computer
programs, configured to perform the actions of methods, encoded on
non-transitory computer storage devices.
[0011] The novel technology for managing coverage regions of
regionalized servers presented in this disclosure is particularly
advantageous in a number of respects. For example, the technology
described herein is capable of dynamically morphing or
re-establishing the coverage regions of the regionalized servers
based on the traffic condition in the coverage regions. Thus, as
the traffic condition changes over time, the coverage regions
associated with the regionalized servers may be dynamically
adjusted and/or redefined so that the regionalized servers may have
sufficient computational resources to provide vehicle applications
to the vehicles located within their corresponding coverage
regions. As a result, the efficiency in utilizing the computational
resources of the regionalized servers can be significantly
improved. As a further example, the present technology is capable
of morphing or re-establishing the coverage area of the
regionalized server based on the traffic condition so that the data
received from multiple vehicles located within the coverage region
may be relevant and/or adequate to facilitate the operation of the
vehicle applications implemented on the regionalized server,
thereby improving the accuracy and efficiency of these vehicle
applications. In addition, the technology described herein can
morph or re-establish the coverage regions of the regionalized
servers to dynamically and temporarily allocate a specific region
to a particular regionalized server during a certain time period.
Therefore, the present technology can flexibly implement one or
more vehicle applications on the particular regionalized server
during this time period, and thus these vehicle applications can be
provided to the vehicles located within the specific region
associated with the particular regionalized server on a temporary
basis as needed.
[0012] It should be understood that the foregoing advantages are
provided by way of example and that the technology may have
numerous other advantages and benefits.
[0013] The disclosure is illustrated by way of example, and not by
way of limitation in the figures of the accompanying drawings in
which like reference numerals are used to refer to similar
elements.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] FIG. 1 is a block diagram of an example system for managing
regionalized vehicular communication.
[0015] FIG. 2 is a block diagram of an example region management
application.
[0016] FIG. 3 is a flowchart of an example method for managing the
coverage regions of the regionalized servers.
[0017] FIGS. 4A and 4B illustrate flowcharts of example methods for
morphing the coverage region of the regionalized server.
[0018] FIG. 5 is a flowchart of an example method for
re-establishing the coverage regions of the regionalized
servers.
[0019] FIG. 6A illustrates an example geographical area.
[0020] FIGS. 6B-6D illustrates example coverage regions.
[0021] FIGS. 7A-7E illustrate examples of the coverage regions
associated with the regionalized servers being morphed.
[0022] FIGS. 8A-8C illustrate examples of the coverage regions
associated with the regionalized servers being re-established.
DESCRIPTION
[0023] The technology described herein can effectively manage
electronic data received from vehicles in different traffic
regions. As described in further detail below, the technology
includes various aspects, such as region management methods,
systems, computing devices, computer program products, and
apparatuses, among other aspects.
[0024] As described in the Background, it is challenging for a
central cloud server to manage data communication for vehicular
networks in a large geographical area. The technology described
herein advantageously addresses this issue with a hierarchical
server architecture. The architecture may include a central server
(which may comprise one or more centralized or distributed physical
and/or virtual server(s)) and regionalized servers. The term
central may, in some embodiments, refer to server(s) that manages,
coordinates and/or instructs other network nodes, such as
regionalized server(s), communication-enabled mobility platforms,
etc., based on rules, logic, data being received, data that is
needed, etc.
[0025] A regionalized server may locally serve the vehicles in
smaller regions of the geographical area, thereby improving the
vehicle-server communication. For example, the regionalized server
may provide vehicle applications to the vehicles located within its
corresponding region. However, while a central server often has a
massive amount of computational resources (e.g., commensurate with
a larger server farm, large data center, etc.) and is generally
always available, the regionalized server often has a comparatively
limited amount of computational resources and may not always be
available. Therefore, in order to flexibly provide vehicle
applications to the vehicles in various regions of the geographical
area, these regions may need to he managed to efficiently be served
by the regionalized servers or the central server.
[0026] The technology described herein is advantageously capable of
dynamically changing the coverage regions covered by the
regionalized servers based on the application requirements the
available computational resources of the regionalized servers and
the central server, the vehicle-server connections, etc. The
changes in the coverage regions of the regionalized servers may be
triggered by the resource availability of the regionalized servers,
the application requirements of the vehicle application, the
implementation of new vehicle applications, the traffic density,
the road conditions, etc.
[0027] In some embodiments, a central server may optimize the
coverage regions of the regionalized servers based on their
availability and resource capacity. The central server may
instantiate new virtual regionalized servers if needed. The central
server may then further adjust or redefine the coverage regions of
the regionalized servers based on various factors, e.g., the
traffic history, the road types, the traffic density, etc. The new
coverage regions being formed may then be communicated to the
regionalized servers and the vehicles to adapt their server-vehicle
communication accordingly.
[0028] An example region management system may determine a topology
modification for a geographical area. The topology modification may
reflect a target coverage region to be covered by a first
regionalized server. As the target coverage region is covered by a
first regionalized server, the first regionalized server can
communicate with the vehicular traffic in the target coverage
region. In some embodiments, the region management system may morph
a first coverage region associated with the first regionalized
server into the target coverage region of the first regionalized
server.
[0029] In some embodiments, the region management system may
determine a set of second coverage regions in the geographical area
that are adjacent to the target coverage region of the first
regionalized server. The set of second coverage regions may be
respectively associated with a set of second regionalized servers,
and thus each second regionalized server may communicate with the
vehicular traffic in its corresponding second coverage region. The
region management system may determine whether a region count of
the set of second coverage regions satisfies a region count
threshold. If the region count of the set of second coverage
regions satisfies the region count threshold, the region management
system may determine a morphing portion for each second coverage
region in the set of second coverage regions, and morph the set of
second coverage regions associated with the set of second
regionalized servers based on the corresponding morphing portions.
If the region count of the set of second coverage regions does not
satisfy the region count threshold, the region management system
may determine a set of third regionalized servers based on the
topology modification of the geographical area, determine a set of
third coverage regions in the geographical area for the set of
third regionalized servers, and respectively assign the set of
third coverage regions to the set of third regionalized
servers.
[0030] FIG. 1 is a block diagram of an example system 100 for
managing coverage regions of regionalized servers. As shown, the
system 100 includes a management server 101, one or more vehicle
platforms 103a . . . 103n, and one or more regionalized servers
107a . . . 107n. The management server 101, the one or more vehicle
platforms 103a . . . 103n, and the one or more regionalized servers
107a . . . 107n may be coupled for electronic communication via a
network 105. In FIG. 1 and the remaining figures, a letter after a
reference number, e.g., "103a," represents a reference to the
element having that particular reference number. A reference number
in the text without a following letter, e.g., "103," represents a
general reference to instances of the element bearing that
reference number. It should be understood that the system 100
depicted in FIG. 1 is provided by way of example and the system 100
and/or further systems contemplated by this present disclosure may
include additional and/or fewer components, may combine components
and/or divide one or more of the components into additional
components, etc. For example, the system 100 may include any number
of vehicle platforms 103, regionalized servers 107, networks 105,
or management servers 101.
[0031] The network 105 may be a conventional type, wired and/or
wireless, and may have numerous different configurations including
a star configuration, token ring configuration, or other
configurations. For example, the network 105 may include one or
more local area networks (LAN), wide area networks (WAN) (e.g., the
Internet), personal area networks (PAN), public networks, private
networks, virtual networks, virtual private networks, peer-to-peer
networks, near-field networks (e.g., Bluetooth.RTM., NFC, etc.),
vehicular networks, and/or other interconnected data paths across
which multiple devices may communicate.
[0032] The network 105 may also be coupled to or include portions
of a telecommunications network for sending data in a variety of
different communication protocols. Example protocols include, but
are not limited to, transmission control protocol/Internet protocol
(TCP/IP), user datagram protocol (UDP), transmission control
protocol (TCP), hypertext transfer protocol (HTTP), secure
hypertext transfer protocol (HTTPS), dynamic adaptive streaming
over HTTP (DASH), real-time streaming protocol (RTSP), real-time
transport protocol (RTP) and the real-time transport control
protocol (RTCP), voice over Internet protocol (VOIP), file transfer
protocol (FTP), WebSocket (WS), wireless access protocol (WAP),
various messaging protocols (SMS, MMS, XMS, IMAP, SMTP, POP,
WebDAV, etc.), or other suitable protocols. In some embodiments,
the network 105 is a wireless network using a connection such as
DSRC (Dedicated Short Range Communication), WAVE, 802.11p, a 3G,
4G, 5G+ network, WiFi.TM., satellite networks, vehicle-to-vehicle
(V2V) networks, vehicle-to-infrastructure/infrastructure-to-vehicle
(V2I/I2V) networks, vehicle-to-infrastructure/vehicle-to-everything
(V2I/V2X) networks, or any other wireless networks. Although FIG. 1
illustrates a single block for the network 105 that couples to the
management server 101, the vehicle platform(s) 103, and the
regionalized server(s) 107, it should be understood that the
network 105 may in practice comprise any number of combination of
networks, as noted above.
[0033] The vehicle platform(s) 103 include computing device(s) 152
having sensor(s) 113, processor(s) 115, memory(ies) 117,
communication unit(s) 119, a vehicle data store 123, a region
management application 120, and a navigation application 122.
Examples of computing device(s) 152 may include virtual or physical
computer processors, control units, micro-controllers, etc., which
are coupled to other components of the vehicle platform(s) 103,
such as one or more sensors 113, actuators, motivators, etc. The
vehicle platform(s) 103 may be coupled to the network 105 via
signal line 156, and may send and receive data to and from other
vehicle platform(s) 103, the regionalized server(s) 107, and/or the
management server(s) 101. In some embodiments, the vehicle
platform(s) 103 may be temporarily coupled to one or more of the
regionalized servers 107 as the vehicle platform(s) 103 travel
along the roads. For example, the vehicle platform 103 may send and
receive data to and from the regionalized server(s) 107 as the
vehicle platform 103 is located within the coverage region that is
managed by the regionalized server(s) 107, and thus the
regionalized server(s) 107 may provide one or more vehicle
applications implemented on the regionalized server(s) 107 to the
vehicle platform 103. In some embodiments, the vehicle platform(s)
103 are capable of transporting from one point to another.
Non-limiting examples of the vehicle platform(s) 103 include a
vehicle, an automobile, a bus, a boat, a plane, a bionic implant, a
robot, or any other platforms with non-transitory computer
electronics (e.g., a processor, a memory or any combination of
non-transitory computer electronics). The vehicle platform(s) 103
may be referred to herein as vehicle(s).
[0034] The processor(s) 115 may execute software instructions
(e.g., tasks) by performing various input/output, logical, and/or
mathematical operations. The processor(s) 115 may have various
computing architectures to process data signals. The processor(s)
115 may be physical and/or virtual, and may include a single core
or plurality of processing units and/or cores. In the context of
the vehicle platform 103, the processor may be an electronic
control unit (ECU) implemented in the vehicle platform 103 such as
a car, although other types of platform are also possible and
contemplated. The ECUs may receive and store the sensor data as
vehicle operation data in the vehicle data store 123 for access
and/or retrieval by the region management application 120, the
navigation application 122, and/or other vehicle applications. In
some implementations, the processor(s) 115 may be capable of
generating and providing electronic display signals to the
input/output device(s), capturing and transmitting images,
performing complex tasks including various types of data analysis
and coverage region management, etc. In some implementations, the
processor(s) 115 may be coupled to the memory(ies) 117 via the bus
154 to access data and instructions therefrom and store data
therein. The bus 154 may couple the processor(s) 115 to the other
components of the vehicle platform(s) 103 including, for example,
the sensor(s) 113, the memory(ies) 117, the communication unit(s)
119, and/or the vehicle data store 123.
[0035] The region management application 120 is computer logic
executable to manage coverage regions of regionalized servers. As
illustrated in FIG. 1, the management server 101 may include the
instance 120a, the vehicle platform 103a . . . 103n may include the
instances 120b . . . 120m, and the regionalized servers 107a . . .
107n may include the instances 120c . . . 120n of the region
management application 120. In some embodiments, each instance
120a, 120b . . . 120m, and 120c . . . 120n may comprise one or more
components the region management application 120 depicted in FIG.
2, and may be configured to fully or partially perform the
functionalities described herein depending on where the instance
resides. In some embodiments, the region management application 120
may be implemented using software executable by one or more
processors of one or more computer devices, using hardware, such as
but not limited to a field-programmable gate array (FPGA), an
application-specific integrated circuit (ASIC), etc., and/or a
combination of hardware and software, etc. The region management
application 120 may receive and process the vehicle data, the
server data, etc., and may communicate with other elements of the
vehicle platform 103 via the bus 154, such as the memory 117, the
communication unit 119, the vehicle data store 123, etc. The region
management application 120 is described in details below with
reference to at least FIGS. 2-8C.
[0036] The navigation application 122 is computer logic executable
to provide navigational guidance to the user of the vehicle
platform 103. As illustrated in FIG. 1, the management server 101
may include the instance 122a, the vehicle platform 103a . . . 103n
may include the instances 122b . . . 122m, and the regionalized
servers 107a . . . 107n may include the instances 122c . . . 122n
of the navigation application 122. In some embodiments, the
navigation application 122 may be implemented using software
executable by one or more processors of one or more computer
devices, using hardware, such as but not limited to a
field-programmable gate array (FPGA), an application-specific
integrated circuit (ASIC), etc., and/or a combination of hardware
and software, etc. In some embodiments, the navigation application
122 may determine one or more vehicle routes to a destination,
generate navigation instructions corresponding to each vehicle
route, and provide the navigation instructions of the vehicle route
selected or followed by the user via the input/output device of the
vehicle platform 103. In some embodiments, the navigation
application 122 may perform path planning to determine one or more
driving maneuvers for the user of the vehicle platform 103 to
follow the vehicle route, and provide driving instructions
describing the driving maneuvers via the input/output device of the
vehicle platform 103.
[0037] In some embodiments, the navigation application 122 may
analyze the data received from multiple vehicle platforms 103 to
determine driving context, and determine optimal vehicle route
and/or optimal driving maneuvers for the vehicle platform 103
accordingly. Thus, as the coverage regions of the regionalized
servers 107 are efficiently managed by the region management
application 120, the navigation application 122 can collect
sufficient relevant data from the vehicle platforms 103 located
within a coverage region of a regionalized server 107, and thus the
accuracy of its operation can be significantly improved. It should
be understood that in addition to the navigation application 122,
the vehicle platforms 103, the regionalized servers 107, and/or the
management server 101 may also implement other vehicle applications
that rely on the data collected from the vehicle platforms 103
located within a coverage region of a regionalized server 107 to
perform their operations (e.g., vehicle sharing application, road
scene modeling application, etc.) in which the coverage regions of
the regionalized servers 107 are managed by the region management
application 120.
[0038] The memory(ies) 117 includes a non-transitory
computer-usable (e.g., readable, writeable, etc.) medium, which can
be any tangible non-transitory apparatus or device that can
contain, store, communicate, propagate or transport instructions,
data, computer programs, software, code, routines, etc., for
processing by or in connection with the processor(s) 115. For
example, the memory(ies) 117 may store the region management
application 120 and/or the navigation application 122. In some
implementations, the memory(ies) 117 may include one or more of
volatile memory and non-volatile memory. For example, the
memory(ies) 117 may include, but is not limited to, one or more of
a dynamic random access memory (DRAM) device, a static random
access memory (SRAM) device, a discrete memory device (e.g., a
PROM, FPROM, ROM), a hard disk drive, an optical disk drive (CD,
DVD, Blue-ray.TM., etc.). It should be understood that the
memory(ies) 117 may be a single device or may include multiple
types of devices and configurations.
[0039] The communication unit 119 transmits data to and receives
data from other computing devices to which it is communicatively
coupled (e.g., via the network 105) using wireless and/or wired
connections. The communication unit 119 may include one or more
wired interfaces and/or wireless transceivers for sending and
receiving data. The communication unit 119 may couple to the
network 105 and communicate with other entities of the system 100,
such as other vehicle platform(s) 103, management server(s) 101,
and/or regionalized server(s) 107 associated with the coverage
region in which the vehicle platform 103 is located, etc. The
communication unit 119 may exchange data with other computing nodes
using standard communication methods, such as those discussed
above.
[0040] The sensor(s) 113 includes any type of sensors suitable for
the vehicle platform(s) 103. The sensor(s) 113 may be configured to
collect any type of signal data suitable to determine
characteristics of the vehicle platform 103 and/or its internal and
external environments. Non-limiting examples of the sensor(s) 113
include various optical sensors and/or image sensors (CCD, CMOS,
2D, 3D, light detection and ranging (LIDAR), cameras, etc.), audio
sensors, motion detection sensors, barometers, altimeters,
thermocouples, moisture sensors, infrared (IR) sensors, radar
sensors, other photo sensors, gyroscopes, accelerometers,
speedometers, steering sensors, braking sensors, switches, vehicle
indicator sensors, windshield wiper sensors, geo-location sensors
(e.g., Global Positioning System (GPS) sensors), orientation
sensor, wireless transceivers (e.g., cellular, WiFi.TM.,
near-field, etc.), sonar sensors, ultrasonic sensors, touch
sensors, proximity sensors, distance sensors, etc. In some
embodiments, one or more sensors 113 may include externally facing
sensors provided at the front side, rear side, right side, and/or
left side of the vehicle platform 103 in order to capture the
situational context surrounding the vehicle platform 103.
[0041] The vehicle data store 123 includes a non-transitory storage
medium that stores various types of data. For example, the vehicle
data store 123 may store vehicle data being communicated between
different components of a given vehicle platform 103 using a bus,
such as a controller area network (CAN) bus. In some embodiments,
the vehicle data may include vehicle operation data collected from
multiple sensors 113 coupled to different components of the vehicle
platform 103 for monitoring operating states of these components,
e.g., the vehicle speed, the vehicle acceleration/deceleration
rate, the wheel speed (Revolutions Per Minute--RPM), the steering
angle, the braking force, etc. In some embodiments, the vehicle
data may also include the vehicle location (e.g., GPS coordinates)
indicating the geographic location of the vehicle platform 103, the
moving direction of the vehicle platform 103, the vehicle route
currently followed by the vehicle platform 103 to get to a
destination, etc.
[0042] In some embodiments, the vehicle data store 123 may store
roadway data describing the roadway structure and the roadway
condition of various road segments. In some embodiments, the
roadway data associated with a road segment may include one or more
roadway attributes of the road segment. Non-limiting examples of
the roadway attributes include, but are not limited to, the roadway
type (e.g., freeway, city street, etc.), the roadway geometry
(e.g., the shape and size of the roadway, the road curvature, the
road grade, etc.), the roadway status (e.g., road closure, road
construction, etc.), the number of lanes, the lane type (e.g.,
carpool lane, exit lane, merging lane, etc.), the lane status
(e.g., lane closure, open lane, etc.), the number of intersections,
the traffic light position, the speed limit, etc., of the road
segment. In some embodiments, the vehicle platform 103 may analyze
the sensor data captured by the sensors 113 as the vehicle platform
103 travel along the road segment, and determine the roadway data
associated with the road segment based on the sensor data. Other
types of roadway data are also possible and contemplated.
[0043] In some embodiments, the vehicle data store 123 may store
traffic data describing the traffic condition on various road
segments. In some embodiments, the traffic data associated with a
road segment may include one or more traffic attributes of the road
segment. Non-limiting examples of the traffic attributes include,
but are not limited to, the vehicle density indicating the number
of vehicles present on a predefined distance of the road segment
(e.g., 40 vehicles/km), the traffic flow rate indicating the number
of vehicles passing a static point on the road segment in a
predefined time period (e.g., 4000 vehicles/h), the average vehicle
speed of the vehicles travelling on the road segment (e.g., 100
km/h), the average following distance between the vehicles
travelling on the road segment (e.g., 15 m), etc. In some
embodiments, the traffic data associated with the road segment may
also include the traffic pattern describing the traffic condition
on the road segment at various time of day. In some embodiments,
the vehicle platform 103 may analyze the sensor data captured by
the sensors 113 as the vehicle platform 103 travel along the road
segment, and determine the traffic data associated with the road
segment based on the sensor data. Other types of traffic data are
also possible and contemplated.
[0044] In some embodiments, the vehicle data store 123 may store
application data of one or more vehicle applications that are
implemented on the management server 101 and/or the regionalized
servers 107 and provided to the vehicle platform 103. In some
embodiments, as the vehicle application is provided to the vehicle
platform 103 by the management server 101 and/or by the
regionalized server 107 associated with the coverage region in
which the vehicle platform 103 is located, the vehicle platform 103
may send and receive the application data of the vehicle
application (e.g., application request, application execution data,
application response data, etc.) to and from the management server
101 and/or the regionalized server 107. In some embodiments, the
vehicle platform 103 may also periodically transmit to the
management server 101 and/or the regionalized server 107 other
types of data associated with the vehicle platform 103 (e.g., the
vehicle data, the roadway data, the traffic data, etc.).
[0045] In some embodiments, the vehicle data store 123 may store
trigger data describing the trigger events that trigger the
adjustment or re-establishment of the coverage regions of the
regionalized servers 107. In some embodiments, the trigger events
may include traffic trigger events and server trigger events.
Non-limiting examples of the traffic trigger events include, but
are not limited to, a change of roadway condition, a change of
traffic condition, a change of traffic condition reflected in the
traffic pattern of the road segment, etc. Non-limiting examples of
the server trigger events include, but are not limited to, an
implementation of a vehicle application to be temporarily
accessible within an application accessible area, a regionalized
server associated with a coverage region becomes unavailable, etc.
Other types of trigger events are also possible and
contemplated.
[0046] In some embodiments, the vehicle data store 123 may store
one or more coverage region topologies of one or more geographical
areas. The coverage region topology of each geographical area may
describe one or more coverage regions in the geographical area, and
specify the regionalized server(s) 107 associated with each
coverage region. In some embodiments, for each coverage region in
the geographical area, the coverage region topology may indicate
the region shape (e.g., ellipse, circle, rectangular, etc.), the
region size (e.g., ellipse axes, circle diameter, rectangular
dimensions, etc.), the region location (e.g., GPS coordinates),
etc., of the coverage region. In some embodiments, the coverage
region topology of the geographical area may be updated as the
coverage regions of the regionalized servers 107 in the
geographical area are adjusted and/or redefined.
[0047] In some embodiments, the vehicle data store 123 may be part
of a data storage system (e.g., a standard data or database
management system) for storing and providing access to data. Other
types of data stored in the vehicle data store 123 are also
possible and contemplated.
[0048] The regionalized server 107 includes a hardware and/or
virtual server that includes a processor, a memory, and network
communication capabilities (e.g., a communication unit). As
depicted, the regionalized server 107 may be communicatively
coupled to the vehicle platforms 103 located within its coverage
region, the management server 101, and/or other entities of the
system 100 via the network 105 as reflected by signal line 160. In
some embodiments, the regionalized server 107 may be a physical
regionalized server 107. The physical regionalized server 107 may
be implemented in a computing infrastructure (e.g., a roadside
unit, a telco node, etc.) as a stationary regionalized server 107,
or implemented in a vehicle platform 103 as a movable regionalized
server 107. In some embodiments, the regionalized server 107 may be
a virtual regionalized server 107. The virtual regionalized server
107 may reside in one or more physical regionalized servers 107,
the management server 101, and/or any physical computing
entity(ies) of the system 100.
[0049] In some embodiments, the regionalized server 107 may be
associated with a coverage region within a geographical area. Thus,
the coverage region may be covered by the regionalized server 107,
and the regionalized server 107 may communicate with vehicular
traffic in this coverage region. As the regionalized server 107 may
communicate with the vehicular traffic in this coverage region, the
regionalized server 107 may send and receive data to and from the
vehicle platforms 103 located within the coverage region, and thus
the regionalized server 107 can provide the vehicle applications
implemented on the regionalized server 107 to these vehicle
platforms 103. In some embodiments, the physical regionalized
servers 107 and/or the physical computing entities on which the
virtual regionalized servers 107 reside may be located at a lower
distance from the geographical areas as compared to the management
server 101. This implementation is advantageous because the
communication delay between the vehicle platforms 103 located in
the geographical areas and these regionalized servers 107 can be
reduced.
[0050] In some embodiments, the regionalized server 107 may be
associated with multiple coverage regions, these coverage regions
may be in the same geographical area or in different geographical
areas. As an example, a physical regionalized server 107 may be
associated with a first coverage region, and may host a virtual
regionalized server 107 associated with a second coverage region.
Thus, the physical regionalized server 107 may be considered as
being associated with the first coverage region and the second
coverage region. As another example, a regionalized server 107 may
implement a vehicle application that does not rely on the traffic
data to operate. Therefore, the regionalized server 107 may be
associated with multiple coverage regions to provide the vehicle
application to the vehicle platforms 103 located within these
coverage regions, even if the traffic in these coverage regions may
not be relevant or may not impact one another.
[0051] In some embodiments, a coverage region in the geographical
area may be associated with multiple regionalized server 107. As an
example, multiple vehicle platforms 103 located within the coverage
region at a particular timestamp may perform the functionalities of
multiple movable regionalized server 107. These movable
regionalized server 107 may collaboratively cover the coverage
region, and provide the vehicle applications implemented on these
movable regionalized server 107 to the vehicle platforms 103
located within the coverage region at the particular timestamp. In
this present disclosure, the region management method and system
may be described with the embodiments in which one coverage region
is associated with one regionalized server 107 to simplify the
description. However, it should be understood that one coverage
region may be associated with one or more regionalized servers 107,
and one regionalized server 107 may be associated with one or more
coverage regions as discussed above. The coverage region(s)
associated with a regionalized server 107 may be referred to herein
as the coverage region(s) of the regionalized server 107.
[0052] As depicted in FIG. 1, the regionalized server 107 may
include an instance 120c of the region management application 120,
an instance 122b of the navigation application 122 and a
regionalized server data store 126 that stores various types of
data for access and/or retrieval by these applications. In some
embodiments, the regionalized server data store 126 includes a
non-transitory storage medium that stores application data of one
or more vehicle applications implemented on the regionalized server
107, and the regionalized server 107 may provide these vehicle
applications to the vehicle platforms 103 located within its
coverage region. Non-limiting examples of the application data of
the vehicle application include, but are not limited to, executable
file, data file, input data, output data, data format, data size,
average execution time, etc., of the vehicle application. In some
embodiments, the application data may also include the operation
requirement describing the requirements to execute an application
request associated with the vehicle application. In some
embodiments, the operation requirement of the vehicle application
may specify the resource amount required to execute the application
request (e.g., the amount of computing resource, the amount of data
storage resource, the amount of memory resource, the amount of
communication resource, etc.). The operation requirement of the
vehicle application may also specify the server configuration
required to implement the vehicle application (e.g., Central
Processing Unit (CPU), Graphic Processing Unit (GPU), etc.). Other
types of application data of the vehicle application are also
possible and contemplated.
[0053] In some embodiments, the regionalized server data store 126
may store server operation data of the regionalized server 107. The
server operation data may include one or more server parameters
describing the server operation of the regionalized server 107, the
server resource data describing the computational resources of the
regionalized server 107, etc. In some embodiments, the server
resource data may indicate the total resource amount of the
regionalized server 107 and the available resource amount of the
regionalized server 107 at multiple timestamps. For each timestamp,
the available resource amount may indicate the amount of available
computing resource (e.g., number of available CPU cycles), the
amount of available data storage resource (e.g., capacity of free
storage space), the amount of available memory resource (e.g.,
capacity of free memory space), the amount of available
communication resource (e.g., unoccupied communication bandwidth),
etc., of the regionalized server 107 at the timestamp.
[0054] In some embodiments, the regionalized server data store 126
may store various types of data received from the vehicle platforms
103. In some embodiments, the regionalized server 107 may receive
the vehicle data, the roadway data, the traffic data, the
application data, etc., from multiple vehicle platforms 103 located
within its coverage region, and store the received data in the
regionalized server data store 126. As discussed elsewhere herein,
the vehicle applications implemented on the regionalized server 107
(e.g., the navigation application 122, etc.) may use the data
received from multiple vehicle platforms 103 located within the
coverage region of the regionalized server 107 to execute the
application requests for these vehicle platforms 103, thereby
improving the accuracy and efficiency of these vehicle
applications. In some embodiments, the regionalized server 107 may
transmit the data received from multiple vehicle platforms 103
located within its coverage region to the management server 101.
The data received from a vehicle platform 103 may be referred to
herein as the data associated with the vehicle platform 103.
[0055] In some embodiments, the regionalized server data store 126
may store the roadway data describing the roadway structure and the
roadway condition of various road segments in the coverage region
of the regionalized server 107. In some embodiments, the
regionalized server 107 may analyze the data associated with the
vehicle platforms 103 located within its coverage region, and
extract or determine the roadway data of these road segments based
on the data associated with these vehicle platforms 103. In some
embodiments, the regionalized server 107 may receive the roadway
data of the road segments in its coverage region from the
management server 101 and/or a third-party server (e.g.,
Transportation Department).
[0056] In some embodiments, the regionalized server data store 126
may store the traffic data describing the traffic condition of
various road segments in the coverage region of the regionalized
server 107. In some embodiments, the regionalized server 107 may
analyze the data associated with the vehicle platforms 103 located
within its coverage region, and extract or determine the traffic
data of these road segments based on the data associated with these
vehicle platforms 103. The regionalized server 107 may also analyze
the data associated with the vehicle platforms 103, and determine
the traffic pattern of these road segments at various time of day.
In some embodiments, the regionalized server 107 may receive the
traffic data and/or the traffic pattern of the road segments in its
coverage region from the management server 101.
[0057] In some embodiments, the regionalized server data store 126
may store the trigger data describing the trigger events that
trigger the adjustment or re-establishment of the coverage regions
of the regionalized servers 107. As discussed elsewhere herein, the
trigger events may include the traffic trigger events and the
server trigger events. In some embodiments, the regionalized server
data store 126 may also store the coverage region topology of the
geographical area that includes the coverage region of the
regionalized server 107. As discussed elsewhere herein, the
coverage region topology of the geographical area may describe one
or more coverage regions in the geographical area, and specify the
regionalized server(s) 107 associated with each coverage
region.
[0058] The management server 101 includes a hardware and/or virtual
server that includes a processor, a memory, and network
communication capabilities (e.g., a communication unit). In some
embodiments, the management server 101 may be a computing server
located remotely from the geographical areas. For example, the
management server 101 may be a cloud server residing in a data
center. The management server 101 may be communicatively coupled to
the network 105, as reflected by signal line 158. In some
embodiments, the management server 101 may send and receive data to
and from other entities of the system 100, e.g., the regionalized
servers 107, the vehicle platforms 103, etc. via the network 105.
As depicted, the management server 101 may include an instance 120a
of the region management application 120, an instance 122a of the
navigation application 122, and a management server data store 124
that stores various types of data for access and/or retrieval by
these applications.
[0059] In some embodiments, the management server data store 124
includes a non-transitory storage medium that stores geographical
area data associated with one or more geographical areas. In some
embodiments, each geographical area may include one or more
coverage regions, each coverage regions may be associated with one
or more regionalized servers 107 as discussed elsewhere herein. In
some embodiments, for each geographical area, the management server
data store 124 may store the coverage region topology describing
the coverage regions in the geographical area and specifying the
regionalized server(s) 107 associated with each coverage region.
The management server data store 124 may also store the server
operation data describing the server operation and the
computational resources of the regionalized server(s) 107
associated with each coverage region.
[0060] In some embodiments, the management server data store 124
may store data associated with multiple vehicle platforms 103. The
management server 101 may receive the data associated with the
vehicle platform 103 from the vehicle platform 103 and/or from the
regionalized server 107 associated with the coverage region in
which the vehicle platform 103 is located, and store the data
associated with the vehicle platform 103 in the management server
data store 124. As discussed elsewhere herein, the data associated
with the vehicle platform 103 may include the vehicle data, the
roadway data, the traffic data, the application data, etc.,
received from the vehicle platform 103.
[0061] In some embodiments, for each geographical area, the
management server data store 124 may store the roadway data
describing the roadway structure and the roadway condition of
various road segments in the geographical area. In some
embodiments, the management server 101 may analyze the data
associated with the vehicle platforms 103 located within the
geographical area, and extract or determine the roadway data of
these road segments based on the data associated with these vehicle
platforms 103. In some embodiments, the management server 101 may
receive the roadway data of the road segments in the geographical
area from a third-party server (e.g., Transportation
Department).
[0062] In some embodiments, for each geographical area, the
management server data store 124 may store the traffic data
describing the traffic condition of various road segments in the
geographical area. In some embodiments, the management server 101
may analyze the data associated with the vehicle platforms 103
located within the geographical area, and extract or determine the
traffic data of these road segments based on the data associated
with these vehicle platforms 103. The management server 101 may
also analyze the data associated with the vehicle platforms 103,
and determine the traffic pattern of these road segments at various
time of day.
[0063] In some embodiments, the management server data store 124
may store application data of various vehicle applications
implemented on the management server 101 and/or the regionalized
servers 107 to provide to the vehicle platforms 103 (e.g.,
navigation application 122, etc.). As discussed elsewhere herein,
the application data may include the operation requirement of the
vehicle application. In some embodiments, the management server
data store 124 may also store the trigger data describing the
trigger events that trigger the adjustment or re-establishment of
the coverage regions of the regionalized servers 107. As discussed
elsewhere herein, the trigger events may include the traffic
trigger events and the server trigger events. In some embodiments,
the management server data store 124 may also store event data
describing various public events in the geographical areas. In some
embodiments, for each public event, the event data may include the
event type (e.g., parade, sport game, etc.), the event location
(e.g., Rio Tinto Stadium), the event capacity (e.g., 10,000
attendees), the event start time, the event end time, etc., of the
public event. Other types of event data are also possible and
contemplated.
[0064] Other variations and/or combinations are also possible and
contemplated. It should be understood that the system 100
illustrated in FIG. 1 is representative of an example system and
that a variety of different system environments and configurations
are contemplated and are within the scope of the present
disclosure. For instance, various acts and/or functionality may be
moved from a server to a client, or vice versa, data may be
consolidated into a single data store or further segmented into
additional data stores, and some implementations may include
additional or fewer computing devices, services, and/or networks,
and may implement various functionality client or server-side.
Further, various entities of the system may be integrated into a
single computing device or system or divided into additional
computing devices or systems, etc.
[0065] FIG. 2 is a block diagram of an example region management
application 120. As depicted, the region management application 120
may include an event detector 202, a topology processor 204, and a
coverage region manager 206, although it should be understood that
the region management application 120 may include additional
components such as, but not limited to, a configuration engine, a
training engine, an encryption/decryption engine, etc., and/or
these various components may be combined into a single engine or
divided into additional engines. The event detector 202, the
topology processor 204, and the coverage region manager 206 may be
implemented as software, hardware, or a combination of the
foregoing. In some embodiments, the event detector 202, the
topology processor 204, and the coverage region manager 206 may be
communicatively coupled by the bus 154 and/or the processor 115 to
one another and/or to the other components of the computing device
152. In some embodiments, one or more of the components 120, 202,
204, and/or 206 are sets of instructions executable by the
processor 115 to provide their functionality. In further
embodiments, one or more of the components 120, 202, 204, and/or
206 are storable in the memory 117 and are accessible and
executable by the processor 115 to provide their functionality. In
any of the foregoing embodiments, these components 120, 202, 204,
and/or 206 may be adapted for cooperation and communication with
the processor 115 and other components of the computing device 152.
The region management application 120 and its components 202, 204,
206 are described in further detail below with reference to at
least FIGS. 3-8C.
[0066] As discussed elsewhere herein, the region management
application 120 is computer logic executable to manage the coverage
regions of regionalized servers 107 in a geographical area. An
example geographical area 600 is illustrated in FIG. 6A. As
depicted, the geographical area 600 may be a predefined area and
may include one or more coverage regions. In some embodiments, the
topology processor 204 may determine the coverage regions for the
geographical area based on the roadway structure and/or the traffic
pattern of various road segments in the geographical area. For
example, as depicted in FIG. 6A, the topology processor 204 may
create a coverage region 602 covering a portion of the freeway 1-15
due to the heavy traffic on this road segment, a coverage region
604 covering an interchange between the freeway 1-15 and the
freeway 215, etc. As depicted, the coverage regions may be
positioned across the geographical area 600 and may have different
shape and size. In some embodiments, two or more coverage regions
may be located adjacent to one another and may share a portion of
their region boundary. In this case, these two or more coverage
regions may be considered as being continuously adjacent to one
another (e.g., the coverage regions 610 and 612; the coverage
regions 620, 622, and 624). In some embodiments, two or more
coverage regions may be located adjacent to one another but may not
share any portion of their region boundary. In this case, these two
or more coverage regions may be considered as being discontinuously
adjacent to one another (e.g., the coverage regions 612 and 614;
the coverage regions 616 and 618). As depicted in FIG. 6A, the
coverage region may cover a road segment (e.g., the coverage
regions 612, 614, 618, 620, 622) and/or a residential area (e.g.,
the coverage regions 616, 624, 626).
[0067] In some embodiments, each coverage region in the
geographical area may be associated with a regionalized server 107,
the regionalized server 107 associated with the coverage region may
be configured to communicate with the vehicular traffic in the
coverage region. For example, the regionalized server 107 may send
and receive data to and from the vehicle platforms 103 located
within the coverage region, and provide vehicle applications
implemented on the regionalized server 107 to these vehicle
platforms 103. Although the region management application 120 is
described below with the embodiments in which each coverage region
is associated with one regionalized server 107 to simplify the
description, it should be understood that each coverage region may
be associated with one or more regionalized servers 107, and each
regionalized server 107 may be associated with one or more coverage
regions as discussed elsewhere herein.
[0068] FIGS. 6B-6D illustrates other example coverage regions of
other geographical areas. FIG. 6B depicts a geographical area 632
and a geographical area 634. In this example, each geographical
area may include one coverage region that covers the entire
geographical area, and each coverage region may be associated with
one regionalized server 107. FIG. 6C depicts a geographical area
650 including the coverage regions 652, 654, 656, 658 that cover
various road segments. In this example, the coverage regions 652,
654, 656, 658 may be determined based on the traffic condition of
the corresponding road segment, and each coverage region may be
associated with one regionalized server 107. FIG. 6D depicts a
residential area 670 of a geographical area. In this example, the
residential area 670 may include multiple road segments with
relatively low traffic. Therefore, the residential area 670 may be
covered by one coverage region, and the coverage region may be
associated with one regionalized server 107.
[0069] FIG. 3 is a flowchart of an example method 300 for managing
the coverage regions of the regionalized servers 107 in a
geographical area. In some embodiments, the geographical area may
initially include a set of coverage regions that are respectively
associated with a set of regionalized servers 107. In this present
disclosure, a set of coverage regions may include one or more
coverage regions, and a set of regionalized servers 107 may include
one or more regionalized servers 107.
[0070] In block 302, the event detector 202 may detect a trigger
event associated with the geographical area, the trigger event may
be a traffic trigger event or a server trigger event that triggers
the adjustment or the re-establishment of the coverage regions in
the geographical area. In some embodiments, to detect the traffic
trigger event, the event detector 202 may monitor the roadway data
of various road segments in the geographical area, and detect the
traffic trigger event based on the roadway data. In some
embodiments, the event detector 202 may analyze the roadway data of
a road segment, and determine whether the roadway attribute of the
road segment has changed (e.g., the roadway status of the road
segment has changed from "open road" to "road construction," the
lane status of a traffic lane in the road segment has changed from
"lane closure" to "open lane," etc.). If the roadway attribute of
the road segment has changed, the event detector 202 may determine
the traffic trigger event to be a change of roadway condition, and
determine the road segment to be the road segment associated with
the traffic trigger event.
[0071] In some embodiments, the event detector 202 may monitor the
traffic data of various road segments in the geographical area, and
detect the traffic trigger event based on the traffic data. In some
embodiments, the event detector 202 may analyze the traffic data of
a road segment, and determine whether the traffic attribute of the
road segment has satisfied the corresponding traffic attribute
threshold (e.g., the vehicle density of the road segment is higher
than 180 vehicles/km, the traffic flow rate of the road segment is
lower than 20 vehicles/hour, etc.). If the traffic attribute of the
road segment has satisfied the corresponding traffic attribute
threshold, the event detector 202 may determine the traffic trigger
event to be a change of traffic condition, and determine the road
segment to be the road segment associated with the traffic trigger
event. In some embodiments, the event detector 202 may analyze the
traffic pattern of the road segment, and determine that the traffic
pattern of the road segment indicates a change of traffic condition
at a particular timestamp (e.g., the vehicle density of the road
segment usually increases above 150 vehicles/km at 5 pm on
weekdays). Thus, at the particular timestamp, the event detector
202 may determine the traffic trigger event to be a change of
traffic condition that is reflected in the traffic pattern of the
road segment.
[0072] In some embodiments, the event detector 202 may analyze the
traffic pattern of various the road segments in a coverage region
of a regionalized server 107, and determine that the traffic
pattern of these road segments indicates low traffic in the
coverage region of the regionalized server 107 during a time window
(e.g., the vehicle density of these road segments is usually lower
than 15 vehicles/km between lam and 5 am). Thus, at the start
timestamp of the time window, the event detector 202 may determine
the traffic trigger event to be the low traffic condition in the
coverage region of the regionalized server 107 during the time
window. Other implementations for detecting the traffic trigger
event are also possible and contemplated.
[0073] In some embodiments, to detect the server trigger event, the
event detector 202 may monitor the server operation data of the
regionalized servers 107 associated with various coverage regions
in the geographical area, and detect the server trigger event based
on the server operation data. In some embodiments, the event
detector 202 may analyze the server operation data of a
regionalized server 107, and determine whether the server parameter
of the regionalized server 107 has satisfied the corresponding
parameter threshold (e.g., the task execution time is higher than
20 ms, etc.). If the server parameter of the regionalized server
107 has satisfied the corresponding parameter threshold, the event
detector 202 may determine that the regionalized server 107 has
become temporarily unavailable. Thus, the event detector 202 may
determine the server trigger event to be an unavailability of the
regionalized server 107, and determine the coverage region of the
regionalized server 107 to be the coverage region associated with
the server trigger event.
[0074] In some embodiments, the event detector 202 may determine a
public event based on the event data associated with the
geographical area, and determine that a vehicle application is to
be temporarily implemented on a regionalized server 107 due to the
public event. During a time window associated with the public
event, the regionalized server 107 may provide the vehicle
application to the vehicle platforms 103 located within an
application accessible area associated with the public event. Thus,
the event detector 202 may determine the server trigger event to be
a temporary implementation of the vehicle application on the
regionalized server 107. As an example, to provide parking
assistance for attendees of a hockey game that starts at 6 pm, the
event detector 202 may determine the server trigger event to be a
temporary implementation of a parking application on a regionalized
server 107, the regionalized server 107 may provide the parking
application to the vehicle platforms 103 located within a
predefined distance from the hockey arena (e.g., 750 m) during the
time window between 4 pm and 7 pm. Other implementations for
detecting the server trigger event are also possible and
contemplated.
[0075] In block 304, the topology processor 204 may determine a
topology modification for the geographical area, the topology
modification may reflect a target coverage region for a first
regionalized server 107. In some embodiments, the topology
processor 204 may determine the first regionalized server 107 based
on the trigger event, the first regionalized server 107 may be
initiated, may be removed, or may have its coverage region being
expanded or reduced in response to the trigger event associated
with the geographical area. In some embodiments, the topology
processor 204 may also determine the target coverage region to be
covered by the first regionalized server 107. As the target
coverage region is covered by the first regionalized server 107,
the first regionalized server 107 will be able to communicate and
provide vehicle applications to the vehicular traffic in the target
coverage region. In some embodiments, depending on the trigger
event being detected, the topology processor 204 may determine the
target coverage region for the first regionalized server 107 based
on the traffic condition of the road segment associated with the
traffic trigger event, the resource amount of the first
regionalized server 107, the operation requirement of the vehicle
application implemented on the first regionalized server 107,
and/or the application accessible area of the vehicle application
to be temporarily implemented on the first regionalized server 107,
etc.
[0076] In some embodiments, if the event detector 202 detects the
server trigger event in which a regionalized server 107 has become
unavailable, the topology processor 204 may determine this
regionalized server 107 to be the first regionalized server 107,
the first regionalized server 107 may be associated with a first
coverage region. As the first regionalized server 107 is no longer
available, the topology processor 204 may determine the target
coverage region for the first regionalized server 107 to be zero.
Thus, in this situation, the topology modification of the
geographical area may be the elimination of the first coverage
region associated with the first regionalized server 107 as the
first regionalized server 107 is removed. The first regionalized
server 107 is considered being removed if the first regionalized
server 107 can no longer serve the vehicular platforms 103 in its
first coverage region because the first regionalized server 107 is
unavailable or inactivated. As an example, FIG. 7C depicts a
topology modification from the coverage region topology 740 to the
coverage region topology 742, in which the coverage region 746
associated with the first regionalized server 107 is eliminated as
the first regionalized server 107 is removed.
[0077] In some embodiments, if the event detector 202 detects the
server trigger event in which a vehicle application is to be
temporarily implemented due to a public event, the topology
processor 204 may initiate a first regionalized server 107. The
first regionalized server 107 may be a virtual regionalized server
107 or a physical regionalized server 107. In some embodiments, the
topology processor 204 may determine the target coverage region and
the required resource amount for the first regionalized server 107,
and initiate the first regionalized server 107 based on the target
coverage region and the required resource amount. In some
embodiments, to determine the target coverage region for the first
regionalized server 107, the topology processor 204 may determine
the application accessible area within which the vehicle
application is accessible to the vehicle platforms 103 based on the
event location of the public event, and determine the target
coverage region for the first regionalized server 107 to be the
application accessible area of the vehicle application. In some
embodiments, to determine the required resource amount for the
first regionalized server 107, the topology processor 204 may
estimate a number of vehicle platforms 103 located within the
target coverage region based on the traffic condition of various
road segments in the target coverage region (e.g., the vehicle
density, the traffic flow rate, etc.). The topology processor 204
may then determine the required resource amount for the first
regionalized server 107 based on the number of vehicle platforms
103 located within the target coverage region and the operation
requirement of the vehicle application (e.g., the amount of various
computational resources required to execute an application
request). Thus, in this situation, the topology modification of the
geographical area may be the creation of the target coverage region
associated with the first regionalized server 107 as the first
regionalized server 107 is initiated. As an example, FIG. 7A
depicts a topology modification from the coverage region topology
700 to the coverage region topology 702, in which the coverage
region 708 associated with the first regionalized server 107 is
created as the first regionalized server 107 is newly
initiated.
[0078] In some embodiments, if the event detector 202 detects the
traffic trigger event in which the roadway condition and/or the
traffic condition of a road segment has changed, or detects the
traffic trigger event in which the change of traffic condition is
reflected in the traffic pattern of the road segment, the topology
processor 204 may determine the first regionalized server 107 and
the target coverage region for the first regionalized server 107
based on the traffic condition associated with the traffic trigger
event. In some embodiments, the traffic condition associated with
the traffic trigger event may be the traffic condition of the road
segment associated with the traffic trigger event, and may include
one or more of the vehicle density, the traffic flow rate, the
average vehicle speed, the average following distance, etc., of the
road segment associated with the traffic trigger event.
[0079] In some embodiments, to determine the first regionalized
server 107, the topology processor 204 may determine the
regionalized server 107 that has its coverage region covering at
least a portion of the road segment associated with the traffic
trigger event, and determine this regionalized server 107 to be the
first regionalized server 107, the first regionalized server 107
may be currently associated with a first coverage region.
[0080] In some embodiments, to determine the target coverage region
for the first regionalized server 107, the topology processor 204
may determine the first road segment to be included in the target
coverage region. In some embodiments, the topology processor 204
may determine from the road segment associated with the traffic
trigger event the first road segment that has the vehicle density
of the first road segment satisfying a vehicle density threshold
(e.g., higher than 120 vehicles/km), and determine the target
coverage region for the first regionalized server 107 to include
the first road segment. This implementation is advantageous,
because as the vehicle density of the first road segment satisfies
the vehicle density threshold, the data associated with the vehicle
platforms 103 located on the first road segment may likely be
relevant to one another. Therefore, as the target coverage region
including the first road segment is covered by the first
regionalized server 107, the first regionalized server 107 can
receive relevant data from multiple vehicle platforms 103 located
on the first road segment, and thus the operation of the vehicle
applications implemented on the first regionalized server 107 can
be significantly improved.
[0081] In some embodiments, to determine the first road segment to
be included in the target coverage region, the topology processor
204 may estimate the number of vehicles that are accommodatable by
the first regionalized server 107 based on the resource amount of
the first regionalized server 107 (e.g., the total resource amount)
and the operation requirements of the vehicle application (e.g.,
the required resource amount to execute an application request).
The topology processor 204 may also determine the vehicle density
of the road segment that includes the first coverage region of the
first regionalized server 107 based on the traffic data of the road
segment. In some embodiments, the topology processor 204 may then
determine the first road segment from the road segment based on the
number of vehicles that are accommodatable by the first
regionalized server 107 and the vehicle density of the road
segment, and determine the target coverage region for the first
regionalized server 107 to include the first road segment. As an
example, the topology processor 204 may determine that the first
regionalized server 107 can accommodate 4500 vehicles, and the
vehicle density of the road segment that includes the first
coverage region of the first regionalized server 107 is 150
vehicles/km. In this example, the topology processor 204 may
determine from the road segment the first road segment that has the
length of 30 km to be included in the target coverage region of the
first regionalized server 107.
[0082] In some embodiments, as the first road segment to be covered
by the target coverage region of the first regionalized server 107
is determined, the topology processor 204 may determine the region
shape of the target coverage region. In some embodiments, the
target coverage region for the first regionalized server 107 may
have the same region shape as the first coverage region of the
first regionalized server 107 or a default region shape (e.g.,
ellipse). In some embodiments, the topology processor 204 may
determine the region shape of the target coverage region based on
the roadway structure of the first road segment included in the
target coverage region (e.g., including both freeway section and
ramp section), etc.
[0083] In some embodiments, the topology processor 204 may compare
the target coverage region of the first regionalized server 107 and
the first coverage region of the first regionalized server 107. If
the target coverage region of the first regionalized server 107 is
smaller than the first coverage region of the first regionalized
server 107, the topology processor 204 may determine the topology
modification of the geographical area to be the reduction of the
first coverage region associated with the first regionalized server
107 to the target coverage region. As an example, FIG. 7D depicts a
topology modification from the coverage region topology 760 to the
coverage region topology 762, in which the coverage region 766
associated with the first regionalized server 107 is reduced to the
target coverage region. If the target coverage region of the first
regionalized server 107 is larger than the first coverage region of
the first regionalized server 107, the topology processor 204 may
determine the topology modification of the geographical area to be
the expansion of the first coverage region associated with the
first regionalized server 107 to the target coverage region. As an
example, FIG. 7B depicts a topology modification from the coverage
region topology 720 to the coverage region topology 722, in which
the coverage region 726 associated with the first regionalized
server 107 is expanded to the target coverage region.
[0084] In some embodiments, the topology processor 204 may
determine that the target coverage region of the first regionalized
server 107 is larger than the first coverage region of the first
regionalized server 107 (e.g., to cover the first road segment that
has the vehicle density satisfying the vehicle density threshold),
and also determine that the resource amount of the first
regionalized server 107 (e.g., the total resource amount) does not
satisfy the required resource amount to accommodate the vehicle
platforms 103 located within the target coverage region of the
first regionalized server 107. In some embodiments, the topology
processor 204 may then remove (e.g., inactivate) the first
regionalized server 107, and initiate a replacement regionalized
server 107 to replace the first regionalized server 107. In some
embodiments, the replacement regionalized server 107 may cover the
target coverage region, and may be allocated the resource amount
that satisfies the required resource amount to accommodate the
vehicle platforms 103 located within the target coverage region. As
the first regionalized server 107 is removed, the replacement
regionalized server 107 may now be considered as the first
regionalized server 107. Thus, in this situation, the topology
modification of the geographical area may be the creation of the
target coverage region associated with the first regionalized
server 107 as the first regionalized server 107 is initiated.
[0085] In some embodiments, the topology processor 204 may
determine that the road segment associated with the traffic trigger
event is not covered by any coverage region of the regionalized
servers 107 in the geographical area. The topology processor 204
may then initiate a first regionalized server 107 (e.g., a virtual
regionalized server 107). In some embodiments, the topology
processor 204 may determine the target coverage region of the first
regionalized server 107 to include the road segment associated with
the traffic trigger event. The topology processor 204 may also
allocate to the first regionalized server 107 the resource amount
that satisfies the required resource amount to accommodate the
vehicle platforms 103 located on this road segment. Thus, in this
situation, the topology modification of the geographical area may
be the creation of the target coverage region associated with the
first regionalized server 107 as the first regionalized server 107
is initiated.
[0086] In some embodiments, if the event detector 202 detects the
traffic trigger event in which the traffic pattern indicates a low
traffic condition in a coverage area of a regionalized server 107
during a time window, the topology processor 204 may determine this
regionalized server 107 to be the first regionalized server 107,
the first regionalized server 107 may be associated with the first
coverage region. In some embodiments, the topology processor 204
may inactivate the first regionalized server 107 during the time
window due to the low traffic condition in the first coverage
region. As the first regionalized server 107 is no longer
available, the topology processor 204 may determine the target
coverage region for the first regionalized server 107 to be zero.
Thus, in this situation, the topology modification of the
geographical area may be the elimination of the first coverage
region associated with the first regionalized server 107 as the
first regionalized server 107 is removed. Other implementations for
determining the topology modification of the geographical area are
also possible and contemplated.
[0087] In some embodiments, as the topology modification reflecting
the target coverage region of the first regionalized server 107 is
determined, the topology processor 204 may modify the coverage
region topology of the geographical area based on the topology
modification. In some embodiments, if the first regionalized server
107 is initiated, the topology processor 204 may create the target
coverage region in the coverage region topology of geographical
area and associate the first regionalized server 107 to the target
coverage region. In some embodiments, if the first regionalized
server 107 associated with the first coverage region is removed,
the topology processor 204 may eliminate the first coverage region
of the first regionalized server 107 from the coverage region
topology of the geographical area. In some embodiments, if the
first coverage region of the first regionalized server 107 is
expanded or reduced to the target coverage region of the first
regionalized server 107, the topology processor 204 may morph the
first coverage region of the first regionalized server 107 into the
target coverage region of the first regionalized server 107 in the
coverage region topology of the geographical area.
[0088] In block 306, the coverage region manager 206 may determine
a set of second coverage regions in the geographical area that are
adjacent to the target coverage region of the first regionalized
server 107. In some embodiments, the distance between the second
coverage region in the set of second coverage regions and the
target coverage region of the first regionalized server 107 may
satisfy a distance threshold (e.g., less than 30 km). In some
embodiments, the set of second coverage regions may be respectively
associated with a set of second regionalized servers 107, each
second regionalized server 107 in the set of second regionalized
servers 107 may communicate with the vehicular traffic in its
corresponding coverage region in the set of second coverage
regions. For example, the second regionalized server 107 may send
and receive data to and from the vehicle platforms 103 located
within its coverage region, and provide the vehicle applications
implemented on the second regionalized server 107 to these vehicle
platforms 103.
[0089] In some embodiments, to determine the set of second coverage
regions, if the topology modification of the geographical area is
the creation of the target coverage region associated with the
first regionalized server 107 as the first regionalized server 107
is newly initiated, or the expansion of the first coverage region
associated with the first regionalized server 107 to the target
coverage region of the first regionalized server 107, the coverage
region manager 206 may determine the set of second coverage regions
in which the second coverage region overlaps with the target
coverage region of the first regionalized server 107. In the
example depicted in FIG. 7A in which the coverage region 704 is
created, the coverage region manager 206 may determine the set of
second coverage regions to be the coverage regions 704 and 706. In
the example depicted in FIG. 7B in which the coverage region 704 is
expanded, the coverage region manager 206 may determine the set of
second coverage regions to be the coverage regions 724 and 728.
[0090] In some embodiments, to determine the set of second coverage
regions, if the topology modification of the geographical area is
the elimination of the first coverage region associated with the
first regionalized server 107 as the first regionalized server 107
is removed, or the reduction of the first coverage region
associated with the first regionalized server 107 to the target
coverage region of the first regionalized server 107, the coverage
region manager 206 may determine the difference region between the
first coverage region of the first regionalized server 107 and the
target coverage region of the first regionalized server 107.
[0091] In some embodiments, the coverage region manager 206 may
determine the set of second coverage regions that are adjacent to
the target coverage region of the first regionalized server 107, in
which the set of second regionalized servers 107 associated with
the set of second coverage regions may have the resource amount
(e.g., the total resource amount of the set of second regionalized
servers 107) satisfying the required resource amount to accommodate
1) the vehicle platforms 103 located within the set of second
coverage regions, and 2) the vehicle platforms 103 located within
the difference region. In some embodiments, to determine the
required resource amount to accommodate the vehicle platforms 103
located within these coverage regions, the coverage region manager
206 may estimate a number of vehicle platforms 103 located within
these coverage regions based on the traffic condition of the road
segments in these coverage regions (e.g., the vehicle density, the
traffic flow rate, etc.). The coverage region manager 206 may then
determine the required resource amount based on the number of
vehicle platforms 103 located within these coverage regions and the
operation requirement of the vehicle application (e.g., the amount
of computational resources required to execute an application
request). Continuing the example depicted in FIG. 7C in which the
coverage region 746 is removed, the coverage region manager 206 may
determine the set of second coverage regions to be the coverage
regions 744 and 748. In the example depicted in FIG. 7D in which
the coverage region 766 is reduced, the coverage region manager 206
may determine the set of second coverage regions to be the coverage
regions 764 and 768.
[0092] In some embodiments, the set of second coverage regions that
are adjacent to the target coverage region of the first
regionalized server 107 and have sufficient resource amount to also
accommodate the vehicle platforms 103 in the difference region may
not exist. If the set of second coverage regions does not exist,
the coverage region manager 206 may initiate a third regionalized
server 107 (e.g., a virtual regionalized server 107). In some
embodiments, the coverage region manager 206 may allocate to the
third regionalized server 107 the resource amount that satisfies
the required resource amount to accommodate the vehicle platforms
103 located within the difference region, and assign the third
regionalized server 107 to the difference region. Thus, in this
case, the difference region caused by the elimination or the
reduction of the first coverage region to the target coverage
region of the first regionalized server 107 may be covered by the
third regionalized server 107 that is newly initiated, without
adjusting the second coverage regions adjacent to the target
coverage region of the first regionalized server 107 (if any). As
an example, FIG. 7E depicts a topology modification from the
coverage region topology 780 to the coverage region topology 782,
in which the coverage region 762 associated with the first
regionalized server 107 is reduced to the target coverage region.
In this example, the coverage region manager 206 may initiate an
additional regionalized server 107 to cover the difference region
784.
[0093] In block 308, as the set of second coverage regions
associated with the set of second regionalized servers 107 that are
adjacent to the target coverage region of the first regionalized
server 107 is determined, the coverage region manager 206 may
determine a region count indicating the number of coverage regions
included in the set of second coverage regions, and determine
whether the region count of the set of second coverage regions
satisfies a region count threshold (e.g., less than 2 coverage
regions). If the region count of the set of second coverage regions
satisfies the region count threshold, the coverage region manager
206 may determine that the topology modification that results in
the target coverage region of the first regionalized server 107
only impacts a limited number of second coverage regions, and thus
the coverage region manager 206 may perform a minor topology update
to adjust the set of second coverage regions. To perform the minor
topology update, in block 310, the coverage region manager 206 may
determine a morphing portion for each second coverage region in the
set of second coverage regions based on the target coverage region
of the first regionalized server 107. In block 312, the coverage
region manager 206 may morph the set of second coverage regions
based on their corresponding morphing portions.
[0094] In some embodiments, the coverage region manager 206 may
rely on the topology modification of the geographical area to
perform the minor topology update. As discussed elsewhere herein,
if the topology modification of the geographical area is the
creation of the target coverage region associated with the first
regionalized server 107 as the first regionalized server 107 is
newly initiated, or the expansion of the first coverage region
associated with the first regionalized server 107 to the target
coverage region of the first regionalized server 107, the set of
second coverage regions may include the second coverage regions
that overlap with the target coverage region of the first
regionalized server 107. In some embodiments, for these types of
topology modification, the coverage region manager 206 may
determine the morphing portion for each second coverage region in
the set of second coverage regions to include an overlap area where
the second coverage region associated with the second regionalized
server 107 overlaps with the target coverage region of the first
regionalized server 107. In some embodiments, the coverage region
manager 206 may determine the morphing portion for the second
coverage region to be the overlap area. The coverage region manager
206 may then morph the set of second coverage regions based on
their corresponding morphing portions.
[0095] FIG. 4A is a flowchart of an example method 400 for morphing
the coverage region of the regionalized server 107. In some
embodiments, the coverage region manager 206 may perform the method
400 to morph the set of second coverage regions if the topology
modification of the geographical area is the creation of the target
coverage region associated with the first regionalized server 107
as the first regionalized server 107 is newly initiated, or the
expansion of the first coverage region associated with the first
regionalized server 107 to the target coverage region of the first
regionalized server 107. In some embodiments, for each second
coverage region in the set of second coverage regions that is
associated with a second regionalized server 107 in the set of
second regionalized servers 107, in block 402, the coverage region
manager 206 may reduce the second coverage region associated with
the second regionalized server 107 to exclude the morphing portion
corresponding to the second coverage region. As discussed above,
the morphing portion of the second coverage region may be the
overlap area between the second coverage region of the second
coverage region 107 and the target coverage region of the first
regionalized server 107.
[0096] In block 404, the coverage region manager 206 may retrieve
the data associated with the morphing portion of the second
coverage region from the second regionalized server 107 associated
with the second coverage region and/or the management server 101,
and transmit the data associated with the morphing portion of the
second coverage region to the first regionalized server 107. In
some embodiments, the data associated with the morphing portion may
include the application data of the vehicle applications, the data
associated with the vehicle platforms 103 located within the
morphing portion, and/or other types of data that is necessary to
communicate and provide the vehicle applications to the vehicle
platforms 103 located within the morphing portion. In some
embodiments, the second regionalized server 107 may continue to
communicate and provide the vehicle applications to the vehicle
platforms 103 located within the morphing portion during the minor
topology update. As the data associated with the morphing portion
is transmitted to the first regionalized server 107, the first
regionalized server 107 may begin to cover the morphing portion. In
block 406, the coverage region manager 206 may instruct the vehicle
platforms 103 located within the morphing portion to communicate
with the first regionalized server 107, and the first regionalized
server 107 may provide the vehicle applications to these vehicle
platforms 103.
[0097] As discussed above, the coverage region manager 206 may rely
on the topology modification of the geographical area to perform
the minor topology update. As discussed elsewhere herein, if the
topology modification of the geographical area is the elimination
of the first coverage region associated with the first regionalized
server 107 as the first regionalized server 107 is removed, or the
reduction of the first coverage region associated with the first
regionalized server 107 to the target coverage region of the first
regionalized server 107, the set of second coverage regions may
include the second coverage regions that are adjacent to the target
coverage region of the first regionalized server 107, in which the
set of second regionalized servers 107 associated with the set of
second coverage regions may have sufficient resource amount to
accommodate 1) the vehicle platforms 103 located within the set of
second coverage regions and 2) the vehicle platforms 103 located
within the difference region. In some embodiments, for these types
of topology modification, the coverage region manager 206 may
determine the morphing portion for each second coverage region from
the difference region between the first coverage region the first
regionalized server 107 and the target coverage region of the first
regionalized server 107.
[0098] In some embodiments, to determine the morphing portion for
each second coverage region in the set of second coverage regions
that is associated with a second regionalized server 107 in the set
of second regionalized servers 107, the coverage region manager 206
may estimate the number of vehicles that the second regionalized
server 107 can additionally accommodate based on the resource
amount of the second regionalized server 107 (e.g., the available
resource amount), and the operation requirement of the vehicle
application (e.g., the amount of various computational resources
required to execute an application request). The coverage region
manager 206 may then determine a portion of the difference region
that the second regionalized server 107 can cover based on the
number of vehicles that the second regionalized server 107 can
additionally accommodate, and the traffic condition of various road
segments in the difference region (e.g., the vehicle density, the
traffic flow rate, etc.). The coverage region manager 206 may then
determine this portion of the difference region to be the morphing
portion for the second coverage region associated with the second
regionalized server 107. As an example, the coverage region manager
206 may determine that second regionalized server 107 can
additionally accommodate 1800 vehicles, and the vehicle density of
the road segments in the difference region is 90 vehicles/km. In
this example, the coverage region manager 206 may determine a
portion of the difference region that includes the road segments
with the length of 20 km to be the morphing portion for the second
coverage region associated with the second regionalized server
107.
[0099] FIG. 4B is a flowchart of an example method 450 for morphing
the coverage region of the regionalized server 107. In some
embodiments, the coverage region manager 206 may perform the method
450 to morph the set of second coverage regions if the topology
modification of the geographical area is the elimination of the
first coverage region associated with the first regionalized server
107 as the first regionalized server 107 is removed, or the
reduction of the first coverage region associated with the first
regionalized server 107 to the target coverage region of the first
regionalized server 107. In some embodiments, for each second
coverage region in the set of second coverage regions that is
associated with a second regionalized server 107 in the set of
second regionalized servers 107, in block 452, the coverage region
manager 206 may expand the second coverage region associated with
the second regionalized server 107 to include the morphing portion
corresponding to the second coverage region. As discussed above,
the morphing portion of the second coverage region may be the
portion of the difference region between the first coverage region
the first regionalized server 107 and the target coverage region of
the first regionalized server 107 that the second regionalized
servers 107 can cover.
[0100] In block 454, the coverage region manager 206 may retrieve
the data associated with the morphing portion of the second
coverage region from the first regionalized server 107 and/or the
management server 101, and transmit the data associated with the
morphing portion of the second coverage region to the second
regionalized server 107 associated with the second coverage region.
As discussed elsewhere herein, the data associated with the
morphing portion may include the application data of the vehicle
applications, the data associated with the vehicle platforms 103
located within the morphing portion, and/or other types of data
that is necessary to communicate and provide the vehicle
applications to the vehicle platforms 103 located within the
morphing portion. In some embodiments, the first regionalized
server 107 and/or the management server 101 may continue to
communicate and provide the vehicle applications to the vehicle
platforms 103 located within the morphing portion during the minor
topology update. As the data associated with the morphing portion
is transmitted to the second regionalized server 107, the second
regionalized server 107 may begin to cover the morphing portion. In
block 456, the coverage region manager 206 may instruct the vehicle
platforms 103 located within the morphing portion to communicate
with the second regionalized server 107, and the second
regionalized server 107 may provide the vehicle applications to
these vehicle platforms 103.
[0101] In some embodiments, the coverage region manager 206 may
update the coverage region topology of the geographical area to
indicate the target coverage region covered by the first
regionalized server 107 and the set of second coverage regions
covered by the set of second regionalized servers 107 that are
morphed based on the target coverage region. The coverage region
manager 206 may then transmit the updated coverage region topology
of the geographical area to the regionalized servers 107 associated
with the coverage regions in the geographical area and the vehicle
platforms 103. In some embodiments, the regionalized servers 107
and the vehicle platforms 103 may adjust the communication between
the regionalized servers 107 and the vehicle platforms 103 based on
the updated coverage region topology of the geographical area. In
some embodiments, the regionalized server 107 may reference the
updated coverage region topology of the geographical area to
determine its coverage region, and communicate and provide the
vehicle applications to the vehicle platforms 103 located within
its coverage region. The coverage region of the regionalized server
107 may lie within the communication range of the regionalized
server 107 but have different shape and/or size. In some
embodiments, the vehicle platform 103 may reference the updated
coverage region topology of the geographical area to determine the
coverage region within which the vehicle platform 103 is located,
and communicate with the regionalized server 107 associated with
this coverage region. If the vehicle platform 103 is not located
within any coverage regions associated with the regionalized
servers 107 in the geographical area, the vehicle platform 103 may
communicate with the management server 101.
[0102] Referring back to FIG. 3, if in block 308, the coverage
region manager 206 determines that the number of coverage regions
included in the set of second coverage regions does not satisfy the
region count threshold (e.g., less than 2 coverage regions), the
coverage region manager 206 may determine that the topology
modification that results in the target coverage region of the
first regionalized server 107 impacts a relatively large number of
second coverage regions, and thus the coverage region manager 206
may perform a major topology update. To perform the major topology
update, the coverage region manager 206 may determine a set of
existing regionalized servers 107 from the first regionalized
server 107 and the set of second regionalized servers 107. The set
of existing regionalized servers 107 may include one or more
regionalized server 107 among the first regionalized server 107 and
the set of second regionalized servers 107 that exist prior to the
topology modification of the geographical area. In some
embodiments, if the topology modification of the geographical area
is the creation of the target coverage region associated with the
first regionalized server 107 as the first regionalized server 107
is newly initiated, the coverage region manager 206 may determine
the set of existing regionalized servers 107 to include the set of
second regionalized servers 107. In some embodiments, if the
topology modification of the geographical area is the expansion of
the first coverage region associated with the first regionalized
server 107 to the target coverage region of the first regionalized
server 107, the reduction of the first coverage region associated
with the first regionalized server 107 to the target coverage
region of the first regionalized server 107, or the elimination of
the first coverage region associated with the first regionalized
server 107 as the first regionalized server 107 is removed, the
coverage region manager 206 may determine the set of existing
regionalized servers 107 to include the first regionalized server
107 and the set of second regionalized servers 107.
[0103] In block 320, the coverage region manager 206 may determine
a set of third regionalized servers 107 from the first regionalized
server 107 and the set of second regionalized servers 107. The set
of third regionalized servers 107 may include one or more
regionalized servers 107 among the first regionalized server 107
and the set of second regionalized servers 107 that exist as a
result of the topology modification. In some embodiments, the
coverage region manager 206 may determine the set of third
regionalized servers 107 based on the topology modification of the
geographical area. In some embodiments, if the topology
modification of the geographical area is the creation of the target
coverage region associated with the first regionalized server 107
as the first regionalized server 107 is newly initiated, the
expansion of the first coverage region associated with the first
regionalized server 107 to the target coverage region of the first
regionalized server 107, or the reduction of the first coverage
region associated with the first regionalized server 107 to the
target coverage region of the first regionalized server 107, the
coverage region manager 206 may determine the set of third
regionalized servers 107 to include the first regionalized server
107 and the set of second regionalized servers 107. In some
embodiments, if the topology modification of the geographical area
is the elimination of the first coverage region associated with the
first regionalized server 107 as the first regionalized server 107
is removed, the coverage region manager 206 may determine the set
of third regionalized servers 107 to include the set of second
regionalized servers 107.
[0104] As an example, FIG. 8A depicts a topology modification from
the coverage region topology 800 to the coverage region topology
802, in which the coverage region 812 associated with the first
regionalized server 107 is created as the first regionalized server
107 is newly initiated. In this example, the set of existing
regionalized servers 107 may include the set of second regionalized
servers 107 associated with the coverage region 804, 806,808, 810,
and the set of third regionalized servers 107 may include the first
regionalized server 107 and the set of second regionalized servers
107. FIG. 8B depicts a topology modification from the coverage
region topology 830 to the coverage region topology 832, in which
the coverage region 842 associated with the first regionalized
server 107 is expanded to the target coverage region. In this
example, the set of existing regionalized servers 107 and the set
of third regionalized servers 107 may both include the first
regionalized server 107 associated with the coverage region 842 and
the set of second regionalized servers 107 associated with the
coverage region 834, 836, 838, 840. FIG. 8C depicts a topology
modification from the coverage region topology 860 to the coverage
region topology 862, in which the coverage region 870 associated
with the first regionalized server 107 is eliminated as the first
regionalized server 107 is removed. In this example, the set of
existing regionalized servers 107 may include the first
regionalized server 107 associated with the coverage region 870 and
the set of second regionalized servers 107 associated with the
coverage region 868, 866, 868, 872, and the set of third
regionalized servers 107 may include the set of second regionalized
servers 107.
[0105] In block 322, the coverage region manager 206 may determine
a set of third coverage regions in the geographical area for the
set of third regionalized servers 107. In some embodiments, if the
set of third regionalized servers 107 includes the first
regionalized server 107, the coverage region manager 206 may
determine the third coverage region for the first regionalized
server 107 to be the target coverage region of the first
regionalized server 107. As discussed above, the set of third
regionalized servers 107 may include the set of second regionalized
servers 107. In some embodiments, the coverage region manager 206
may determine the third coverage region for each second
regionalized server 107 in a manner similar to determining the
target coverage region for the first regionalized server 107 as
discussed in details with reference to block 304 of FIG. 3.
[0106] Thus, as discussed in details with reference to block 304 of
FIG. 3, the coverage region manager 206 may determine the third
coverage region for the third regionalized server 107 in the set of
third regionalized servers 107 (e.g., the first regionalized server
107 (if included) and the second regionalized servers 107) based on
the resource amount of the third regionalized server 107, the
operation requirement of the vehicle application implemented on the
third regionalized server 107, the traffic condition of the road
segments in the third coverage region, etc. For example, the
coverage region manager 206 may determine the third coverage region
for the third regionalized server 107 to include the road segment
that has the vehicle density of the road segment satisfying the
vehicle density threshold, the road segment that the third
regionalized server 107 has sufficient resource amount to
accommodate the vehicle platforms 103 located on the road segment,
the road segment where a vehicle application implemented on the
third regionalized server 107 is temporarily accessible to the
vehicle platforms 103 located on the road segment, etc. In block
324, the coverage region manager 206 may respectively assign the
set of third coverage regions to the set of third regionalized
servers 107.
[0107] In some embodiments, as the set of third coverage regions is
determined and respectively assigned to the set of third
regionalized servers 107, the coverage region manager 206 may
re-establish the coverage regions associated with the set of
existing regionalized servers 107 to form the set of third coverage
regions associated with the set of third regionalized servers 107.
FIG. 5 is a flowchart of an example method 500 for re-establishing
the coverage regions of the regionalized servers 107. In block 502,
the coverage region manager 206 may classify the set of existing
regionalized servers 107 into one or more physical regionalized
servers 107 and one or more virtual regionalized servers 107. As
discussed above, the set of existing regionalized servers 107 may
include the set of second regionalized servers 107 and/or the first
regionalized server 107.
[0108] In block 504, for each physical regionalized server 107, the
coverage region manager 206 may initiate a temporary virtual
regionalized server 107 corresponding to the physical regionalized
server 107. The temporary virtual regionalized server 107 may
reside at the management server 101. In block 506, the coverage
region manager 206 may transmit the data associated with each
physical regionalized server 107 to the temporary virtual
regionalized server 107 corresponding to the physical regionalized
server 107. In some embodiments, the data associated with each
physical regionalized server 107 may include the application data
of the vehicle applications, the data associated with the vehicle
platforms 103 located within the coverage region of the physical
regionalized server 107, and/or other types of data that is
necessary to communicate and provide the vehicle applications to
the vehicle platforms 103 located within the coverage region of the
physical regionalized server 107. In some embodiments, the coverage
region manager 206 may also implement on the temporary virtual
regionalized server 107 the vehicle applications implemented on the
corresponding the physical regionalized server 107.
[0109] In some embodiments, during the major topology update, the
physical regionalized server 107 may continue to receive data from
the vehicle platforms 103 located within its coverage region, and
relay this data to the corresponding temporary virtual regionalized
server 107. Thus, the temporary virtual regionalized server 107 may
execute application requests and provide the vehicle applications
to the vehicle platforms 103 located within the coverage region of
the physical regionalized server 107 during the major topology
update. During the major topology update, the virtual regionalized
server 107 may also continue to receive data and provide the
vehicle applications to the vehicle platforms 103 located within
its coverage region. This implementation is advantageous because it
avoids interrupting the operation of the vehicle applications
provided by the set of existing regionalized servers 107 to the
vehicle platforms 103 located within their coverage regions.
[0110] In block 508, responsive to respectively assigning the set
of third coverage regions to the set of third regionalized servers
107, the coverage region manager 206 may retrieve the data
associated with each third coverage region from the virtual
regionalized server 107 and/or the temporary virtual regionalized
server 107 corresponding to the physical regionalized server 107,
and transmit the data associated with each third coverage region to
the third regionalized server 107 associated with the third
coverage region. In some embodiments, the data associated with the
third coverage region may include the application data of the
vehicle applications, the data associated with the vehicle
platforms 103 located within the third coverage region, and/or
other types of data that is necessary to communicate and provide
the vehicle applications to the vehicle platforms 103 located
within the third coverage region. The data associated with each
third coverage region may be retrieved from the virtual
regionalized servers 107 and/or the temporary virtual regionalized
servers 107 that covered at least a portion of the third coverage
region during the major topology update.
[0111] In some embodiments, as the data associated with each third
coverage region is transmitted to the third regionalized server 107
associated with the third coverage region, the third regionalized
server 107 may begin to cover the third coverage region. Thus, the
coverage region manager 206 may instruct the vehicle platforms 103
located within the third coverage region to communicate with the
third regionalized server 107, and the third regionalized server
107 may provide the vehicle applications to these vehicle platforms
103. In block 510, as the data associated with the third coverage
regions is transmitted to the corresponding third regionalized
server 107, the coverage region manager 206 may remove the
temporary virtual regionalized servers 107.
[0112] In some embodiments, the coverage region manager 206 may
update the coverage region topology of the geographical area to
indicate the set of third coverage regions associated with the set
of third regionalized servers 107 that replaces the coverage
regions associated with the set of existing regionalized servers
107. The coverage region manager 206 may then transmit the updated
coverage region topology of the geographical area to the
regionalized servers 107 associated with the coverage regions in
the geographical area and the vehicle platforms 103. As discussed
elsewhere herein, the regionalized servers 107 and the vehicle
platforms 103 may adjust the communication between the regionalized
servers 107 and the vehicle platforms 103 based on the updated
coverage region topology of the geographical area. For example, the
regionalized servers 107 may reference the updated coverage region
topology of the geographical area to determine its coverage region,
and communicate and provide the vehicle applications to the vehicle
platforms 103 located within its coverage region. The vehicle
platform 103 may reference the updated coverage region topology of
the geographical area to determine the coverage region within which
the vehicle platform 103 is located, and communicate with the
regionalized server 107 associated with this coverage region.
[0113] Thus, as a result of the topology modification and the minor
topology update or the major topology update, the first coverage
region associated with the first regionalized server 107 can be
flexibly modified (e.g., created, eliminated, expanded, or reduced)
into the target coverage region of the first regionalized server
107, and the set of second coverage regions associated with the set
of second regionalized servers 107 that are adjacent to the target
coverage region of the first regionalized server 107 can be morphed
or re-established according to the target coverage region of the
first regionalized server 107. As the coverage regions of the
regionalized servers 107 can be dynamically adjusted or redefined,
the regionalized server 107 may have sufficient computational
resources to provide vehicle applications to the vehicle platforms
103 located within its coverage region. The regionalized server 107
can also collect relevant data from multiple vehicle platforms 103
located within its coverage region, and thus the operation of the
vehicle applications implemented on the regionalized server 107
(e.g., the navigation application 122) can be improved. The
regionalized server 107 can also temporarily cover a particular
coverage region in the geographical area to dynamically provide a
vehicle application to the vehicle platforms 103 located within
that coverage region on a temporary basis.
[0114] In the above description, for purposes of explanation,
numerous specific details are set forth in order to provide a
thorough understanding of the present disclosure. However, it
should be understood that the technology described herein could be
practiced without these specific details. Further, various systems,
devices, and structures are shown in block diagram form in order to
avoid obscuring the description. For instance, various
implementations are described as having particular hardware,
software, and user interfaces. However, the present disclosure
applies to any type of computing device that can receive data and
commands, and to any peripheral devices providing services.
[0115] In some instances, various implementations may be presented
herein in terms of algorithms and symbolic representations of
operations on data bits within a computer memory. An algorithm is
here, and generally, conceived to be a self-consistent set of
operations leading to a desired result. The operations are those
requiring physical manipulations of physical quantities. Usually,
though not necessarily, these quantities take the form of
electrical or magnetic signals capable of being stored,
transferred, combined, compared, and otherwise manipulated. It has
proven convenient at times, principally for reasons of common
usage, to refer to these signals as bits, values, elements,
symbols, characters, terms, numbers, or the like.
[0116] It should be borne in mind, however, that all of these and
similar terms are to be associated with the appropriate physical
quantities and are merely convenient labels applied to these
quantities. Unless specifically stated otherwise as apparent from
the following discussion, it is appreciated that throughout this
disclosure, discussions utilizing terms including "processing,"
"computing," "calculating," "determining," "displaying," or the
like, refer to the action and processes of a computer system, or
similar electronic computing device, that manipulates and
transforms data represented as physical (electronic) quantities
within the computer system's registers and memories into other data
similarly represented as physical quantities within the computer
system memories or registers or other such information storage,
transmission or display devices.
[0117] Various implementations described herein may relate to an
apparatus for performing the operations herein. This apparatus may
be specially constructed for the required purposes, or it may
comprise a general-purpose computer selectively activated or
reconfigured by a computer program stored in the computer. Such a
computer program may be stored in a computer readable storage
medium, including, but is not limited to, any type of disk
including floppy disks, optical disks, CD ROMs, and magnetic disks,
read-only memories (ROMs), random access memories (RAMs), EPROMs,
EEPROMs, magnetic or optical cards, flash memories including USB
keys with non-volatile memory or any type of media suitable for
storing electronic instructions, each coupled to a computer system
bus.
[0118] The technology described herein can take the form of an
entirely hardware implementation, an entirely software
implementation, or implementations containing both hardware and
software elements. For instance, the technology may be implemented
in software, which includes but is not limited to firmware,
resident software, microcode, etc. Furthermore, the technology can
take the form of a computer program product accessible from a
computer-usable or computer-readable medium providing program code
for use by or in connection with a computer or any instruction
execution system. For the purposes of this description, a
computer-usable or computer readable medium can be any
non-transitory storage apparatus that can contain, store,
communicate, propagate, or transport the program for use by or in
connection with the instruction execution system, apparatus, or
device.
[0119] A data processing system suitable for storing and/or
executing program code may include at least one processor coupled
directly or indirectly to memory elements through a system bus. The
memory elements can include local memory employed during actual
execution of the program code, bulk storage, and cache memories
that provide temporary storage of at least some program code in
order to reduce the number of times code must be retrieved from
bulk storage during execution. Input/output or I/O devices
(including but not limited to keyboards, displays, pointing
devices, etc.) can be coupled to the system either directly or
through intervening I/O controllers.
[0120] Network adapters may also be coupled to the system to enable
the data processing system to become coupled to other data
processing systems, storage devices, remote printers, etc., through
intervening private and/or public networks. Wireless (e.g.,
Wi-Fi.TM.) transceivers, Ethernet adapters, and modems, are just a
few examples of network adapters. The private and public networks
may have any number of configurations and/or topologies. Data may
be transmitted between these devices via the networks using a
variety of different communication protocols including, for
example, various Internet layer, transport layer, or application
layer protocols. For example, data may be transmitted via the
networks using transmission control protocol/Internet protocol
(TCP/IP), user datagram protocol (UDP), transmission control
protocol (TCP), hypertext transfer protocol (HTTP), secure
hypertext transfer protocol (HTTPS), dynamic adaptive streaming
over HTTP (DASH), real-time streaming protocol (RTSP), real-time
transport protocol (RTP) and the real-time transport control
protocol (RTCP), voice over Internet protocol (VOIP), file transfer
protocol (FTP), WebSocket (WS), wireless access protocol (WAP),
various messaging protocols (SMS, MMS, XMS, IMAP, SMTP, POP,
WebDAV, etc.), or other known protocols.
[0121] Finally, the structure, algorithms, and/or interfaces
presented herein are not inherently related to any particular
computer or other apparatus. Various general-purpose systems may be
used with programs in accordance with the teachings herein, or it
may prove convenient to construct more specialized apparatus to
perform the required method blocks. The required structure for a
variety of these systems will appear from the description above. In
addition, the specification is not described with reference to any
particular programming language. It will be appreciated that a
variety of programming languages may be used to implement the
teachings of the specification as described herein.
[0122] The foregoing description has been presented for the
purposes of illustration and description. It is not intended to be
exhaustive or to limit the specification to the precise form
disclosed. Many modifications and variations are possible in light
of the above teaching. It is intended that the scope of the
disclosure be limited not by this detailed description, but rather
by the claims of this application. As will be understood by those
familiar with the art, the specification may be embodied in other
specific forms without departing from the spirit or essential
characteristics thereof. Likewise, the particular naming and
division of the modules, routines, features, attributes,
methodologies and other aspects are not mandatory or significant,
and the mechanisms that implement the specification or its features
may have different names, divisions and/or formats.
[0123] Furthermore, the modules, routines, features, attributes,
methodologies and other aspects of the disclosure can be
implemented as software, hardware, firmware, or any combination of
the foregoing. Also, wherever a component, an example of which is a
module, of the specification is implemented as software, the
component can be implemented as a standalone program, as part of a
larger program, as a plurality of separate programs, as a
statically or dynamically linked library, as a kernel loadable
module, as a device driver, and/or in every and any other way known
now or in the future. Additionally, the disclosure is in no way
limited to implementation in any specific programming language, or
for any specific operating system or environment.
* * * * *