IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture

1609.0是一个针对V2V, V2I的概述协议，包含了组件，操作等，用来帮助更好的理解其他相关的WAVE协议，如1609.2，1609.3，1609.4等。
DSRC (dedicated short range communications) 在美国常用于指代WAVE相关的频谱或技术。在美国以外，DSRC可能会指5.8GHz上的通信技术，如电子收费。
WAVE标准提供了在支持互操作的低延迟，低开销的WAVE设备上进行安全有效可持续的通信开发。
1609.0提供了从设备，协议，标准不同视角的架构。

1609.4对802.11的MAC层进行了扩展，包含以下features:

• 信道时钟和切换
• 在BSS外使用802.11设备（信道使用，EDCA等）
• 在WAVE中使用802.11的vendor specific action和timing advertisement frames
• MAC层的再编址以支持假名

1609.4默认设备具有以下高层features:

• 发送或者接收功能
• EDCA和发送时的用户优先级

1609.3包含以下features:

• WAVE的service advertisements和信道安排
• WSM协议
• 对已有协议的支持，如LLC和IPv6，包括IPv6的配置
• 通过air接口传递控制信息

1609.3默认设备具有以下高层features:

• LLC和SNAP（subnetwork access protocol)
• IPv6或者WSMP，至少能用其中一个来发送或接收数据

5 WAVE system overview

5.1 general

WAVE系统提供了固定的和移动的（如行人和行驶车内）设备之间的安全与便捷的通信。包含了加密，认证，完整性，抗抵赖性的，隐私保密的features，这些特性会在5.13.1中介绍。WAVE系统支持应用向汽车系统和驾驶员提供更大的环境事件提醒，潜在的风险和马上要发生的危险，增加了每天驾驶的安全性，移动性和便利性。
WAVE支持一个V2V, V2I，V2D的低延迟的网络环境。为了支持低延迟通信，需要使用特殊的频谱，开发特殊的short message协议。

5.2 System componets and connectivity

1609标准不区分设备类型，灵活的支持包含RSU和OBU在内的多种设备类型。RSU是永久安装的通信时固定的设备，OBU通信时是移动的，通常安装在车上。后期还会包含手机设备和路边的行人。
一个应用服务是一个包含数据交换的由WAVE设备上的一个上层实体提供给另一个WAVE设备上相似的实体的通过WAVE通信的服务。WAVE协议是设计给设备间一致的，可互操作的，及时的交换数据的。WAVE标准确定设备角色为provider的，广播发送可用应用服务，角色为user的，选择性的加入provider提供的服务。provider和user并不是与RSU和OBU类型绑定，在很多情况下，RSU可可以做provider。
通信安全服务可能被应用调用，也可能由Data或者管理层调用，会后续在5.13.中介绍。

Protocols

5.3.1 General

WAVE协议栈如下所示：

5.3.2 WAVE Short Message Protocol

WSMP运行应用直接控制物理层特性，如传输数据时的信道号和传输功率。源应用也会提供目标设备的PSID和MAC地址，包括可能的组地址。目的设备上的应用实体可以通过PSID来正确接收WSM，如果PSID不是本设备上的应用服务所需，那么这个消息将会被丢弃。WSM设计成消耗最少的信道资源，所以它在CCH和SCH上都能传输。
下面给出一个WSM的传输例子。一个源设备应用组件一个WSM数据包，把它的地址填为广播MAC地址。根据它的配置，应用选择合适的信道信息（功率，数据速率）来控制这个发送，调用WSM请求原语（WSM-WaveShortMessage.request) 来请求WSMP来传递数据到底层服务，随后在信道上传输出去。一个接收设备接收到该数据包，把它传递给通信协议栈。WSMP根据PSID把它传给目的接收应用。这时，接收应用知道源发送设备的存在知道发送设备的地址，如果有需要它可以继续通过单播或者广播MAC地址来和源设备通信。
WSMP非常适合基于消息的应用，该应用受制于间断的无线连接。附录C提供了WSMP在安全和电子收费场景的应用实例。

5.3.3 Internet Protocol

WAVE支持IPv6。WAVE标准没有明确规定IPv6以上的上层协议。IP协议适合提供给应用所需的网络包，如发送到远端网络主机的路由包。IPv6提供了分片重组功能。IP协议上2个流行的传输协议有UDP和TCP。UDP提供了WSMP不提供的端口号和校验和，TCP提供了端口号和保证端到端可靠性的确认重传机制。
NOTE - TCP在很多场景下很适用，但是WAVE环境下丢包率高，错误率高，可传输时长短，TCP的适用性需要再考虑。
1609.3定义了一个WAVE Service Advertisement (WSA)来支持基于IP的应用服务。一个RSU可以通过RSU router来广播所有消息，用来给OBU访问基于IPv6的应用服务。

5.3.4 Management plane

管理服务与多个Data plane实体相关，来提供系统操作必要的层级功能。这些功能包括信道协调所需的时间同步和执行服务请求与广播。1609.4规定了对IEEE 802.11 MAC层管理实体的扩展（MLME)，1609.3规定了WAVE的管理实体（WME)，5.13中描述的安全服务也在这个管理plane中，可以被WME或上层应用调用。

5.4 Interfaces

设备间接口如下：

5.5 The 5.9 GHz spectrum allocation

下图是美国FCC规定的用以DSRC的无线信道定义。这要求部署在美国的WAVE系统需要使用下列信道，或者他们的子集。

FCC channel allocation

• 5.850 GHz 到 5.855 GHz保留
• 信道178是控制信道CCH
• 信道172，174，176，180，182和184是服务信道SCH
• 信道174和176，信道180和182可以组合成2个20MHz的信道，即信道175和181
• 信道172和184是设计用以公共安全应用的，包括生命安全和财产安全。根据FCC，信道172是用以V2V安全通信，用来做事故避免和减缓的，生命安全和财产安全的应用。信道184是用来做高功率，长距离的公共安全和财产安全的应用，包括十字路口车祸避免。
  WAVE设备可用的无线信道由在1609.4的management information base (MIB) 定义。WAVE协议区分控制信道和服务信道，但是没有按FCC的要求强制规定服务信道的不同规则。

5.6 Channel types

WAVE定义了2种无线信道：一个单独的控制信道和多个服务信道。CCH保留给WSMP消息和系统管理消息如WSA用。SCH用以通用的应用数据传输，可以通过WSA来协调。SCH也可以由别的方法来安排，不需要advertisement。在SCH上，WAVE允许IPv6传输，也允许WSMP和管理包传输。
WAVE标准一方面规定CCH用以WSA广播，不允许CCH上的IP传输，但是另一方面并没有规定这么多信道怎么用。譬如1609并没有定义一个单独的安全信道，任一一个控制或服务信道都可以作为安全信道。
某个信道可能被规则设计为安全所用，如5.5中的例子。现在展望，信道172未来可能在美国的部署会被设计为安全信道，但从WAVE协议的角度来说它还是SCH。

5.7 Communication services

5.7.1 General

WAVE通信服务支持信息使用WAVE协议通过空中接口从一个设备的高层实体传输到另一个设备的高层实体。
应用使用服务原语通过SAP来向WAVE协议或管理实体发起服务请求。应用也可以通过WAVE通信向其他应用提供应用服务，如WAVE设备间的客户端-服务器模式的地图信息交换。
高层可能通过CCH或SCH交换信息。WSMP传输可能使用任一信道，但是IPv6只能在SCH上传输。接下来会讲3种通信场景，其中一个使用CCH，另2个使用SCH。

5.7.2 CCH communications

第一个场景是CCH通信。这个场景不涉及空中协调。只有WSMP和管理包能在CCH上传输。WSM可能是单播的，也可能是组播或广播的，可以被附近任一一个传输时刻信道切换到CCH上的设备接收到。CCH通信可以被用于向附近WAVE设备请求时间信息。发出请求的设备通过WSMP广播一个请求消息，收到的设备会通过一个管理帧来返回时间信息，单播或广播都可以。

5.7.3 SCH communications

多个应用服务机制，广播的或非广播的，都在同一时间同一地点使用相同的SCH。在同一个SCH上的操作消耗同一个设备的PHY层资源，如同一时刻在同一个信道上的PHY操作。

5.7.3.1 Unadvertised application-service opportunity

第二个场景中，一个非广播式应用服务，应用会可能会使用一个预先定义好的SCH。一个SCH用于特殊用途可以提前配置，或通过其他的OOB机制来决定。任一一个可通信的WAVE设备（如切换至正确信道）都参与进这个非广播式应用服务。实际上任何参与者都不会被分配任何角色。信道172上的安全通信就是一个例子，所有参与的设备的信道172都提前配置成安全信道，应用协议设定定期广播消息（如Basic Safety Message)。

5.7.3.2 Advertised application-service opportunity

在第三个场景中，WAVE为广播式应用服务提供选择。在这个场景中，一个WAVE设备作为provider角色。provider传输WSA消息，标识和描述了应用服务和它使用的SCH，会在5.8中详述。provider WAVE设备切换到SCH上用以与其他参与者交换消息。其他作为user的WAVE设备是这个应用服务的潜在参与者。接收到一个带advertised应用服务的WSA的user，可以选择加入在provider所在的SCH来参加这个服务。这时，provider和user可以交换这个应用服务的信息了。
下面是一个例子。一个固定的路边provider设备，发送一个WSA，包含了绑定一个交通咨询服务的PSID的service info，相应的WSA的channel info指定了使用SCH182. Provider的交通咨询服务应用在SCH182上广播交通预警消息，也通过IPv6回复那些需要更多信息的请求。车辆user设备进入RSU的覆盖范围后，从CCH上接收WSA，解析service info。对交通咨询服务感兴趣的话，解析出相关PSID，然后切换信道到SCH182，这样就可以在SCH182上访问交通咨询应用服务了。
需要注意的是建立一个广播式应用服务的信息交换只涉及WSA，其他的信息交换是应用本身的事。
选择哪个data plane协议来支持一个特定的应用服务是由参与者本身决定的。下面描述了选择合适的协议的方法因素：

• 基于PSID或者PSC (Provider Service Context) 的信息选择
• WSA的service info里面含有IP地址则选IP协议，IP协议以上的协议没有指定
• 其他的都选WSMP

5.7.3.3 Device roles in an advertised application-service opportunity

在一个广播式应用服务中，一个WAVE设备可能作为一个或两个角色存在，provider或者user。像在5.7.3.2和5.8中描述的，provider负责传输包含广播应用服务信息的WSA。user监控WSA，来选择是否加入这个服务。过程如下图所示：

开始时，WAVE设备并没有发出支持这个应用服务的请求。在1a中，provider设备上的应用发起一个Provider Serivice请求原语到WME。这个请求包含了这个服务的特征，如需广播的PSID，服务优先级，广播重复速率和所需的SCH。WME时可以拒绝这个请求的，如它的无线信道资源被其他服务请求占用。如果没有拒绝，那么WME继续填充这个请求。服务参数填充在WSA中的service info段，信道参数填充在channel info段。
在1b步中，WME收到请求后会和Security Processing Services交互来给这个WSA签名。然后，在1c步中，WME会和MLME交互来分配合适的SCH和协调CCH上WSA的周期传输。WSA会包含在802.11的管理帧中，具体格式会在1609.4和1609.3中描述。
在1c步时，provider设备同时也会切换信道到SCH，此时它也是这个广播式服务应用的参与者。
另一个WAVE设备作为user角色。在2a中一个应用发送一个user service请求到WME。成功处理这个请求后，WAVE设备开始等待接收WSA。2b中，user设备接收到WSA。如果这个WSA是签名过的，根据user service请求，需要安全验证，那么WME就会在2c中调用Security Processing Service来解析WSA。
如果安全认证通过，WME根据WSA service info中的PSID来判断收到的WSA的应用服务是否是user service request中的应用服务。如果不是，或者安全认证不通过，那么这个WSA将被忽略，设备继续监控CCH，等待接收下一个WSA。
如果是user service request中的服务，那么WME在2d中通知应用。此时，假如无线资源够用，会有多种操作可选，都在1609.3中描述。根据user service request， WME会在2e中自动的开始加入这个广播应用服务，或者等待应用的确认是否加入。如果加入，设备就会开始访问相关的SCH。此时，两个设备都加入了这个应用，并处于同一个SCH，可以开始应用数据的传输了。
其他的WAVE设备也还可以作为user加入这个应用 。一个WAVE设备可以接收多个provider和user的Service request，同时作为provider和user角色存在于不同的应用服务。

5.7.3.4 Ending participation in an application-service opportunity

如果一个设备加入了一个应用服务，加入状态会一直保持到本地结束。WAVE标准没有用空中包交换来确认结束。在设备内部，WME把结束决定发给MLME来结束参与，如停止信道访问，停止在WSA中广播这个应用服务。WME也会通知影响到的应用。WME停止服务参与有很多原因，比如，应用操作完成会使应用发送结束请求，或者WME可能需要重新分配本地通信资源来相应更高优先级的应用服务。

5.7.3.5 IPv6 services

WAVE系统可以支持普通的IPv6应用。举个例子，一个RSU连接进Internet，它被配置成一个Internet访问服务的provider，发送一个广播Internet访问服务的WSA。这个WSA中和service info, channel info一样，可能包含WAVE Routing Advertisement(WRA). 这个WRA中包含了一个OBU访问Internet所需的所有信息，并且移除了对ICMPv6 Router Advertisement message的需要。
基于WRA中的信息，OBU可以配置自己的IPv6栈来访问Internet，使用RSU设备作为网关，如下图所示：

如果IPv6应用的host是RSU的话，那么就不需要Internet连接或者WRA，本地的service info和channel info就包含在RSU的发出的WSA中。
WAVE设备，比如OBU，也可以不通过RSU而加入IPv6本地网络，这种情况下，OBU可以发送包含相关service info和channel info的WSA。
IPv6提供邻居发现功能，邻居缓存里面放有通信范围内的设备的IP地址和MAC地址。这个功能通过组播-回复机制实现，在RFC2461里有描述，会在信道上产生大量的传输信息。在一些WAVE系统中，它需要保持信道上的传输量到一个最小值，它会建议邻居缓存通过其他方式实现，比如积极监控空中传输包。不过1609标准并没有排除掉RFC2461中的邻居发现功能。
在一个WAVE系统中，邻居缓存的成员通常基于接收到的包含MAC地址和IP地址的包构建。当访问一个服务信道时，一个加入无路由的通信（包不需要通过路由来发送给服务器）的host会把这个服务器加入到它的邻居缓存中。如果这个通信时需要路由的，那么客户端主机会把网关加入到它的邻居缓存中。此外，一个WAVE设备还可以通过从一个本地链路的IPv6地址接收到的ICMPv6和IPv6 PDU来增加邻居缓存，可以将它的MAC头中的MAC地址和源IP地址关联起来。