iBSC_CS业务基本流程2.5.doc

CS业务基本流程GSM开发部 黄立伟1353471. CS语音业务流程CS语音电话电话是GSM系统CS业务的核心内容，在iBSC控制面中，该流程以RANCS模块为核心，其他有关的模块还有RANUMC、RANA、RANCONNECT、AbisDispatch、ADispatch、DBS等，其关系如下图所示。其中，DBS进行数据信息的管理，提供若干函数接口供各个业务进程调用；AbisDispatch进行Abis口消息的解码和转发、ADispatch进行A口消息的解码和转发，2者都只有1个主进程，不需要创建子进程（后文把子进程又称为实例）；RANUMC是RANCS实例的主进程，负责RANCS实例的创建和释放；用红色表示RANCONNECT负责CMM和TCU接续，为RANCS发来的每个接续请求建立一个实例；用紫色表示RANA负责SCCP链路的管理，为每条使用的SCCP链路建立一个实例，同时也是RANCS和A口之间消息传送的桥梁；用蓝色表示RANCS负责CS业务信令流程的控制，为每条使用的信道建立一个实例。一个普通CS电话业务过程需要先后使用2条信道，一条SDCCH，一条TCH，相应的需要建立2个实例，RANCS1(SD,用浅绿色表示)，RANCS2(TCH,用深绿色表示)。其中加灰色的部分描述了“模式更改”和“排队”这2种特殊的流程。RANCS状态分为2级，第1级只有3种状态：IDLE_PROC、WORK_PROC和WAITREL_PROC，实例刚创建是1级IDLE_PROC态，收到StartUp消息初始化后转入1级WORK_PROC态，在1级WORK_PROC态中根据处于流程中的不同位置又分为17个2级状态，下文中所有提到的状态都是1级WORK_PROC态中的2级状态。当实例完成释放动作，转入1级WAITREL_PROC态等待主进程RANUMC来释放1. 主叫手机发Channel Request,经BTS处理从Abis口上Chl Rqd消息，在AbisDispatch中进行解码后发给RANUMC进程。（注：如果手机是作为被叫，则MSC先通过寻呼模块发起寻呼，手机听到后发Channel Request，后面的流程与主叫一样）2. 【RANUMC】收到EV_ABIS_IND消息，取出消息头中的byMsgType一看是ABIS_CHL_RQD，于是从消息体中读取接入类别，如果是PS业务请求则创建RANPS实例，这里按下不表，如果是CS业务请求则创建RANCS实例，并向RANCS实例发送EV_RANUMC_CHL_RQD消息，该消息包括了Chl Rqd消息的内容、从OMP申请到的TraceID和TermID信息(含站点号，小区号，TRX号等)。3. 【RANCS1】实例创建后处于idle态(这里指的是1级WORK_PROC态下的2级idle态)，在idle态下收到EV_RANUMC_CHL_RQD消息，记录下初始接入信息，根据信道请求的原因，确定需要的信道类型，然后向数据库申请信道资源，若失败发立即指派拒绝，若成功发信道激活，启动定时器T9103，状态跃迁至Activate。4. 【RANCS1】BTS激活信道成功，则实例在Activate态会收到信道激活应答，杀掉定时器T9103，发立即指派消息，启动定时器T3101,状态跃迁至WaitAccess。5. 【RANCS1】MS发SABM帧，BTS给MS回UA帧并给BSC发Est Ind,实例在WaitAccess态收到Est Ind,杀掉定时器T3101，Est Ind消息中带了类别，具体类型有位置更新、IMSI分离、CM服务请求(主叫)、寻呼响应(被叫)、呼叫重建等。先根据类型进行性能测量统计和初始化切换算法处理，然后建立指示将转发给Rana主进程，启动定时器TWAITSCCPEST，状态跃迁至SccpEst。6. 【RANA主进程】(也称为Manager进程)收到EV_RANCS_EST_IND后，从空闲实例号队列中取得实例号创建子进程(也称为Worker进程)，向其转发EV_RANCS_EST_IND消息。7. 【RANA】实例刚创建处于IDLE态，在IDLE态收到EstInd消息 (在函数RanAWorkerWorkLeaf中处理)，记录Rancs实例的信息，确立对应关系，申请到SCCP连接后，通过ADispatch向MSC发ConnectReq(CR)消息，启动定时器T9105，状态跃迁至SCCPCONNECTING。8. 【RANA】MSC回ConnectConf(CC)，Rana实例收到后杀T9105，向自己对应的Rancs实例发EV_RANA_CONN_CONF消息，启动THANDSHAKE开始与Rancs实例的心跳握手，状态跃迁至SERVE。(注：进入Serve态后，除了发生切换、释放或异常需要作相应处理外，RANA实例主要充当MSC和Rancs实例之间消息的通道，只进行转发而不处理)9. 【RANCS1】在SccpEst态收到EV_RANA_CONN_CONF，说明通向A口的链路已建立，先杀掉定时器TWAITSCCPEST，初始化目标实例和源实例,记录Rana实例的Pid，如果有缓存消息则发往A口，开始与Rana实例的心跳握手，状态跃迁至Serve。10. 此时从手机到MSC的整条链路已经打通，手机和MSC之间会透传几条消息，主叫和被叫方略有不同，如下图主叫MS MSC MSC 被叫MS| - CM Service Accept- | | | -Set Up- | | -Set Up- | -Call Proceeding- | | -Call Confirm- |除了上述几条必要的透传消息外，根据MSC的设置，可能还会有鉴权、加密、Identification等过程，其中只有加密过程BSS需要参与。MS BTS BSC MSC11. 【RANCS1】如果MS和MSC信令交互顺利，MSC将发下来指配请求经Rana转发到Rancs，Rancs实例在Serve态收到该消息，先检查信道类型、数据速率/语音版本是否相配，然后检查地面电路的状态是否可用，检查发现有问题则向MSC回指配失败。12. 【RANCS1】如果检查顺利通过，判断当前的信道类型和指派消息的信道模式是否相配：(1)最常见的情况是不相配，则根据指配请求的信息组装一个EV_RANCS_RADIO_APPLY消息发往RANUMC,在本小区中请求新的信道，启动TRADIOAPPLY，状态跃迁至RadioApply。(2)模式更改如果相配，意味着原来申请SD的时候DBS分配的是FACCH，现在不必换信道，把信道模式从FACCH改为TCH就行了，于是则走模式更改流程，缓存AssignReq消息，确定新的语音版本，向RanConnect主进程发出2条消息请求进行Abis接续和BIU-TCU接续，启动TWAITCONN，状态跃迁至WaitConn。转1513. 【RANUMC】收到EV_RANCS_RADIO_APPLY，新建一个Rancs实例，将发来该消息的源Rancs实例Pid和TraceId填入消息体，以EV_RANUMC_RADIO_APPLY消息发给新建的Rancs实例。14. 【RANCS2】在idle态收到EV_RANUMC_RADIO_APPLY消息， 调RancsGetRadioApplyInfo从消息中提取出信息填入实例数据区，调用RancsDbGetRadioChannel函数申请无线信道。排队如果数据库返回说没有信道，且系统设置允许排队的话，则把实例号加入本小区的排队队列，状态跃迁至WaitResrc。若DBS将PS信道转为CS成功，则会发来消息EV_RANUMC_DBSCHL_AVAIL，实例重新向数据库发起申请；若其他Rancs实例释放信道，则实例会在WaitResrc态收到EV_RANCS_RESRC_AVAIL，回EV_RANCS_RESRC_AVAIL_ACK，占用消息中带来资源，接着按下面申请成功的情况一样处理。如果成功，再获取信道模式和语音版本。占用地面电路，从数据库查到接续信息，向RanConnect主进程发出2条消息请求进行Abis接续和BIU-TCU接续（该接续有时也简称为BIU接续或TCU接续），启动TWAITCONN，状态跃迁至WaitConn。15. 【RANCONNECT主进程】主进程收到接续请求，先创建子进程，然后将消息发给子进程处理。16. 【RANCONNECT】子进程在idle态若收到Abis接续请求，则向BTS的CMM发ABIS_CSCONN_CMM_REQ消息；若是BIU-TCU接续请求，则分别向BIU和TCU上的接续模块发EV_CSCHAN_INNER_CONNECT消息。根据接续类型的不同，启动相应的定时器，状态跃迁至work态。17. 【RANCONNECT】子进程在work态收到应答消息，先看一下本实例的接续类型，若是Abis接续，且收到的是SPS_ABIS_CSCONN_CMM_ACK，则发EV_RANCONN_CS_ABISCONN_ACK给Rancs实例；若类型是BIU/TCU接续且收到EV_CHAN_INNER_CONNECT_ACK，则根据消息来源将实例数据区中BIU/TCU连接标志置为TRUE，等2个连接标志都为TRUE，发EV_RANCONN_CS_TCUCONN_ACK给Rancs实例。向主进程发送实例释放消息等待被释放，RANCONNECT子进程的业务结束。18. 【RANCS2】在WaitConn态收到Abis接续Ack和TCU接续Ack两条消息后，杀TWAITCONN，如果不是模式更改则发信道激活消息，启动T9103，状态跃迁至Activate。模式更改如果是模式更改，则向CHP和MS发ChlModeModify消息，启动TMODEMODIFY，状态跃迁至ModeModify；在ModeModify态收到BTS和MS的应答后，更新信道模式，杀TMODEMODIFY，向Rana实例发EV_RANCS_ASS_COM，状态跃迁至Serve，转2819. 【RANCS2】BTS激活信道成功，则实例在Activate态会收到信道激活应答，杀掉定时器T9103，构造指派命令，包在EV_RANCS_RADIO_AVAIL消息中发给源实例，启动定时器TWaitMSAccess,状态跃迁至WaitAccess20. 【RANCS1】源实例发送EV_RANCS_RADIO_APPLY消息后一直在RadioApply态等着，现在收到RadioAvail消息后，杀掉TRADIOAPPLY，从消息中提取出指派命令，向Um口发送，启动T3107，状态跃迁至Assign。21. 【RANCS2】手机收到指派命令后在新信道上发SABM帧，BTS回UA帧并向新实例发Est Ind，新实例在WaitAccess态收到Est Ind，初始化切换算法，状态不转移。22. 【RANCS2】手机发指派完成，新实例在WaitAccess态收到UmAssignCom,杀掉TWaitMSAccess，将EV_RANCS_ASS_COM消息发给源实例，启动TNEWINSTCOMPACK，状态跃迁至Preserve23. 【RANCS1】源实例在Assign态收到EV_RANCS_ASS_COM，杀掉T3107，向Rana实例发EV_RANCS_ASS_COM，启动TOLDINSTCOMPACK，状态跃迁至HoGuard。24. 【RANA】实例在SERVE态收到EV_RANCS_ASS_COM，回EV_RANA_ASS_COM_ACK消息，把消息中带上来的Rancs新实例号覆盖掉自己原来保存的Rancs实例号，向MSC发A_ASSIGN_COM25. 【RANCS1】源实例在HoGuard态收到EV_RANA_ASS_COM_ACK，杀掉TOLDINSTCOMPACK，向新实例发EV_RANCS_ASSIGNCOM_ACK，其中带上了Rana的PID，然后清掉目标实例号和Rana实例号，开始释放。由于是SD信道，且手机已离开本信道，因此释放无线信道即可：向BTS发送DeactSACCH和RF_CHL_REL消息，启动TRFCHLREL，状态跃迁至RfChlRel。26. 【RANCS1】源实例在RfChlRel态收到RFChlRelAck，杀掉TRFCHLREL。释放数据库资源，向RANUMC发EV_RANCS_REL_IND，转入一级WAITREL态，RANUMC收到消息清除实例RANCS1。27. 【RANCS2】新实例在Preserve态收到EV_RANA_ASS_COM_ACK，将消息中带来的Rana实例的PID保存，杀掉TNEWINSTCOMPACK，状态跃迁至Serve。28. 接下来，MSC和手机之间将透传Altering、Connect、ConnectAck等消息，通话开始。主叫MS MSC 被叫MS(开始回铃音)| - Altering - | - Altering - |(开始振铃)| - Connect - | - Connect - |(接听)| - Connect Ack - | - Connect Ack - |29. 通话过程中，如果不发生切换或者什么异常，一般并不产生信令交互。主动挂断通话时首先透传Disconnect、Release、Release Complete等消息。然后MSC将向BSC发A_CLEAR_CMD。对于非主动挂断的一方，要看MSC的策略， MSC可以直接下发Disconnect,进行类似的流程，也可能MSC只是向其发送对方已挂机的语音提示，然后等待用户主动挂断。主动挂机的MS MSC | - Disconnect - | | - Release - | | - Release Complete - | 30. 【RANA】收到A_CLEAR_CMD后，向Rancs实例转发该消息。启动TWaitRancsCleCom，状态跃迁至WaitRancsCleCom31. 【RANCS2】实例收到A_CLEAR_CMD后，立即向Rana实例回EV_RANCS_CLEAR_COM，清除Rana实例号，开始释放流程。32. 【RANA】收到EV_RANCS_CLEAR_COM后，向MSC发A_CLEAR_COM消息。启动T9101，状态跃迁至SCCPRELEASING，T9101是用来延时保护的定时器，超时后向SCCP发送DISCONNECT REQUEST，然后向Rana主进程发EV_RANA_DEL_PROC，主进程收到后杀死Rana实例，Rana的业务结束33. 【RANCS2】释放流程开始后，先拆除Abis和Tcu接续(如果是半速率则不拆Abis), 释放地面电路。然后发向UM口发ChlRel消息，向BTS发Deactive SACCH,启动T3109, 状态跃迁至ChlRel34. 【RANCS2】MS发DISC帧，BTS给MS回UA帧并给BSC发Rel Ind,新实例在ChlRel态收到Rel Ind,杀掉定时器T3109,启动T3111。T3111是个延时保护定时器，超时后，新实例向Abis口发RfChlRel消息，启动TRFCHLREL，状态跃迁至RfChlRel35. 【RANCS2】新实例在RfChlRel态收到RFChlRelAck，如果此前未收到拆Abis接续的应答消息，则继续等待，否则杀掉TRFCHLREL，开始释放实例。检查一下是否有别的实例在排队等待资源，如果存在符合条件的则向其发EV_RANCS_RESRC_AVAIL消息带去信道资源，状态跃迁到Preempt态等待其应答；如果没有，则调数据库接口CS_RELRADIOCHANNEL释放资源。36. 【RANCS2】新实例在Preempt态收到EV_RANCS_RESRC_AVAIL_ACK或者调接口释放了资源，则清除定时器，向RANUMC发EV_RANCS_REL_IND消息，然后转入一级WAITREL态，RANUMC收到消息清除实例RANCS2，新实例的业务结束，整个电话流程也宣告结束。2. CS纯信令业务流程纯信令业务是本文作者对不使用TCH信道，而只使用SDCCH信道进行的业务的称谓。纯信令业务包括：短消息、位置更新、手机关机去附着等。在这些业务的过程中，BTS和BSC的作用只是提供一条从MS到MSC的信令通路，负责链路的建立和拆除。大致过程是：1. MS发起Channel Request申请SD信道2. BSC响应并为其分配一条SD信道，发立即指派消息3. MS接入SD信道，发上来建立指示，Rana建立一条A口的SCCP链路4. 此时贯穿Um、Abis、A三个口的链路已接通，MS和MSC之间使用这条链路透传DTAP消息，消息的内容由业务的类型决定，可能是短信内容，也可能是位置更新或手机的Detach5. 业务处理完毕，MSC通过A口下发Clear Cmd，BSC拆除链路，释放SDCCH信道，业务流程结束。具体的各模块创建实例以及状态跃迁的过程见语音业务流程中19步。3. CS切换流程简述所谓切换其实就是手机在已经占用一条专用信道(SD或TCH)的情况下换到别的信道上去。广义的切换应该包括了指配、定向重试和狭义的切换(包括小区内切换，小区间切换和跨BSC的外部切换)。我们平常说起的切换指的是狭义的切换。先说指配和定向重试吧。手机主动发起呼叫，先占用了一条SD信道，在建立指示的层三消息中向MSC发出CM Service Req，MSC将向BSC发指配请求，要求BSC为手机分配TCH信道。如果在SD信道所在同一个小区申请到TCH，则这个过程叫指配，如果本小区没有空闲TCH，向BSC内其他小区申请TCH，这个过程叫内部定向重试，如果向BSC外的小区申请，则叫外部定向重试。顺便提一句，我们经常会提到的指配和指派，在协议中其实是同一个词Assignment，具体用哪个看习惯了。再来说切换。切换的具体原因有很多，发起切换的主要依据是测量报告。当信道被激活后，BTS就会不断的发上来测量报告，其中包括了上下行电平、质量、TA以及各邻接小区的电平值。BSC收到测量报告后将这些报告作平均存起来，Rancs实例如果处于Serve态则会进行切换判决，也就是依据最近收到的测量报告，对各种切换原因挨个儿判断是否满足切换的条件，只要发现有满足条件的，则决定进行此类型的切换尝试。切换的过程和指配很相似，也是组装一个RadioApply消息发给RANUMC，RANUMC新建Rancs实例去申请新信道，后面的流程与CS电话流程中1327基本一致。不同的地方是向手机发出的消息可能是切换命令，而非指派命令，手机回切换完成。如果是外部切换，则更简单，判断需要切换，于是向MSC发去切换要求，然后等着MSC下来切换命令，如果手机成功切过去了，则MSC发Clear Cmd释放原信道。绝大多数的切换都是收到测量报告然后进行切换判决触发的，也有一些例外情况，如强切(高优先级用户需要信道，逼你切换走把信道让给他)，切换候选征询(MSC根据各小区资源使用情况让部分用户切换达到一个平衡)，人工切换(改全局变量制造切换，一般用于测试阶段)等。这里的叙述只能让你对切换有个大致的印象，要详细了解切换流程可结合信令流程、代码和CS电话流程中1327步的描述。切换过程中源实例（浅绿）和目标实例（深绿）分别对应着源信道和新信道，两个实例的状态转移过程如下图所示。补充说明：（1）每个状态在收、发完消息后转入下一个状态（2）图中所画的流程适用于小区内切换，小区间切换，如果是指配和定向重试过程，与图中流程只有1个差别，那就是第1步不是收到测量报告，而是RANA发来Assign Req消息，后面步骤都一样。（3）图中出现“指派/切换”的地方，由切换类型决定，指配和小区内切换为“指派”，小区间切换为“切换”，定向重试比较特殊，在8，10，11处为“切换”，12，13处为“指派”（4）14步这个地方之所以没有区分指派和切换是因为对目标实例来说，指派流程和切换流程的处理完全一样，所以在代码实现上就统一用指派完成应答这条消息了。（5）14和15之间其实会进行很多释放动作，如释放地面电路、拆接续、通知手机释放等，但由于绘图比较困难，所以没有画出，在这里特别说明一下。4. CS业务信道类型和语音版本进行一次CS业务BSC需要确定信道类型和语音版本，这2者的最终确定是许多因素共同作用的结果。具体包括手机能力、MSC策略，用户优先级、后台配置的优选信道类型、优选语音版本、载频类型等。先要定义2个概念：请求信道类型和实际信道类型，有2点区别。前者是指配请求中带来的，经源实例目标实例一路传递过来，一直到调用数据库接口申请信道之前；后者是数据库最后分配的信道的类型。前者有18种类型，其实就是18种申请策略，比如TCH_HF_CHANGE(半速率优先，但也可以全速率)。后者是实际信道的类型，不存在任何变数，常见的只有TCHF、TCHH、SDCCH等为数不多的几种。这一节就专门针对语音版本和信道类型的决定过程进行描述。步骤如下：1. 手机把自己支持的语音版本放在SETUP消息中发给MSC。2. MSC通过A口下发指配请求消息，其中包含了申请信道类型和语音版本列表3. Rancs源实例把这2个信息放入RadioApply消息传递给Rancs目标实例4. Rancs目标实例要准备申请信道和定语音版本了，目前代码中是先定信道，再根据信道类型选版本。5. 申请信道Step1：后台可以分别配置高低优先级用户的信道优选策略(共5个选择：不变、FR优先、HR优先、只能FR、只能HR)，根据用户优先级确定其优选策略，把这个优选策略与申请信道类型取交集。6. 申请信道Step2：调数据库接口申请信道时填上交集结果。数据库根据这个交集结果进行信道分配。申请信道这就算OK了，请注意，申请信道时根本不考虑语音版本的情况。7. 确定语音版本Step1：数据库申请信道成功，获得了实际信道类型。这时先对语音版本列表进行1个过滤：若载频不支持AMR，如果列表中有FRV3，HRV3则去掉。8. 确定语音版本Step2：后台分别设了FR和HR的优选语音版本，根据信道类型，看看对应优选版本在语音版本列表中是否有，有则直接选用，没有则选第一个与信道类型匹配的版本。为了让以上描述更加易懂，我们来看个例子，假设一次呼叫背景是这样的：l 手机支持FRV1, FRV2, FRV3,HRV1,HRV3l 用户是低优先级l 后台配置信道策略：高优先级用户优选FR，低优先级用户优选HRl 后台配置语音版本策略：全速率优选FRV2，半速率优选HRV3l 载频不支持AMR那么整个步骤如下：1. 手机把FRV1, FRV2, FRV3,HRV1,HRV3放在SETUP消息中发给MSC。2. MSC通过A口下发指配请求消息，其中包含了申请信道类型TCH_FH_CHANGE(FR优先，必要可选HR)和语音版本列表FRV1, FRV2, FRV3,HRV1,HRV33. Rancs源实例把这2个信息放入RadioApply消息传递给Rancs目标实例4. Rancs目标实例要准备申请信道和定语音版本了，目前代码中是先定信道，再根据信道类型选版本。5. 申请信道Step1：低优先级用户信道策略是优选HR，TCH_FH_CHANGE 与 优选HR取交集= TCH_HF_CHANGE。6. 申请信道Step2：调数据库接口申请信道时填上交集结果TCH_HF_CHANGE。数据库分配了HR信道。7. 确定语音版本Step1：此时已经从数据库成功获得了一条HR信道。因为载频不支持AMR，语音版本列表进行过滤后变成FRV1, FRV2,HRV1。8. 确定语音版本Step2：后台设的HR的优选语音版本是HRV3，列表中没有，因此选第一个与信道类型匹配的版本HRV1。5. CS业务常见概念5.1. BSC、BTS、站点、小区和载频(TRX)的层次关系这是一个让很多的人，特别是新员工困惑的问题。在学习GSM框架的时候，我们知道有BSC、BTS；在后台配置界面中，我们看到的是基站、机架、站点、小区、收发信机，这些都是与BTS相关的概念。那么，基站、机架与站点、小区又是如何对应的呢。首先，BSC、BTS、MSC以及MS(移动台)都是GSM系统中的网元，在协议中规定了各个网元在系统中的作用以及功能，而各设备供应商的各种型号的产品则是对这些网元的具体实现。现在说一下基站、机架、载频、站点、小区和收发信机之间的关系。在实际应用中，BSC一般都在运营商的中心机房，BTS设备则分散在各个区域。如果要新覆盖一个区域，则先找个高处建一座小机房，机房上安装了一个铁塔，租用或者自建一条从中心机房到小机房的传输线路。把BTS的机架和载频等硬件设备搬进去，载频插上，连好线，物理的安装就完成了。接着开始从后台配置数据，这才是重点。先进行物理配置，先新建基站，然后建机架，机架中创建载频和其他必要的如CMM等组件。物理视图中机架和载频的配置和实际硬件环境要一致。基站1机架1机架2载频1物理视图载频2载频3载频4载频5载频6站点1小区1小区2小区3逻辑视图收发信机1收发信机2收发信机4收发信机6收发信机3收发信机5接着在逻辑视图中配这些硬件的逻辑关系。物理视图中建了1个基站，则逻辑视图中建1个站点。假设我们有2个机架，各有三个载频。我们总共可以创建6个收发信机，每个收发信机对应1个载频。6个载频可以放在同1个小区，也可以分配给多个小区。这要看网络的规划。下面这个图中是一种可能的配置方式。总结一下吧，物理配置是记录系统中有那些硬件设备，逻辑配置则描述了这些硬件如何协同工作以及无线参数等。其中基站和站点是一一对应的，载频(TRX)和收发信机是一一对应的，但机架和小区没有对应关系。BTS本身是一个网元，在我们习惯的说法中，提到BTS有时指的是基站(如：“明天BTS会发到现场”)。但在阅读代码的时候，我们看到对一个abis消息的Lapd头中包括了以下参数，这些值都是在逻辑视图中配置的。其中特别的是这个BtsId指的并非基站编号，而是小区的编号，在理解的时候要注意。 WORD wSiteId; /* 站点编号 */BYTE byBtsId; /* 小区编号 */BYTE byTrxId; /* 收发信机编号 */5.2. 关于信道号(Channel Num)在代码中要描述一个信道，需要4个参数，上面的3个加上信道号。byChlNum存在lptRancsInst-tChannel.tChlDescri结构中，这一个字节包含了2部分信息：信道类型和信道在TRX中的时隙号，具体编码方式，协议44018