- 在线时间
- 426 小时
- 最后登录
- 2013-12-24
- 威望
- 8
- 金钱
- 3676
- 贡献
- 230
- 注册时间
- 2011-7-13
- 阅读权限
- 70
- 主题
- 85
- 帖子
- 507
- 分享
- 0
- 精华
- 0
- 积分
- 4429
- 相册
- 0
|
本帖最后由 yonka 于 2012-9-11 15:29 编辑
之前看到爱总在其他一个帖子里提到的:
如果是RAU的话,获取context失败时会以CC9拒绝RAU,终端收到CC9会删除P-TMSI而发起IMSI附着。但对于P-TMSI附着的话则可能不会回CC9而起发起identification procedure向MS获取。
但在MCON时,我看到alex文档中有下面的描述:
In the MOCN constellation, when the UE performs a Routing Area Update (RAU), if an invalid NRI, which means the P-TMSI is wrong, is included in RAURequest message due to defects of some mobile terminals, the RNC may select the wrong SGSN . If the query fails (this includes an external DNS-server query, local RAI-table query, or local NRI-table query, depending on the operator's configuration) or there is no Gn/Gp interface between the new and old SGSN , the new SGSN cannot get the Mobility Management and PDP contexts from the old SGSN. The new SGSN will then fetch the IMSI from the UE by means of an identification procedure(当无法从老的SGSN获得MM和PDP上下文的话,会通过identification流程向UE获取...). The RAU Request message together with the IMSI is then redirected to the correct SGSN by the RNC .
Fetching IMSI over the air is an enhancement to the licensed MOCN feature. It can be turned on or off using the function parameter fetch_imsi_no_gp by the CLI command modify_node_function. For more details, see Parameter Description and Feature Management (CLI).
为什么MCON时即使RAU获取上下文失败也不会拒绝而是UE获取呢?
并且为何说“Fetching IMSI over the air is an enhancement to the licensed MOCN feature”,获取IMSI不是正常的流程吗?即使不在MCON的情况下?
谢谢
|
|