在ESM procedure中，UE發起的resource allocation/modification procedure

抱抱宝宝

hycl5410 发表于 2012-7-16 19:31
以下全是个人理解和猜测，没有任何根据啊：
靠手机的应用软件。
最简单的就是协议匹配，不需要啥太高深 ...

我觉得也UE侧也只能这样子干
现在也没协议提到怎么实现的问题啊
H大侠是做核心网的？
你知识面很广，佩服！

hycl5410

抱抱宝宝 发表于 2012-7-17 09:06
我觉得也UE侧也只能这样子干
现在也没协议提到怎么实现的问题啊
H大侠是做核心网的？

瞎混了几年而已，真正高手其实很少愿意出来说话的。
爱老大除外~~{:soso_e113:}

小米加芋头

hycl5410 发表于 2012-6-15 11:09
1.
EPS bearer identity EPS bearer identity 9.3.2 M V 1/2
这个不是很清楚么？EPC一定会知道这个PDN有 ...

1. EPS bearer identity EPS bearer identity 9.3.2 M V 1/2 这个不是很清楚么？EPC一定会知道这个PDN有哪些已经存在的bearer ID（5是一定存在的），假设这个用户的PDN只存在bearer id=5 （default），而之后在bearer resource req中请求了bearer id 6，那么必然网络会发activate而不是modify。同理，若已存在5&6，bearer resource req中请求了bearer id 6，并且某些属性发生变化（比如Required traffic flow QoS），那么网络应该会发modify。 很清楚也说错了。 bearer resource allocation消息中有两个bearer ID,一个是消息头中的，在该消息中固定填0（因为承载ID是MME分配的，不是UE分配的，此时UE要建新的承载，ID还没有分配，只能填无效值0），还有一个Linked EPS bearer identity填写默认的承载ID（如果默认承载是5，该字段固定是5），让网络识别是哪个PDN。所以上面的回答说ID一下是5一下是6是不可能的，如果只有一条默认承载，只能是5。 那么网络怎么回消息了？这个和厂家的实现有关，也与网络侧当前状态，UE申请的新承载特性有关。 比如UE原来有条默认流，现在又想新建一条流用来上网浏览网页。有的厂商认为同意建一天新的承载，就发起activate dedicated 流程。有的厂商觉得这个业务可以直接放在原来已有的一条承载上，则把原来的承载modify一下加一个pf即可。 实际上实现时，一般厂家都不会选择这种NAS消息来触发建立新业务（不需要UE发送bearer resource allocation 消息，而是直接在应用层发送业务请求消息），UE直接通过应用层告知网络侧，网络测直接发起activate dedicated 流程 。这样实现的好处是网络直接知道UE需要哪种应用而分配相应的资源，而不是通过NAS再转成应用才知道UE需要的应用。 问题2不用再回答了吧 版主说得很清楚

hycl5410

小米加芋头 发表于 2012-7-23 15:43

多谢多谢！
确实是我写错了。bearer ID是网络分配的，UE是无法请求的。

看24301－b30中对6.5.3        UE requested bearer resource allocation procedure和 6.5.4        UE requested bearer resource modification procedure应该是针对2中不同场景的流畅

6.5.3        UE requested bearer resource allocation procedure如下：
终端会携带制定的Qos(QCI)并可选择的携带GBR等信息，请求一个新的TFA的承载资源家里过程，属于完全新建的一个过程，最后出发的是网络侧发起的dedicate Bearer流程的新建或者修改。。

The purpose of the UE requested bearer resource allocation procedure is for a UE to request an allocation of bearer resources for a traffic flow aggregate. The UE requests a specific QoS demand (QCI) and optionally sends a GBR requirement for a new traffic flow aggregate. If accepted by the network, this procedure invokes a dedicated EPS bearer context activation procedure (see subclause 6.4.2) or an EPS bearer context modification procedure (see subclause 6.4.3).
If there is a PDN connection for emergency bearer services established, the UE shall not request additional bearer resources for this PDN connection.

终端应该携带Linked EPS barer identity 以及TFT的操作码
The UE shall include the EPS bearer identity of the default EPS bearer associated with the requested bearer resource in the Linked EPS bearer identity IE. The UE shall set the TFT operation code in the Traffic flow aggregate IE to "Create new TFT". In the Required traffic flow QoS IE, the UE shall indicate a QCI and, if the UE also includes a GBR, the additional GBR required for the traffic flow aggregate.

6.5.4        UE requested bearer resource modification procedure如下：
中断请求对已有的某指定TFA承载资源的修改或者释放，或者是替换、增加TFA中的packet filter来实现修改TFA，而对网络侧的影响是承载激活，修改，去激活，比6.5.3多了一个去激活承载
The purpose of the UE requested bearer resource modification procedure is for a UE to request a modification or release of bearer resources for a traffic flow aggregate or modification of a traffic flow aggregate by replacing packet filters or adding packet filters. When requesting a modification of bearer resources for a traffic flow aggregate or a modification of a traffic flow aggregate, the UE can modify the existing GBR. If accepted by the network, this procedure invokes a dedicated EPS bearer context activation procedure (see subclause 6.4.2), an EPS bearer context modification procedure (see subclause 6.4.3), or an EPS bearer context deactivation procedure (see subclause 6.4.4).
If there is a PDN connection for emergency bearer services established, the UE shall not request a modification of bearer resources for this PDN connection.
大概分如下几种场景，具体参考协议
To request a change of the GBR without changing the packet filter(s),
To request a modification of a traffic flow aggregate,
To request a release of bearer resources


以上2个流程启动的定时器分别是T3480和T3481

wenliu

小米加芋头 发表于 2012-7-23 15:43

实际上实现时，一般厂家都不会选择这种NAS消息来触发建立新业务（不需要UE发送bearer resource allocation 消息，而是直接在应用层发送业务请求消息），UE直接通过应用层告知网络侧，网络测直接发起activate dedicated 流程 。这样实现的好处是网络直接知道UE需要哪种应用而分配相应的资源，而不是通过NAS再转成应用才知道UE需要的应用。

很赞同这段。感觉bearer resource allocation 和 modify的过程 是从原来的UMTS继承过来。但是随着LTE的发展，应该不用着这两个过程。
我想根本问题应该在于，其实应该是我们现实中找不到相对应的用户场景来针对这两种procedure。

前面爱总提到
"3）如果是定制机，应该运营商会将自己的数据业务（飞信等）的TFT写入手机中，如果是非运营商的应用，应该应用开发者也会写入一个TFT来描述吧！例如飞信、米聊这种。"

其实这个模式也不用用户来发起QOS请求，并预装飞信的TFT。 以前有介绍飞信的帖子，也是从SIP协议演化而来，在早期的飞信版本上，还能从设置中找到类似SIP 域名的一个配置项（现在可能没有了）。
因此用户在手机侧要发起飞信业务，还是得和飞信业务相关的APN展开链接，那这个过程PCRF就可以提前和飞信的AS配合来决定是否建立dedicated Bearer。
每个应用应该都有个接入点，那有了接入点就好办了，应用层也有自己的控制信令和媒体面，PCRF和AF就在应用层的信令面进行监控就足够用来建立随后的IP tunnel。

因此看不出，UE有来发起QOS请求或者建立EBI的必要。

hycl5410

见仁见智吧，或者从不同角度来看，各方出发点不一样。
从网络设备商或者运营商角度来看，我的网络设计已经足够合理，能够对不同QOS需求的业务流给予合理的QOS，没必要再让UE请求一次；
但是从手机厂商角度来看，只有请求需求的QOS，才能保证业务流的正常，而且手机厂商应该也不会认为所有的运营商网络设置的QOS都与自己期望的值一致。

显然我们现在看到的EPC网络，UE请求的情况被边缘化，其实这样的也是正常的，因为QOS最终还是掌握在运营商手里（PCRF），不管你UE请求了什么。所以，就没必要搞那么复杂，简单直接，一切都交给网络来分配好了。

kongshiwen

使用实验室仪表打出来的报文，不是真实中网络报文。