请教一下关于QOS的问题。

爱卫生

原帖地址为：http://www.gprshome.com/forum.ph ... &extra=page%3D1。由会员zglaojiang提出。烦请高手解答。悬赏1个G点。谢谢！

问题如下：

“想请教一下大家，如果说用户在做激活的时候是成功的，但是由于网络环境不是很好，得到的最终QOS不是很高，不过依然可以做业务，比如FTP下载。然后过一会网络环境变得很好，这个时候QOS会不会自动提高。RNC会不会自动发起PDP修改流程来改变QOS值。

然后空口环境的变化会不会导致QOS的自动改变？RNC到SGSN之间的带宽资源紧张时会不会导致QOS的自动改变？烦请各位掌门拆解。感激不尽！”

hycl5410

这种场景在3GPP是有定义的。详细请看
TS 23.060
9.2.3.6        RAN-initiated RAB Modification Procedure (Iu mode)
TS 25.413
8.30        RAB Modification Request

但是具体实现起来涉及很多网元内部功能实现
1） RNC会不会触发这个流程，如何触发？不清楚。
2） CN是否接受？要看具体网元是否实现该功能，是否开启相关功能，请求的QOS是否是在支持范围内（用户签约，网元支持等）。

readhere

  我的理解是QoS与业务有关，与无线环境无关。在业务建立的过程中，核心网是不知道也是没有必要知道无线环境的。这就要求QoS要有一些弹性，比如PS都是一些尽力而为的业务，能确保最低流量就行了。
  至于无线环境变化导致用户速率的变化，就是前面说的QoS的弹性了。

wuwu

readhere 发表于 2012-5-15 22:01
我的理解是QoS与业务有关，与无线环境无关。在业务建立的过程中，核心网是不知道也是没有必要知道无线环境 ...

目前接触到的移动和联通的网络都是readhere描述的这样的

tony9492

QOS主要表现在对不同级别用户的无线资源分配调度的方面，对于高级别用户分配较多的无线资源，低级别用户分配较少的无线资源。
Qos参数在签约信息中定义好的，QoS不会根据无限环境的变化进行适配改变，不同的用户级别享受不同的服务，应该是这样吧。

hycl5410

其实说起来，QOS不是说签的是啥就一定能得到啥，在大部分场景下我们所谓的QOS都是MBR而不是BGR。MBR就如楼上readhere所说，是尽力而为的，是无保证的；
ARP参数一般用于无线资源紧张的时候的接入策略（比如金用户就可能会有更大的几率接入）；
另外一些参数（SDU error ratio这些）貌似也是无线用于调度用的，核心网一般都不太看这些东西（个人感觉也不会支持RNC重新协商这些参数）。

zs622

Qos参数在签约信息中定义好的，注意HLR中定义的用户订购QoS能力是该业务可以达到的最高QoS，最终协商和网络提供的QoS保障还受限于无线和核心网的资源。偶网上找到WCDWA网下的协商情况。


在手机进行PDP激活过程中，将有一系列的QOS协商过程，正常情况下，如果对方不支持高版本的QOS，则会发送消息进行协商。



（1）UE在附着网络时，HLR将用户签约的QoS（QoS签约）信息下发给SGSN。
（2）UE在发起PDP激活时，在激活请求消息中携带明确的QoS（QoS requested），向SGSN申请激活一个PDP上下文。
    // UE也可以通过将请求消息中的QoS参数值置0而不具体给出QoS需求，只表明默认使用HLR签约的QoS，这种情况只能进行非实时类业务（如交互类业务）。
（3）SGSN 根据签约的QoS检查用户是否有资格申请相关的QoS Profile，如果允许并且SGSN有足够的资源，则SGSN向GGSN申请创建一个PDP上下文，并带上相应的QoS请求（QoS negotiated 1）。
    // 如果SGSN当前资源不够时，能够对QoS Profile进行限制，降低QoS或者拒绝本次激活。
    // 如果用户在HLR中没有签约相应的QoS Profile，则按照配置，可以分两种处理：一种是认为该用户签约信息无效，无法进行数据业务，拒绝PDP激活；另一种处理是将SGSN当前的缺省QoS能力作为该用户签约QoS信息。
（4）如果GGSN有足够的资源满足业务QoS的需求，向SGSN回送一个PDP上下文创建成功消息，一个GTP隧道将在GGSN和SGSN之间建立。GGSN会根据自身的资源情况进行QoS的调整，将协商后的QoS信息（QoS negotiated 2）返回给SGSN。
（5）SGSN会根据与GGSN协商的QoS（QoS negotiated 2）通过信令通知RNC（Radio Access Bearer Service Attributes），允许由RNC去建立一个无线接入承载（RAB）。
（6）UTRAN执行内部的接入控制和资源预留，并向SGSN返回是否创建RAB成功（QoS negotiated 3）。如果UTRAN没有足够的资源，将返回RAB创建失败并在原因值中指明请求的QoS不能提供。
（7）SGSN会根据UTRAN返回的结果降低QoS属性（QoS negotiated 3）并再次向GGSN发起上下文更新请求。
（8）如果成功，GGSN在应答消息中将最终协商好的QoS参数（QoS negotiated 4）通过SGSN发送给手机，手机决定是否继续进行业务。
（9）如果手机接受网络的协商结果，至此满足相关QoS（QoS negotiated 4）的手机到GGSN的PDP上下文才建立完成。如果手机不能接受协商后的QoS属性，将发起PDP上下文去激活流程。

    在整个QOS协商过程中，SGSN起到主导角色，SGSN、GGSN、RNC可以根据本身的资源状况，进行业务QoS参数的调整，协商过后的QoS参数由SGSN在应答消息中发送给手机，手机决定是否继续进行业务。
    如果手机不能接受协商后的QoS属性，将发起PDP上下文去激活流程。

zs622

郁闷，权限不够不能发链接，详细见htt****p://****blog.sina.com.cn   /s/blog_6617106b0100qd67.****html
自己去星

天高云淡ah

如果用户的获得的QoS比签约的低，理论上网络应该要根据实际的资源状况（包括无线环境）为用户调整QoS，但一旦动态修改，就要涉及很多网元，实际测试中，貌似很少有见到PDP上下文修改消息，不知现网的实际情况。

yonka

我觉得可以引出另一个问题：
当网络侧根据多个节点的profile以及请求的profile和签约的profile协商好QoS（比如A）下发后，如果由于无线侧原因，比如用户所在地点无线覆盖差等，甚至是RNC的原因比如负荷较高等，是否会导致无线侧向网络侧要求降低QoS？
同样，当该情况改善后，是否会有相应的流程来恢复QoS？

还一个问题是，无线侧/RNC向CN要求恢复/增加该用户的QoS是以什么为依据呢？恢复到多少？根据ARP/THP来确定么？

enjoying007

学习了！！！！

tyytzy

非常感谢各位！！

browzor

{:soso__5663373028670280397_3:}

LTE目标

学习了！！！！