CN103096179A - 一种保障流媒体业务质量的方法和*** - Google Patents
一种保障流媒体业务质量的方法和*** Download PDFInfo
- Publication number
- CN103096179A CN103096179A CN2011103423305A CN201110342330A CN103096179A CN 103096179 A CN103096179 A CN 103096179A CN 2011103423305 A CN2011103423305 A CN 2011103423305A CN 201110342330 A CN201110342330 A CN 201110342330A CN 103096179 A CN103096179 A CN 103096179A
- Authority
- CN
- China
- Prior art keywords
- streaming media
- dedicated bearer
- media service
- address
- tft
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种保障流媒体业务质量的方法和***，方法包括：分组数据网络网关(P-GW)为流媒体业务建立专用承载；所述P-GW通过所述专用承载发送流媒体业务的下行媒体流数据，通过默认承载接收流媒体业务的上行媒体流及信令数据；用户设备(UE)通过所述专用承载接收流媒体业务的下行媒体流数据，通过默认承载发送流媒体业务的上行媒体流及信令数据。通过本发明，实现了基于IMS based CDS(基于IMS的内容传输业务)架构下更为灵活和精细化的流媒体QoS策略控制，更为有效地利用专用承载资源。
Description
技术领域
本发明涉及网络通信技术领域，尤其涉及一种保障流媒体业务质量的方法和***。
背景技术
P2P(Peer-to-Peer)常称为对等互联或者点对点技术。相对于传统的C/S(Client/Server，客户端/服务器)模式而言，P2P网络中的不同Peer(对等)节点之间无需经过中继设备直接交换数据或服务，每个节点的地位都是对等的。如图1所示，在P2P网络中，每个节点既可以从其他节点得到服务，也可以向其他节点提供服务。由于P2P技术能够极大缓解传统C/S架构中服务器端的压力过大、单一失效点等问题，又能充分利用终端的丰富资源，所以P2P技术在文件共享、流媒体、语音通信及在线游戏支撑平台等方面已经获得广泛应用。
P2P流媒体业务主要是采用P2P技术进行流媒体传输。目前IETF(TheInternet Engineering Task Force，互联网工程任务组)也在制定相关规范和协议，其中最为普遍接受和广泛研究的是PPSP(P2P Streaming Protocol，P2P流媒体协议)。如图2所示，是PPSP协议的架构，主要包含以下实体：
Tracker，负责存储内容分片的索引；
Peer，P2P网络中的对等节点，负责存储内容分片；Peer可以是用户终端，也可以是运营商部署的专门的内容存储服务器。
PPSP协议由Tracker协议和Peer协议组成，Peer通过Tracker协议向Tracker注册自己存储的内容分片，或通过Tracker协议向Tracker查询获取存储目标资源的Peer节点。Peer和Peer之间通过Peer协议互通，获取所需的内容分片。
在PPSP架构下，一个典型的流媒体业务流程如图3所示，主要包括以下步骤：
步骤301，UE(User Equipment，用户设备)向Tracker发送资源请求，请求获取拥有所需内容分片的Peer节点列表。
步骤302，Tracker将拥有UE所需内容分片的Peer节点列表返回给UE。
步骤303，UE从所述Peer节点列表中选择一个或多个目标Peer节点，向所选的目标Peer节点请求内容。
步骤304-305，目标Peer节点接收内容请求后，返回内容请求响应给UE，并将UE所需内容返回给目标Peer节点。
当流媒体业务在电信网络中实现时，一种较好的实现方式是在IMS(IPMultimedia Subsystem，IP多媒体子***)网络基础之上构建PPSP网络，即IMSbased CDS(IMS based Content Delivery Service，基于IMS的内容传输业务)，该网络是一种内容分发网络。其主要原理是将Tracker作为AS(ApplicationServer，应用服务器)接入到IMS网络，UE通过IMS网络进行注册和计费，UE和Tracker之间的PPSP Tracker协议需要承载在SIP(Session InitiationProtocol，会话初始协议)中，并且UE和Tracker之间的消息交互都需要经过IMS核心网，UE和Peer之间的交互则不需要经过IMS核心网而直接通过PPSPPeer协议进行交互。在这种架构下，既能充分利用现有的IMS网络来实现对流媒体业务的控制，又能够在媒体面传输时充分利用P2P技术的优势。
在电信网络中，为了保证业务质量，运营商需要对网络进行QoS(Quality ofService，服务质量)策略控制。目前现有技术中流媒体业务QoS控制的实现方式是流媒体业务相关的上行数据(如UE发送的信令和UE上传的文件)和下行数据(如UE接收的信令和UE下载的内容)都走专用承载。由于用户的专用承载资源是有限且宝贵的，所以这种方式存在的问题是对于一些不需要进行带宽保证的数据(例如UE上传的内容数据)也占用了专用承载带宽，容易造成专用承载带宽浪费，影响那些必须要用专用承载下载的内容的传输效果。
发明内容
有鉴于此，本发明的主要目的在于提供一种保障流媒体业务质量的方法和***，以实现基于IMS based CDS架构下更为灵活和精细化的流媒体QoS策略控制，更为有效地利用专用承载资源。
为达到上述目的，本发明的技术方案是这样实现的：
本发明提供了一种保障流媒体业务质量的方法，该方法包括：
分组数据网络网关P-GW为流媒体业务建立专用承载；
所述P-GW通过所述专用承载发送流媒体业务的下行媒体流数据，通过默认承载接收流媒体业务的上行媒体流及信令数据；用户设备UE通过所述专用承载接收流媒体业务的下行媒体流数据，通过默认承载发送流媒体业务的上行媒体流及信令数据。
所述专用承载为单向下行承载。
所述P-GW根据服务质量QoS策略信息和流量模板TFT建立专用承载；
所述TFT中携带方向指示表示所述TFT所匹配的是单向下行承载。
所述方向指示由RCF从应用功能实体AF获取后通知所述P-GW，或者由所述RCF根据本地策略生成后通知所述P-GW，或者由所述UE生成后通知所述P-GW。
所述TFT中携带所述UE的IP地址和端口信息、以及存储了所述UE请求资源的内容缓存服务器Cache的IP地址和端口信息；所述UE的IP地址和端口信息、以及所述Cache的IP地址和端口信息由内容跟踪服务器Tracker通过RCF通知给所述P-GW。
所述P-GW将所述UE向目标Cache请求的下行媒体流数据通过所述TFT绑定到所述专用承载发送给所述UE，所述UE通过所述专用承载接收所述下行媒体流数据。
本发明还提供了一种保障流媒体业务质量的***，该***包括：用户设备UE、分组数据网络网关P-GW，其中，
所述P-GW，用于为流媒体业务建立专用承载；所述P-GW通过所述专用承载发送流媒体业务的下行媒体流数据，通过默认承载接收流媒体业务的上行媒体流及信令数据；
所述UE，用于通过所述专用承载接收流媒体业务的下行媒体流数据，通过默认承载发送流媒体业务的上行媒体流及信令数据。
所述专用承载为单向下行承载。
所述P-GW进一步用于，根据服务质量QoS策略信息和流量模板TFT建立专用承载；
所述TFT中携带方向指示表示所述TFT所匹配的是单向下行承载。
所述方向指示由RCF从应用功能实体AF获取后通知所述P-GW，或者由所述RCF根据本地策略生成后通知所述P-GW，或者由所述UE生成后通知所述P-GW。
所述TFT中携带所述UE的IP地址和端口信息、以及存储了所述UE请求资源的内容缓存服务器Cache的IP地址和端口信息；所述UE的IP地址和端口信息、以及所述Cache的IP地址和端口信息由Tracker通过RCF通知给所述P-GW。
所述P-GW进一步用于，将所述UE向目标Cache请求的下行媒体流数据通过所述TFT绑定到所述专用承载发送给所述UE，
所述UE通过所述专用承载接收所述下行媒体流数据。
本发明所提供的一种保障流媒体业务质量的方法和***，由P-GW为流媒体业务建立专用承载；所述P-GW通过所述专用承载发送流媒体业务的下行媒体流数据，通过默认承载接收流媒体业务的上行媒体流及信令数据；UE通过所述专用承载接收流媒体业务的下行媒体流数据，通过默认承载发送流媒体业务的上行媒体流及信令数据。
通过本发明，能够实现基于IMS based CDS架构的内容分发网络中更为灵活和精细化的流媒体QoS策略控制，同时能针对流媒体业务特征对上下行流媒体不同的传输需求分配不同的承载，实现对带宽更为有效的利用，且更为有效地利用专用承载资源。
附图说明
图1为现有技术中P2P网络的架构示意图；
图2为现有技术中PPSP协议的基本架构示意图；
图3为现有技术中使用PPSP协议进行流媒体业务的流程图；
图4为本发明实施例的一种QoS策略控制***的架构图；
图5为本发明实施例一的流媒体业务的流程图；
图6为本发明实施例二的流媒体业务的流程图。
具体实施方式
下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。
图4是本发明的实现QoS策略控制的***架构图，该***包括：
UE 401：发起业务请求并进行终端侧相应的业务处理功能。
MME(Mobility Management Entity，移动管理实体)402：接入侧网元，主要负责移动性管理、承载管理等功能。
P-GW(Packet Data Network Gateway，分组数据网络网关)403：接入侧网元，管理3GPP接入和non-3GPP接入间的移动，还负责策略执行、计费等功能。
P-CSCF(Proxy-Call Session Control Function，代理呼叫控制功能实体)404：IMS核心网网元，用于终端接入到IMS核心网。
S-CSCF(Session-Call Session Control Function，会话呼叫控制功能实体)405：IMS核心网网元，用于对用户的认证鉴权，会话控制和业务触发。
Tracker 406：内容跟踪服务器，存储资源索引信息，如某个特定的Cache中存储的资源信息。
Cache 407：内容缓存服务器，存储具体的资源，如影片内容分片等。
RCF(Resource Control Function，资源控制功能实体)408：负责接收来自业务实体的业务QoS请求，结合运营商策略和用户签约等信息制定相应的资源控制策略，并下发给REF执行。此外，RCF还可以接收REF上报的事件，发送给相应的业务层功能实体。
REF(Resource Enforcement Function，策略执行功能实体)409：根据RCF下发的资源控制策略进行QoS策略实施和门控、事件上报等功能。REF是个逻辑功能，可以部署在多个网元中。在本架构中REF部署在P-GW网元中。
和RCF对接的网元可以是P-CSCF或者Tracker，在实际部署时二选一即可。为方便描述，将P-CSCF和RCF对接的架构称为P-CSCF作AF(ApplicationFunction，应用功能实体)，将Tracker和RCF对接的架构称为Tracker作AF。
P-CSCF和RCF之间的接口和协议为现有技术，P-CSCF将业务层的QoS需求承载在Diameter消息中下发给RCF，RCF向其返回执行结果。
Tracker和RCF之间存在接口时，Tracker网元还具备如下功能：
(1)根据UE能力等信息决策出业务QoS需求；
(2)和RCF交互，将业务层的QoS需求承载在Diameter消息中下发给RCF，RCF向其返回执行结果。
参照上述***，本发明实施例所提供的一种保障流媒体业务质量的方法，主要包括：P-GW为流媒体业务建立专用承载；所述P-GW通过所述专用承载发送流媒体业务的下行媒体流数据，通过默认承载接收流媒体业务的上行媒体流及信令数据；所述UE通过所述专用承载接收流媒体业务的下行媒体流数据，通过默认承载发送流媒体业务的上行媒体流及信令数据。
其中，所述专用承载为单向下行承载。
所述单向下行承载的建立过程为：所述P-GW收到专用承载建立请求后，所述P-GW通知所述UE建立无线侧承载。
所述P-GW根据QoS策略信息和TFT(Traffic Flow Template，流量模板)建立专用承载；所述TFT由所述P-GW生成，或者由RCF生成后通知所述P-GW；所述QoS策略信息由所述RCF生成后通知所述P-GW。
所述TFT中携带方向指示表示所述TFT所匹配的是单向下行承载。
所述方向指示由所述RCF从所述AF获取后通知所述P-GW，或者由所述RCF根据本地策略生成后通知P-GW，或者由UE生成后通知P-GW。所述AF可以由Tracker或PCSCF(代理CSCF)充当。
所述TFT中携带所述UE的IP地址和端口信息、以及存储了所述UE请求资源的内容缓存服务器Cache的IP地址和端口信息；所述UE的IP地址和端口信息、以及所述Cache的IP地址和端口信息由内容跟踪服务器Tracker通过RCF通知给所述P-GW。
所述P-GW将所述UE向目标Cache请求的下行媒体流数据通过所述TFT绑定到所述专用承载发送给所述UE，所述UE通过所述专用承载接收所述下行媒体流数据。
对应的，本发明实施例还提供了一种保障流媒体业务质量的***，主要包括：UE和P-GW，其中，P-GW用于为流媒体业务建立专用承载；P-GW通过所述专用承载发送流媒体业务的下行媒体流数据，通过默认承载接收流媒体业务的上行媒体流及信令数据；UE，用于通过所述专用承载接收流媒体业务的下行媒体流数据，通过默认承载发送流媒体业务的上行媒体流及信令数据。
所述专用承载为单向下行承载。
该***进一步包括：RCF和AF，所述RCF收到AF的资源预留请求消息后，通知所述P-GW建立专用承载，所述P-GW通知所述UE建立无线侧承载。
P-GW进一步用于，根据QoS策略信息和TFT建立专用承载；所述TFT由所述P-GW生成，或者由所述RCF或所述UE生成后通知所述P-GW；所述QoS策略信息由所述RCF生成后通知所述P-GW。
该***进一步包括Tracker，
所述UE的IP地址和端口信息、以及所述Cache的IP地址和端口信息由Tracker通过所述RCF通知给所述P-GW。
所述P-GW进一步用于，将所述UE向所述目标Cache请求的下行媒体流数据通过所述TFT绑定到所述专用承载发送给所述UE，所述UE通过所述专用承载接收所述下行媒体流数据。
下面结合附图和实施例对本发明作进一步详细说明。在下述实施例中仅描述了Tracker作AF的情况，P-CSCF做AF的情况也类似，在此不再赘述。REF部署在P-GW中，P-GW和RCF之间通过REF功能进行交互。
本发明的实施例一如图5所示，描述了如何通过建立默认承载和专用承载使得上行IP数据包走默认承载、下行媒体流IP数据包走专用承载的过程，主要包括：
步骤501，UE1发送PDN(Public Data Network，公用数据网络)连接请求消息给MME，其中携带PDN类型、协议配置选项等信息。
步骤502，MME收到PDN连接请求消息后，分配承载ID(标识)，选择P-GW并向其发送创建会话请求消息，消息中携带P-GW地址、签约的APN-AMBR(Access Point Name-Aggregate Maximum Bit Rate，接入点聚合的最大比特速率)、APN(Access Point Name，接入点)、APN限制、默认EPS(EvolvedPacket System，演进分组***)承载的QoS参数、PDN地址等参数。
步骤503，P-GW收到创建会话请求消息后，向MME返回创建会话响应消息，消息中携带PDN地址、EPS承载QoS等参数。在此过程中，P-GW根据策略可能需要和PCRF(Policy and Charging Rules Function，策略和计费规则功能实体)交互，对收到的QoS相关参数进行修改。
步骤504，MME通过eNodeB(基站)通知UE1进行无线承载建立过程。MME发送的消息中携带给UE分配的PDN地址以及承载建立所需的QoS参数等。
步骤505，UE1完成无线承载建立过程后，向MME发送承载连接完成消息。
至此默认承载建立完毕。从而，后续UE1作为内容提供节点上传或向其他终端发送的流媒体内容以及信令面的消息可以直接走默认承载而无需建立新的专用承载，这样可以使得所述UE在无需预留带宽的情况下为其他的终端提供力所能及的服务，使得所述UE的带宽利用更为合理。
需要说明的是，上述建立默认承载的过程还可以通过其它方式实现，例如通过终端附着的过程建立。
步骤506，UE1向P-CSCF发送会话请求(INVITE)消息，该消息是为了向Tracker请求拥有目标资源的节点列表。消息中携带UE1的终端能力信息(如UE1的数据处理能力、屏幕分辨率等)、UE1的媒体面IP地址和端口信息，此外该INVITE消息中还包括UE1要请求的内容信息，如所需的资源ID及资源类型(如影片是否高清)等。
所述UE1的媒体面端口信息可以是为该业务临时分配的，也可以是预先默认设置的；可以是一个端口，也可以是端口列表或者范围。
步骤507-508，P-CSCF收到INVITE消息后，向S-CSCF转发该消息；S-CSCF将该消息发给Tracker。
步骤509，Tracker收到INVITE消息后，根据INVITE消息中的资源ID和资源类型等信息获取存储了该资源的Cache的地址列表，所述Cache的地址列表中包含Cache的媒体面IP地址和端口信息。
步骤510，Tracker根据INVITE消息中携带的UE1的终端能力结合本地策略生成业务QoS需求。
上述步骤509和510无严格的先后顺序关系。
步骤511，Tracker在生成业务QoS需求后，向RCF发送资源预留请求消息，消息中携带业务QoS相关信息、UE1的标识、所述UE1的媒体面IP地址和端口信息、所述Cache的媒体面IP地址和端口信息等。如果所述UE1的端口是专门为该业务分配的，那么所述Cache的媒体面IP地址可以填通配符，端口不填，端口不填时表示通配。而不论UE端口是临时分配的，还是默认设置的，都可以将Cache对应的地址和端口参数填写步骤509中Tracker获取到的所有cache的媒体面IP地址和端口信息。
此外，所述资源预留请求消息中还可以携带下行IP流指示，所述下行IP流指示表示该IP流只是一个单向的下行IP流。
步骤512，RCF收到Tracker发送的资源预留请求消息后，根据业务QoS相关信息结合用户QoS签约和运营商策略生成QoS策略，根据所述UE1的IP地址和端口信息、所述Cache的IP地址和端口信息和下行IP流指示信息生成TFT(Traffic Flow Template，流量模板)，所述TFT中IP流方向设为仅下行方向。因此，所述TFT对应的承载为一单向的下行承载。
之后，RCF向P-GW发送策略执行请求消息，消息中携带UE1的标识、QoS策略、TFT信息等。后续P-GW可根据所述TFT进行承载绑定。
此外，所述RCF也可以不生成TFT，所述RCF将UE1的IP地址和端口信息、所述Cache的IP地址和端口信息和下行IP流指示信息发送给P-GW，由所述P-GW根据上述信息生成TFT。
所述下行IP流指示信息可以由所述Tracker发送，也可以由RCF根据本地策略产生。
步骤513，P-GW收到RCF发送的策略执行请求消息后，根据消息中携带的QoS策略分配EPS承载QoS，所述EPS承载QoS是指承载层QoS参数，包括QCI(QoS Class Identifier，QoS类别标识)、ARP(Allocation and RetentionPriority，分配和保留优先级)、GBR(Guaranteed Bit Rate，保证比特率)和MBR(最大比特率，Maximum Bit Rate)。P-GW向MME发送创建承载请求消息，消息中携带UE1的标识、EPS承载QoS信息、TFT、EPS承载标识等。所述TFT用于IP流的承载绑定。
步骤514，MME通知UE1进行无线承载建立过程。MME在这个过程中将EPS承载QoS信息和TFT等参数通知UE。UE根据QoS参数进行资源预留。
步骤515，完成承载建立相关过程后，MME向P-GW返回创建承载响应消息，带上EPS承载标识等信息。至此，具备QoS保障的专有承载建立完成。
步骤516，P-GW收到MME返回的创建承载响应消息后，向RCF发送策略执行响应消息，通知RCF策略已经执行完成。
步骤517，RCF收到策略执行响应消息后，向Tracker返回资源预留响应消息，通知Tracker资源已经预留完成。
步骤518-520，Tracker收到RCF发送的资源预留响应消息后，通过S-CSCF和P-CSCF向UE发送应答(200OK)消息，消息中携带所述UE所请求的Cache列表。
步骤521，UE1获取到Cache列表后从中选择一个或者多个Cache作为内容获取节点，下称目标Cache，并获取所述目标Cache的媒体面IP地址和端口信息。
步骤522，UE1向所选择的Cache发送内容请求，由于专用承载是下行承载，该消息对应的IP数据包无法匹配上专用承载，将会被自动匹配到默认承载，因此该消息将通过默认承载发送。
本实施例中以UE和一个Cache之间协商为例，多个Cache的情况类似。
步骤523，所述Cache向UE1返回内容请求响应消息。
步骤524，所述Cache向UE1传送所述UE1请求的流媒体。由于所述流媒体IP包中使用的UE的地址和端口信息是步骤506中UE1的媒体面地址和端口，所述流媒体IP包中使用的Cache的地址和端口信息是步骤509中的Cache的媒体面地址和端口，因此该IP流将被TFT匹配到专有承载，即实现下行媒体流通过专有承载发送，从而保障下行流媒体的QoS。
下述步骤525-528描述了UE1作为内容传输节点，终端UE2向其请求流媒体，UE1向UE2发送流媒体的过程。该过程和上述步骤521-524无任何关系，只是为了进一步说明在本实施例中上行流媒体的处理情况。
步骤525，UE2向Tracker请求内容资源，Tracker返回存有该资源的Peer，其中包括UE1，UE2选择UE1作为内容传输节点。
步骤526，UE2向UE1发送内容请求消息。
步骤527，UE1返回内容请求响应消息。由于专用承载是下行承载，因此该消息对应的IP包无法匹配上专用承载，将会被自动匹配到默认承载，因此该消息将通过默认承载发送。
步骤528，UE1向所述UE2传送所述UE2请求的流媒体。由于专用承载是下行承载，因此该IP流无法匹配上专用承载，将会被自动匹配到默认承载，因此该IP流将通过默认承载发送。
由此可见，通过上述过程，可以实现下行流媒体的IP流走专用承载，其余IP流(主要是指信令和上行流媒体)走默认承载。
本发明的实施例二如图6所示，该实施例与图5所示实施例一的基本思想相同，区别点在于：UE在承载建立完成后可以通过承载修改过程对最初生成的TFT中的UE地址和端口信息以及Cache的地址和端口信息进行修改，修改后的TFT包含明确的UE和Cache媒体面IP地址和端口列表信息。该过程包含以下步骤：
步骤601-605，默认承载建立过程，同步骤501-505。
步骤606，UE1向P-CSCF发送会话请求(INVITE)消息，该消息是为了向Tracker请求拥有目标资源的节点列表。消息中携带UE1的终端能力信息、UE1要请求的内容信息、UE1的媒体面IP地址和端口信息。所述UE1的媒体面IP地址和端口信息在后续UE和Cache进行流媒体传输时可以通过重新分配或协商等方式进行修改。
步骤607-608，P-CSCF收到INVITE消息后，向S-CSCF转发该消息；S-CSCF将该消息发给Tracker。
步骤609，Tracker收到S-CSCF发送的INVITE消息后，根据INVITE消息中的资源ID和资源类型等信息获取存储了该资源的Cache列表，所述Cache列表中包含被选择的Cache的媒体面IP地址和端口信息，所述Cache的地址和端口信息在后续UE和Cache进行流媒体传输时可以通过重新分配或协商等方式进行修改。
步骤610，Tracker根据INVITE消息中携带的UE1的终端能力结合本地策略生成业务QoS需求。
上述步骤609和610无严格的先后顺序关系。
步骤611，Tracker在生成业务QoS需求后，向RCF发送资源预留请求消息，消息中携带业务QoS相关信息、UE1的标识、所述UE1的媒体面IP地址和端口信息、所述Cache的媒体面IP地址和端口信息等。
所述Cache的IP地址填通配符，端口不填，端口不填时表示通配。
此外，所述资源预留请求消息中还可以携带下行IP流指示，所述下行IP流指示表示该IP流只是一个单向的下行IP流。
步骤612，RCF收到Tracker发送的资源预留请求消息后，根据业务QoS相关信息结合用户QoS签约和运营商策略生成QoS策略，根据所述UE1的IP地址和端口信息、所述Cache的IP地址和端口信息和下行IP流指示信息生成TFT，所述TFT中IP流方向设为仅下行方向。因此，所述TFT对应的承载为一单向的下行承载。
之后，RCF向P-GW发送策略执行请求消息，消息中携带UE1的标识、QoS策略、TFT信息等。后续UE地址和端口信息发生改变后需要对所述TFT进行修改。
当然，所述RCF也可以不生成TFT，所述RCF将UE1的IP地址和端口信息、所述Cache的IP地址和端口信息和下行IP流指示信息发送给P-GW，由所述P-GW根据上述信息生成TFT。
所述下行IP流指示信息可以由所述Tracker发送，也可以由RCF根据本地策略产生。
步骤613，P-GW收到RCF发送的策略执行请求消息后，根据消息中携带的QoS策略信息分配EPS承载QoS。P-GW向MME发送创建承载请求消息，消息中携带UE1的标识、EPS承载QoS信息、TFT、EPS承载标识等。
步骤614-620，同步骤514-520。
步骤621，UE1获取到Cache列表后从中选择一个或者多个Cache作为内容获取节点，下称目标Cache。
步骤622，UE1和选择的目标Cache之间协商媒体面IP地址和端口，在这个过程中，UE1可以重新分配新的媒体面IP地址和端口列表，Cache也可以动态分配自身的媒体面IP地址和端口列表，所述UE1和/或Cache的媒体面IP地址和端口列表包含一个或多个端口。通过这个过程，UE1和目标Cache之间通知并获知了对方的媒体面IP地址和端口列表。本实施例中以UE1和一个Cache之间协商为例，多个Cache的情况类似。
该协商过程可以通过步骤626-627的内容请求流程实现，也可以通过其他单独的消息流程实现。
步骤623-624，UE1通过承载修改流程通知P-GW修改TFT。UE1启动承载修改的流程是，所述UE1根据协商确定的UE1媒体面IP地址和端口列表和/或所选择的目标Cache媒体面IP地址和端口列表生成TAD(Traffic AggregateDescription，流量聚合描述)信息。之后UE1向MME发送承载资源修改请求消息，携带承载标识和TAD等信息。MME向P-GW发送承载资源命令，携带承载标识和TAD等信息。
需要说明的是，UE1修改TFT时不修改IP流的方向，即在此过程中IP流方向仍然是下行方向，此承载依然是单向的下行承载。另外在实施过程中，由于流程的差异可能导致初始TFT的方向不是单向下行方向，或者承载建立请求由UE1发起，那么UE1发起的承载建立请求或承载修改请求中需将IP流方向设置为下行方向。
步骤625，P-GW收到承载资源命令后，根据TAD信息修改TFT，并通知UE1进行承载更新过程。此时，P-GW可根据TFT进行承载绑定。
步骤626-632，同步骤522-528。
由此可见，通过上述步骤，可以实现下行流媒体的IP流走专用承载，其余IP流(主要是指信令和上行流媒体)走默认承载。
综上所述，本发明能够实现基于IMS based CDS架构的内容分发网络中更为灵活和精细化的流媒体QoS策略控制，同时能针对流媒体业务特征对上下行流媒体不同的传输需求分配不同的承载，实现对带宽更为有效的利用。
以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。
Claims (12)
1.一种保障流媒体业务质量的方法，其特征在于，该方法包括：
分组数据网络网关P-GW为流媒体业务建立专用承载；
所述P-GW通过所述专用承载发送流媒体业务的下行媒体流数据，通过默认承载接收流媒体业务的上行媒体流及信令数据；用户设备UE通过所述专用承载接收流媒体业务的下行媒体流数据，通过默认承载发送流媒体业务的上行媒体流及信令数据。
2.根据权利要求1所述保障流媒体业务质量的方法，其特征在于，所述专用承载为单向下行承载。
3.根据权利要求1或2所述保障流媒体业务质量的方法，其特征在于，所述P-GW根据服务质量QoS策略信息和流量模板TFT建立专用承载；
所述TFT中携带方向指示表示所述TFT所匹配的是单向下行承载。
4.根据权利要求3所述保障流媒体业务质量的方法，其特征在于，所述方向指示由RCF从应用功能实体AF获取后通知所述P-GW，或者由所述RCF根据本地策略生成后通知所述P-GW，或者由所述UE生成后通知所述P-GW。
5.根据权利要求3所述保障流媒体业务质量的方法，其特征在于，所述TFT中携带所述UE的IP地址和端口信息、以及存储了所述UE请求资源的内容缓存服务器Cache的IP地址和端口信息；所述UE的IP地址和端口信息、以及所述Cache的IP地址和端口信息由内容跟踪服务器Tracker通过RCF通知给所述P-GW。
6.根据权利要求3所述保障流媒体业务质量的方法，其特征在于，所述P-GW将所述UE向目标Cache请求的下行媒体流数据通过所述TFT绑定到所述专用承载发送给所述UE，所述UE通过所述专用承载接收所述下行媒体流数据。
7.一种保障流媒体业务质量的***，其特征在于，该***包括：用户设备UE、分组数据网络网关P-GW，其中，
所述P-GW，用于为流媒体业务建立专用承载；所述P-GW通过所述专用承载发送流媒体业务的下行媒体流数据，通过默认承载接收流媒体业务的上行媒体流及信令数据；
所述UE，用于通过所述专用承载接收流媒体业务的下行媒体流数据，通过默认承载发送流媒体业务的上行媒体流及信令数据。
8.根据权利要求7所述保障流媒体业务质量的***，其特征在于，所述专用承载为单向下行承载。
9.根据权利要求7或8所述保障流媒体业务质量的***，其特征在于，所述P-GW进一步用于，根据服务质量QoS策略信息和流量模板TFT建立专用承载；
所述TFT中携带方向指示表示所述TFT所匹配的是单向下行承载。
10.根据权利要求9所述保障流媒体业务质量的***，其特征在于，所述方向指示由RCF从应用功能实体AF获取后通知所述P-GW，或者由所述RCF根据本地策略生成后通知所述P-GW，或者由所述UE生成后通知所述P-GW。
11.根据权利要求9所述保障流媒体业务质量的***，其特征在于，
所述TFT中携带所述UE的IP地址和端口信息、以及存储了所述UE请求资源的内容缓存服务器Cache的IP地址和端口信息；所述UE的IP地址和端口信息、以及所述Cache的IP地址和端口信息由Tracker通过RCF通知给所述P-GW。
12.根据权利要求9所述保障流媒体业务质量的***，其特征在于，所述P-GW进一步用于，将所述UE向目标Cache请求的下行媒体流数据通过所述TFT绑定到所述专用承载发送给所述UE，
所述UE通过所述专用承载接收所述下行媒体流数据。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2011103423305A CN103096179A (zh) | 2011-11-02 | 2011-11-02 | 一种保障流媒体业务质量的方法和*** |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2011103423305A CN103096179A (zh) | 2011-11-02 | 2011-11-02 | 一种保障流媒体业务质量的方法和*** |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN103096179A true CN103096179A (zh) | 2013-05-08 |
Family
ID=48208225
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2011103423305A Pending CN103096179A (zh) | 2011-11-02 | 2011-11-02 | 一种保障流媒体业务质量的方法和*** |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN103096179A (zh) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105141545A (zh) * | 2014-06-05 | 2015-12-09 | 北京邮电大学 | 一种IP航空电信网空地通信QoS保障方法与*** |
| WO2016201939A1 (zh) * | 2015-06-16 | 2016-12-22 | 中兴通讯股份有限公司 | 专用承载建立方法、装置及用户设备 |
| CN106537857A (zh) * | 2014-06-30 | 2017-03-22 | 英特尔Ip公司 | 增强用于lte的服务质量架构的装置和方法 |
| CN106534898A (zh) * | 2016-11-15 | 2017-03-22 | 中国联合网络通信集团有限公司 | 一种获取流媒体数据的方法、装置及*** |
| CN108200140A (zh) * | 2017-12-26 | 2018-06-22 | 广东欧珀移动通信有限公司 | 专用承载的建立方法及相关设备 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101388901A (zh) * | 2007-09-14 | 2009-03-18 | 大唐移动通信设备有限公司 | 长期演进***中支持用户静态ip地址寻址的方法及*** |
| CN101400148A (zh) * | 2007-09-26 | 2009-04-01 | 华为技术有限公司 | 缺省承载建立过程中专有承载建立的控制方法和设备 |
| CN101686171A (zh) * | 2008-09-27 | 2010-03-31 | 华为技术有限公司 | 承载建立、修改过程中实现单向承载的方法、***及设备 |
| CN101860910A (zh) * | 2009-04-09 | 2010-10-13 | 大唐移动通信设备有限公司 | 本地网络的承载建立方法、***及装置 |
| CN101964996A (zh) * | 2010-01-18 | 2011-02-02 | 华为终端有限公司 | 一种优化无线数据传输的方法及装置 |
| US20110170517A1 (en) * | 2010-01-11 | 2011-07-14 | Research In Motion Limited | System and method for enabling session context continuity of local service availability in local cellular coverage |
-
2011
- 2011-11-02 CN CN2011103423305A patent/CN103096179A/zh active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101388901A (zh) * | 2007-09-14 | 2009-03-18 | 大唐移动通信设备有限公司 | 长期演进***中支持用户静态ip地址寻址的方法及*** |
| CN101400148A (zh) * | 2007-09-26 | 2009-04-01 | 华为技术有限公司 | 缺省承载建立过程中专有承载建立的控制方法和设备 |
| CN101686171A (zh) * | 2008-09-27 | 2010-03-31 | 华为技术有限公司 | 承载建立、修改过程中实现单向承载的方法、***及设备 |
| CN101860910A (zh) * | 2009-04-09 | 2010-10-13 | 大唐移动通信设备有限公司 | 本地网络的承载建立方法、***及装置 |
| US20110170517A1 (en) * | 2010-01-11 | 2011-07-14 | Research In Motion Limited | System and method for enabling session context continuity of local service availability in local cellular coverage |
| CN101964996A (zh) * | 2010-01-18 | 2011-02-02 | 华为终端有限公司 | 一种优化无线数据传输的方法及装置 |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105141545A (zh) * | 2014-06-05 | 2015-12-09 | 北京邮电大学 | 一种IP航空电信网空地通信QoS保障方法与*** |
| CN106537857A (zh) * | 2014-06-30 | 2017-03-22 | 英特尔Ip公司 | 增强用于lte的服务质量架构的装置和方法 |
| CN106537857B (zh) * | 2014-06-30 | 2020-03-13 | 英特尔Ip公司 | 增强用于lte的服务质量架构的装置和方法 |
| WO2016201939A1 (zh) * | 2015-06-16 | 2016-12-22 | 中兴通讯股份有限公司 | 专用承载建立方法、装置及用户设备 |
| CN106534898A (zh) * | 2016-11-15 | 2017-03-22 | 中国联合网络通信集团有限公司 | 一种获取流媒体数据的方法、装置及*** |
| CN108200140A (zh) * | 2017-12-26 | 2018-06-22 | 广东欧珀移动通信有限公司 | 专用承载的建立方法及相关设备 |
| CN108200140B (zh) * | 2017-12-26 | 2019-06-25 | 广东欧珀移动通信有限公司 | 专用承载的建立方法及相关设备 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9602417B2 (en) | Multiple bearer support upon congestion situations | |
| CN102934459B (zh) | 在暂停ip电视(iptv)会话时释放互联网协议(ip)多媒体子***(ims)会话发起协议(sip)、ip-连接性接入网(ip-can)和无线接入网(ran)联网资源的方法和*** | |
| CN103404102B (zh) | 一种承载创建方法、装置和*** | |
| CN101835201B (zh) | 一种多网络连接环境中保证数据不中断的方法及*** | |
| KR102016428B1 (ko) | 서비스 레이트를 위한 조정 방법 및 디바이스 | |
| US20070237134A1 (en) | Packet-based conversational service for a multimedia session in a mobile communications system | |
| CN102457477B (zh) | Ims多媒体优先级业务会话处理方法和装置 | |
| EP1382214A2 (en) | Binding information for ip media flows | |
| CN102413522A (zh) | 一种用于通信***中切换期间传输信息的方法 | |
| CN101448292A (zh) | 一种接入网获取归属网代理呼叫会话控制功能的方法 | |
| CN103096179A (zh) | 一种保障流媒体业务质量的方法和*** | |
| CN103119981B (zh) | 服务质量控制方法和设备 | |
| CN109792799A (zh) | 一种业务通信方法及设备 | |
| CN101978727B (zh) | 单接收机语音连续切换及其数据传输的方法、装置和*** | |
| CN102891830B (zh) | 保障流媒体业务服务质量的方法及*** | |
| CN1870635B (zh) | 一种服务质量授权方法 | |
| Yun et al. | QoS control for NGN: A survey of techniques | |
| CN102904859A (zh) | 保障流媒体业务服务质量的方法及*** | |
| CN104468481A (zh) | 一种实现媒体QoS承载资源控制的方法及装置 | |
| CN100377546C (zh) | 一种保证业务服务质量的数据包传输方法 | |
| CN100502395C (zh) | 一种保证端到端业务质量的ip网络及方法 | |
| CN100433890C (zh) | 应用动态业务质量控制的移动数据业务实现方法 | |
| Rexhepi et al. | A framework for QoS & mobility in the Internet next generation | |
| Corici et al. | Prototyping mobile broadband applications with the open Evolved Packet Core | |
| CN101102254A (zh) | 跨域端到端路径建立方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WD01 | Invention patent application deemed withdrawn after publication | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20130508 |