CDMA2010电信考试题库-综合题.doc

1. 手机做主叫时，第一次发起呼叫后，很快回到待机画面，第二次发起呼叫，很快呼通。请从信令流程方面分析可能的原因，以及提供相应的处理方法，并说明移动台接入过程中涉及到的手机侧的定时器的应用限制以及默认时长，请至少列举3个。答：原因分析a) 在手机呼叫建立过程中，收到ECAM消息后，在前向业务信道上收NULL DATA，收到前向业务信道上的NULL DATA后，在反向业务信道上发送Preamable帧，整个过程持续时间为3秒。系统等待Preamble定时器设置为3s，当基站发送ECAM消息时，定时器开始启动，3秒钟内（默认值）系统连续发送3次（默认值）ECAM消息，如果基站在3秒钟内没有收到手机的Preamble帧，则系统释放通话。等待Preamble定时器设置太短，公共信道非确认模式最大重发次数太少。b) 系统捕获preamble后，随即发送BS ACK ORDER，并启动CCM_T_WT_MS_ACK_ORD定时器。按照协议要求，手机有2s的定时器，系统应该留够时间余量，在发送BS ACK ORDER时保证手机在协议规定的时间内有机会尝试接收消息。专用信道确认模式消息的最大重发次数3次，消息重发间隔：400ms，BS ACK ORDER消息发送的时间最长只能持续到约1.2s，BSS消息发送时间过短，而导致手机可能因此没有能接收到消息，从而引起呼叫建立过程中信令交互失败。处理过程:1、通过MOD TMR: MN=CCM, TMRID=5, TMRV=5000修改等待Preamble定时器到5秒；2、通过MOD TMR: MN=CCM, TMRID=4, TMRV=3000修改等待MS ACK ORDER定时器到3秒；3、在BSC维护台将公共信道非确认模式最大重发次数修改为5次；4、在BSC维护台将专用信道确认模式最大重发次数修改为5次。T51mT50mT41mIIIIIIIVVVIT42mT40mI: Subscriber presses “Send” button；II: Begin Probing；III: Receives BSs Ack of Origination；IV: Receives BSs CAM；V: Acquition of FTCH successful；VI: Receives BSs ACK Order T41m，4秒；T42m为12秒；T40m（3秒）；T50m，1秒；T51m，2秒2. 请问800M的S6/6/6配置下，机柜，单板，合分路器，TRM+HPA，GPS馈线，天线馈线，天线的配置如何。答：1，BTS3612-800单机柜最多支持12载频，对于超过12 载频，可以通过“并柜”既采用增加副机柜实现。当发生“并柜”时，我们称含有基带框的机柜为“主机柜”，不含基带框的机柜称为“副机柜”。每组并柜只含一个主机柜，在满配置的情况下：每个主机柜最多可带2个副机柜，即最多可实现3个机柜的并柜（这里所说的满配置是指：主机柜含有12载频，每个副机柜也都含有12载频）。2，S6/6/6总共18个载频，需要采用2个机柜，一个主机柜，一个副机柜，传输需要6条E1，基带框单板配置如下（主机柜）：BCIM板 1块（6条E1）BCPM板 A型 12块 B型 6块（优先选B型）BRDM板（多模）3块BCKM板 2块PSU 主机柜 4+1 副机柜 2+1主机柜：CDU 6RLDU 3TRM+HPA 12副机柜：CDU 3RLDU 3TRM+HPA 6主机柜配3根双极化天线，副机柜配3根双极化天线，总共6根双极化天线，GPS天馈总共只需一套；可以简化认为主机柜射频（天馈）部分按照S4/4/4配置，副机柜射频（天馈）按照S2/2/2配置，但所有的基带处理单元都配置在主机柜。3. J地数据业务优化测试中，平均下载速率比较低，而且传输缺口比较大，详细情况如下：用串口线前向平均下载速率只有6Kbyte，而且有很明显的缺口问题，传输图见下图：目前SCH的信令延时时10帧，SCH传输是128帧，检查各定时器值为系统的默认值，正常。观察BSC维护台跟踪信令，手机在连续下载过程中，每两个连续的Extended supplemental channel assignment message时间大约味6.6秒。从手机速率窗口观测到的情况也差不多，将近有2至3秒时间没有分配163.2的SCH信道。到基站下面测试，EcIo45左右,Rx=-50dBm，结果类似，BSC版本是R02B03D006SP01。京瓷手机版本是JS1.0.45。经最终分析，发现SCH申请的重试间隔为200帧，为4秒，建议将更改此参数后，数据业务传输得到改善，如下所示：现场反馈的信令跟踪如下：LCB(3864)FCB(0) tx MSG_CCM_RRM_SCH_REQ succ 2003-10-13 15:32:57.540LCB(3864) Start CCM_T_WT_SCH_CNF succ. 2003-10-13 15:32:57.540LCB(3864)FCB(0) FS(FS_ACT_SCH)-FS(FS_WT_SCH_CNF) succ 2003-10-13 15:32:57.540 COCRB(1557) rx CCM_RRM_SCH_REQ from CCB(3081) LCB(3864) in pilot(4),direc(0) 2003-10-13 15:32:57.540 COCRB(1557) according to pilot strength and branch number max rate(255),max duration(255) 2003-10-13 15:32:57.540 COCRB(1557) FwdSchAdmissCtr MutiBranchRate(255) SOWantRate(4) DataAcuumRate(4) PltStrgthAllowRate(4) LoadAllowRate(4) CEResAllowRate(4) 2003-10-13 15:32:57.540 COCRB(1557) Fwd Sch code res assign successes WalshCode(2) 2003-10-13 15:32:57.540 COCRB(1557) Fwd SCH Final Rate(4),duration(13) 2003-10-13 15:32:57.540 COCRB(1557) tx RRM_CCM_SCH_CNF to CCB(3081) LCB(3864) on PILOT:(4) in direc:(0), result:(0) 2003-10-13 15:32:57.540 LCB(3864)FCB(0) rx MSG_RRM_CCM_SCH_CNF 2003-10-13 15:32:57.540LCB(3864)FCB(0)dxMSG_RRM_CCM_SCH_CNFsucc:Dirc=0,FwdSch=start(27),duration(13),RevSch=start(0),duration(0) 2003-10-13 15:32:57.540 LCB(3864) Stop CCM_T_WT_SCH_CNF succ. 2003-10-13 15:32:57.540 LCB(3864)FCB(0) FS(FS_WT_SCH_CNF)-FS(FS_ACT_SCH_CONN) succ 2003-10-13 15:32:57.540 LCB(3864) tx Abis-Burst Request succ 2003-10-13 15:32:57.540 LCB(3864) Start CCM_T_WT_ABIS_BST_RSP succ. 2003-10-13 15:32:57.540 LCB(3864) LS(LS_ACT_SCH)-LS(LS_WT_ABIS_BST_RSP) succ 2003-10-13 15:32:57.540 LCB($) rx Abis-Burst Response 2003-10-13 15:32:57.570 LCB($) dx Abis-Burst Response succ 2003-10-13 15:32:57.570 LCB(3864) Stop CCM_T_WT_ABIS_BST_RSP succ. 2003-10-13 15:32:57.570 LCB(3864) tx Abis-Burst Commit succ 2003-10-13 15:32:57.570 LCB(3864) tx MSG_CCM_SDU_SCH_ASSG_REQ succ. 2003-10-13 15:32:57.570 LCB(3864) Start CCM_T_WT_SCH_ASSG_CNF succ. 2003-10-13 15:32:57.570 LCB(3864) LS(LS_WT_ABIS_BST_RSP)-LS(LS_WT_SCH_ASSG_CNF) succ 2003-10-13 15:32:57.570 LCB(3864) rx MSG_SDU_CCM_SCH_ASSG_CNF 2003-10-13 15:32:57.610 LCB(3864) dx MSG_SDU_CCM_SCH_ASSG_CNF succ 2003-10-13 15:32:57.610 LCB(3864) Stop CCM_T_WT_SCH_ASSG_CNF succ. 2003-10-13 15:32:57.610 LCB(3864) tx MSG_LCB_CCB_ACT_SCH_ACK succ 2003-10-13 15:32:57.610 LCB(3864) LS(LS_WT_SCH_ASSG_CNF)-LS(LS_CONNECTED) succ 2003-10-13 15:32:57.610 LCB(3864)FCB(0) FS(FS_ACT_SCH_CONN)-FS(FS_CONNECTED) succ 2003-10-13 15:32:57.610CCB(3081)rxMSG_LCB_CCB_ACT_SCH_ACKonCS/CSS(CS_WT_ACT_SCH/CSS_WT_ACT_SCH_ACK) 2003-10-13 15:32:57.610 CCB(3081) stop CCM_T_WT_ACT_SCH_ACK succ 2003-10-13 15:32:57.610 CCB(3081) tx ESCAM to LAC succ 2003-10-13 15:32:57.610 CCB(3081) tx MSG_CCM_RRM_SCH_PILOT_RSP succ 2003-10-13 15:32:57.610CCB(3081) (CS_WT_ACT_SCH/CSS_WT_ACT_SCH_ACK)-(CS_CONNECTED/CSS_IDLE) 2003-10-13 15:32:57.610 MSSB(2746) rx ESCAM 2003-10-13 15:32:57.610 MSSB(2746) set ESCAM L2 val: MsgSeqUnAss=6 2003-10-13 15:32:57.610 MSSB(2746) tx msg to BIM or SAR 2003-10-13 15:32:57.610 MSSB(2746) start LAC_TIMER_TYPE_DSCH_UNASS succ: MsgSeq=6 2003-10-13 15:32:57.610 CRB(2868) rx CCM_RRM_SCH_PILOT_RSP from CCB(3081) in direc(0) 2003-10-13 15:32:57.610 CRB(2868) Transfer Call Sub State: (WT_SCH_PILOT_RSP) - (IDLE) 2003-10-13 15:32:57.610 MSSB(2746) FDSCH ESCAM NoAck timeout:MsgSeq=6, RepCnt=3 2003-10-13 15:32:57.710 MSSB(2746) tx msg to BIM or SAR 2003-10-13 15:32:57.710 MSSB(2746) FDSCH ESCAM NoAck timeout:MsgSeq=6, RepCnt=2 2003-10-13 15:32:57.810 MSSB(2746) tx msg to BIM or SAR 2003-10-13 15:32:57.810 MSSB(2746) FDSCH ESCAM NoAck timeout:MsgSeq=6, RepCnt=1 2003-10-13 15:32:57.910 MSSB(2746) stop MSSB tick timer succ 2003-10-13 15:32:57.960CRB(2868)rxPMRMFer:0/10HdmSeq:3AsNum:1-4.5,-31.5,-31.5,-31.5,-31.5,-31.5SchIncl:0,Fer:0/0 2003-10-13 15:32:57.990CRB(2868)rxSDU_RRM_LINK_STAT_RPTEbNt(25),FER:FCH(0/100),DCCH(0/0),SCH0(0/0),SCH1(0/0) 2003-10-13 15:32:58.100CRB(2868)rxPMRMFer:0/10HdmSeq:3AsNum:1-4.5,-31.5,-31.5,-31.5,-31.5,-31.5SchIncl:0,Fer:0/0 2003-10-13 15:32:58.610CRB(2868)rxPMRMFer:0/10HdmSeq:3AsNum:1-4.0,-31.5,-31.5,-31.5,-31.5,-31.5SchIncl:0,Fer:0/0 2003-10-13 15:32:59.230CRB(2868)rxPMRMFer:0/10HdmSeq:3AsNum:1-4.0,-31.5,-31.5,-31.5,-31.5,-31.5SchIncl:0,Fer:0/0 2003-10-13 15:32:59.830CRB(2868)rxSDU_RRM_LINK_STAT_RPTEbNt(25),FER:FCH(1/100),DCCH(0/0),SCH0(0/0),SCH1(0/0) 2003-10-13 15:33:00.110 CRB(2868) rx SDU_RRM_SCH_REL_IND from SCB(36) in direc(0),reason is(0) 2003-10-13 15:33:00.310 CRB(2868) tx RRM_CCM_SCH_REL_IND to CCB(3081) in direc(0) Fwd reason(1) Rev reason(0) 2003-10-13 15:33:00.310 CRB(2868) Transfer Call Sub State: (IDLE) - (WT_SCH_REL_RSP) 2003-10-13 15:33:00.310 CRB(2868) start TIMER RRM_STATE_WT_SCH_REL_RSP succ 2003-10-13 15:33:00.310 CCB(3081) rx MSG_RRM_CCM_SCH_REL_IND on CS/CSS(CS_CONNECTED/CSS_IDLE) 2003-10-13 15:33:00.310 CCB(3081) tx MSG_CCB_LCB_DEACT_SCH succ 2003-10-13 15:33:00.310 CCB(3081) tx MSG_CCM_RRM_SCH_REL_RSP succ 2003-10-13 15:33:00.310 LCB(3864) rx MSG_CCB_LCB_DEACT_SCH 2003-10-13 15:33:00.310 LCB(3864) dx MSG_CCB_LCB_DEACT_SCH succ:RspFlag=0,FwdCause=1,RevCause=0 2003-10-13 15:33:00.310 LCB(3864) IM:LegNo(0) ARFCN(548) SiteId(0x50158275) AAL22=1,2,255,255 FCB1=*+ 188, 65535, 65535, 65535, 65535, 65535 2003-10-13 15:33:00.310 LCB(3864) tx MSG_CCM_RRM_SCH_REL_REQ succ 2003-10-13 15:33:00.310 CRB(2868) rx CCM_RRM_SCH_REL_RSP from CCB(3081) in direc(0) 2003-10-13 15:33:00.310 CRB(2868) Transfer Call Sub State: (WT_SCH_REL_RSP) - (IDLE) 2003-10-13 15:33:00.310 COCRB(1557) rx CCM_RRM_SCH_REL_REQ from LCB(3864) FCB(0) in PILOT(4) 2003-10-13 15:33:00.310CRB(2868)rxPMRMFer:0/6HdmSeq:3AsNum:1-4.0,-31.5,-31.5,-31.5,-31.5,-31.5SchIncl:1,Fer:1/128 2003-10-13 15:33:00.370CRB(2868)rxPMRMFer:0/10HdmSeq:3AsNum:1-3.5,-31.5,-31.5,-31.5,-31.5,-31.5SchIncl:0,Fer:0/0 2003-10-13 15:33:00.990CRB(2868)rxPMRMFer:0/10HdmSeq:3AsNum:1-3.5,-31.5,-31.5,-31.5,-31.5,-31.5SchIncl:0,Fer:0/0 2003-10-13 15:33:01.610CRB(2868)rxSDU_RRM_LINK_STAT_RPTEbNt(22),FER:FCH(0/100),DCCH(0/0),SCH0(0/0),SCH1(0/0) 2003-10-13 15:33:02.100CRB(2868)rxPMRMFer:0/10HdmSeq:3AsNum:1-4.0,-31.5,-31.5,-31.5,-31.5,-31.5SchIncl:0,Fer:0/0 2003-10-13 15:33:02.230CRB(2868)rxPMRMFer:0/10HdmSeq:3AsNum:1-4.0,-31.5,-31.5,-31.5,-31.5,-31.5SchIncl:0,Fer:0/0 2003-10-13 15:33:02.850 CCB(3081) rx MSG_RLP_CCM_SCH_ASSG_IND on CS/CSS(CS_CONNECTED/CSS_IDLE) 2003-10-13 15:33:02.920 CCB(3081) tx MSG_CCM_RRM_SCH_PILOT_REQ succ 2003-10-13 15:33:02.920请根据测试结果以及解决方案提供该问题的相关分析过程，信令分析的过程中要求分拣出如下信令：1、 申请建立SCH；2、 地面链路资源准备完成3、 SCH拆除4、 RLP发起另一次SCH申请答：A) 通过数据采集，需要至少得到以下的参数配置结果：1. 信令延时：10 frames2. SCH最大时长：128frames（2.56 s）B) 从附件的测试图显示的结果看：1. Max Throughput12639.846 bytes/s12639.8468/1000101.12kbps2. Average Througput4682.733bytes/s4682.7338/100037.46kbps3. SCH申请最大间隔：20.88s4. SCH平均申请间隔：7.35sC) 信令分析（截取信令中的一段进行分析） LCB(3864)FCB(0) tx MSG_CCM_RRM_SCH_REQ succ 2003-10-13 15:32:57.540（申请建立SCH） COCRB(1557) tx RRM_CCM_SCH_CNF to CCB(3081) LCB(3864) on PILOT:(4) in direc:(0), result:(0) 2003-10-13 15:32:57.540（此信令后10帧，开始SCH的开始时间，应该是15:32:57.74为开始时刻） CCB(3081) tx MSG_CCM_RRM_SCH_PILOT_RSP succ 2003-10-13 15:32:57.610（此信令表明地面链路资源准备完成）（快速重发三条ESCAM消息） MSSB(2746) FDSCH ESCAM NoAck timeout:MsgSeq=6, RepCnt=3 2003-10-13 15:32:57.710 MSSB(2746) tx msg to BIM or SAR 2003-10-13 15:32:57.710 MSSB(2746) FDSCH ESCAM NoAck timeout:MsgSeq=6, RepCnt=2 2003-10-13 15:32:57.810 MSSB(2746) tx msg to BIM or SAR 2003-10-13 15:32:57.810 MSSB(2746) FDSCH ESCAM NoAck timeout:MsgSeq=6, RepCnt=1 2003-10-13 15:32:57.910 MSSB(2746) stop MSSB tick timer succ 2003-10-13 15:32:57.96015:32:57.74为SCH开始时刻 （信令中没有体现）15:33:0.3为SCH结束时刻 CRB(2868) rx SDU_RRM_SCH_REL_IND from SCB(36) in direc(0),reason is(0) 2003-10-13 15:33:00.310（SCH拆除） CCB(3081) tx MSG_CCM_RRM_SCH_PILOT_REQ succ 2003-10-13 15:33:02.920（RLP发起另一次SCH申请，与SCH拆除的时间间隔为2.61s）1. 信令延时，从附件的统计结果看，从RRM收到SCH申请“COCRB rx CCM_RRM_SCH_REQ”到网络侧SCH准备完成“CRB rx CCM_RRM_SCH_PILOT_RSP”一般在60ms90ms之间（35帧），加上空口和手机的准备需要的3帧，因此信令延时设为810帧，比较合理。2. SCH时长：128 frames。SCH时长越长，相当于SCH间隔越少，速率应当更高。3. RLP申请间隔。最理想的情况是，间隔Duration（2.56s）信令延时，约3s。4. 综合如下：（1） 地面链路准备 70ms （3.5帧）（2） 空口、手机准备（3帧）（3） 信令延时（10帧）（4） SCH Duration （128帧）（5） RLP下一次SCH的申请与上一次SCH拆除的时间间隔为2.61s因此从RLP发起SCH申请到SCH拆除的时间为2.77s，在3s以内。因次空中接口是正常的。但是，由于在一次SCH拆除之后到下一次SCH申请之前，由信令和图示分析得出有2.61S的间隔周期，在该周期内数据业务无传输，因此可知，该值是引起数据业务传输缺口大的主要原因。查询RLP的设置参数应该可知：| RLP | SCH_RETRY_TIME | SCH申请的重试间隔 200 发现SCH申请的重试间隔为200帧，为4秒，因此，建议将此参数改为20帧。以减少数据业务传输之间的间隔时长。4、某CDMA450局在密集市区进行组网，该地地形平坦，道路宽阔，房屋平均6层楼。可以使用的频率有三个160、210、260，平均基站间距达到800米左右。开局初期由于用户量不高只使用了160频点，但是覆盖商业区的局部话务热点区域出现拥塞，局方要求进行热点区域的扩容。由于局方强烈要求，现场督导紧急开通了热点地区附近的一个双载频基站（使用了160/210频点），采用Hash算法分配载频间话务，该处的话务拥塞得到部分缓解，但是160载频上的话务依然很高，而210上话务吸纳有限。另外，在DT测试发现：从周围的单载频基站上网建立呼叫的手机移动到双载频基站附近100米以内的地方,手机奇怪掉话。问题：1）进行热点地区的扩容可以采用什么方法？对于450M市区组网，每种方法时需要进行哪些特殊考虑？2）为什么采用Hash算法分配，话务依然没有完全缓解？3）请分析为什么手机会奇怪掉话?4）如何解决上述奇怪掉话？答：1) 阅卷人可以考虑只要答案合理并且不重复，可以一个答案一分。可以采用：小区分裂；多载频；灵活ODU或者小基站；室内分布系统；街道站等。特殊需要考虑的：大下倾角；降低天线高度；特殊天馈（内置下倾角、高前后比天线等）；频点选择使用（160、260，不用210）；配合的切换参数和邻区关系（软切换和硬切换的）。2) 由于放号的用户前期基本上是160频点上的，Hash不上210频点上；或者Hash对于整网有统计均匀意义，但对单个基站均匀用户意义不大。需要考虑硬指配。3)没有做硬切换相关参数（开关和切换门限、异频邻区关系），导致邻频干扰（可能是手机在接收通道的滤波较宽所致。理想的情况是手机只对160频点1.23M的信号进行接收, 手机在接收通道的滤波较宽,就会引入210载频的一些信号,致使手机运动到双载频基站附近时,Rx增大,由于210载频的信号手机无法利用,成为干扰,造成在双载频基站附近时, FFER急剧升高，奇怪掉话）4)频点依然使用160和210，则需要加上异频硬切换相关参数，注意要调高启动门限，信号很好时早点就切换过去，防止邻频干扰；频点修改为160和260，就可以解决。当然为了让信号覆盖联系，异频硬切换相关参数也要加上（但门限没有特别要求）。5、 数据业务实际吞吐量分析 (20分)CDMA20001x数据业务物理层采用IS2000空中接口，上层协议为标准的TCP协议。CDMA20001x提供了多种速率的数据业务，一条SCH可分配的速率为9.6kbps，19.6kbps，38.4kbps，76.8kbps，153.6kbps。在CDMA 1X数据业务中，采用了多种技术来保证数据传输的准确性， 在协议栈的各层都规定了固定的格式来保证传输的准确性，具体如下：TCP层TCP/IP数据包头40bytesTCP数据包长度典型为5001500bytesPPP层为了减小TCP/IP头的影响，在PDSN和MS之间建立的PPP link使用头压缩技术，可以把数据头的长度降低到4bytesRLP层FCH，头长度10bits，帧长度172bitsSCH，头长度16bits，帧长度352bitsRLP层误帧引起的数据重传Mux/RF层CDMA20001x SCH各速率及其相应的MUX字节数与RF字节数：1)在CDMA 1X数据业务中，为什么用户实际感受到的速率要小于理论上宣称的速率（即物理层速率），这主要是什么原因造成的？（4分）2)根据上面的技术规定，请计算，a）数据在TCP层的实际传输效率是多少？（2分）b）数据在经过PPP层之后，TCP/IP数据的传输效率是多少？（2分）c）数据在RLP层的时候，FCH信道和SCH信道的数据传输效率分别是多少？（2分）d）假定在RLP层采用二次重传，当FER分别为5%和1%的时候，由FER带来的数据的传输效率分别为多少？（2分）e）当SCH信道数据速率为153.6 kpbs的时候，数据在MUX层的传输效率是多少？（2分）f）假定FCH信道传输5 kpbs的信令，则一个FCH+8XSCH的数据业务（TCP/IP数据包设为1000 bytes，FCH的FER设为1，SCH的FER设为5）配置的实际最大数据吞吐量是多少？（6分）答：1)这是由于，在在CDMA 1X数据业务的协议栈中，在每一层都加入了该层的数据头，这样就增大了最终数据包的长度（2分）。此外，由于RLP的重传机制，也会增大额外传送的数据量（2分）。2)a) TCP层的传输效率为（500-40）/500*100%=92%；（1分）（1500-40）/1500*100%=97.3% （1分）b) 在经过PPP头压缩之后，TCP/IP层的传输效率为：（500-4）/500*100%=99.2%; （1分）(1500-4)/1500*100%=99.73% （1分）c) 在RLP层的数据传输效率：FCH信道：162/172*100%=94.2%（1分）SCH信道：(352-16)/352*100%=95.45% （1分）d) 经过RLP层的二次重传之后，数据传输效率为：当FER为5%的时候数据传输效率为：1-5%*2=90% （1分）当FER为1%的时候数据传输效率为：1-1%*2=98% （1分）e) 在MUX层，SCH信道速率为153.6kpbs时，传输效率为：2816/（2816+232+24）*100%=91.7% （2分）f) 当8XSCH信道的配置的时候，实际SCH信道速率为76.8kbps，在MUX/RF层的传输效率为：1408/（1408+104+24）*100%= 91.7% （1分）而速率为9.6kpbs的FCH信道，在MUX/RF层的传输效率为：172/（172+20）*100%=90% （1分）在这种数据业务配置情况下空口支持的最大数据速率为9.676.886.4kpbsSCH信道速率为76.8kpbs时，其总体传输效率为：（n为传输效率因子）（1nTCP）（1nRLP）（1nFER）（1nMUX）0.9960.95450.90.917 78.5% （1分）FCH信道速率为9.6kpbs时，其总体传输效率为：（1nTCP）（1nRLP）（1nFER）（1nMUX） 0.9960.9420.980.9 83% （1分）考虑在FCH上承载的信令约5kpbs实际的最大吞吐量为0.78576.8kpbs0.839.6kpbs5kpbs63.256kpbs （2分）(不一定要完全按上面的中间过程来，如果中间过程没有，得出最后结果可以给5分)6、 如下图所示：在两个RASYS本地网1和本地网2之间存在重叠覆盖区；MS1是在本地网1中开户的固定台。当MS1处在重叠覆盖区时，有时RAU1的信号超过RAU2，有时RAU2的信号超过RAU1，而且当MS1使用RAU2的信号时，无法作主被叫。请分析：假定禁止RAC间漫游的情况下，请从网络侧、终端侧、信号覆盖、频率使用和放号策略等方面分析，有哪些方法解决这种情况？ （10分）LE 1RAC 1RAU11LE 2RAC 2RAU2A3/A7本地网1本地网2MS1答：如果运营商不允许固定台在两个RAC间漫游，或者RAC1与RAC2之间不存在A3A7链路。那么无论RAU1的信号超过或者低于RAU2，固定台MS1都应当始终锁定在本地网1中。1、减少重叠区域，在重叠区增加定向基站或者增加定向天线，裂化重叠区；或者调整两个RAU小区的前向功率，收缩覆盖半径。通过以上的邻区分析获得重叠区的网络覆盖情况后，在重叠区的本地网增加定向手段，使其对覆盖区内的固定台的覆盖信号增强，可以达到减少重叠区的效果。适用于：所有具有重叠覆盖的区域 （2分）2、网络侧将固定台锁定在本地网中，本地网1和本地网2分别配置不同的频点以及不同的SID/NID。在固定台MS1的PRL列表中，只是存储F1和SID/NID1。 这样可以保证固定台MS1始终锁定在F1频点。即使掉网，也不会上到本地网2。（可能存在的问题：a、由于450只有3个频点，很难保证任何两个相邻RAC小区都能分配到不同频点；b、网络运行过程中，对网络更改频点的情况，需要将所影响小区下的所有终端全部要重新设置，人工改的方式导致运营比较困难，通过网络侧提供OTA功能可以达到此目的，但目前RAC版本没有此功能。）适用于：重叠区的两个RAC间频率配置不同的情况 （2分）3、固定台侧改进，使其锁定在本地网中：调整转动固定台的定向天线的方向，使其他基站的信号要小于归属基站的信号，可以抑止同频干扰问题。适用于：所有具有重叠覆盖的区域 （2分）4、固定台优化搜索可用网络的策略：如果固定台不能够稳定停留在本地网的RAU1上，当RAU2的信号超过RAU1大概在35dB时，固定台MS1将频繁搜网；在搜网过程中，固定台对历史情况进行记录，如果在RAU2上尝试后无法获得正确的系统参数，后续的一定时间内不应该对RAU2再发起搜索尝试；固定台维护该历史搜网记录，当定时器超时或者空闲切换成功后清除对指定BTS的“惩罚”记录。这样就确保了固定台稳定停留在归属基站上。网络侧已经使用类似的切换惩罚策略算法，避免了无谓的切换尝试，对切换性能有较好提升，建议推动终端部门解决。适用于：禁止漫游且SID/NID配置不同的重叠区，可较好解决终端上网问题（2分）5、如果明确重叠区的地理范围后，控制在重叠区内的固定台数量，可以降低重叠区对网络质量的影响。适用于：对局方放号建议 （2分）7、 在一片城区内，存在有下面的组网结构。设备配置为1MSC/1BSC/8BTS。（12分）这些站现在的框分布和LAC区信息情况如下：BTS IDBSC SubrackLACReg_zone130x1211230x1211530x2212340x1211440x1211640x2212740x2212840x2212现在每个站的忙时不含切换话务量如下：BTS IDTraffic(erl)1142235321041215676160713581471) 从话统上发现，在两个框的边界小区，软切换成功率低于20%，但检查无线覆盖和邻区关系都是正常的，则最有可能是什么原因引起的？（1分）2) 目前的框分布是否合理，存在哪些问题？如果不合理应该如何调整，调整的原则是什么？（7分）3) 目前在边界区域，通过测试发现，覆盖良好，但2个LAC的相互交叠区域比较多，这会引起什么问题？如何进行优化？（4分）答：1.最有可能是由于框间软切换链路没有配置所导致。（1分）2.框分布不合理。存在的问题：A.从地理位置上，1，2站和3，4站同在商业区，5，和6，7，8站同在居民区，按照现在的框配置，容易引起大量的框间切换，导致框负荷增高。B.LAC区跨框严重，导致寻呼消息重复下发到2个框，增高框负荷。C.计算每个框的总话务量，3框：142+35+67=244erl，4框：210+121+160+135+147=773erl，两个框的话务负荷严重不均衡，并且4框的话务负荷已经严重超出单框额定容量600erl，会引起框的负荷严重过载。（ 每点一分）调整的建议：（1分）BTS IDBSC SubrackLACReg_zone130x1211230x1211330x1211430x1211540x2212640x2212740x2212840x2212调整的原则：A.话务均衡原则，调整后 3框话务 142+35+210+121=508，4框话务 67+160+135+147=509，这样每个框的负荷都没有过载。B.按照地理分布原则，2个区域中间是话务比较低的公园，框的边界放在这里可以避免过多的框间软切换。C.保持和LAC区划分统一，避免了跨框的LAC。（每条一分）3.引起的问题：A.用户会频繁进行基于ZONE的登记，导致接入信道负荷高。（1分）B.会导致寻呼失败增高。（1分）优化方法：A.调整TOTAL_ZONE到2，并且把ZONE_TIMER 时间设置加长（如果给出值，需要大于30秒，降低注册频度。（1分）B.打开MSC的扩展LAC寻呼功能，修改寻呼策略为：第一次，第二次在本LAC寻呼，第三次在2个LAC寻呼。（1分）8、 对某网络内呼叫建立成功率低的某载扇进行分析：（14分）1) 请简画出2000手机进行语音主叫的流程图，要求包括核心网和接入网的所有流程。（2分）2) 呼叫流程中，反向开环功控，反向闭环功控的起始点分别在哪个环节？（2分）3) 在话统中，发现某载频扇区存在大量的呼叫资源分配失败，则应该如何分析定位？目前常见的是由于哪些原因引起的？(6分)4) 如果在CSL呼叫建立失败原因分析中，发现大量的A13原因释放，是否会对呼叫建立成功率造成影响？引起A13的原因是？（4分）答：1、（2分）2、反向开环功控：手机发送接入试探。（1分） 反向闭环功控：手机发送TCH PREAMBLE。（1分）3、问题1：a.分析话统中的Tch Congestion Ratio，检查是否存在WALSH不足，CE不足，前向功率不足，反向功率不足或者其他原因。（1分） b. 若Tch Congestion Ratio正常，则分析告警，检查是否存在传输链路的拥塞或者中断告警。（1分） c.从CSL分析中进一步检查是否存在设备内部原因问题。（1分）问题2：a.WALSH，CE，前反向功率不足引起的拥塞。（1分，答不全0分）b.传输链路不足引起的地面链路拥塞。（0.5分）c.ABIS口逻辑带宽因子配置不当引起的假拥塞。（0.5分）d.微波传输链路闪断。（1分）4、A13释放在话统中没有统计，因此不会影响呼叫建立成功率。（1分）引起A13的原因：（1）手机没有开户，网络侧收到CM业务请求后直接拒绝。（1分）（2）主叫打被叫，手机被叫寻呼响应上去后，如果在MSC下发指配请求之前主叫挂机，MSC直接释放被叫，属于正常的呼叫早释。（1分）（3）采用定位寻呼方式的短消息呼叫过程中，MSC收到BSC的寻呼响应后，下发短消息，然后发起拆线，属于正常释放。（1分）9、 某市ETS450D网络共有1个CBTS3612大基站与1个CBTS3601小基站。在路测时发现通话时如果单独使用小基站或者大基站的信号，就不易掉话；处于两基站的软切换状态就很容易掉话。在掉话时RX、Ec/Io都很好；Tx在-10dBm左右；FFER为0；前反向发射功率没有任何调高的迹象。从话统数据来看，小基站的忙时掉话率在8以上，掉话原因都是无线链路掉话。问题排查中发现小基站采用的传输方式是UNI方式，而大基站采用的传输方式是IMA方式，修改FMR板的反向帧合并定时器长度后，小基站与大基站在软切换时的掉话问题得以解决。以下是在呼叫掉话时，BSC调试台通过跟踪SPU板的CCM呼叫跟踪打印出的信息：“Call Trace: CcbNo（32）SDU_CCM_TCH_ERROR_IND （Tick=172254972）（2003-04-15 00:02:18）CcbNO（