使用帮助
关注公众微信
 读懂通信 LTE学习大使 登陆 搜索

>> 讨论PHS网络优化的方方面面
空中接口学园 → 空中接口技术的实施 → PHS网络优化 → [讨论]短信息问题
  发表一个新主题  发表一个新投票  回复主题 您是本文的第 25182 个阅读者　　浏览上一篇主题  刷新本主题   树形显示文章　浏览下一篇主题
 * 主题： [讨论]短信息问题 保存该页为文件  报告本帖给版主  显示可打印的版本  把本贴打包邮递  把本贴加入论坛收藏夹  发送本页面给朋友  把本贴加入IE收藏夹 
 华人 离线，有人找我吗？
  
  
  等级：多面手
  文章：184
  积分：
  注册：2003-07-14
给华人发送一个短消息 把华人加入好友 查看华人的个人资料 搜索华人在PHS网络优化的所有文章 点击这里发送电邮给华人 引用回复这个文章 回复这个文章第11楼
发文心情 
不过tom的分流想法倒是非常好的，至少我们现在可以将群发的广告短信安排在非忙时发送，这样可以平衡资源，提高利用率～～

----------------------------------------------
欢迎大家光临空中接口学园！
希望大家踊跃发言！

点击查看用户来源及管理<br>发贴IP：*.*.*.* 2004-04-13 21:55:45
 cerolla 离线，有人找我吗？
  
  
  等级：预备用户
  文章：2
  积分：55
  注册：2004-03-19
给cerolla发送一个短消息 把cerolla加入好友 查看cerolla的个人资料 搜索cerolla在PHS网络优化的所有文章 点击这里发送电邮给cerolla 引用回复这个文章 回复这个文章第12楼
发文心情 
以下是引用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）。只能控制群发信息流量，降低拥塞的概率。
点击查看用户来源及管理<br>发贴IP：*.*.*.* 2004-08-17 11:38:02
 raind 离线，有人找我吗？
  
  
  等级：预备用户
  文章：55
  积分：129
  注册：2003-12-26
给raind发送一个短消息 把raind加入好友 查看raind的个人资料 搜索raind在PHS网络优化的所有文章 点击这里发送电邮给raind 引用回复这个文章 回复这个文章第13楼
发文心情 
目前来说，除了系统侧做流控外，还没有什么特别好的办法.
点击查看用户来源及管理<br>发贴IP：*.*.*.* 2004-12-22 15:26:31
 wangjy 离线，有人找我吗？
  
  
  等级：学友
  文章：37
  积分：179
  注册：2004-10-14
给wangjy发送一个短消息 把wangjy加入好友 查看wangjy的个人资料 搜索wangjy在PHS网络优化的所有文章 点击这里发送电邮给wangjy 引用回复这个文章 回复这个文章第14楼
发文心情 
各位版主，那么长时间过去了，大家有没有找到好的解决方法呀？
我们就碰到这个问题了。谢谢回复！
点击查看用户来源及管理<br>发贴IP：*.*.*.* 2004-12-27 22:32:10
 transmit 离线，有人找我吗？
  
  
  等级：学长
  文章：511
  积分：
  注册：2004-02-27
给transmit发送一个短消息 把transmit加入好友 查看transmit的个人资料 搜索transmit在PHS网络优化的所有文章 点击这里发送电邮给transmit 引用回复这个文章 回复这个文章第15楼
发文心情 
UT基站的新版本对寻呼能力有了一定的增强，但对于大量的群发还是要靠流控。
点击查看用户来源及管理<br>发贴IP：*.*.*.* 2005-01-06 13:46:50
 zwdu 离线，有人找我吗？
  
  
  等级：学友
  文章：154
  积分：
  注册：2003-11-19
给zwdu发送一个短消息 把zwdu加入好友 查看zwdu的个人资料 搜索zwdu在PHS网络优化的所有文章 点击这里发送电邮给zwdu 引用回复这个文章 回复这个文章第16楼
发文心情 
"UT基站的新版本对寻呼能力有了一定的增强"类似于六个(?)超帧的周期内由CS完成对PCH的"一次存储多次(?)转发"的无线接入的分布式二级处理,增强了PCH的寻呼响应率,而不影响核心网侧的ACM.不知对否.


点击查看用户来源及管理<br>发贴IP：*.*.*.* 2005-01-09 21:46:52
 transmit 离线，有人找我吗？
  
  
  等级：学长
  文章：511
  积分：
  注册：2004-02-27
给transmit发送一个短消息 把transmit加入好友 查看transmit的个人资料 搜索transmit在PHS网络优化的所有文章 点击这里发送电邮给transmit 引用回复这个文章 回复这个文章第17楼
发文心情 
楼上的话很拗口，还有问号，一下子消化不了。
新版本其实就是增加了缓存，由原先的3个增为6个，缓解了不同PS number在时域上的不平衡性，减少了溢出的可能性。
点击查看用户来源及管理<br>发贴IP：*.*.*.* 2005-01-11 10:25:15
 zwdu 离线，有人找我吗？
  
  
  等级：学友
  文章：154
  积分：
  注册：2003-11-19
给zwdu发送一个短消息 把zwdu加入好友 查看zwdu的个人资料 搜索zwdu在PHS网络优化的所有文章 点击这里发送电邮给zwdu 引用回复这个文章 回复这个文章第18楼
发文心情 
1.半月前听某公司PT工程师讲:一次PAGING向PA区发3次;实际的东西还未见到,当然用35的LCCH一看就知.
2."新版本其实就是增加了缓存，由原先的3个增为6个"这项PT工程师到未提及.假设6个缓存还不如2个一组由CS将一次PAGING"时域上"3次发送,寻呼成功率岂不更高.好象有的公司早已是这样做的.
拙见,请问transmit你是RD的吗?


[此贴子已经被作者于2005-1-12 0:47:42编辑过]
点击查看用户来源及管理<br>发贴IP：*.*.*.* 2005-01-12 00:38:36
 transmit 离线，有人找我吗？
  
  
  等级：学长
  文章：511
  积分：
  注册：2004-02-27
给transmit发送一个短消息 把transmit加入好友 查看transmit的个人资料 搜索transmit在PHS网络优化的所有文章 点击这里发送电邮给transmit 引用回复这个文章 回复这个文章第19楼
发文心情 
先回答简单的问题：我不是RD的。
1、“一次paging向pa区发3次”，这应该是layer paging功能，即基站在空闲的PCH上自动重发；这和增强基站寻呼能力是两回事；
2、不太明白楼上的“2个一组由cs将一次paging"时域上"3次发送”，能否说得详细点？是说将PS number从模8加1改成模2加1吗？
点击查看用户来源及管理<br>发贴IP：*.*.*.* 2005-01-12 15:02:17
 zwdu 离线，有人找我吗？
  
  
  等级：学友
  文章：154
  积分：
  注册：2003-11-19
给zwdu发送一个短消息 把zwdu加入好友 查看zwdu的个人资料 搜索zwdu在PHS网络优化的所有文章 点击这里发送电邮给zwdu 引用回复这个文章 回复这个文章第20楼
发文心情 
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编辑过]
点击查看用户来源及管理<br>发贴IP：*.*.*.* 2005-01-12 22:34:52

本主题文章数22，分页： [1] [2] [3]

管理选项： 锁定 | 解锁 | 提升 | 删除 | move | 固顶 | 总固顶 | 奖励 | 惩罚 | 发布公告

Powered by：Old version
Copyright ©2002 - 2019空中接口学园 , 页面执行时间：62.012毫秒