基于IP架构的cdma2000系统A接口协议的设计.doc_第1页
基于IP架构的cdma2000系统A接口协议的设计.doc_第2页
基于IP架构的cdma2000系统A接口协议的设计.doc_第3页
基于IP架构的cdma2000系统A接口协议的设计.doc_第4页
基于IP架构的cdma2000系统A接口协议的设计.doc_第5页
免费预览已结束,剩余5页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

基于ip架构的cdma2000系统a接口协议的设计摘要:结合一种基于ip架构的cdma2000系统,讨论了a接口上信令/业务/控制流的特点和网络组成,提出了在ip网络架构下a接口协议的设计方案,完成了a接口中信令子接口的ip化协议设计,以及业务子接口听控制流模型设计,形成了一个完整的ip化a接口协议体系。对呼叫处理中的指配流程进行改进,降低了系统的呼损率。关键词:ipcomaa接口a1/a2 指配流程随着ip协议在世界范围内的广泛应用以及cdma移动通信系统的飞速发展,基于ip网络架构的cdma2000系统的设计问题日益受到人们的关注。在设计基于ip的cdma2000系统时,a接口的设计是关键。由于系统核心网络的全ip化,并引入了控制与业务、传送与接入分离的中交换设计思想,在ip上实现a接口协议与在传统电路交换上实现a接口有所不同,主要是需要设计信令与业务分离的a接口协议栈以及信令流、业务流在ip承载方式下的传输。1 ip架构下的cdma2000的系统a接口研究a接口是无线接入网与核心网之间的接口。在cdma2000系统中a接口包括:a1/a2、a3/a7、a8/a9和a10/a11等接口,它们满足3gpp2ios4.1规范。a1/a2接口是cdma2000系列移动交换中心(msc)与基站控制器(bsc)之间的接口,该接口秉承cdmaone系统。a1接口用于传输msc与bsc之间的信令信息;a2接口用于传输msc与bsc之间的话音信息。msc与bsc之间的a1/a2接口,传统上称之为a接口,下文中加不特殊声明a接口即指此接口。11基于ip的cdma2000系统体系结构目前cdma系统模型有很多种,这里结合一种基于ip架构的cdma2000系统讨论a接口的设计。本系统采用多种无线传输与接入技术、ip网络技术以及软交换控制技术等,其核心交换机制为ip交换机制,即利用统一的ip交换平台在各功能部件间交换信令控制信息和业务数据信息。系统结构如图1(a)。系统主要划分为以下几个模块:无线接入单元wau(wirelessaccessunit):完成空中接口物理信道的收发处理,建立和维护与无线终端设备之间的无线通道连接。无线接入服务器was(wirelessaccessserver):主要完成与wau之间接口信令的处理和与cs的交互,辅助cs实现电路型业务的无线资源管理与控制、移动性管理和呼叫控制功能。呼叫控制服务器cs(callserver):主要完成无线资源和呼叫的控制与管理,实现中交换中媒体网关控制器的功能。电路媒体网关cmg(circuitmediagateway):实现连接pstn、isdm和plmn的网关功能以及话音压缩编解码功能。呼叫信令网关csg(callsignalinggateway):为系统中分布的各种应用提供稳定、可靠的信令支持。以及位置寄存器(lr)、分组数据业务网()pdsn、操作维护中心(omc)等模块。12a接口的网络架构a接口架构如图1(b)所示,msc与bsc之间的接口即为文本所研究的a接口,包含信令和用户业务两个子接口,对应标准a接口的a1/a2接口。cs与was之间的接口构成信令子程序;对应标准a接口中的a1接口,用于传输msc与bsc之间的信令消息;was业务部件与cmg之间以及两个was业务部件之间构成了业务子接口,对应标准a接口中的a2接口,用于传输msc与bsc之间的语音业务信息。电路分配单元cdb在cs与cmg的控制关系中起辅助作用,负责选定路由。2基于ip的a接口方案设计21a接口协议栈设计传统电路交换型cdma系统中a1接口采用3gpp2的ios4.1版本规范中规定的七号信令sccp0类和2类协议及mtp等作为低怪传输协议。基于ip的cdma系统引入中交换思想,呼叫控制与业务承载分离。而sccp信令协议又无法分别交换控制和承载的信息,而此需要新的信令系统支持。本系统的a接口采用tcp/ip协议作为低层传输协议。协议栈结构如图2所示。信令和业务子接口协议栈的物理层、数据链路层和网络层协议均采用商售以太网交换机上的标准协议。传输层采用本系统的专利技术:rudp协议代替了传统的七号信令sccp。信令子接口应用层内容基本对应3gpp2的ios4.1版本规范a1接口中的基站管理应用部分(bsmap)和直接传递应用部分(dtap);业务子接口应用层内容以媒体数据为主。rudp协议是“reliableudp”的简称,是一种自定义的、为udp引入可靠传输机制的简化协议。它兼顾有tcp的可靠性与udp的高效性,是本系统可靠传输所采用的协议。rudp的基本思想是在udp包头内加入两个字节的协议头,即一个字节的前向序号和一个字节的后向序号。围绕这两个字节的协议头,rudp协议采用了一个套证实机制、重发机制、序号对齐机制分别保证了rudp通信的可靠性、高效性和数据流的有序性。rudp协议技术保证了系统内信令和业务数据的传输性能要求。22信令子接口设计221信令连接建立方式(1)传统的信令连接建立方式传统cdma系统a1接口信令采用了七号信令sccp的0类基本无连接业务和2类基本有连接业务。sccp通过e1接口传输信令消息建立信令连接。e1接口即一个pcm中继电路,可以同时容纳32时隙64kbps的语音数据。在32个时隙中,第0时隙被用作帧同步信息,第16时隙作为sccp的信令通道,其余30个时隙被用作语音时隙被作用语音通道。这样,第16时隙就被信令消息全时独占,无论该时隙空闲与否,均不允许其它消息(语音消息)使用,造成了资源浪费。(2)ip架构下的信令连接建立方式由于协议栈采用了tcp/ip传输协议,因此在设计a1接口信令连接方式时取消了基于无连接方式的应用,所有信令均基于有连接方式传送。在a1接口上以目的设备id(d_did)、目的处理id(d_cid)和源设备id(s_did)、源处理id(s_cid)组成的四元组唯一标识一个信令连接。信令连接以一次握手的机制建立。连接建立方首先发送源处理id为空的连接起始建立消息,接收方进行处理后回送的第一条消息为本次处理申请的处理id,双方连接建立完成。所有信令均基于有连接方式传送,连接建立的流程如图3所示。实体1与实体2之间由实体1发起一个基于连接的处理流程,实体1首先申请处理id,在始发消息的信件头d_did中填对端实体2的设备id,d_cid填空。s_did填实体1的设备id,s_cid填本地处理id。实体2收到d_cid为空的始发消息,确认可以处理后申请处理id,向对方发送后续处理消息,消息中d_did、d_cid置对方did和cid,s_did、s_cid置本身did和cid。至此双方信令连接成功。222消息及消息元素继承了标准basp协议中定义的大部分消息和消息元素,并结合ip网络特性增加、删除了部分消息和消息元素。(1)由于a2接口上用户业务基于ip传输,完全取消了a2接口电路的概念,因此删除所有地面电路管理类消息和电路识别码cic等消息元素;因简化了清除流程,而删除呼叫处理类的清除请求消息;(2)增加两条用于呼叫建立的新消息。放语音通知:由cs发向was,用于向移动台播放辅助语音;开始语音业务:由cs发向was,用于向was通知呼叫对端的业务端口地址,开始接入通话状态。223a1接口上的呼叫处理流程以移动中(ms)始发语音呼叫为例介绍呼叫建立流程,并以bsc侧发起为例介绍了呼叫清除流程。(1)ms始发语音呼叫建立流程流程建立如图4(a)所示。a.ms发送语音呼叫,was收到控制信道上传来的始发消息,选定某个cs,发送连接管理cm(connectionmanagement)业务请求消息;b.cs收到cm业务请求消息,确定能够处理,申请处理id后向was发送连接确认消息,建立ip虚连接;c.cs根据was建立的业务选项,发送指配请示消息,请求was为ms指配无线业务信道;d.was指示wau和ms交互,完成无线业务信道指配,向cs发送指配完成消息,等待cs进行后续呼叫处理;e.cs进行呼叫接续,发现被叫为本局ms,进行寻呼被叫流程,在被叫开始振铃后,向was发送放语音通知,指示was通过带内音向主叫ms播放回铃音,提醒主叫ms等待被叫摘机;f.cf收到被叫ms的应答指示,向was发送“开始语音业务”消息,通知被叫ms的业务端口,was收到后,建立业务链路ip虚链妆,开始交互语音数据包,主被叫双方进入通话状态。在步骤e中如果cs进行呼叫连续时发现被叫为外局ms或外网终端,则先通过cmg申请出局中继电路,将was端口与出局电路连接,然后直接向was发送“开始语音业务”消息,通告出局电路的业务端口。was收到后,与出局电路业务端口建立虚连接,后续呼叫处理提示信息(如回铃音等)由出局电路通过业务链路由带内音主叫ms提供。(2)bsc侧发起的呼叫清除流程标准a接口协议中,无论是哪一侧发起的呼叫清除,都只能由msc向bsc发送清除命令。如果是bsc侧发起的呼叫清除,则bsc必须先向msc发送清除请求消息,再由msc通过发送清除命令指令bsc释放相关专用资源(如地面电路)。在ip架构下,已取消了地面电路概念,因此对呼叫清除流程进行了简化,取消了清除请求消息,bsc侧可以直接向msc发送清除命令。bsc侧发起的清除流程如图4(b)所示。a.was收到移动台发来的释放指示或由于其他原因,首先释放本次呼叫相关资源,然后向cs发送清除命令,指示cs清除本次呼叫;b.cs收到was发来的清除命令,释放本次呼叫相关资源后,向was发送清除完成消息,同时释放处理id。was收到清除完成后也释放处理id,完整整个信令连接的释放。23业务子接口设计231ip包交换方式因核心网络基于ip架构,故业务子接口采用ip包交换方式传输业务流。ip包交换基于ip包格式的分组交换,是一种非面向连接或无连接的存储转发方式。各种语音、数据业务都采用ip包的格式,使用统一的以太网接口及协议,通过网络交换完成传输。它可实现多种速率的交换,能灵活支持带宽不同的多种业务,并且只在发送时才占用网络资源,网络资源可由各个业务共享。232ip包交换下的业务流控制模型业务子接口的资源实体包含was业务部件和cmg。was业务部件的业务端子称为was端口,它可以输入输出ip包媒体流,完成无线接入网与核心网业务流的交互。cmg包括两种业务端子:中继端口和声码器。中继端口完成pcm语音流的输入输出。声码器完成pcm流和ip包媒体流的转换。这三种业务端子的不同组合衍生出不同的业务流控制模型,完成用户业务流在业务子接口上的传输。(1)was与was相同声码器编码类型主被叫双方位同一局且双方声码器类型相同时,呼叫一方产生的业务包可以不经cmg进行编码类型转化而直接通过内部ip网络发送到另一方。双方业务端口均为was业务端口。(2)was与was不同声码器编码类型主被叫双方位于同一局但双方声码器类型不同时,呼叫一方产生的业务包括必须经本端声码器转换为pcm语音流,再通过将两端声码器的pcm出口对接形成的ip隧道输入到对端声码器中;对端声码器将pcm语音流转化为ip包,再经由网络发往另一方的was端口。(3)was与中继端品主被叫双方位不同局且其中一方的业务端口为中继端口,或一方为漫游用户、另一方的业务端口为中继端口时,需要一个声码器来完成ip与pcm语音流的转化,且此声码器与中继电路须处于同一cmg中。(4)中断端口属于相同cmg呼叫双方的业务端口皆为中断端口并且属于同一cmg时,将两中断端口的pcm出口对接即可实现业务交互。(5)中继端口分属不同cmg呼叫双方的业务端口皆为中继端口但不属于同一cmg时,双方需要在各自中继端口所属cmg上申请一个声码器以完成pcm语音流与ip包的相互转化。一方发出的pcm语音流经声码器转化为ip语音包,进行网络交换一到达另一方所属cmg的相应声码器,再转换为pcm语音流通过中继端口发送出去,反之亦然。通过对以上各种模型的分析可知,在无线ip环境下实现移动终端之间的话音业务时,业务流在a接口上无需经过编码类型转换而以ip包方式直接交互,节约了声码器资源,避免了标准a2接口上固定的声码器-中继-声码器连接模式中的两次编解码变化对语音质量的损失,从而提高了业务质量。3指配流程的改进(1)标准指配流程描述如上所述,在设计a接口协议流程时,继承了标准流程中的指配流程:即收到cm业务请求或寻呼响应时,was并不立即与ms建立无线业务信道,而是收到cs的指配请示消息后,was才开始与ms交互交开始建立无线业务信道。(2)弊端在测试过程中,was从收到ms初始信道到收到cs的指配请求最多可能需要6s。而cdma无线环境是高时变系统,每时每刻都可能因为ms的移动或周边环境的变化引起无线环境的变化。这样当was收到cs指配请求、开始在ms始发消息带来的无线环境参数指导下建立业务信道时,以前的测量参数已不完全适合现在的无线环境,这样基站要俘获ms只有加大功率反复搜索,对设备资源和系统容量都有很大的负面影响,同时系统呼损率较高。(3)改进鉴于上面的分析,对指配流程进行改进:在不支持加密业务的前提下,把业务信道建立的时机提前,即只要was收到ms的始发消息,就开始俘获ms建立业务信道;待业务信道成功建立后,was再向cs发送a1接口呼叫建立消息,这样ms就不会在业务信道建立前的间隙逃脱。实践证明以上流程的修改显著降低了系统的呼损率。(4)进一步研究指配流程在标准接口中有两个作用:指配地面电路、指配无线信道。基于ip的cdma20

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论