CN116055253A - 多网络通信系统 - Google Patents

Abstract

提供了一种多网络通信系统，包括：第一子网络，第一子网络内包含至少一个本地服务，至少一个本地服务中的每一个映射到对应的内部VLAN并经由对应的内部VLAN以及第一子网络与第二子网络之间的第一虚拟网络端口对来收发去往或来自通信系统的外部的第一数据包；以及第二子网络，与第一子网络通信地耦合，第二子网络被配置成直接转发来自或去往外部的第一数据包。

Description

多网络通信系统

技术领域

本公开涉及通信技术领域，尤其涉及一种包含多个子网络的多网络通信系统。

背景技术

随着人工智能和芯片技术的发展，汽车内集成了越来越多的功能模块，诸如自动驾驶、影音娱乐、汽车智能。这导致车辆内的控制器、例如ECU(Electronic Control Unit：电子控制单元)越来越多。这些系统需要大量的数据在ECU之间或者ECU和云之间进行交互。

传统的车载通信方案包括LIN(Local Interconnect Network：局部互联网络)、MOST(Media Oriented System Transport：面向媒体的系统传输)、CAN(Controller AreaNetwork：控制器局域网)和FlexRay等。随着数据传输量以及传输速率要求的提高，这些通信方案难以满足高带宽低延时的需求。尤其是，车载系统对于传感器及控制系统的响应速度有非常高的要求，需要保证毫秒级别(或更小)的传输延迟。

为了解决这一需求，开发了车载以太网。车载以太网在民用以太网协议的基础上，改变了物理端口的电气特性，并结合车载网络需求专门定制了一些新标准。目前，车载以太网以诊断DoIP(Diagnostic communication over Internet Protocol：通过网络协议进行诊断通信)、中间件SOME/IP(Scalable service-Oriented Middleware over IP：基于IP协议的面向服务的可扩展性通信中间件协议)、EthernetAVB(Ethernet Audio/VideoBridging：以太网音视频桥接)作为车载以太网自有协议栈，以满足车载环境中特殊需求，例如，车载设备对于电气特性的要求(EMI(电磁干扰)/RF(辐射))，车载设备对高带宽、低延迟以及音视频同步等应用的要求，车载系统对网络管理的需求等。

然而，随着越来越多的模块的应用以以太网为载体，不同系统和不同厂商的硬件和软件需求导致车载以太网的资源被极大地占用，以智能座舱为中心构建安全可靠的汽车以太网网络拓扑成为高性能、高可靠性汽车的亟需解决的问题。

发明内容

本公开的一个方面提供了一种多网络通信系统，包括：第一子网络，第一子网络内包含至少一个本地服务，至少一个本地服务中的每一个映射到对应的内部VLAN并经由对应的内部VLAN以及第一子网络与第二子网络之间的第一虚拟网络端口对来收发去往或来自通信系统的外部的第一数据包；以及第二子网络，与第一子网络通信地耦合，第二子网络被配置成直接转发来自或去往外部的第一数据包。

在一个可选实施例中，第一子网络与第二子网络之间的内部通信可以通过不同于第一虚拟网络端口对的专用虚拟网络端口对进行。

在一个可选实施例中，在第二子网络内部，第一数据包可以经由在数据链路层上工作的网桥直接与外部之间进行转发。

在一个可选实施例中，第一子网络可以具有唯一的外部IP地址。

在一个可选实施例中，第一子网络可以包含用于将来自外部的第一数据包中的五元组信息的至少一部分映射到用于接收第一数据包的本地服务的私有IP地址的第一映射表。

在一个可选实施例中，第一子网络可以还包含用于将私有IP地址映射到的对应的内部VLAN的第二映射表。

在一个可选实施例中，用于接收第一数据包的内部VLAN可以与用于发送第一数据包的内部VLAN相同。

在一个可选实施例中，至少一个本地服务中的每一个可以在对应的内部VLAN上侦听数据。

在一个可选实施例中，第一子网络可以通过虚拟网络端口与第二子网络通信，并且第二子网络通过实体网卡与外部通信。

在一个可选实施例中，第二子网络可以提供安全服务。

附图说明

图1示出以太网在车载系统中的示例应用。

图2示出作为多网络通信系统的一个示例的车载以太网的示例架构。

图3示出以往的多IP网络的地址分配方式。

图4示出根据本公开的实施例的单IP多VLAN的地址分配方式。

图5示出根据本公开的实施例的应用了单IP多VLAN地址分配的座舱系统100的通信架构的示意图。

图6示出OSI参考模型的示意图。

图7示出根据本公开的实施例的座舱系统100的通信解耦的示意图。

图8示出根据本公开的实施例的应用了策略路由的座舱系统100的通信方案的示意图。

图9示出根据本公开的实施例的在图8所示的座舱系统100中执行的报文传输的示例过程900的流程图。

具体实施方式

在以下描述中，陈述了众多特定细节。然而，应当理解，可在没有这些特定细节的情况下实践本发明的实施例。在其他实例中，未详细示出公知的电路、结构和技术，以免使对本描述的理解模糊。

说明书中对“一个实施例”、“实施例”、“示例实施例”等的引用表明所描述的实施例可以包括特定的特征、结构或特性，但是每个实施例不一定都包括该特定的特征、结构或特性。此外，此类短语不一定是指同一个实施例。此外，当结合实施例描述特定的特征、结构或特性时，认为结合无论是否被明确描述的其他实施例而影响此类特征、结构或特性是在本领域技术人员的知识范围之内的。

出于本公开的目的，短语“A和/或B”意指(A)、(B)或(A和B)。出于本公开的目的，短语“A、B、和/或C”意指(A)、(B)、(C)、(A和B)、(A和C)、(B和C)或(A、B和C)。

下文以汽车为平台描述本公开的实施例，但应理解，本公开的通信架构和技术也可应用于其他涉及在多个域(下文有时也称为子网络)和/或ECU之间进行通信的平台，诸如其他类型的机动交通工具(例如，摩托车、公共汽车、牵引车、牵引车-拖车交通工具或建筑设备)、轨道交通工具(例如火车或有轨电车)、船舶(例如船只或轮船)、飞行器(例如飞机或直升机)或航天器(例如卫星)等。

图1示出以太网在车载系统中的示例应用。目前，越来越多的车载系统以以太网为载体，例如图1所示的V2X(Vehicle to Everything：车对外界的信息交换)、通信系统、音频系统、摄像头系统、娱乐系统、DMS(Driver monitoring system：驾驶员监测系：统)。根据不同的整车厂或者客户提出的各种各样的要求，这些系统/ECU以独立的域(下文有时也称为子网络)集成在车身内。各个域可能包含一个或多个应用。至少部分地取决于应用的数量，各个系统可能占用一定数量的IP地址。然而，随着这些域和应用数量的增加，对以太网的资源调度和网络拓扑安全性提出了挑战。

本公开的目的之一在于提供一种多网络通信系统，能够改善各个子网络对网络资源的占用。各个子网络可以来自不同的厂商，使用不同的标准和协议，提供不同的服务。这些子网络可以共同接入到车载以太网中，进行子网络内部、子网络之间和/或各个子网络与外部的通信。向外部提供服务的形式例如可以是从其他网络、设备或者云端接收请求消息，由子网络内的本地服务处理该请求消息后向该其他网络、设备或者云端回复响应消息。

取决于网络端口的布置，响应消息可以直接发送给外部或者经由其他子网络发送给外部。例如，没有设置实体网卡的子网络可以通过虚拟网络端口将消息传递到设置有实体网卡的子网络然后发送到外部。实体网卡可以设置在对网络传输实时性和安全性要求较高的子网络。

图2示出作为多网络通信系统的一个示例的车载以太网的示例架构。图2中，多网络通信系统的一个实现可以是座舱系统100，其包括两个子网络(域)，即QNX 101和Android102。

QNX 101和Android 102是车载应用内常用的操作系统。QNX101采用非开源的微内核架构，具有较高的功能性和安全性，可以用来提供仪表和动力系统以及各类安全服务，例如图2中所示的ADCU(Automated Driving Control Unit：自动驾驶域控制器)服务、HOD(Hands Off Detection：离手检测)服务、HUD(Head-up Display：抬头显示)服务、DoIP诊断服务等。

Android 102具有开源开放、良好的开发环境，在移动端积累了大量的应用生态，在车载娱乐领域具有优势。因此，在Android 102的子网络通常具有大量的本地服务。Android 102内的本地服务是可修改且可扩展的，因此其本地服务占用的网络资源也是变化的。相比之下，QNX 101内的本地服务可以是固定的，其占用的网络资源也是相对固定的。

QNX 101和Android 102内的本地服务可以来自不同的开发商，具有不同的通信要求，诸如通信协议、源端口、目的地端口等。不同开发商的本地服务可能使用相同的通信协议和/或端口，也可能不同。

例如，QNX 101的本地HUD服务(未图示)可以通过CAN与外部的HUD模块121传输数据，本地HOD服务(未图示)可以通过LIN协议与外部的HOD模块122传输数据，本地ADCU服务(未图示)可以通过车载以太网与外部的ADCU模块123传输数据。QNX 101还可以通过网关130与外部设备传递数据，诸如图2所示的PC诊断仪，来执行DoIP诊断。例如，厂商可以通过DoIP诊断来从QNX 101获取本车辆的运行数据。

TBOX(Telematics-BOX)模块140可以提供与移动端的交互。例如，座舱系统100内的本地引用可以通过TBOX模块140来与移动端、远端云或者服务器实现交互。作为一个示例，用户可以通过移动端应用程序发送获取车辆信息的请求。该请求经由TBOX模块140到达座舱系统100。座舱系统100内的本地服务提供对该请求的响应。该响应可以通过TBOX模块140回复到移动端。

QNX 101和Android 102内本地服务的增多导致QNX 101和Android 102占用更多的IP地址。图3示出以往的多IP网络的地址分配方式。如图3所示，示出了车载环境中的TBOX服务、DVR(行车记录仪)服务、DoIP服务和SOME/IP服务，它们分别分配有一个IP地址(地址1～地址4)。虚线框201表示包含这些服务的一个子网络。因此，图3中，子网络201需要分配四个外部IP地址。

图4示出根据本公开的实施例的单IP多VLAN的地址分配方式。如图4所示，子网络201A内的TBOX服务、DVR服务、DoIP服务和SOME/IP服务分别映射到对应的VLAN(VirtualLocal Area Network：虚拟局域网)通道，并通过对应的VLAN通道与外部通信。与图3所示的占用四个外部IP地址的子网络201不同，本实施例的子网络201A只占用唯一的外部IP地址。内部的本地服务(TBOX服务、DVR服务、DoIP服务和SOME/IP服务)可以分配私有IP地址并通过对应的VLAN(VLAN 2～VLAN 5)映射到该唯一的外部IP地址。私有IP地址可以由制造商预先决定，不对外公开。私有IP地址到外部IP地址的转换可以通过已有的NAT(NetworkAddress Translation：网络地址转换)技术来实现。通过采用这种单一IP地址到多个私有IP地址的转换，子网络201A对所在的车载以太网的外部IP地址资源的占用得以减少。

图5示出根据本公开的实施例的应用了单IP多VLAN地址分配的座舱系统100的通信架构的示意图。本实施例中，座舱系统100可以通过可选的外部交换机120连接到外部的ADCU模块123，并可以进一步经由可选的网关130连接到TBOX模块140。

Android 102具有一个外部IP地址“198.18.34.15”，内部设置了四个私有IP地址“10.1.2.6”、“10.1.3.6”、“10.1.4.6”和“10.1.5.6”供本地服务使用。私有IP地址与本地服务的对应关系可以根据需要设置和变更。取决于本地服务的数量，私有IP地址的一部分可以不被启用或在本地服务变更后启用。本实施例中，四个私有IP地址“10.1.2.6”、“10.1.3.6”、“10.1.4.6”和“10.1.5.6”分别对应到四个VLAN通道，即VLAN2～VLAN4。各个VLAN通道可以具有不同的优先级。可以向优先级更高的本地服务分配对应到具有更高优先级的VLAN通道的私有IP地址。私有IP地址“10.1.2.6”、“10.1.3.6”、“10.1.4.6”和“10.1.5.6”与外部IP地址“198.18.34.15”之间可以通过NAT进行相互转换。例如，可以设置私有IP地址与外部IP地址的映射表。

例如，当外部请求传输到Android 102时，其报文中的目的地地址为Android 102的外部IP地址“198.18.34.15”。Android 102内的路由模块可以根据报文中的五元组信息确定该报文的目的地，例如被分配私有IP地址“10.1.2.6”的本地服务。五元组信息用于确定报文的来源和目的地，包括源地址、目的地地址、通信协议、源端口、目的地端口。路由模块由此可以利用NAT将接收到的报文中的目的地地址替换为该私有IP地址“10.1.2.6”并通过预先分配给该私有IP地址的VLAN 2传输到对应的本地服务进行处理。本地服务处理完后需要将响应信息通过VLAN 2传输到外部。此时响应信息的报文中的源地址为私有IP地址“10.1.2.6”。网络过滤模块可以利用NAT将该私有IP地址“10.1.2.6”转换为Android 102的外部IP地址“198.18.34.15”作为回复消息的源地址发送到外部。这样，对于外部而言，Android 102始终只使用一个外部IP地址“198.18.34.15”，节省了以太网的网络资源。

需要注意的是，本实施例中，Android 102本身不具有实体网络端口，无法直接与外部进行数据传递。实体网络端口设置在QNX 101中，即emac，以保证QNX网络的实时性和系统安全性。因此，Android 102与外部的数据传递需要通过QNX 101的emac来实现。此外，Android 102与QNX101之间也可以进行通信，QNX 101与外部之间也可能产生通信。为了提高网络拓扑的稳定性和安全性，本公开将Android 102与外部的通信、Android102与QNX101之间的域间通信以及QNX 101之间与外部的通信这三者解耦。为了实现通信的解耦，本实施例利用QNX 101内的不同层来进行这三者的通信。

图6示出OSI参考模型的示意图。OSI(Open System Interconnection ReferenceModel：开放式系统互联通信参考模型)模型将计算机网络体系结构(architecture)划分为图中所示的七层：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。应用层提供为应用软件而设的端口，以设置与另一应用软件之间的通信。表达层用于将数据转换为能与接收者的系统格式兼容并适合传输的格式。会话层用于在数据传输中设置和维护计算机网络中两台计算机之间的通信连接。传输层用于将传输表头(TH)加至数据以形成数据包。传输表头包含了所使用的协议等发送信息，例如传输控制协议(TCP)等。网络层决定数据的路径选择和转寄，将网络表头(NH)加至数据包，以形成分组。网络表头包含了网络数据，例如互联网协议(IP)等。数据链路层用于网络寻址、错误侦测和改错。物理层在局部局域网上传送数据帧，负责管理计算机通信设备和网络媒体之间的互通，包括针脚、电压、线缆规范、集线器、中继器、网卡、主机适配器等。

以往，报文的传输从第一层(物理层)开始逐级向上。应用程序(例如DoIP服务)的报文通常影响到四层以上，即，第一层至第四(第五、第六或第七)层。

图7示出根据本公开的实施例的座舱系统100的通信解耦的示意图。本实施例中，来自Android 102的报文经由QNX 101的网桥1014(图5中的bridge)然后通过实体网卡1013直接发送到外部。由于网桥1014和网卡1013工作在二层、即数据链路层，因此通过使用网桥1014和网卡1013直接转发来自Android 102的报文，使得来自Android 102的报文只会影响QNX 101的二层以下，不会影响二层以上的报文。

Android 102和QNX 101的域间通信通过专用的虚拟化端口vif0、vp0进行。Android 102与外部的通信通过该专用的虚拟化端口vif0、vp0以外的虚拟化端口vif 1、vp1进行。也就是说，虚拟化端口vif0、vp0只传输Android 102和QNX 101的域间通信的数据包。这样，Android 102和QNX101的域间通信能够与Android 102和外部的通信解耦。

QNX 101与外部的通信在图6所示的第四层、即传输层及以上进行。因此，QNX 101和外部的通信能够与仅进行到二层的Android 102和外部的通信解耦。由此实现了QNX 101和外部的通信、Android 102和外部的通信以及Android 102和QNX 101的域间通信这三者之间的解耦，提高了网络拓扑的安全性和稳定性。

以上描述了应用了单IP多VLAN的地址分配的座舱系统100。但需要注意的是，单IP多VLAN的地址分配虽然能减少对外部IP地址的占用，但需要解决数据包的VLAN标签问题。具体而言，在图3所示的多IP网络地址分配的实现中，针对某一本地服务的报文可以直接通过分配给该服务的IP地址来寻址。例如，外部设备或云端可以直接向分配给该本地服务的IP地址发送报文，本地服务处理完来自该外部设备或云端的请求后可以直接向接收到的报文中包含的源地址回复该报文。

但是，在图4和图5所示的单IP多VLAN地址分配的实现中，多个本地服务共享一个外部IP地址。来自外部设备或云端的报文只包含该唯一的外部IP地址作为目的地地址。子网络的收发模块接收到该报文后，根据该接收报文中包含的五元组信息(源IP地址、目的地IP地址、协议、源端口、目的地端口)来确定该报文应发送到哪个本地服务，然后通过NAT模块将报文中包含的该子网络的外部IP地址转换为对应本地服务的私有IP地址并通过对应VLAN通道发送到本地服务。然而以往，本地服务在处理完接收报文后，通过传统的路由表回复报文。这会导致回复的报文不经由正确的VLAN通道到达子网络的网络端口，例如图7所示的Android 102的虚拟网络端口1022。换言之，本地服务接收到的报文与回复的报文未通过相同的VLAN通道传输。其结果，由本地服务回复的报文会被丢弃。

为了解决这一问题，本公开在单IP多VLAN地址分配的基础上，增加了策略路由来实现回复报文的VLAN标签的匹配，使得同一本地服务能够经由相同的VLAN通道接收和发送报文(数据包)。图8示出根据本公开的实施例的应用了策略路由的座舱系统100的通信方案的示意图。图9示出根据本公开的实施例的在图8所示的座舱系统100中执行的报文传输的示例过程900的流程图。

图8的示例与图7相对应，仅仅将座舱系统100的外部示出在左侧。QNX 101通过实体网卡1013与外部通信。Android 102通过自身的虚拟网络端口1022与QNX 101侧的虚拟网络端口1012进行通信，并且进一步经由QNX 101侧的网卡1013来与外部进行通信。

Android 102侧的虚拟网络端口1022与QNX 101侧的虚拟网络端口1012之间可以设置多个虚拟网络接口对，例如上文参照图5和图7描述的vif0-vp0端口对、vif1-vp1端口对。vif0-vp0端口对可专用于Android 102与QNX 101侧的域间通信。vif1-vp1端口对等其他端口对可供Android 102传递与座舱系统100外部的通信数据。

QNX 101的网卡1013通过网桥1014耦合到虚拟网络端口1012，从而能够实现二层(即，数据链路层)以下的数据包的转发。QNX 101的本地应用1011也通过网桥1014耦合到网卡1013。本地应用1011能在四层(传输层)以上与外部传输数据。

在Android 102侧，设置了DNAT(Destination Network Address Translation：目的地址转换)模块1023和SNAT(Source Network Address Translation：源地址转换)模块1026来进行接收报文和回复报文的地址转换。DNAT模块1023将接收报文中的目的地地址、即Android 102的外部IP地址(例如图8中所示的“198.18.34.15”)转换为内部的私有IP地址，以作为转换后的目的地地址(图8中所示的“DNAT dst ip”)。目的地地址的转换可以基于接收报文的五元组信息的至少一部分。五元组信息包括源地址(“src ip”)、目的地地址(“dst ip”)、协议(“protocol”)、源端口和目的地端口。图8中省略了源端口，仅示出源地址、目的地地址、协议和目的地端口(“port”)。

在图8所示的示例中，上方的映射表(第一映射表)设置有两个条目。对于来自外部的TBOX模块140并将Android 102作为目的地的报文，其源地址为“198.18.34.7”，目的地地址为Android 102的外部IP地址“198.18.34.15”，通信协议为TCP，目的地端口为2022。基于这些五元组信息能够在映射表中查找到对应本地服务的私有IP地址为“10.1.3.6”。类似地，对于来自外部的ADCU模块123并将Android 102作为目的地的报文，其源地址为“198.18.34.6”，目的地地址为Android 102的外部IP地址“198.18.34.15”，通信协议为UDP，目的地端口为2345。基于这些五元组信息能够在映射表中查找到对应本地服务的私有IP地址为“10.1.4.6”。

由于外部数据源可能来自不同厂商的产品或应用程序，其使用的协议、端口、源地址可能相同，因此基于五元组信息生成映射表能更准确地定位到正确的私有IP地址。但应理解，在能够确保通过五元组中的一部分元素能够定位到正确的私有IP地址的情况下(例如外部数据源来自同一厂商)，可以仅基于该部分元素来制作映射表。

在DNAT模块1023将接受报文中的目的地地址转换为对应本地服务的私有IP地址后。路由判决模块1024根据所确定的私有IP地址确定对应的内部VLAN通道，并通过对应的内部VLAN通道发送到本地接口1021以由对应的本地服务211进行处理。

本地服务211处理完接收到的报文后需要发送回复消息。如上所述，回复消息的报文需要与接收报文经由同一内部VLAN通道才不会被丢弃。路由判决模块1025可以根据提供回复消息的本地服务211的私有IP地址来确定对应的内部VLAN通道，并经由该对应的内部VLAN通道将回复报文发送到SNAT模块1026。

路由判决模块1024和路由判决模块1025中可以预先存储本地服务的私有IP地址与内部VLAN通道的映射表(第二映射表)。

SNAT模块1026经由对应的VLAN通道接收到回复报文后，将报文中的私有IP地址替换为所在子网络、即Android 102的外部IP地址作为源地址，然后经由虚拟网络端口1022发送给QNX 101。QNX 101将来自Android102的回复报文发送到该报文中的目的地地址，由此完成本次服务。

根据本实施例，对于外部而言，Android 102只具有一个唯一的外部IP地址“198.18.34.15”。换言之，来自外部的请求报文中的目的地地址以及来自Android 102的回复报文中的源地址均为Android 102的外部IP地址“198.18.34.15”。

下面结合图9，以图8所示的座舱系统100作为提供网络服务的服务器、TBOX模块140作为TCP网络请求的客户端为例说明本实施例的报文处理过程。

首先对座舱系统100的内部私有IP地址和外部IP地址、ADCU模块123和TBOX模块140的IP地址、请求和侦听的端口(Port)和协议(Protocol)分配做如下假设：

表1

上表中，“座舱系统内部VLAN 3”表示座舱系统内部被分配VLAN 3通道的本地服务，其私有IP地址为“10.1.3.6”。端口Port表示目的地端口。下面基于上述假设描述报文处理过程。

首先，在框901中，作为客户端的TBOX模块140向座舱系统100发送请求报文。QNX101侧的网卡1013接收到该请求报文。

在框902中，网卡1013将接收到的报文通过网桥1014转发到虚拟网络端口1012。网卡1013可以根据报文中的目的地地址确定该报文的目的地是QNX 101侧的本地服务1011还是Android 102。

在框903中，QNX 101侧的虚拟网络端口1012和Android 102侧的虚拟网络端口1022可以经由指定的虚拟网络端口对传递报文。本实施例中，由于报文来自座舱系统100外部，因此可以通过上文描述的vif1-vp1端口而非专用于QNX 101与Android 102的域间通信的vif0-vp0端口来传递报文。

在框904中，Android 102侧的DNAT模块1023查看报文中的信息。DNAT模块1023中可以存储如下所示的映射表。

表2(第一映射表)

DNAT模块1023中的映射表可以将接收报文的五元组信息(源IP、目的地IP、协议、源端口、目的地端口)的至少一部分映射到Android 102内的对应本地服务211的私有IP地址。根据表2，对于来自源IP地址“198.18.34.7”(TBOX模块123)、目的地IP地址“198.18.34.15”、通信协议为TCP、目的地端口2022的报文，可以将目的地IP地址“198.18.34.15”转换为对应本地服务中的TBOX服务的私有IP地址“10.1.3.6”。对于来自源IP地址“198.18.34.6”(ADCU模块140)、目的地IP地址“198.18.34.15”、通信协议为UDP、目的地端口2345的报文，可以将目的地IP地址“198.18.34.15”转换为对应本地服务211中的ADCU服务的私有IP地址“10.1.4.6”。

在框905中，DNAT模块1023判断报文中的信息是否与表2中的某一条目相匹配。如果没有条目命中(框905中为“否”)，则可以进行进一步路由判断、转发或丢弃处理。

如果在第一映射表中找到对应条目(框905中为“是”)，则进入框906以进行目的地地址转换。

在框907中，路由判决模块1024进行路由判断。路由判断可以基于如下所示的将私有IP地址映射到的内部VLAN的映射表(也称为第二映射表)。

表3

目的IP	接收通道
		10.1.3.6	VLAN3
10.1.4.6	VLAN4

在框908中，经由对应的VLAN通道将接收报文发送到DNAT转换后的目的地地址所指示的本地服务。

在框909中，本地服务211中的每一个在各自对应的VLAN通道上侦听报文。例如，私有IP地址为“10.1.3.6”的ADCU服务可以在VLAN 3上侦听数据，私有IP地址为“10.1.4.6”的TBOX服务可以在VLAN 4上侦听数据。通过对应VLAN通道传输过来的报文被对应的本地服务211侦听到并接收。

在框910中，本地服务211处理完接收报文后生成回复报文后将回复报文发送到路由判决模块1025。

路由判决模块1025在框911中查看报文及其存储的策略路由表，并在框912中确定回复报文应经由哪条VLAN通道发送。策略路由表指示提供服务的本地服务211的私有IP地址(即，源IP地址)与用于发送回复报文的VLAN通道的映射关系。

表4

源IP	目的IP	发送通道
			10.1.3.6	198.18.34.7(TBOX)	VLAN3
10.1.4.6	198.18.34.6(ADCU)	VLAN4

通过设置路由判决模块1025，能使用正确的VLAN通道，即，与用于接收请求报文的VLAN通道相同的VLAN通道发送回复报文。例如，对于目的地地址为“10.1.3.6”的请求报文而言，VLAN 3为对应接收通道。本地服务处理完该该报文后，应通过同样的VLAN 3进行回复。该情况下，对于回复报文，其源地址为“10.1.3.6”，用于发送的通道为VLAN 3。若经由不正确的VLAN通道发送，例如采用以往的主路由表，则回复的报文会因为回复路径的VLAN通道与接收路径的VLAN通道不一致而被丢弃。通过设置本实施例的路由判决模块1024、1025能够避免这一问题，从而能够实现单IP多VLAN路由下不同本地服务能通过正确的VLAN通道收发报文。

在框913中确定用于发送回复报文的VLAN通道后，路由判决模块1025在框914中经由确定的VLAN通道将回复报文发送到SNAT模块1026。

SNAT模块1026在框914中查看报文。SNAT模块1026用于将回复报文中的源地址(对应本地服务的私有IP地址)转换为所在子网络(Android102)的外部IP地址。SNAT模块1026中的映射表的一个示例如下所示。

表5

条件	执行的SNAT动作
		源IP
10.1.3.6	10.1.3.6->198.18.34.15
		10.1.4.6	10.1.4.6->198.18.34.15

在框915中，SNAT模块1026判断接收到的回复报文的源IP地址是否命中。若未命中，则丢弃该报文。若命中(框915中为是)，则在框916中进行源IP地址转换，然后发送到虚拟网络端口1022。

与接收报文的过程类似，Android 102侧的虚拟网络端口1022通过与接收报文时使用的同一虚拟网络端口对(例如vif1-vp1)将回复报文发送到QNX 101侧的虚拟网络端口1012。

虚拟网络端口1012然后在框918中通过网桥1014将回复报文转发到网卡1013。该转发仅影响到QNX 101的二层(数据链路层)以下，从而与QNX 101的本地服务1011与外部在四层以上进行的通信解耦。

最后，在框919中，网卡1013依据回复报文中的目的IP地址将该回复报文发送到目的地。

以上描述了由Android 102内的本地应用211接收来自座舱系统100的外部的请求并回复报文的过程。对于Android 102与QNX 101之间的域间通信，例如由QNX 101侧的本地服务1011向Android 102侧的本地服务211请求服务的情况，Android 102侧的通信过程与上文参考图8和图9描述的过程大体类似，区别在于发送报文的源IP地址以及回复报文的目的地IP地址为QNX 101的外部IP地址，并且Android 102和QNX 101经由专用的虚拟网络端口对传递数据，来与Android 102和座舱系统100外部的通信解耦。该情况下，针对Android102的请求报文由QNX 101侧的本地服务1011发出，经过网桥1014到达虚拟网络端口1012。来自Android 102的回复报文由虚拟网络端口1012接收后，经由网桥1014到达QNX 101侧的本地服务1011。

在QNX 101与座舱系统100外部通信的情况下，QNX 101侧的本地服务1011经由网桥1014和网卡1013来与外部传递数据。该情况下，传递的数据在OSI参考模型的四层(传输层)以上进行，来与Android 102和座舱系统100外部的通信解耦。

本实施例中，描述了在Android 102侧设置单IP多VLAN地址分配的布置，但也可以在此基础上在QNX 101侧同样设置单IP多VLAN地址分配的布置，以进一步减少QNX 101对网络资源的占用，尤其是在QNX 101的本地服务1011数量较多的情况。

此外，上文以QNX和Android两种操作系统为例描述了多网络通信系统的示例实现。但应理解，本公开的技术也适用于包含其他类型子网络的多网络通信系统。

本文中所公开的机制的实施例的至少一部分可被实现在硬件、软件、固件或此类实现方式的组合中。本发明的实施例可实现为在可编程系统上执行的计算机程序或程序代码，该可编程系统包括至少一个处理器、存储系统(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备以及至少一个输出设备。

可将程序代码应用于输入指令，以执行本文中所描述的功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本申请的目的，处理系统包括具有处理器的任何系统，该处理器诸如例如，数字信号处理器(DSP)、微控制器、专用集成电路(ASIC)或微处理器。

至少一个实施例的一个或多个方面可由存储在机器可读介质上的表示处理器中的各种逻辑的表示性指令来实现，该表示性指令在由机器读取时使得该机器制造用于执行本文中所描述的技术的逻辑。被称为“IP核”的此类表示可以被存储在有形的机器可读介质上，并可被供应给各个客户或生产设施以加载到实际制造该逻辑或处理器的制造机器中。

以上详细描述了本发明的优选实施方式。但应当理解为本发明在不脱离其广义精神和范围的情况下可以采用各种实施方式及变形。本领域的普通技术人员无需创造性劳动就可以根据本发明的构思做出诸多修改和变化。因此，凡本领域技术人员依本发明的构思在现有技术的基础上通过逻辑分析、推理或者有限的实验可以得到的技术方案，皆应属于由本发明的权利要求书所确定的保护范围内。

Claims (10)

1.一种多网络通信系统，包括：

第一子网络，所述第一子网络内包含至少一个本地服务，所述至少一个本地服务中的每一个映射到对应的内部VLAN并经由所述对应的内部VLAN以及所述第一子网络与第二子网络之间的第一虚拟网络端口对来收发去往或来自所述通信系统的外部的第一数据包；以及

所述第二子网络，与所述第一子网络通信地耦合，所述第二子网络被配置成直接转发来自或去往所述外部的所述第一数据包。

2.如权利要求1所述的多网络通信系统，其特征在于，所述第一子网络与所述第二子网络之间的内部通信通过不同于所述第一虚拟网络端口对的专用虚拟网络端口对进行。

3.如权利要求1所述的多网络通信系统，其特征在于，在所述第二子网络内部，所述第一数据包经由在数据链路层上工作的网桥直接与外部之间进行转发。

4.如权利要求1所述的多网络通信系统，其特征在于，所述第一子网络具有唯一的外部IP地址。

5.如权利要求1所述的多网络通信系统，其特征在于，所述第一子网络包含用于将来自所述外部的第一数据包中的五元组信息的至少一部分映射到用于接收所述第一数据包的本地服务的私有IP地址的第一映射表。

6.如权利要求5所述的多网络通信系统，其特征在于，所述第一子网络还包含用于将所述私有IP地址映射到的所述对应的内部VLAN的第二映射表。

7.如权利要求1所述的多网络通信系统，其特征在于，用于接收所述第一数据包的内部VLAN与用于发送所述第一数据包的内部VLAN相同。

8.如权利要求1所述的多网络通信系统，其特征在于，所述至少一个本地服务中的每一个在所述对应的内部VLAN上侦听数据。

9.如权利要求1所述的多网络通信系统，其特征在于，所述第一子网络通过虚拟网络端口与所述第二子网络通信，并且

所述第二子网络通过实体网卡与所述外部通信。

10.如权利要求1所述的多网络通信系统，其特征在于，所述第二子网络提供安全服务。

Images