TCH拥塞率高的分析处理

TCH拥塞率高的分析处理第一章：前言：我们在谈到网络拥塞时，常常是指信令信道拥塞以及话务信道拥塞。其中话务信道拥塞也就是我们常说的TCH信道拥塞，发生在用户在申请网络服务信令交互之后，一般进行用户的真正话音要由TCH信道承载，TCH信道的分配也称指配过程。出现TCH信道拥塞是说：在指配过程中，如果网络没有可用的TCH信道来分给手机，则系统计一次TCH分配失败。在本文中，笔者主要从出现TCH信道拥塞可能的原因入手，提出一些解决TCH信道拥塞的方法和思路，以供大家参考。第二章：信令流程1）正常TCH分配信令流程2）TCH分配拥塞信令流程（起呼、切换中）（1）MOC：（2）Intra_BSS_HO：（3）Inter_BSS_HO：3）TCH分配拥塞信令流程分析说明在SDCCH信令接续完成后，系统将向手机分配陆地电路和TCH信道。手机先向系统发SETUP消息，其中包含被叫号码即Bnumber和所需业务等。MSC收到SETUP消息后，要通过VLR发送出局呼叫消息（Send_Info_For_O/C_Call）,VLR在收到该消息后，将根据其从HLR获得的此主叫用户的信息，来分析被叫的号码即HLR－Inquire（实际是依据B的号码分类向B归属的HLR查询B的信息）和主叫用户本身的能力（根据主叫用户被允许的业务种类，查看A用户是否支持本次呼叫，检查系统是否能接纳这此呼叫。若某些要求不能满足，系统则向主叫用户发出释放完成消息（ReleaseComplete），此次呼叫建立就失败了；经过查询后，如果对B用户的HLR－Inquire成功，且A用户具有此次呼叫的权限，VLR则向MSC发完成呼叫能力查询消息（CompleteCall）。当MSC收到这个消息后，则向MS发出呼叫继续消息（CallProceeding），表示主叫用户的呼叫请求已经通过了检查，呼叫处理正在进行当中。此后MSC将根据用户的业务请求，向BSC的SSM发出指配请求消息（AssignmentRequest），给用户的此次呼叫分配TCH话音信道。此消息中指明了所请求信道的类型等内容。SSM收到AssignmentRequest后触发统计ma_req_from_msc。BSC的SSM在收到MSC的TCH信道请求后，通过BTS的RRSM向BTS的CRM申请TCH信道分配。如果有可用的TCH信道资源的话，CRM会通知RRSM消息assignmentchannelassigned，RRSM收到后触发统计alloc_tch。RRSM再向BTS的Layer1发出激活TCH信道消息（ChannelActivationforTCH）。如果CRM没有可用的TCH信道，则CRM触发统计alloc_tch_fail，并通知RRSM消息resourcenotavailable，此时RRSM触发统计ma_cmd_to_ms_blkd，再由RRSM向MSC返回分配失败的消息（AssignmentFailure）。如果系统允许排队的话，则CRM通知RRSM消息forcequeue，RRSM在启动T11的同时，向MSC发出排队指示的消息（QueuingIndication），如T11超时，则RRSM向MSC发出清除请求（ClearRequest消息）。在RRSM收到Layer1回送的信道激活响应（ChannelActivationACK）的消息后，就在SDCCH信道上通过指配消息（AssignmentCommand）通知手机分给其的TCH的情况，这个消息中包含：TCH信道类别（话音/数据的指示），信道的速率和类别、话音解码算法、透明传输指示、分配优先级以及CIC电路识别码。在发送指配消息的同时，RRSM启动T10。MS收到系统发来的AssignmentCommand消息后，将就从SDCCH信道调整到所分的TCH信道上，再通过与TCH随路的FACCH信道向系统发出SABM消息，BTS的Layer1在收到该消息后，会向RRSM发ESTABLISHINDICATION（建立指示消息），同时Layer1向手机回UA的证实消息。MS收到UA后，通过FACCH向系统发出分配完成消息（AssignmentComplete），如果因为其他原因导致手机不能占用TCH信道，手机就向系统发出指配失败消息（AssignmentComplete）。如果在T10规定的时间内手机没有回送AssignmentComplete消息，则系统将该TCH信道释放掉。在手机成功占上TCH后，BSS将启动SDCCH的释放进程。BTS发出无线信道释放（RFChannelRelease）消息，要求将以前占用的SDCCH信令信道资源释放掉，当BTS完成了信令信道的释放后，将发给BSC一条信道释放完成（RFChannelReleaseACK）消息，BSC收到此消息后就认为该信道已返回到空闲状态下，该资源可以用于分配给新的信道请求。第三章：TCH拥塞率计算公式1）含切换的TCH拥塞率公式TCH拥塞率（含切换）（2002中国移动集团公司公式）=忙时话音信道溢出总次数（含切换）×100/忙时话音信道试呼总次数（含切换）(％)＝alloc_tch_fail×100/alloc_tch+alloc_tch_fail(％)2）不含切换的TCH拥塞率公式TCH拥塞率（不含切换）（2002中国移动集团公司公式）=忙时话音信道溢出总次数（不含切换）×100/忙时话音信道试呼总次数（不含切换）(％)＝ma_cmd_to_ms_blkd×100/ma_req_from_msc(％)第四章：可能导致TCH拥塞率高的原因及其解决方法当基站的TCH拥塞率指标出现拥塞后（拥塞率关注的程度要视网络性能发展的阶段而定），通常优化人员要提取与TCH信道分配过程有关的性能统计，并结合基站的配置参数、现场测试文件或OMC的CallTrace文件等，对基站拥塞的原因进行分析定位，并采取有效的解决方法予以处理。一、出现突发性话务量增加而且产生话务量时间相对集中基站出现突发话务量一般是指：出现高话务量的小区在以往的统计记录中没有出现或极少出现这样高的话务量情况。用户的服务需求比较集中一般指：相对以往的统计记录来说，小区出现比较明显的拥塞率高的现象，但小区的话务量没有明显的增加现象、基站的拥塞不是由硬件故障引起的、检查与TCH分配有关的其他性能指标均没有异常，在这种情况下，我们可以怀疑在这个时段基站覆盖范围内的用户有比较集中的网络服务需求。当系统出现突发性的话务量，而且用户的服务需求比较集中时，可以考虑采用以下的方法来缓解或解决：适当开启并调整TCH的排队功能；在合适的情况下开启TCH的流量控制功能以缓解TCH的突发拥塞。1）开启TCH排队功能，适当考虑增加排队时长由于呼叫建立或切换接入的原因，需要指配某个BTS的TCH信道，而该BTS上所有的TCH均已被占用时，BSC的无线资源管理程序有三种处理方式。其一是在系统使用定向重试（DirectedRetry）功能且该BTS和相邻BTS将具有此能力时，BSC采用定向重试方式直接将该呼叫指配到相关的其它小区（此处理不适用于切换接入的情况）；其二是在系统不使用排队功能（Queuing）时，BSC直接向MSC报告指配失败，从而使本次呼叫或切换尝试失败；第三种情况是系统采用排队功能，此时BSC将MSC的指配请求进行排队，一旦该BTS中有TCH被释放，即处理队列中的指配请求。对于最后一种情况，BSS系统需确定在队列中最多可以缓冲多少次呼叫或切换接入请求，即参数“全速率信道最大队列长度”。排队管理：在正常的呼叫建立过程中，系统先分配给MS一个专用信令信道SDCCH用于呼叫建立进程的信令交互，之后系统要给MS分配话音信道TCH，有可能发生当MS完成SDCCH上的信令交互后，系统没有可用的TCH来分给MS，此时若开启了排队功能，则系统可将MS放在队列中，与其他等待TCH的MS一起排队。这种功能在一定程度上可以缓解系统TCH拥塞，但一般在突发且时间相对集中的拥塞情况效果比较明显。涉及的系统参数：queue_managment_information：BSS小区级参数；定义了系统允许排队队列的最大长度。若此参数等于0，则系统不允许MS进行排队。bss_map_t11：Site级参数；MS在队列中等待系统分配TCH的最大时长由bss_map_t11来决定。这个参数的设置要与MSC的相应参数设置一致。系统启用排队功能时，会同时启动定时器T11，在该定时器超时前，若有TCH被释放，则系统会将该TCH指配给队列中的这次呼叫，并清除该定时器。若到定时器超时时，依然没有可用的TCH资源，则系统将队列中的此次请求清除，并以指配失败的形式告知MSC。Max_q_length_full_rate_channel：BSS小区级参数；定义了等待分配全速率TCH的MS的队列的最大长度。Max_q_length_sdcch：BSS小区级参数；决定了等待分配SDCCH信道的MS队列的最大长度。对于channelrequest系统不支持排队，但是对于MSC发起的SDCCH切换中对SDCCH的申请可以进行排队，但一般情况下MSC不会发起SDCCH切换。Priorityassignmentfunction：MSC上定义的BSC级参数；此功能使得系统按照呼叫的类型来将排队等待资源的MS按优先级排队。此参数要置为“开”，系统才能真正开启TCH的排队功能。在一般情况下，开启TCH的排队可以在一定程度上缓解系统的拥塞，我们建议在网络参数的设置中将此功能打开。可以参考以下的参数设置：queue_managment_information＝2；bss_map_t11＝10000（ms）Max_q_length_full_rate_channel＝2；Max_q_length_sdcch＝0；Priorityassignmentfunction＝1；注意：queue_managment_information的取值要大于Max_q_length_full_rate_channel与Max_q_length_sdcch之和。在北京移动的GSM网络中，开启TCH的排队已经是网络的基本配置要求。在话务的出现相对集中的地区，采用排队方式可以有效地提高系统的接通率，平滑局部地区的话务量，对缓解TCH信道拥塞，此功能效果比较明显。但在具体实施时，要估算用户能够容忍的等待时长，还要注意及时调整MSC的功能设置以及等待时长，来配合无线侧的排队等待。例如：队列长度过大常常会导致T10的超时，而T10超时前，系统中有一定的资源会被占用，因此T10超时事件越多，系统的资源利用率越低。选择合适的队列长度对系统资源利用率有至关重要的影响。另外，并不是所有对系统资源的请求都是允许排队的，其中对于立即指派请求，BSC内切换，BSC间切换是不许参加排队的，只有TCH资源请求（即TCH指派请求和小区内部切换）允许给相应的请求分配那些在T10规定时间内被释放掉的TCH信道，如果排队长度或等候时间超出系统要求则该请求将被拒绝。案例分析：1、通常在切换过程中涉及到的TCH信道请求，若目的小区没有资源，则BSC会向满足切换要求的邻区清单中的下一个小区申请TCH资源，这种由于切换引起的TCH请求是不参加排队。当MS做主叫或被叫时申请TCH资源时可以参加排队，所以若TCH排队正常进行时，统计出来的TCH拥塞率中，含切换的拥塞率要高于不含切换的拥塞率。2001年6月底，我们在分析全网的TCH拥塞率时，发现个别MSC上的TCH拥塞率中，含切换和不含切换的大小关系不正常，即表现出来的大小关系为：这些MSC的含切换的TCH拥塞率小于不含切换的TCH拥塞率。发现此现象后，我们发现这应该是由TCH没有正常工作引起的，因为若MS起呼和被叫参加TCH排队，而切换不参加TCH排队的话，不应该出现这种现象了。我们检查了BSS中涉及TCH排队的参数后，没有发现异常的情况，进而检查MSC中的有关参数，发现MSC上的参数设置不正常。7月2日，我们修改了BSC23所属的MSC上的参数后，