问题已开启
(普通问题)
上行channel request和下行immediate assignment中的random reference不一致会是什么原因?
G网路测TEMS数据分析未接通时,层3信令中的上行channel request和下行immediate assignment中都有个random reference值,仔细看了下,一致时基本不会出现block call,但只要不一致,就会出现block call,求教高手这个random reference是怎么分配的?有什么作用?一般是什么原因导致上下行不一致?谢谢了
提问者: xiejiujie 提问时间: 2011-08-01
• CSFB至2G后,被叫上发pagingresponse,之后一直l连续收到ImmediATEasSIGNMEnt,8s后上发LAUreQUEst,导致未接 2016-06-07
• 以下关于立即分配(ImmediATEAsSIGNMEnt)和分配(AsSIGNMEnt) 2015-07-15
• 如何确认ImmediATEasSIGNMEnt消息是给本手机的 2015-04-13
• GSM信令Blocktype:NoImmediATEAsSIGNMEnt 2015-01-14
• DLRRImmediATEAsSIGNMEnt为何会在空闲态出现 2014-11-17
• gsm中ImmediATEAsSIGNMEnt中的信道描述信息在Normalburst中的哪里 2014-08-11
• ImmediATE AsSIGNMEnt Reject消息中的信息 2013-08-21
• ImmediATE AsSIGNMEnt Reject, Cuse:Reserved for future use,是SD拥塞吗? 2013-08-16
• 以下关于立即分配(ImmediATEAsSIGNMEnt)和分配(AsSIGNMEnt) 2015-07-15
• 如何确认ImmediATEasSIGNMEnt消息是给本手机的 2015-04-13
• GSM信令Blocktype:NoImmediATEAsSIGNMEnt 2015-01-14
• DLRRImmediATEAsSIGNMEnt为何会在空闲态出现 2014-11-17
• gsm中ImmediATEAsSIGNMEnt中的信道描述信息在Normalburst中的哪里 2014-08-11
• ImmediATE AsSIGNMEnt Reject消息中的信息 2013-08-21
• ImmediATE AsSIGNMEnt Reject, Cuse:Reserved for future use,是SD拥塞吗? 2013-08-16
问题答案
( 4 )
随机参考用于解决接入的冲突。
正常情况下无冲突时,手机发送Channel Request携带一个随机参考(Random Reference),网络侧如果响应该接入请求则回应Immediate Assignment带相同的随机参考。
有冲突时,两个手机发送Channel Request一般携带不同的随机参考,网络侧只会响应一个手机的请求,则回应Immediate Assignment带其中一个的随机参考。收到相同随机参考的手机继续介入过程,而另一个手机接入失败,随后重新发起接入。
极小概率时,当两个手机同时发起Channel Request携带完全相同的随机参考,只能够从更上层的后续过程区分了。
一般情况,网络侧提供服务时,没有理由发送不同的随机参考,除非特殊设置或者收到了干扰导致误码。
正常情况下无冲突时,手机发送Channel Request携带一个随机参考(Random Reference),网络侧如果响应该接入请求则回应Immediate Assignment带相同的随机参考。
有冲突时,两个手机发送Channel Request一般携带不同的随机参考,网络侧只会响应一个手机的请求,则回应Immediate Assignment带其中一个的随机参考。收到相同随机参考的手机继续介入过程,而另一个手机接入失败,随后重新发起接入。
极小概率时,当两个手机同时发起Channel Request携带完全相同的随机参考,只能够从更上层的后续过程区分了。
一般情况,网络侧提供服务时,没有理由发送不同的随机参考,除非特殊设置或者收到了干扰导致误码。
回答者:
jinshi
回答时间:2011-08-02 09:23
26 24
分析block call,应该和楼主说的这些没有什么直接关系吧!
查了资料也没有发现这条消息的内容
求高手解答
查了资料也没有发现这条消息的内容
求高手解答
回答者:
sdshaomb
回答时间:2011-08-02 09:23
25 28
random reference是随机鉴别符,用来区分同时发起呼叫的MS。解释如下:
MS 在Um接口的接入信道上(RACH)上向BTS 发送Channel Request 消息,主要包括
参数Establish Cause 和Random Reference,有用的信令消息为8bit,其中3~6bit 用来提供
接入网络原因,2~5bit 可以携带鉴别符。最多只能同时区分32 个MS,要进一步区分同
时发起请求的MS,还需要根据Um 接口上应答消息判断。
通过上面的描述,我们大致可以了解到,正常情况下我们发出的random reference 是23,下行immediate assignment中,回应给我们的random reference 也是23,只能说明在指配过程当中,网络侧找对了手机。至于为什么上下行不一致,也就只能看为什么指配失败了。如何分配的,个人理解是随机的。
你可以找一个 主叫发起呼叫,但马上连续质差,最后导致未接通的LOG看下,有可能上下行的random reference值是一致的,但是它还未接通,这和形成未接通的原因有关系,不仅仅局限在SD上。也就是说,上下行random reference的值是否一致,与block call不是一一对应关系,只是几率很大。个人理解,期待高手指正,共同学习
MS 在Um接口的接入信道上(RACH)上向BTS 发送Channel Request 消息,主要包括
参数Establish Cause 和Random Reference,有用的信令消息为8bit,其中3~6bit 用来提供
接入网络原因,2~5bit 可以携带鉴别符。最多只能同时区分32 个MS,要进一步区分同
时发起请求的MS,还需要根据Um 接口上应答消息判断。
通过上面的描述,我们大致可以了解到,正常情况下我们发出的random reference 是23,下行immediate assignment中,回应给我们的random reference 也是23,只能说明在指配过程当中,网络侧找对了手机。至于为什么上下行不一致,也就只能看为什么指配失败了。如何分配的,个人理解是随机的。
你可以找一个 主叫发起呼叫,但马上连续质差,最后导致未接通的LOG看下,有可能上下行的random reference值是一致的,但是它还未接通,这和形成未接通的原因有关系,不仅仅局限在SD上。也就是说,上下行random reference的值是否一致,与block call不是一一对应关系,只是几率很大。个人理解,期待高手指正,共同学习
回答者:
ilnn123
回答时间:2011-08-02 11:17
30 23
我也知道block call肯定不只是这个原因,我现在就是想知道什么原因导致网络找错手机,干扰?寻呼过载?拥塞?还是别的什么原因,期待高手
xiejiujie 2011-08-09 21:52
不是找错了手机,而是这条立即支配是发给别的手机的
立即指配是在AGCH上广播给同一寻呼组的所有MS的。
立即指配是在AGCH上广播给同一寻呼组的所有MS的。
LordDeSies 2012-06-05 10:52
路过,楼上高手
回答者:
zhouwang
回答时间:2011-08-03 17:05
25 33
联系我们 - 问通信专家 | Powered by MSCBSC 移动通信网 © 2006 - |