CN101394583A - 一种寻呼消息组包的方法和装置 - Google Patents
一种寻呼消息组包的方法和装置 Download PDFInfo
- Publication number
- CN101394583A CN101394583A CNA2007101498480A CN200710149848A CN101394583A CN 101394583 A CN101394583 A CN 101394583A CN A2007101498480 A CNA2007101498480 A CN A2007101498480A CN 200710149848 A CN200710149848 A CN 200710149848A CN 101394583 A CN101394583 A CN 101394583A
- Authority
- CN
- China
- Prior art keywords
- beep
- page message
- bsc
- message
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种寻呼消息组包的方法,包括以下步骤:基站控制器BSC接收移动交换中心MSC发送的寻呼消息;所述BSC对所述寻呼消息进行组包处理。通过本发明实施例,BSC对接收自MSC的寻呼消息按照小区或按照站点进行组包处理,将经组包处理后的寻呼消息发送给基站,减少了寻呼链路上寻呼消息的发送数量和寻呼消息的总长度,有效降低了下发寻呼消息的下行链路的负荷。
Description
技术领域
本发明涉及通信技术领域,特别涉及一种寻呼消息组包的方法和装置。
背景技术
随着移动通信技术的发展,GSM(Global System for MobileCommunications,全球移动通讯系统)网络系统已成为当今世界上使用最广泛的无线通讯系统,并且这个系统的用户数目仍在不断增长。现有的GSM系统的网元部署如图1所示。图1中,BSC(Base Station Controller,基站控制器)和BTS(Base Transceiver Station,基站收发信台)之间的接口称为Abis接口,接口采用LAPD(Link Access Protocol on the D-Channel,D信道上的链路访问协议)通讯协议。Abis接口协议栈如图2所示,其中,BTSM(Base TransceiverStation Management)为基站收发信台管理;RR(Radio Resource)为无线资源管理;LAPD为D信道上的链路接入协议;LAPDm(Link Access Protocol onthe Dm Channel)为Dm信道上的链路接入协议;BSSAP(Base Station subSystemApplication Part)为基站子系统应用部分;SCCP(Signalling Connection ControlPart)为信令连接控制部分;MTP(Message Transfer Part)为消息传输部分。
一个BTS称为一个基站,每个基站站点中可以配置一到多个小区(Cell),每个小区中可以配置有一到多个载频(TRX)。每个载频都会通过一条LAPD链路与BSC进行信令业务消息的发送和接收处理,每一个基站都会通过一条LAPD链路与BSC进行整个基站的操作维护信令的发送和接收处理。通常,称用于操作维护通讯的LAPD链路为OML(Operation and Maintenance Link,操作和维护链路)链路,把用于信令通讯的LAPD链路称为RSL(RadioSignalling Link,无线信令链路)链路。并且一个小区中配置了主BCCH(Broadcasting Control Channel,广播控制信道)信道的载频称为这个小区的主B载频,这个主B载频与BSC之间进行业务交互使用的RSL链路就称为当前小区的主B RSL链路。站点、小区、载频以及RSL链路和OML链路的配置关系可以参考图3。其中,灰色标识的载频为主B载频。BCF(Base Control Function,公共控制功能)是在BTS中处理公共控制功能,如BTS初始化、软件下载、信道配置、操作维护等的功能实体。
在GSM系统中,为了减少资源浪费,引入了LA(Location Area,位置区)的概念。一个位置区包括一个小区组群,一个MS在某一时刻属于一个位置区。当一个本网或者他网用户(主叫用户)呼叫到当前的MSC(Mobile SwitchingCenter,移动交换中心)中的某个移动用户(被叫用户)的时候,MSC根据这个被叫用户注册的位置区,向这一位置区内所有小区发送寻呼消息。在该寻呼消息中包含有能够识别用户身份的信息IMSI(International Mobile SubscriberIdentity,国际移动用户标识)或TMSI(Temporary Mobile Subscriber Identity,临时移动用户标识)。MSC根据位置区确定要进行寻呼的BTS,并将寻呼指令发送给BTS,BTS在规定的PCH(Paging Channel,寻呼信道)上发送该被叫MS(Mobile Station,移动台)的寻呼消息,通知被叫用户接入网络。
当前,BSC发送给基站的寻呼消息是以小区为单位发送的,即如果当前位置区下含有多个小区,那么对于每一个小区,BSC都会通过这个小区的主BRSL发送一条寻呼消息到基站,寻呼消息的分发过程如图4所示。图4中MSC连续在当前位置区中发送了n条寻呼消息以寻呼n个被叫用户,则BSC根据位置区中包含的小区,向基站发送寻呼消息。每当MSC向BSC发送一条寻呼消息(按照位置区寻呼),BSC下当前这个位置区(MSC在发给BSC的寻呼消息中指定)中有多少个小区,BSC就要向基站发送多少条寻呼消息,寻呼同一个被叫用户。这些寻呼消息都是通过目标小区的主B RSL链路发送的。当MSC顺序寻呼多个用户的时候,在目标小区的主B RSL链路上,这些寻呼消息将被BSC顺次发送给基站。
现有这种寻呼技术的一个很大的缺点就是,在当前的寻呼信令流程下,寻呼消息在BSC发送到各个小区,使Abis接口传送寻呼消息的链路的下行负荷很重,严重影响了BSC系统的稳定性和业务可靠性。尤其在话务量高峰时段或者话务量瞬时升高的网络状况下,很可能会导致BSC中下发寻呼消息的下行链路拥塞,大量的寻呼消息被丢弃,反过来可能引起MSC对同一个用户重发大量的寻呼消息或者发起全网寻呼,进而可能引起当前位置区下所有小区的Abis接口的下行链路的进一步拥塞,导致BSC话务容量下降,被叫业务甚至可能完全不能进行。
因此,现有技术的缺点是:Abis接口传送寻呼消息的下行链路负荷重,容易导致Abis接口的下行链路拥塞,BSC话务容量下降,被叫业务进行不顺畅。
发明内容
本发明实施例要解决的问题是提供一种寻呼消息组包的方法和装置,以实现减少寻呼消息在Abis接口下行链路上的数量和占用下行链路的负荷比重,避免由于寻呼消息造成的Abis接口下行链路拥塞。
为达到上述目的,本发明实施例一方面提供一种寻呼消息组包的方法,包括以下步骤:基站控制器BSC接收移动交换中心MSC发送的寻呼消息;所述BSC对所述寻呼消息进行组包处理。
另一方面,本发明实施例还提供了一种基站控制器BSC,包括:消息接收模块,用于接收移动交换中心MSC发送的寻呼消息;组包处理模块,与所述消息接收模块连接,用于对所述消息接收模块接收的寻呼消息进行组包处理。
再一方面,本发明实施例还提供了一种基站子系统BSS,包括:BSC,用于接收移动交换中心MSC发送的寻呼消息,对所述寻呼消息进行组包处理,并将所述组包处理后的寻呼消息发送给基站;基站,用于接收所述BSC发送的经组包处理后的寻呼消息,并将所述寻呼消息向所述基站内的小区下发。
与现有技术相比,本发明实施例具有以下优点:通过本发明实施例,对下发给基站的寻呼消息进行组包,从而减少了寻呼消息在Abis接口下行信令链路上的数量和占用下行链路的负荷,较少甚至避免了因为寻呼消息造成的Abis接口下行信令链路拥塞。
附图说明
图1为现有技术GSM系统的网元部署;
图2为现有技术Abis接口协议栈示意图;
图3为现有技术站点、小区、载频以及RSL链路和OML链路的配置关系示意图;
图4为现有技术寻呼消息的分发过程示意图;
图5为本发明实施例基站控制器BSC的结构图;
图6为本发明实施例按照小区进行组包处理的示意图;
图7为本发明实施例按照站点进行组包处理的示意图;
图8为本发明实施例寻呼消息组包的方法的流程图;
图9为本发明寻呼消息组包的方法实施例一的流程图;
图10为本发明实施例的系统配置示意图;
图11为本发明实施例一的寻呼消息组包处理条件和寻呼消息组包的关系示意图;
图12为本发明实施例一按照小区进行寻呼消息组包处理的示意图;
图13为本发明寻呼消息组包的方法实施例二的流程图。
具体实施方式
本发明实施例提供了一种寻呼消息组包的方法,通过本发明实施例,在BSC和基站之间的Abis接口上,按照小区或按照站点、或者按照先小区后站点等方式对下发给基站的寻呼消息进行组包,从而减少了寻呼消息在Abis接口下行信令链路上的数量和占用下行链路的负荷,较少甚至避免了由于寻呼消息造成的Abis接口下行信令链路拥塞。
如图5所示,为本发明实施例基站控制器BSC的结构图,包括消息接收模块1、组包处理模块2和消息发送模块3。消息接收模块1用于接收移动交换中心MSC发送的寻呼消息。组包处理模块2,与消息接收模块1连接,用于根据预先设置的组包结构对消息接收模块1接收的寻呼消息进行组包处理。本发明实施例提供了三种组包处理的方式进行说明,既可以按照小区对接收的寻呼消息进行组包处理,也可以按照站点对接收的寻呼消息进行组包处理,还可以按照先小区后站点的方式对接收的寻呼消息进行组包处理。在按照小区对接收的寻呼消息进行组包处理之前,组包处理模块2判断该寻呼消息是否满足组包处理条件,在判断该寻呼消息满足组包处理条件之后,组包处理模块2对该寻呼消息按照小区进行组包处理。该组包处理条件可以有多种设置方式,例如:寻呼消息的个数是否已达到最大缓存的寻呼消息的个数,或该寻呼消息的缓冲时间是否已达到所述寻呼消息在BSC被缓冲的最长时间,只要寻呼消息满足组包处理条件中的任意一个,组包处理模块2就可以对寻呼消息按照小区进行组包。在组包处理模块2按照站点对接收的寻呼消息进行组包处理之后,对于MSC对同一个小区内的多个用户或者同一位置区LA的某一个用户的寻呼消息,消息发送模块3只需向基站发送一条寻呼消息,然后由基站将该寻呼消息发送给基站内的各个小区。消息发送模块3,与组包处理模块2连接,用于将组包处理模块2处理后的寻呼消息发送给基站。
优选地,BSC还包括负荷判断模块4,用于在组包处理模块2对寻呼消息进行组包处理之前,判断系统负荷是否超过预设的负荷门限值。如果负荷判断模块4判断当前系统的负荷已超过预设的负荷门限值,则组包处理模块2对所述寻呼消息进行组包处理;如果负荷判断模块4判断当前系统的负荷还未超过预设的负荷门限值,则仍按现有寻呼消息的处理方式处理寻呼消息。该系统负荷可以包括:BSC或BTS或BSS(Base Station subSystem,基站子系统)的系统负荷,或下行链路负荷等。
如图5所示,其中,组包处理模块2包括条件判断子模块21、小区组包子模块22和站点组包子模块23。
条件判断子模块21用于判断寻呼消息是否满足寻呼消息组包条件,该组包处理条件可以有多种设置方式,例如:寻呼消息的个数是否已达到最大缓存的寻呼消息的个数,或该寻呼消息的缓冲时间是否已达到所述寻呼消息在BSC被缓冲的最长时间,只要寻呼消息满足组包处理条件中的任意一个,条件判断子模块21就会判断寻呼消息满足寻呼消息组包条件。小区组包子模块22用于在条件判断子模块21判断寻呼消息满足寻呼消息组包条件之后,将指定时间内的同一个小区的多个用户的寻呼消息,在Abis接口组包成一个自定义的扩展寻呼消息,一次性发给基站进行处理。如图6所示,其中,图6(a)为寻呼消息组包前的寻呼下发链路示意图,图6(b)为寻呼消息组包后的寻呼下发链路示意图。由图6可以看出,将寻呼消息按照小区组包后,在下发寻呼消息的链路上,不但寻呼消息的个数相对以前减少了,而且寻呼消息组包后寻呼消息在链路上的净负荷,包括寻呼消息内容和底层协议单元内容,比寻呼打包前在链路上发送的所有寻呼消息的净负荷之和可以少很多。
如图5所示,站点组包子模块23,用于将消息接收模块1接收的寻呼消息按照站点进行组包处理。在进行寻呼消息组包前,对于一个站点下的多个小区,BSC每收到MSC的一个寻呼消息,都会向这个站点的所有小区发送一条寻呼消息。在站点组包子模块23对寻呼消息按照站点进行寻呼消息组包之后,消息发送模块3将同一个站点下的多个小区的寻呼消息,组装成一条寻呼消息发送给基站,由基站将该寻呼消息按照各个小区进行分发处理,如图7所示。其中,图7(a)为寻呼消息组包前CELL1的寻呼下发链路,图7(b)为寻呼消息组包前CELL2的寻呼下发链路,图7(c)为寻呼消息组包前CELLn的寻呼下发链路,图7(d)为寻呼消息组包后基站的寻呼下发链路,图7中的MS_A表示被寻呼的被叫用户。CELL1~CELLn为同一个基站下的n个小区。
由图7可以看出,在将寻呼消息按照站点组包之前,MSC对同一个用户例如:MS_A的寻呼消息,在CELL1~CELLn的寻呼下发链路上各发送一条寻呼消息给基站,共发送n条消息给基站。在站点组包子模块23对寻呼消息按照站点进行寻呼消息组包之后,对于MSC针对同一个用户,例如:MS_A的寻呼消息,BSC只需要向基站发送一条寻呼消息,然后由基站将该寻呼消息通过空口发送给基站下的各个小区。在Abis接口上发送组包后的寻呼消息的信令链路,可以是CELL1~CELLn这n条链路中的一条或者多条,也可以是这n条链路轮流使用,或者负荷分担使用,或者使用OML链路发送,或者使用自定义的链路发送等。
优选地,组包处理模块2还包括结构保存子模块24,用于保存预设的组包结构,该组包结构可用于按照小区进行组包处理的情形。本发明实施例中,Abis接口自定义的组包结构如表1所示:
表1
信元 | 索引 | 存在状态 | 格式 | 长度 | 自定义值 |
Message discriminator | 3GPP 480589.1 | M | V | 1 | 0xAA |
Message type | 3GPP 480589.2 | M | V | 1 | 0x18 |
Paging Package Number | 自定义 | M | V | 1 | |
Paging Package | 自定义 | M | V | 16~240 |
其中Paging Package Number的定义如表2所示:
表2
Paging Packang的定义如表3所示:
表3
Paging Package Info的定义如表4所示:
表4
Channel And eMLPP | 自定义 | M | V | 1 |
MS Identity | 3GPP 480589.3.12 | M | TLV | 2-10 |
Paging Group Paras | 自定义 | M | V |
Channel And eMLPP的定义如表5所示:
表5
Paging Group Paras的定义如表6所示:
表6
Paging Group Paras是变长结构,根据当前寻呼是电路域寻呼还是分组域寻呼,采用不同的结构定义,例如:当Paging Type=0时的结构如表7所示,可以看出其结构长度为1个字节,
表7
当Paging Type=1时的结构如表8所示,可以看出其结构长度为5个字节,
表8
表1~表8中出现的信元参数的含义如表9所示,表9中引用的章节,是指3GPP48.058 V4.0.0协议中对应的章节,例如:表9中的“9.3.14”是指3GPP 48.058V4.0.0协议中的9.3.14小节。
表9
参数名称 | 取值范围 | 参数说明 |
Paging Msg Number | 1~15 | 寻呼打包消息中“Paging Package Info”结构的数目。 |
Paging Package Info | 自定义结构 | 寻呼打包消息中单个寻呼消息的结构定义 |
Paging Group Paras | 自定义结构 | 根据“寻呼包”中当前寻呼为CS寻呼和PS寻呼的不同,在后续字节携带对应的寻呼组参数。 |
Paging Group | 0~80 | 寻呼组,9.3.14中的Paging Group的值(无IE标识) |
Channel Number | 0~7 | 9.3.1中“Downlink CCCH(PCH+AGCH)”部分 |
Channel Needed | 0~4(无效时填0) | 9.3.40中“Channel”部分。“Channel Needed”为可选,无效的时候填写为0。 |
eMLPP Priority | 0~7(无效时填0) | 9.3.49中“call priority”部分。“eMLPP Priority”为可选,无效的时候填写为0。 |
如图8所示,为本发明实施例寻呼消息组包的方法的流程图,具体包括以下步骤:
步骤S801,基站控制器BSC接收移动交换中心MSC发送的寻呼消息。
步骤S802,BSC对寻呼消息进行组包处理。在接收到MSC发送的寻呼消息之后,BSC对寻呼消息进行组包处理,本发明实施例提供了三种组包处理的方式,既可以按照小区对接收的寻呼消息进行组包处理,也可以按照站点对接收的寻呼消息进行组包处理,还可以按照先小区后站点的方式对接收的寻呼消息进行组包处理。
在按照小区对接收的寻呼消息进行组包处理之前,BSC先判断该寻呼消息是否满足组包处理条件,在判断该寻呼消息满足组包处理条件之后,BSC对该寻呼消息按照小区进行组包处理。该组包处理条件可以有多种设置方式,例如:寻呼消息的个数是否已达到最大缓存的寻呼消息的个数,或该寻呼消息的缓冲时间是否已达到所述寻呼消息在BSC被缓冲的最长时间,只要寻呼消息满足组包处理条件中的任意一个,BSC就会对寻呼消息按照小区进行组包。按照小区对接收的寻呼消息进行组包处理,即将指定时间内的同一个小区的多个用户的寻呼消息,在Abis接口组包成一个自定义的扩展寻呼消息,一次性发给BTS进行处理,如图6所示。其中,图6(a)为寻呼消息组包前的寻呼下发链路示意图,图6(b)为寻呼消息组包后的寻呼下发链路示意图,由图6可以看出,将寻呼消息按照小区组包后,在下发寻呼消息的链路上,不但寻呼消息的个数相对以前减少了,而且寻呼消息组包后寻呼消息在链路上的净负荷,包括寻呼消息内容和底层协议单元内容,比寻呼打包前在链路上发送的所有寻呼消息的净负荷之和要少很多。优选地,BSC保存预设的组包结构,该组包结构如表1~表9所示。在按照小区对寻呼消息进行组包处理时,BSC根据预存的该组包结构对寻呼消息进行组包。
在BSC对寻呼消息按照站点进行寻呼消息组包前,对于一个站点下的多个小区,BSC每收到MSC的一个寻呼消息,都会向这个站点的所有小区发送一条寻呼消息。在进行寻呼消息组包之后,BSC将同一个站点下的多个小区的寻呼消息,组装成一条寻呼消息发送给基站,由基站将该寻呼消息按照各个小区进行分发处理,如图7所示。其中,图7(a)为寻呼消息组包前CELL1的寻呼下发链路,图7(b)为寻呼消息组包前CELL2的寻呼下发链路,图7(c)为寻呼消息组包前CELLn的寻呼下发链路,图7(d)为寻呼消息组包后基站的寻呼下发链路,图7中的MS_A表示被寻呼的被叫用户。CELL1~CELL n为同一个基站下的n个小区。由图7可以看出,在将寻呼消息按照站点组包之前,MSC对同一个用户例如:MS_A的寻呼消息,在CELL1~CELLn的寻呼下发链路上各发送一条寻呼消息给基站,共发送n条消息给基站。在将寻呼消息按照站点组包之后,对于MSC对同一个用户,例如:MS_A的寻呼消息,BSC只需要向基站发送一条寻呼消息,然后由基站将该寻呼消息通过空口发送给基站下的各个小区。在Abis接口上发送组包后的寻呼消息的信令链路,可以是CELL1~CELLn这n条链路中的一条或者多条,也可以是这n条链路轮流使用,或者负荷分担使用,或者使用OML链路发送,或者使用自定义的链路发送等。
上述两种组包处理的方式既可以单独使用,也可以联合使用,例如:可以按照先小区后站点的方式对接收的寻呼消息进行组包处理,即BSC先按照小区组包的方式对接收的寻呼消息进行组包处理,再按照站点组包的方式对上述按照小区组包后的寻呼消息进行组包处理。
优选地,在BSC对寻呼消息进行组包处理之前,BSC先判断系统负荷是否超过预设的负荷门限值。如果当前系统的负荷已超过预设的负荷门限值,则BSC对所述寻呼消息进行组包处理;如果当前系统的负荷还未超过预设的负荷门限值,则仍按现有寻呼消息的处理方式处理寻呼消息。该系统负荷包括:BSC或BTS或BSS(Base Station subSystem,基站子系统)的系统负荷,或下行链路负荷等。
另外,以下技术的应用,也会导致同一个小区下配置的载频数目增加,或者导致同一个小区下话务量增加,进而被叫用户增加,使单位时间内同一个小区的寻呼消息增加,加大了这个小区下发寻呼消息的下行链路的负荷:
扩展BCCH的应用:使用扩展BCCH后,空口寻呼容量加大,寻呼在空口拥塞的可能性降低,导致运营商进一步加大小区话务容量。
Abis接口传输进行优化提升或者使用IP(Internet Protocol,因特网协议)技术:这种情况下增大了一条物理传输情况下BTS支持载频的数目,甚至可以达到在同一个小区中配置24个载频,导致小区话务容量进一步加大,直接或间接导致寻呼消息负荷加重。
在GSM技术不断发展情况下,大站型的基站不断应用,相应的每个小区的话务容量也随之增大,导致当前小区对用户的寻呼数量加大,进一步加大了寻呼消息在下行链路上的负荷比重。
而本发明实施例提供的一种寻呼消息组包的方法,使BSC根据预设的寻呼结构对下发给基站的寻呼消息按照小区或按照站点或按照先小区后站点的方式进行组包,减少了寻呼消息在Abis接口下行链路上的数量和占用下行链路负荷的比重,较少甚至避免了由于寻呼消息造成的Abis接口下行链路拥塞,达到了很好的技术效果。
如图9所示,为本发明寻呼消息组包的方法实施例一的流程图。BSC对寻呼消息按照小区进行组包处理的实施例的一个假定的环境配置为:一个GSM系统,含有一个MSC,一个BSC和一个基站BTS1。基站下配置有三个小区(CELL1,CELL2,CELL3),每一个小区下配置有三个载频,其示意图如图10所示。这一假定的环境配置仅为说明相关技术问题的需要,并非为限制本发明技术方案的范围。对于现实应用场景中,多MSC、多BSC、多BTS、多CELL、多载频的环境配置,可以类推,不再赘述。
本实施例预先设定的两个组包处理条件为:
(1)寻呼消息的个数是否已达到最大缓存的寻呼消息的个数,设最大缓存的寻呼消息个数为N个;
(2)寻呼消息的缓冲时间是否已达到所述寻呼消息在BSC被缓冲的最长时间,设最长时间为T毫秒。
在当前小区有寻呼消息并且在BSC缓存的情况下,只要满足上述条件中的任意一个,BSC将组装一条寻呼消息发送给基站。该寻呼消息组包处理条件和寻呼消息组包的关系如图11所示。
在以下具体实施方式的描述中,为叙述方便,假定配置当前系统中按照小区进行寻呼消息组包的N=8,T=100毫秒,具体包括以下步骤:
步骤S901,MSC寻呼被叫用户,向BSC发送寻呼消息。MSC寻呼被叫用户,在一定的时间内,向当前位置区的BSC陆续发送9条寻呼消息,分别寻呼9个用户,MS1,MS2,...,MS9。
步骤S902,BSC接收MSC发送的寻呼消息。
步骤S903,BSC开辟寻呼消息缓存区,缓存寻呼消息。BSC在接收到MSC的寻呼消息之后,对于每一个需要下发寻呼消息的小区,分别开辟一个寻呼消息缓存区,将要发往这些小区的寻呼消息缓存。
步骤S904,BSC判断是否满足寻呼消息组包条件。在BSC对发往小区的寻呼消息按照小区进行寻呼消息组包之前,BSC会判断寻呼消息是否满足寻呼组包条件,在本实施例中,该寻呼组包条件为寻呼消息的个数是否已达到最大缓存的寻呼消息的个数或寻呼消息的缓冲时间是否已达到所述寻呼消息在BSC被缓冲的最长时间。只要满足上述两个条件中的任意一个,BSC就会对寻呼消息按照小区进行寻呼消息组包处理。如果寻呼消息还没有满足上述寻呼消息组包条件,则返回步骤S902,BSC继续接收MSC发送的寻呼消息。参照图12,图12为BSC中小区CELL1的寻呼缓冲区示意图,以CELL1为例对BSC的判断过程描述如下:
(1)在配置的T毫秒内,小区CELL1缓存的寻呼消息个数达到了配置的N值。如图12(a)所示,小区CELL1在从系统10MS到90MS的时间段80MS内,小于配置的T值(100MS),连续收到了8个寻呼消息,达到了系统配置的最大缓存的寻呼消息个数N(N这里配置为8),则BSC在CELL1上组装了一条自定义的寻呼消息,其中含有对8个用户的寻呼消息。
(2)在配置的T毫秒内,小区CELL1缓存的寻呼消息个数没有达到配置的N值,如图12(b)所示,小区CELL1在从系统10MS到110MS的使间段100MS,达到了系统配置的T值(100MS),只连续收到了5个寻呼消息,但由于已经达到了T值配置的时间限制,所以BSC在CELL1上组装了一条自定义的寻呼消息,其中含有对5个用户的寻呼消息。
步骤S905,BSC对寻呼消息按照小区进行寻呼消息组包处理。在判断接收自MSC的寻呼消息满足寻呼消息组包条件之后,BSC对寻呼消息按照小区进行寻呼消息组包处理。优选地,BSC保存预设的组包结构,该组包结构如表1~表9所示。在按照小区对寻呼消息进行组包处理时,BSC根据预存的该组包结构对寻呼消息进行组包。优选地,在BSC对寻呼消息按照小区进行组包处理之前,BSC先判断系统负荷是否超过预设的负荷门限值。如果当前系统的负荷已超过预设的负荷门限值,则BSC对所述寻呼消息按照小区进行组包处理;如果当前系统的负荷还未超过预设的负荷门限值,则BSC不对寻呼消息按照小区进行组包处理,仍按现有寻呼消息的处理方式处理寻呼消息。该系统负荷包括:BSC或BTS或BSS(Base Station subSystem,基站子系统)的系统负荷,或下行链路负荷等。
步骤S906,BSC将寻呼消息组包后的寻呼消息发送给基站。如图12(a)所示,BSC将含有8个用户的寻呼消息,通过CELL1的主B RSL链路,发送给基站;如图12(b)所示,BSC将含有5个用户的寻呼消息,通过CELL1的主B RSL链路,发送给基站。
按照小区寻呼消息组包的链路优化计算如下所示:
参数配置:小区CELL1接收到的寻呼消息为120条/秒;寻呼消息组包参数为N=8个,T=100毫秒;
在原来消息模式下,1秒中发送的消息数目为:120条;
信令链路流量:120条消息×(LAPD/HDLC(High-Level Data LinkControl,高级数据链路控制))协议单元10个字节+20个字节的寻呼消息长度)=3600字节。
在按照小区组包优化方案下,1秒中发送的消息数目为:120/8=15条;
信令链路流量:15条×(LAPD/HDLC协议单元10个字节+Abis头3字节+12字节的包内寻呼消息长度×8个寻呼/包)=1635字节。
对比表:
说明:LAPD/HDLC协议单元10个字节:是指在Abis接口LAPD链路上传送寻呼消息的时候,LAPD和HDLC协议承载传输寻呼时必须的协议头部和协议尾部字节数目。20个字节的寻呼消息长度:是指3GPP 48058协议中定义的一个Abis接口寻呼消息的最大长度。
上述寻呼消息组包的方法,对于MSC发送的寻呼消息,BSC根据预设的组包处理条件按照小区进行组包处理,将组包处理后的寻呼消息发送给基站,减少了Abis下行链路上寻呼消息的数量和消息的总长度,从而降低了下发寻呼消息的Abis接口信令链路的下行负荷。
如图13所示,为本发明寻呼消息组包的方法实施例二的流程图,BSC对寻呼消息按照站点进行组包处理的实施例一个假定的环境配置为:一个GSM系统,含有一个MSC,一个BSC和一个基站BTS1。基站下配置有三个小区(CELL1,CELL2,CELL3),每一个小区下配置有三个载频,其示意图如图10所示,这一假定的环境配置仅为说明相关技术问题的需要,并非为限制本发明技术方案的范围。对于现实应用场景中,多MSC、多BSC、多BTS、多CELL、多载频的环境配置,可以类推,不再赘述。
具体包括以下步骤:
步骤S1301,MSC寻呼被叫用户,向BSC发送寻呼消息。MSC寻呼被叫用户,在一定的时间内,向当前位置区的BSC陆续发送5条寻呼消息,分别寻呼5个用户,MS1,MS2,...,MS5。
步骤S1302,BSC和基站对接收到的寻呼消息依次进行处理。在接收到MSC的寻呼消息之后,BSC和BTS对于接收到的寻呼5个用户MS1,MS2,...,MS5的寻呼消息依次进行处理:
(1)BSC接收到对MS1的寻呼消息之后,通过当前CELL1的TRX0上的RSL(主B RSL)将该寻呼消息发送给基站,不再向其余小区发送寻呼消息。基站收到对MS1的寻呼消息后,将寻呼消息通过空口向本站内的其他小区转发;
(2)BSC接收到对MS2的寻呼消息之后,通过当前CELL2的TRX3上的RSL(主B RSL)将该寻呼消息发送给基站,不再向其余小区发送寻呼消息。基站收到对MS2的寻呼消息后,将寻呼消息通过空口向本站内的其他小区转发;
(3)BSC接收到对MS3的寻呼消息之后,通过当前CELL3的TRX6上的RSL(主B RSL)将该寻呼消息发送给基站,不再向其余小区发送寻呼消息。基站收到对MS3的寻呼消息后,将寻呼消息通过空口向本站内的其他小区转发;
(4)BSC接收到对MS4的寻呼消息之后,通过当前CELL1的TRX0上的RSL(主B RSL)将该寻呼消息发送给基站,不再向其余小区发送寻呼消息。基站收到对MS4的寻呼消息后,将寻呼消息通过空口向本站内的其他小区转发;
(5)BSC接收到对MS5的寻呼消息之后,通过当前CELL2的TRX3上的RSL(主B RSL)将该寻呼消息发送给基站,不再向其余小区发送寻呼消息。基站收到对MS5的寻呼消息后,将寻呼消息通过空口向本站内的其他小区转发。
BSC向基站发送组包后的寻呼消息的信令链路,可以是CELL1~CELL3这3条链路中的一条或者多条,也可以是这3条链路轮流使用,或者负荷分担使用,或者使用OML链路发送,或者使用自定义的链路发送等。在步骤S1302中,BSC轮流使用当前基站下的小区的主B RSL链路进行寻呼消息的发送。
按照站点寻呼消息组包的链路优化计算如下所示:
假设当前一个站点有3个小区,并且寻呼消息长度为L字节,则:寻呼消息组包前,Abis接口链路的寻呼消息长度为:
L字节/寻呼×3寻呼/站点×1个站点=3×L字节寻呼消息组包后,Abis接口链路的寻呼消息长度为:
L字节/寻呼×1寻呼/站点×1个站点=L字节可以看出,Abis接口寻呼消息负荷变为原来的33%。
相较现有技术中BSC需要向每个小区发送一条寻呼消息,上述寻呼消息组包的方法,BSC将接收自MSC的寻呼消息按照站点进行组包处理,使得对于MSC针对同一个用户的寻呼消息,BSC只需向基站发送一条寻呼消息,从而减少了寻呼链路上寻呼消息的发送数量,降低了Abis接口下行信令链路的负荷。
本发明寻呼消息组包的方法实施例一和实施例二提供的两种组包处理的方式既可以单独使用,也可以联合使用,例如:可以按照先小区后站点的方式对接收的寻呼消息进行组包处理,即BSC先按照小区组包的方式对接收的寻呼消息进行组包处理,再按照站点组包的方式对上述按照小区组包后的寻呼消息进行组包处理。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
以上公开的仅为本发明的几个具体实施例,但是,本发明并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明的保护范围。
Claims (18)
1、一种寻呼消息组包的方法,其特征在于,包括以下步骤:
基站控制器BSC接收移动交换中心MSC发送的寻呼消息;
所述BSC对所述寻呼消息进行组包处理。
2、如权利要求1所述寻呼消息组包的方法,其特征在于,还包括:所述BSC将所述组包处理后的寻呼消息发送给基站。
3、如权利要求1所述寻呼消息组包的方法,其特征在于,在所述BSC对所述寻呼消息进行组包处理之前,还包括以下步骤:
所述BSC判断系统负荷是否超过预设的负荷门限值;
如果超过所述负荷门限值,则所述BSC对所述寻呼消息进行组包处理。
4、如权利要求1或2所述寻呼消息组包的方法,其特征在于,所述BSC对所述寻呼消息进行组包处理具体包括:所述BSC按照小区和/或按照站点对所述寻呼消息进行组包处理。
5、如权利要求4所述寻呼消息组包的方法,其特征在于,还包括以下步骤:如果所述寻呼消息满足预设的寻呼组包条件,则所述BSC按照小区对所述寻呼消息进行组包处理。
6、如权利要求5所述寻呼消息组包的方法,其特征在于,所述BSC判断所述寻呼消息是否满足预设的寻呼组包条件具体包括以下步骤:
判断所述寻呼消息的个数是否已达到最大缓存的寻呼消息的个数;
和/或判断所述寻呼消息的缓冲时间是否已达到所述寻呼消息在BSC被缓冲的最长时间。
7、如权利要求2或4所述寻呼消息组包的方法,其特征在于,在所述BSC将所述经组包处理后的寻呼消息发送给基站之后,还包括以下步骤:所述基站将所述组包处理后的寻呼消息发送给所述基站内的小区。
8、如权利要求1或3所述寻呼消息组包的方法,其特征在于,所述BSC对所述寻呼消息进行组包处理具体包括以下步骤:
所述BSC按照小区对所述寻呼消息进行组包;
所述BSC按照站点对所述按照小区组包后的寻呼消息进行组包。
9、一种基站控制器BSC,其特征在于,包括:
消息接收模块,用于接收移动交换中心MSC发送的寻呼消息;
组包处理模块,与所述消息接收模块连接,用于对所述消息接收模块接收的寻呼消息进行组包处理。
10、如权利要求9所述BSC,其特征在于,还包括消息发送模块,与所述组包处理模块连接,用于将所述组包处理模块处理后的寻呼消息发送给基站。
11、如权利要求9所述BSC,其特征在于,还包括负荷判断模块,用于判断系统负荷是否超过预设的负荷门限值。
12、如权利要求9所述BSC,其特征在于,所述组包处理模块包括:
小区组包子模块,用于按照小区对所述消息接收模块接收的寻呼消息进行组包处理;
站点组包子模块,用于按照站点对所述消息接收模块接收的寻呼消息进行组包处理。
13、如权利要求9所述BSC,其特征在于,所述组包处理模块还包括:条件判断子模块,与所述小区组包子模块连接,用于在所述小区组包子模块对所述寻呼消息按照小区进行组包处理之前,判断所述寻呼消息是否满足预设的寻呼组包条件。
14、一种基站子系统BSS,其特征在于,包括:
如权利要求9所述的BSC,用于接收移动交换中心MSC发送的寻呼消息,对所述寻呼消息进行组包处理,并将所述组包处理后的寻呼消息发送给基站;
基站,用于接收所述BSC发送的经组包处理后的寻呼消息,并将所述寻呼消息向所述基站内的小区下发。
15、如权利要求14所述BSS,其特征在于,所述BSC包括:
消息接收模块,用于接收移动交换中心MSC发送的寻呼消息;
组包处理模块,与所述消息接收模块连接,用于对所述消息接收模块接收的寻呼消息进行组包处理。
16、如权利要求15所述BSS,其特征在于,所述BSC还包括消息发送模块,与所述组包处理模块连接,用于将所述组包处理模块处理后的寻呼消息发送给基站。
17、如权利要求15所述BSS,其特征在于,所述组包处理模块包括:
小区组包子模块,用于按照小区对所述消息接收模块接收的寻呼消息进行组包处理;
站点组包子模块,用于按照站点对所述消息接收模块接收的寻呼消息进行组包处理。
18、如权利要求15所述BSS,其特征在于,所述组包处理模块还包括:条件判断子模块,与所述小区组包子模块连接,用于在所述小区组包子模块对所述寻呼消息按照小区进行组包处理之前,判断所述寻呼消息是否满足预设的寻呼组包条件。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2007101498480A CN101394583A (zh) | 2007-09-17 | 2007-09-17 | 一种寻呼消息组包的方法和装置 |
EP08800870.1A EP2192796B1 (en) | 2007-09-17 | 2008-09-16 | Method, device and system of encapsulating paging messages into a packet |
PCT/CN2008/072374 WO2009036696A1 (fr) | 2007-09-17 | 2008-09-16 | Procédé, dispositif et système d'encapsulation de messages de recherche de personnes dans un paquet |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2007101498480A CN101394583A (zh) | 2007-09-17 | 2007-09-17 | 一种寻呼消息组包的方法和装置 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210254962.0A Division CN102791001B (zh) | 2007-09-17 | 2007-09-17 | 一种寻呼消息组包的方法和装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101394583A true CN101394583A (zh) | 2009-03-25 |
Family
ID=40467525
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2007101498480A Pending CN101394583A (zh) | 2007-09-17 | 2007-09-17 | 一种寻呼消息组包的方法和装置 |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP2192796B1 (zh) |
CN (1) | CN101394583A (zh) |
WO (1) | WO2009036696A1 (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101635897B (zh) * | 2009-08-07 | 2012-11-28 | 中兴通讯股份有限公司 | 用于全球移动通讯系统的联合寻呼方法和装置 |
CN106162873A (zh) * | 2015-04-10 | 2016-11-23 | 中兴通讯股份有限公司 | 一种寻呼消息的发送方法、基站控制器及基站收发台 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005005967A (ja) * | 2003-06-11 | 2005-01-06 | Nec Corp | 移動通信システムにおけるページング多重方法、および移動通信システム |
US8619816B2 (en) * | 2005-05-20 | 2013-12-31 | Go Net Systems Ltd. | Method and corresponding device for improved bandwidth utilization |
CN100558186C (zh) * | 2006-10-12 | 2009-11-04 | 华为技术有限公司 | 一种寻呼消息处理方法及装置 |
CN101227732B (zh) * | 2008-02-02 | 2012-05-23 | 中兴通讯股份有限公司 | 一种全球移动通信系统中基站子系统寻呼的方法 |
-
2007
- 2007-09-17 CN CNA2007101498480A patent/CN101394583A/zh active Pending
-
2008
- 2008-09-16 EP EP08800870.1A patent/EP2192796B1/en not_active Not-in-force
- 2008-09-16 WO PCT/CN2008/072374 patent/WO2009036696A1/zh active Application Filing
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101635897B (zh) * | 2009-08-07 | 2012-11-28 | 中兴通讯股份有限公司 | 用于全球移动通讯系统的联合寻呼方法和装置 |
CN106162873A (zh) * | 2015-04-10 | 2016-11-23 | 中兴通讯股份有限公司 | 一种寻呼消息的发送方法、基站控制器及基站收发台 |
CN106162873B (zh) * | 2015-04-10 | 2020-08-04 | 南京中兴软件有限责任公司 | 一种寻呼消息的发送方法、基站控制器及基站收发台 |
Also Published As
Publication number | Publication date |
---|---|
EP2192796A4 (en) | 2011-01-05 |
EP2192796B1 (en) | 2013-04-10 |
EP2192796A1 (en) | 2010-06-02 |
WO2009036696A1 (fr) | 2009-03-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112913315A (zh) | 针对小数据传输的配置 | |
EP1191800B1 (en) | Apparatuses and mobile stations for providing packet data communication in digital TDMA cellular systems | |
US9264975B2 (en) | Post access policing in a mobile communication network | |
US8125937B2 (en) | Data over signaling (DoS) optimization over wireless access networks | |
KR101247851B1 (ko) | 점대다 서비스에 대한 제어 정보 메시지 처리 방법 | |
CN101507329B (zh) | 基站和移动台以及转移目的地小区设定方法 | |
CN102484844A (zh) | 用于提供对局域网的接入的装置和方法 | |
US7336631B2 (en) | Radio network system and radio communication control method | |
CN104980980A (zh) | 一种建立连接的方法、系统和设备 | |
CN103379546A (zh) | 数据分流的方法和装置 | |
US9084158B2 (en) | Supplementary service implementation method, LTE network system and mobile terminal | |
US20140301201A1 (en) | Management of communications with multiple access points based on inter-access point communications | |
KR101211515B1 (ko) | 사용자 기기, 리소스를 결정하기 위한 방법, 리소스를 보고하기 위한 방법, 및 리소스를 분배하기 위한 시스템 | |
CN105557019B (zh) | 一种资源分配、业务传输方法及装置 | |
EP2622900B1 (en) | Methods and nodes for transferring a service identifier from a packet core network to a radio network | |
CN103582018A (zh) | 一种系统间负荷控制方法、接入设备及用户设备 | |
CN101394583A (zh) | 一种寻呼消息组包的方法和装置 | |
CN101449528B (zh) | 在多跳通信系统中提供服务质量支持的方法和节点 | |
US20230413355A1 (en) | Method and equipment for multicast transmission | |
CN102791001B (zh) | 一种寻呼消息组包的方法和装置 | |
CN101370166A (zh) | 长期演进架构下多媒体广播多播业务资源分配方法及系统 | |
Ming et al. | GSM/GPRS bearers efficiency analysis for machine type communications | |
CN103517447B (zh) | 传输数据的方法和装置 | |
CN113273306A (zh) | 无线设备与多个网络节点之间的多重通信的方法、相关无线设备和相关网络节点 | |
CN105491670A (zh) | 数据传输的方法和设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20090325 |