Remote Vehicle Interaction - Architecture High Level Description

Authors Magnus Feuer

Plaintext

Title Remote Vehicle Interaction - High Level Description Author mfeuer Date 2014-06-27

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 1 / 81

Remote Vehicle Interaction
Architecture High Level Description

Magnus Feuer
mfeuer@jaguarlandrover.com

© 2014 Jaguar Land Rover.
This document is licensed under Creative Commons Attribution-ShareAlike 4.0 International.
Title Remote Vehicle Interaction - High Level Description Author mfeuer Date 2014-06-27

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 2 / 81

Revisions
Revision Date Author Notes
1 2014-06-11 Magnus Feuer First Draft.
2 2014-06-11 Magnus Feuer Review feedback from Arthur Taylor integrated.
3 2014-06-12 Magnus Feuer Additional feedback from Arthur Taylor and Paul Hanchett
integrated.
4 2014-06-14 Magnus Feuer Formatting and minor corrections
5 2014-06-26 Magnus Feuer Renamed document, removing the Tizen reference.
Updates from security review:
1. Change document license to Creative Commons.
2. Remove all security between Service Edge and services
Securing the service - Service Edge link security is now scoped
out to implementation / deployment / ops.
3. Add certificate timestamp field.
Allows chronological sorting of certificates
4. Add node detection technique examples
5. Add per-user service access to the Issue list
6. Add suggestion on how to avoid node spoofing to issue list

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 3 / 81

Table of Contents

Contents
1. References ............................................................................................................................................ 8
2. Acronyms and definitions ..................................................................................................................... 9
3. Introduction and Purpose ................................................................................................................... 10
3.1. Document Structure and Reader Assumptions .......................................................................... 11
3.2. Issues ........................................................................................................................................... 12
3.2.1. Federation ........................................................................................................................... 12
3.2.2. Data Link node discovery .................................................................................................... 12
3.2.3. Certificate revocation.......................................................................................................... 12
3.2.4. Request transaction id ........................................................................................................ 12
3.2.5. Certificate format ................................................................................................................ 12
3.2.6. User-level Node authorization ............................................................................................ 12
3.2.7. Node spoofing prevention .................................................................................................. 13
4. Requirements and Objectives ............................................................................................................. 14
4.1. Internet Connectivity Optional ................................................................................................... 14
4.2. Zero Service Configuration.......................................................................................................... 14
4.3. Decentralized Service Discovery ................................................................................................. 14
4.4. Self-Carried Authorization .......................................................................................................... 14
4.5. Interoperability ........................................................................................................................... 15
4.6. Connectivity Awareness .............................................................................................................. 15
4.7. Sparse Connectivity Support ....................................................................................................... 15
4.8. Hybrid Deployment Support ....................................................................................................... 15
5. Architecture Overview ........................................................................................................................ 16
5.1. Data Router ................................................................................................................................. 17
5.2. Remote Vehicle Access Manager (RVAM) .................................................................................. 17
5.3. Service Edge ................................................................................................................................ 17

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 4 / 81

5.4. Store and Forward ...................................................................................................................... 17
5.5. Protocol ....................................................................................................................................... 17
5.6. Data Link ..................................................................................................................................... 17
5.7. Service Discovery ........................................................................................................................ 18
5.8. Authorization Manager ............................................................................................................... 18
5.9. Provisioning Server ..................................................................................................................... 18
5.10. Software Over The Air (SOTA) ..................................................................................................... 18
5.11. Mobile Device Data Router ......................................................................................................... 18
6. RVI-Wide Concepts ............................................................................................................................. 19
6.1. RPC, Message, and Metric Request Type ................................................................................... 19
6.2. Topic Trees and Service Addressing ............................................................................................ 20
6.3. Node addressing ......................................................................................................................... 22
6.4. RVI Security Scope....................................................................................................................... 24
7. Service Management .......................................................................................................................... 26
7.1. Service Registration .................................................................................................................... 27
7.1.1. Step 1 - Register with Service Edge ..................................................................................... 27
7.1.2. Step 2 - Register with Service Discovery ............................................................................. 28
7.1.3. Step 3- Confirm Service Discovery registration Service Discovery confirms that the service
has been registered and announced. ................................................................................................. 28
7.1.4. Step 4 - Confirm Service Edge registration Service Edge replies to Media Server service
that the registration was successful, and that traffic is to be expected. ............................................ 28
7.2. Certificates .................................................................................................................................. 29
7.3. Service Discovery ........................................................................................................................ 32
7.4. Node Detection ........................................................................................................................... 35
7.4.1. Vehicle connection to well-known server........................................................................... 35
7.4.2. WiFi network connections .................................................................................................. 35
7.4.3. P2P connections (Bluetooth, serial) .................................................................................... 35
7.4.4. SMS ..................................................................................................................................... 36
7.6. Authorization .............................................................................................................................. 37
7.7. Service Announcement ............................................................................................................... 40

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 5 / 81

8. Request Routing .................................................................................................................................. 43
8.1. Step 1 [Vehicle] - Submit request to Service Edge ...................................................................... 44
8.2. Step 2 [Vehicle] - Validate service request ................................................................................. 46
8.3. Step 3 [Vehicle] - Validate service reply...................................................................................... 47
8.4. Step 4 [Vehicle] - Resolve network address................................................................................ 48
8.5. Step 5 [Vehicle] - Return resolved network address ................................................................. 49
8.6. Step 6 [Vehicle] - Schedule request ............................................................................................ 50
8.7. Step 7 [Vehicle] - Setup Communication Channel ...................................................................... 52
8.8. Step 8 [Vehicle] - Authorize and Announce ................................................................................ 54
8.9. Step 9 [Vehicle] - Report data link availability ............................................................................ 55
8.10. Step 10 [Cloud] - Report data link availability ............................................................................ 56
8.11. Step 11 [Vehicle] - Request encoding and transmission............................................................. 57
8.12. Step 12 [Vehicle] - Transmit data................................................................................................ 58
8.13. Step 13 [Cloud] - Decode payload............................................................................................... 59
8.14. Step 14 [Cloud] - Forward request to Service Edge .................................................................... 60
8.15. Step 15 [Cloud] - Authorize remote request............................................................................... 61
8.16. Step 16 [Cloud] - Return Authorization data .............................................................................. 62
8.17. Step 17 [Cloud] - Request Media Server URL.............................................................................. 63
8.18. Step 18 [Cloud] - Return Media Server local address ................................................................. 64
8.19. Step 19 [Cloud] - Forward request to Media Server ................................................................... 65
8.20. Reply Routing .............................................................................................................................. 66
9. Node and Service Provisioning............................................................................................................ 67
9.1. Add certificate Step 1 -Send out the request ............................................................................. 68
9.2. Add certificate Step 2 – Forward request to target node ........................................................... 69
9.3. Add certificate Step 3 – Deliver request to target Authorization ............................................... 70
9.4. Delete certificates ....................................................................................................................... 71
9.5. Revoke certificates ...................................................................................................................... 72
9.6. P2P Access Granting.................................................................................................................... 73
10. Service Edge feature set ................................................................................................................. 74

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 6 / 81

10.1. Local Service Registration ........................................................................................................... 74
10.2. Service availability reporting....................................................................................................... 74
10.3. Process requests from local services .......................................................................................... 74
10.4. Process requests from remote services ...................................................................................... 74
11. Service Discovery feature set .......................................................................................................... 75
11.1. Register local services ................................................................................................................. 75
11.2. Register node to network address mappings ............................................................................. 75
11.3. Resolve service to network address ........................................................................................... 75
11.4. Process incoming service announcements ................................................................................. 75
11.5. Send outgoing service announcement ....................................................................................... 75
11.6. Process communication channel availability reports ................................................................. 76
12. Authorization feature set ................................................................................................................ 77
12.1. Authorize local requests ............................................................................................................. 77
12.2. Authorize remote requests ......................................................................................................... 77
12.3. Provision certificates ................................................................................................................... 77
13. Store and Forward feature set ........................................................................................................ 78
13.1. Process local requests ................................................................................................................. 78
13.2. Process remote requests ............................................................................................................ 78
13.3. Process data link availability reports .......................................................................................... 78
13.4. Process service availability reports ............................................................................................. 78
14. Protocol feature set ........................................................................................................................ 79
14.1. Encode and transmit requests .................................................................................................... 79
14.2. Receive and decode requests ..................................................................................................... 79
15. Data Link feature set ....................................................................................................................... 80
15.1. Setup communication channel ................................................................................................... 80
15.2. Disconnect communication channel ........................................................................................... 80
15.3. Transmit data payload ................................................................................................................ 80
15.4. Receive data payload .................................................................................................................. 80
15.5. Send node authorization............................................................................................................. 80

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 7 / 81

15.6. Receive remote Node authorization ........................................................................................... 80
15.7. Send service announcement ....................................................................................................... 80
15.8. Receive service announcement .................................................................................................. 80
15.9. Report communication channel availability ............................................................................... 80

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 8 / 81

1. References
[1] Google Protocol Buffers https://code.google.com/p/protobuf/

[2] Requirement Specification Xxx

[3] MQT Specification 3.1, Appendix A. http://public.dhe.ibm.com/software/dw/webservices/ws-
mqtt/MQTT_V3.1_Protocol_Specific.pdf

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 9 / 81

2. Acronyms and definitions
RVI Remote Vehicle Interface

SOTA Software Over The Air

TSP Telematics Service Provider

RVAM Remote Vehicle Access Manager

Node A vehicle, mobile device, or backend server running RVI-integrated
services

Component An internal service inside the RVI system

Manager A higher level component

Service An external application connected to the RVI system

Topic Tree A global registry to identify and locate services

Node Address Topic Tree section that uniquely identifies a node

Network An URL, IP address, MSISDN, or similar that a node can be reached
Address at

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 10 / 81

3. Introduction and Purpose
This document introduces the Remote Vehicle Interaction (RVI) architecture on a high level, outlining its
design, the components, and the core use cases. It is intended for the reader who wants a
comprehensive overview of the RVI, its parts, and how they interact. Once this document has been read,
the reader can continue with the DDS (see below) for specific components to understand their
implementation requirements.

The purpose of the RVI architecture is to enable vehicles, mobile devices, and backend servers to
exchange today’s and tomorrow’s connected car services in a robust, secure, and versatile manner. The
RVI will place a minimum number of requirements and restrictions of the services that use it, aiming at
giving applications a maximum degree of freedom in their implementation. Examples of such
applications are remote door unlock, software upgrades (through the dealer, OTA and USB sticks),
climate control from mobile device, syncing of media files between the cloud and the vehicle, geo
fencing, etc.

The RVI architecture describes a set of components and services that form a distributed, sparsely
connected, secure P2P network where vehicles, mobile devices, and backend servers can access each
other.

The complete set of RVI architecture documents will be used as the basis for a reference open source
implementation of the RVI that will be released to the community.

The philosophy behind the RVI effort is that the reference implementation drives the specification, and
that any design issues resolved in the implementation flows down to the specification. Thus, if the
implementation and the specification are in conflict with each other, the implementation takes priority.
The feedback from the implementation will be used to refine the RVI architecture and specification
itself.

Consequently, all APIs are specified using Google’s Protocol Buffer [1] schema language, using a JSON-
RPC interpretation as examples and in the reference implementation. Other implementations, however,
are free to use other protocols (SOAP, restful HTTP, BERT-RPC, etc), as long as they provide a clear and
deterministic translation table between Protocol Buffers and their chosen protocol.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 11 / 81

3.1. Document Structure and Reader Assumptions

The RVI is described in the following hierarchy of documents:

1. PowerPoint presentation
Gives a summary of the design, what it does, and how it operates

2. High Level Description (HLD) (this document)
Goes through the overall schematics, its included components, and core use cases.

3. Per Component Detailed Design Specification (DDS)
Each component described by the HLD is described in detail in their own DDS document.
Descriptions, Schematics, API specifications are included for each component DDS.

It is recommended that the documents are read in the order given above.

The reader of this HLD is assumed to be familiar with the following areas:

1. Mobile terminology
Terms such as 3G, handset, pppd, and mobile data links will be used throughout the HLD.

2. Automotive applications
Media Players, door lock management, and other applications will be used as examples.

3. Networking
Distributed system terminology, IP-terms, and web technologies such as JSON-RPC and HTTP
will be used.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 12 / 81

3.2. Issues
This specification is not complete. Below is a table with currently identified issues and shortcomings that
should be addressed.

3.2.1. Federation
The current specification leaves it up to each individual node to trust the certificates sent out by a
provisioning server. There is no way for a node to validate the legitimacy of a provisioning server.

3.2.2. Data Link node discovery
There is no specification for how two nodes should find each other prior to running the
authorize/announce use case. While this is technically in the domain of each Data Link implementation,
best practices such as UDP broadcasts, connection attempt to well-known addresses, etc, should be
documented.

3.2.3. Certificate revocation
The revocation model provided in the current revision of the specification is a primitive blacklist
distribution that may not scale depending on the communication channels available.
This model can be improved upon by having P2P propagation. There may also be a better general
solution for revocation than blacklisting.

3.2.4. Request transaction id
The current specification does not indicate the necessity for a request-sending service to provide a
monotonically increasing transaction id with each request. This opens up the Service – Service Edge up
for replay attacks. A transaction id should be provided by the sending service, which is then translated
by Service Edge to an internal transaction id that will follow the transaction through the network. The
reason for the transaction id switch is to avoid duplicate IDs being provided by two different services;
the Service Edge-generated ID is guaranteed to be RVI-wide unique.

3.2.5. Certificate format
There is an IETF draft for JSON-based web encryption. The certificate format in that draft is a candidate
to replace the format used by the current version of this HLD.

3.2.6. User-level Node authorization
Currently the authentication and authorization system of the platform that a Node runs on is ignored.
Future versions of RVI may want to integrate user-level access control to determine which users can
access which services on a Node.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 13 / 81

3.2.7. Node spoofing prevention
There is currently no way to detect that a node’s private key and certificates have been stolen and are
used to impersonate that node. A partial solution is to have a local node instruct its remote counterpart
to provide a specific token in the authorization process next time it is connected to the local node. If the
remote node is impersonated, and there are currently two nodes with a single identity, one of the two
nodes will fail to provide the correct token during its subsequent authorization.

There is, however, currently no way to validate that an authorizing node is executing on a specific
hardware unit.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 14 / 81

4. Requirements and Objectives
There are several objectives for the RVI design and its reference implementation.

The core mission is to provide a specification and implementation that is easy to adopt for vendors and
customers, who are either are starting from a blank page or want to integrate their existing solution into
the RVI framework.

Please see [2] for a formal functional and non-functional requirement specification.

The following chapters outline the high level requirements and objectives being pursued.

4.1. Internet Connectivity Optional
If two nodes see each other over a communication link, their services must still be able to exchange
traffic even if neither node has an Internet connection. The typical use case is an owner who wants to
unlock and start a car in a garage using his/her mobile phone, and wants to do this even if there is no
carrier signal. The access app on the mobile phone must be able to talk to the access service in the
vehicle without having to authenticate toward a (non-reachable) central server.

4.2. Zero Service Configuration
Given the Internet requirement above, a new service, be it a mobile phone app, an in-vehicle HVAC
controller, or a cloud-based traffic information service, must be able to register themselves without
updating a central repository. A new service should only have to present correctly signed requests to the
RVI system in order to register and access other, remote services.

Please note that nodes (hosting services) still need to be provisioned with addresses, protocols, and
access rights, all expressed through certificates.

4.3. Decentralized Service Discovery
Nodes need to discover services on other nodes without involving a central repository so that two nodes
without an Internet connection can explore each other’s available services. This is also true for when
two nodes communicate with each other over non-IP based links such as Bluetooth, IR, or even USB
sticks (software updates or content transfer).

4.4. Self-Carried Authorization
When two nodes have discovered each other’s services, they need to authenticate their right to access
them. With the optional internet connectivity requirement, these authorizations have to be made in a
pure peer-to-peer fashion without third party involvement.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 15 / 81

4.5. Interoperability
An organization shall be able to implement individual components and drop them into an existing set of
RVI components without compatibility issues, given that they use the API protocol (JSON-RPC, etc).

4.6. Connectivity Awareness
Both Services and individual RVI components need to know if a remote node and its services can
currently be reached or not. This spans from a mobile device knowing if a peer-to-peer connection for a
specific vehicle is available or not, to a cloud-based media server wanting to know the available
bandwidth to a media player, to a vehicle wanting to know its currently available data channels.

4.7. Sparse Connectivity Support
Since data links come and go, often with short notice, and services on two nodes may not see each other
for weeks at the time, the RVI shall handle resend attempts, delivery validation, timeouts, and store &
forward for transactions in order to support sparse connectivity.

4.8. Hybrid Deployment Support
RVI nodes will have to integrate with servers and vehicles using other designs and products. An RVI
deployment must, with custom protocol implementations, be able to connect and interact with other
telematics and M2M systems.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 16 / 81

5. Architecture Overview
Below is a layout of a typical RVI deployment, where the blue and green components form the core of
the architecture.

Figure 1 - Architecture Overview

The API of the individual components are designed as standalone as possible, allowing the components
to be used outside the original RVI environment. Services can communicate peer-to-peer with each
other, allowing, for example, a mobile device to interact directly with a vehicle, even if neither have an
Internet connection to a Remote Access Vehicle Manager.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 17 / 81

The components are described in the following chapters.

5.1. Data Router
A high-level aggregate of lower-level components that delivers transactions between services robustly
and securely over sparsely connected networks. Different compositions of the data router executes
inside the vehicle, on the backend server, and in mobile devices.

5.2. Remote Vehicle Access Manager (RVAM)
The server-side RVAM aggregates the Data Router, Billing & Charging, Software Over The Air (SOTA), and
Provisioning into a single server system that extends the service transaction routing with external device
and software management, as well as billing, charging, and reconciliation.

5.3. Service Edge
Service Edge, present inside the Data Router acts as a service-facing API coordinating all traffic sent to
and from local services. It is responsible for authorizing and routing requests to their targeted end
points.

5.4. Store and Forward
Store and Forward receive requests from Service Edge, and, in case the addressed service cannot be
reached, stores the request until a data link to the service becomes available. It is also responsible for
management communication channels to other nodes (and their services) through Data Link.

5.5. Protocol
Protocol components (there can be many) receive requests from Service Edge and format them as
payloads to be transmitted by Data Link to their counterparts on a remote node. Conversely, incoming
data payload from Data Link is decoded by the Protocol before it is handed over in a standardized
format to Service Edge for validation and forwarding to its destination service. A protocol can also,
optionally, bypass Data Link and communicate directly with its counterpart. (Not shown in Figure 1.)

5.6. Data Link
Responsible for bringing up and tearing down data channels to remote nodes. Typical data links are
WiFi, SMS, 3G, 4G (over PPP), Ethernet, and USB sticks containing requests. Data Link can be ordered by
Store and Forward to setup or disconnect a data link, and will report to subscribing parties when link to

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 18 / 81

a remote node becomes available or unavailable.

5.7. Service Discovery
Service Discovery tracks service availability local and remote nodes. The Service Edge queries Service
Discovery in order to retrieve a target node address for a specific request. Service Discovery will
opportunistically use available data links to push Service Lists to other Service Discoveries on other
nodes as they become available for communication.

5.8. Authorization Manager
The authorization manager adds necessary signatures and certificates to outgoing transactions to
remote nodes, allowing requests to be validated prior to execution by the targeted services.
Authorization will also validate incoming requests from remote services before Service Edge sends them
on to their local service destinations.

5.9. Provisioning Server
The Provisioning server, a part of the RVAM, supports Service Discovery with information about nodes
(mobile devices, vehicles, and servers) available in a RVI network, and how they can be reached.
Provisioning also supports the Authorization Service with certificates used to sign outgoing requests to
prove their authenticity. In many instances, Provisioning is a gateway to one or more external
provisioning services hosted by TSPs, Enterprise IT, and other organizations.

5.10. Software Over The Air (SOTA)
Software Over The Air is, from a strict RVI perspective, a generic service with no special access to the
internal RVAM / Data Router components. Since SOTA (and Firmware Over The Air) is so central to the
RVI, it has been included in the architecture as a specification and reference implementation. The SOTA
server, however, can be replaced without modifying any other components apart from its SOTA
Manager counterpart on the vehicle.

5.11. Mobile Device Data Router
Mobile devices, with their often constrained execution environment, can sometimes not be suitable for
having a loosely coupled set of components forming the Data Router. Instead, these targets may need a
monolithic service or library that presents a similar interface

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 19 / 81

6. RVI-Wide Concepts
6.1. RPC, Message, and Metric Request Type
A Service can send three different types of requests to a remote counterpart, depending on the type of
payload that is to be delivered. The request types are:

1. RPC
Remote Procedure Call. A request sent from one Service to another, where the originating
Service expects a reply. If the request cannot be delivered, the originating Service will be
notified. A Service can issue a “call” command to invoke an rpc.

2. Message
An asynchronous request sent from one Service to another, where no reply is expected by the
originating Service. If the message cannot be delivered, the originating Service will not be
notified.
A Service can issue a “send” command to send a message.

3. Metrics
A set of requests to subscribe to topic entries (metrics), published by another Service, that are
to be delivered to the originating Service when updated.
A Service can issue a “subscribe” or “unsubscribe” command to setup or cancel a subscription.
A Service can issue a “publish” command to send out an updated topic entry to all its
subscribers.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 20 / 81

6.2. Topic Trees and Service Addressing
A number of system-wide topic trees are used as registries to describe all nodes and services, local and
remote, in an RVI system. Thus the topic tree is used to describe all available services in the system-wide
RVI network.

Different types of topic trees are used for different types of request, such as metrics, RPCs, alerts, and
publish/subscribe data. The syntax of a topic tree entry is:

[type]:[organization]/[path]

Figure 2 - Topic tree entry

The components of the entry are as follows:

1. [type]
Specifies the type of the topic tree, identifying which type of service it describes. Initial types are
rpc, metric, and message, although more can be added in future revisions of the RVI. See
“RPC, Message, and Metric Request Type” for details.

2. [organization]
A domain name describing the organization that hosts a sub-section of the root. All topic tree
entries in the subsequent organization are managed by the given organization.

3. [path]
A path to a number of services. The path follows the MQTT 3.1 topic structure described in [3].

Please note that several organizations can co-exist in a single topic tree. An organization is simply a top-
level divider between different sub-sections of the tree.

Below is an example of a topic tree entry, with numbered components.

Figure 3 - Typical Service Entry

The components are as follows
1. Service Type

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 21 / 81

Specifies that the topic tree entry can be invoked as a remote procedure call.

2. Organization
Specifies that this service is hosted by Jaguar Land Rover.

3. VIN sub-tree
A sub-section of the topic tree under which all registered VINs are hosted.

4. VIN
The VIN of the vehicle running the service

5. Services sub-tree
A sub-section of the topic tree hosting all services running on the given vehicle.

6. Service name
The name of the service running on the given vehicle

7. Command name
The name of the command to execute on the given service and vehicle.

Please note that only components 1 and 2 are standardized. All other components in a topic tree can be
specified by the organization hosting the tree.

Since a topic tree is system-wide, i.e. a topic tree entry resolves to the same service for all nodes, the
identity of a node that hosts a specific service is embedded into the topic tree entry. In the examples
above, the node is identified by the vehicle VIN running the body service in a car, and by the Remote
Vehicle Access Manager (RVAM) hosting services in the cloud.

When a request is sent to the service using an entry above, the node of the service will be resolved to a
network address, which will then receive the request. See chapter “Node addressing” for a description
of how a node address is translated to a network address.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 22 / 81

6.3. Node addressing
Nodes, setup in the Provisioning Server, are servers, vehicles, devices running the RVI and a number of
services. Each node can communicate with one or more other nodes over various data links.

A node is identified as a part of a topic tree path that identifies a specific service. By sending the topic
tree entry to Service Discovery, a network address to the node hosting the service. The network address
can then be handed over to Data Link in order to establish a connection to the node. Below is an
example of a topic tree entry with the address section marked.

Figure 4 - The Node Address section of a topic tree entry

Since it is up to Service Discovery to convert a topic tree to a network address, the exact format of the
address section, and how it is extracted from an entry, is implementation dependent.

The figure below shows the high-level call flow for address resolving a service, identified by a topic tree
entry, to a network address.

Figure 5 - Node to network address resolution

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 23 / 81

The steps above are as follows.

1. Send Request service edge
The Media Server sends a request, to be forwarded to the vehicle with vin sajwa71b37sh1839,
to Service Edge

2. Lookup node address
Service Edge sends a request to Service Discovery, providing the full service name received from
Media Server, in order to retrieve the network address of the node (vehicle) that hosts the
targeted service.

3. Return network address
Service Discovery, having matched the service name against its internal database, returns the
network address, which in this case is a URL, to Service Edge.

Please note that this is a simplified scenario since no data link types (3G, WiFi, SMS, etc), specifying the
recommended delivery methods to the destination node, is returned by Service Discovery.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 24 / 81

6.4. RVI Security Scope

Security, in the context of this architecture, is the process of authenticating services to access other
services in an RVI system. A service should only be able to discover and access other services it has
received authorization to from a central provisioning server.

The constraints imposed by the sparse connectivity requirement means that each node, and its services,
must be able to authenticate themselves toward other nodes without having to rely on a connection to
a central provisioning server.

This is solved by having each node carry centrally provisioned certificates with them at all times. These
certificates, downloaded from the provisioning server when connectivity to it is available, can be used
by a service to prove its access rights toward another service.

The security management of the RVI architecture covers the following areas:

1. Certificate Generation
The provisioning server has support for generating certificates granting access for a given service
to one or more other services. See chapter “Certificates” and “Authorization” for details on
service’s public key, can authenticate traffic sent from the service.

2. Certificate Distribution
Once a certificate has been generated by Provision Service, it has to be sent out to the node that
the certificate was generated for. This transmission can be implemented through an RVI built-in
certificate service.

3. Certificate Revocation
All certificates are specified with a time interval within which they are active. Sometimes,
however, certificates need to be revoked prior to their expiration date. Such revocation can also
be implemented through the certificate service.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 25 / 81

The security management of the RVI does not cover the following areas.

1. Communication Channel security
The actual transmission protocol between two Protocol (or Data Link) instances should be
secured using SSL/TLS or similar mechanisms. The exact security mechanisms employed for this
is to be determined by the Protocol implementations, and are outside the scope for the RVI
itself.

2. Node – Certificate linking
Since the RVI will operate on many devices, platforms, and network protocols, there is no
uniform way of linking a certificate to a specific device using a mac address, CPU ID, etc. As a
consequence, there is no way for a node receiving a certificate to validate that the sending
device is actually the owner of that certificate. If a device manages to steal a certificate and the
private key from a node, the device will then be able to impersonate the node and hijack its
traffic.

3. Node protection of certificates
Another consequence of the unknown devices and platforms that will run RVI, the storage and
protection of certificates and key pairs on a node is outside the scope of the RVI design and has
to be addressed by the implementation of individual Authorization components.

4. Service – Service Edge Authentication and Authorization
Services are implicitly trusted by Service Edge and are expected to execute inside the trusted
domain of a node. It is up to the implementation, deployment, and operations of an RVI system
to ensure that no illicit services gain access to Service Edge.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 26 / 81

7. Service Management
Service Management consists of a set of components, use cases and APIs that enables services to:

1. Register with the RVI
A service can connect to the RVI (through Service Edge) and register itself.

2. Announce themselves
A registered service can announce their availability not only to the local node they are executing
on, but also to other, remote nodes in the RVI network.

3. Discover other services
A service can receive availability announcements from other services, with all information
necessary to connect and send requests to them.

4. Authorize themselves
A service can authorize themselves toward other services, which in their turn can validate the
originating service.

5. Invoke other services
Once authorized, a service can send requests to other, remote services, having them carry out
tasks and send back the result.

The following chapters describe the service management on a high level.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 27 / 81

7.1. Service Registration
A Service can register itself with the RVI through Service Edge to set itself up for sending and receiving
requests, as is shown below.

Figure 6 - Service Authorization

The steps above are as follows.

7.1.1. Step 1 - Register with Service Edge
The Media Server sends a request to register itself with Service Edge.
The request contains the following elements:

1. Service Name
The symbolic name of the service, which will be added at a configurable point in the topic tree.

2. Supported Requests
A list of RPCs, messages, and metrics that are supported by the service. These will be added
under the service name in the topic tree.

3. Service Address
Specifies where t to forward requests and replies targeting the service.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 28 / 81

7.1.2. Step 2 - Register with Service Discovery
The service is forwarded by Service Edge to Service Discovery, who will announce it to all matching
subscribers. After this point, the service will be forwarded requests addressed to it.

7.1.3. Step 3- Confirm Service Discovery registration
Service Discovery confirms that the service has been registered and announced.

7.1.4. Step 4 - Confirm Service Edge registration
Service Edge replies to Media Server service that the registration was successful, and that traffic is to be
expected.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 29 / 81

7.2. Certificates
Certificates are, in the RVI context, cryptographically signed JSON structures that prove the authenticity
and authorization of one node to another.

Certificates are exchanged, peer-to-peer, between two nodes, and references to those certificates are
included to requests sent from one node to another.

An example of a certificate is given below (with non JSON-compliant comments added for clarity):

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 30 / 81

{
"node_certificate": {
// Topic tree patterns that this node is authorized to
// process requests for.
"sources": [ "jaguarlandrover.com/cloud/media_server" ],

// Services that can be accessed by the source service.
“destinations": [
"rpc:jaguarlandrover.com/vin/+/services/media_player"
],

// Public key for source.
// Used to validate signature of requests, etc.
"public_key": {
"algorithm": "....", // Of sending node.
"key": "..."
},
// Period during which certificate is valid. UTC
"validity": {
"start": 1401918299,
"stop": 1402000000
},
// A system wide unique id for the certificate
"id": b674546e-76ae-4204-b551-3f850fbffb4b
// UTC timestamp of when the certificate was created.
“create_timestamp”: 1403825201
},
// Signed by provisioning server.
// All nodes have provisioning server's public key.
// Signature covers all data in claims element.
"signature": {
"algorithm": "...",
"signature": "..."
}
}

Figure 7 – Certificate Example

The following elements are included:

1. Sources
A list of topic tree prefixes that the sending node is authorized to process requests for.
This list will be installed in Service Edge of certificate-receiving nodes to be matched against
requests that are to be sent out. If there is a match, the current network address of the

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 31 / 81

certificate-issuing node is looked up (see chapter “Step 4 [Vehicle] - Resolve network address”),
and the request is sent to it.

2. Destinations
The destination services which the certificate authorizes the source service to access. Specified
as one or more topic entries with MQTT [3] patterns. During request authorization, the request
is pattern and prefix matched against the destination fields.

3. Public key
The public key of the source service, used to validate the signature of incoming authorizations
and requests originating from the certificate-owning node.

4. Validity period
The start and stop dates, specified as UTC, within which the certificate is valid.

5. ID
System-wide unique ID for the certificate. Higher value is newer.

6. Creation timestamp
Specifies the time, in UTC, when the certificate was created.

7. Signature
Certificate signature, generated by the provisioning server’s private key. All nodes have the
provisioning server’s public key setup as a step in the installation process.

See chapter “Node and Service Provisioning” for details on how certificates are exchanged between
nodes.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 32 / 81

7.3. Service Discovery
Service discovery is the process in where the availability of services is announced between two or more
nodes. In order to fulfill the decentralized service discovery, sparse connectivity, and zero service
configuration requirements stated in “

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 33 / 81

Requirements and Objectives”, a somewhat different strategy was chosen for this process. This strategy
breaks down into the following two tenets.

1. Peer to Peer Service Announcements
Since two nodes exchanging service availability information may not have an internet
connection to a backend server, the exchange must be purely P2P without relying on a trusted
third party for validation.

2. Pairing-based Service Discovery
While traditional service discovery mechanisms are often broadcast information over a local
network, the sparse connectivity environment of RVI makes that impossible. Instead two nodes
exchange information on an opportunistic basis as soon as they see each other. A node keeps
track of all other nodes it has ever seen together with the services that were available on each
of these nodes when they were last seen. When two nodes see each other again, they exchange
updated service information.

A backend server/cloud node will see most of the other nodes as they connect in to the server and will,
over time, form a complete picture of all other nodes (vehicles, mobile phones and other devices) and
their available services. Services connected directly to the backend node will, through its Service Edge,
have access to all other nodes and their services, as is shown below:

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 34 / 81

Figure 8 - Service Discovery mechanics

In the case above, Mobile and Vehicle1 exchange services directly with each other on sight, as well as
with Cloud, while Vehicle2 only exchanges services with Cloud.

The end result is that Mobile, having access to Vehicle1’s services can control its media player, HVAC,
and door locks, whole at the same time having access to Cloud’s services. Meanwhile Vehicle2, having
never seen Mobile, can only access Cloud’s services.

The Service Discovery process between two nodes is described below.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 35 / 81

7.4. Node Detection
When two or more nodes establish a communication channel, they need to detect the presence of each
other before they can execute the Service Discovery process.
The exact means of how this is done is wholly dependent on the mechanics of the underlying network.
There are, however, a number of best practices that can be employed for standard network models,
described in the following chapters.

7.4.1. Vehicle connection to well-known server
When a vehicle’s Data Link is instructed to connect to a backend server, identified by a pre-provisioned
URL or IP address, the Data Link can ping the server once the communication channel is up.
The ping, which is a TCP/IP connection, does not have to transmit any information and can immediately
be disconnected. The receiving server will ask the operating system for the peer address of the TCP
connection to determine that there is a node at a given address that wants to execute Service Discovery.

If the protocol used to drive the Service Discovery process between two Data Links is connection based,
the TCP connection can be used in the subsequent authorization and announce steps.

7.4.2. WiFi network connections
When a Data Link connects to a WiFi, LAN or CAN network, there may be a number of other nodes
available to execute the Service Discovery process toward.

In these cases, each connected Data Link can send out a UDP/IP broadcast or multicast packet to a well-
known address and port that all Data Links listen to. The payload of the packet is irrelevant since the
receiving Data Link can look at the peer address of the packet to retrieve the IP address of the remote
Node, and then initiate the Service Discovery Process against that Node.

7.4.3. P2P connections (Bluetooth, serial)
In a strict P2P connection, where two Data Links are in direct connection with other, the Service
Discovery process can be initiated directly toward the remote end.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 36 / 81

7.4.4. SMS
SMS communication between a vehicle and a central backend server can be handled as a connection to
a well-known server described in chapter “Vehicle connection to well-known server”.

SMS communication between two nodes requires the Data Link to know the target’s MSISDN (phone
number) since all mobile terminals are addressable at all times. There is no way for an SMS-connected
Node to determine if another SMS-connected node is currently online or not. Instead the sending Node
initiates its Service Disocvery process by submitting an SMS to the network, and then time out of there is
no reply from the target node.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 37 / 81

7.6. Authorization
When two nodes see each other, either for the first time, or on a recurring connection, they start by
sending authorization information to the counterpart. In order to maintain the pairing paradigm, each
node will send an Authorization package to each other node it sees.

Figure 9 – Mobile to Vehicle authorization

In this case, the mobile device authenticates itself with the following information:

 Network Address
Gives the network address where the node can be reached. Please note that this address may
be transient and can change the next time two nodes see each other.

 Protocol
Specifies the protocol to use when communicating with the node at the network address. In this
case it is JSON-RPC over HTTP.

 Certificate
A certificate, signed by the provisioning server, contains identities, public keys, and access rights
of the sending node. The certificate also stores one or more topic tree prefixes that the sending

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 38 / 81

Node is authorized to receive requests for.

 Signature
Contains the node signature of the address and protocol elements in the authorization package.
The signature is generated by the Node’s private key and can be verified by the public key
contained in the Node Certificate.

 Transaction ID
A monotonically incremented ID. The received will store the last received ID from the node using
the given certificate, and reject any new transactions with an ID that is lower than or equal to
the stored ID. This stops replay attacks.

The steps of authorization process are as follow:

1. Request certificate from local Authorization
The certificate for the given peer-to-peer pair is retrieved from Authorization.
FIXME: How does Authorization know which P2P connection is up?

2. Transmit authenticate package to remote node
This is done by having Service Discovery interact directly with Data Link, without involving
Protocol.

3. Forward incoming package to Service Discovery
The receiving Vehicle Data Link forwards the package to Service Discovery

4. Validate authenticate package
Service Discovery on Vehicle forwards the package to Authorize, which will validate the
certificate toward the provision server’s public key and check that the provided topic tree prefix
matches those in the certificate.

Once completed, the topic tree prefix(es) are added together with the network address in the address
table of Service Discovery.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 39 / 81

The Vehicle device sends a similar authorization package to the mobile device, as is shown below.

Figure 10 – Vehicle to mobile authorization

Once authorization packages have been exchanged between two nodes, they know their counterpart’s
address, and which service requests that should be forwarded to it.

The prefix element will be matched against the “source” element of the certificate to ensure that a node
does not try to serve traffic it is not authorized to handle.

The authorization is valid on the receiving node until the same certificate is used in another
authorization package, or the accompanying certificate is revoked or expired.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 40 / 81

7.7. Service Announcement
When a node has sent its authorization to another node, the received uses the sending node’s
certificate to determine which services the receiving node should announce to the sender. By pattern
matching all available services against a received certificate’s destination element, it can filter out those
services eligible for announcement.

The announcement is carried out as follows:

Figure 11 – Mobile Device service announcement

The “service announce” package contains one or more services that the receiving node can invoke on
the sending node.

The steps of announcement process are as follow:

1. Sign announcement

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 41 / 81

The service announcement is sent to Authorization, which will sign the package using the private
key of the Mobile node.

2. Transmit service announcement package Vehicle
The package contains all services that the Mobile can invoke on Vehicle.

3. Forward service announcement to Service Discovery

4. Validate package
The received package is forwarded to Authorize to match the signature against the certificate
received in the authorization process.

Once the process has completed, all services announced by the mobile device are stored in the service
table of Service Discovery on the vehicle side.

The Vehicle goes through the same process of service announcement:

Figure 12 - Vehicle service announcement

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 42 / 81

The service announcement is valid with the receiver until a new authenticate package is received using
the same certificate that validates the service announcement’s certificate, or the certificate is revoked
or expires.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 43 / 81

8. Request Routing
A request sent by one service to another goes through several steps. The following chapters describe a
use case where a vehicle-based media player requests a song to be played from a cloud-based media
server. The involved components are shown below.

Figure 13 - Request Routing setup

At the start of the request routing, the following preconditions are met:

1. Services are registered
The Media Player and Media Server are both registered with their Service Edge, as described in
chapter “Service Registration”

2. No certificates
The Vehicle does not have a certificate from the Cloud, and vice versa.

3. No connection
The mobile connection between the cloud and the vehicle is yet to be setup.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 44 / 81

8.1. Step 1 [Vehicle] - Submit request to Service Edge
The transaction is initiated when the Media Player on the vehicle sends a play request, addressed to the
Media Server in the Cloud, to its local Service Edge.

Figure 14 - Initial request submit

The request contains the following elements

1. method
Always “invoke”. The actual request mechanism, rpc, message, subscribe, etc, is specified in
“target”.|

2. timeout
Specifies the time stamp, as UTC, by which the reply for this request has to be returned to the
Media Player in order not to trigger a timeout error.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 45 / 81

3. requesting_service
Specifies the service that is sending the request, in this case the media player. The name is used
as a key by the local Service Edge when validating credentials.

4. target
Specifies where the request is to be sent. This node address will be resolved to a network
address by Service Discovery. The service will have built-in knowledge of available remote
services it wants to access. Since the topic tree encompasses all services on all nodes, a single
topic tree entry is enough to identify a given service, no matter where it is running.

5. arguments
Provides additional, arbitrary data to deliver to the target service.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 46 / 81

8.2. Step 2 [Vehicle] - Validate service request
Service Edge forwards the request it received from the Media Player to Authorization to be validated.

Figure 15 - Validate service request

The request is identical to the one received from Media Player, save that the method has been replaced
with authorize_local_service. Since this is a validation of a locally connected service, the service name
(specified in requested_service) can be used as a key to lookup and validate the transaction.
The “target” element is pattern matched against the “destinations”elements of all certificates the
Vehicle node have provisioned. If there is a match, the given certificate will be sent with the request to
its targeted remote (Cloud) node to prove that Vehicle has the right to invoke targeted service on it.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 47 / 81

8.3. Step 3 [Vehicle] - Validate service reply
If Authorization successfully validates the request, it will reply with the certificate to present to the
remote node.

Figure 16 - Validate service reply

The certificate returned by Authorization is either pre-installed, or distributed using a dedicated
certificate transmission service from a provisioning service to the node.

The authorization reply contains the following elements.
1. status
Contains the result of the authorization request.

2. request_signature
The signature for the authorized request. This signature, generated by Authorization’s private
key, is to accompany the request through all steps to its targeted destination.

3. certificate
Contains the certificate, with the public key used to validate request_signature, that can be used
by the target node to validate the request. The certificate is generated by the Provisioning
Server and is signed by its private key.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 48 / 81

8.4. Step 4 [Vehicle] - Resolve network address
Service Edge sends an address resolve request to Service Discovery in order to translate the service
entry specified as the request’s target service to a network address that can be handled by Data Link.

Figure 17 - Resolve network address

The node address is set to the value of the “target” element in the original request sent by Media Player.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 49 / 81

8.5. Step 5 [Vehicle] - Return resolved network address
Service Discovery uses either install-time provisioned data or received service discovery announce data
to pattern match and resolve the received node address to a network address, which is sent back to
Service Edge.

Figure 18 - Address resolve reply

In this case, the vehicle is pre-provisioned with a match for “+:jlr.com/cloud/+”, which yields
“http://176.74/176.178/rvi”.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 50 / 81

8.6. Step 6 [Vehicle] - Schedule request
Service Edge assigns a node-unique transaction id that ties the request to the originating Media Player.
This id will follow the transaction throughout its travel to its targeted service.
Service Edge then forwards the original request to Store and Forward in order to schedule it for
transmission to the destination Cloud node.

Figure 19 - Store and Forward request

The request sent over to Store and Forward has the following elements:

1. transaction_id
Unique transaction id that will follow the request to its destination, and accompany the reply on
its way back. Vehicle Service Edge can map the transaction ID to the callback URL of the Media
Player.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 51 / 81

2. target, network_address, arguments
Request routing and payload information carried over from previous steps.

3. request_signature
The request signature, generated by Authorization, to prove that this request is created by the
Vehicle node.

4. certificate
The certificate, signed by the Provisioning Server, used to validate the signature, hence the
request itself.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 52 / 81

8.7. Step 7 [Vehicle] - Setup Communication Channel
Store and Forward uses its internal database to determine the type of data link needed to transmit the
request to its target node, and then requests Data Link to setup a connection to the network address
resolved by Service Edge.

Figure 20 - Data link setup request

The request contains the following information:

1. target
The original target specified by the originating Media Player service

2. network_address
The network address resolved from the target by Service Discovery

3. callback

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 53 / 81

The callback to invoke once Data Link has setup the communication channel, or failed in its
attempt doing so.

4. link_type
A symbolic name for the type of communication channel that Data Link is to establish. In this
case it is an Long Term Evolution 4G link (over ppp).

5. link_arg
Additional data to pass on to Data Link and its handled for the given link type. For an LTE link an
access point node, user name and password is needed.
The link_arg element can also contain priority information, depending on how urgent Store and
Forward deems the request to be.

Data Link uses the provided network_address, link_type and link_arg to setup a ppp link over LTE.

FIXME: Where do we get link_type and link_arg from? Locally provisioned in Data Link?

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 54 / 81

8.8. Step 8 [Vehicle] - Authorize and Announce
Vehicle and Cloud authorizes themselves and announces their services as described in chapter “Service
Registration”

Figure 21 - Authorize and Announce

Once the authorization and announcement process has completed, Vehicle and Cloud are aware of each
other’s available services.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 55 / 81

8.9. Step 9 [Vehicle] - Report data link availability
Once the Vehicle and the Cloud have authorized each other and announced their services, Data Link on
Vehicle announces the communication channel availability to its local Store and Forward.

Figure 22 – Vehicle communication channel available.

The network address contains the address reported by the Cloud during its authorization phase
described in chapter “Authorization”

The services elements lists all services announced by the Cloud during discover phase described in
chapter “Service Announcement”.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 56 / 81

8.10. Step 10 [Cloud] - Report data link availability
In a similar manner to step 9, Data Link on Cloud announces the communication channel availability to
its local Store and Forward.

Figure 23 – Cloud communication channel available.

The network address contains the address reported by the Vehicle during its authorization phase
described in chapter “Authorization”

The services elements lists all services announced by the Vehicle during discover phase described in
chapter “Service Announcement”.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 57 / 81

8.11. Step 11 [Vehicle] - Request encoding and transmission
Store and Forward match available services received from Data Link against all pending requests, thus
finding the waiting request sent from the Vehicle Media Player targeting the Cloud Media Server.

The appropriate Protocol is retrieved and the original Media Player request is forwarded to it for
encoding and transmission.

Figure 24 - Prepare request for transmission

The request forwarded to Protocol is identical to that received by Store and Forward from Service Edge
in step 6.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 58 / 81

8.12. Step 12 [Vehicle] - Transmit data
Protocol encodes the request to a data payload and sends it to Protocol’s counterpart in the Cloud.

Figure 25 – Data transmission

In this case the payload is transmitted as JSON-RPC over a HTTP 1.1 connection.

As an alternative, Protocol can forward its encoded payload to Data Link for transmission to the other
node. This may be a feasible solution when Data Link has communication awareness and capabilities
lacking in Protocol.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 59 / 81

8.13. Step 13 [Cloud] - Decode payload
Cloud Protocol uses the received data payload to reconstruct the original request sent by Vehicle’s
Media Player. The reconstructed request is forwarded to Store and Forward on Cloud.

Figure 26 - Decoding incoming payload

The payload will be identical to that forwarded in step 6 from Vehicle’s Store and Forward to its
Protocol.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 60 / 81

8.14. Step 14 [Cloud] - Forward request to Service Edge

Store and Forward sends the decoded request to Service Edge in order to have it forwarded to the
targeted Media Server.

Figure 27 - Forward request to Service Edge

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 61 / 81

8.15. Step 15 [Cloud] - Authorize remote request
Service Edge forwards the received request to Authorization in order to have the request and its
certificate validated.

Figure 28 - Authorize remote request

Authorization will use the request_signature and certificate to validate the request.

If the request is successfully validated, a positive reply is sent back to Service Edge.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 62 / 81

8.16. Step 16 [Cloud] - Return Authorization data

Authorization, upon successfully validating the request, returns a positive reply.

Figure 29 - Return local service signature

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 63 / 81

8.17. Step 17 [Cloud] - Request Media Server URL
Service Edge queries its local Service Discovery, requesting the URL of the Media Server based on the
service topic entry.

Figure 30 - Resolve local service

The service element is extracted from the original request and is used by Service Discovery to map to a
network address where the targeted Media Server can be reached.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 64 / 81

8.18. Step 18 [Cloud] - Return Media Server local address
Service Edge searches its database with local service registrations, described in chapter “Service
Registration, for a service that prefix matches the provided service topic entry.

Figure 31 - Return Media Server local address.

Once found, the network address of the service (specified in the address element of its register _service
request) is returned.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 65 / 81

8.19. Step 19 [Cloud] - Forward request to Media Server

The request is sent from Service Edge to the local Media Server, using the address returned by Service
Discovery. The request is signed by Authorization, using the Service Edge’s private key so that it can
validate the incoming request using the Service Edge’s pre-provisioned public key.

Figure 32 - Forward request to Media Server.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 66 / 81

8.20. Reply Routing
The processing and transportation of a request reply is identical to that of the original request, with the
following exceptions.

1. method element value
The “method” element of the request will be changed from “invoke” to “reply”.

2. transaction_id element value
In step 6 of the reply routing, Service Edge will reuse the transaction id of the original request
instead of creating a new identity for the reply. This allows the Vehicle Service Edge receiving
the reply to reconnect the reply with the original request from the Media Player service.

3. Step 7-10 are optional
Since the reply is sent back from Cloud to Vehicle shortly after the request was sent from
Vehicle to Cloud, chances are that the communication channel between the two nodes is still
up. In these cases, Step 7-10 are skipped, and Cloud immediately sends the reply to Protocol for
encoding and transmission in step 11.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 67 / 81

9. Node and Service Provisioning
Before a Node, and its locally connected services, can access remote services on other Nodes, it needs
to be provisioned with a certificate specifying its access rights, public keys, and other information. See
chapter “Certificates” for details.

All certificates in an RVI system are signed by the private key of a provisioning server. The public
counterpart of that key is installed in all Nodes’ Authorization as a part of the RVI software install and
setup process.

Using its private key, the provisioning server can generate new certificates and have them distributed to
Authorization on the Node the certificate was created for. A single Node can host multiple certificates,
each specifying a different set of access rights for the Node. The total sum of all certificates’ access
rights will be the access rights of the Node as a whole.

The provisioning server connects and registers to a Node as regular, locally connected service. This Node
has a pre-installed certificate, giving it access rights to Authorization on all Nodes for which the
provisioning server is to create certificates.

Authorization on each node, in addition to its dedicated authorization and validation channel, is also
registered with its local Service Edge as a regular service. Through this local connection, Authorization
announces its provisioning services to those remote services that can present the pre-installed
certificate described above.

The following chapters describe the distribution process for new certificates.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 68 / 81

9.1. Add certificate Step 1 -Send out the request
The provisioning server, having created a new certificate to give Vehicle a set of access rights, sends a
request to the Vehicle’s provisioning service and its “add_certificate” RPC command.

Figure 33 - Request containing certificate

The “certificate” element contains the new certificate to distribute.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 69 / 81

9.2. Add certificate Step 2 – Forward request to target node
The request is validated and forwarded to its target Vehicle node as described in chapter “Request
Routing”, up until step 19 (forward the request to its target service).

Figure 34 - Provisioning request transmission to target Node

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 70 / 81

9.3. Add certificate Step 3 – Deliver request to target Authorization
The target element of the request maps to the services registered by Vehicle’s Authorization. Thus the
request is delivered internally to Authorization instead of a locally connected service.

Figure 35 - Internal provisioning request delivery

Authorization, acting as a service, will store the received certificate in its internal persistent storage and
use it in all future authorization processes toward other nodes.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 71 / 81

9.4. Delete certificates

Certificate deletion follows the same flow of events as when a certificate is added, but with a different
service invoked.

Figure 36 - Delete certificate

The certificate_id element specifies the unique ID of the certificates to remove from the target node.
Authorization will permanently delete the given certificates from its persistent storage.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 72 / 81

9.5. Revoke certificates
Certificate revocation is the process of announcing to multiple nodes that a given certificate shall no
longer be accepted when received from remote nodes. This effectively expires a certificate before its
active period has run out.

While certificate deletions affects only what a single node sends out as credentials to other nodes,
revocations are sent out to multiple nodes and affects which credentials are accepted from other nodes.

In order for certificate revocation to be efficient, a mass distribution mechanism with a high success
rate, such as SMS, will be necessary.

Figure 37 - Certificate revocation

The certificate(s) specified by certificate_id element will be permanently added by the receiving
Authorization to a list of blacklisted certificates that should no longer be recognized if received from

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 73 / 81

remote nodes.

9.6. P2P Access Granting
If a node wants to grant another specific node access to its services without having to invoke a remote
provisioning server, the granting node (which will give out access rights) can issue a P2P certificate with
specified access rights to the given services. This certificate follow the same specification and use cases
as regular certificates, with the single exception that it is signed by a private key owned by the granting
node.

Once created, the granting node distributes the certificate to the granted node (which will receive
access rights) as described in chapter “Add certificate Step 1 -Send out the request” and subsequent
chapters.

The granted node can then use the certificate to sign its requests to the granting node, which will use
the public key of the certificate to validate the request.

The created P2P certificate is only useable between the two given nodes since it explicitly gives access to
the granted node (through the certificate’s “sources” element), and has been signed by the granting
node. The granted node cannot use the certificate anywhere else since no other node has the
certificate’s public key to validate the request.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 74 / 81

10. Service Edge feature set
Service Edge supports a number of operations toward connected services, Authorization, and Service
Discovery.

10.1. Local Service Registration
A local service will be able to connect to Service Edge and register itself as described in chapter “Service
Registration”. Once successfully registered the local service shall be able to send and receive requests,
as well as subscribe to and receive service availability reports from Service Edge.

10.2. Service availability reporting
When a remote or local service becomes available, other services, as well as Service Discovery, shall
have the option of being informed of the event.

A subscription command sent to Service Edge will contain a topic tree pattern for which any matching
services shall be reported.

There are two events that can trigger a service availability report to a locally connected service or
Service Discovery.

First, a service availability report may be sent by Service Discovery as a reaction to a received service
announcement from Data Link, which means that there is now a data link available to a remote service
that matches the subscribed-to topic tree pattern. In these cases a locally connected service will be
informed that a remote service is available.

Second, a local service may register directly with Service Edge, thus making the service available for
locally and remotely originated requests. In these cases, Service Edge will report the event to Service
Discovery, a service availability subscriber who in its turn will forward it to relevant remote nodes.

10.3. Process requests from local services
A locally connected service may send requests (RPCs, replies, messages, and metrics) to Service Edge for
processing and forwarding to its target service. See chapter “Request Routing” for details.

10.4. Process requests from remote services
Service Edge can also receive incoming requests from Protocol, which are to be forwarded to a locally
connected service. Service Edge will use Service Discovery to map

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 75 / 81

11. Service Discovery feature set
11.1. Register local services
Service Edge shall register locally connected services with Service Discovery, specifying their network
address and their topic tree pattern to match incoming requests against. The received information will
be used to resolve the targeted service topic tree entry to the network address of the locally connected
service that can handle the request.

11.2. Register node to network address mappings
Service Discovery will also receive information about remotely available services from Data Link. Such
services will be stored, with their corresponding network address, in Service Discovery. When the
communication channel supporting the remote service communication disappears, Service Discovery
will be informed.

Any subscribers to remote service availability will be informed of remote services becoming available
and unavailable, as long as the service topic entry matches the pattern provided with the subscription
request.

11.3. Resolve service to network address
Service Discovery will be able to map a topic entry, describing a service, to a network address that
requests can be sent to. Information about the topic entry-to-network address mapping is provided by
the two authorize and announce stages described in chapter “Service Registration”.

11.4. Process incoming service announcements
Data Link will, during its authorize and announce stage, receive service announcements from other
nodes with information about network addresses, and services. The remote service information is
forwarded by Data Link to Service Discovery, which will match the reported services against its
subscription tables and send out reports. Service Edge is a typical such subscriber and will, in its turn,
forward the information to its locally connected services.

11.5. Send outgoing service announcement
When Data Link reports that a remote node is available for communication through its authorization
step, Service Discovery will be informed.

Service Discovery will respond by filtering all available locally connected services through the
“destinations” element of the certificate provided by the remote node. See chapter “Certificates” for
details.

All local services matching the destinations entry will be forwarded to Data Link, which in its turn will

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 76 / 81

construct an announce message with the service list to the remote node. See chapter “Service
Announcement” for details.

11.6. Process communication channel availability reports
Data Link will report when communication channels to other nodes become available and disappear.
Such reports will trigger service availability reports to Service Edge, who will forward them to their
subscribing services.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 77 / 81

12. Authorization feature set

12.1. Authorize local requests
Once registered, locally connected services will submit “invoke” requests to be sent to a targeted
remote service. See chapter “Step 1 [Vehicle] - Submit request to Service Edge” for details.

Service Edge will forward the received “invoke” request to Authorization to have it validated.
Authorization will check that the signature, generated by the service’s private key, can be verified with
its public key.

Authorization will also verify that the Node that both Service and Authorization executes on has the
right to invoke the targeted service. This is done by pattern matching the “destinations” element of the
Node’s certificate against the targeted service’s topic tree entry. See chapter “Certificates” for details.

12.2. Authorize remote requests
A remote request received and decoded by Protocol and forwarded to Service Edge, will be sent to
Authorization for validation. See chapter “Step 15 [Cloud] - Authorize remote request” for details.

The request will contain a certificate, describing the rights of the sending node, and a signature
generated by the private counterpart of the certificate’s public key. Authorization will validate the
certificate, signature, and the remote node’s access rights to the targeted service.

12.3. Provision certificates
Authorization must provision, delete, and blacklist certificates when directed to do so from a
provisioning server. Please see chapter “Node and Service Provisioning” for details.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 78 / 81

13. Store and Forward feature set
13.1. Process local requests
A request received from local Service Edge will be stored until a data link to its target node is available. If
the request times out before such a link becomes available, or it times out before a reply has been
received (when applicable), a timeout is sent back to Service Edge to be forwarded to the service
originating the request.

13.2. Process remote requests
Remote requests received from Protocol needs to be stored in cases where the targeted locally
connected service is not available. Timeouts have to be sent back to the originating Node in case the
service does not become available to process the request within the timeout interval.

13.3. Process data link availability reports
When Data Link reports that a communication channel, and its associated services, is available, Store
and Forward will traverse all pending requests received from locally connected services. Those requests
targeting now available services are forwarded to Protocol for encoding and transmission to the remote
Node.

13.4. Process service availability reports
When Service Edge reports to Store and Forward that a locally connected service is available, Store and
Forward will traverse all pending requests received from remote nodes. Those requests targeting the
now available local service are sent to Service Edge to be forwarded to the service itself.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 79 / 81

14. Protocol feature set
14.1. Encode and transmit requests
Protocol shall receive requests from Store and Forward, encode them to an implementation-specific
protocol, and send them to their destination network addresses. Protocol will only be called upon by
Store and Forward after Data Link has reported that a communication channel to the destination node is
up. Thus, a network error should be reported back to Store and Forward so that it can re-queue the
request for a later retransmission.

14.2. Receive and decode requests
Inbound communication from a remote Protocol should be decoded and forwarded to Store and
Forward.

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 80 / 81

15. Data Link feature set
15.1. Setup communication channel
Data Link shall be able to setup a communication channel to a remote node, identified by a network
address. Once the communication channel is up, a report is sent to any subscribing local processes, such
as Store and Forward.

15.2. Disconnect communication channel
When a communication channel has been idle for a period of time, or is explicitly ordered to be
disconnected, Data Link shall shut it down and free the associated resources.

15.3. Transmit data payload
In cases where Protocol, instead of transmitting a data packet itself, elects to have Data Link transmit
the payload, Data Link shall forward the payload to its remote counterpart.

15.4. Receive data payload
When Data Link receives a data payload from a remote counterpart, it shall forward it to a suitable
Protocol for further processing.

15.5. Send node authorization
When Data Link has established a communication channel with a remote node, it shall send an
authorization package as described in chapter “Authorization”.

15.6. Receive remote Node authorization
When Data Link has established a communication channel with a remote node, it shall be prepared to
receive and process an authorization package as described in chapter “Authorization”.

15.7. Send service announcement
Once Data Link has authorized a remote counterpart, it shall send a service announcement package to
the remote Node as described in chapter “Service Announcement”.

15.8. Receive service announcement
Once Data Link has sent its own authorization to a remote counterpart, it shall be prepared to receive
and process a service announcement from the remote node as described in chapter “Service
Announcement”.

15.9. Report communication channel availability
Data Link shall report when communication channels to remote nodes becomes available, or disappear,
to all local components who have subscribed to such information. A typical example of such a subscriber

ID 15-456-POC-RVI-HLD Rev Draft 5 Page 81 / 81

is Store and Forward.