51学通信技术论坛

 找回密码
 立即注册
搜索
楼主: 爱卫生
打印 上一主题 下一主题

NSAPI   [复制链接]

Rank: 9Rank: 9

懒

19#
发表于 2012-10-7 19:35:30 |只看该作者
gaoyang_fei 发表于 2012-10-7 18:26
a)如果 GGSN侧的 pdp update  request 是作为pdp上下文修改的一部分呢?这种情况下 用来修改MS 的ip 是不 ...

a) 是。MS IP一般不重新分配,否则影响用户体验。
b) 下行用户面是一定要修改的。因为服务的SGSN变了,否则GGSN还会将下行数据发给老的SGSN。其它可选。
c)没有。Gn口的信令只能由GSN节点来协商,和Gb口无关。换句话也就是说BSC和MS不需要关心TEID。
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 2Rank: 2

20#
发表于 2012-10-7 21:18:20 |只看该作者
本帖最后由 gaoyang_fei 于 2012-10-8 19:21 编辑
爱卫生 发表于 2012-10-7 19:35
a) 是。MS IP一般不重新分配,否则影响用户体验。
b) 下行用户面是一定要修改的。因为服务的SGSN变了,否 ...

不好意思 爱总 打错字了 第三个问题是  Gn口的信令还有那些会影响teid?

还有关于a问题到底ggsn侧的update 用来 进行ip修改常见不常见?你回答的前半句是“是”,后半句是否定,把我搞糊涂了。 我们要做一个上网用户的ip和imsi映射表 ,所以对这个比较关心,不常见但有改变ip的机会的的话,(如果准确率优先,不是性能优先的话)也要有代码在抓到update的时候进行处理,

                          还有在ggsn发起的update下 下行的控制面teid也是必须改变的吗 ,你在另一处对我的回答中提到update 过程 必定会改变下行的控制面teid  因为会话中的SGSN变了,(上行的控制面不必要变更吗?我看标准中只有data(I)是必须的?为什么?)这个不是在作为RAU流程的一部分才会更换SGSN吗 ?update 过程还有其他目的啊,比如更换Qos,所以SGSN不一定会变更啊?

          另一个问题  update response中如果原因值为不接受,那之前的pdp context呢?是不是teid不更新,还维持update 之前的值?

使用道具 举报

Rank: 9Rank: 9

懒

21#
发表于 2012-10-8 21:58:22 |只看该作者
gaoyang_fei 发表于 2012-10-7 21:18
不好意思 爱总 打错字了 第三个问题是  Gn口的信令还有那些会影响teid?

还有关于a问题到底ggsn侧的up ...

因为你的a问题问了两个问题。所以“是”是回答前一个问题。MS IP一般不重新分配是回答后一个问题。如下:

a)如果 GGSN侧的 pdp update  request 是作为pdp上下文修改的一部分呢?这种情况下 用来修改MS 的ip 是不是 很常见?

答:是。这种情况下,MS IP一般不重新分配,否则影响用户体验。不用担心update消息(对应的是PDP上下文修改流程)后用户的IP会变,可以说接近100%的情况下是不变的。以下是规范的原文(TS23.060的9.2.3节):“

The following parameters can be modified:
- QoS Negotiated;
- Radio Priority;
- Packet Flow Id;
- PDP Address (in case of the GGSN-initiated modification procedure);
- TFT (in case of MS- or GGSN-initiated modification procedure);
- BCM (in case of GGSN-initiated modification procedure); and
- Usage of Direct Tunnel.

”特意说明了PDP上下文修改流程中只有GGSN发起的PDP修改流程才可以修改UE的IP地址,其他场景都不行(例如RAU、切换等过程产生的update pdp context消息等)。但GGSN通常不会主动去发一个PDP修改流程更新UE的IP地址的,除非是人工在GGSN上触发了什么指令操作。

b)我是针对你的问题,针对Inter-SGSN RAU场景所触发的update pdp context消息,必须要更新用户面TEID,因为SGSN变了。如果是其他场景,例如只是更新Qos,那用户面TEID当然可以不变。规范里只是说用户面TEID是强制IE,一定要携带,并没有说一定要变啊。

PDP上下文更新失败,规范是这么说的。“If the SGSN receives an Update PDP Context Response with a Cause value other than "Request accepted", it shall abort the update of the PDP context.

If the SGSN receives an Update PDP Context Response with a Cause value "Non-existent", it shall delete the PDP Context.”

c)Gn接口只有update pdp消息可以修改GSN之间的TEID。Create用于创建,delete用于删除。

www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 2Rank: 2

22#
发表于 2012-10-9 10:16:16 |只看该作者
a)   关于"规范里只是说用户面TEID是强制IE,一定要携带,并没有说一定要变啊"携带不就是给对端重新分配吗?要不携带干嘛?

b)关于“PDP上下文更新失败,规范是这么说的。“If the SGSN receives an Update PDP Context Response with a Cause value other than "Request accepted", it shall abort the update of the PDP context.

If the SGSN receives an Update PDP Context Response with a Cause value "Non-existent", it shall delete the PDP Context.”
” 其他原因的情况呢,只说了non-existent的情况?

点评

admin  a) 携带的目的是为了让GGSN能够识别,不一定要重新分配。因为该TEID是GGSN分配的。b)其他情况是上面的红字"it shall abort the update of the PDP context".  发表于 2012-10-9 21:31:06

使用道具 举报

Rank: 2Rank: 2

23#
发表于 2012-10-10 10:42:41 |只看该作者
gaoyang_fei 发表于 2012-10-9 10:16
a)   关于"规范里只是说用户面TEID是强制IE,一定要携带,并没有说一定要变啊"携带不就是给对端重新分配吗 ...

上述两个问题想追问下。。我们只关心update流程过程中控制面的TEID,  1)如果信令中携带了(也就是给对端分配了),对端一定会更新到新的TEID吗?2)”abort update context  “          TEID还是维持create pdp context 过程后,update前的 TEID吗?

使用道具 举报

Rank: 9Rank: 9

懒

24#
发表于 2012-10-10 21:12:40 |只看该作者
1) GTP中的TEID有两个。一个是头部中的TEID,这是对方分的。还有一个是头部后面的信息元素部分。这里的TEID是分给对方GSN节点的。如果是信息元素部分携带了TEID,不管是否和原来创建时候的值相同,对方都要拿这个新值覆盖掉旧值。2)是的。

使用道具 举报

Rank: 8

义 超级之星 勤 论坛核心会员

25#
发表于 2012-11-4 10:39:07 |只看该作者
爱卫生 发表于 2012-10-3 09:49
呵呵,欢迎提问。说下我的个人理解。 a) 你说的对。SGSN传送下行数据报文给MS时,不会根据IP来传的。传送 ...

"a) 你说的对。SGSN传送下行数据报文给MS时,不会根据IP来传的。传送的是LLC PDU,IP已经被封装到里面了,是看不见的。IP地址从技术上来说,可能会重。例如MS同时激活了两个primary PDP,并且是在两个不同GGSN上建立的。那正好GGSN侧假设配置了相同的MS地址池,就有可能重。但这只是从技术上说的。运营商会从整体规划上避免这一点。给不同的GGSN来分配不同的地址池来避免。"

爱总,MS的地址冲突会有影响吗?如你所说的不同GGSN的地址池重复的话?
1、我感觉如果同一个运营商,比如XXCM,如果多个GGSN的地址池冲突的话可能会有影响。因为从下行方向来说,防火墙做NAT转换后可能会下发给错误的GGSN。
2、同一个GGSN的不同APN的道理也一样吧?但alex中提到的使用routing instance来隔离不同APN的话可以重复使用地址池是如何理解呢?从下行方向,防火墙到GGSN还是不知道怎么下发吧?
3、但如果不同运营商的话或者XXCM和YYCM这样的,应该没关系吧?


欢迎多多交流

PS CORE & SS7 & SIGTRAN & IP

有相关的专业技术网站/Q群也多谢推荐

使用道具 举报

Rank: 8

义 超级之星 勤 论坛核心会员

26#
发表于 2012-11-4 10:41:49 |只看该作者
爱卫生 发表于 2012-10-2 22:57
因为问题比较多。不确定能否全部回答了。如果漏了,再提醒我吧。1)一次激活和二次激活中的控制面的TEID是 ...

1)一次激活和二次激活中的控制面的TEID是一样的(参见论坛的PDP二次激活实例帖子),NSAPI不同。如果是两个Primary PDP,两者的TEID无任何关系,NSAPI是递增的,从5开始分配。数据面TEID不一样。

爱总,同一个用户不同primary PDP上下文间NSAPI也是递增的吗?还是独立使用?
比如使用CMWAP激活了一个primary然后再激活一个CMWAP的secondary,再激活一个CMNET的primary。这三个PDP上下文都占用同一个5~11吗?

点评

爱卫生  一定是递增。NSAPI是针对一个用户数所有的PDP上下文来说的,并不是说针对一个APN来说。所以用户最多同时只能有11个PDP上下文(含CMWAP、CMNET等等)。  发表于 2012-11-4 14:54:08
欢迎多多交流

PS CORE & SS7 & SIGTRAN & IP

有相关的专业技术网站/Q群也多谢推荐

使用道具 举报

Rank: 9Rank: 9

懒

27#
发表于 2012-11-4 14:58:16 |只看该作者
yonka 发表于 2012-11-4 10:39
"a) 你说的对。SGSN传送下行数据报文给MS时,不会根据IP来传的。传送的是LLC PDU,IP已经被封装到里面了, ...

1 没事的。防火墙现在全部都是状态化防火墙,即可以记录用户的session状态的。所以你是从哪个端口来的,回来也从哪个端口下发。防火墙不会弄错的。

2 用VPN实例隔离后就不会有问题了。如果两个VPN实例连接到一个相同的没有划分VPN的防火墙,这就不叫VPN了。所以采用了VPN实例划分的话连接防火墙,那要么是两个不同的防火墙,或者是同样划分了两个VPN实例的一个物理防火墙。所以不会弄错的。

3 跨运营商就更没问题的。运营商之间还有防火墙以及采用不同的地址规划呢。

www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 2Rank: 2

28#
发表于 2013-1-24 13:04:15 |只看该作者
gaoyang_fei 发表于 2012-10-7 18:26
a)如果 GGSN侧的 pdp update  request 是作为pdp上下文修改的一部分呢?这种情况下 用来修改MS 的ip 是不 ...
a)如果 GGSN侧的 pdp update  request 是作为pdp上下文修改的一部分呢?这种情况下 用来修改MS 的ip 是不是 很常见?
b)update 为什么要修改上下行的 teid呢? 且我见到的包 在response里面 只有 data teid,没有修改控制面的teid,这是为什么呢?
c)追问下在Gb口之间,还有什么信令是会改变一对GSN之间的teid的?

a)GGSN修改MSIP是作为初始连接时动态分配IP使用的,后续不会更改MSIP。
b)Update会修改下行TEID,上行TEID不会更改。这个问题我最近刚翻过规范,上行TEID在Release7以前版本中GTPv0向GTPv1切换的时候有可能更改,其他情况不会携带。


使用道具 举报

Rank: 3Rank: 3Rank: 3

29#
发表于 2013-6-9 14:10:57 |只看该作者
爱总,实际现场测试中,怎么在终端上激活primary PDP和secondary PDP,second PDP呢?IOS系统,android系统,sybiam系统,上网卡上分别是该如何触发的?

点评

admin  这个不太清楚哦。需要看具体的终端吧。另外AT指令集没有仔细研究过能不能发起secondary pdp。primary肯定可以的。  发表于 2013-6-9 16:32:37

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

站长邮箱|Archiver|51学通信 ( 粤ICP备11025688 )

GMT+8, 2024-11-26 03:31 , Processed in 0.048114 second(s), 10 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部