Vehicle --> Multi-Access Edge Computing:
access request

This flow may also be implemented by Vehicle --> Connected Vehicle Roadside Equipment: access request

Definitions

access request (Information Flow): Request for access to an access-controlled transportation facility.

Vehicle (Source Physical Object): This 'Vehicle' physical object is used to model core capabilities that are common to more than one type of Vehicle. It provides the vehicle-based general sensory, processing, storage, and communications functions that support efficient, safe, and convenient travel. Many of these capabilities (e.g., see the Vehicle Safety service packages) apply to all vehicle types including personal vehicles (including motorcycles), commercial vehicles, emergency vehicles, transit vehicles, and maintenance vehicles. From this perspective, the Vehicle includes the common interfaces and functions that apply to all motorized vehicles. The radio(s) supporting V2V and V2I communications are a key component of the Vehicle. Both one-way and two-way communications options support a spectrum of information services from basic broadcast to advanced personalized information services. Advanced sensors, processors, enhanced driver interfaces, and actuators complement the driver information services so that, in addition to making informed mode and route selections, the driver travels these routes in a safer and more consistent manner. This physical object supports all six levels of driving automation as defined in SAE J3016. Initial collision avoidance functions provide 'vigilant co-pilot' driver warning capabilities. More advanced functions assume limited control of the vehicle to maintain lane position and safe headways. In the most advanced implementations, this Physical Object supports full automation of all aspects of the driving task, aided by communications with other vehicles in the vicinity and in coordination with supporting infrastructure subsystems.

Multi-Access Edge Computing (Destination Physical Object): 'Multi-Access Edge Computing' ((MEC) previously known as mobile edge computing) represents computing devices that operate and are managed like a cloud server, but are deployed at the edge of a network (typically a cellular network, but it could be any network). While not in strict proximity to the transportation network, these systems do benefit from vastly decreased distances to the roadway compared to central systems, and so can provide lower latency than strictly backoffice systems

Included In

This Triple is in the following Service Packages:

This triple is associated with the following Functional Objects:

This Triple is described by the following Functional View Data Flows:

This Triple has the following triple relationships:

Communication Solutions

Solutions are sorted in ascending Gap Severity order. The Gap Severity is the parenthetical number at the end of the solution.

Selected Solution

(None-Data) - Secure Wireless Internet (EU)

Solution Description

This solution is used within Australia and the E.U.. It combines standards associated with (None-Data) with those for I-M: Secure Wireless Internet (EU). The (None-Data) standards include an unspecified set of standards at the upper layers. The I-M: Secure Wireless Internet (EU) standards include lower-layer standards that support secure communications between two entities, either or both of which may be mobile devices, but they must be stationary or only moving within wireless range of a single wireless access point (e.g., a parked car). Security is based on X.509 certificates. A non-mobile (if any) endpoint may connect to the service provider using any Internet connection method.

ITS Application Entity
Mind the gapMind the gapMind the gap

Development needed
Click gap icons for more info.

Mgmt
Facilities
Mind the gap

Development needed
Security
Mind the gapMind the gap
TransNet
Access
TransNet TransNet

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

Access Access

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

ITS Application ITS Application

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

Mgmt Mgmt

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

Facility Facility

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

Security Security

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

Note that some layers might have alternatives, in which case all of the gap icons associated with every alternative may be shown on the diagram, but the solution severity calculations (and resulting ordering of solutions) includes only the issues associated with the default (i.e., best, least severe) alternative.

Characteristics

CharacteristicValue
Time Context Now
Spatial Context Adjacent
Acknowledgement True
CardinalityUnicast
InitiatorSource
AuthenticableTrue
EncryptTrue


InteroperabilityDescription
NationalThis triple should be implemented consistently within the geopolitical region through which movement is essentially free (e.g., the United States, the European Union).

Security

Information Flow Security
  Confidentiality Integrity Availability
Rating Moderate Moderate Moderate
Basis This indicates the OBE-equipped vehicle's intent to perform a given action. Such information is intended only for the entity capable of granting access, and if observed by a third party may reveal the OBE operator's intent, so should be protected. Incorrect permission may deny rightful access or appear to grant access when it should not. If rightful access is mission critical this should be HIGH. An incorrect granting of access will likely be subsequently denied by other means (guards, gates, etc.), which justifies leaving this at MODERATE. Importance rationale tied to Integrity requirement. If critical, there should be other mechanisms.


Security CharacteristicsValue
AuthenticableTrue
Encrypt True