信令数据

信令数据（共8篇）

信令数据 篇1

随着大数据时代的来临，从电信运营商的角度，其面临越来越大的数据存储、处理和分析的压力。从用户的角度，层出不穷的业务，让用户越来越注重网络性能的个人体验[1]。在这样的背景下，建立一套基于大数据的信令监测系统以满足用户需求、解决运营商难题已成为现阶段电信运营商的迫切需求。

传统的信令监测系统往往以基于网元层面的客观评估方法对网络进行优化和故障诊断，并没有充分考虑网络安全和用户体验[2]。然而，在大数据时代，从用户的角度，海量数据中包含大量用户敏感信息，确保这些信息的安全已受到用户越来越多的关注;从电信运营商的角度，海量数据只是简单存储在服务器中，这些数据中隐含的价值没有得到利用，通过对海量数据的挖掘分析不仅可以按照用户不同需求实现差异化服务，也可以更精细的管理、经营业务。因此，建立一套基于大数据的信令监测系统对用户和电信运营商都具有重要意义。

本文在传统的信令监测系统的基础上，重点研究了大数据的关键技术和数据分析挖掘的方法，设计了一套基于大数据的信令系统监测方案，并详细介绍了该方案在网络优化、业务经营、网络安全3方面的应用。

1 大数据在信令监测系统中的应用

1.1 大数据环境下信令数据特征分析

相比于传统的信令数据，由于通信技术的快速发展和数据流量的急剧增长，现网数据包含信令面和业务面数据以及错综复杂的用户数据，从这些数据中挖掘出的信令数据对信令监测系统有着重要作用。现网信令数据具有大数据特征:

1)数据量巨大。存储的数据量十分庞大，通信技术的快速发展和智能终端的普及，使得信令数据的数据规模从TB级别跃升到PB级别甚至更大，因而对其分析的计算量也大。

2)数据类型多。数据类型非常复杂，不仅仅包括大量的像文本这种结构化和半结构化数据，还包括图片、音频、视频以及地理位置信息等非结构化的数据。

3)价值密度低。对数据的处理挖掘存在潜在的价值，但是大量复杂的不相关数据会导致价值密度低。

4)处理速度快。数据的增长速度快，那么处理速度也要快。处理速度越快，实时性越高，其价值就越大，发挥的效能也就越大，这是大数据区分于传统数据挖掘的本质区别[3]。

1.2 大数据处理在信令监测系统中的应用

由于现网信令数据的大数据特征，不能运用传统的信令监测系统对其进行分析。面对大数据，传统的信令监测系统存在以下几个方面的问题[4]:

1)网络的运行质量在很大程度受数据量的影响，现网数据不仅包括结构化数据，还包括非结构化数据，传统的信令监测系统只适合于分析结构化数据，而不能分析视频数据等非结构化的数据。

2)由于网络链路和数据流量的飞速增长，传统的信令监测系统在海量数据的高效率读写、高并发读写、可扩展性等方面存在缺陷，无法满足海量数据在计算和存储等方面的需求。

3)现网大数据要求信令监测系统能够满足大规模数据挖掘、实时反馈分析结果、实时触点营销等需求，但是传统的信令监测系统因其垂直化的架构设计使得建设成本高，而且服务的响应时间长，难以满足大数据对信令监测系统的要求。

针对上述问题，本文提出的基于大数据平台的信令监测系统，实现了对多样化数据结构、海量信令数据的分析、挖掘和存储，具有建设成本低廉、数据实时处理高效、系统配置灵活、系统扩容平滑等显著优势。信令监测系统的大数据关键技术[5,6,7]主要包括并行计算、分布式数据库、分布式文件系统和云存储等。

1.2.1 并行计算

并行计算是指利用多种计算资源来协同解决同一个计算问题的一种计算手段，能够有效地提高整个系统的处理能力和计算速率。其基本思想是将同一计算问题分配到若干个处理机同时进行计算，即将需要求解的计算任务分解成若干个子任务，各个子任务都由一个独立的处理机来完成并行计算。并行计算系统既可以是含有多个处理机的计算机，也可以是若干个通过某种方式相互连接的计算机集群。

1.2.2 分布式数据库

分布式数据库系统一般使用较小的计算机系统，采用分布式架构对海量数据进行存取，并通过集中服务器对资源进行管理或调度。其基本思想是将原来集中式数据库中的数据分散地存储到多个网络互连的数据存储节点上，从而获取更大的存储容量和更高的并发访问量。由于关系型数据库在处理海量数据时存在一些很难克服的缺点，使得可扩展性和并发性高的非关系型数据库得到快速发展，传统的关系型数据库开始从集中式模型向分布式架构扩展。

1.2.3 分布式文件系统

分布式文件系统是指资源存储在分布于各处且与网络互连的节点上，而不是一定连接在本地节点上的文件系统。其基本思想是通过网络互连的方式将各个节点的存储资源整合在一起，在提供大规模的文件存储能力的同时，还能降低高端服务器的使用成本。分布式文件系统通常采用C/S(客户端/服务器)的设计模式，将数据存放在一个可供多用户访问的服务器集群上。当用户访问分布式文件系统时，首先需要定位用户所需存取数据在集中服务器存放的节点，定位成功之后，分布式数据存取就与传统文件系统下普通的资源存取方式一致。

1.2.4 云存储

云存储是指将存储资源放到云上供用户随时随地通过任何可连网设备存取的网络存储系统。其基本思想是利用网络技术、集群应用或分布式文件系统等技术，将网络中大量的类型各异的存储设备通过软件集合起来协同工作，实现数据存储功能和数据访问功能[8]。

2 基于大数据的信令监测系统设计

在传统信令监测系统的基础上，基于大数据的信令监测系统如图1所示，整个系统采用集群架构和分层分布式的数据处理模式[9]。

2.1 数据采集层

数据采集层主要功能是通过一个或者多个采集点的信令采集设备采集通信网的信令数据与业务数据，如GB接口、IUPS接口等接口的数据，并把这些接口的数据进行整合，即把数据进行过滤、复制、整合处理，实现数据的统一存储。信令采集点的位置一般设在信令转接点、长途局等信令链路比较集中的地方[10]。

2.2 数据处理层

数据处理层主要功能是完成对采集层采集到的信令数据进行处理，包括协议解析、数据转换、批量计算等。该层根据功能可分为以下两大模块。

2.2.1 信令预处理

该模块主要功能是把采集设备采集到的二进制数据流进行预处理，如接口适配、协议解析等，转化成用具有逻辑意义的数据结构并能提供给计算平台的调用。首先，整合后的数据经过接口适配，根据需求的不同选择相应的协议解析方案。协议解析分为两种:一种为只提取消息中的部分关键字段信息，跳过其他字段信息的简单解码;另一种为对信令数据或者业务数据整条消息的所有信息都进行解析并对某些关键字段生成解析说明的详细解码[11]。其中详细解码的流程如图2所示。

经过解码后，需要把同属一个CDR流程的消息进行关联匹配并合成[12]。合成流程如图3所示。

2.2.2 分布式计算平台

经过预处理之后得到原始CDR文件，根据不同的需求经过数据分流分发到各个分布计算流程进行处理。若需要对现网数据进行流量统计、呼损分析、话务统计等实时处理，则选择实时数据流处理流程;若分析用户的群体构成及其偏好或者高精确度与高效率的大数据量处理任务，可以分流到批量式计算处理流程，并把相关数据存入分布式数据库，以供应用层各种业务需求调用[13]。

在批量式计算处理流程中，用户偏好等分析需要对用户使用的业务进行识别，故该流程采用了DPI技术进行业务识别。DPI业务识别流程如图4所示，具体流程如下:

1)读取DPI业务特征库，生成DPI数据字典;

2)读取数据文件，逐条地提取业务数据中的HOST,URL,Refer等字段信息;

3)根据HOST信息，通过DPI数据字典查找相关特征，并与URL、Refer等字段进行比对，若URL等信息与特征相匹配，则识别成功，并把业务信息与HOST等字段进行关联;否则业务信息为空。然后再进行下一条数据识别;

4)把识别的结果录入数据库[14,15]。

2.3 应用层

应用层主要功能是把数据处理层处理得到的数据进行归纳、分析，按照不同的专题应用进行统计，如呼损分析、TOP业务统计、网络优化等。对于各种应用的结果，可选用柱状图、表格、折线图、饼状图等不同形式进行展示。

3 基于大数据的信令监测系统应用分析

信令监测系统的大数据解决方案，实现了对海量数据的并行处理和深度挖掘，相对于传统的信令监测系统，在网络优化、业务经营、网络安全等方面具有显著的优势。

3.1 网络优化

基于大数据的网络优化应用通过信令采集模块采集原始信令数据，并利用大数据平台的处理能力对移动网络各项KPI进行统计挖掘，从而找到影响网络质量的原因。由于我国各地区通信服务水平的差异，三大运营商需要综合协调发展不同的网络类型，如2G、3G、LTE等网络，各类型网络的统计KPI多达百余项，基于大数据的信令监测系统可以对网络问题进行高效处理和实时定位。

以某部专用网(SS7信令系统)中的实测数据作为数据来源，对专用网络下的ISUP呼叫接通率进行统计，统计结果如图5所示。

由图5第一行可得到源信令点和目的信令点之间的呼叫接通率为98.29%，呼叫应答率为74.36%，通信状态良好。

以重庆移动某地区公用网络中采集的数据作为数据来源，对该地区公网网络下的附着成功率和路由区更新成功率进行统计，统计结果如图6、图7所示。

从图6和图7可以得到该地区附着成功率只有40%，路由区更新成功率为90%，网络通信质量较差。

3.2 业务经营

随着OTT应用的爆发式发展，从电信运营商的角度，三大运营面临越来越大的管道压力，并逐步从语音业务转向流量经营。基于大数据的信令监测系统通过对用户海量业务数据的挖掘统计，可以实现用户偏好分析、业务TOP分析、用户流量分析以及夜间高流量用户等分析。通过以上分析，不仅可以提高用户体验，还可以实现业务的精细化经营和用户的差异化服务。

图8展示了在客户端页面中查询出的2015年1月视频用户对3G门户-NBA直播中心的偏好程度分析情况。

从图8中可以看出，通过对当月视频用户使用时长、使用流量和访问次数3个指标的统计分析后可知:行号为1,IMSI为“460026083440797”的用户被划分为强偏好用户;行号为6,IMSI为“460025083291428”的用户被划分为发烧用户。

图9展示了2015年1月—3月根据用户量统计出的电视剧Top10，从图中可以看出，用户量排名前三的都是网络热播剧。

3.3 网络安全

随着业务综合化、开放化和网络融合化的发展，专用网络的安全脆弱性日益显露出来，传统的信令监测系统主要是实现网络优化和故障诊断，在网络安全防护方面相对比较薄弱。基于大数据的信令监测系统通过对各类攻击方式的深度挖掘，能够有效地对攻击行为进行识别，并制定相应的防护方案，从而达到保护网络安全的目的。

3.3.1 骚扰电话拦截

骚扰电话是指攻击者通过合法用户接入，利用电话网资源，骚扰和欺骗合法用户，常见的骚扰电话形式有以下3种:

1)被叫用户听到电话振铃，用户电话振铃却无法正常通话;

2)被叫用户听到电话振铃，主叫号码显示为空号或是公共服务号码;

3)用户听到电话振铃，接通之后转至一段录音。

基于大数据的信令监测系统通过对各类攻击行为的深度挖掘，分析出骚扰电话具有以下攻击特征:

1)振铃时长短;

2)超频呼叫;

3)主叫占比门限高，号码作为主叫呼出的次数占所有呼入呼出次数比例高;

4)用户通常无法正常接听;

5)不产生话单记录。

根据以上骚扰电话的特征，基于大数据的信令监测系统网络安全防护方案如图10所示。

信令消息采集:从链路数据包中过滤出需要处理的信令消息。

呼叫状态恢复:对采集到的信令消息进行解码合成，从中得到每一条呼叫的用户序号、开始时间、结束时间、主被叫号码、接通时长、应答时长、通话时长等表征用户通话过程的行为参数，并为每条呼叫建立记录以供分析。

分析检测:对骚扰电话进行检测，若判断为骚扰电话，则通知系统进行拦截，并保存该号码至骚扰电话黑名单。

行为数据挖掘:将该条呼叫记录与数据库中的海量数据进行深度挖掘分析，如该呼叫主叫占比门限高达90%，则判断该条呼叫的号码为骚扰电话。

识别特征库设置:自动或人为调整分析检测环节中所设置的各种判决门限。

骚扰电话拦截:对骚扰电话进行拦截，并以短信形式预警被叫用户。

以某部队专用网(SS7信令系统)中的实测数据作为数据来源，对号码的接通时长、应答时长等指标统计分析如图11所示。

通过以上统计，基于大数据的信令监测系统可以对专网网络下的各个号码进行全面监控，结合骚扰电话拦截系统，可以全面防范并处理骚扰电话的攻击。

3.3.2 虚假主叫号码识别

虚假主叫主要是通过改变主叫号码来实施欺骗或欺诈，基于大数据的信令监测系统可以通过在汇接层获取主叫号码的海量信令数据，然后通过大数据处理技术与现网识别规则库进行对比，从而最终判断来话路由是否正常。

以某专用网为例，整个虚假主叫号码识别步骤如下:

1)建立全网所有交换局下各用户号码与该信令点编码或IP地址之间的对应关系，形成识别规则库;

2)获取主叫号码和发送呼叫信令的交换局源信令点编码以及IP地址;

3)将提取的关系与识别规则库进行对比;

4)若识别为虚假号码则对用户进行预警。

整个识别流程示意图如图12所示。

以某部队专用网(SS7信令系统)中的实测数据作为数据来源，通过PL/SQL程序在监测系统数据库中查询到5月15日的虚假号码识别结果如图13所示。

从图13中可以看到，5月15日共查询到两个虚假号码，分别是“0603969774”和“0701014331340”。

4 结束语

未来移动通信将迎来大数据时代，如何快速、高效地实现海量数据的处理与挖掘将成为未来建设信令监测系统的研究重点。基于此，本文提出了一套信令监测系统建设方案，该方案基于大数据分析，详细分析了该方案的业务需求和功能架构，重点介绍了该方案在网络优化、业务经营、网络安全三方面应用，验证了其合理性及可行性，为大数据时代背景下信令监测系统的建设提供了重要的理论支撑和实践基础。

摘要：随着计算机技术与通信技术的飞速发展,各种数据流量也随之急剧增加,这给信令数据的采集、存储、分析带来了巨大挑战。在传统信令监测系统的基础上结合大数据特征,设计了该信令监测系统建设方案,讨论了该方案的关键技术和功能架构,详细介绍了该方案在网络优化、业务经营、网络安全三方面的应用,为大数据时代下实现信令监测、提高网络安全,提供了理论支撑和实践基础。

关键词：大数据,信令监测系统,网络优化,业务经营,网络安全

信令数据 篇2

【关键词】STP；信令；链路

【中图分类号】TN91 【文献标识码】A 【文章编号】1672-5158（2013）01—0053—02

1 概述

我公司的STP采用的是S1240设备。在STP系统中，MTP部分所需的基本功能模块有信令终端模块（HCCM386或MCCSM），7号信令系统辅助控制单元（SACEN70），数字中继模块（DTM）。MTP第一级，信令数据链路功能-对应中继模块DNTUPTCE，每一条链路占用一个模块即一个2M口的一个时隙。MTP第二级信令链路功能-对应高性能公共信道信令模块HCCSM386，每一条链路占用一个模块八个时隙中的一个。MTP第三级信令网功能-对应七号信令辅助控制单元SACEN70，消息处理功能由信令终端模块完成，网络管理功能由SACEN70模块完成。

一般来说，我们处理障碍时，也是按照这个层次结构，由低层到高层进行分析。

2 S1240设备No.7信令部分故障处理

2.1 常用指令介绍

2.1.1

2.1.2

2.1.3

2.2 故障的一般处理过程

在S-1240中，LINK的正常工作状态为“ACTIVE”，而且应该处在话务状态“IT”，除此之外的其他状态都是不正常的，下面就不同情况给出处理方法：

2.2.1 LINK的状态为“ACTING”，业务状态为NOTRF

这种情况应首先考虑传输原因，传输故障可能是传输告警或误码率过高，排除传输故障后再显示链路状态。或没有传输告警LINK仍然不好，则检查本局是否良好。可用220对链路做打死激活，或用220指令打死后做ACTLOOP看是否可以进入ACTIVE-LOOP状态。若LINK为“ACTIVELOOP”则证明本局无误，若为“ACTING-LOOP”则说明本局有问题。一般为该LINK所在的SLTC安全块有问题，每个SLTC安全块对应的硬件为HCCM的一个SLTA板。通常的做法是对其进行打死激活的操作。

：D SLTC，NA，NBR

：I SLTC，NA，NBR

NA为241命令中看到的CCMEN的PCE，NBR为CCMEN的TN。

打死激活后，SLTC的OBC会重新LOAD数据，需时2-3分钟

有些情况下，问题可能出现在中继模块，但这种情况会表现为依赖于该中继模块的所有LINK均不能正常工作。中继模块出现问题的情况较少。排除以上情况后，基本可以断定本局没有问题，这时将链路恢复成“ACTING”状态，同对端局联系解决。

2.2.2 LINK为“OOS”状态，业务状态为“NOTRF”

这种情况一般是SLTC有问题，处理方法同上。

：D SLTC，NA，NBR

：I SLTC，NA，NBR

NA为241命令中看到的CCMEN的PCE，NBR为CCMEN的TN。

打死激活后，SLTC的OBC会重新LOAD数据，需时2-3分钟。

链路如果过了2-3分钟后，状态一直为OOS，证明OBC的装载没有成功，需要对模块做CE RES，再不成功就需要更换SLTC所在的硬件。

>AC 4（4是SLTC所在的NA）

>CE RES

如果链路状态变成ACTING，再对其进行自环看是否可以进入ACTIVE-LOOP状态。

可对对应的HCCM模块进行CE RES（注意不是RB），过2分钟OBC装载完毕后，应该进入ACTIVE或ACTING状态，否则更换SLTA板。

链路如果过了2-3分钟后，状态一直为OOS，证明OBC的装载没有成功，需要对模块做CE RES，再不成功就需要更换SLTC所在的硬件。

>AC 4（4是SLTC所在的NA）

>CE RES

如果链路状态变成ACTING，再对其进行自环看是否可以进入ACTIVE-LOOP状态。

2.2.3 其他情况

LINK为“MAI-DIS”业务状态为“NOTRF”，信令终端安全块工作异常（例如进入FLT状态），先对消除安全块告警后，再对链路进行220的打死激活。

LINK为“ACTING-LOOP”业务状态为“NOTRF”，此为使用220指令对链路进行打死并做ACTLOOP后，如果进入这种状态，说明本端工作不正常。可对对应的SLTC进行打死激活，过2分钟OBC装载完毕后，应该进入ACTIVE-LOOP状态，否则更换SLTA板。

LINK为“ACTING”业务状态为“RBLO”，此为对端处理机故障发送SIPO，必须由对端处理

3 S1240 STP信令链路故障处理案例

*故障现象：

GMSTP-SJZTSH1方向SLC=1信令链路频繁翻转，

*处理过程：

1.GMSTP执行指令

<220：DEST=“SJZTSH1”&NAT;，SLC=1，9=6.

<220：DEST=“SJZTSH1”&NAT;，SLC=1，9=5.

对该信令打死激活，无效。

2.GMSTP对信令模块进行

>：V SLTC，201，5，ALL操作后信令恢复正常。但一般两三天后信令又会不活。

3.查看5691报告，发现信令翻转时事件均为H1B，排除传输不稳导致信令翻转的可能。

EVENT+MEANING

H1B

SIE/SIN/SIO/SIOS RECEIVED

4.GMSTP对信令模块做环回测试，执行指令

<220：DEST=“SJZTSH1”&NAT;，SLC=1，9=6.

<220：DEST=“SJZTSH1”&NAT;，SLC=1，9=30，

显示信令状态为ACTIVE-LOOP。考虑到SLC=1信令链路所在的中继模块上同时承载了四条信令链路，而翻转的总是SLC=1信令链路。于是考虑更换信令模块。但更换信令模块H201&5后故障依旧。

5.在排除对端原因造成信令翻转的可能后，更换中继模块H114。故障彻底解决。

*处理结论

对于信令链路频繁翻转的处理，现场主要信息就是5691报告（链路翻转报告），其中我们主要关心局向、信令模块、中继模块、EVENT等信息。先看EVENT，经常出现的EVENT代码有H′17、H′18、H′1B、H′1C等等。（各EVENT说明可参考设备维护资料）

4 结束语

信令数据 篇3

在LTE网络基本覆盖基础上, 运营商的关注重点从广度覆盖转向深度覆盖, 由于目前4G网络缺少对网络覆盖盲区的全面评估, 所以制约了规划、建设、市场推广等工作的效率。网络质量评估现在多采用DT+CQT、基于仿真的覆盖评估、基于测量报告 (MR, Measurement Report) 的覆盖评估三种方法, 但是, DT+CQT需要现场测试, 时间、人力成本高, 且无法评估全网用户感知情况;基于传输模型仿真的覆盖评估受制于传播模型的准确性, 且缺少用户级信息, 实时性差;基于MR采样点的覆盖评估缺少用户级信息, 且覆盖盲区无MR数据上报, 无法准确识别盲区。

针对上述问题, 本文以信令数据为出发点, 介绍了基于信令数据实现LTE覆盖评估的方法, 并在传统评估的基础上提出了网络盲区的定位方法, 可以解决常规评估手段的不足。

2 基于信令软采MR三级匹配定位的覆盖评估

MR是终端发给网络的测量报告, 其中包含参考信号接收功率 (RSRP, Reference Signal Receiving Power) 、时间提前量 (TA, Time Advance) 、信号到达角度 (AOA, Angle of Arrival) 等信息。如果知道每条MR数据的位置信息, 即可从用户角度准确评估网络覆盖情况, 但普通的基于TA、AOA的定位方式精确度较低, 在LTE网络深度覆盖要求越来越高的情况下, 显然无法满足精准规划、精准优化的工作要求。通过精确MR匹配、指纹库MR匹配和基于TA、AOA的MR匹配, 可以更加准确地对有网络覆盖区域的网络情况进行整体评估。

(1) 精确MR匹配

精确MR匹配采用MR匹配终端经纬度信息, 准确定位每条MR数据, 从而实现精确覆盖评估。定位采用软采和硬采信令数据关联的方法, 提取有效的经纬度信息, 与MR数据使用时间戳进行关联。

1) 基于软硬采信令数据关联的终端定位算法

LTE信令采集分为硬采和软采。信令软采对UU、X 2数据进行采集, 信令硬采对S 1-U接口数据进行采集。硬采数据上报的S1-U-HTTP XDR中包括了终端上报的URL (互联网标准资源地址) 信息, 当使用的APP有经纬度上报时, 可以通过经纬度的相关格式在URL中对其进行提取 (图1) 。

对硬采S1-U-HTTP XDR中提取的经纬度信息需要进一步判断其有效性。首先判断终端上报经纬度信息与终端当前占用的小区是否匹配, 如果经纬度明显超出小区覆盖范围则视为无效经纬度;然后根据不同的地图供应商对获取的经纬度进行纠偏, 真实还原终端的位置信息, 提供给后续分析。

2) 硬采的终端位置信息与软采MR数据进行关联

通过硬采数据获取终端位置信息后进一步与软采的MR数据进行关联, 从而使MR数据带有经纬度。由于软硬采数据采用统一DPI规范, 在时间上具有一致性, 因此可直接通过时间及终端标识进行关联。算法主要通过终端标识 (IMSI) 、事件时间 (Procedure Start Time、Procedure End Time字段) 将S 1-U-HTTP及UE-MR-XDR采用时间滑动搜索方式进行关联, 时间窗可根据匹配程度进行调整, 一般设置为10s, 从而保证关联的有效性。关联匹配成功后, 即可将准确的经纬度信息回填至UE_MR_XDR数据中。

(2) 指纹库MR匹配

根据已有经纬度的MR数据, 通过MR测量的TA、AOA、服务小区和邻区的RSRP作为特征值建立指纹模型。对于在URL字段中没有匹配到经纬度的MR数据, 可通过指纹模型进行关联匹配 (匹配规则为TA、AOA偏离5%以内, RSRP偏离2db以内) , 对匹配成功的MR直接使用指纹模型中对应的经纬度信息。

(3) 基于TA、AOA的MR匹配

对于前两个方法未匹配的MR数据, 可以通过TA、AOA进行定位。将TA和AOA进行关联计算, 确定终端距离基站的位置及方位角, 结合基站经纬度, 可实现对终端的定位。基于定位信息关联终端的参考信号接收功率 (RSRP) , 即可得到小区地理化覆盖情况, 从而发现覆盖弱区。此定位方式的误差较前两种方式的精确度要差, 但可以全量匹配MR数据, 通过海量数据叠加以弥补位置准确度低的问题。

3 基于信令数据的LTE网络盲区识别算法

通过上述三种方式的MR数据聚合, 基本可以准确评估整体网络覆盖情况, 但只有当终端驻留在4G网络时才会上报MR信息;当终端进入覆盖空洞、离开4G网络时, 则无法通过RSRP信息对网络覆盖情况进行全面有效的评估。本文采用基于信令数据的盲区识别算法来补充MR评估, 主要是根据终端在LTE网络业务态重定向及空闲态TAU的特征, 识别4G到2G、2/3G至4G的临界区域, 以确定网络覆盖盲区。

业务态下, 使用软采数据中4G回落到2G时的A2事件、服务小区的A2盲重定向门限、RRC release消息等信息, 确定盲重定向终端及盲重定向事件时间;空闲态下, 使用硬采数据中的TAU信令判断终端异系统返回时间点。结合终端定位算法, 确定由于覆盖原因发生4->2、2/3->4G互操作事件的位置, 通过汇聚大量位置信息, 找出网络覆盖盲区。本方法可以更全面、精确地定位覆盖盲区, 对网络规划建设具有重要意义。

(1) 连接态盲区识别算法

当终端处于连接态时, 根据发生的异系统重定向以判断终端处于4G覆盖盲区。目前现网99%以上的4->2互操作事件是A2盲重定向, 可以采用判断A 2盲重定向事件以识别盲区边界。判断方法为是否发生基于测量的A2盲重定向事件。A2盲重定向事件是指服务小区差于绝对门限, 终端不上报异系统测量报告, 而直接切换至2G。根据统一DPI规范, 在软采数据的UE_MR XDR中, MR TYPE共有9个值, 其中字段值为3表示为A2事件。将A2事件上报的RSRP与当前占用小区的互操作门限进行关联比对, 同时判断A2事件后5S内是否有RRC release消息, 综合确认该次A2事件是否为异系统盲重定向事件。具体判断流程如图2所示。

(2) 空闲态盲区识别算法

当终端处于空闲态时, 可通过TAU (Tracking Area Update, , 即跟踪区更新) 事件的消息内容判断是否为从异系统重选回4G而触发的TAU流程。如果判断为是, 则说明该终端当前位置处于4G覆盖边缘, 刚好满足2G到4G的重选条件, 终端所处位置同时为4G盲区边缘, 通过大量样本点统计可有效识别覆盖盲区。

具体的判断方法为:通过TAU过程中终端返回的Attach request消息中携带的Old GUTI Type信元来判断终端是否是从2/3G返回。GUTI (Globally Unique Temporary UE Identity) 即全球唯一临时UE标识是由核心网分配, 在Attach Accept、TAU Accept等消息中带给UE;Old GUTI Type信元内容分Native GUTI和Mapped GUTI两种:当Old GUTI Type为Native GUTI时, 表明GUTI是由LTE网络分配;当Old GUTI Type为Mapped GUTI时, 表明GUTI是由2/3G网络SGSN分配的P-TMSI/RAI映射而来的, 这次TAU是终端从2/3G返回4G网络触发的, 此时终端所处位置为4G覆盖盲区的边缘。TAU Accept消息中Old GUTI Type信元截图如图3所示。

图3异系统返回4G时TAU携带OLD GUTI TYPE字段

由于CSFB终端返回4G时也会发生TAU, 通过信令发现CSFB时TAU的OLD GUTI TYPE字段为Native GUTI, 排除了终端因CSFB发生4G TAU对该算法的影响。相关信令截图如图4所示。

通过上述两种盲区判断方法, 确定在业务态及空闲态下因覆盖问题所触发的异系统互操作终端及相关事件发生的时间, 结合终端定位信息, 通过数据汇聚, 即可确定4G盲区覆盖边缘位置, 从而实现盲区识别。

4 结束语

基于MR和信令数据的网络覆盖评估和盲区识别方法, 通过对MR数据和软硬采信令数据的聚合分析, 结合终端定位算法, 对LTE网络覆盖情况进行全面评估;通过深入挖掘用户行为规律, 提出了网络盲区识别算法, 对无覆盖区域进行识别;从而为实现深度覆盖评估、用户投诉预警、网络精准规划建设、网络精准优化等工作提供了准确高效的网络评估手段。

摘要：本文介绍了基于信令软采MR的覆盖评估和基于信令数据的盲区识别算法, 阐述分析了算法中的终端定位、盲区识别两个主要步骤。盲区识别算法基于信令软采、信令硬采两种数据的关联, 在网络盲区识别上具有较高的准确性与实时性, 可进一步应用于深度覆盖评估、网络建设规划等方面。

关键词：信令,MR,覆盖评估,终端定位,盲区识别

参考文献

[1]李昶, 华志超, 刘猛.基于MR大数据的LTE网络结构评估方法.电信工程技术与标准化, 2015 (11) .

[2]王新楼, 郭超, 纪国强.基于MR位置指纹定位的优化算法分析与实践.无线通信, 2014 (11) .

[33]GPP TS 36.214:“Evolved Universal Terrestrial Radio Access (E-UTRA) ;Physical layer;Measurements”.

信令数据 篇4

关键词：信令接入单元,链路负荷,信令点

1 SAU (Signalling Access Unit)

SAU (Signalling Access Unit) 也就是信令接入单元, 主要应用于无线智能网、有线智能网、短消息。基于各交换版本的基础上也有不同SAU, 其目的都是完成一个相同的功能, 为业务侧提供信令接口。在工程设计时, 就需要考虑配置组网来保证链路负荷均匀;在安装维护时, 常遇到链路负荷不均类问题。文中主要从与SAU链路负荷相关的几个因素阐述负荷不均原因。要分析SAU上信令链路负荷情况, 首先需要了解SAU消息来龙去脉。SAU接收消息来源于两方面:一方面为STP或SSP发到SAU的消息;另一方面为业务侧发到SAU的消息。按消息传递方向分为上行消息和下行消息, 上行消息是通过SAU到达SCP的消息, 下行消息是业务侧 (SCP/SMSC) 在一次对话过程中返回的消息或主动下发的消息。上行消息到达SAU后, SAU会在该模块对话号范围内分配一个奇数对话号, 在整个对话交互过程中, 使用同一个对话号, 业务侧 (SCP/SMSC) 在对话过程中返回的消息, 根据对话号送到相应的模块上。智能网中, 如果在业务流程中有主动下发的消息 (如EXECUTE、ATI等操作) , SCP会在SCP配置的对话号范围内由小到大分配一个偶数对话号;短消息业务中, MT消息可以根据参数配置均分到SAU模块上。上行消息在各链路上负荷 (即SAU接收负荷) 是否均匀, 由对端STP或SSP确定;下行消息在各链路上负荷 (即SAU发送负荷) 是否均匀, 与多个因素有关。

2 如何实现SAU链路负荷均匀

2.1 SAU组网配置合理是保证链路发送负荷均匀的前提

一个链路集中的链路数应该为2n (n=0、1、2、3、4) , 这样才能保证链路集中各链路负荷均分。在32模SAU中由于模块之间通信带宽限制, 缺省设计具有优选本模块的特性, 即从业务侧下行的消息分配到某模块, 只要本模块有可用路由, 消息就从本模块链路发送出去;128SAU优选本模块特性是由软件参数表中参数P88控制。启用优选本模块特性后, 一个链路集分配到某模块的链路数应该为2n。这样才能保证同一链路集中在同一个模块的链路负荷分配均匀。为了使链路集中各链路负荷均匀, 一个链路集中链路均分在2n个模块中。如图组网中, LSTP1或LSTP2与SAU可开链路模块数为1、2、4、8、16, 一个链路集中链路均分到这些模块中, 例如一个链路集中有16条链路, 开在2个模块上, 每个模块开8条链路;开在4个模块上, 每个模块开4条链路;开在8个模块上, 每个模块开2条链路。从链路负荷均分的角度来看这样配置较为合理

2.2 同一链路集中链路编码为奇数和偶数的链路要放在同一模块中

SAU启用优选本模块特性时, 各模块接收负荷均匀才能保证一个链路集各链路负荷均匀。由于对端原因可能存在SAU上链路编码 (SLC) 奇偶链路接收负荷不均, 因此建议不要将同一链路集中链路编码为奇数和偶数的链路分开放在不同模块中, 这样会导致模块间负荷不均, 从而导致链路集中各链路负荷不均。例如, 一个链路集中8条链路分配在两个模块中, 一个模块SLC为0、1、2、3;另一个模块SLC为4、5、6、7。对于短信中心下发的MT消息要求到SAU各模块均匀。

2.3 本局信令点按GT选路时负荷要均匀分担

业务侧下行消息寻址到目的信令点是按GT选路送到LSTP1 (LSTP2) , 再由STP做二次翻译落地, 在远端信令点表中又定义了这对LSTP1、LSTP2为负荷分担信令点, 这样, 消息在SCCP层就会均分到一对LSTP1、LSTP2信令点上, 正常情况下, 在MTP层也会均分到一对LSTP1、LSTP2上。从SAU数据可以看出, 在全局码翻译表中, 对应GT码, 翻译结果为DPC+OLDGT, DPC为LSTP1或LSTP2, 远端信令点表中一对LSTP1、LSTP2定义为负荷分担信令点。在MTP层有到LSTP1、LSTP2相应数据。MTP目的信令点表中对应LSTP1、LSTP2数据中, 链路集选择码为0000。通过路由路由状态查询, 到目的信令点通过LSTP1、LSTP2的路由都是可用的, 对应路由分配的SLS都为0、1、….、F。这里所说的一对负荷分担信令点针对同一个本局信令点而言的。

2.4 本局信令点按DPC+SSN选路时负荷要均匀分担

业务侧下行消息寻址到目的信令点是按DPC+SSN选路 (DPC为目的信令点编码) , 消息通过LSTP1 (LSTP2) 的MTP层转发到目的信令点, 消息分配到LSTP1、LSTP2是由该目的信令点路由确定, 如果通过LSTP1、LSTP2路由上分配的SLS均等, 那么, SAU的发送负荷到LSTP1、LSTP2会均匀。移动智能业务或短消息业务, 在全局码翻译表中对应GT码, 翻译结果为DPC+SSN, 不能通过对目的信令点对应GT码翻译到一对LSTP1、LSTP2上, 也就不能在SCCP层对消息进行负荷分担。只能在MTP层通过路由选择, 将消息负荷均分到一对LSTP1、LSTP2上。通过查询到该目的信令点路由状态为可用的, SLS均分在两个链路集上。

2.5 目的信令点表中链路集选择码正确配置

目的信令点表中链路集选择码正确配置, 才能保证到该目的信令点同优先级路由的负荷均分。如果到该目的信令点同优先级路由数为1、2, 对应的链路集选择掩码分别置“1”位数为0、1, 如0000、1000。注意不要与链路选择码重叠。

2.6 链路集表中的链路选择码正确设置

链路集表中的链路选择码正确设置, 才能保证该链路集中各链路负荷均分。如果链路集中链路数为2n (n=0、1、2、3、4) , 对应链路选择码分别置“1”位数为0、1、2、3、4, 如0000、0001、0011、0111、1111。注意不要与链路集选择码重叠。

2.7 信令点链路集选择掩码错开设置来保证负荷均匀

业务侧下行消息寻址到目的信令点是按DPC+SSN选路, 如果到该目的点有两条同等级路由, 各路由对应的链路集中链路数为16, 这样, SLS均分配到两个链路集中, 一个链路集有16条链路只有一半链路承担负荷, 只有通过各局点业务情况综合考虑, 到不同目的信令点链路集选择掩码错开设置, 来保证一个链路集中承担的SLS为0、1、。。。、F, 达到在链路集中各链路负荷基本均匀的目的。或通过调整到不同目的信令点路由顺序来保证一个链路集中承担的SLS为0、1、。。。、F, 达到在链路集中各链路负荷基本均匀的目的。

SAU具有多信令点功能, 多信点之间具有负荷分担特性, 是业务侧下行消息中主动下发的消息均分到SAU多个本局信令点上。如智能网中, 主动下发的消息 (如EXECUTE、ATI等操作) ;短消息中MT消息。

3 配置数据实现MTP负荷分担

3.1 增加MTP链路集进行负荷分担

增加MTP链路集使用链路选择方法:设置链路选择字段;ADD N7LKS:LS=1, LSN="ff", APX=1, LKS=2;LKS为“链路选择”。

信令点1是本局信令点。信令点2是相邻目的信令点。信令点1和信令点2之间直连有一个信令链路集, 由此可知, 该信令链路集中包括四条信令链路:信令链路1、信令链路2、信令链路3、信令链路4。假设这四条信令链路都是可以利用的, 怎样才能完全利用这四条可用的信令链路来实现信令业务的负荷分担呢?存在于[MTP链路集表]中的[链路选择]字段就是用来辅助我们实现信令业务的负荷分担。

按照ITU-T规范中的MTP协议, 经由MTP传输的用户业务使用标号来进行业务的负荷分担, 标号的最后一个字段是SLS (信令链路选择) , 长度为4个比特。MTP部分就是靠着这四个比特来区分不同的信令业务。这也就意味着MTP部分可以识别的业务种类共计16种, 编码为0~15。[MTP链路集表]中[链路选择]字段就是与这四个业务比特SLS一一对应。

“链路选择3位”对应了SLS四位中的最高位;“链路选择2位”对应了SLS四位中的次高位;“链路选择1位”对应了SLS四位中的次低位;“链路选择0位”对应了SLS四位中的最低位。正是因为这种一一对应关系, 在信令链路集内实现了信令业务的负荷分担。将“链路选择”字段的某一比特位置位就意味着SLS中对应的那个比特将被取出以参与负荷分担算法。

如果“链路选择”中并无一位被设置, 则会导致负载在信令链路集上的所有信令业务永远集中在第一条可用信令链路上 (假设所有信令链路集内的信令链路具有同一优先级别) 。当然, 如果信令链路集中仅有一条信令链路时, 正好符合这种情况。

如果“链路选择”中仅有一位被设置, 则因为21=2, 所以最多存在两种选择, 这种方式能够使两条信令链路的情况得到最好的负荷分担方式。

如果“链路选择”中有两位被设置, 则因为22=4, 所以最多存在四种选择, 这种方式能够使少于或等于四条信令链路且大于两条信令链路的情况得到最好的负荷分担方式。

如果“链路选择”中有三位被设置, 则因为23=8, 所以最多存在八种选择, 这种方式能够使少于或等于八条信令链路且大于四条信令链路的情况得到最好的负荷分担方式。

如果“链路选择”中四位都被设置, 则因为24=16, 所以最多存在十六种选择, 这种方式能够使少于或等于十六条信令链路且大于八条信令链路的情况得到最好的负荷分担方式。

根据ITU-T的No.7信令规范定义, 一个信令链路集中的信令链路最多存在16条。

3.2 增加目的信令点进行负荷分担

增加目的信令点使用链路集选择方法:设置[链路选择]字段;ADD N7LKS:LS=1, LSN="ff", APX=1, LKS=2;LKS为“链路选择”。

信令点D1是本局信令点。信令点D2是准直连的目的信令点, STP1和STP2是两个STP点。去往D2的信令路由总共有两条:D1-STP1-D2 (信令路由0) 和D1-STP2-D2 (信令路由1) 。也就是从D1发出的去往D2的信令消息可以选择这两个“大”方向出局去往D2。假设这两条信令路由都是可以利用的, 怎样才能完全利用这两条可用的信令路由来实现信令业务的负荷分担呢?存在于[MTP目的信令点表]中的[链路集选择]字段就是用来辅助我们实现信令业务的负荷分担。

按照ITU-T规范中的MTP协议, 经由MTP传输的用户业务使用标号来进行业务的负荷分担, 标号的最后一个字段是SLS (信令链路选择) , 长度为4个比特。MTP部分就是靠着这四个比特来区分不同的信令业务。这也就意味着MTP部分可以识别的业务种类共计16种, 编码为0~15。[MTP目的信令点表]中[链路集选择]字段就是与这四个业务比特SLS一一对应。

“链路集选择3位”对应了SLS四位中的最高位;“链路集选择2位”对应了SLS四位中的次高位;“链路集选择1位”对应了SLS四位中的次低位;“链路集选择0位”对应了SLS四位中的最低位。

正是因为这种一一对应关系, 系统在信令路由间实现了信令业务的负荷分担。将[链路集选择]字段的某一比特位置位就意味着SLS中对应的那个比特将被取出以参与负荷分担算法。

如果[链路集选择]中并无一位被设置, 则会导致去往该目的信令点的所有信令业务永远集中在第一条可用信令路由上 (假设所有信令路由具有同一优先级别) 。当然, 如果仅有一条信令去往该目的信令点时, 正好符合这种情况。

如果[链路集选择]中仅有一位被设置, 则因为21=2, 所以最多存在两种选择, 这种方式能够使两条信令路由的情况得到最好的负荷分担方式。

如果[链路集选择]中有两位被设置, 则因为22=4, 所以最多存在四种选择, 这种方式能够使少于或等于四条信令路由且大于两条信令路由的情况得到最好的负荷分担方式。

如果[链路集选择]中有三位被设置, 则因为23=8, 所以最多存在八种选择, 这种方式能够使少于或等于八条信令路由且大于四条信令路由的情况得到最好的负荷分担方式。

如果[链路集选择]中四位都被设置, 则因为24=16, 所以最多存在十六种选择, 这种方式能够使少于或等于十六条信令路由且大于八条信令路由的情况得到最好的负荷分担方式。

根据ITU-T的No.7信令规范定义, 去往一个目的信令点的信令路由最多有16条。

4 总结

通过对合理配置SAU组网、同一链路集中链路编码为奇数和偶数的链路要放在同一模块中、本局信令点按GT选路时负荷要均匀分担、本局信令点按DPC+SSN选路时负荷要均匀分担、目的信令点表中链路集选择码正确配置、链路集表中的链路选择码正确设置、信令点链路集选择掩码错开设置来保证负荷均匀、增加MTP链路集进行负荷分担、增加目的信令点进行负荷分担阐述及分析, 基本上对信令链路负荷分配有了整体的新认识, 希望能够帮助大家解决绝大部份信令链路负荷不均问题。

参考文献

[1]李小良.通信网络互联中信令故障的分析与处理[J].信息通信, 2010, 4.

信令数据 篇5

区域人流量分析统计是国家制定政治经济政策, 指导人民生产生活的一项非常重要的参考依据。但长期以来, 统计部门只能依赖于抽样统计[1,2,3]的方式来进行获取。这种方式需要消耗大量的人力物力, 统计周期较长且很难得到一个较准确的数据。而且由于人群的流动性, 实际人群分布数据是一个动态变化的过程, 传统的统计方法根本无法实现对数据的动态掌握。文献[4]中提出了一种利用用双目摄像机原理进行人流量统计的方法, 该方法采用两个CCD摄像机, 运用双目立体视觉技术、摄像机标定算法与立体匹配算法对人流量进行统计。这种统计方式与人工计数方式相比更加智能化, 对铁路站、机场以及一些大型的展览馆比较适合, 但是由于要部署大量的摄像机与服务器, 部署周期较长, 硬件成本较高, 后期维护成本也较高。

随着互联网与移动通信技术的迅速发展, 移动用户占手机使用总人口的比例迅速攀升, 尤其在北京等发达地区, 移动用户已经接近人口总数的80%。因此, 移动用户的分布情况, 可以近似于地区人群的总体分布情况。与此同时公众出行群体中手机持有者的比例也日益上升, 这使人们越来越认识到移动通信网络中的手机信令数据可以作为一种理想出行分析探测器[5]。

目前, 各级政府部门包括国家旅游局、北京市公安局、北京市交通委员会、北京市旅游发展委员会以及北京市各区县相关部门都有关于移动用户资源数据的应用需求[6,7]。如交通规划、交通调查、旅游景区等重点区域的人口流量监测、流动人口监测管理等等, 但由于目前缺乏现网数据统一的处理应用平台, 在之前的客户需求满足上, 出现了需求反应时间长, 效率低下等问题。本文正是基于以上状况结合北京移动信令处理基础平台项目提出了一种利用现网移动信令数据来实时统计区域人流量的系统架构, 该系统已通过北京移动等相关部门的验证, 目前在北京移动昌平机房试运行。

2 系统设计

2.1 原理

实时人流量是交通量的一种, 交通量[8]是指单位时间里通过道路或某一交通小区断面的交通实体数量。基于手机信令的流量统计, 这里的交通实体数量指的是人数基础平台通过移动通信信令进行人流量分析的一个根本性依据是通过移动用户发生的通信事件记录 (如用户呼叫、短信、位置更新等通信事件) 来判断该用户所处的位置。本平台通过对甲方区域信息服务业务系统传送过来的合成后的甲方移动通信网络全网相关接口 (A接口、Mc接口、HSTP等) 的海量用户信令基础信息, 调用相应算法进行存储分析, 并结合GIS技术, 实现甲方网络参数与GIS地图的自动匹配并动态更新, 在保障用户信息安全的同时, 满足政府类客户对特定区域的人口流量、出行统计需求[9,10], 以及甲方内部平台的数据支撑统计需求。

2.2 系统的总体设计

为描述方便现将用到5个接口定义如下:

IF1:基础平台与区域信息服务业务系统之间;

IF2:基础平台与外部政府客户应用系统之间;

IF3:基础平台与VGOP等内部应用系统之间;

IF4:基础平台与EDSMP集团业务管理平台之间;

IF5:基础平台与网运中心网管系统之间

基础平台通过IF1接口从区域信息服务 (RISS) 订阅和接收区域信令事件, 经过数据挖掘和统计分析之后, 通过实时/非实时接口向外部政府客户应用系统和内部业务系统提供基于地理信息系统 (GIS) 的实时监测和历史分析结果。基础平台同时分别通过IF4和IF5与集团业务管理平台 (EDSMP) 和网运中心网管平台互连, 实现与集团业务平台的对接, 以及定期实时接收移动通信网络参数。总体方案如图1所示。

2.3 模块设计

由图1知, 该系统主要有三个部分组成:区域信息服务业务系统、信令处理平台、应用客户端, 本文主要针对该系统核心--信令处理平台的设计而写。信令处理平台主要有入库程序、接口程序、数据库ETL、外部应用、管理五部分组成。其中入库程序部分主要包括目录监控模块、文件生成模块、消息发送模块、消息监控模块;接口程序部分主要包括文件导出、SOCKET服务端、与其他系统的特定接口;数据库ETL部分主要包括存储过程与算法的调用、JOB及管理;外部应用部分主要包括登陆模块、图表展示模块、报表展示模块、文件导出模块;管理部分主要包括客户端模块、分析服务端模块、GIS管理模块、业务定制模块。模块设计详图如图2所示。

入库程序主要接收从甲方区域服务系统采集的现网手机信令数据, 根据配置好的数据库连接字符串, 从数据库读取用户手机归属地, 用户手机型号, 通话监控手机号, 短信监控手机号4个缓存;接口程序负责文件的生成, 数据的接收与发送以及与其它接口的链接;数据库是该信令平台的重要组成部分, 存储所有的存储与分析过程;外部应用主要是数据的前台WEB展示, 要求前台在WEB页面显示登陆信息, 数据能以报表与图表展示;管理模块主要实现平台所有服务器如WEB服务器、GIS服务器的管理以及GIS区域的圈选与相关业务的定制, 如特殊号码监控、通勤出行分析等。

2.4 平台的软件架构图

本系统主要对北京地区的海量移动网络信令数据进行存储、分析、展示, 由由于北京地区人口的流动性较强, 现网信令数据巨大, 那么如何保证系统对数据处理的实时性, 如何保证系统的可靠性与稳定性对整个系统至关重要。本系统的核心在信令数据处理模块, 该模块主要的负责对海量的数据的存储、分析, 该模块的性能直接影响整个系统, 为了提高整个系统的性能, 就必须合理规划该模块软件系统架构, 使其在实时数据的处理分析方面尽量最优。平台软件架构图如图4所示。

系统软件架构分为上下两层, 如图3所示, 从下往上分为基础数据处理层 (BDP:Basic Data Process) 和应用分析处理层 (AAP:Application Analysis Process) 。

基础数据处理层 (BDP) 主要通过IF1接口接收来自区域信息服务业务系统的信令数据。先将接收到的信令数据放入临时缓存, 然后经过压缩、建立原始数据索引、加密等预处理后将数据存放至细节数据库。细节数据库中存放的数据即AAP层进行分析的数据来源。而移动通信网络参数和GIS基础图层数据、基站图层数据等数据则通过IF5接口存放至网络参数存储单元和空间数据库。

应用分析处理层 (AAP) 主要负责根据需求进行进一步数据加工, 并对外提供数据服务。首先将细节数据库中的数据使用包括提取 (Extract) 、转换 (Transform) 和加载 (Load) 的ETL程序集 (应用数据库存储过程, 结合相关算法和分布式数据库等多种技术, 根据不同的业务需求相应设计的专题工具) 来分析统计数据。然后将分析处理结果存放至数据仓库DW1 (外部应用数据仓库) 和DW2 (内部应用数据仓库) 。通过数据服务引擎 (DSE1和DSE2) 和应用接口IF2、IF3来提供人流量和人口出行分析和VGOP等内部应用系统业务请求的分析结果或报表。并通过Web/GIS服务单元, 提供相应的GIS服务。

2.5 数据的处理流程

基础平台接收信令数据和网络参数等基础数据, 经过分析处理形成外部政府客户和内部业务平台所需的报表数据, 完整的数据处理流程如图4所示。

(1) 基础平台接收信令数据, 作为临时数据, 存储在临时数据区;

(2) 临时数据, 结合网络参数等基础数据, 经过预处理过程, 生成细节数据, 存贮在细节数据库;

(3) 细节数据经过ETL工具处理, 根据业务需求, 生成多维报表数据, 存贮在相应的DW中;

(4) 用户接收报表数据;修改或生成新的业务需求并部署给基础平台。

由于现网的手机信令数据是海量的, 所以数据入库前要进行预处理, 系统入库预处理数据流图如图5所示:

数据流向简要说明:

(1) 信令数据接口发送文本数据到远端服务器。

(2) FTP监控程序将远端服务器信令数据流读取到本地, 输出TXT文件。

(3) 数据预处理程序读取本地信令数据流处理后转化成加密后的元数据。将元数据流发送到数据库保存。

(4) ETL程序读取元数据多层处理后, 将加工的统计数据反发送回数据库保存。

(5) 数据库将统计数据按系统请求将被请求数据流发送至应用系统。

3 实现

这里以北京市旅游局指定区域 (天坛公园) 与北京市交通局所指定区域 (北站地区) 统计结果展示为例, 首先北京市旅游局与北京市交通局指出需要统计的区域, 北京市移动根据指定区域汇总区域对应的cellid, 然后将cellid表导入后台, Gis会根据导入cellid自动匹配区域, 然后调用算法, 产生数据, 最后在前台web展示:如图6, 图7所示。

由图6、图7知各景点或者交通枢纽早上1点至早上7点人流量较少, 8时之后逐渐增多, 中午12时左右最多, 下午5时候逐渐减少, 符合实际情况。通过该统计方法我们能利用信令处理平台直观地观察到各区域人流量状况, 图中数据展示已通过北京市相关部门验证, 目前该产品已在北京市移动正式上线运行。

4 结论

论文深入研究了实时性人流量统计方法的原理, 在此基础上设计出基于移动网络信令数据的人流量统计系统中信令处理平台模块, 并基于北京移动信令处理基础平台项目完成了对模块的验证, 成功实现了对各区域实时人流量智能化统计, 并展示出实时数据统计结果。应用该成果我们只需在现有移动网络现网的相应接口上安装信令采集设备, 并将采集到的信令数据传送至专用服务器进行分析、处理, 最后就在web页面展示统计结果。不需要重新部署新的系统, 节省了基础设施投入, 对移动网络不产生任何影响, 而且有利于快速覆盖和应用。

摘要：实时掌握城市交通枢纽、各大旅游景点的人流量状况, 为城市交通规划、旅游景点人力资源配备提供数据支撑已越来越受到相关部门重视。结合北京区域人流量系统项目中移动信令处理基础平台模块提出一种利用现网移动信令数据统计实时人流量数据的架构, 该平台已经过北京移动与北京市旅游委、交通局验证, 目前在北京移动正式运行。

关键词：信令处理平台,区域人流量,系统架构

参考文献

[1]关志超, 胡斌等.基于手机数据的城市交通信息采集技术研究[A].中国智能交通协会论文集[C], 北京:中国智能交通协会, 2012:845-848.

[2]冉斌.手机信令数据在城市交通管理中的应用与展望[A].中国智能交通协会论文集[C], 北京:中国智能交通协会, 2012:18-23.

[3]刘杰, 胡显标等.基于无线通信网络的人员出行信息系统设计与应用.公路交通科技[J], 2009, 26 (12) , 6-8.

[4]张艳琼.基于立体视觉的行人流量分析.计算机测量与控制, 2008, 5 (5) :12-17.

[5]杨飞, 裘炜毅.基于手机定位的实时交通数据采集技术[J];城市交通;2005, 3 (4) , 1-3.

[6]张博.基于手机网络定位的OD调查的出行方式划分研究[D].北京:北京交通大学, 2010.

[7]信令处理基础能力平台技术规范书.重邮汇测通信技术有限公司, 2012.9.

[8]北京移动信处理基础平台总体技术要求.中国移动集团北京公司, 2012.8.

[9]赖建辉, 陈艳艳等.基于手机定位信息的地铁乘客出行路径辨识方法[J].计算机应用, 2013, 1 (2) , 3-5.

中国一号信令解析 篇6

数字线路信令

线路信令的作用是监测中继线闭塞、空闲及占用与否等状态。中国1号信令为局间信令,在PCM传输系统中一个子帧由32个时隙(TS)组成,其中TS16传输信令。16个子帧组成一个复帧,每个复帧有16个TS16。对于TS16,每帧只传送8位码组,每一路只占4位,目前信令中的码组只用了前3位。第0针F0的TS16前4位是复帧同步码,为0000,第6位是复帧失步告警码,同步为0,失步为1,其他位为暂留位,默认为1。第1帧F1至第15帧F15的TS16,前4位依次传送1-15路话路信令,后4位依次传送16-30路的话路信令。由于每帧传送2路话信令,所以一个复帧才能包含完整个30路话。第1帧F1至第15帧F15的TS16信令简要功能如表1所示。PCM复帧结构如图1所示。

多频互控方式和记发器信令

多频互控方式分为前向信号和后向信号,二者是连续的,且每个前向信号都必须要后向信号进行证实。

记发器信令有两种,一是前向信号,二是后向信号。该信号用来完成主叫、被叫号码的请求与发送,主叫用户类型、被叫用户状态、呼叫业务类型的传送。前向信号分为I、II组,后向信号分为A、B组。其含义见表2。

前向信号

KA信号的定义:发端的市话局向发端的长途局或发端的国际局传送的关于主叫用户类别的信号,它是前向信号。KA信号为本次接续提供计费种类及用户等级。发端长途局将KA信号中关于通信业务类型及用户等级的信息翻译成KC信号。其编码含义见表3。

KC信号是前向信号,长话局与长话局之间发送的用于接续的控制信号,它的功能主要是对卫星电路的段数进行控制及为优先用户的通信提供保证。其编码含义见表4。

KE信号是前向信号,即市话局与市话局之间和终端的长话局向终端的市话局发送的用于接续的控制信号。其编码含义见表5。

主被叫电话号码用数字“0到9”来表示。阿拉伯数字“15”表示主叫号码已发完。

KD为发端业务类别,其含义如表6所示。

后向信号

后向A组信号证实和控制前向Ⅰ组信号。其含义如表7所示。

后向B组信号KB用来证实KD信号和控制接续,表示被叫用户的状态。其含义见表8。

信令的编码与传输

模拟线路信令用2600Hz或2400Hz单音频脉冲表示,或者利用通过中继线的电流表示,其通过话音信道传输。数字型线路信令编码和传输见数字线路信令部分。

记发器信号编码采用双音多频方法,步进是等差的,即120Hz。前向信号用的频段是1380Hz到1980Hz,六个频点取二个。后向信号用的频段是780Hz到1140Hz,四个频点取二个。一般情况下使用互控方式(MFC)或非互控方式(MFP)传输记发器信号。若用MFC时,其流程为:(1)主叫方发送前向信号;(2)被叫方接收到主叫方发送的信号后,给主叫方回传后向信号;(3)主叫方接收到被叫方回传的后向信号后,停止向被叫方发送前向信号;(4)被叫方检测到主叫方停发,停发后向信号。记发器信号可通过模拟信道传输;也可经PCM编码后传输。

结语

该文将中国1号信令解析为记发器信令与线路信令。着重分析了记发器信令的编码、构成、传输方式和数字线路信令的编码、构成、传输方式,进而可得出中国1号信令为随路信令,即信息与信令共用同一信道。

CDMA国际漫游信令探讨 篇7

对比起电信之前的小灵通移动终端业务, CDMA网络一大特点就是终端可以实现国内以致国外的漫游。无论是电信用户漫游到境外还是境外用户漫入到电信网络, 双方的网络都需要验证漫入的用户是否合法、用户权限信息、短信送往的网关等;这就涉及到双方的信令交互。本文介绍了CDMA国际漫游涉及的信令, 同时结合参加漫游信令工作的经验讨论目前电信CtoC (从C网到C网的漫游) 国际漫游的实现情况。

2 CDMA网络漫游信令简介

2.1 CDMA信令结构

CDMA网络主要使用ANSI-41版本C规范定义的网络模型:如图1中B、C、D等接口协议都在ANSI-41的定义范围内。

ANSI-41信令协议定义了各种无线通信系统间的操作系统定义为单个MSC及与之相关的位置寄存器、无线基站及处理中心等。“系统间”即用户在MSCs服务区之间移动。ANSI-41系统间操作支持三种基本的移动管理功能:系统间切换、自动漫游、系统间操作管理和维护 (OA&M) 。本文主要讨论ANSI-41信令协议里面自动漫游的相关情况。

电信CDMA网络ANSI-41的协议栈如图2所示, 应用业务信令消息通过SS7网络传送:MTP层主要提供了物理层、数据链路层和部分网络层的业务;SCCP提供了网络层的业务平衡。目前通过LSTP/HSTP/ISTP等传送该部分信令消息, 后续中会讨论到ISTP和HSTP需要配合完成的相关的SCCP层的工作。

2.2 漫游的基本信令流程

当一个用户在原籍系统之外漫游时, 受访系统即用户拜访的地区主要做以下判别处理:

(1) 对漫游移动台的原籍系统的识别, 这主要是接受漫游用户的运营商要识别这是哪个对端运营商的漫游用户, 需要向哪个运营商获取以及漫游时的一些策略, 这主要取决于运营商之间的协议。

(2) 对漫游移动台身份的验证, 这主要是鉴别移动台是否合法, 有没有欠费等问题, 对端运营商是否允许改移动台漫游, 这主要是鉴别移动台的合法性。

(3) 对漫游移动台业务能力的识别, 这主要是取得移动台的业务数据, 类似于固网的用户数据, 以便向用户提供各种业务如呼转、呼叫权限等。

对应于受访问系统, 原籍系统即是用户归属地则做以下判别处理:

(1) 对漫游移动台当前位置的识别, 避免用户处在两个系统边界或者实际没有漫出到拜访地的问题出现。

(2) 对漫游移动台当前状态的识别, 如移动台是否空闲等。

以上就是用户漫游到新系统时原籍系统和受访问系统需要处理的问题, 即漫游用户的注册过程。一个成功的漫游注册的ANSI-41信令流程如图3, 各个步骤如下:

(1) 新移动台进入业务区域, 新系统向HLR请求用户业务资格认证、位置更新

(2) HLR向前一服务系统进行位置取消

(3) 前一服务系统删除移动台记录并返回确认

(4) HLR接收位置更新

(5) HLR确认用户权限和提供用户业务列表后新服务系统向移动

在完成注册后, 当漫出的用户作为被叫时, 原籍系统和受访系统还需要交互TLDN (临时本地号码簿号码) 以便主被叫接续;在发送短信时需要交互短消息中心的地址等, 这里就不再赘述了。

3 CDMA国际漫游信令的组网实现

C网用户漫游到境外的C网, 或境外C网漫游到电信C网, 称为CtoC国际漫游。在漫游过程中, 无论是语音、短信还是数据业务, 漫入漫出地的网络都需要通过信令交互用户信息权限, 在完成了信令信息的交互后, 业务的提供就可以正常完成:例如通过电路域进行语音接续、短信网关完成短信业务等等。因此以下着重介绍国际漫游信令的组网和实现情况。

3.1 CtoC国际漫游的信令组网

为了实现各个运营商之间的漫游信令交互, 就需要各运营商建立信令的连接关系。世界上有多个CDMA网络, 如果采用网状连接, 则每两个运营商之间都需要开信令连接, 大大增加了网络的复杂性。同时不同运营商如果采用网状相连, 还需要互相建计费结算系统解决争议等等。因此目前国际漫游的信令都是通过若干家国际漫游信令转接商进行转接。各运营商的漫游信令都首先送到转接商, 由他们完成ANSI-41各种版本的信令适配以便各种交换机可以互相兼容;完成国际漫游的计费;存储转接的信令, 提供网页接口以便查询国际漫游信令;简单的漫游成功失败情况统计等。以下就是C网国际漫游的组网情况:

为电信转接国际漫游信令的运营商是Syniverse, C网移交以前是通过联通的北京国际局与该运营商对接进行信令转接的, 在移交后就需要割接到电信在广州和上海的ISTP进行信令转接。国内C网的漫入漫出的信令辨识SCCP层是境外运营商的GT码 (非46003) 后送广州一对HSTP后送电信一对ISTP后送Syniverse, 再由Syniverse送对应的境外运营商;同样境外辨识到电信C网GT (46003) 后经Syniverse送国内。

Syniverse系统充当了信令转接点的作用, 同时由于该系统会存储漫游用户信息, 他也有HLR和VLR的作用。Syniverse的系统也类似于信令监测系统, 会存贮C网运营商间交互的信令信息并进行漫游失败成功的统计等, 通过Syniverse提供的网页, 运营商可以查看近期漫入漫出的用户的情况, 对漫游失败的用户也可以通过查找相关记录检查原因。

3.2 CtoC国际漫游的信令转接的实现

为了实现国际漫游信令的传输, ISTP需要完成相关的信令转接数据。如前所述信令栈应用层是建立在SCCP层之上, 而SCCP是在MTP层之上。因此如果要实现信令的转接, ISTP和HSTP可以选择两种方式:

(1) HSTP进行SCCP的翻译, 目的点是Syniverse的CP处理器点码3-36-3, 同时完成MTP路由到ISTP;ISTP不进行SCCP翻译直接完成MTP路由到Syniverse的CP。

(2) HSTP进行SCCP的翻译, 目的点是两个ISTP负荷分担;ISTP再进行SCCP翻译到Syniverse的CP, 同时完成到CP的MTP路由。

由于HSTP和ISTP都采用SCCP翻译有利于实现SCCP层的负荷分担, 因此现网采用的是 (2) 的方式。

另一方面, Syniverse的CP却不能实现SCCP层的负荷分担, 也就是对于电信的GT (46003) 不能在SCCP层翻译到广州和上海的两个ISTP作为目的点分担。为了保证境外返回国内的信令的路由安全, 就需要考虑通过MTP层实现负荷分担。该做法类似于IP网络中VRRP的概念, 如图5。

在广州和上海ISTP原来的点码 (4-121-4和4-121-3) 的基础上, 再增加一个虚拟点码4-124-0, Syniverse直接将GT翻译到该点码。一旦Syniverse与其中一个电信ISTP的链路中断就可以通过另一个点疏通保证业务。该功能需要ISTP上加载相关补丁支持, 同时R_N73PARAM关系的D_NM_MULPC值需要设置为1, 具体增加虚点码和修改关系的命令如下:

MODIFY-N7PARM:OPC=H'23E0, SSF=INTAL, MOPCAPPL=MNETOPER, NEWNAME="OWNPC_SYN".

378:1="R_N73PARAM", 3="D_NM_MULPC"&0&"1", ALL.

另外就是ISTP、HSTP上需要增加境外运营商的GT码数据, 翻译点指向Syniverse的CP。在境外运营商发布增加新的GT码后, STP需要增加相应的数据以保证漫游信令的传输。

4 总结

本文讨论了CDMA国际漫游涉及的信令和具体组网情况, 并对其中的设置进行了分析探讨。希望可以为漫游故障的处理分析提供一定的指引。漫游注册等故障处理中, 可以通过逐段分析的方法排除各个网元的故障, 修正补充部分网元的GT数据等。另外也可以通过境外信令转接商提供的工具定位故障, 统计漫游业务的使用情况。

摘要：文章首先介绍了CDMA网络漫游涉及的信令, 通过简单的例子说明漫游需要交互的信令信息。随后讨论了目前电信CDMA国际漫游的组网和具体的实现情况, 以便为C网国际漫游故障处理分析等提供一些参考。

GSM网络测量报告信令采集改造 篇8

目前随着移动网络优化的重点由单纯的网络指标向关注用户感知度的转变, 测量报告 (MR) 采集在网优分析中的作用越来越重要。从目前的设备看, 大部分主设备厂家均能提供软采集方式, 采集较为方便, 但是现网爱立信GSM网络设备不支持MR的软采集, 需要采用第三方设备通过Abis接口采集, Abis接口是基站子系统的基站控制器 (BSC) 与基站收发信台 (BTS) 之间的通信接口。本文根据现网设备的实际情况在传统采集方案基础上进行了改造, 不仅使得MR的采集更加方便, 并且极大地节省了投资。

1 传统Abis接口MR采集方案

1.1 2 Mb/s链路采集方式

目前业界普遍应用通过数字配线架 (DDF) 高阻跨接, 分散采集, 集中处理的采集方式, 该方案已非常成熟, 应用于各信令监测系统中。DDF高阻跨接, 数字交叉连接设备 (DXC) 收敛后, 传输回中心机房采集处理机处理, 如图1所示。

此方案的缺点是每个基站的2 Mb/s链路都要进行高阻跨接, 工程施工量大, 线缆多, 接口多, 故障点多。

1.2 155/622 Mb/s光链路分光采集方式

主要应用于Abis接口, 一般BSC与其下带的BTS间采用SDH环状传输相连。采用分光采集155/622 Mb/s光链路方式, 通过分光器对Abis口数据进行采集, 送至前端数据处理机处理, 如图2所示。

此方案在传输成环的情况下进行MR分光采集, 优点是工程量小, 缺点是受传输资源影响较大, 如果基站传输链路进行了割接可能会影响MR的采集, 需要重新进行调整。

2 BSC Abis接口光板工作原理

目前爱立信BSC的Abis接口采用的光板名称为ET155板卡, 一对ET155板卡配置成备份模式。主备ET155分别有一对光纤直接连接到打散机框, 将155 Mb/s打散成63个2 Mb/s, 与传输设备对接向基站提供Abis链路, 如图3所示。

主备光板ET155板卡的工作原理:主备两块ET155板卡同时、独立传输相同的信号。在正常情况下, 收端只接收主用板卡发送的信号。当主用板卡或链路发生故障损坏时, 收端切换到备用板卡连接的备用信道。为了减少设备的操作风险, 避免不必要的保护倒换动作, 因此, 倒换发生后, 即使主用侧恢复后也不再倒回, 除非再次发生倒换条件。

3 MR采集改造方案

3.1 改造方案

如果采用传统的2 Mb/s链路采集方式, 常州全网Abis接口在用的2 Mb/s有上千个, 采集施工量就相当大。

如果采用155/622 Mb/s光链路分光采集方式, 首先必须将现网的Abis接口改为光口对接。根据目前常州传输资源情况, 则需要在传输侧新增传输板卡, 投资成本较高。

因此, 考虑对BSC内部Abis接口的光纤连接方式进行改造, 更换155 Mb/s输出机框中主备用光板与2 Mb/s打散机框的板卡之间的光纤, 并在中间进行分光, 经过分光器后, 一路光纤回接2 Mb/s打散框中的板卡, 另一路接入MR采集设备进行MR采集, 如图4所示。此方案的优点是采集方便, MR采集不收传输割接影响, 但是也存在一定风险:可能会产生光信号损耗、滑码、高误码率等问题。为此研究制定了可行的执行方案, 选择了覆盖郊区的BSC下的一对光板进行了测试验证。

3.2 改造操作步骤

1) 主备光纤倒换, 确认现有备用侧光纤能正常接管话务。

首先, 查看系统状态, 确认系统工作正常。

然后, 手动强制倒换备用光板到执行侧, 成为主用。

最后, 观察无告警, 拨打测试正常。

2) 对备用光板侧的光纤连接进行改造, 加入分光器。

首先, 闭掉备用侧光板及光纤。

然后, 进行光纤改造, 加入分光器。

最后, 解闭备用侧光板与光纤。观察无告警, 拨打测试正常。

经过一周时间的观察, 设备运行稳定, Abis接口未出现滑码、误码告警。MR数据能够正常采集入库。

3) 将改造后的光板倒换为执行侧, 成为主用。

若新光纤在备用侧运行没有问题, 则手工强制倒换为执行侧, 让新光纤在执行侧运行一周时间, 观察设备稳定, 无滑码、误码告警。MR数据能够正常采集入库。

4) 对另一侧光板进行同样的改造。

若新光纤在执行侧运行没有问题, 则按照以上相同的步骤, 对另一条光板的光纤进行改造。经过一周时间的观察, 设备稳定, 无滑码、误码告警。两份MR数据同时采集入库, 保留其中一份数据。

3.3 改造前后观测情况

改造后BSC设备及基站正常运行, 通过对改造前后误码滑码情况的跟踪对比, 改造后并未造成误码滑码上升。

同时, 在测试中, 使用手工强制倒换命令进行光板主备用切换时, 未出现基站告警, 基站业务正常, 各项指标正常, 说明整个改造不影响现网业务, 有很高的安全性。

4 结论

根据以上改造说明及验证情况, 我们看到, 采用改造后的MR采集方式, 并未对BSC的误码滑码产生影响, 并且MR数据能够正常采集入库。

由于爱立信BSC的Abis接口采用光板热备工作方式, 根据前面的试验我们确认了备用光板上也能采集MR数据, 因此可以只在BSC备用光板上进行分光采集, 主用光板保持原有连接方式。这样, 不仅实施过程中工作量减半, 整个改造过程也更加安全, 对网络运行没有任何影响。