一种收集信息的方法和车载天线与流程

1.本公开涉及无线通信领域，尤其涉及一种收集信息的方法和车载天线。


背景技术：

2.在传统无线局域网(wlan)技术中，ap之间均通过有线网络连接，这种有线的连接决定了无线网络中的ap依旧不具备移动性，限制了无线的自由性，为了解决这一问题，衍生出了无线网状网即mesh网络技术。
3.如图1所示，mesh网络技术提供了对ap移动性的支持，从而，mesh网络技术成为了轨道交通(地铁等)通信技术的一大主力。典型的轨道交通场景有地铁，动车等。目前，地铁上的mesh技术应用发展十分迅速。
4.轨道交通中，cbtc(基于通信技术的列车控制系统)和pis(一种提供监控、视频等应用功能的系统)是两类主要的应用。其中cbtc用于列车控制，对mesh链路的稳定性要求较高，不允许mesh链路出现超过2.4秒的中断，如若超过势必会触发控制系统保护程序造成紧急停车。而pis用于列车视频、监控应用，对mesh链路带宽有较高的要求，无论是cbtc应用还是pis应用，列车在移动过程中车载mp都是在轨旁mp之间按照一定规则进行切换，车载mp与轨旁mp建立多条mesh链路(一般为2或3条)，一条作为主链路，其余作为备链路，在适当的时机(如主备链路信号强度高于主链路信号强度达到一个阈值)将主链路降级为备链路，将备链路升级为主链路。
5.但地铁环境复杂，在列车运行过程中难免因信号强度弱、空口干扰、丢包等原因导致车地无线通信出现故障，在cbtc应用中表现为紧急停车，在pis应用中表现为视频出现卡顿，维护人员排查故障十分困难。


技术实现要素：

6.本公开提供了一种收集信息的方法和车载天线，通过该方法，可以实时收集轨旁天线与车载天线的状态信息，从而可以根据收集的信息进行状态分析，对故障进行定位。
7.本公开实施例提供了一种收集信息的方法，该方法应用于车载天线中，该方法包括：
8.获取与轨旁天线间建立的各无线网格网络mesh链路；
9.通过各mesh链路向轨旁天线发送通告报文，所述通告报文中携带指示轨旁天线发送第一状态信息的指令；
10.接收轨旁天线发送的携带轨旁天线第一状态信息的反馈报文，并获取所述第一状态信息；
11.获取自身的第二状态信息，为所述第一状态信息和所述第二状态信息设置时间戳并存储。
12.可选的，在所述通过各mesh链路向轨旁天线发送通告报文前，所述方法还包括：
13.监控与轨旁天线的链路状态，当监控结果达到预设状态时，则通过各mesh链路向
轨旁天线发送通告报文。
14.可选的，所述通告报文为mesh链路保活报文。
15.可选的，所述为所述第一状态信息和所述第二状态信息设置时间戳并存储，包括：
16.将第一状态信息和第二状态信息汇总为总状态信息，并为所述总状态信息设置时间戳。
17.可选的，所述为所述第一状态信息和所述第二状态信息设置时间戳并存储，包括：
18.为所述总状态信息设置时间戳，并将设置了时间戳的总状态信息写入flash中进行存储。
19.通过上述方法可以看出，车载天线可以发起获取请求，获取轨旁天线的状态信息，并将此时的车载天线的状态信息和轨旁天线的状态信息打上时间戳并保存，后期管理员可通过保存的状态信息进行故障定位。
20.本公开实施例还提供了一种车载天线，所述车载天线包括：
21.获取模块，用于获取与轨旁天线间建立的各无线网格网络mesh链路；
22.发送模块，用于通过各mesh链路向轨旁天线发送通告报文，所述通告报文中携带指示轨旁天线发送第一状态信息的指令；
23.接收模块，用于接收轨旁天线发送的携带轨旁天线第一状态信息的反馈报文；
24.所述获取模块，还用于从反馈报文中获取第一状态信息和自身的第二状态信息；
25.处理模块，用于为所述第一状态信息和所述第二状态信息设置时间戳并存储。
26.可选的，所述车载天线还包括：监控模块，所述监控模块，用于监控与轨旁天线的链路状态，当监控结果达到预设状态时，指示所述发送模块通过各mesh链路向轨旁天线发送通告报文。
27.可选的，所述通告报文为mesh链路保活报文。
28.可选的，所述处理模块，具体用于将第一状态信息和第二状态信息汇总为总状态信息，并为所述总状态信息设置时间戳。
29.可选的，所述处理模块，具体用于为所述总状态信息设置时间戳，并将设置了时间戳的总状态信息写入flash中进行存储。
附图说明
30.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施例，并与说明书一起用于解释本说明书的原理。
31.图1为本公开实施例提供的一种网络架构示意图。
32.图2为本公开实施例提供的一种收集信息的方法流程示意图。
33.图3为本公开实施例提供的一种逻辑示意图。
具体实施方式
34.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
35.在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
36.应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”。
37.目前在轨道交通中，地铁mesh环境复杂，mesh链路通信异常故障是多方面的，需收集多模块的日志信息，而且是车载mp和轨旁mp双方的，而产生通信异常的情况主要可以包括以下几种：
38.a：信号强度不对称导致的通信异常，如车载mp认为轨旁mp信号较强，但轨旁mp认为车载mp信号较弱。
39.b：列车运行区间某个时间段出现干扰导致信道利用率升高产生丢包。
40.c：网络中存在大量的广播报文导致正常通信报文被淹没。
41.d：车载设备本身工作异常，如设备温度过高、cpu使用率过高、剩余内存过低等。
42.e：链路切换时刻车载mp发送的garp丢失导致下行数据通信异常。
43.f：组播加入和离开报文丢失导致端口无法加入组播组或无法离开组播组，最终导致车载视频卡顿。
44.上述异常情况虽然可以通过日志来进行记录，但是日志种类繁多给维护人员造成极大的麻烦。
45.同时，车载ap日志与轨旁ap日志相互独立，一旦出了问题需要结合车载mp和轨旁mp的日志来共同分析，且车载ap和轨旁ap的时间校准不够精确势必造加大维护的难度。
46.同时，每条地铁线路都会部署好几百个轨旁mp，大量轨旁ap收集日志是一件十分庞大的工程。
47.为解决上述技术问题，本公开实施例提供了一种收集信息的方法，如图2所示，该法应用于车载天线中，所述方法包括：
48.s101获取与轨旁天线间建立的各无线网格网络mesh链路；
49.s102通过各mesh链路向轨旁天线发送通告报文，所述通告报文中携带指示轨旁天线发送第一状态信息的指令；
50.s103接收轨旁天线发送的携带轨旁天线第一状态信息的反馈报文，并获取所述第一状态信息；
51.s104获取自身的第二状态信息，为所述第一状态信息和所述第二状态信息设置时间戳并存储。
52.在本实施例中，该车载天线可以为车载mp(mesh point，提供mesh服务的ap)，该车载mp被部署在移动列车(地铁)上的移动的无线终端。
53.在步骤s101中，车载天线(车载mp)可以根据链路探测报文来获取与轨旁天线(轨旁mp)间存在的链路，该链路包括主链路和备链路。
54.在执行步骤s102前，可先获取监控与轨旁天线的链路状态的监控结果，当监控结果达到预设状态时，则通过各mesh链路向轨旁天线发送通告报文，其中，该预设状态可以为链路不稳定。否则，可以不执行步骤s102，以免造成资源浪费。
55.在另一种实施例中，可以设置开关模块，通过该开关模块控制车载天线执行步骤s102。
56.在本实施例中，利用现有协议，该通告报文可以为mesh链路保活报文，车载天线可以在每一个mesh链路保活报文(porbe request报文)中携带指示轨旁天线发送第一状态信息的指令，以使轨旁mp在接收到保活报文后，根据保活报文中携带的该指令收集该轨旁mp中的第一状态信息。
57.其中，该指令可以为vendor ie。
58.其中，该第一状态信息可以由管理员根据需求事先约定，或者该第一状态信息为该轨旁mp的全部实时状态信息。
59.在一种实施例中，该第一状态信息可以包括以下一种或者多种组合，具体如下：(需要说明书的，该实施例中仅示例性的列举了第一状态信息的种类，本实施例并不限制该第一状态信息还包括其他种类信息)
60.1.时间戳(该条诊断信息成生的时间)
61.2.mesh链路切换原因(只在切换的时刻生成)
62.3.建立链路的mac地址(只需记录轨旁mp的mac地址)
63.4.链路建立时间
64.5.mesh链路信号强度
65.6.cpu使用率
66.7.剩余内存
67.8.信道利用率
68.9.发送的报文总数
69.10收到的报文总数
70.11.重传报文数
71.12.收到的错包数
72.13.发送的garp个数
73.14.收到的garp个数
74.15.发送的组播加入和组播离开报文个数
75.16.收到的组播加入和组播离开报文个数
76.在本实施例中，轨旁天线在获取了自身的第一状态信息后，可同时执行步骤s103和步骤s104，在执行步骤s104时，可参考上述1
‑
16条状态种类获取车载天线的第二状态信息。在进行故障分析定位时，需要同时对车载天线和与该车在天线通信的轨旁天线的状态信息进行分析，因此，本实施例中会获取第一状态信息和第二状态信息并进行打包，也可以被理解为将第一状态信息和第二状态信息汇总为总状态信息。
77.本实施例提供一种总状态信息的示例，具体如下：
78.1.时间戳(该条诊断信息成生的时间)
79.2.mesh链路切换原因(只在切换的时刻生成)
80.3.建立链路的mac地址(只需记录轨旁mp的mac地址)
81.4.链路建立时间
82.5.mesh链路信号强度(双方的)
83.6.cpu使用率(双方的)
84.7.剩余内存(双方的)
85.8.信道利用率(双方的，包括tx和rx)
86.9.发送的报文总数(双方的)
87.10收到的报文总数(双方的)
88.11.重传报文数(双方的)
89.12.收到的错包数(双方的)
90.13.发送的garp个数(车载mp)
91.14.收到的garp个数(轨旁mp)
92.15.发送的组播加入和组播离开报文个数(车载mp)
93.16.收到的组播加入和组播离开报文个数(轨旁mp)
94.其中，上述双方的指的是车载天线(车载mp)和轨旁天线(轨旁mp)。
95.由于列车在一趟行程中，车载天线会与多个轨旁天线进行交互，并且，一般情况下当出现故障时，通过故障时间点来进行定位分析将会得到更为准确的分析结果，因此，在将第一状态信息和第二状态信息汇总为总状态信息，可对该总状态信息设置时间戳。
96.并将设置了时间戳的总状态信息进行存储。
97.在本实施例中，存储总状态信息时，可将该总状态信息写入flash中进行存储。
98.由于flash空间有限，在将该总状态信息写入flash时，可将该flash已经超时的历史状态信息删除。
99.通过上述实施例可以看出，利用车载天线向轨旁天线发送指令，可以即时获取与车载天线通信的轨旁天线的状态信息和车载天线的状态信息，并进行储存，操作人员可以根据储存的状态信息进行故障分析定位，解决了现有技术中定位难的问题。
100.根据上述实施例，本公开提供了一种实施本公开中方法的流程图，如图3所示，车载mp通过携带vendor ie指令的链路保活报文实现获取与该车载mp通信的轨旁mp的状态信息，并将获取的状态信息进行存储。
101.本公开实施例还提供了一种车载天线，所述车载天线包括：
102.获取模块，用于获取与轨旁天线间建立的各无线网格网络mesh链路；
103.发送模块，用于通过各mesh链路向轨旁天线发送通告报文，所述通告报文中携带指示轨旁天线发送第一状态信息的指令；
104.接收模块，用于接收轨旁天线发送的携带轨旁天线第一状态信息的反馈报文；
105.所述获取模块，还用于从反馈报文中获取第一状态信息和自身的第二状态信息；
106.处理模块，用于为所述第一状态信息和所述第二状态信息设置时间戳并存储。
107.可选的，所述车载天线还包括：监控模块，
108.所述监控模块，用于监控与轨旁天线的链路状态，当监控结果达到预设状态时，指示所述发送模块通过各mesh链路向轨旁天线发送通告报文。
109.可选的，所述通告报文为mesh链路保活报文。
110.可选的，所述处理模块，具体用于将第一状态信息和第二状态信息汇总为总状态信息，并为所述总状态信息设置时间戳。
111.可选的，所述处理模块，具体用于为所述总状态信息设置时间戳，并将设置了时间戳的总状态信息写入flash中进行存储。
112.上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
113.本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。
114.应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。
115.以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。