CN105307213A - 一种解决微信信令风暴的基站侧跨层信令优化传输方案 - Google Patents

Abstract

本发明公开了一种应用于蜂窝无线移动通信基站侧的跨层信息共享和优化方案，解决无线网络中用户基数较大场景下使用微信等即时通信软件造成的信令风暴问题。本发明通过以下技术方案实现该优化：通过基站侧的跨层信息共享技术，基站侧将即时通信软件的在线状态请求信息以及软件侧的在线状态汇报信息解析出来，通过专用控制信道资源发送，从而降低数据传输的负载。该方案的实现核心在于基站侧的跨层数据共享和解析，即基站侧将来自用户和软件服务器的信息解包至应用层，将在线状态确认信息提取并通过专用控制信道发送，从而实现降低网络负载，提高传输成功率的作用。

Description

一种解决微信信令风暴的基站侧跨层信令优化传输方案

技术领域

本专利涉及电子信息领域中通信的传输技术优化，具体来说，涉及一种对现有无线通信网络中基站传输内容的优化，以解决大用户数场景下信令负载问题。

背景技术

随着无线通信系统的快速发展，越来越多的移动端应用软件得到广泛的应用，尤其是近些年来终端处理能力的大幅度提升，软件的应用呈现多样化趋势。客户端软件可以利用移动网络为用户提供多种多样的功能，诸如常见的移动端即时通信软件QQ、微信等。这类即时通信软件在位用户提供实时的接入同时，由于必须和服务器交互以获取用户的在线或者离线状态，有可能会使得网络负载随着用户数量的增大而显著提升，造成信令拥塞。即时通信软件的在线状态标记信息需要占用系统的数据服务带宽进行传输，因此当用户数量较多时，软件大量发送短数据信息，将使得网络性能急剧下降。与此类似的，移动网络中寻呼信号的特点类似于即时通信软件的在线状态标记信号，但是寻呼信号使用的是专用控制信道（广播信道）进行数据传输，因此不会对数据传输带来压力。

发明内容

为了评估即时通信软件带来的应用层的信令负载，其信令传输流程必须进行必要的讨论，从而得出流程中可以优化的部分，降低网络的负载。

传统的寻呼等信令主要用于探测用户的在线状态，由基站侧主动发出。由于该信令内容仅仅提供给网络侧进行分析和存储，因此使用专用的物理信道，使用专用的资源进行传输。在专用物理信道中，信令不会占据数据传输的带宽和功率，因此不会影响到用户侧体现的网络性能。以WCDMA系统为例，当网络侧要确定某个移动终端在线或者离线与否时，基站侧将发送寻呼（paging）信令来确定状态。

图1描述了WCDMA系统中用户在线和离线的两种可能状态流程。其中，无线网络控制器（RNC）每隔180秒需要对用户的在线或者离线状态进行刷新，因此该寻呼信令将在给定的时刻由基站侧广播给所辖用户。首先，基站侧将发送下行的寻呼信令，如果用户当前处于在线状态，那么该用户将在给定的时间段内返回寻呼确认ack信号，表明已经收到寻呼请求，且当前状态为在线。基站侧收到信息后会将该信息传送给无线网络控制器，并在移动用户状态寄存器中更新状态。如果某个移动用户处于离线状态，系统的流程会有部分区别。当用户处于无服务状态等被动场景时无法回应基站侧的寻呼请求，最终会因为超时被标记为离线状态并在网络端标记。当用户需要关机等主动离开网络时，用户将响应寻呼请求，并上报离线申请，最终完成状态标记。寻呼信令无需占据系统数据传输带宽，因此寻呼信号对系统性能的影响几乎可以忽略不计，即使用户数量急剧增大，其对控制信道的影响也不会扩散到数据信道。然而，来自即时通信软件的心跳信号则需要占用数据信道带宽，随着用户数量的增大，其性能会受到较大的影响。

图2给出了即时通信软件的在线或者离线状态的判别方案。很明显，应用层是虚拟层且不具备传输实体，因此论文采用虚线代表了微信软件的应用层，而其余的实体层使用实线表示。在这种场景下，用户在线状态请求由腾讯服务器发出，在网络侧作为数据进行传输，因此该信号是在数据信道传输的心跳信号。通常来说，这种状态确认信号仅仅包含4比特或更少的信息，在应用软件内进行内容解析，但是却需要消耗一整个数据帧来进行传输和处理，当用户从基站侧收到信号时，软件将通过数据传输信道发送确认的ack信息。当用户在线时，系统可以直接将信息传输至应用层软件，而当用户出现超时回复或者主动离线时，腾讯服务器将把该用户标记为离线状态。

因此，控制信道的信令信息和软件发起的在线状态请求信息具有相类似的功能但是完全不同的资源占用方式。诸如寻呼等信令使用专用的控制信道进行传输且基本不会影响用户的性能；与此相反，心跳信号包含在数据传输中，且在应用层起作用，因此底层传输并不知晓这是信令类的传输，而是仅仅把它当成普通数据传输。当用户数量增加时，软件发起的心跳信号将逐渐占用更多的数据带宽和传输功率，从而极大的影响传输性能。

考虑到心跳信号占用系统资源，影响系统性能的特点，论文提出了一种可行的跨层数据共享方案来降低心跳信号对资源的占用。

无论是心跳信号还是寻呼这类的控制信令，其主要功能是标记用户的在线或者离线状态。控制信令之所以不会显著影响系统性能，是因为控制信令有专用的控制信道进行传输，不会占用系统数据传输资源，而心跳信号无法做到这一点。

考虑到系统的跨层资源可共享，可以将心跳信号标记的在线或者离线状态由信令帧发送，并在基站端进行跨层数据提取，这样系统就可以有效地利用专用控制信道传输数据信息。仅仅需要的改进是，基站端能够识别和分离从控制信道传输的包含软件在线状态标记的信息。

如图3所示，给出了论文所述的一种改进型心跳信令传输流程。传统场景下，移动用户的心跳信号自用户应用层发出，通过数据信道经基站发送至腾讯服务器，并在服务器端解析至应用层，这一过程与传输其他的语音、文本等信号是一致的，因而这也是产生误码率升高的主要原因。改进的流程主要是基于心跳信号的跨层共享设计，即心跳信号拥有和寻呼等信令类似的传输频率、数据结构以及功能，完全可以利用公共控制信道进行传输。同样的，心跳信号最初仍然在用户端应用软件的应用层产生，发送至物理层进行传输。

这里我们引入一个标记信号，所有应用层产生的心跳信号在物理层将被分离出来。也就是说，物理层知晓这些信号属于信令类型的数据信号，当需要传输时，物理层按照信令的传输流程从公共控制信道进行数据传输，并在基站侧进行解析。基站侧根据物理层标记将该信号从公共控制类信号解包，并重新将该信号封装为具有源用户ip地址和mac地址的数据包并从有线网（以太或者光纤主干网）发送至腾讯公司服务器，最终在服务器端解析成心跳信号。这样跨层数据共享和利用公共控制信道传输的优势在于：公共控制信道的资源不影响数据传输的速率和误码率，只影响用户的接入，且公共控制信道的预留资源丰富，完全有能力承载部分具有信令特点的数据信号传输，从而降低数据信道传输压力，达到资源的最优利用。

Claims (4)

1.一种针对微信信令风暴的协同处理流程：当使用微信等即时通信软件人数较多时，因软件需要知晓用户的在线状态需要在用户静默时每隔30秒请求用户的在线状态，造成了大用户数量时的信令负载；为了解决该信令风暴问题，该专利特征在于：

基站侧通过跨层信息共享知晓用户发送和接收服务器端的在线请求信息；

基站侧通过跨层信息共享将该种类信令通过公共控制信道发送和接收；

基站侧通过跨层信息共享将信息重新组装并发送至软件服务器；

该处理流程不需要对微信服务器进行任何操作，仅需要在基站侧和用户侧进行软修改，用于识别位于应用层的用户在线状态信息。

2.根据权利要求1所述的基站侧通过跨层信息共享分离出微信在线状态信令，其特征是：

基站侧通过光纤，同轴电缆，无线回程链路等方式从软件服务器端得到的数据，通过跨层信息共享解析出在线状态请求信令；

在线状态请求信令经优化后通过公共控制信道发送和接收，节省系统数据带宽资源。

3.根据权利要求1所述的基站侧通过跨层信息共享将微信通过专用控制信道发送的在线状态信息分离，并重新组合，通过基站的高速数据链路发送至服务器端，其特征是：

基站侧收到专用控制信道的信息后，通过解析信息标识信号，将微信软件的在线信息分离出来；

基站侧将分离出来后的微信在线状态汇报（状态请求）信息重新组合，通过高速数据传输链路发送至微信服务器端。

4.根据权利要求1所述的基站侧通过跨层信息共享降低网络用户数量较大时，使用微信等即时通信软件造成的信令风暴的操作流程，其特征是：

步骤1：基站侧通过跨层信息共享，解析出位于应用层的微信服务器端向指定用户发送的在线状态请求信息；

步骤2：基站侧将微信软件的在线状态请求信息加上信息标识信号，通过专用控制信道发送至用户；

步骤3：用户侧将微信软件的在线状态汇报信息加上信息标识信号，通过专用控制信道发送至基站侧；

步骤4：基站侧将专用控制信道收到的信息解析至应用层并重新封装；

步骤5：基站侧将重新封装的信息通过高速网络链路，如光纤、同轴电缆等发送至微信服务器端；

步骤6：微信服务器收到在线状态信息，并更新用户的在线状态信息。