GPRS核心网基本架构（一）（补充QOS协商讨论）

爱卫生

   GPRS核心网主要包括SGSN/GGSN等主要节点。和固网的联系其实很紧密。例如GGSN很多厂家如爱立信,思科等的实现里实际上就是一台传统的路由器。
   从端到端的角度来看，关注架构，可以先从应用层开始着手。也就是从用户的上网开始了解。
   手机要上网，你可以把它看成其实是一台移动的PC，或者是一台装了WLAN网卡的移动PC。总之，它要上网的话，首先需要一个IP地址。另外，在计费这一块，和固网不一样，固网一般是按照包月来收费。而GPRS一般是按流量或者包月。不管怎么样，运营商需要在某个节点上开启对用户的流量的监管并进行计费。第三，和固网宽带不一样，GPRS是移动网络，服务于移动用户。所以要对用户的位置要清楚。所以多了一个移动性管理的功能。最后，每个用户的QOS是不一样的，也就是申请的带宽不一样，那也需要来保证。这几点就是要实现的基本目标，而如何完成就需要GSN等核心节点配合来完成。
先看第一点：
    一 IP地址的分配。这个是由GGSN来分配的。因为它是GPRS Gateway Service Node。从名字就可以看出来，它提供的是网关的功能。根据网关的定义，是两种异构网络的边界。所以GGSN是GPRS移动网络和固定宽带网络如Internet的边界。是手机的下一跳网络。所以手机的数据包下一跳都是交给GGSN，然后再发送到外部的数据网。GGSN和外部数据网的接口就是Gi接口。
     二 计费。这个也是在GGSN上完成的。因为用户实际的数据都是经过GGSN再发送到外部数据网。所以GGSN是最佳的用户数据包采集点，它可以对用户的IP数据包进行采集，统计，汇总，然后送给计费网关，最后生成计费账单。
     三 移动性管理。这个是由SGSN来完成的。移动运营商会将自己的网络分成很多个服务区然后分给不同的SGSN进行管理。用户的话总是在SGSN的服务区域里进行移动。后面会提到，SGSN的这个服务区域叫做RA，也就是路由区。路由区又包含多个小区，能跟踪用户当前在哪个小区。SGSN要知道用户在哪个小区来决定采取相应的行为。比如用户关机了，则需要通知GGSN收回用户的IP地址，将相应的会话删除，回收相应的网络侧资源给别的用户使用。
     四 QOS的管理。这个是由HLR来管理的。HLR是home location register。看名字不大好懂，实际上他是在存放归属地用户签约数据的节点。比如你是广州的卡，在广州开户。那你首先要到移动营业厅去开通GPRS业务并购买相应的套餐，如5元包50M等。这个套餐会变成一个节点能够识别的指令输入到HLR中，构成你的签约数据。例如你签约能访问哪个外部网络，是否允许直接访问internet还是只有wap网络。上下行的允许的带宽限制是多少。每月允许的最大流量是多少等等。这些信息在手机做网络登记即附着的时候会由SGSN到HLR上去下载，SGSN就得到了用户的QOS信息，并以此为依据对用户进行QOS的管理。

NightKiss

{:soso_e182:}每天学习一点点

janser

每天学习一点点

flove2001

刚刚由数通转行过来做GPRS核心网，版主的帖子入门起来真的很不错。版主要多多发帖啊，呵呵。我会常来光顾的。

爱卫生

回复 flove2001 的帖子

  谢谢你！和大家一起分享我也很开心。同样我自己也能进步。因为如果不分享，可能过两年，我自己都忘了。呵呵！

Albert

哎，那个号FLOVE2001．看了几个帖子，扣钱被降级了．．现在用这个号．在下的MSN:flove2001@msn.com有空加我啊．以后还得向版主请教．目前刚转行入职不到两周，还没接触到项目，通过版主的抓包再配合TS23.060，着实受益匪浅啊．希望版主能在对PDP上下文激活搞个视频．造福我们这些入门者啊．

爱卫生

回复 Albert 的帖子

   现在论坛有收费的帖子啊？怪我啦，不好意思。我记得我之前发的贴都只是设置了注册用户可见，但应该不扣费的啊。以后还有这种情况，可以使用站内短消息或首页的最下面的举报功能把链接发给我，如果是我发的，我一定会将收费的去掉的。谢谢！不过我很少上MSN，主要是平时杂事比较多。所以加了估计可能也见不到我哦！没关系的，我经常在论坛，多交流！

izturn

看一看，学习了！

xunfeng

学习学习,刚刚开始接触移动分组网.版主的帖子好good阿

xunfeng

可以这么问么:
MS访问数据业务,看版主的流程是到了GGSN才获取到一个IP地址,之后拿着这个IP地址到Internet上使用业务,在GGSN之前MS用的什么东东来标记自己的身份呢?是IMSI么?

爱卫生

回复 xunfeng 的帖子

当然可以这么问啊。
   实际上MS访问数据业务，包括两部分。先要进行GPRS网络的登记，使网络侧了解到你的存在及位置信息后，并且完成对你的身份进行确认。这一步是没有GGSN参与，也就是和Internet不相关的。对应的这个流程术语叫做GPRS的附着。标识MS的身份可以用P-TMSI、IMSI等来标识。
  附着完成之后，MS才能发起到数据业务的访问。对应的流程是PDP激活流程。因为GGSN后面连接的数据网络其实不光有Internet还有很多，例如企业网，WAP网络等（这些网络有个统一的名称叫PDN（Packet Data Network），它们很多信息都不一样。例如IP地址等。这些信息需要MS在PDP激活流程中指明。标识PDN是用APN来标识的。
  这就像如果去医院看病，不能直接去找医生看。首先要挂号，登记。然后你才能去看对应的科室，例如内科，外科等。每个科室的服务对象不一样，但都是医院的一个功能科室。你去看哪个科，这些信息应该是病人来提供。医院并不知道你要看哪个科。

kfclove

回复 爱卫生 的帖子

爱总，您写道的第四点“QOS管理”中提到的“这些信息在手机做网络登记即附着的时候会由SGSN到HLR上去下载，SGSN就得到了用户的QOS信息，并以此为依据对用户进行QOS的管理。”
是指手机做attach附着的时候就申请QOS吗？我看GB口attach信令怎么好像没有发现有携带相关QOS信息？而在PDP激活信令中有QOS消息。

kfclove

解压密码找到了

爱卫生

回复 kfclove 的帖子

  这个密码在论坛公告贴中的密码获取贴中刚更新不久。可能你没看到。其实在WINRAR压缩文件的右边注释侧有写解压密码是www.gprshome.com。加这个密码的目的纯粹是为了宣传目的。因为我还是希望能有更多的人了解这个网站，一起来分享。不便之处，请见谅哈！

爱卫生

回复 kfclove 的帖子

  呵，不用叫我爱总，叫我爱卫生就可以了。或者就叫斑竹也可以。
  你观察的很仔细啊。附着的阶段是SGSN去HLR下载关于MS的QOS签约信息，但在附着阶段并不涉及到对MS的QOS管理，MS的附着请求也不会携带请求的QOS。因为请求的QOS是针对PDN网络的某个应用来说的，打个比方视频需要100K的带宽，而WEB浏览只需要10K的带宽。而和PDN网络的应用是针对会话管理而言的。附着只涉及到PS的业务注册登记，没有和APN的交互，所以MS不需要发送请求的QOS，它也不知道发什么。因为在手机中可能有很多种应用需要访问（例如IPHONE中太多的应用），手机是不知道该请求哪个QOS的。只有在PDP激活时，MS才知道具体访问的是哪个应用，因为这个PDP激活实际上是由某个应用如网页浏览触发的。所以MS就会为这个应用请求相应所需要的QOS。而这时SGSN就可以根据在附着阶段从HLR上获取的MS签约的QOS（也就是你实际开通GPRS套餐时合约里写明的QOS），和你进行协商。或者说对你请求的QOS进行监管。这个过程实际上体现了GPRS网络中的QOS特性，采用的是协商机制。MS请求的，SGSN/GGSN支持的，HLR上用户签约的，还有RNC上能支持的，这几方的QOS取最小值作为最后MS实际能使用的QOS。

gprssanling

回复 爱卫生 的帖子


讨论："MS请求的，SGSN/GGSN支持的，HLR上用户签约的，还有RNC上能支持的，这几方的QOS取最小值作为最后MS实际能使用的QOS。"

1、"MS请求的Qos"应该不参与协商。
PDP激活请求消息中，请求的Qos两个字段值Maximum bitrate for uplink、Maximum bitrate for downlink都是0。如果参与协商，实际使用最大bit率为0，如何进行数据传送呢？

2、实际协商的最小值应该是用来做有保证bit率的。
实际bit率时刻是变化的，只能用最大、最小（有保证的（Guaranteed bitrate for uplink、Guaranteed bitrate for downlink））来界定这个服务质量，大家说对吧？

爱卫生

回复 gprssanling 的帖子

   谢谢你将话题展开哦。这又给了我去查规范的机会。否则我可能就比较懒不去查了。哈哈！
   以下是我的理解。
   根据规范TS23.060 V9.0.0中第9章关于PDP激活流程的描述，查到在PDP激活过程中。
1）MS会在激活请求消息里携带“Requested QOS”，这是MS希望的QOS，是上层应用程序下发下来，也就是应用程序开发者要写到程序里去的。原文是：QoS Requested indicates the desired QoS profile. For an E-UTRAN capable UE, the QoS requested shall include interactive or background traffic class in this message. If the UE is not E-UTRAN capable, in this release the QoS requested should include interactive or background traffic class in this message.
2）SGSN收到激活请求消息后，会做一些QOS的协商，原文为：The SGSN may restrict the requested QoS attributes given its capabilities and the current load, and it shall restrict the requested QoS attributes according to the subscribed QoS profile.然后SGSN再给GGSN发Create PDP Context Request。
3）GGSN收到创建PDP上下文请求后，也要做一个本地协商，原文为：The GGSN may restrict QoS Negotiated given its capabilities and the current load or increase the QoS Negotiated based on any external input (e.g. policy control).
4）SGSN收到GGSN回的Create PDP Context Resposnse消息后，还要做一个本地协商，原文为：The SGSN shall re-verify and may restrict the QoS Negotiated received in the response from the GGSN against the subscribed QoS profile and additionally restrict the QoS negotiated based on its capabilities and current load. The SGSN shall use this updated QoS Negotiated for the subsequent steps.并且SGSN会将这个最新的QOS下发给MS。
   以上是协商的流程。

1 MS参不参与QOS协商？
    答：我的理解是，还是要参与协商的，关于MBR查找了规范TS23.107 V9.0.0关于MBR和GBR的说明。
MBR:
---  maximum number of bits delivered by RAN and to RAN at a SAP within a period of time, divided by the duration of the period. The traffic is conformant with the Maximum bitrate as long as it follows a token bucket algorithm where token rate equals Maximum bitrate and bucket size equals Maximum SDU size.
The conformance definition should not be interpreted as a required implementation algorithm. The token bucket algorithm is described in annex B.
The Maximum bitrate is the upper limit a user or application can accept or provide.
   上一句说明了这个MBR是上层用户或应用（例如一些联机游戏）所支持的最大比特率。如果超过，可能上层用户不能完成重组和解析。另外解释提到的令牌桶是我们熟悉的一种QOS控制机制。对应到附录B，应该MBR可以看成是一种突发最大值。如果MBR=0，则代表这种应用不允许有突发流量。只允许这种应用按照GBR速率来传，如果GBR也没有，则不会丢弃，对按照Best Effort来传。GBR实际上你的最大平均速率，只要不超过就不会丢包。
    然后关于协商，我也是觉得用“最小值”这个词可能不太合适。在“信令流程”版块有个二次激活流程实例，里面的抓包就可以看到，MS在做二次激活时，有携带为下行数据请求的GBR，（在Primary PDP上下文激活请求中应该也可以带），是64kbps，但上行请求的为0.但在二次激活的Accept消息中，MS收到的协商后的QOS，上下行GBR都变成了64kbps。可参考Secondary PDP Context激活流程及实例 这篇贴。
   所以，我还是觉得MS需要参与协商。这主要是怕有些应用为了迎合终端用户，故意将请求的MBR，GBR定得很高，而网络侧则可以根据你的签约文件和实际的能力进行限制。如上面的例子。分以下几种场景：
1 如果MS请求的是64k，而签约的或网络侧实际能提供的有64k，则将给你实际分配64k。
2 如果MS请求的32k，而签约的或网络侧实际能提供的有64k，则网络侧也可以根据策略来决定给你实际分配64k或32k。
  所以，也不见得一定是最小值。

2 关于GBR和MBR的关系理解。
    答：我的理解是，GBR是运营商承诺的速率。例如签约为100k，如果没有达到，你就可以投诉。他是一个长期恒定的速率。而MBR是一个突发大小。 例如你签约的GBR是100k，则在任何一个时间段内，你的平均速率都不应低于100kbps，但如果超过，即使只超过10k，超过的部分也将被丢弃。MBR就是定义你后面这个超出的10k，允许你超，但时间不会太长。否则就变成GBR了。如果MBR为0，则只允许你按GBR来传送。能超出的具体时间由令牌桶机制来控制。要不断的加令牌才能转发。如果MBR太小，则令牌桶很短时间就溢出了，则就会被丢弃。

   以上是我的理解。请大家帮忙纠正，补充。特别是有参与过手机应用研发的朋友。谢谢！

爱卫生

  做个类比。就像我们在家用的宽带一样，假如你是买的2M包年1500的套餐。那2M就是你的GBR。那运营商应保证你的下载平均速率维持在2M左右。但只要你超过2M，就全部被丢包。因为你没有买MBR。如果只有GBR，则运营商在BRAS上要做速率限制就用Rate-Limit，而如果你有GBR+MBR，则允许你有突发，那在BRAS上限制就需要用到Traffic Policing and Traffic Shaping，即流量整形和监管,这种机制也是用的令牌桶来监管。可以允许你在一段时间周期内突发到3M（打个比方）。