CN103096180A - 流媒体QoS保障方法及*** - Google Patents

Abstract

本发明公开了一种流媒体QoS保障方法及***，上述方法包括：预置的MediaProxy为存储了UE所需资源的Cache分配本地地址信息，并告知P-GW上述本地地址信息；P-GW使用上述本地地址信息建立专用承载并进行承载绑定；MediaProxy根据Cache的地址信息与上述本地地址信息的对应关系通过上述承载在UE及Cache之间转发媒体流。通过本发明的技术方案，解决了现有IMS P2P CDS网络中，对分处于不同的位置的Cache生成TFT的时候可能造成TFT中的IP过滤准则数目超过目前协议限定的15个的问题，达到了减少TFT中的IP过滤准则数目的效果。

Description

流媒体QoS保障方法及***

技术领域

本发明涉及通信领域，具体而言，涉及一种流媒体QoS(Quality of Server，服务质量)保障方法及***。

背景技术

P2P是Peer-to-Peer的缩写，常称为对等互联或者点对点技术。相对于传统的C/S(client/server，客户端/服务器)模式而言，P2P网络中的不同Peer节点之间无需经过中继设备直接交换数据或服务，每个节点的地位都是对等的，拥有对等的权利和义务。如图1所示，在P2P网络中，每个节点既可以从其他节点得到服务，也可以向其他节点提供服务。由于P2P技术能够极大缓解传统C/S架构中服务器端的压力过大、单一失效点等问题，又能充分利用终端的丰富资源，所以P2P技术在文件共享、流媒体、语音通信及在线游戏支撑平台等方面已经获得广泛应用。

P2P流媒体业务主要是采用P2P技术进行流媒体传输，例如PPLive就是典型的P2P流媒体业务，即采用P2P技术实现视频点播或者直播。当P2P流媒体业务在电信网络实现时，为了实现对P2P业务的计费和管控，一种较好的实现方式是在现有的IMS(IP MultimediaSubsystem，IP多媒体子***)网络之上构建PPSP(P2P Streaming Protocol，P2P流媒体协议)网络，即IMS P2P CDS(IMS P2P Content Delivery Service，基于IMS的P2P内容传输业务)网络。一个典型的IMS P2P CDS***架构如图2所示，包含如下网元：

UE(User Equipment，用户设备)：发起业务请求并进行终端侧相应的业务处理功能。

MME(Mobility Management Entity，移动管理实体)：接入侧网元，主要负责移动性管理、承载管理等功能。

P-GW(Packet Data Network Gateway，分组数据网络网关)：接入侧网元，管理3GPP接入和non-3GPP接入间的移动，还负责策略执行、计费等功能。

PCSCF(Proxy-Call Session Control Function，代理呼叫控制功能)：IMS核心网网元，用于终端接入到IMS核心网。另外，当PCSCF作为应用层功能和RCF对接时(即由PCSCF充当AF(Application Function，应用功能)时)，还具备如下功能：PCSCF将业务层的QoS需求承载在Diameter(“直径”)消息中下发给RCF(Resource Control Function，资源控制功能)，RCF向其返回执行结果。

SCSCF(Session-Call Session Control Function，会话呼叫控制功能)：IMS核心网网元，用于对用户的认证鉴权，会话控制和业务触发。

Tracker(内容跟踪服务器)：存储资源索引信息，如某个特定的Cache(内容缓存服务器)中存储的资源信息。另外，当Tracker作为应用层功能和RCF对接时(即由Tracker充当AF时)，还具备如下功能：

根据用户终端能力等信息决策出业务QoS需求；

和RCF交互，将业务层的QoS需求承载在Diameter消息中下发给RCF，RCF向其返回执行结果。

Cache：存储具体的资源，如影片内容分片等。

RCF：负责接收来自业务实体的业务QoS请求，结合运营商策略和用户签约等信息制定相应的资源控制策略，并下发给REF(Resource Enforcement Function，策略执行功能)执行。此外，RCF还可以接收REF上报的事件，发送给相应的业务层功能实体(如PCSCF或Tracker)。

REF：根据RCF下发的资源控制策略进行QoS策略实施和门控、事件上报等功能。REF是个逻辑功能，可以部署在多个网元中。在本架构中REF部署在P-GW网元中。

在上述架构中，Tracker和Cache是在IMS网络基础上增加的网元，其余都是IMS中的网元。

在IMS P2P CDS网络中，运营商需要对流媒体业务提供QoS保障，以此来保证用户体验(例如保证用户收看视频的流畅度以及低延时等)。

目前在传统IMS网络中，现有的QoS保障机制可以通过如下方式实现：P-GW根据QoS策略和UE之间建立专用承载，该专用承载相当于UE和P-GW之间建立的一个专用通道，UE的媒体流承载在专用通道上，以此来保障该UE请求的业务的服务质量。由于P-GW在同一时间会同时接收到很多不同用户的不同业务的媒体流，并且P-GW也会为很多UE建立各自不同的专用承载，为了区分收到的各个媒体流应该跑在哪个对应的承载上，P-GW需要使用TFT(Traffic Flow Template，流量模板)，TFT相当于IP过滤准则和专用承载对应关系的集合，UE的过滤准则可以由RCF发送给P-GW，过滤准则中包含UE和远端的媒体面的IP地址和端口号等信息，这些信息可以用来标识UE的某个或多个特定的媒体流。P-GW为UE的过滤准则和将要为UE建立的专用承载的标识之间建立对应关系(即生成TFT)，由于过滤准则可以标识UE特定的媒体流，因此根据这个建立的对应关系即可以确定P-GW收到的媒体流分别应该跑在哪个专用承载上。在IMS P2P CDS网络，上述现有的QoS机制的实现流程如图3所示(仅描述了Tracker充当AF的场景，PCSCF充当AF的情况类似)：

步骤S302-步骤S306：UE通过IMS核心网发起内容业务请求，向Tracker请求拥有目标资源的节点列表，消息中携带UE要请求的内容信息等。

步骤S308-步骤S310：Tracker获取存储了该内容的Cache的地址信息列表，并生成业务QoS需求。

步骤S312：Tracker向RCF发送资源预留请求，消息中携带业务QoS相关信息、UE标识、UE的媒体面地址和端口列表以及Tracker选择的Cache的媒体面地址和端口列表，这里Cache可以是多个。

步骤S314-步骤S324：RCF生成QoS决策，之后向P-GW发送策略执行请求消息通知创建承载，消息中携带UE的媒体面IP地址和端口列表以及Cache的媒体面地址和端口列表等信息。P-GW根据上述信息建立TFT，并通知UE建立无线承载，之后向RCF发送策略执行响应消息，通知RCF策略已经执行完成。RCF收到后向Tracker返回资源预留响应消息，通知Tracker资源已经预留完成。

步骤S326-步骤S330：Tracker向UE发送应答消息，消息中携带Tracker获取的Cache地址列表。

步骤S332-步骤S338：UE向所选择的Cache发送内容请求，Cache向其返回内容请求响应，之后Cache通过之前建立的EPS承载开始向UE发送媒体流。在这个过程中，媒体流将会通过TFT绑定到之前已经建好的专用承载上，从而保障流媒体的QoS。

以上是目前现有的QoS机制的实现流程。而根据3GPP的TS 24.008协议，一个UE在相同的P-GW中生成的TFT中所包含的IP过滤准则个数不能超过15个。但在IP过滤准则的生成方式中，如果端口或者IP地址是连续的，那么可以采用范围或掩码的方式来描述，使得具备连续端口或IP地址的多条地址信息生成一条IP过滤准则。在IMS P2P CDS网络中，由于P2P技术的特殊性，UE可能会从多个Cache同时下载内容分片，这些Cache的数目可能超过了15个，并且各个Cache由于是分处于不同的位置的实体可能造成他们之间IP地址和端口不是连续的，无法简单地用地址掩码和端口范围来描述，因此在P-GW为这些Cache生成TFT的时候有可能造成TFT中的IP过滤准则数目超过协议限定的15个。针对这个问题，目前尚未提出有效的解决方案。

发明内容

针对现有IMS P2P CDS网络中，对分处于不同的位置的Cache生成TFT的时候可能造成TFT中的IP过滤准则数目超过目前协议限定的15个，从而导致流媒体QoS得不到保障的问题，本发明提供了一种流媒体QoS保障方法及***，以解决上述问题。

根据本发明的一个方面，提供了一种流媒体QoS保障方法，包括：预置的MediaProxy为存储了UE所需资源的Cache分配本地地址信息，并告知P-GW上述本地地址信息；P-GW使用上述本地地址信息建立专用承载并进行承载绑定；MediaProxy根据Cache的地址信息与上述本地地址信息的对应关系通过上述承载在UE及Cache之间转发媒体流。

上述本地地址信息是连续或部分连续的；和/或上述本地地址信息与Cache的地址信息一一对应。

在MediaProxy为Cache分配上述本地地址信息之前还包括：Tracker或UE向MediaProxy发送携带有Cache的地址信息和/或UE的最大连接数的分配地址请求消息。

P-GW使用上述本地地址信息建立专用承载并进行承载绑定包括：MediaProxy向Tracker或UE返回携带有上述本地地址信息的分配地址响应消息；Tracker或UE根据上述本地地址信息生成IP过滤准则并发送给P-GW；P-GW根据IP过滤准则建立专用承载，并对专用承载进行绑定。

MediaProxy根据Cache的地址信息与上述本地地址信息的对应关系通过上述专用承载在UE及Cache之间转发媒体流包括：Cache将发送给UE的媒体流数据包发送至MediaProxy；MediaProxy接收到该媒体流数据包后，根据上述对应关系将该媒体流数据包的源地址信息修改为Cache的地址信息对应的本地地址信息，由P-GW将该媒体流数据包通过上述专用承载发送至UE。

MediaProxy根据Cache的地址信息与上述本地地址信息的对应关系通过上述专用承载在UE及Cache之间转发媒体流还包括：UE获取上述本地地址信息；UE在向Cache的媒体面发送数据包时，将上述本地地址信息作为目标地址信息，由P-GW将该数据包通过上述专用承载发送至MediaProxy；MediaProxy收到该数据包后，根据上述对应关系将该数据包的目标地址信息由与Cache的地址信息对应的本地地址信息修改为Cache的地址信息，将该数据包发送至Cache。

UE获取上述本地地址信息包括以下之一：UE接收MediaProxy返回的携带有上述本地地址信息的分配地址响应消息；Tracker接收MediaProxy返回的携带有本地地址信息的分配地址响应消息，再将上述本地地址信息转发给UE。

上述分配地址请求消息还携带有UE的地址信息；在MediaProxy为Cache分配上述本地地址信息或MediaProxy将UE发送给Cache媒体面的数据包的目标地址信息由与Cache的地址信息对应的本地地址信息修改为Cache的地址信息之后还包括：MediaProxy为UE的地址信息分配相应的UE本地地址信息，其中，UE的地址信息与UE本地地址信息一一对应；在MediaProxy将UE发送给Cache媒体面的数据包的目标地址信息由与Cache的地址信息对应的本地地址信息修改为Cache的地址信息之后还包括：MediaProxy根据UE的地址信息与UE本地地址信息的对应关系将UE发送给Cache媒体面的数据包的源地址信息由UE的地址信息修改为与之对应的UE本地地址信息；在MediaProxy将Cache发送给UE的媒体流数据包的源地址信息修改为Cache的地址信息对应的本地地址信息之后还包括：MediaProxy根据UE的地址信息与UE本地地址信息的对应关系将Cache发送给UE的媒体流数据包的目标地址信息由与UE的地址信息对应的UE本地地址信息修改为UE的地址信息。

MediaProxy为Cache分配上述本地地址信息之后还包括：当Cache的地址信息发生变更后，MediaProxy根据变更后的Cache的地址信息更新或新建Cache的地址信息与上述本地地址信息的对应关系。

在MediaProxy根据变更后的Cache的地址信息更新上述对应关系之前还包括以下之一：MediaProxy通过DPI(Deep Packet Inspection，深度包检测)获取变更后的Cache的地址信息；UE通过Tracker通知MediaProxy变更后的Cache的地址信息。

根据本发明的另一方面，提供了一种流媒体QoS保障***，包括：MediaProxy，用于为存储了UE所需资源的Cache分配本地地址信息，并告知P-GW上述本地地址信息，以及根据Cache的地址信息与上述本地地址信息的对应关系通过UE对应的专用承载在UE及Cache之间转发媒体流；P-GW，用于使用上述本地地址信息建立上述专用承载并进行承载绑定。

通过本发明，采用设置MediaProxy，由MediaProxy为存储了UE所需资源的Cache分配连续或部分连续的本地地址信息，并记录Cache的地址信息与上述本地地址信息的对应关系，根据上述对应关系通过UE对应的专用承载在UE及Cache之间转发流媒体的业务数据的方案，解决了现有IMS P2P CDS网络中，对分处于不同的位置的Cache生成TFT的时候可能造成TFT中的IP过滤准则数目超过目前协议限定的15个的问题，达到了减少TFT中的IP过滤准则数目的效果，使得现有***可以在不违背现有协议对于TFT和IP过滤准则数目的规定的前提下提供P2P流媒体业务的QoS机制。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是P2P网络原理示意图；

图2是现有IMS P2P CDS网络的功能结构示意；

图3是现有IMS P2P CDS网络中QoS保障机制的流程图；

图4是根据本发明实施例的流媒体QoS保障方法的流程图；

图5是根据本发明实例的流媒体QoS保障方法应用的***结构示意图；

图6是根据本发明实施例一的流媒体QoS保障方法流程图；

图7是根据本发明实施例二的流媒体QoS保障方法流程图；

图8是根据本发明实施例三的流媒体QoS保障方法流程图；

图9是根据本发明实施例四的流媒体QoS保障方法流程图；

图10是根据本发明实施例五的流媒体QoS保障方法流程图；

图11是根据本发明实施例六的流媒体QoS保障方法流程图；

图12是根据本发明实施例的流媒体QoS保障***的结构框图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

图4是根据本发明实施例的流媒体QoS保障方法的流程图。如图4所示，根据发明实施例的流媒体QoS保障方法包括：

步骤S402，预置的MediaProxy为存储了UE所需资源的Cache分配本地地址信息，并告知P-GW上述本地地址信息；

步骤S404，P-GW使用上述本地地址信息建立专用承载并进行承载绑定；

步骤S406，MediaProxy根据Cache的地址信息与上述本地地址信息的对应关系通过上述专用承载在UE及Cache之间转发媒体流。

本实施例提供的方法，利用了IP过滤准则的生成方式中，端口或者IP地址(即地址信息)连续时，可以采用范围或掩码的方式来描述，使得具备连续端口或IP地址的多条地址信息生成一条IP过滤准则的特点，为存储了UE所需资源的Cache再次分配了MediaProxy本地地址信息，使用该MediaProxy本地地址信息间接的表示Cache自身的地址信息，后续MediaProxy也会根据上述对应关系在UE及Cache之间转发流媒体的业务数据，这样，即使Cache自身的地址信息是分散的，通过控制MediaProxy本地地址信息连续的程度也可以保证最终生成的IP过滤准则不会超于目前标准规定的15个，从而保证了UE及Cache之间的业务数据始终在UE对应的专用承载上转发，确保了流媒体的QoS。

优选地，上述本地地址信息可以是连续或部分连续的，上述本地地址信息也可以是与Cache的地址信息一一对应的。

由上述IP过滤准则的生成方式的特点可知，上述本地地址信息最好是连续的，或者至少是部分连续的，这样即可大幅降低生成的IP过滤准则的数目。同时，在资源允许的情况下，最好保证上述本地地址信息是与Cache的地址信息一一对应的，以避免传输冲突或错误的出现。

MediaProxy本地地址信息分配的触发可以由现有***中的多个实体实现，但在现有流程的基础上，由Tracker或UE为MediaProxy提供Cache地址信息，并触发MediaProxy为Cache分配连续或部分连续的MediaProxy本地地址信息改动最小，实现起来最为容易。优选地，在MediaProxy为Cache分配MediaProxy本地地址信息之前还可以包括：

Tracker或UE向MediaProxy发送携带有存储了UE所需资源的Cache的地址信息和/或UE的最大连接数的分配地址请求消息。

获取存储了UE所需资源的Cache的地址信息是MediaProxy分配MediaProxy本地地址信息的基础，在具体实施过程中，也可以将UE的最大连接数同时发送给MediaProxy，这样MediaProxy只分配与UE的最大连接数相同的MediaProxy本地地址信息即可，大大减少了MediaProxy的负担。

P-GW使用MediaProxy本地地址信息建立专用承载并进行承载绑定的方式可以是多种多样的，但其目的都是将再分配的MediaProxy本地地址信息作为生成IP过滤准则的依据，本优选实施例在现有流程的基础上给出一种优选地实施方式。优选地，P-GW使用上述本地地址信息建立专用承载并进行承载绑定可以包括：

MediaProxy向Tracker或UE返回携带有上述本地地址信息的分配地址响应消息；

Tracker或UE根据上述本地地址信息生成IP过滤准则并发送给P-GW；

P-GW根据上述IP过滤准则建立专用承载，并对专用承载进行绑定。

MediaProxy为存储了UE所需资源的Cache再次分配了MediaProxy本地地址信息后，要将分配的MediaProxy本地地址信息通知Tracker或UE，使Tracker或UE根据MediaProxy本地地址信息生成IP过滤准则，再由P-GW根据上述IP过滤准则生成专用承载并进行承载绑定，最简单的方式就是由MediaProxy直接向Tracker或UE返回携带有上述本地地址信息的分配地址响应消息。这里，进行承载绑定也就是使用由IP过滤准则生成的TFT将IP流绑定到不同的承载的过程，TFT实际上相当于IP过滤准则和专用承载对应关系的集合，在承载绑定后，即可保证符合某IP过滤准则的业务数据都会在由该IP过滤准则生成的TFT所绑定到的专用承载上进行转发，从而保证了流媒体的QoS。

优选地，MediaProxy根据Cache的地址信息与上述本地地址信息的对应关系通过上述专用承载在UE及Cache之间转发媒体流可以包括：Cache将发送给UE的媒体流数据包发送至MediaProxy；MediaProxy接收到该媒体流数据包后，根据上述对应关系将该媒体流数据包的源地址信息修改为Cache的地址信息对应的MediaProxy本地地址信息，由P-GW将该媒体流数据包通过上述专用承载发送至UE。

优选地，MediaProxy根据Cache的地址信息与上述本地地址信息的对应关系通过上述专用承载在UE及Cache之间转发媒体流还可以包括：UE获取上述本地地址信息；UE在向Cache的媒体面发送数据包时，将上述本地地址信息作为目标地址信息，由P-GW将该数据包通过上述专用承载发送至MediaProxy；MediaProxy收到该数据包后，根据上述对应关系将该数据包的目标地址信息由与Cache的地址信息对应的MediaProxy本地地址信息修改为Cache的地址信息，将该数据包发送至Cache。

由于MediaProxy为存储了UE所需资源的Cache再次分配了间接的表示Cache自身的地址信息的MediaProxy本地地址信息，因此，UE在向Cache的媒体面发送数据包时会直接以该Cache对应的MediaProxy本地地址信息作为目标地址信息，这时，要想UE发送的数据包最终发送到相应的Cache，MediaProxy就需要对UE发送的数据包的目标地址信息按照上述对应关系进行修改。而Cache向UE发送数据包时源地址填写的则是该Cache自身的地址信息，这时，要想Cache发送的数据包可以使用相应UE对应的专用承载，MediaProxy就需要对Cache发送的数据包的源地址信息按照上述对应关系进行修改，保证Cache发送的数据包符合相应的TFT。通过本优选实施例提供的方法，即可保证始终使用专用承载在Cache和UE之间进行数据转发，从而保证了流媒体的QoS，这时MediaProxy实际上是作为了Cache的媒体代理。

优选地，UE获取上述本地地址信息可以包括以下之一：UE接收MediaProxy返回的携带有上述本地地址信息的分配地址响应消息；Tracker接收MediaProxy返回的携带有上述本地地址信息的分配地址响应消息，再将上述本地地址信息转发给UE。

UE获取上述本地地址信息有多种实现方式，可以是UE自身向MediaProxy申请的，也可以是Tracker向MediaProxy申请再转发给UE的。

优选地，上述分配地址请求消息还可以携带有UE的地址信息；

在MediaProxy为Cache分配上述本地地址信息或MediaProxy将UE发送给Cache媒体面的数据包的目标地址信息由与Cache的地址信息对应的MediaProxy本地地址信息修改为Cache的地址信息之后还可以包括：MediaProxy为UE的地址信息分配相应的UE本地地址信息，其中，UE的地址信息与UE本地地址信息一一对应；

在MediaProxy将UE发送给Cache媒体面的数据包的目标地址信息由与Cache的地址信息对应的MediaProxy本地地址信息修改为Cache的地址信息之后还可以包括：MediaProxy根据UE的地址信息与UE本地地址信息的对应关系将UE发送给Cache媒体面的数据包的源地址信息由UE的地址信息修改为与之对应的UE本地地址信息；

在MediaProxy将Cache发送给UE的媒体流数据包的源地址信息修改为Cache的地址信息对应的MediaProxy本地地址信息之后还可以包括：MediaProxy根据UE的地址信息与UE本地地址信息的对应关系将Cache发送给UE的媒体流数据包的目标地址信息由与UE的地址信息对应的UE本地地址信息修改为UE的地址信息。

通过本优选实施例提供的方法，MediaProxy即可同时作为Cache和UE的媒体代理，在Cache和UE之间进行数据转发。

优选地，在MediaProxy为Cache分配上述本地地址信息之后还可以包括：当Cache的地址信息发生变更后，MediaProxy根据变更后的Cache的地址信息更新或新建Cache的地址信息与本地地址信息的对应关系。

为保证数据包的正确转发，上述对应关系应该时刻保持在最新的状态，因此，一旦Cache的地址信息发生了变更，MediaProxy就要对上述对应关系进行更新。

优选地，在MediaProxy根据变更后的Cache的地址信息更新或新建上述对应关系之前还可以包括以下之一：

MediaProxy通过DPI检测获取变更后的Cache的地址信息；

UE通过所Tracker通知MediaProxy变更后的Cache的地址信息。

本优选实施例给出了两种优选的获取变更后的Cache的地址信息的方式，在具体实施过程中，可用的方法包括但不限于上述两种。

下面结合实例对上述优选实施例进行详细说明。

本实例中采用地址映射表表示上述对应关系。

图5是根据本发明实例的流媒体QoS保障方法应用的***结构示意图，如图5所示，该***包括：

UE：发起业务请求并进行终端侧相应的业务处理功能。

MME：接入侧网元，主要负责移动性管理、承载管理等功能。

P-GW：接入侧网元，管理3GPP接入和non-3GPP接入间的移动，还负责策略执行、计费等功能。

PCSCF：IMS核心网网元，用于终端接入到IMS核心网。

SCSCF：IMS核心网网元，用于对用户的认证鉴权，会话控制和业务触发。

Tracker：内容跟踪服务器，存储资源索引信息，如某个特定的Cache中存储的资源信息。Tracker和MediaProxy之间增加接口，用于Tracker向MediaProxy发送Cache地址以及获取MediaProxy为Cache分配的本地地址。

Cache：内容缓存服务器，存储具体的资源，如影片内容分片等。

RCF：负责接收来自业务实体的业务QoS请求，结合运营商策略和用户签约等信息制定相应的资源控制策略，并下发给REF执行。此外，RCF还可以接收REF上报的事件，发送给相应的业务层功能实体。

REF：根据RCF下发的资源控制策略进行QoS策略实施和门控、事件上报等功能。REF是个逻辑功能，可以部署在多个网元中。在本架构中REF部署在P-GW网元中。

MediaProxy：建立UE和/或Cache的地址映射关系，并根据地址映射关系修改IP报文中的源和/或目的IP地址和/或端口信息并进行报文转发。

MediaProxy是新增的网元，MediaProxy和Tracker之间的接口以及MediaProxy和P-GW之间的接口是新增的接口。

REF部署在P-GW中，P-GW和RCF之间通过REF功能进行交互，为简便起见，下述流程图中没有示出REF功能。

本实例中采用的是Tracker做AF的情况，PCSCF做AF的情况也类似。

图6是根据本发明实施例一的流媒体QoS保障方法流程图，描述了MediaProxy仅做Cache媒体代理情况下的一种实现流程，如图6所示，包括以下步骤：

步骤S602：UE向PCSCF发送会话请求(INVITE)消息，该消息是为了向Tracker请求拥有目标资源的节点列表。消息中携带UE的终端能力信息(如UE的数据处理能力、屏幕分辨率等)、UE要请求的内容信息，如所需的资源ID及资源类型(如影片是否高清)、UE的(媒体面)IP地址和端口信息。

UE的IP地址和端口信息是指后续用于和Cache交互的地址和端口信息，可以预先默认配置，也可以临时分配，上述端口信息包含一个端口或端口列表或端口范围。

需要注意的是，UE的IP地址和端口信息在后续媒体流传输过程中可能只使用部分端口。UE的IP地址和端口信息在整个业务过程中不再更改。

步骤S604-步骤S606：PCSCF收到INVITE消息后，向SCSCF转发该消息。SCSCF将该消息发给Tracker。

步骤S608：Tracker收到SCSCF发送的INVITE消息后，根据INVITE中的资源ID和资源类型等信息获取并选择存储了该资源的Cache地址信息，Cache地址信息包括Tracker选择的所有Cache的媒体面IP地址和端口信息。

步骤S610：Tracker根据INVITE消息中携带的UE终端能力结合本地策略生成业务QoS需求。

步骤S608和步骤S610无严格的先后顺序关系。

步骤S612：Tracker向MediaProxy发送分配地址请求，该请求中携带步骤S608中Tracker选择的所有Cache的地址信息。该消息是请求MediaProxy为Cache在本地分配相应的地址信息并对两者进行关联。

步骤S614：MediaProxy收到分配地址请求后，根据请求消息中的Cache地址信息数在本地分配相应的地址信息(即IP地址和端口)，所分配的地址信息需和Cache地址信息一一对应，并在本地记录所分配的地址和Cache地址的对应关系，即地址映射表。

例如Tracker向MediaProxy发送的请求中携带了30个Cache的地址信息，那么MediaProxy也需要在本地分配30个地址(一个地址包含一个IP地址和一个对应的端口)，为了方便实现，可以采用分配同一IP地址和连续端口的方式，MediaProxy为Cache一一在本地分配地址后，在地址映射表中记录它们的对应关系，后续根据该地址映射表进行地址转换。

步骤S616：MediaProxy向Tracker返回分配地址响应消息，消息中携带本地分配的地址信息。后续Tracker将用MediaProxy的地址信息取代原先的Cache地址信息通知UE。

分配地址响应消息中携带的本地分配的地址信息要能体现和Cache地址信息的对应关系，例如MediaProxy在分配地址响应消息中将本地分配的地址信息按照分配地址请求消息中Cache的地址信息对应的顺序携带，或者MediaProxy在分配地址响应消息中除了携带本地分配的地址信息外还携带各MediaProxy地址对应的Cache地址信息。

步骤S618：Tracker向RCF发送资源预留请求，消息中携带业务QoS相关信息、UE标识和UE标识和IPFilterRule(IP过滤准则)等。IP过滤准则是Tracker根据UE的IP地址和端口信息及MediaProxy的IP地址和端口信息构建的。

步骤S620：RCF收到Tracker发送的资源预留请求后，获取其中的业务QoS相关信息，结合用户QoS签约和本地策略生成QoS决策，根据IP过滤准则信息生成TFT(流量模板，Traffic Flow Template)，之后向P-GW发送决策执行请求消息通知创建承载，消息中携带UE标识、QoS决策信息以及TFT等信息。

后续P-GW可根据TFT进行承载绑定。

由上述步骤可以看出，由于UE和MediaProxy的IP地址和端口信息在分配时均可以采用列表或者范围的形式进行分配，所以最终可以在无需对现有的IPFilterRule及TFT进行扩展的情况下实现IPFilterRule和TFT的构建。

步骤S622：P-GW收到RCF发送的决策执行请求后，根据消息中携带的QoS决策信息分配EPS(Evolved Packet System分组演进***)承载QoS，即承载层QoS参数。P-GW向MME发送创建承载请求消息，消息中携带UE标识、EPS承载QoS信息、TFT、EPS承载标识等。TFT用于IP流的承载绑定。

步骤S624：MME通知UE进行无线承载建立过程。MME在这个过程中将无线承载QoS信息和TFT等参数通知UE。UE根据QoS参数进行资源预留，根据TFT进行承载绑定。

步骤S626：完成承载建立相关过程后，MME向P-GW返回创建承载响应消息，带上EPS承载标识等信息。至此，具备QoS保障的专有承载建立完成。

步骤S628：P-GW收到MME返回的创建承载响应消息后，向RCF发送决策执行响应消息，通知RCF决策已经执行完成。

步骤S630：RCF收到决策执行响应消息后，向Tracker返回资源预留响应消息，通知Tracker资源已经预留完成。

步骤S632：Tracker收到RCF发送的资源预留响应消息后，向SCSCF发送应答(200OK)消息，消息中携带Tracker获取的Cache列表。Cache列表中携带的地址信息是原Cache地址信息对应的MediaProxy地址信息。

步骤S634-步骤S636：SCSCF收到应答消息后，通过PCSCF将该消息转发给UE。

步骤S638：UE收到应答消息后，从消息携带的Cache列表中选择一个或者多个Cache作为内容获取节点并获取地址信息。UE从中获取的地址是和Cache地址信息对应的MediaProxy地址信息。后续UE将MediaProxy地址信息认为是Cache的地址信息，并通过MediaProxy地址和其进行交互。

如果之前Tracker没有通过RCF去通知P-GW建立承载，那么在选择目标Cache之后，UE也可以主动发起承载修改流程请求P-GW根据目标Cache地址去建立承载。本实施例是Tracker已经通知了P-GW建立承载，因此UE无需再去请求P-GW新建承载。

本实施例以UE选取一个Cache为例，多个Cache的情况类似。为方便描述，将UE选择的Cache称为目标Cache。

步骤S640：UE向目标Cache发送内容请求消息，该消息的目标IP地址和端口地址填写与目标Cache地址信息对应的MediaProxy的IP地址和端口。后续网元根据MediaProxy的地址信息进行路由。该消息的源IP地址和端口地址填写UE的地址信息，该地址信息在步骤S602中UE的地址信息范围内。

P-GW收到IP包后，根据目的地址信息将其路由到MediaProxy。

步骤S642-步骤S644：MediaProxy从P-GW收到IP包后，根据本地存储的地址映射表修改报文中的目的地址信息，将IP包中的目的地址和端口修改成对应的Cache地址和端口，源地址不变，依然是UE的地址和端口。之后MediaProxy向Cache发送修改后的IP报文。

步骤S646：Cache收到内容请求消息后，向UE返回内容请求响应消息。该消息的IP包中目标地址信息填写从内容请求消息中获取到的UE地址和端口，源地址信息填写Cache相应的地址和端口。该消息首先被路由到MediaProxy。

步骤S648-步骤S650：MediaProxy从Cache收到IP包后，根据本地存储的地址映射表修改报文中的源地址信息，将IP报文中源地址信息由Cache地址和端口修改成对应的本地地址和端口，目标地址不变，依然是UE的地址和端口信息。之后MediaProxy将该IP包路由到P-GW。P-GW收到IP包后，根据目的地址信息将其转发至UE。

步骤S652：Cache向UE发送流媒体，流媒体IP包中的源地址和目的地址信息同步骤S6463。流媒体IP包首先被路由到MediaProxy。

步骤S654-步骤S656：MediaProxy对于收到的所有流媒体IP包，均根据本地存储的地址映射表修改报文中的源地址信息，将IP报文中源地址信息由Cache地址和端口修改成对应的本地地址和端口，目标地址不变，依然是UE的地址和端口信息。之后MediaProxy将流媒体IP包路由到P-GW。

P-GW收到流媒体IP包后，根据目的地址信息将其通过专有承载转发至UE。

在上述过程中，由于所有P-GW接收到的流媒体IP包中源地址信息都为MediaProxy的IP地址和端口，目的地址都为UE的地址和端口，因此根据之前生成的TFT规则，流媒体的IP流都被映射到专有承载上，从而保证了流媒体业务的QoS。

图7是根据本发明实施例二的流媒体QoS保障方法流程图，描述了MediaProxy同时做Cache和UE媒体代理情况下的一种实现流程，如图7所示，包含以下步骤：

步骤S702-步骤S710：同步骤S602-步骤S610。

步骤S712：Tracker向MediaProxy发送分配地址请求，该请求中携带步骤S708中Tracker选择的所有Cache的地址信息。该消息是请求MediaProxy为Cache在本地分配相应的地址信息并对两者进行关联。

此外，该请求中还携带UE的(媒体面)IP地址和端口信息。

步骤S714：MediaProxy收到分配地址请求后，根据请求消息中的Cache地址信息数在本地分配相应的地址信息(即IP地址和端口)，所分配的地址信息需和Cache地址信息一一对应，并在本地记录所分配的地址和Cache地址的对应关系，即地址映射表。

MediaProxy还需要根据请求消息中的UE地址信息数在本地分配相应的地址，所分配的地址信息需和UE地址信息一一对应，并在本地记录所分配的地址和UE地址的对应关系，即UE地址映射表。

步骤S716：MediaProxy向Tracker返回分配地址响应消息，消息中携带本地分配的地址信息。后续Tracker将用MediaProxy的地址信息取代原先的Cache地址信息通知UE。

分配地址响应消息中携带的本地分配的地址信息要能体现和Cache地址信息的对应关系，例如MediaProxy在分配地址响应消息中将本地分配的地址信息按照分配地址请求消息中Cache的地址信息对应的顺序携带，或者MediaProxy在分配地址响应消息中除了携带本地分配的地址信息外还携带各MediaProxy地址对应的Cache地址信息。

消息中无需携带MediaProxy为UE分配的地址信息。

步骤S718-步骤S740：同步骤S618-步骤S640。

步骤S742-步骤S744：MediaProxy从P-GW收到IP包后，根据本地存储的地址映射表修改报文中的地址信息，将IP包中的目的地址和端口修改成对应的Cache地址和端口，源地址由UE的IP地址和端口修改成本地与其对应的IP地址端口。之后MediaProxy向Cache发送修改后的IP报文。

如果此前没有建立过UE地址映射表，那么MediaProxy也可以在此时在本地为UE分配相应的地址，所分配的地址信息需和该IP包中UE的地址信息对应，并在本地记录所分配的地址和UE地址的对应关系，即建立UE地址映射表。

步骤S746：Cache收到内容请求消息后，向UE返回内容请求响应消息。该消息的IP包中目标地址信息填写从内容请求消息中获取到的源地址，即MediaProxy为UE地址分配的对应的地址和端口，源地址信息填写Cache相应的地址和端口。该消息首先被路由到MediaProxy。

步骤S748-步骤S750：MediaProxy从Cache收到IP包后，根据本地存储的地址映射表修改报文中的地址信息。MediaProxy根据Cache地址映射表将IP报文中源地址信息由Cache地址和端口修改成对应的本地地址和端口，根据UE地址映射表将目标地址由本地的IP地址和端口修改成和该地址对应的UE的IP地址和端口。之后MediaProxy将该IP包路由到P-GW。

P-GW收到IP包后，根据目的地址信息将其转发至UE。

步骤S752：Cache向UE发送流媒体，流媒体IP包中的源地址和目的地址信息同步骤S746。流媒体IP包首先被路由到MediaProxy。

步骤S754-步骤S756：MediaProxy对于收到的所有流媒体IP包，均根据本地存储的地址映射表修改报文中的地址信息。修改方法同步骤S748。之后MediaProxy将流媒体IP包路由到P-GW。

P-GW收到流媒体IP包后，根据目的地址信息将其通过专有承载转发至UE。

在上述过程中，由于所有P-GW接收到的流媒体IP包中源地址信息都为MediaProxy的IP地址和端口，目的地址为都UE的地址和端口，因此根据之前生成的TFT规则，流媒体的IP流都被映射到专有承载上，从而保证了流媒体业务的QoS。

图8是根据本发明实施例三的流媒体QoS保障方法流程图，描述了在MediaProxy已经建立了地址映射表的前提下(参见步骤S602-步骤S616或步骤S702-步骤S716)，Cache(媒体面)地址信息更新后，MediaProxy采用DPI方式获取更新后的Cache地址信息，并进行地址映射表更新的一种实现流程，如图8所示，包含以下步骤：

步骤S802：UE和Cache通过PPSP消息协商进行Cache地址信息修改。MediaProxy通过DPI检测对PPSP消息进行检测并获取修改后的Cache地址信息。

步骤S804：MediaProxy根据新的Cache地址信息对地址映射表进行更新。

步骤S806-步骤S822：后续MediaProxy根据更新后的地址映射表修改IP报文中的地址和端口信息并进行转发。具体过程同步骤S640-步骤S656或步骤S740-步骤S756。

图9是根据本发明实施例四的流媒体QoS保障方法流程图，描述了在MediaProxy已经建立了地址映射表的前提下(参见步骤S602-步骤S616或步骤S702-步骤S716)，Cache(媒体面)地址信息更新后，通过Tracker通知MediaProxy进行地址映射表更新的一种实现流程，如图9所示，包含以下步骤：

步骤S902：UE和Cache通过协商进行地址信息修改。

步骤S904：地址协商修改完成后，UE向Tracker发送消息通知新的地址信息。消息中携带Cache更新后的地址信息。通知消息经过PCSCF和SCSCF等网元发送至Tracker。

步骤S906：Tracker收到通知消息后，向MediaProxy发送消息通知其更新或新建地址映射信息。消息中携带Cache更新后的地址信息。消息中可以携带Cache更新前的地址信息，MediaProxy由此可以判断需要对哪条纪录进行更新或新建。

步骤S908：MediaProxy根据Cache新的地址信息对地址映射表进行更新或新建。

步骤S910：MediaProxy完成地址映射表更新后，通知Tracker更新完成。

步骤S912：Tracker收到MediaProxy的通知消息后，向UE返回通知消息。

步骤S914-步骤S930：同步骤S806-步骤S822。

图10是根据本发明实施例五的流媒体QoS保障方法流程图，描述了UE选择了内容传输节点之后再通知MediaProxy建立地址映射表的过程，如图10所示，包括以下步骤：

步骤S1002-步骤S1010：同步骤S602-步骤S610。

步骤S1012：Tracker向MediaProxy发送分配地址请求。可选地，该请求消息中可以携带UE的最大连接数，后续MediaProxy可以参考UE的最大连接数进行地址和/端口分配。

步骤S1014：MediaProxy收到请求后，向Tracker返回响应消息，其中携带MediaProxy为本次业务分配的地址及端口信息。此地址可以是MediaProxy默认配置的地址和端口，也可以是MediaProxy临时分配的地址和端口。MediaProxy分配地址和/或端口的具体方法可以由策略决定，例如可以根据UE的最大连接数判断需要分配多少个地址和/或端口。

步骤S1016-步骤S1036：同步骤S618-步骤S638。

步骤S1038：UE通知MediaProxy建立地址映射表，消息中携带UE选择的目标Cache的地址和端口信息。

步骤S1040：MediaProxy在目标Cache地址和端口和之前分配的本地地址和端口之间建立地址映射关系。

步骤S1042：UE向目标Cache请求内容。

步骤S 1044：Cache向MediaProxy发送流媒体包。

步骤S1046：MediaProxy根据地址映射表将IP报文中源地址信息修改成地址映射表中本端的地址和端口。

步骤S1048：之后MediaProxy将流媒体IP包路由到P-GW，P-GW收到流媒体IP包后，根据目的地址信息将其通过专有承载转发至UE。

在上述过程中，由于所有P-GW接收到的流媒体IP包中源地址信息为MediaProxy的IP地址和端口，目的地址为UE的地址和端口，因此根据之前生成的TFT规则，流媒体的IP流都被映射到专有承载上，从而保证了流媒体业务的QoS。

需要说明的是，以上实施例中，内容请求和内容请求响应消息也是发往UE和Cache的媒体面地址，如果这两个消息是发向UE和Cache的信令面地址，那么这两条消息可以经过MediaProxy转发，也可以不经过MediaProxy而直接发往对端。

图11是根据本发明实施例六的流媒体QoS保障方法流程图，描述了UE选择了内容传输节点(Cache)之后请求MediaProxy为所选择的目标Cache分配地址并建立地址映射表的过程，如图11所示，包括以下步骤：

步骤S1102：UE发起业务请求并请求peerlist。

步骤S1104：Tracker返回peerlist。

步骤S1106：UE选择内容缓存服务器。

步骤S1108：UE通知Mediaproxy目标Cache地址，请求Mediaproxy为目标Cache分配本地地址。

步骤S1110：Mediaproxy为目标Cache分配本地的地址信息建立地址映射表。

步骤S1112：Mediaproxy向UE返回目标Cache对应的本地地址信息。

步骤S1114：UE使用本地地址信息通知P-GW建立承载。

步骤S1116-1122：同步骤S1042-步骤S1048。

图12是根据本发明实施例的流媒体QoS保障***的结构框图。如图12所示，根据本发明实施例的流媒体QoS保障***包括(现有***中其他实体未示出)：

MediaProxy 122，用于为存储了UE所需资源的内Cache分配本地地址信息，并告知P-GW上述本地地址信息，以及根据Cache的地址信息与上述本地地址信息的对应关系通过UE对应的专用承载在UE及Cache之间转发媒体流；

P-GW 124，与MediaProxy 122相连，用于使用上述本地地址信息建立上述专用承载并进行承载绑定。

在本实施例提供的***中，MediaProxy 122利用了IP过滤准则的生成方式中，端口或者IP地址(即地址信息)连续时，可以采用范围或掩码的方式来描述，使得具备连续端口或IP地址的多条地址信息生成一条IP过滤准则的特点，为存储了UE所需资源的Cache再次分配了MediaProxy本地地址信息，使用该MediaProxy本地地址信息间接的表示Cache自身的地址信息，后续MediaProxy 122会根据上述对应关系在UE及Cache之间转发流媒体的业务数据，这样，即使Cache自身的地址信息十分分散，通过控制MediaProxy本地地址信息连续的程度页可以保证最终生成的IP过滤准则不会超于目前标准规定的15个，从而保证了UE及Cache之间的业务数据始终在UE对应的专用承载上转发，确保了流媒体的QoS。

从以上的描述中，可以看出，本发明提供的技术方案可以减少TFT中的IP过滤准则数目，从而解决现有技术中存在的为P2P流媒体业务生成的TFT中的IP过滤准则数目超过协议规定的数目限制的问题，使得P2P流媒体业务可以在遵循现有协议规定的前提下提供QoS机制。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种流媒体服务质量QoS保障方法，其特征在于，包括：

预置的媒体代理网关功能MediaProxy为存储了用户设备UE所需资源的内容缓存服务器Cache分配本地地址信息，并告知分组数据网络网关P-GW所述本地地址信息；

所述P-GW使用所述本地地址信息建立专用承载并进行承载绑定；

所述MediaProxy根据所述Cache的地址信息与所述本地地址信息的对应关系通过所述专用承载在所述UE及所述Cache之间转发媒体流。

2.根据权利要求1所述的方法，其特征在于，

所述本地地址信息是连续或部分连续的；和/或

所述本地地址信息与所述Cache的地址信息一一对应。

3.根据权利要求1所述的方法，其特征在于，在所述MediaProxy为所述Cache分配所述本地地址信息之前还包括：

内容跟踪服务器Tracker或所述UE向所述MediaProxy发送携带有所述Cache的地址信息和/或所述UE的最大连接数的分配地址请求消息。

4.根据权利要求3所述的方法，其特征在于，所述P-GW使用所述本地地址信息建立专用承载并进行承载绑定包括：

所述MediaProxy向所述Tracker或所述UE返回携带有所述本地地址信息的分配地址响应消息；

所述Tracker或所述UE根据所述本地地址信息生成IP过滤准则并发送给所述P-GW；

所述P-GW根据所述IP过滤准则建立所述专用承载，并对所述专用承载进行绑定。

5.根据权利要求4所述的方法，其特征在于，所述MediaProxy根据所述Cache的地址信息与所述本地地址信息的对应关系通过所述专用承载在所述UE及所述Cache之间转发媒体流包括：

所述Cache将发送给所述UE的媒体流数据包发送至所述MediaProxy；

所述MediaProxy接收到该媒体流数据包后，根据所述对应关系将该媒体流数据包的源地址信息修改为所述Cache的地址信息对应的所述本地地址信息，由所述P-GW将该媒体流数据包通过所述专用承载发送至所述UE。

6.根据权利要求5所述的方法，其特征在于，所述MediaProxy根据所述Cache的地址信息与所述本地地址信息的对应关系通过所述专用承载在所述UE及所述Cache之间转发媒体流还包括：

所述UE获取所述本地地址信息；

所述UE在向所述Cache的媒体面发送数据包时，将所述本地地址信息作为目标地址信息，由所述P-GW将该数据包通过所述专用承载发送至所述MediaProxy；

所述MediaProxy收到该数据包后，根据所述对应关系将该数据包的目标地址信息由与所述Cache的地址信息对应的所述本地地址信息修改为所述Cache的地址信息，将该数据包发送至所述Cache。

7.根据权利要求6所述的方法，其特征在于，所述UE获取所述本地地址信息包括以下之一：

所述UE接收所述MediaProxy返回的携带有所述本地地址信息的分配地址响应消息；

所述Tracker接收所述MediaProxy返回的携带有所述本地地址信息的分配地址响应消息，再将所述本地地址信息转发给所述UE。

8.根据权利要求6所述的方法，其特征在于，

所述分配地址请求消息还携带有所述UE的地址信息；

在所述MediaProxy为所述Cache分配所述本地地址信息或所述MediaProxy将所述UE发送给所述Cache媒体面的数据包的目标地址信息由与所述Cache的地址信息对应的所述本地地址信息修改为所述Cache的地址信息之后还包括：所述MediaProxy为所述UE的地址信息分配相应的UE本地地址信息，其中，所述UE的地址信息与所述UE本地地址信息一一对应；

在所述MediaProxy将所述UE发送给所述Cache媒体面的数据包的目标地址信息由与所述Cache的地址信息对应的所述本地地址信息修改为所述Cache的地址信息之后还包括：所述MediaProxy根据所述UE的地址信息与所述UE本地地址信息的对应关系将所述UE发送给所述Cache媒体面的数据包的源地址信息由所述UE的地址信息修改为与之对应的所述UE本地地址信息；

在所述MediaProxy将所述Cache发送给所述UE的媒体流数据包的源地址信息修改为所述Cache的地址信息对应的所述本地地址信息之后还包括：所述MediaProxy根据所述UE的地址信息与所述UE本地地址信息的对应关系将所述Cache发送给所述UE的媒体流数据包的目标地址信息由与所述UE的地址信息对应的所述UE本地地址信息修改为所述UE的地址信息。

9.根据权利要求1-8任一项所述的方法，其特征在于，在所述MediaProxy为所述Cache分配所述本地地址信息之后还包括：

当所述Cache的地址信息发生变更后，所述MediaProxy根据变更后的Cache的地址信息更新或新建所述对应关系。

10.根据权利要求9所述的方法，其特征在于，在所述MediaProxy根据变更后的Cache的地址信息更新所述对应关系之前还包括以下之一：

所述MediaProxy通过深度包检测DPI获取变更后的Cache的地址信息；

所述UE通过所述Tracker通知所述MediaProxy变更后的Cache的地址信息。

11.一种流媒体服务质量QoS保障***，其特征在于，包括：

媒体代理网关功能实体MediaProxy，用于为存储了用户设备UE所需资源的内容缓存服务器Cache分配本地地址信息，并告知分组数据网络网关P-GW所述本地地址信息，以及根据所述Cache的地址信息与所述本地地址信息的对应关系通过所述UE对应的专用承载在所述UE及所述Cache之间转发媒体流；

所述P-GW，用于使用所述本地地址信息建立所述专用承载并进行承载绑定。

Images