弃我去者,昨日之日不可留; 乱我心者,今日之日多烦忧。
分类: 系统运维
2015-07-29 13:53:36
Abis接口协议
在Abis接口,涉及的协议不多,主要有链路层的LapD协议和第三层协议(规范并没有专门为这一层协议其起名字,因此后面我们都称其为Abis层3协议)。
1.1 LapD协议
在GSM中,LapD(D信道链路接入规程)是BTS与BSC之间传送信令的数据链路规程,其目的是使用D信道通过用户—网络接口在第三层各实体间传送信息。LapD的规定考虑到开放系统互连(OSI)的参考模型和层服务规约。在OSI参考模型中的基本结构技术就是分层的技术。基于这种思想的设计,CCITT在建议Q.920-Q.921中对LapD作了详尽的描述,由于GSM 08.56在Q.921基础上作了一些修改,所以实际使用的是一种变形协议,以下的阐述均基于GSM 08.56。根据GSM规范的定义,BSC与BTS之间的信令接口应遵循LapD规程。
以下的三种信息种类可以被LapD支持:信令(包括短消息信息)、操作维护和层2管理信息。
对每种信息种类BSC可以由一条或多条层2的链路到每个TRX和BCF。在Abis接口上的信令链路通过Terminal Endpoint Identifiers (TEI)来寻址不同的是单元。
同样的单元通常有多个功能实体,在不同的功能实体之间的逻辑链路通过功能地址Service Access Points Identifier (SAPI)来识别。在GSM规范中,有无线信令链路RSL(SAPI=0),操作维护链路OML(SAPI=62)和层2管理链路L2ML(SAPI=63)三种逻辑链路。
下图显示了不同层2链路的体系模型,一些逻辑链路可以在服用在一条物理链路上,同样的层2逻辑链路不可以分布在一条以上的物理链路上。
1.1.1 帧结构
链路层的基本功能是将要在信道上传送的信息构造成比单个比特大的单位,这种很小的单位将是所有链路层功能工作的基本结构。在信令世界中,这样的一个单位称为一帧。整个问题的关键是要在比特流中包含足够的信息,使接收端能够找到每一帧的开头和结尾。在这一点上LapD是HDLC的继承者,帧的起始和结尾都用一个8比特长的标志。为了防止虚假的开始和结束,引入了“0比特插入”掩盖数据流中出现的与标志相同的比特序列。这种机制允许帧的长度是可变的,甚至不需要指出帧内的实际长度。同一标志可以作为一帧的结束,同时指示下一帧的开始。
图 1 1 LapD帧标志
1.1.2 分段和重组
帧的最大长度要受低层传输约束的限制,当信令报文的最大长度超过帧允许的最大长度时,这条报文就得分段,按几帧发送;相反的,在接收端必须将报文重组。要作到这一点,接收端必须收到足够的信息才能知道怎样重组报文,这增加了协议的额外开销。当预见到信令报文的最大长度不会超过帧的最大长度时,就可以免去分段和重组的过程。
在Abis接口上无须定义分段和重组的功能,Abis的LapD帧长度简单地限制在264字节(不包括标志),它对应上一层信息的260个字节。
1.1.3 检错和纠错
链路层的第二个重要功能是通过检测可能发生传输差错的帧,并当帧出错时请求重发来提高传输的质量。
就检错来说,LapD使用了HDLC方案(它在每帧增加了16个冗余位,在LapD中称为FCS,或帧校验序列),根据差错检测特点选取编码方案。在LapD协议中,使用了生成多项式:X16 +X12 +X5 +1来计算16比特。
差错检测由两个用途:一是提供帧内残余差错似然性的足够信息,从而可请求重发该帧;二是检测链路的质量,当误码率超过某给定门限时就触发相关的告警。帧确认和重发功能通过消除剩余差错的方法可获得很好的性能,LapD协议没有利用前向纠错能力(这种特征通常被认为是物理层的),而是使用了类似HDLC的后向纠错机制,可在两种模式中选择:
- 不确认模式,无论接收端结果怎样,帧只传一次;
- 确认模式,可由重发保证纠正有错的帧。
确认和重发都是以循环帧计数为基础的,它使接收者能检测可能的帧重复和/或帧丢失,并确认特定的帧。在LapD中,确认是通过接收机向发送方传送下一个期望帧的号码N(R)实现的,LapD的最大帧号(计数周期)是128。这一机制示于下图中,如果帧号是按模8计算的,一个接收端期望2号帧则表明帧号为1,0,7,6,…的帧都已正确收到了。在各种情况下,如果有未确认的帧,发送方都要重发那一帧。然而,重发的总次数是要受到限制,以免当发生严重问题时出现无限循环。
图 1 2 重发机制
发送方必须保留帧知道它们得到确认,以便当需要重发时可用。为了限制相应的缓冲器的数量,以及避免计数的歧义,LapD中用到了窗口概念。发送窗的大小决定了在任一时刻已发出但尚未得到确认的帧数。这个窗的大小值K必须足够大,使得发送方可进行预期处理而不必因等待确认而延时。在LapD中,窗口的大小可以改变。
为了在接口两侧启动一个确认模式的传输,LapD中使用了一个简单程序,它由两条消息组成,参见多帧操作过程。只有在这一交换后才会发生上层信息的交换。与确认模式下传输的建立类似,链路的正常释放也通过一个简单的过程完成,参见多帧操作过程。
1.1.4 复用
链路层提供了将信息流在一个信道上复用的可能性。这些信息流是独立的,不能保证它们之间帧的次序,而且要对各个流分别运用窗口机制。为了区分它们,要在每个帧中插入一个地址。这种机制对于点对多点链路是必须的,它就是为有一条线路和几个终端的用户装置涉及的,并在LapD中保留下来。
Abis接口上的复用有两个方面。一方面是对应于不同功能之间的差别,其实现与无线接口相类似。这一接口上的“SAPI”值列在下表中,SAPI0用于自/至无线接口的所有报文。另一方面,复用要向终接在BTS内不同设备提供不同链路(TRX),这个的鉴别利用了LapD链路层地址的另一个域TEI(终端设备识别),TEI的动态管理是SAPI63消息的一种功能。
SAPI 信息流类型
0 无线信令
62 操作和维护
63 层2管理
1.1.5 流量控制
链路层要研究的最后一个问题是流量控制。当考虑一条链路时,通常假设接收端的处理和缓冲能力能处理链路的最大吞吐量。但是,经常是由不同信息流共享资源,其处理能力要低于各个信息流最大能力之和。拥塞控制的一个目标是控制每个信息流,是系统的某些部分的过载不至于是整个系统能力降为0,并尽可能实现最大的吞吐量。瓶颈可能距离信息流的实际源很远,但必须向其报告拥塞情况以控制输入负载,最终是源信息流量降低。延传输链对每一段分别进行流量控制是有助于控制吞吐量的一个方法。
用类似于HDLC的协议(只需简单地延时发送确认)就很自然地提供了某种方式的流量控制。但这种控制只是勉强合格的,因为如果延时太长,发送者将重复该帧,从而加重了拥塞。也可以使用一种附加机制,即将窗口变为1的简单的停-等协议,LapD中明确要求提供这种机制。
1.1.6 TEI指配过程
下面描述均基于TEI值在0~63之间时的情况。
TRX需要建立相应TEI的传输链路,则向BSC发出UI帧,内含相应的TEI的标识,BSC收到之后,广播一个UI帧,内含一条检测消息,如果其他实体(如其他TRX)有回应,说明该TEI已经被使用,BSC不能分配相应的TEI。如果一段时间内没有收到应答,BSC会再次发送一个广播UI帧,如果再次没有收到应答,则说明该TEI没有被使用,BSC通过一UI帧通知用户分配TEI成功。
1.1.7 TEI检验过程
当BSC怀疑在一条物理链路上存在不止一个用户使用相同的TEI时,则启动TEI检验过程,以便对这一情况进行证实。
1.1.8 TEI取消过程
TEI取消时,BSC侧的LAPD层管理进程应发出MDL-REMOVE-REQUEST原语,引起物理信道上的连续两次身份取消消息的发送。
1.1.9 差错处理
由于LapD链路数据传送的硬件程度高,传送差错大部分能用硬件处理,所以层2软件主要对与TEI有关的差错作相应处理,对一些其它差错仅进行差错记录。
当层2软件收到MDL-ERROR-INDICATION,差错码为C、D、G、H时,将调用TEI检测规程,根据用户侧的响应进行处理:
- 当未收到响应,取消TEI;
- 当收到单个响应,进行差错记录;
- 当收到多个响应,TEI取消规程。
1.1.10 未确认信息传送的过程
第三层用原语DL-UNIT DATA-REQUEST、或管理实体利用MDL-UNIT DATA-REQUEST将未确认的信息传送到数据链路层,这些消息均在UI帧中发送。
- 对广播式操作,UI帧中的TEI值应为127。
- UI帧P比特为0。
对于TEI管理规程消息,在用户侧与网络侧用UI帧发送,且必须经过广播链路,则此类UI帧中的TEI值必为127,SAPI为63。
当接收方收到UI帧时,将采用数据链路层对第三层的原语DL-UNIT DATA-INDICATION或数据链路层对层管理实体的原语MDL-UNIT DATA-INDICATION将信息传送出去(由SAPI确定到第三层或层管理实体)。
需要注意的是,未确认信息的传送与确认信息I帧的传送并不是互斥的,二者可同时进行,在多帧规程的任何一TEI已分配的状态,均可处理UI帧。
1.1.11 多帧操作过程
1.1.11.1 建立过程
第三层用DL_ESTABLISH_REQEST请求建立数据链路连接。数据链路实体向对端实体发送SABME命令。接收SABME命令的实体,如果能进入建立状态,则发送UA响应,向第三层发送建立指示,并进行初始化。收到UA响应,SABME发起者向第三层发出建立证实,并初始化。
1.1.11.2 释放过程
第三层利用DL_RELEASE_REQEST请求释放数据链路连接。数据链路实体向对端发送DISC命令。接收DISC命令的实体向对端发UA响应,丢弃所有I帧队列,进入连接断开状态并通知第三层。DISC命令发起者收到UA响应之后,丢弃所有排队I帧,通知第三层,并进入连接断开状态。
1.1.11.3 信息传递过程
第三层用DL_DATA_REQEST原语请求发送的数据包将首先被链入一个I帧队列,并发出一个I_FRAME_QUEUE_UP的消息,LapD进程收到这个消息后,将发送一个I帧,将发送状态变量VS和接收状态变量VR分配给I帧的NS和NR字段,同时将VS在发送结束后加1。打开定时器T200。信息发送中的流量控制采用滑动窗口机制。窗口大小可随SAPI的不同而略有变化。接收到一帧I帧后,将比较I帧中的发送序号NS和本端接收状态变量VR,如相等则接收,采用DL_DATA_INDICATION原语传送给第三层,不相等则丢弃I帧,向发送端发送REJ帧,表示接收帧顺序错。
在发送端收到一个有效I帧和监视帧(RR、RNR、REJ),将把该帧中的NR做为对所有NS
1.2 Abis层3协议
Abis层3协议的模型可以参见下图。
图 1 3 层3模型
Abis层3协议中的消息按照BTS的处理方式可以分为两类:
透明消息:BTS负责转发该类消息,不加以任何解释或改变。
不透明消息:消息只在BSC和BTS之间传送,BTS根据消息发起相应的动作或消息作为一次BTS动作的结果。
另外,Abis层3协议中的消息根据其具体功能还可以分为四组:无线链路层管理消息、专用信道管理消息、公共信道管理消息和TRX管理消息。
所有的Abis层3协议中的消息几乎都通过LapD的I帧进行传送,除了MEASUREMENT RESULT消息,它是通过LapD的UI帧进行传送。
在空中接口,上行方向(MS发来的消息),所有的通过LapDm的I帧和UI帧的消息,除了MEASurement REPort消息,多被当作透明消息,被BTS在DATA INDication和UNIT DATA INDication消息中转发给BSC。在下行方向(发往MS的消息)的所有Um接口的L3消息除了以下几种之外都是透明通过BTS的,这几种消息在Abis接口被Abis接口层3协议的指定消息替换掉,但到了BTS,BTS在经过必要的动作之后,将发送对应的Um接口L3消息到无线接口上。
Message to MS Replaced on A-bis interface by
CIPHering MODe CoMmanD ENCRyption CoMmanD
PAGing REQuest PAGing CoMmanD
SYSTEM INFOrmation BCCH INFOrmation and SACCH FILLing
NOTIFication NOTIFication CoMmanD
EXTENDED MEASUREMENT ORDER SACCH FILLing
Immediate assign (3 types) IMMEDIATE ASSIGN COMMAND
为了讲清楚有关的信令流程,我们先将部分的全局流程图画出来,以帮助对局部流程的理解。
图 1 4 MS接入和信道分配
图 1 5 寻呼流程和加密模式改变流程
图 1 6 传输模式改变(指配)流程
图 1 7 切换流程
图 1 8 释放流程
图 1 9 其他流程
下面的描述中,如果没有专门说明消息所属的协议,则统统是指Abis接口层3的消息。
1.2.1 无线链路层管理过程
1.2.1.1 链路建立指示
当BTS检测到在一条已经激活的逻辑信道上MS发来的一个SABM帧,则通过一条ESTablish INDication消息向BSC指示在无线接口上MS发起的一条多帧模式的L2链路已建立,消息中包含了SABM帧中携带的内容。BSC在收到该消息后应该进行和MSC建立一条SCCP连接的过程。
在MS初始接入流程、信道模式改变(指配)流程和切换流程中,我们都可以看到链路建立指示过程。另外,当MS要发送点对点短消息时也会使用链路建立指示过程。
1.2.1.2 链路建立请求
当BSC需要主动和MS在无线接口建立一条多帧模式的L2链路时,向MS所在的BTS发送一条ESTablish REQuest消息,BTS向MS发送一SABM帧,在收到MS的UA应答帧时,BTS发送一条ESTablish CONFirm消息给BSC作为肯定应答。
这个过程使用得比较少,只有在网络要发送点对点短消息给MS时才会使用,这时BSC主动要求建立一条新的用于发送点对点短消息的L2链路。
1.2.1.3 链路释放指示
当BTS通过一条多帧模式的链路层连接收到MS发来的一个DISC帧,则BTS发送一条RELease INDication消息通知BSC无线接口的链路层连接已经释放。BSC在收到RELease INDication消息后可以将相应的逻辑信道释放。
在会话释放流程中,我们可以看到链路释放指示过程。另外在MS主动将发送点对点短消息的L2链路释放时也会使用。
1.2.1.4 链路释放请求
当BSC要求释放一条多帧模式的L2链路时,向BTS发送一条RELease REQuest消息给BTS,BTS则在该L2链路上发送一DISC帧给MS,当BTS收到MS发送的应答(UA或DM帧),则发送一条RELease CONFirm消息给BSC。
这个过程使用得比较少,只有在网络主动将给MS发送点对点短消息的L2链路释放时才会使用。
1.2.1.5 透明L3消息在确认模式下的发送
BSC发送一条DATA REQuest消息给BTS,消息里面包含了完整的需要用确认模式发送的L3消息。
此过程用于BTS透明发送Um接口的RR、MM、CC和SS消息给MS。
1.2.1.6 透明L3消息在确认模式下的接收
BTS在收到一条确认模式下的L3消息时,将该消息放在一条DATA INDication消息发送给BSC。
此过程用于BTS透明发送Um接口的RR、MM、CC和SS消息给BSC(后三类消息又透明通过BSC传给MSC)。
1.2.1.7 透明L3消息在不确认模式下的发送
BSC发送一条DATA REQuest消息给BTS,消息里面包含了完整的需要用不确认模式发送的L3消息。
此过程用于BTS透明发送Um接口的RR消息给MS。
1.2.1.8 透明L3消息在不确认模式下的发送
BSC发送一条UNIT DATA INDication消息给BTS,消息里面包含了完整的需要用不确认模式发送的L3消息。
此过程用于BTS透明发送Um接口的RR消息给BSC。
1.2.2 专用信道管理过程
1.2.2.1 信道激活
当BSC为决定为某个MS分配了一个逻辑信道则通过消息CHANnel ACTIVation命令BTS的对应TRX启动相应的信道,在激活信道之后TRX用消息CHANnel ACTIVation ACKnowledge作为肯定回答,或用消息CHANnel ACTIVation NACK作为否定回答。
在MS初始接入、切换和信道模式改变(指配)流程中,我们可以看到信道激活过程。
1.2.2.2 信道模式改变
当BSC要改变以激活信道的一些模式信息时(这都是由MSC发来的消息触发的),发送一条MODE MODIFY消息给BTS,消息中包含了新的模式(BTS使用的旧模式是在信道激活或前一次信道模式改变中指定的),在改变到新模式之后,BTS向BSC发送一条MODE MODIFY ACKnowledge消息作为肯定回答,或发送一条MODE MODIFY NACK消息作为否定回答。
在信道模式修改流程中,我们可以看到信道模式修改过程。
1.2.2.3 切换检测
在切换过程中,当MS尝试接入目标BTS和BSC时,会在新信道上向BTS发送HANDOVER ACCESS接入突发,BTS每次接收突发成功则向BSC发送一条HANDOver DETection消息。如果切换采用的是异步切换方式,则期间BTS会向MS重复发送多次PHYsical INFOrmation消息。
在切换流程中,我们可以看见切换检测过程。
1.2.2.4 开始加密
BSC在决定对信道上传输的信息采用新的加密算法时(这都是由MSC发来的BSSMAP协议的消息触发的),向信道所在的BTS发送ENCRyption CoMmanD消息,消息中包括需要BTS要使用的所有信息以及一条传给MS的完整的Um接口RR层的消息Ciphering Mode Command(因为加密需要发送方和接收方都了解有关信息才行),BTS收到消息之后,以原加密模式将内含的Um接口RR层的消息Ciphering Mode Command传给MS,同时开始启动新解密模式(上行方向)。MS收到Um接口RR层的消息Ciphering Mode Command后,同时启动新加密(上行方向)和新解密(下行方向),并发送CIPHering MODe COMplete消息给BTS,BTS收到任何一个正确解码的报文(在新加密模式下),就表明MS已正确地转换到新的加密模式时,BTS的发送也变为新加密模式(下行方向),并在收到MS的CIPHering MODe COMplete消息(Um接口RR消息)后,将该消息放在Abis接口消息DATA INDication中发送给BSC,作为肯定回答。若BTS基于某种原因不能按照的ENCRyption CoMmanD消息要求加密,它就回发一个ERROR REPORT消息给BSC作为否定回答。
在加密流程中,我们可以看到开始加密过程的使用。
1.2.2.5 测量报告
一般情况下,MS每102/104复帧将一个测量报告(Um接口消息MEASurement REPort)通过SACCH信道上报BTS,里面包含了102/104复帧以来的下行的测量信息,BTS在这期间同时也在进行着上行的测量,因此每过102/104复帧,BTS会将这两部分信息组合在一条Abis消息MEASurement RESult发送给BSC,如果因为某些原因,BTS没有按时收到MS的测量报告,则只将自己的上行测量结果放在Abis消息MEASurement RESult发送给BSC。
在其他流程中,我们可以看到测量报告过程的使用。
为了减少BSC的处理测量报告的负荷以及减少Abis接口的消息流量,还可以使用一种所谓的测量报告预处理的过程,即由BTS先对102/104复帧一次的测量数据作一些加工(如求平均),然后将加工的结果以比较低的频次发送给BSC。要让BTS进行测量报告预处理,首先BSC要发送一条PREPROCESS CONFIGURE消息给BTS,消息中包含了BTS进行加工需要的一些基本控制参数,BTS在收到这个消息后,就进行测量报告的预处理,将预处理的结果以PREPROCESSED MEASUREMENT RESULT消息发送给BSC。
当在上行SACCH信道中包含了一条MS发来的EXTended MEASurement REPort,BTS将向常规处理方法一样将它转发给BSC,不能使用测量预处理。
1.2.2.6 SACCH去激活
此过程用于BSC根据无线信道释放程序释放BTS处的SACCH逻辑信道。在BSC发送Channel Release消息(Um接口RR层消息)给MS时,BSC也发送一条DEACTIVATE SACCH消息给BTS以去激活SACCH信道。
在信道释放流程中,我们可以看到SACCH去激活过程的使用。
1.2.2.7 无线信道释放
当某个逻辑信道不再被使用的时候,BSC需要通知BTS将该信道释放掉,于是向对应的BTS发送一条RF CHANnel RELease消息,BTS在释放该信道后,返回一条RF CHANnel RELease
ACKnowledge消息给BSC。
在信道释放流程中,我们可以看到无线信道释放过程的使用。
1.2.2.8 MS功率控制
BSC会根据测量数据的结果推算出MS应该使用的合适的发射功率,于是通过消息MS POWER CONTROL将控制参数通知BTS,BTS将这些信息通过SACCH信道的L1帧头发送给MS,从而最终完成MS功率控制的动作。
在其他流程中,我们可以看到MS功率控制过程的使用。
1.2.2.9 基站功率控制
BSC会根据测量数据的结果推算出BTS侧应该使用的合适的发射功率,于是通过消息BS POWER CONTROL将控制参数通知BTS,BTS随之执行相应的发射功率调整工作。
在其他流程中,我们可以看到基站功率控制过程的使用。
1.2.2.10 连接失败
当BTS检测到激活的无线链路已经中断时,发送消息CONNection FAILure INDication通知BSC无线连接已经中断,消息中包含了BTS认为最可能的中断原因。
在会话释放流程中,我们可以看到连接失败过程的使用。
1.2.2.11 物理上下文请求
当BSC需要了解MS所在当前信道的一些情况(物理上下文)时,发送申请消息PHYsical CONTEXT REQuest给BTS,BTS通过消息PHYsical CONTEXT CONFirm将有关的物理上下文告知BSC。一般来说,物理上下文主要包括MS的当前的时间提前量以及上下行当前的发射功率等(当由BTS进行功率控制时)。
在信道模式修改(指配)流程和切换流程中,我们可以看到物理上下文请求过程的使用。
1.2.2.12 SACCH信息修改
在SACCH信道的下行方向上,BTS除了在L1帧头将功率控制参数和最新的时间提前量通知MS之外,还要将Um接口的RR消息SI5/5bis/5ter/6重复发送给MS,当BSC想修改某条SACCH上的相关消息,则发送一条SACCH INFO MODIFY消息给BTS,消息中包含了新的Um接口的RR消息SI5/5bis/5ter/6。
在其他流程中,我们可以看到SACCH信息修改过程的使用。
1.2.2.13 说者检测
当在为一个话音组呼叫(voice group call)的信道被激活期间,BTS如果收到MS在信道的上行方向的接入突发,BTS则组装一条VGCS UPLINK GRANT消息(Um接口L3消息)以不确认模式在主信令链路上发送给MS,同时BTS发送一条TALKER DETection消息给BSC,消息中包含了测量到的接入突发的时延,如果一定时间内没有MS收到一个正确解码的帧,BTS则重复发送VGCS UPLINK GRANT消息给MS,如果连续发送多次,仍然无法从MS收到正确解码的帧,BTS将发送一条CONNECTION FAILURE INDICATION消息给BSC。
这个过程只有在系统支持VGCS/VBS的情况下才会被使用。
1.2.2.14 听者检测
当在为一个话音组呼叫(voice group call)的信道被激活期间,BTS如果收到MS在信道的一个接入突发,包含了保留作为上行接入请求应答的值,则BTS组建一条LISTENER DETection消息发送给BSC。
这个过程只有在系统支持VGCS/VBS的情况下才会被使用。
1.2.3 公共信道管理过程
1.2.3.1 MS信道请求
当BTS在RACH信道上检测到MS的一个随机接入(即MS的CHANnel REQuest消息),则发送一条消息CHANnel ReQuireD给BSC,里面包含了CHANnel REQuest消息的有效信息。
在初始接入流程中,我们可以看到MS信道请求过程的使用。
1.2.3.2 寻呼
从A接口收到MSC发来的BSSMAP协议的PAGING消息,BSC发送一条PAGing CoMmanD消息BTS,消息包含了MS标识(TMSI或IMSI),BTS通过消息PAGing REQuest在无线口的PCH信道上发送给MS。
在初始接入流程中,我们可以看到寻呼过程的使用。
1.2.3.3 删除指示
当BTS发觉由于下行CCCH信道拥塞而删除了一条IMMEDIATE ASSIGN COMMAND,则用消息DELETE INDication通知BSC。
在初始接入流程中,我们可以看到删除指示过程的使用。
1.2.3.4 CCCH负载指示
当BTS检测到某条CCCH信道过载时,则需要向BSC周期性发送一条CCCH LOAD INDication消息以通知BSC。
在其他流程中,我们可以看到CCCH负载指示过程的使用。
1.2.3.5 广播信息改变
当BSC要改变BCCH信道上发送的信息,则发送一条BCCH INFOrmation消息给BTS,消息中包含了完整的需要修改的Um接口的RR层的SI消息。
在其他流程中,我们可以看到广播信息改变过程的使用。
1.2.3.6 短消息小区广播
短消息服务小区广播消息以Abis接口消息SMS BROADCAST REQUEST或SMS BROADCAST COMMAND发送给BTS。
在其他流程中,我们可以看到以下的短消息小区广播过程的使用。
当使用SMS BROADCAST REQUEST消息模式时, BSC要负责处理排队、重发和如何充分利用CBCH信道的工作,BSC也要负责将SMS小区广播消息分成适合在无线接口上发送的小块。
当使用SMS BROADCAST COMMAND消息模式时,BSC能够请求一条完成的小区广播消息。BSC处理排队、重发和如何充分利用CBCH信道的工作,BSC也要负责将SMS小区广播消息分成适合在无线接口上发送的小块。
当使用SMS BROADCAST COMMAND消息模式时,BSC能够设置BTS广播缺省消息,BTS在BTS没有其他消息要发送的时候,则负责发送缺省广播消息。
即使BSC处理如何充分利用CBCH信道的工作,BTS也能够在CBCH信道负载过重或负载过轻的时候通知BSC,通过使用消息CBCH LOAD INDICATION,当负载过轻的时候BTS能够请求立即广播多条BSC已安排好的SMSCB消息,BSC通过消息发送给BTS。
通过使用消息CBCH LOAD INDICATION,当负载过重的时候BTS能够请求立即停止广播一段时间,BSC在此期间不再发送短消息给BTS,直到时间过为止。
1.2.3.7 立即指配
BSC在收到MS信道请求,则相应地争取为其分配一条信道并将信道激活,然后发送一条IMMEDIATE ASSIGN COMMAND消息给BTS,消息中包含了一条完整的通知MS的Um接口RR层消息IMMEDIATE ASSIGNMENT或IMMEDIATEASSIGNMENT EXTENDED或IMMEDIATE ASSIGNMENT REJECT(如果没有信道可用),BTS收到这条消息后,负责在CCCH信道安排将消息中的Um接口RR层消息发送给MS。
在初始接入流程中,我们可以看到立即指配过程的使用。
1.2.3.8 通知
当BSC要求修改争对某语音组呼叫(voice group call)的通知时,发送一条NOTIFication CoMmanD消息给BTS,BTS在无线口组装并发送相应的NOTIFication消息(Um接口L3消息)。
如果因为某些原因BTS 无法执行BSC发来的通知命令,则BTS返回一条ERROR REPORT 消息。
这个过程只有在系统支持VGCS/VBS的情况下才会被使用。
1.2.4 TRX管理过程
1.2.4.1 无线资源指示
此过程用于BTS将下属的某个TRX上的空闲信道的干扰情况周期性地通知BSC,使用消息RF RESource INDication。
在其他流程中,我们可以看到无线资源指示过程的使用。
1.2.4.2 SACCH填充信息改变
当BSC要修改在SACCH信道上发送的SI5/5bis/5ter/6/EXTENDED MEASUREMENT ORDER消息时,通过发送一条SACCH FILLing消息给BTS.
1.2.4.3 流量控制
当TRX的处理器过载、下行CCCH过载或ACCH过载,BTS要根据一定的要求向BSC发送OVERLOAD消息(过载之后周期发送直到过载解除),将当前的情况通知BSC。BSC要控制相应的业务流量,算法简单描述如下:
在收到第一条OVERLOAD消息,BSC减少一级业务,启动定时器T1和T2。在T1期间,所有的OVERLOAD消息都被BSC忽略,主要防止业务减少得太快。在T1超时之后但T2未超时之前,如果收到BTS发来的一条OVERLOAD消息,BSC将再降低一级业务并重新启动定时器T1和T2。这样一步接一步的减少业务直到已经无法再减少为止。如果T2超时,业务将升高一级,并重新启动T2,这样一步接一步的升高业务直到所有负荷都恢复。
再其他流程中,我们可以看到流量控制过程的使用。
1.2.4.4 错误报告
当BTS检测到一些错误,而且无法通过其他过程报告给BSC,则发送一条ERROR REPORT 消息给BSC。消息中包含了引起错误的最可能的原因一级引起错误的消息的标识、类型、信道号、链路标识甚至完整的引起错误的消息。
在加密流程中,我们可以看到错误报告过程的使用。在BTS从BSC收到无法正确使用的消息的时候,也会使用到错误报告过程。