本文目录一览

1，寻呼拥塞怎么处理

调整短信下发走业务信道合理调整LAC区域调整寻呼信道速率全速率改为半速率增加寻呼信道开启双载频站点的2载频寻呼信道调整ECAM 消息的下发次数关闭3次寻呼功能

寻呼拥塞怎么处理

2，请问知道了基站的业务信道数怎样就可以知道用户的容量

用呼损和业务信道数确定总的话务量X，然后用X除掉(1/60erl)就是用户数量当然这个计算方法是在假设的情况下计算的，也就是你上面提到的“每用户话务量”是假设的，至于拥塞的意思是说，话务是有高峰的，上面的假设只是平均值，而用户的真正行为，可能是在某一个小时内一直在打电话，那么他该小时的话务量就是1erl，那么再使用上面的计算方法得出的用户数量就会少很多，而这种情况在每天的早高峰很晚高峰时间段内是经常出现的，所以就会引起拥塞，所以在做规划的时候我们为基站选择载频数的时候要使用适当的话务模型来计算，配置高了在闲时就会浪费资源，配置低了就会经常性的出现拥塞

请问知道了基站的业务信道数怎样就可以知道用户的容量

3，华为TD寻呼率如何计算了怎么判断寻呼拥塞

PAGING CHANNEL(寻呼信道) PCH(PAGING CHANNEL)寻呼信道AGCH,RACH同属于CCCH． 寻呼信道用于传送与寻呼程相关数据行传输信道用于网络与终端进行初始化简单例向终端发起语音呼叫网络使用终端所区寻呼信道向终端发送寻呼消息 网络想与某MS建立通信根据MS所登记LAC号向所具该LAC号区PCH信道进行寻呼寻呼MS标识TMSI或IMSI用于传输基站寻呼移台信息寻呼信道属于行信道点点传播式 非组合CCCH51复帧共9CCCH块其包括PCH块AGCH块．般城市AGCH设置0PCH空闲做AGCH用． 同PCH信道用于同寻呼组进行寻呼组合信道寻呼组减少非组合增．寻呼组越用户需要等待间越.
我们可以用以下方法解决外场寻呼拥塞问题： （1）优化放号规则，提高寻呼信道利用率（根据td寻呼机制来做调整）。 （2）cn寻呼机制采用tmsi寻呼，寻呼能力提高1/3（根据td寻呼机制调整） 。 （3）优化cn的短消息处理机制，降低突发寻呼量（根据网络性能调整）。 降低cn每秒下发的寻呼需求，可以降低寻呼冲突的概率，提高寻呼成功率； 降低cn对短消息寻呼的重发机制，取消重发； 延长cn对短消息寻呼的等待时间，rnc优化处理流程，提高短消息的寻呼成功率； 如果短消息中心采取的寻呼策略能考虑接入网寻呼的限制，适当进行流控和均匀化，能够避免或缓解寻呼拥塞的程度。 （4）优化lac配置，减少lac中寻呼的ue数目（根据网络寻呼能力调整） cs域寻呼消息是按lac进行下发的，一类寻呼消息在lac中的每个小区都进行下发，如每个lac规划的用户容量适中，则可减少寻呼冲突的概率。 （5）提升系统寻呼能力（根据厂商终端能力调整） 优化相关系统参数，如减少重发次数等。

华为TD寻呼率如何计算了怎么判断寻呼拥塞

4，拥塞控制算法

做QoS吗？你还是找论文吧，关于这方面的论文还是比较多的，这里有一个算法，你先看一下吧BLUE。BLUE的队列管理方式直接基于丢包率和链路利用率,而非瞬时的或平均队列长度。即它记录过去的丢包和链路利用状态,以此来对BLUE设定概率Pm 来标记(或丢弃)队列中的包。如果由于缓存溢出而造成队列连续丢包, BLUE将增大标记概率Pm ,使返回源端的拥塞通知的速率增加。相反,如果队列变空了或链路处于空闲状态,则减小标记概率,从而降低丢包率,提高链路利用率。以下是BLUE算法:Upon packet loss (or Qlen >L ) event: if ( ( now2last update) > freeze time) then Pm = Pm + d1 last update = nowUpon link idle event: if ( ( now2last update) > freeze time) then Pm = Pm + d1 last update = now其中: freeze time决定两个Pm 之间的时间间隔; d1 和d2 决定当队列溢出时Pm 的增加量或当链路空闲时Pm的减少量。你是学生吗？如果是直接上中国期刊网，不是的话可能要花钱了，书上一般不会给你具体算法。
慢开始,拥塞避免,快重传,快恢复. 首先要明白什么tcp协议可靠传输,还有什么是拥塞窗口:表示当前发送数据的上限,但是它会根据网络好坏状况动态改变. 慢开始:简单的说,开始传输时,传输的数据由小到大递增到一个值(即发送窗口由小到大(指数增长)逐渐增大到拥塞窗口的数值). 拥塞避免:数据发送出去,并发到接收方发回来的确认收到,拥塞窗口每次值加1地线性增大. 快重传:数据传输时(数据被分成报文,每个报文都有个序号),中间的一部分丢失接收方没收到,接收方连续接到后面的数据,则发回对丢失前的数据的重复确认,这样发送方就知道有部分数据丢失了,于是从丢失出重传数据. 快恢复:快恢复是与快重传配合的算法,在发生数据丢失时,发送方收到接收方发回的三个重复确认信息时,就把每次传输的数据量减为原来的一半,拥塞窗口也修改为这个值,然后又开始拥塞避免的算法.

5，CDMA 拥塞都有哪些

拥塞主要是由于资源不足和资源过度重复利用造成的结果，拥塞问题中的网络资源包括：公共(Page、Access)开销信道拥塞、TCH话务信道拥塞、Walsh code资源拥塞，基站收发信机功率（Power）匮乏，这几个主要问题。而无线环境的拥塞是指在网络资源得到保障的前提下，由于CDMA系统在软切换（SHO）和更软切换（SSHO）时需要重复利用大量的CE、WC、Power等有限资源，从而引起系统有限资源的短缺，直截导致拥塞故障的发生。 目前，造成CDMA网络拥塞主要有两大问题：一是网络资源，另一是无线环境。 分析及解决方法：　　在了解可能导致系统拥塞产生的基本概况后，就需要来讨论一下如何去发现、分析、解决这些问题的实际操作以及如何解决这些故障的办法。 　　产生的现象：（与有线的互联互通、交换的相关电路、漫游的局数据等非无线故障不在此作讨论） 　　呼入呼出困难；用户多次拨打才可接通；有信号，但呼不出去； 　　系统统计中MCC的Loading超过90%. 基站扇区CDL中有大量CFC20(No Radio Resource Available) 现象产生； 　　整个系统各个CBSC的Page Success降低，而CFC27(MSC Disconnect with SCCP Connection Refused) 增加； 　　在主叫方听到系统提示音为：“你所拨打的用户暂时无法接通，请稍后再拨”。 　　假如某一个基站的覆盖区域内广大用户具备上述现象中的任一现象，都必须来做如下分析： TCH拥塞　　首先，要分析故障现象中基站的MCC板的TCH利用率，因为这是最常见的，也是最具普遍意义的拥塞原因。计算Trifficchannel的方法是整个MCC的CE(Channelelement)减掉ControlChannel所占的CE数量和Soft hand off需占用的CE数量，最后剩余的CE即为TCH Channel。然后根据这些剩余的TCH CE，将其与Erlang-B表相对应，扣除中国联通总部规定的2%呼损，从而可以得到系统最大支持业务容量的Erlang数，将每日的系统实际业务统计量和这个理论的容量相对比，就可以知道目前的系统是不是TCH拥塞了。倘若的确是TCH Block，那么，就必须以增加MCC板卡或增加支持MCC板卡的SPAN数量来达到增加MCC数量的方式来解决TCH拥塞故障，即普通意义上的扩容工程。 　　Walsh code拥塞 　　如果没有TCHBlock现象，那么要继续分析看是否为WalshcodeBlock，因为Walsh code资源和MCC的CE资源是有区别的，MCC的CE 是整个基站共用的，而Walsh code的资源是分扇区来配置的，也就是说，当某一扇区的CALL ACCESS的数量大于该扇区的Walsh code数量，而又小于整个基站MCC的TCH Channel时，这时的话务小区应该是拥塞的，这种拥塞就是Walsh code资源拥塞故障。解决的办法就是增加话务小区的Walsh code数量，却不必增加MCC板卡。但是这个容量的配置也是和系统所支持的业务不同而分别配置，以MOTOROLA系统为例，在IS-95A时每扇区配为42个WC，而在1X业务时则配置为61个WC（最大为62个）。 　　通常，无线业务在系统的切换（SHO）中会占用大量的CE、WC、Power等资源。以及在更软切换（SSHO）中占用WC的现象。而如何降低这些资源的利用率，也就是如何消除拥塞的优化工作。实际上这个消除过程恰恰就是一柄双刃的利剑，一方面系统优化的目的是要极大地提高系统的利用率，而另一方面为了解决拥塞状况却又不得不来降低设备的利用率。 　　如果说网络中基站的业务容量、天线高度、切换小区是不变的，也就是说CE、Power、WC是一定的，这时系统发生拥塞故障了，在不能增加资源的情况下（增加基站、增加功率、增加CE、增加WC等），要解决的方法只有在WC上来具体分析。在CDMA系统中WC的重复利用主要是在SHO和SSHO的时候较多，而减少的办法只有调整基站的无线覆盖范围，比如降低天线高度等，这样系统小区的切换就会降低，WC的利用率也会减少，从而达到解决WC拥塞的目的。还有一种办法就是修改切换的基本参数、搜索窗等，而修改切换的基本参数无非就是在TADD、TDROP、TCOMP、T-TDROP上做文章，但是在降低切换电平、缩短切换时间、减小搜索窗的同时，是以降低切换成功率做为代价的。当然优化工作的意义正是如何为系统在其中找到最佳平衡点。 　　比如当某一个三扇区基站的MCC配置为两块MCC-48，那么Page和Access共占用3个CE，Sync占用3个CE，还剩90个CE，按照总部对软切换因子的算法要求只有90/1.35=66.66个CE可以作为TrifficChannel使用。如果三个扇区话务均衡，可以近似地认为每扇区有22.2个CE可用。目前的网络对纯语音（IS-95A）的扇区Walshcode配置为42个，只要具备DATA功能的小区配置Walsh code为61个，那么WC数量一直大于TCH的配置。也就是说除非所有的CE都被一个扇区里的用户占用，否则Walsh code始终都是够用的，从而避免造成Walsh code拥塞的存在。 　　公共(Page,Access)开销信道拥塞 　　还有一种资源拥塞现象就是BSS系统中的控制信道拥塞，最典型的当属Page拥塞，当许多的SP供应商在提供大量短信、游戏等业务时，由于群发的用户众多，当然会占用大量的公共信道，比如Page信道，实际上就会造成开销信道的拥塞，其具体表现为系统中许多语音或数据等传统业务的Page成功率下降，系统指标上CFC27会突然增多。一方面移动市场需要鼓励大量的SP来丰富网络业务，另一方面技术上又要保证提供足够的公共开销信道给广大用户，如果简单公共开销信道扩容，或者轻易地压缩TCH信道来满足公共开销信道，这样势必会造成巨大的资源浪费。但是在业务信道利用率较低的系统中，也许可以采用部分TCH信道来作为开销信道使用。其实在实际优化中可以采用以下两种方法来优化公共开销信道的拥塞问题： 　　一是限制Page所发送的Byte长度的方法来调整公共开销信道的拥塞，这和不同厂家交换机所提供的容量是有关系的，例如在BELL系统中将其利用公共开销信道发送的最大容量由120Byte更改为75Byte，也就是说大于75Byte的Message从TCH信道发送，这样也可有效杜绝大容量Message对公共信道的冲击。 　　二是选择一个系统空闲时间段来做Page群发的业务，就是将SP的群发业务改在整个系统的非忙时来操作，这样既满足了SP的业务需要，又避免了在移动传统业务Page高峰期和SP群发争用开销信道而导致拥塞的可能，保证了广大用户的利益,也保证了系统网络的安全。以上两种方法是在不增加资源的情况下来讨论避免拥塞的方法，如果采用对公共信道进行扩容的做法来解决拥塞，那就是工程方法而不是优化的工作了。 　　基站收发信机功率（Power）匮乏导致拥塞 　　最后一种拥塞故障就是无线系统的本质现象，这是由CDMA的网络特点所决定的，比如在某一话务小区，由于通话人数大增，而且大部分通话人距离基站较远，此时相应基站系统的上行底噪就会被抬高，同时对基站下行功率的需求也在增加，但是基站功率是一定的，这就会出现通常所说的功率不够用的情况，用户的呼叫在CDL（CallDetailLog）上体现为CFC20，拥塞也就在所难免。对于这样问题就只有通过增大基站的功率或增加基站载波的方法来解决。但是还有一种功率方面的拥塞并不是靠增大功率或增加载波的办法来解决的，相反，是将功率适当降低来解决的。大家都知道CDMAIS-95A系统在下行功率控制上的一大优点是闭环控制，但是在当用户接入到系统时的前2-3秒时间里，也就是闭环控制之前，其系统还是开环控制的。这就意味着在系统刚刚开始接入用户时是满功率发射的，当接入用户所需功率达到扇区功率最大发射功率时，系统就不会再接入用户了（注意此时是开环功率控制时期），所以此时不能分配到TCH的所有呼叫就会产生CFC20，于是拥塞发生了，闭环功率控制也失去了意义。在网络优化时建议对于扇区的功率是采取适当的降低，这样保证在系统闭环功率控制开始前还能够再接入新的用户，也才能够保证系统闭环功率控制优点的正常表现

文章TAG：业务信道拥塞次数怎么计算业务  业务信道  信道  
下一篇