using acronym package for all abbreviations

also began working on "identifiers" part
This commit is contained in:
Trolli Schmittlauch 2018-06-05 18:16:49 +02:00
parent 207b8c19c8
commit d35df3f15b
2 changed files with 65 additions and 29 deletions

View file

@ -1,19 +1,37 @@
\todo{include long version of abbreviations at first mention}
\textbf{AU}: application unit
\begin{acronym}[GN6ASL]
\textbf{CCU}: communication \& control unit
\acro{AU}{application unit}
\textbf{ETSI}: European Telecommunications Standards Institute
\acro{BTP}{Basic Transport Protocol}
\textbf{ITS}: Intelligent Transportation Systems
\acro{CCU}{communication \& control unit}
\textbf{LS}: GeoNetworking Location Service
\acro{ETSI}{European Telecommunications Standards Institute}
\textbf{LT}: GeoNetworking Location Table
\acro{GN}{GeoNetworking}
\textbf{OBU}: on-board unit
\acro{GN6ASL}{GeoNetworking to IPv6 Adaptation Sub-Layer}
\textbf{RSU}: road-site unit
\acro{GNSS}{Global Navigation Satellite System}
\textbf{VANET}: vehicular ad-hoc network
\acro{IPv6}{Internet Protocol version 6}
\acro{ITS}{Intelligent Transportation Systems}
\acro{LS}{GeoNetworking Location Service}
\acro{LT}{GeoNetworking Location Table}
\acro{OBU}{on-board unit}
\acro{OSI}{Open Systems Interconnection}
\acro{RSU}{road-site unit}
\acro{VANET}{vehicular ad-hoc network}
\acro{V2X}{vehicle-to-everything}
\end{acronym}

View file

@ -25,6 +25,7 @@
\fi
\usepackage[]{svg}
\usepackage{acronym}
\usepackage{hyperref}
\newcommand{\comment}[1]{{\parindent0pt\fbox{\begin{minipage}{0.45\textwidth}{\em #1}\end{minipage}}}}
@ -148,15 +149,15 @@ Networks, Intelligent transportation systems, Security, Mesh networks, Privacy
\subsection{ITS Architecture}
This section gives a brief overview of the ETSI architecture for Intelligent Transport Systems. It isn't meant to be elaborate but has a focus on identifiers and other message contents allowing linkability of messages.
This section gives a brief overview of the \ac{ETSI} architecture for Intelligent Transport Systems. It isn't meant to be elaborate but has a focus on identifiers and other message contents allowing linkability of messages.
VANETs have some special requirements: Due to many nodes being constantly on the move at higher speeds, tolerance for quickly changing topologies and low-latency communication are important points. Multi-hop mesh-networking is an important ability to keep the network functional in areas without designated infrastructure.
\acp{VANET} have some special requirements: Due to many nodes being constantly on the move at higher speeds, tolerance for quickly changing topologies and low-latency communication are important points. Multi-hop mesh-networking is an important ability to keep the network functional in areas without designated infrastructure.
A VANET consists of different kinds of ITS stations: \\
On-board units (OBU) residing inside vehicles can be divided into the communication and control unit (CCU), managing the ITS specific network communication over the car's wireless interfaces, and application units (AU) utilising the network services provided by the CCU to communicate transparently over a standard IPv6 stack. \\
On the stationary infrastructure side, road-site units (RSU) can either just provide some special local services or even be connected to a network operator's infrastructure and thus provide an uplink to the internet.
A \ac{VANET} consists of different kinds of ITS stations: \\
\acfp{OBU} residing inside vehicles can be divided into the communication and \acl{CCU}, managing the \ac{ITS} specific network communication over the car's wireless interfaces, and \acfp{AU} utilising the network services provided by the \ac{CCU} to communicate transparently over a standard \acs{IPv6} stack. \\
On the stationary infrastructure side, \acfp{RSU} can either just provide some special local services or even be connected to a network operator's infrastructure and thus provide an uplink to the internet.
The protocol architecture of ITS stations according to the ETSI reference architecture \cite{europeantelecommunicationsstandardsinstituteetsiETSI3026652010} is mostly based on the well-known OSI layer model.
The protocol architecture of \ac{ITS} stations according to the \ac{ETSI} reference architecture \cite{europeantelecommunicationsstandardsinstituteetsiETSI3026652010} is mostly based on the well-known \ac{OSI} layer model.
\begin{figure}
% center graphic
@ -166,23 +167,23 @@ The protocol architecture of ITS stations according to the ETSI reference archit
\label{fig:etsi-its-arch}
\end{figure}
OSI layers 1 and 2 are combined into the \textit{Access} layer, OSI layers 3 and 4 into the \textit{Networking \& Transport} layer and OSI layers 5, 6 and 7 are put into the \textit{Facilities} layer (see Fig. \ref{fig:etsi-its-arch} ). \\
The two vertical \textit{Management} and \textit{Security} layers provide supporting functionality throughout the whole stack. \textit{Applications} make use of the ITS-station services and thus sit on top of it all.
\ac{OSI} layers 1 and 2 are combined into the \textit{Access} layer, \ac{OSI} layers 3 and 4 into the \textit{Networking \& Transport} layer and \ac{OSI} layers 5, 6 and 7 are put into the \textit{Facilities} layer (see Fig. \ref{fig:etsi-its-arch} ). \\
The two vertical \textit{Management} and \textit{Security} layers provide supporting functionality throughout the whole stack. \textit{Applications} make use of the \ac{ITS}-station services and thus sit on top of it all.
\todo{participants, structure, special requirements: changing topology, speed, realtime}
Designed for modularity, the ETSI ITS architecture allows for a big number of access protocols. Similarly, a great variety of applications can run on top of the stack. Because of that variety, these two layers are considered out-of-scope of this survey.
Designed for modularity, the \ac{ETSI} \ac{ITS} architecture allows for a big number of access protocols. Similarly, a great variety of applications can run on top of the stack. Because of that variety, these two layers are considered out-of-scope of this survey.
The \textbf{Networking \& Transport} layer takes care of addressing and routing of messages within the ITS network and multiplexing them to higher-level services. Similarly to the OSI model, the groundwork of this functionality is provided by various networking protocols: \\
ETSI explicitly mentions the usage of IPv6 (possibly equipped with mobility support), the CALM FAST protocol \cite{TN_libero_mab2} and the GeoNetworking protocol, which can also be used to encapsulate IPv6 packets.
The \textbf{Networking \& Transport} layer takes care of addressing and routing of messages within the ITS network and multiplexing them to higher-level services. Similarly to the \ac{OSI} model, the groundwork of this functionality is provided by various networking protocols: \\
\ac{ETSI} explicitly mentions the usage of \ac{IPv6} (possibly equipped with mobility support), the CALM FAST protocol \cite{TN_libero_mab2} and the \acf{GN} protocol, which can also be used to encapsulate \ac{IPv6} packets.
CALM FAST \cite{TN_libero_mab2} is a non-IP port-mapper protocol designed for single-hop communication between ITS stations and extensible with additional features. Due to a lack of proper access to the standard document, this protocol is considered out-of-scope of this survey.
\subsubsection{GeoNetworking}
GeoNetworking (GN, \cite{europeantelecommunicationsstandardsinstituteetsiETSI30263612014} and following) is an ETSI-standardized networking protocol for routing and forwarding packets through VANETs based on geographical Information. It sits between the link and network layer and provides its services to other networking and transport protocols. The background section of \cite{sandonisVehicleInternetCommunications2016} gives a good high-level overview of the GN networking architecture and the rationale behind it.
\acf{GN} (\cite{europeantelecommunicationsstandardsinstituteetsiETSI30263612014} and following) is an \ac{ETSI}-standardized networking protocol for routing and forwarding packets through \acp{VANET} based on geographical Information. It sits between the link and network layer and provides its services to other networking and transport protocols. The background section of \cite{sandonisVehicleInternetCommunications2016} gives a good high-level overview of the \ac{GN} networking architecture and the rationale behind it.
Every GN node has to know its geographical position, e.g. through GNSS (Global Navigation Satellite Systems), for the routing to work. The services provided by GN are:
Every \ac{GN} node has to know its geographical position, e.g. through \acp{GNSS}), for the routing to work. The services provided by \ac{GN} are:
\begin{itemize}
\item geo-unicast: routing a packet to a single node at a specific location
@ -192,24 +193,41 @@ Every GN node has to know its geographical position, e.g. through GNSS (Global N
\item geo-anycast: routing packet to an arbitrary node within a specified geographical area
\end{itemize}
For this to work, each node maintains a location table (LT) with the positions of its direct neighbours. This LT is populated with information from periodically-sent beaconing messages, advertising a node's position, GN address, its speed, station type \todo{check advertised information}. This information is also included in all other sent GN packets. LT entries have a lifetime attached, after which they expire if not refreshed periodically.
For allowing to retrieve the position of non-neighbour nodes, the Location Service (LS) forwards request packets, until the node with the destination GN address is found and has replied via geo-unicast or a retransmission counter has expired.\todo{influence of frequent pseudonym change}
For this to work, each node maintains a \ac{LT} with the positions of its direct neighbours. This \ac{LT} is populated with information from periodically-sent beaconing messages, advertising a node's position, \ac{GN} address, its speed, station type \todo{check advertised information}. This information is also included in all other sent \ac{GN} packets. \ac{LT} entries have a lifetime attached, after which they expire if not refreshed periodically.
For allowing to retrieve the position of non-neighbour nodes, the \ac{LS} forwards request packets, until the node with the destination \ac{GN} address is found and has replied via geo-unicast or a retransmission counter has expired.\todo{influence of frequent pseudonym change}
Security properties of GN messages are ensured by signing (authenticity), encrypting (confidentiality) the messages and checking their plausability and consistency. The necessary information for that is given in a security header \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636412017}.
Security properties of \ac{GN} messages are ensured by signing (authenticity), encrypting (confidentiality) the messages and checking their plausability and consistency. The necessary information for that is given in a security header \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636412017}.
\subsubsection{IPv6}
IPv6 \cite{RFC8200} \nocite{baeckerRFCE014IPv6} specifies the 6th version of the Internet Protocol, the routing protocol used in the Networking layer of the internet. Relevant details for VANETs are the addressing using 128 bit long IP addresses \cite{RFC4291} with the first up to 64 bits specifiying the network part and the last 64 bits specifying the interface ID (node ID) within that subnetwork. Additionally to the globally unique routable address, nodes are also addressable in the scope of the same OSI layer 2 link using their link-local address automatically derived from lower-layer identifiers. Together with the huge number of globally unique IPv6 addresses, this new property makes it usable for vehicular ad-hoc networks. Another improvement in IPv6 is the \textit{router advertisement} \cite{RFC4861} of clients, where routers just periodically announce their parameters so clients are able to derive an address themselves without further negotiation.
\acsu{IPv6} \cite{RFC8200} \nocite{baeckerRFCE014IPv6} specifies the 6th version of the Internet Protocol, the routing protocol used in the Networking layer of the internet. Relevant details for \acp{VANET} are the addressing using 128 bit long IP addresses \cite{RFC4291} with the first up to 64 bits specifiying the network part and the last 64 bits specifying the interface ID (node ID) within that subnetwork. Additionally to the globally unique routable address, nodes are also addressable in the scope of the same \ac{OSI} layer 2 link using their link-local address automatically derived from lower-layer identifiers. Together with the huge number of globally unique \ac{IPv6} addresses, this new property makes it usable for vehicular ad-hoc networks. Another improvement in \ac{IPv6} is the \textit{router advertisement} \cite{RFC4861} of clients, where routers just periodically announce their parameters so clients are able to derive an address themselves without further negotiation.
\subsubsection{IPv6 over GeoNetworking}
Transparently exposing IP networking to higher layers allows re-using existing services based on the classical internet TCP/IP stack without modification. The GeoNetworking to IPv6
Adaptation Sub-Layer (GN6ASL) \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636612014} specifies a mechanism for sending IPv6 packets over the GN protocol by using it as a sub-IP coupling layer. GN takes care of encapsulating and routing the IP packet to its final destination node, so that the whole underlying VANET looks like a flat layer 2 network to IP services.
GN6ASL specifies how to derive a GN address from an IPv6 address and extends IPv6 with some GeoNetworking specific extensions like geographic multicast, Geographically
Transparently exposing IP networking to higher layers allows re-using existing services based on the classical internet TCP/IP stack without modification. The \acf{GN6ASL} \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636612014} specifies a mechanism for sending \ac{IPv6} packets over the GN protocol by using it as a sub-IP coupling layer. \ac{GN} takes care of encapsulating and routing the IP packet to its final destination node, so that the whole underlying \ac{VANET} looks like a flat layer 2 network to IP services.
\ac{GN6ASL} specifies how to derive a \ac{GN} address from an \ac{IPv6} address and extends \ac{IPv6} with some \acl{GN} specific extensions like geographic multicast, Geographically
Scoped stateless Address Configuration or (un)reachability detection.
\subsubsection{BTP}
The transport layer protocol above \acl{GN} is the \acf{BTP} \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636512017}. It provides a connectionless multiplexing/ demultiplexing of datagrams to the layers above, adding minimal overhead while providing an unreliable packet transport comparable to UDP.
If \ac{IPv6} over \ac{GN} is used at the network layer, transport protocols like TCP and UDP from the standard internet protocol suite can of course be used, too.
\todo{facilities layer, management and security layer too?}
\subsection{Identifiers}
There are many different addresses, IDs or other identifying information scattered around the network layers. This sections gives a list of these identifiers and the information encoded in them.
\subsubsection{GeoNetworking}
Each \ac{GN} node is identified by a \ac{GN} address
\ac{GN} packets have a basic, a common and an optional extended header.
\subsubsection{BTP}
\section{Pseudonym Schemes}
\subsection{Pseudonym Schemes for ETSI ITS Systems}