CDMA-QCHAT交流材料PPT课件.ppt

QCHAT特性介绍 CBSC测试组凌湘寿2003年10月25日 1 本材料主要内容 1概要介绍集群业务 2PCF部分的修改 3RRM部分的修改 4FMR部分的修改 5CCM CMF SM部分的修改 6DB OM部分的修改 7BTS MSC的配合问题 8代码估计 风险分析 9参考资料 2 1概要介绍集群业务 本节主要内容包括 Pushtotalk业务的概念PUSHTOTALK业务典型应用CDMA网PTT业务技术平台的进展PTT进一步发展存在的问题高通公司QChat业务QChat需要满足的基本要求QChat呼叫建立类型 3 1概要介绍集群业务 2 QChat呼叫中目标加入会话的模式QCHAT协议结构华为QChat解决方案需要CDMA1X的支持的内容Qchat应用服务器需要考虑的特性我们系统支持PTT面临的挑战 4 1概要介绍集群业务 20030915情报所资料 PUSHTOTALK业务向大众用户走来一 Pushtotalk业务的概念PTT PUSHTOTALK 业务也称即按即说业务 指的是实时直连的 点到点 和 点到多点 话音通信 这种业务使用非常简单的半双工通信方式 也就是说同一时间只有一人能够讲话 以便于群体交流 主叫方只要按一个键就可向一个人或一组人发起通话 无需拨号和等待对方摘机 电话立即接通 迅速建立起 谈话组 5 PUSHTOTALK业务典型应用 PUSHTOTALK业务典型应用是 一个团队在行动过程中需要一直听管理者的信息和命令 而团队成员偶尔需要向管理者说些什么 队员之间有时也需要交流 这种简单 直接的通信无论在需小组管理的商业用户非常实用而必要 车队司机和总调度的通信属于这种业务的典型应用 政府部门的执行公务 商业娱乐 社会活动的协调也很需要这种服务 6 基于VoIP技术的Pushtotalk 从业务上讲 基于VoIP技术的Pushtotalk业务实质上是把话音作为无线数据的一种应用 把风靡Internet的传统即时文本消息和即时图象消息的所具有的好友列表 状态呈现 聊天等功能引入话音服务 为用户需求中占绝对重要地位的话音业务赋予了新的内容 通过为消费者提供更大的价值也为运营带来附加收入 恰当解决了数据业务这个长远发展方向和当前依靠话音业务生存的矛盾 况且Nextel的实践证明Pushtotalk业务在市场上是受欢迎的 7 CDMA网PTT业务技术平台的进展 CDMA网PTT业务技术平台的进展目前CDMA2000的Pushtotalk业务的技术方案基本采用的是NextelCommunications Qualcomm和Motorola联合开发的Qchat方案 Qchat方案以Nextel和Motoral开发的DirectConnect协议为基础 使用标准的VoIP技术 8 Motorola Motorola将为Qchat在CDMA2000系列网上使用提供综合基础设施解决方案 并针对CDMA2000网的快速呼叫建立 移动性管理以及与Qchat与Nextel的DirectConnect业务互操作开发专门的增强功能 9 高通公司 高通公司基于BREW平台上建立Qchat服务器 客户机软件系统 该技术设计成由用户对小组成员动态管理 即用户可以随时在自己手机上删除或添加谈话参与者 除了管理者可以建立固定成员组 常设组 用户自己也可以临时创建谈话组 10 PTT进一步发展存在的问题 进一步发展存在的问题首先存在技术上的挑战 从技术上讲 Push To Talk一直引以为豪的 即时性 在现有公众移动网上实际实现起来难度不小 对CDMA和GSM网运营商而言 降低呼叫建立时延的挑战首先在于手机每6到10秒才检测是否有来话 其次 呼叫过程中的时延是分组话音的致命弱点 平均来说其PTT解决方案面临着围绕呼叫和呼叫建立的3到10秒延迟的技术挑战 11 PTT进一步发展存在的问题 此外 由于Push To Talk是建立在分组数据网络之上的VoIP 语音质量 QoS 等问题也是该业务要推广必须要面对的一个问题 需要采取一些QoS保障技术 12 PTT进一步发展存在的问题 其次 Pushtotalk面临市场上的挑战 除了行业用户市场直接面临集群系统的挑战 本身产业支持程度 以及产业链能否完整 也决定了最终Pushtotalk在市场上成功与否 比如可供选择手持终端的多样性 13 高通公司QChat业务 QChat是美国高通公司QIS QualcommInternetServices 部门开发的通过CDMA1X分组域提供集群通信的一种技术 QChat基于VoIP提供点到点 点到多点的半双工通信服务 其业务有 1 直接呼叫 类似于两人对讲 2 组呼叫 3 聊天 14 QChat需要满足的基本要求 QChat系统需要满足以下3个基本要求 1 瞬时接入 通过PTT按钮 在较短时间之内建立呼叫 Motorola的iDEN系统可以实现在1秒内接通 2 永远在线3 通话保证 GuaranteedTalkPermit 保证至少有一个目标听众在参与通信 否则通话发起失败 15 QChat呼叫建立类型 QChat呼叫建立有2种类型 动态的 Ad hoc 特别 静态的 Predefined Ad hoc 主叫选择了一个或多个用户做被叫 主叫选择了两个或多个预定义组 Predefinedgroups 做被叫 主叫选择了前两种情况的联合做被叫 Predefined 主叫选择了一个预定义组做被叫 16 QChat呼叫中目标加入会话的模式 QChat呼叫建立中目标加入会话的2种模式主动模式 组定义中的每个用户都需要显式 explicit 决定是否参加该QChat呼叫 被动模式 组定义中的每个用户不需要任何用户的操作动作 只是被通知已加入该QChat呼叫 17 QCHAT协议结构 与CDMA1X基本无关 18 华为QChat解决方案 我公司自己开发的解决方案考虑 自己开发从网络侧来看是可行的 1 终端方面合作OEM或购买 自行开发需论证 2 QChat服务器方案 智能的U NICA MRS解决 3 1X承载设备可以考虑分组域 或电路域 考虑QOS 待讨论 19 需要CDMA1X支持的内容 主要解决快速接入和一直在线特性DCCH信道REACH信道SDB ShortDataBurst 功能支持数据头压缩 PPP PDSN要求PCF以SDB方式发送快速呼叫建立 在分组休眠期到激活态转变情况 需要较高的QOS支持 20 Qchat应用服务器需要考虑的特性 为实现Qchat业务 Qchat应用服务器需要考虑的特性 考虑QSP建立QChat呼叫 为高通专有SIP协议完成Qchat终端的注册需要MCU完成组呼VOIP语音的复制广播功能 考虑组播技术 单工特性 Qchat业务是一个数据呼叫 空中资源可以单向DCCH完成 调度服务器与PDSN之间的IP包有一个特殊的需求 VP2功能 考虑支持Qchat呼叫与电路域呼叫并发的情况 明年芯片考虑支持 其他集群相关的功能 保密 限定时间通信 优先级别定义抢占等 21 我们系统支持PTT面临的挑战 空口 支持版本7的手机A口 支持IOS4 2ABIS口 要做修改BSC BTS支持多个新的信道改变流程 让接入控制在1 2秒以内业务信道支持DCCH影响呼叫和切换不走MSC下寻呼要实现VLR的功能话统要为QCHAT单独修改 22 返回处理 返回主目录 23 2PCF部分的修改 支持快速接入 PDSN要求PCF以SDB方式发送快速呼叫建立 在分组休眠期到激活态转变情况 主要内容包括 QChat呼叫信令高通建议处理方式QChatSDB在PCF的处理流程QchatSDB在SPU板的处理流程PCF要实现的具体需求 解码 流控 保存时隙信息 24 QChat呼叫信令 QChat呼叫信令的具体内容BSC PCF看不见也不用关心 BSC PCF的任务就是发送和接收封装有QChat呼叫信令的SDB 我们现有的系统已经支持了SDB流程 但是QChat业务对SDB的要求比一般的SDB要高 所以需要对现有的流程进行优化 25 高通建议不使用MSC下发SDB 因为高通Qchat文档参考协议都是CDMA2000ReleaseA 所以以下描述中的终端协议版本默认为7 高通建议 为了缩短SDB发送时间 不使用MSC下发ADDSPAGE的方式 由BSC直接将SDB发给手机 对现有流程需要作如下优化 26 QChatSDB在PCF的处理流程 QChatSDB在PCF的处理流程QChat服务器为了能保证数据包能以SDB的方式迅速的发给终端 利用数据包的IP层的TOS字段的保留位最后1个bit来进行标识 参见 1 80 D1527 1Rev A P5 4 如果该bit为 1 那么该数据包一定要以SDB的方式进行发送 27 BPU解析数据包识别Qchat业务 PCF要识别出Qchat业务特殊的数据包 将数据包作为SDB发给BSC 并通知BSC该SDB是Qchat业务的SDBa 当BPU板收到PDSN送来的数据包后 如果该PPP连接处于Dormant态 解析该数据包 一直解到IP层 从IP层中的TOS字段中取出保留位 判断是否为强制使用SDB的数据包 具体解数据包的算法在高通QChat文档 参见 1 中有详细描述 这里不再赘述 28 BPU PCU处理 b BPU板在发给PCU板的PktInd消息中指明该数据包是否要强制作为SDB进行发送 c PCU板在发给BSC的SPU板的消息A9SDD中通过消息中ADDSUserPart的保留位向BSC表明该SDB需要强制在FCCCH上发送 29 QchatSDB在SPU板的处理流程 Qchat终端终结的SDB流程要求PIM模块给所有SPU板发送A9SDD消息 SPU板收到A9SDDAck消息后不能马上给PCF回A9SDDAck 如果马上回响应 PCF会收到多条A9SDDAck 为了避免这种情况 SPU板只有收到终端对DBM的应答消息之后给PCF回A9SDDAck 再紧接着发A9UpdateA8 30 PCF要实现的具体需求 PCF处理下行SDB时需要增加对数据的解码 PCF主要工作量都在这里需要对PKT IND消息进行流控处理 PCF上需要对时隙信息进行保存新增参数配置 PCF代替VLR的部分功能 但第一个版本实现时没有存位置区小区信息 实现过于复杂 每次呼叫 登记 切换都要更新 31 目前PCF上对SDB的处理流程 目前PCF上对SDB的处理流程大致是 发送数据时 对处于休眠态且缓存有数据的用户 BPU统计用户缓存数据长度 通过MSG BPU PCU PKT ARR IND消息发送给PCU 消息中带有缓存数据长度 PCU收到MSG BPU PCU PKT ARR IND 判断消息携带的 缓存数据长度 长度小于等于L PCU上设定值 将采用SDB发送数据 并发送MSG PCU BPU PKT ARV RSP给BPU 消息中带原因值 PCU PKT ARV RSP MODE SDB 建议使用SDB发送数据 32 目前PCF上对SDB的处理流程 BPU收到PCU发送的带原因值 PCU PKT ARV RSP MODE SDB 的MSG PCU BPU PKT ARV RSP消息 将对应用户缓存的第一个数据包放入MSG BPU PCU PKT IND消息发送给PCU PCU收到MSG BPU PCU PKT IND消息 取出数据通过A9 ShortDataDelivery消息发送给PIMPIM收到PCU的A9 ShortDataDelivery消息 选择一个SPU并转发该消息 33 修改PCF上对SDB的处理流程 PCF对SDB处理需要做如下方面改动 增加对IP数据解码 QChat服务器为了能保证数据包能以SDB的方式迅速的发给终端 利用数据包的IP层的TOS字段的保留位最后1个bit来进行标识 参见80 D1527 1Rev A P5 4 如果该bit为 1 而且缓存长度小于设定的上限值X 暂时定为255 那么该数据包一定要以SDB的方式进行发送 34 修改PCF上对SDB的处理流程 为简化流程 节约处理时间 对TOS置位的特殊数据SDB处理中 不发送MSG BPU PCU PKT ARR IND 直接发送MSG BPU PCU PKT IND消息 并在消息中指明该数据需要用SDB方式发送 PCU收到指明需要用SDB方式发送的MSG BPU PCU PKT IND消息 取出数据通过A9 ShortDataDelivery消息发送给SPU 并在消息中携带强制发送的数据标记和时隙信息 PIIM收到强制发送A9 ShortDataDelivery消息 将把A9 ShortDataDelivery消息转发给所有的SPU 35 PCF保存SLOT CYCLE INDEX 终端终结的SDB流程中 BSC将不通过MSC而直接向终端下寻呼 但是现有系统中BSC不保存终端的SLOT CYCLE INDEX 需要对协议版本7终端作特殊处理 在PCF上保留用户的时隙信息 SPU将在A9SETUPA8的消息携带时隙信息 PCU收到A9SETUPA8的消息 需要保存时隙信息 在发送强制SDB数据时使用 36 PCF保存SLOT CYCLE INDEX PCU需要在连接控制表结构CONN CTRL BLK STRU定义中最后增加一项ucSlotCycleIndex 用于记录时隙信息 PCU收到A9SETUPA8消息后 解码出时隙信息 将时隙信息保存到用户对应连接控制记录下的ucSlotCycleIndex里面 用户释放到空态时 时隙信息随用户连接控制记录一起释放 在该连接进入稳态时 备份ucSlotCycleIndex内容 37 PCF流控 在流控特性设计中 要求PCU上对SDB进行流控 根据以前关于SDB处理的设计 PCU只需要对MSG BPU PCU PKT ARR IND消息进行流控就实现了对SDB的流控 在本需求中 参见需求QChat R FUN PCF 001 SDB设计方案已经变动 原来只对MSG BPU PCU PKT ARR IND消息流控的方案已经不能完全满足流控SDB 需要新增对MSG BPU PCU PKT IND消息进行流控 38 返回按钮 返回主目录 39 3RRM部分的修改 修改说明 为提高接入速度 支持不连续的DTX帧 必须支持新的共用信道和专用信道 导致信道管理 资源管理 功控几个部分都有修改 切换本来也会涉及 为避免判决过于复杂 暂不考虑新老基站中间的切换保护 这点由数据配置来保证 修改主要内容 DCCH的信道参数分配DCCH的前反向功控Qchat新增信道的动态配置 40 RRM模块结构 41 DCCH的信道参数分配 DCCH的信道参数分配在CDMA2000协议中 新增了专有信道DCCH 它可以用于传输用户数据和信令 不能传输语音 它与IS95中的专有信道FCH相比 最大的区别在于支持不连续传输 简称DTX 对于数据业务来说 使用DTX方式 有助于减少空口的干扰 提高系统容量 对于Inquam项目 明确要求我司系统必须支持DCCH 42 与DCCH相关的信道参数分配方法 重点是与DCCH相关的信道参数分配方法 确定分配DCCH的时机确定DCCH信道的无线参数对Qchat业务限制SCH的分配 数据业务使用DCCH SCH也是可以的 但在QCHAT方案中没有考虑 仅对QCHAT业务分DCCH 且可以用软参关掉 以后需要测试数据业务DCCH SCH的情况 43 DCCH信道分配输入 1 MSG CCM RRM CRB REQCC REQ CHN INFO STRU 新增接入信道类型 ACH EACH 这样做并不合适 版本7手机也是可以从PCH ACH上来的 并不降版本使用 同样支持QCHAT业务 不能以EACH作为判定标准 2 MSG CCM RRM HHO CRB REQCC IS2000 CHN ID STRU 含有源侧的信道类型 接口不变 44 DCCH信道分配输入 3 MSG CCM RRM TCH REQCC IS2000 SRV CFG REC STRU 含分配的信道类型 接口不变 4 MSG SHM RRM TCH REQCC IS2000 SRV CFG REC STRU 含分配的信道类型 接口不变 45 分配DCCH软参开关 5 分配DCCH软参开关相关内容 RRM DB SOFT WHEN ORG DCCH SW 当始呼时分配DCCH的软参开关 缺省关RRM DB SOFT WHEN HHO DCCH SW 当硬切换时分配DCCH的软参开关 缺省关RRM DB SOFT ALLOW QCHAT ASS SCH SW 是否允许QCHAT分配SCH 缺省关 46 始呼时确定分配DCCH的策略 始呼时确定分配DCCH的策略在确定是否分配DCCH时 主要考虑以下因素 业务类型 DCCH只能够传输数据 不能够传语音 所以仅仅对SO为33的数据业务呼叫 才允许分配DCCH 手机版本 DCCH是1X的新增信道 只有版本6或版本6以上手机才支持 所以仅仅对版本大于等于6的手机 才允许分配DCCH 但是考虑到QCHAT业务的手机都是版本7的 因此将条件加强为 仅仅对版本大于等于7的手机 才允许分配DCCH 47 始呼时确定分配DCCH的策略 手机DCCH支持能力 手机在始呼消息中携带有以下DCCH支持能力字段 DCCH SUPPORTED 表示是否支持DCCH DCCH FRAME SIZE 表示支持的DCCH的帧长度 FOR DCCH RC MAP 表示支持的前向RC的集合 REV DCCH RC MAP 表示支持的反向RC的集合 仅当DCCH SUPPORTED为1 而且DCCH FRAME SIZE支持20ms帧 前向支持RC3或者RC4 反向支持RC4 以上条件同时成立 才允许分配DCCH 接入信道类型 接入信道包括ACH和EACH 本身DCCH的分配与接入信道无关 但是考虑到QCHAT业务的手机都是从EACH上接入的 因此将条件加强为 仅仅对从EACH上接入的呼叫 才允许分配DCCH 有问题 48 始呼时确定分配DCCH的策略 始呼时分配DCCH的软参开关 仅当软参RRM DB SOFT WHEN ORG DCCH SW为开时 才允许分配DCCH 仅当以上5个条件同时成立 才确定该呼叫的信道类型为DCCH 49 硬切换时确定分配DCCH的策略 硬切换时确定分配DCCH的策略在确定是否分配DCCH时 主要考虑以下因素 硬切换源侧正在使用的信道类型 判断源侧携带的CC IS2000 CHN ID STRU中的ucChnType字段 仅当源侧正在使用DCCH 才允许分配DCCH 分配DCCH软参开关 仅当软参RRM DB SOFT WHEN HHO DCCH SW为开时 才允许分配DCCH 仅当以上2个条件同时成立 才确定该呼叫的信道类型为DCCH 50 DCCH的其它信道参数分配 DCCH的其它信道参数分配对于帧长 目前版本只是支持20ms帧 故直接写死为20ms即可 对于前向RC 分配方法同FCH对于反向RC 分配方法同FCHCOCRB在分配walsh码时 目前版本也已经考虑到了DCCH信道存在的情况 51 目前版本中其它涉及信道的地方 目前版本中其它涉及信道类型的地方当CRB确定信道类型为DCCH时 应当在CRB保存呼叫的信道类型为DCCH 目前版本 函数CHM FillCrbInfo将bit1DcchExist写死为0 需要修改 在处理HHO CRB REQ过程中 函数CHM DealCcmRrmHhoCrbReq中也存在没有考虑源侧信道类型为DCCH的地方 需要相应修改 52 目前版本中其它涉及信道的地方 在处理TCH REQ消息时 函数CHM CoCrbAssignFchPara中也存在没有考虑源侧信道类型为DCCH的地方 需要相应修改 53 QCHAT业务不分配SCH 根据高通对QCHAT的guideline文件 不要求对QCHAT业务分配SCH 为此 我们设置软参RRM DB SOFT ALLOW QCHAT ASS SCH SW 表示是否允许对QCHAT呼叫分配SCH 无论是否这个QCHAT呼叫分配了FCH还是DCCH 都这样判断 54 QCHAT业务暂定判别标准 但是目前BSC还没有准确的办法用于区分某数据业务呼叫是否是QCHAT呼叫 暂定办法如下 SO为33 版本为7 接入信道类型为EACH 55 DCCH的功控 在处理CCM RRM CRB REQ消息时 如果判断呼叫为QCHAT而且软参禁止分配SCH 则 RRM的信道子模块在整个呼叫过程中将禁止分配SCH 并不再像普通数据呼叫一样要求手机周期性的上报PMRM消息 以减少对业务的影响 并且设置前向快速功控的FPC MODE为0 表示功控速率800Hz s 目前对于普通数据业务设置为1 表示FCH和SCH各400Hz s 56 DCCH的前反向功控 DCCH的前反向功控DCCH信道的最大特征在于支持DTX 当没有数据传输时 空口将不再发射数据 功控仍然维持 前反向功控子信道都保持全速率发射 不采取门控方式 PILOT GATING USE RATEs 0 57 DCCH的前反向功控 对于前向 仍然可以采取前向快速功控 简单起见 不采取QIB功控 对于反向 仍然采取反向外环功控 但是这时反向将有三种类型的帧 好帧 坏帧 DTX帧 因此需要新增对DTX帧的处理 下面重点分析使用DCCH时的前反向功控方法 它包括 DCCH上的前向快速功控DCCH上的反向闭环功控新增DCCH后 FMR上功控模块其它处理 58 DCCH的功控配置参数 1 DCCH的功控配置参数 与以前保持不变 来源 DBAPI 相关内容 前向快速功控参数表 已经包含DCCH的功控参数 反向闭环功控参数表 已经包含DCCH的功控参数 目标FER表 已经包含DCCH的目标FER 59 DCCH上的Abis反向业务帧 2 DCCH上的Abis反向业务帧来源 BTS 相关内容 功控参数 与FCH反向帧中的功控参数相同 帧类型 新增了DTX帧类型 60 DCCH上的前向快速功控 DCCH上的前向快速功控与FCH上的前向快速功控 它们原理相同 手机根据收到的每个帧的质量 调整目标EbNt的大小 对于FCH来说 帧可以分为好帧和坏帧 对于DCCH来说 多了一个DTX帧 手机在收到DTX帧时 保持目标EbNt不变 在收到坏帧时 提高0 5dB 在收到好帧时 根据目标FER的大小 下降一个固定的步长 61 DCCH上的前向快速功控 手机比较实际EbNt和目标EbNt 命令BTS调整功率 由于手机是根据测量前向功控子信道的EbNt来估算整个前向业务信道的EbNt的 因此不论是否DTX 只要前向功控子信道存在 估算出的前向业务信道的EbNt都是一样的 62 DCCH上的前向快速功控 对于BSC来说 只是需要将前向快速功控的参数 分别传递给手机和BTS即可 分析目前版本 已经在DB表格中配置了DCCH的参数 而且也已经通过CRB CNF或者HHO CRB CNF消息 将这些参数携带给了CCM 只是需要CCM将DCCH的前向EbNt参数传给手机即可 考虑到QCHAT呼叫限制分配SCH 所以如果QCHAT呼叫已经被限制分配SCH后 需要将FPC MODE设置为0 63 64 DCCH上的反向闭环功控 DCCH上的反向闭环功控与FCH上的反向闭环功控 它们原理相同 BTS检测每个反向帧的质量 并将其上报给BSC 对于DCCH 存在DTX帧类型 65 DCCH上的反向闭环功控 BSC根据每个反向帧的质量 调整反向的目标EbNt的大小 并将其传递给BTS 对于DCCH 需要考虑对DTX帧的处理 BTS比较实际EbNt和目标EbNt 命令手机调整功率 无论前向信道是否处于DTX方式下 BTS都必须照常进行反向内环的800Hz的功率调整 66 DCCH上的反向闭环功控 对于BSC来说 需要将反向闭环功控的参数 从SPU传递到给FMR和BTS 分析目前版本 已经在DB表格中配置了DCCH的参数 而且也已经通过CRB CNF或者HHO CRB CNF消息 将这些参数携带给了CCM 只是需要CCM将这些参数分别传递给FMR和BTS即可 对于FMR板上的功控模块 也需要对收到的反向DCCH业务帧进行处理 67 68 目前FCH上的反向外环功控算法 目前FCH上的反向外环功控算法 收到一个坏帧 将目标EbNt提高Step up 连续收到PWR CTRL FREQ个好帧 将目标EbNt降低Step down 69 DCCH上的反向外环功控算法 在FCH反向外环功控算法的基础上 增加对DTX帧的处理 当收到DTX帧时 保持目标EbNt不变 直接退出处理 收到一个坏帧 将目标EbNt提高Step up 连续收到PWR CTRL FREQ个好帧 将目标EbNt降低Step down 这里 连续 的概念是 忽略DTX帧的存在 假定 连续收到下述帧 5个好帧 2个DTX帧 6个好帧 可以认为最终收到了连续11个好帧 70 FMR上功控模块处理 新增DCCH后 FMR上功控模块其它处理 DCCH上的链路状态报告 需要根据C03版本的新的链路状态报告的接口 向SPU报告链路信息 DCCH上的前向功率同步 与FCH的前向功率同步策略相同 对于反向Abis口的DTX帧 也需要和反向FCH上的好帧一样 携带相应的功率信息字段 对于前向Abis口的DTX帧 也需要和前向FCH上的普通业务帧一样 携带前向功率同步信息 71 Qchat新增公共信道的配置 Qchat新增公共信道的配置在系统开工时 如果某个载频配置有BCCH FCCCH 需要为其分配码资源 当对某个载频的新增BCCH FCCCH EACH进行以下操作 增删信道数目 修改信道参数 或者修改某个小区的新增开销消息的参数时 要对该小区进行重新配置 同时 还需要支持新增信道的开销消息更新 流程与以前相同 包括 BCCH FCCCH的码资源分配新增信道的动态配置 72 Qchat新增公共信道的配置 1 信道参数动态配置命令 在MSG CMF RRM DYNCFG IND消息中新增命令字 来源 CMF 相关内容 OM BAM ADD 2000ACCH REQ 增加2000A公共信道BCCH FCCCH EACHOM BAM RMV 2000ACCH REQ 删除2000A公共信道BCCH FCCCH EACHOM BAM MODI BCCH PARA REQ 修改BCCH参数OM BAM MODI FCCCH PARA REQ 修改FCCCH参数OM BAM MODI EACH PARA REQ 修改EACH参数 73 Qchat新增公共信道的配置 2 开销消息参数动态配置命令 在MSG CMF RRM DYNCFG IND消息中新增命令字 来源 OAM 相关内容 CMF BAM MODI A41SPM PARA REQ 修改AN41 SystemParasMessageCMF BAM MODI MCRRPM PARA REQ 修改MC RRParasMessageCMF BAM MODI EAPM PARA REQ 修改EnhancedAccessParasMessageCMF BAM MODI UNLM PARA REQ 修改UniversalNeighborListMessage 74 Qchat新增公共信道的配置 3 给CMF提供重新分配2000A信道码资源的接口RRM ReAssign2000AChanWalsh来源 CMF 相关内容 载频标识usPilotId BCCH的数目 以及每个BCCH的码速率BCCH CODE RATE FCCCH的数目 以及每个FCCCH的码速率FCCCH CODE RATE和FCCCH的数据速率FCCCH RATE 75 Qchat新增公共信道的配置 4 给SM提供获取2000A信道码资源的接口RRM Get2000AChanWalsh来源 CCM的SM子模块 相关内容 载频标识usPilotId 76 Qchat新增公共信道的配置 BCCH FCCCH的码资源分配 与目前版本的现有开销信道的码资源分配策略不同 现有开销信道的walsh码在协议中都是定义好了的 比如 同步信道的walsh为31 导频信道的walsh为0 而BCCH FCCCH的walsh在协议中没有明确定义 所以需要由BSC动态分配 BSC动态分配BCCH FCCCH的walsh后 再将walsh通知到BTS和手机 77 78 Qchat新增公共信道的配置 BCCH的Walsh码长与 BCCH的码速率BCCH CODE RATE 有关 如下 79 Qchat新增公共信道的配置 FCCCH的Walsh码长与 FCCCH的码速率FCCCH CODE RATE和FCCCH的数据速率FCCCH RATE 同时有关 如下 80 Qchat新增公共信道的配置 当CMF调用RRM提供的接口函数RRM ReAssign2000AChanWalsh时 RRM主要处理步骤如下 RRM判断g pRrmPltResTable 该结构用于存储各个开销信道的walsh分配情况 中 是否已经存在2000A信道 如果已经存在2000A信道 强制释放所有2000A信道的码资源 81 Qchat新增公共信道的配置 判断输入参数中的BCCH和FCCCH信道数目是否为0 如果是 直接返回成功 分别对于输入中的每个BCCH和FCCH 根据其码速率和数据速率 依据上述表格中的walsh码长选取方法 调用码资源分配函数 得到每个信道的walsh 并将记录到g pRrmPltResTable中 如果存在有的信道分配walsh码失败 返回失败 返回成功 82 Qchat新增公共信道的配置 对于涉及信道的参数的动态配置 比如增删信道 改变信道的功率增益等 流程与以前版本的载频重配置流程完全相同 对于普通开销消息的参数改变 如果不涉及到BTS配置参数的改变 就不需要执行扇区载频重配置流程 这时OAM直接向RRM发送动态配置命令OM RRM CMD RRM向CCM发送开销消息更新指示 流程与以前相同 83 84 返回处理 返回主菜单 85 4FMR部分的修改 因新增DCCH信道 FMR要增加相应的处理 主要内容如下 FMR创建 释放DCCH信道FMR增加 删除DCCH分支FMRDCCH分集合并 信令和数据处理FMRDCCH可测试性FMR新增动态配置数据FMR新增外部接口 86 FMR创建 释放DCCH信道 FMR创建 释放DCCH信道FMR接收SPU的CCM SDU TCH SETUP REQ消息 如果消息中信道类型为DCCH 创建DCCH信道 或增加DCCH分支 FMR接收SPU的CCM SDU TCH RELEASE REQ消息 如果消息中信道类型为DCCH 释放DCCH信道 或删除DCCH分支 87 FMR创建DCCH信道 FMR创建DCCH信道流程与创建FCH信道一样 FMR的RMM SCM MUX LAC SAR RLP模块都已经支持创建DCCH 保持不变 FP MDC模块创建实例 增加对DCCH的处理 初始化FP MDC实例中DCCH参数 88 FMR创建DCCH信道 FMR与BTS之间的DCCHIDLE帧交互 FP MDC创建使用DCCH的实例后 向BTS发送DCCHIDLE帧 如果FP MDC在规定时间内收到BTS的DCCHIDLE帧 FMR向SPU发送SDU CCM TCH SETUP CNF 消息中cause 0 DCCH信道创建成功 如果FP MDC在规定时间内没有收到BTS的DCCHIDLE帧 FMR向SPU发送SDU CCM TCH SETUP CNF 消息中cause 3 DCCH信道创建失败 89 FMR释放DCCH信道 FMR释放DCCH信道流程与释放FCH信道一样 FMR的RMM SCM MUX LAC SAR RLP模块都已经支持释放DCCH 保持不变 FP MDC模块释放实例 增加对DCCH的处理 清空FP MDC实例中DCCH参数 90 FMR增加DCCH分支 FMR增加DCCH分支流程与增加FCH分支一样 FMR的RMM SCM模块都已经支持创建DCCH 保持不变 FP MDC模块创建DCCH分支 增加对DCCH的处理 初始化FP MDC实例中DCCH新增分支的参数 91 FMR增加DCCH分支 FMR与BTS之间的DCCHIDLE帧交互 FP MDC创建新的DCCH分支后 向BTS发送DCCHIDLE帧 如果FP MDC在规定时间内收到BTS的DCCHIDLE帧 FMR向SPU发送SDU CCM TCH SETUP CNF 消息中cause 0 DCCH分支增加成功 如果FP MDC在规定时间内没有收到BTS的DCCHIDLE帧 FMR向SPU发送SDU CCM TCH SETUP CNF 消息中cause 3 DCCH分支增加失败 92 FMR删除DCCH分支 FMR删除DCCH分支流程与删除FCH分支一样 FMR的RMM SCM模块都已经支持删除DCCH分支 保持不变 FP MDC模块释放分支 增加对DCCH的处理 清空FP MDC实例中DCCH某个分支的参数 93 FMRDCCH帧处理 分集合并 FMRDCCH帧处理 分集合并FMR的FP MDC模块处理DCCH帧 DCCH软切换分支的分集合并 94 DCCH反向帧处理 DCCH反向帧处理DCCH路径时延调整与FCH作同样处理 从反向帧中取出PATE值 计算分支的发送相位 取路径时延最大的分支的发送相位作为DCCH信道的发送相位 DCCH分支合并与FCH作同样处理 启动一个分支合并定时器 定时器长度与FCH分支合并定时器相同 比较DCCH各分支FSN相同的帧 帧选择顺序 优先级从高到底 为 TRAFFIC帧 ERASURE帧 DTX帧 IDLE帧 TRAFFIC帧之间根据反向帧质量选择 如果分支合并定时器超时 处理当前收到的最好帧 95 DCCH反向帧处理 IDLE帧 收到第一个IDLE帧表示BTS与FMR之间的地面电路建立成功 如果连续收到的IDLE帧 软切换合并之后 超过一定门限 说明DCCH反向信道无法扑获 向SPU上报SDU CCM TCH ERROR IND 消息中cause 4 DTX NULL 帧 FMR板每收到一定数量的帧 就进行如下检查 如果收到的DTX帧 软切换合并之后 所占的百分比超过一定门限 这时终端可能已经掉话 向SPU上报SDU CCM TCH ERROR IND 消息中cause 13 新增 请求CCM对手机发起核查 96 DCCH反向帧处理 TRAFFIC帧 取出其中的数据交给MUX模块处理 ERASURE帧 FMR板每收到一定数量的帧 就进行如下检查 如果收到的ERASURE帧 软切换合并之后 所占的百分比超过一定门限 说明反向信道质量很差 向SPU上报SDU CCM TCH ERROR IND 消息中cause 5 97 DCCH反向帧处理 新增功控字段处理 取出DCCH反向TRAFFIC ERASURE DTX帧携带的功控字段 交给FMRPWR模块处理函数处理 异常情况 如果某个分支在FMR与BTS之间IDLE帧交互完毕之后 在规定时间内没有收到任何帧 向SPU上报SDU CCM TCH ERROR IND 消息中cause 2 98 DCCH前向帧处理 DCCH前向帧处理分发 向信道下所有分支发送前向帧 如果分支之间的时延差超过5ms 先向路径时延最长的分支发帧 然后根据分支之间的时延差对其他分支开启发送定时器 定时器超时再发送 IDLE帧 分支刚建立 还没有收到BTS的反向帧之前发送前向IDLE帧 99 DCCH前向帧处理 DTX NULL 帧 如果无业务数据 发送前向DTX帧 TRAFFIC帧 如果有数据业务 发送前向TRAFFIC帧 新增功控字段处理 从FMRPWR获取功控信息 填入DCCH前向TRAFFIC DTX帧携带的功控字段 100 FMR在DCCH上发送L3信令 数据 FMR在DCCH信道上发送L3信令 数据FMR板在DCCH信道上发送SPU板发来的L3信令 发送PPU板送来的数据业务数据 SPU发给FMR的LAC SDU DATA REQ消息 PPU发给FMR的PPM SDU DATA REQ消息 101 FMR在DCCH上发送L3信令 数据 L3信令处理 MUX模块在数据业务选项SO33情况下判断DCCH是否存在 如果存在 就在DCCH发送L3信令 并且停止发送数据 等当前的L3信令发送完毕之后再重新开始发送数据 数据业务数据处理 MUX模块在数据业务选项SO33情况下判断DCCH是否存在 如果存在 MUX指示RLP在DCCH上发送数据 102 FMR在DCCH上发送L3信令 数据 RLP在DCCH上接收和发送数据的处理和在FCH上完全一样 在没有数据时的处理有些不一样 RLP判断如果是在DCCH上发送数据 那么在没有数据的情况下不组RLP帧 RLP在发送给MUX模块的RLP MUX DATA REQ消息中的数据块个数ucBlockNum填0 MUX模块如果收到数据块个数ucBlockNum为0的RLP MUX DATA REQ消息 在发送给FP MDC模块的MUX MDC DATA REQ消息中的帧长度usLen填0 指示FP MDC模块向BTS发送DTX帧 103 FMR在DCCH上发送L3信令 数据 输出 FMR发给BTS的DCCH前向帧 Abis IS2000 DCCHFwd 帧中包含L3信令或数据业务数据 104 FMRDCCH可测试性 FMRDCCH可测试性1 打开DCCH前向时延调整信息2 关闭DCCH前向时延调整信息3 打开DCCH反向时延调整信息4 关闭DCCH反向时延调整信息5 打开DCCH前向帧内容信息 105 FMRDCCH可测试性 6 关闭DCCH前向帧内容信息7 打开DCCH反向帧内容信息8 关闭DCCH反向帧内容信息9 打开解析FP信令功能10 关闭解析FP信令功能 106 FMR新增动态配置数据 FMR新增动态配置数据在已有FMR的FP MDC动态配置数据中包括下列几个参数 检查ERASURE帧比率 检查ERASURE帧门限 检查IDLE帧门限 等待IDLE帧计数器 这些参数都是针对FCH的设置的 需要增加针对DCCH的参数 以前的参数需要改名 107 FMR新增外部接口 FMR与BTS接口IS2000DCCHFwdIS2000DCCHRev 108 返回处理 返回主菜单 109 5CCM部分修改 主要介绍实现Qchat业务在CCM模块所需要完成的功能 下面主要描述CCM对Qchat业务的支持所需的功能 110 CCM支持Qchat业务所需的功能 快速建立业务信道呼叫建立流程支持DCCH信道软切换建立分支流程支持DCCH信道硬切换流程支持DCCH信道CCM模块支持协议版本7QchatClient在BSC中的移动性管理 111 CCM支持Qchat业务所需的功能 QchatClient终结的SDBQchatClient发起的SDBQchat业务消息的流量控制F CSCH消息在BTS的重发和生存期控制IS2000ReleaseA小区建立IS2000ReleaseA小区重配置IS2000ReleaseA总体消息更新 112 Qchat业务的假设和依赖关系 Qchat业务的假设和依赖关系1 本版本Qchat业务只支持BSC内的软切换支持BSC内的软切换是指切换的目标侧和源侧都是在本BSC内 2 容量由于在处理QAS发送给QchatClient的SDB时 需要先将SDB缓存在BSC 在本版本中每块SPU板暂时设计为能同时缓存的SDB个数为2000个 113 Qchat业务的假设和依赖关系 3 协议a Qchat业务基于CDMA20001X分组域 b 空口协议版本基于CDMA2000ReleaseA c QchatClient协议版本默认为7 d A口协议IOS4 1 注意 当QchatClient做被叫时 A口协议需要支持IOS4 2 否则不会从FCCCH上下寻呼 114 Qchat业务的假设和依赖关系 4 业务选项QchatClient需要支持业务选项为0 x8026的寻呼 5 BSC内寻呼在目前的版本中 在给QchatClient发送SDB时 对QchatClient定位是采用整个BSC内进行寻呼 故寻呼量比较大 6 信道空口的公共控制信道必须支持EACH FCCH BCCH信道 可能不一定 115 CCM1 快速建立业务信道 快速建立业务信道 116 CCM1 快速建立业务信道 对于Qchat业务 是在R003C02版本基础之上实现的 快速建立业务信道功能是通过对呼叫建立的接入试探阶段 等信道指配阶段 确定业务配置阶段的优化来实现的 接入试探阶段的优化 采用在EACH信道发送OriginationMessage消息 在F CCCH上给手机回BaseStationAcknowledgmentOrder消息 117 CCM1 快速建立业务信道 在BTS实现对反向公共信道的需要应答的消息进行层二应答 给手机回BaseStationAcknowledgmentOrder消息 BTS发送层2应答使用消息序号为7 BSC发送其它前向公用信道消息时只能使用消息序号0 6 118 CCM1 快速建立业务信道 等信道指配阶段的优化 BSC在分配BSS资源时 将BSC等MSC下发指配请求与分配BSS地面资源和空口资源并行处理 119 CCM1 快速建立业务信道 确定业务配置阶段的优化 业务协商是指数据业务的协商 主要协商SCH的参数配置 对于Qchat业务通过软参来控制是否与手机进行业务协商来实现否支持SCH信道 如果不进行协商 则在收到MSAcknowledgmentOrder后就直接给MS发送ServiceConnectMessage消息 120 CCM1 快速建立业务信道 是否走快速建立流程判别 CCM收到OriginationMessage后如果发现消息是来自EACH信道 而且MS协议版本为7时 首先判断业务选项 1 如果业务选项不为数据业务 0 x21 则CCM判定不是QChat业务 不走快速建立业务信道流程 2 如果业务选项为数据业务 0 x21 则CCM判定为Qchat业务 在CCB中置Qchat业务标志 处理流程按Qchat业务流程进行 121 CCM1 快速建立业务信道 对于Qchat业务 在发送完CMServiceRequest后 根据软参判断是否需要等待MSC的AssignmentRequest消息 如果不需要等待 默认值 则不用启动定时器等MSC下发AssignmentRequest 直接给RRM发送CCM RRM CRB REQ 在该消息中 新增接入信道类型字段通知RRM该业务是Qchat业务 并启动定时器等待RRM的RRM CCM CRB CNF消息 122 CCM1 快速建立业务信道 从等RRM的RRM CCM CRB CNF消息开始 到收到MS的ServiceConnectCompletionMessage之间的过程与其它数据业务大致相同 不同点为 在这期间 如收到MSG