FTP上传业务和下载业务中的Qos参数会不一样吗？

enjoying007

有个问题：手机在发起FTP业务的时候，核心网如何知道本次业务请求是上传还是下载呢？
                  在PDP激活的时候，手机发送的PDP上下文请求中会指明吗？
                  如果PDP上下文请求 中指明， 核心网发来的Qos参数会不一样吗？
求高手指点~~

爱卫生

通过TFT（Traffic Flow Template)参数指明。包括了IP五元组等信息。例如端口号、IP地址等就能区分上下行的FTP应用了。但现网中，目前通用APN（xxwap、xxnet）都没有开启PDP二次激活功能，因此不区分FTP的Qos。因为TFT只有在secondary PDP激活时才在MS的请求消息中携带（Primary PDP激活不携带），所以实际上现网不会为这种通用APN的FTP业务提供额外的Qos保障，因为毕竟用户没有付这部分的费用。

核心网可以根据UE提供的Qos参数进行调整和协商。

enjoying007

多谢爱总，可不可以这样理解：
现网中，没有开启PDP二次激活，因此核心网无法从TFT参数中判别用户是上传还是下载。但是，从UE发来的Qos参数中可以判定上传或下载？
但是FTP类的GBR是不受保障的，是不是UE依然会发送这个参数？网络侧比较DL GBR和UL GBR即可判别？或者比较DL MBR和UL MBR？
（PS：GPRS EGPRS系统）

admin

1 纠正一个概念。FTP上传还是下载和UE的上行和下行PDU。FTP的上传和下载属于FTP应用层的消息才能区分，上传用put指令，下载用get或mget指令。这些核心网肯定区分不出来。有TFT也区分不出来，TFT也没有应用层的信息。讲究对等层的通信。但这个PDU是上行还是下行还是很容易区分的。Gb接口都通过BSSGP协议传送，上行的PDU和下行的PDU有专门的PDU类型，如UL PDU和DL PDU，SGSN看到就知道是上行还是下行了。如果这都区分不了，那SGSN估计该把寻呼请求发给GGSN了。
2 会发的。DL GBR 和UL GBR是分开的两个参数。不直接比较。SGSN只是把MS请求的DL GBR和签约的DL GBR以及SGSN的当前负荷做比较，不会拿DL GBR和UL GBR去比较，没有意义。

enjoying007

admin 发表于 2012-9-23 15:41
1 纠正一个概念。FTP上传还是下载和UE的上行和下行PDU。FTP的上传和下载属于FTP应用层的消息才能区分，上传 ...

这个应该是链路已建立成功，MS已开始传送或接受数据了，SGSN通过上下行PDU就可判断是上传还是下载了吧？

我的疑问是用户在发起业务的时候，网络侧（BSS、SGSN、核心网之间的协商）如何根据用户是上传还是下载分配不同的资源呢？如果是上传业务就分配上行多点时隙，下行分少点·····
而这个时候走的都是信令业务，没有PDU数据吧，按我的理解只能在协商过程中判断吧，问题还是归结到用户发起业务的时候是否会通知网络侧，本次业务的方向呢？

admin

没你想的那么复杂。又得纠正一下，时隙的分配和业务无关啊。完全是由PCU分配，通常手机支持3+1时隙。在建上行和下行TBF的时候就由PCU给手机分配，这时没有任何业务信息。得先梳理下业务过程。

1 建立上行和下行TBF，完成时隙、信道、频率等资源分配。

2 GPRS附着流程完成。和业务无关。

3 用户打开FTP程序准备上传或下载触发PDP激活流程。该流程中不会指明业务的方向（参见论坛信令流程实例版块的PDP激活流程），但会带请求的Qos和网络侧协商，包括上行和下行的GBR和MBR请求。

4 SGSN根据用户签约数据、自身能力完成协商。给MS分配一个Qos，通常都是Non-GBR代表尽力而为。如果BSC侧支持PFC(packet flow context)流程的话，则也可以参与Qos的协商。

5 用户开始FTP的上传或下载。无论上传或下载，都由BSC根据TBF分配的无线资源调度。

3、4、5部中无论是GMM信令消息还是用户的ftp payload，在Gb接口上传送，都是由BSSGP协议携带。PDU Type=0x01为UL-UNITDATA代表上行，PDU Type=0x00为DL-UNITDATA代表下行。所以网络侧很容易能够区分。

hycl5410

说下我的理解。
在网络中不存在PCRF，或者PCEF/GGSN不存在基于业务感知和控制的rule的情况下，整个primary PDP的qos协商都是跟业务无关的。与什么有关呢？
1）用户在激活PDP时请求的qos
2）用户对于该PDP的qos签约
3）核心网对用户的qos支持能力
由三者中最低值来决定用户最终得到的qos（激活PDP响应）。一般场景下，用户请求都是0，核心网不支持的情况也基本不存在（如果签约和请求GBR的话，可能会有一定影响），所以最常见的情况就是用户得到的qos就是其签约的qos。
那么当用户激活一个PDP的时候，得到的QOS就是固定的（不考虑RAT切换的情况）。之后再做任何业务，对于网络来说都一视同仁。

楼主期望的方式，在引入业务感知和策略控制功能的网络，是可能实现的：
假设2G下激活了一个PDP，协商得到ul MBR 20K dl MBR 64K，用户执行FTP上传操作，GGSN配置了相关检测，检测的结果是向PCRF查询对该业务流所应执行的策略，PCRF返回某QOS策略为ul MBR 64K dl MBR 64K，GGSN再向SGSN发起modify QOS过程，SGSN继续向PCU发起相关QOS修改的流程（假设PFC是支持的）。
这个过程可能需要很多网元都有相关配置并且支持。
当然，对于例子中FTP上传（put）业务流，目前还不知道哪家的GGSN可以支持这种深层检测。。。

综上，对于没有PCC架构的网络，激活PDP之后再修改QOS其实是一件比较困难的事；对于没有业务感知配置的网络，就不要谈基于业务来做某些控制或者策略。
所以还是要看楼主到底是在谈什么样的网络情况，因为现在的网络不管是业务感知还是策略控制，有部署的比没有部署的多。