-- 发布时间：2004-03-02 15:25:45
短信息与移动、联通互连互通后，PCH的容量瓶颈问题越发突出了，有没有什么好的对策？难道眼睁睁地看着巨大的短信息流量将PCH占光，最终将被叫接通率拉下去？
-- 作者：angel
-- 发布时间：2004-03-09 16:57:06
可以通过短消息流量控制来避免PCH的大量占用。比如说，我们可以在系统中设置一个寻呼区下每小时的短消息流量。
-- 作者：transmit
-- 发布时间：2004-03-10 15:13:03
治标不治本，那还不如干脆将短信息功能关了，岂不更省事？
-- 作者：angel
-- 发布时间：2004-03-10 18:04:17
不能这么说嘛，我们只是在控制短消息流量，对于用户来说，应该不会有太大影响。不要忘记，短信可是小灵通的增值业务之一呢，怎么能取消呢？
-- 作者：华人
-- 发布时间：2004-04-12 23:04:13
控制短消息流量，那么短信的延时问题怎么解决？群发的广告还可以忍受，点对点的怎么办？难道我现在发一个短信告诉对方我在××等你，要对方在一个小时后收到说我来了～岂不尴尬？
-- 作者：华人
-- 发布时间：2004-04-12 23:17:44
不过我决定首先应该尽量将超帧结构中的24000次/秒的潜力尽量挖出来，如果还不能满足要求那么只能划小PA，然后通过增加基站来抵消由于位置登记的增加的SCCH需要增加。PCH是一个全局资源不能通过增加基站解决，SCCH是一个局部资源可以通过增加基站来解决。当然增加基站将导致 TCH的干扰增加，那只有通过优化解决了！呵呵～～
-- 作者：tom
-- 发布时间：2004-04-13 08:19:19
| 以下是引用华人在2004-4-12 23:04:13的发言： 控制短消息流量，那么短信的延时问题怎么解决？群发的广告还可以忍受，点对点的怎么办？难道我现在发一个短信告诉对方我在××等你，要对方在一个小时后收到说我来了～岂不尴尬？ |
上层软件不能判断吗？可以设优先级嘛。不同优先级费用不同，效果也不同，差异化服务。
-- 作者：tom
-- 发布时间：2004-04-13 08:21:28
| 以下是引用华人在2004-4-12 23:17:44的发言： 不过我决定首先应该尽量将超帧结构中的24000次/秒的潜力尽量挖出来，如果还不能满足要求那么只能划小PA，然后通过增加基站来抵消由于位置登记的增加的SCCH需要增加。PCH是一个全局资源不能通过增加基站解决，SCCH是一个局部资源可以通过增加基站来解决。当然增加基站将导致 TCH的干扰增加，那只有通过优化解决了！呵呵～～ |
现在是收短消息多还是发短消息多？注意两者优化方式是不一样的。
-- 作者：华人
-- 发布时间：2004-04-13 17:00:39
| 以下是引用tom在2004-4-13 8:21:28的发言： [quote]以下是引用华人在2004-4-12 23:17:44的发言： 不过我决定首先应该尽量将超帧结构中的24000次/秒的潜力尽量挖出来，如果还不能满足要求那么只能划小PA，然后通过增加基站来抵消由于位置登记的增加的SCCH需要增加。PCH是一个全局资源不能通过增加基站解决，SCCH是一个局部资源可以通过增加基站来解决。当然增加基站将导致 TCH的干扰增加，那只有通过优化解决了！呵呵～～ [/quote] 现在是收短消息多还是发短消息多？注意两者优化方式是不一样的。 |
当然是收多了，发一次可以引起收好多次，而且还有广播的广告。所以我们才会提出PCH的问题啊，要不然就要讨论SCCH的问题了，呵呵～～
-- 作者：transmit
-- 发布时间：2004-04-13 19:16:36
也不能这样说, 互联互通后还有发到其他网络的. 但是总的来说还是收的多, 短消息的问题归根到底是PCH的问题.
-- 作者：华人
-- 发布时间：2004-04-13 21:55:45
不过tom的分流想法倒是非常好的，至少我们现在可以将群发的广告短信安排在非忙时发送，这样可以平衡资源，提高利用率～～
-- 作者：cerolla
-- 发布时间：2004-08-17 11:38:02
| 以下是引用tom在2004-4-13 8:21:28的发言： [quote]以下是引用华人在2004-4-12 23:17:44的发言： 不过我决定首先应该尽量将超帧结构中的24000次/秒的潜力尽量挖出来，如果还不能满足要求那么只能划小PA，然后通过增加基站来抵消由于位置登记的增加的SCCH需要增加。PCH是一个全局资源不能通过增加基站解决，SCCH是一个局部资源可以通过增加基站来解决。当然增加基站将导致 TCH的干扰增加，那只有通过优化解决了！呵呵～～ [/quote] 现在是收短消息多还是发短消息多？注意两者优化方式是不一样的。 |
发送短信的流程相当于做一次主教，短信内容随SETUP消息传送，接受短信多了一个寻呼过程，信令流程和主被叫流程相似。可参照GSM的短信协议流程。PHS的PCH应该是24000次/小时。考虑到用户的随机分布性，现有的模型用户按平均分布设计。因此无有效方法应对点对点的短信风暴（集中在某个PA）。只能控制群发信息流量，降低拥塞的概率。
-- 作者：raind
-- 发布时间：2004-12-22 15:26:31
目前来说，除了系统侧做流控外，还没有什么特别好的办法.
-- 作者：wangjy
-- 发布时间：2004-12-27 22:32:10
各位版主，那么长时间过去了，大家有没有找到好的解决方法呀？
我们就碰到这个问题了。谢谢回复！
-- 作者：transmit
-- 发布时间：2005-01-06 13:46:50
UT基站的新版本对寻呼能力有了一定的增强，但对于大量的群发还是要靠流控。
-- 作者：zwdu
-- 发布时间：2005-01-09 21:46:52
"UT基站的新版本对寻呼能力有了一定的增强"类似于六个(?)超帧的周期内由CS完成对PCH的"一次存储多次(?)转发"的无线接入的分布式二级处理,增强了PCH的寻呼响应率,而不影响核心网侧的ACM.不知对否.
-- 作者：transmit
-- 发布时间：2005-01-11 10:25:15
楼上的话很拗口，还有问号，一下子消化不了。
新版本其实就是增加了缓存，由原先的3个增为6个，缓解了不同PS number在时域上的不平衡性，减少了溢出的可能性。
-- 作者：zwdu
-- 发布时间：2005-01-12 00:38:36
1.半月前听某公司PT工程师讲:一次PAGING向PA区发3次;实际的东西还未见到,当然用35的LCCH一看就知.
2."新版本其实就是增加了缓存，由原先的3个增为6个"这项PT工程师到未提及.假设6个缓存还不如2个一组由CS将一次PAGING"时域上"3次发送,寻呼成功率岂不更高.好象有的公司早已是这样做的.
拙见,请问transmit你是RD的吗?
[此贴子已经被作者于2005-1-12 0:47:42编辑过]
-- 作者：transmit
-- 发布时间：2005-01-12 15:02:17
先回答简单的问题：我不是RD的。
1、“一次paging向pa区发3次”，这应该是layer paging功能，即基站在空闲的PCH上自动重发；这和增强基站寻呼能力是两回事；
2、不太明白楼上的“2个一组由cs将一次paging"时域上"3次发送”，能否说得详细点？是说将PS number从模8加1改成模2加1吗？
-- 作者：zwdu
-- 发布时间：2005-01-12 22:34:52
transmit你好.
1. 你所描述的"增强基站寻呼能力"和"其实就是增加了缓存"已理解.
2.我所谓的“2个一组由cs将一次paging"时域上"3次发送”原意并不是说将PS number从模8加1改成模2加1,至于选用何种LCCH的超帧结构,换句话也就是UT和ZTE采用不同超帧的优劣性到目前本人都不是非常清楚. 抱歉,又牵扯到了设备制造商.
3.我的原意应和"即基站在空闲的PCH上自动重发"类似,请问transmit:以何算法在空闲的PCH上自动重发,"layer paging功能"的含义.
初入行,请各位多指教.
[此贴子已经被作者于2005-1-12 22:50:07编辑过]
-- 作者：transmit
-- 发布时间：2005-01-18 16:16:21
Layer paging，就是基站发了一条Paging后，如果下一个PCH为空闲，就知道重发一遍，当然，由于Paging是根据PS Number分组的，这个“下一个PCH”必定是在1.2秒以后了。这项功能可以增加寻呼到手机的成功率，但不能增强每小时的寻呼能力。
-- 作者：tianjiu
-- 发布时间：2005-02-27 15:29:13
IPAS可以通过升级CSC提高寻呼的最大次数，PAS只能裂化PA了，现在SP的群发很多，我们这里有一个县局春节期间就死了4次，PA最高寻呼达到19000次，晕啊！IPAS还可以通过网管来控制流量，浙江的IPAS系统年前就做了，以防万一啊！！！
目前已经有22条评论 >>> 发表你的见解