互联网流量内容交付的系统、装置及其方法

摘要

在一个实施例中，提供媒体的方法包括例如，在部署在内容交付网络180中的媒体控制器182接收为用户设备110提供媒体内容的请求和接收缓存与媒体内容有关的信息的请求。缓存信息包括有关用户设备110请求的媒体内容是否可以缓存的信息。如果媒体内容可缓存，便从媒体服务器层次集中(例如，MX-A124，MX-B184，MX-C194)分配第一媒体服务器(例如，MX-A124)，以便为用户设备提供服务。媒体服务器层次集包括部署在多个L2接入网的多个第一媒体服务器。用户设备110通过多个L2接入网的L2 120接入网与内容交付网络180耦合。

说明书

交叉引用相关申请

本专利申请要求2011年5月11日提交的申请号为13、105.439，名 称为“互联网流量内容交付的系统、装置及其方法”的美国正式申请，以及 2010年5月13日提交的申请号为61/334,548，名称为“产生、分发以 及呈现预览在线媒体业务的系统”的美国临时申请案的优先权，该两申请将 引用该申请以作参考。

技术领域

本发明主要涉及内容交付，具体涉及互联网流量内容交付的系统、 仪器及其方法。

背景

近年来，应用移动设备的媒体消费大幅度增加。结果，流量的爆炸 性增长，使电信网络拥挤不堪。这一现象在移动宽带(MBB)网络上更为明 显，其基础设施的成本比固定宽带(FBB)网络的成本高出许多(大约超出 20至30倍)。近期，移动设备(如智能手机、平板电脑、上网本和笔记本 电脑)大量普及使用，开创了无线接入高速全网络的新纪元。因此，多媒体 通信流量的增长预计比FBB网络前5年(从2000年到2005年)的流 量增长更加迅速。

但是，MBB和FBB网络运营商并没有从流量增幅中受益。大多 数这种快速增长的流量并不会为MBB和FBB网络运营商带来利益，因 为这种流量被直接归类为消费者流量，而消费者流量通常被视为OTT (Over-The-Top)流量。因此，降低快速增长的OTT流量的影响，已经成为 MBB和FBB网络运营商的当务之急。

OTT流量不同于其他流量，如企业对企业(B2B)或企业对消费者 (B2C)流量，其中，OTT内容和流量特征对运营商来说都是未知的。这些 未知的特征包括媒体源、媒体类型、所使用的交付协议/方式、受保护与明 确内容、动态与静态内容等。因此，由于技术的复杂性、网络成本和OTT处 理上的不确定性，使得应对并降低OTT流量的影响变得困难。

发明内容

一般情况下，通过本发明的实施例可以解决或绕过这些问题和其他 问题，并实现主要的技术优势。

在本发明的一个实施例中，服务媒体的方法包括接收为用户设备提 供媒体内容的请求和接收缓存与媒体内容有关的信息的请求。缓存信息包括 有关用户设备请求的媒体内容是否可以缓存的信息。此方法还包括在将要提 供的媒体内容是可缓存的，便将媒体服务器层次集中的第一媒体服务器分配 给用户设备。媒体服务器层次集包括部署在多个第2层(L2)接入网的多 个第一类媒体服务器。用户设备通过多个L2接入网的L2接入网与内容 交付网络耦合。

在本发明的其他实施例中，一种提供媒体服务的方法包括在部署在 L2接入网上的第一台媒体服务器上，接收将可缓存媒体内容提供给用户设 备的请求。用户设备通过L2接入网与内容交付网络耦合。上述方法另包 含确定可缓存媒体内容是否存储于第一媒体服务器中。第一媒体服务器不会 确定可缓存媒体内容是否可缓存内容。如果媒体内容已存储在第一媒体服务 器的缓存中，便会从缓存将可缓存媒体内容提供给用户设备。

在本发明的其他实施例中，一种提供媒体服务的方法包括接收将可 缓存媒体内容提供给用户设备的请求。用户设备通过多个L2接入网的L2 接入网与内容交付网络耦合。上述方法另外还包括确定将要提供的媒体内容 是否可缓存，以及在要供应的媒体内容是可缓存的情况下，重定向请求以便 将媒体内容提供给第一媒体服务器。第一媒体服务器是媒体服务器层次集中 的一台媒体服务器。媒体服务器层次集包括部署在多个L2接入网的多个 第一类媒体服务器。

在本发明的另一个实施例中，媒体串流的一个方法包括接收将可缓 存媒体内容提供给用户设备的请求，以及确定请求的目的地互联网协议(IP) 地址。上述方法还包括在目的地IP地址与存储的目的地IP地址列表相匹 配的情况下，将收到的请求转发至L2接入网的第一媒体服务器。收到的 请求会被重新打包成一个TCP/IP消息并被转发至第一媒体服务器。

下文将详细列出本发明实施例的特点，以便使以下发明的详细说明 更易懂。后文将说明本发明实施例的其它功能和优势，构成本发明权利要求 的主题。本技术领域的人员应深知，本文所透露的概念和指定实施例可被用 作为修改或设计与本发明拥有相同目的的其他结构或流程的基础。上述技术 人员还应认识到，这些等效结构并不违背追加申请中阐述的发明的精神和范 畴。

附图简介

为提供更完整的本发明见解及其优势说明，现为以下说明提供参考信息，请 参阅与其相对应的附图，其中：

图1说明了采用Gi卸载方法来处理OTT流量的在先技术接入网卸载解 决方案；

图2描述了一种先进技术方法(“基于Gi卸载的流量卸载功能(TOF)”)， 根据TR 23.829标准，这种方法在第4种实施例中还被称为“移动边缘接 入网关(MEAG)”；

图3依据当前3GPP标准说明了一种在MBB网络中使用的在先技术方 法(“本地网关GPRS支持节点(GGSN)方法”)；

图4根据本发明的其中一个实施例说明了用于MBB和/或FBB网络的 统一内容交付网络解决方案；

图5包括图5A至图5D，说明了根据本发明实施例所进行的L2网络的 配置；

图6包括图6A至图6D，说明了根据本发明实施例所进行的L3网络和 内容交付网络的配置；

图7说明了根据本发明实施例应用于MBB网络的统一内容交付解决方 案；

图8包括图8A至图8D，说明了根据本发明实施例对内容交付网络中的 组件所进行的配置；

图9说明了根据本发明实施例所部署的媒体服务器的层次结构；

图10说明了根据本发明实施例对媒体控制器中存储的分组数据协议 (PDP)上下文数据所制定的表；

图11说明了根据本发明实施例可在一般情况下进行的控制和媒体消息流 操作；

图12说明了当UE在多个网络中或跨多个网络重定位/漫游时，根据本发 明多个实施例可对资源进行的重新分配；

图13说明了当UE在多个网络中或跨多个网络重定位/漫游时，根据本发 明实施例可对资源进行的重新分配，并强调了可能的影响；

图14说明了根据本发明实施例可在MBB网络中对其进行重定位和漫游 的一般网络体系结构，其中，图14A说明了图12中方案II下的漫游实 施例，图14B说明了图13中方案III下的漫游实施例；

图15说明了根据本发明的实施例，在SGSN间进行UE重定位的一套经 修改的程序；

图16说明了一种供用于根据3GPP 33.107进行分组交换合法监听(LI) 的在先技术参考配置，据此并入本发明，以供参考；

图17说明了一种适用于实施合法监听方法的实施例；

图18包括图18A和图18B，说明了另一个适用于合法监听方法的实施 例，其中，层2网络中的媒体服务器决定并交付与目标UE的通信，图18A 说明了实施LI的上下文图，及图18B说明了LI消息流；

图19包括图19A和19B，说明了合法监听方法的第三种实施例，其中， 层2网络中的媒体服务器决定并交付(但通过媒体控制器)与目标UE的 通信，图19A说明了实施LI的上下文图，及图19B说明了LI消息流；

图20根据本发明的实施例演示了用于处理计费、报告和分析的一般网络体 系结构以及经验规定的质量；

图21说明了用于根据本发明实施例对媒体服务器故障进行处理的一般网 络体系结构；

图22说明了实施上述发明实施例的XDSL网络；

图23说明了实施上述发明实施例的有线宽带网络；

图24说明了符合本发明实施例的代表性媒体服务器；

图25说明了用于根据本发明实施例提供媒体服务的媒体控制器的组件；

图26说明了用于根据本发明实施例提供媒体服务的媒体服务器的组件；

图27说明了用于根据本发明实施例提供媒体服务的内容处理器的组件；

图28说明了用于根据本发明实施例提供媒体服务的交互功能单元的组件；

图29说明了用于根据本发明实施例串流媒体的第二媒体服务器的组件；

图30说明了用于根据本发明实施例串流媒体的媒体控制器的组件；

图31说明了用于根据本发明实施例串流媒体的L3节点3100的组件；

图32说明了用于根据本发明实施例串流媒体的媒体服务器的组件；

图33根据本发明实施例说明了深层数据包检测节点的组件；

图34根据本发明实施例说明了媒体服务器的组件；

图35根据本发明实施例说明了媒体服务器的组件；

图36根据本发明实施例说明了媒体控制器的组件；

图37根据本发明实施例说明了媒体服务器的组件；

图38根据本发明实施例说明了媒体数据单元的组件；

图39根据本发明实施例说明了L2接入网中的媒体服务器的组件；

图40根据本发明实施例说明了媒体控制器的组件；

图41根据本发明实施例说明了互通功能单元的组件；以及

图42根据本发明实施例说明了媒体控制器的组件。

不同图片中的相应数字和符号一般指相对应的部件，除非另有说明。这些图 片虽未按比例绘制，但可清晰说明实施例的相关部分。

具体实施例的详细说明

下文将详细讨论多种实施例的制备和使用。但这应理解为，本发明提 供许多适用的发明概念都能够在各种各样的指定场合中实施。所讨论的指定 实施例只是演示本发明的指定利用和使用方法，而不是限制本发明的使用范 围。

下文将说明在下列描述中使用的基本功能实体的定义和首字母缩略词 以及实体之间的接口。

首字母缩略词：

AAA-认证、授权及计帐

ADMF-合法监听的管理功能

B2B-企业对企业(运营商向另一个企业提供服务的一种模型)

B2C-企业对消费者(运营商向其终端用户提供服务的一种模型)

BC-计费和收费策略服务器

BG-边界网关(互联网对等点)

CC-CDN控制(一种控制功能，用于决定哪个MS来处理给定请求)

CDN-内容交付网络(支持OTT、B2B和B2C的开放式CDN)

CG-计费网关(负责服务的计费事宜)

DF-交付功能(LI基础设施术语)

DPI-深层数据包检测(一种用于检测数据包的功能)

DPI-C-内容请求级别DPI(涉及到深层HTTP头、URL分析)

DSL-数字用户线路

FBB-固定宽带(XDSL、电缆网络等)

GGSN-网关GPRS支持节点

GPRS-通用分组无线服务

GSN-GPRS支持节点(可能是SGSN也可能是GGSN)

IWF-互连功能(一种特殊功能，用于连接L2节点和媒体服务器)

L2节点-层2节点(如MBB中的RNC和节点B、FBB网络中 的DSLAM等)

L3节点-层3节点(如MBB中的GGSN或FBB中的BRAS 等)

LEMF-执法监控功能

LI-合法监听(为LI的接口，如MBB的LIG)

LIG-合法监听网关

LIMS-LI管理系统

MBB-移动宽带(2.xG、3G、4G或WiMax网络)

MC-媒体控制(与CDN控制功能相同)

MD-媒体数据(数据分析、日志和报告)

MS-媒体服务器(提供媒体流、缓存和适配功能)

MX-媒体开关(与MS的功能相同)

NB-节点B(3GPP RAN功能，例如也被称为BS、eNB的无线基 站)

OCS-在线计费系统

OTT-Over The Top(网络运营商未知的内容和流量类型)

PCC-策略计费和控制

PCRF-策略、计费规定功能

PS-策略服务器(如MBB中的PCRF)

QoE-体验质量(终端用户体验质量)

QoS-服务质量

RNC-无线网络控制器(3GPP标准中的RAN控制功能)

SGSN-为GPRS支持节点提供服务

SUR-用户使用报告

UE-用户实体(终端用户设备/客户端)

XDSL-DSL技术(如ADSL和HDSL)的所有变体。

图1至图3将说明关于处理OTT流量的不同在先技术方法。但是， 发明者已经认识到这些在先技术方法具有不同的优点和缺点，在下文我们将 对这些优点和缺点做详细探讨。

下文描述的申请使用缩写词GGSN和SGSN的目的仅在于举例说 明。这些术语还可以是在网络中执行这些操作的服务器。例如，在3GPP  LTE/4G网络中执行GGSN操作的服务器是指系统体系结构进化网关 (SAE-GW)，在3GPP LTE/4G网络中执行SGSN操作的服务器是指移动管 理实体(MME)。因此，执行GGSN、SAE-GW和相似等效服务器操作的 服务器的类别可指网关服务器节点，执行SGSN、MME和相似等效服务器 操作的服务器的类别可以指服务/管理节点。仅出于说明的目的，描述中使 用了GGSN和SGSN。本文描述的各种实施例中可使用任何相对应的服务 器。

图1说明了采用Gi卸载方法来处理OTT流量的在先技术接入网卸 载和缓存解决方案。

图1说明了一种通过层2(L2)网络20与互联网70相耦合的用户 设备(UE 10)，如无线接入网、层2(L2)节点21。L2节点21可以是基 站、NB、eNB、无线网络控制器等。L2网络20通过层3(L3)网络30与 互联网70相耦合。L3网络30提供服务，如计费网关(CG)31、合法监 听(LI)32和策略服务器(PS)33。

Gi卸载方法在移动宽带(MBB)网络中广泛使用。在Gi卸载方法中， 通过IP流量网络40引入了缓存媒体服务器MS 41。MS 41可作为独立 的缓存功能或作为CDN网络中的媒体服务器发挥功能性。深层数据包检 测DPI 37功能可以独立于L3节点36(如网关GPRS支持节点 (GGSN))或作为其中的一部分。然而，Gi卸载方法在DPI功能下不能帮 助缓解流量压力，因为网络路径中缓存有大量内容。为了解决这一问题，图 2中引入了第二种方法，但仅作说明之用。

图2说明了一种在先技术方法(“基于Gi卸载的流量卸载功能 (TOF)”)，这种方法还被称为“移动边缘接入网关(MEAG)”。

在MEAG方法中，卸载位置自L3节点36(例如GGSN位置上的 Gi)转移至L2节点(例如，RNC)。Gi是GGSN和公共数据网络(PDN) 之间基于IP的接口。如图2中所示，向L2网络20引入了TOF 22。因 此，这种方法能够提供节省上述TOF 22的带宽，即，节省TOF 22中所 有L3节点36的实际带宽。但是为了支持所有其它与MBB接入网相关 的支持类服务，例如，合法监听(LI)、实时计费服务和基于策略的QoS服 务(PCRF)，TOF 22需要支持与图2中描述的CG 31、LI 32和PS 33的 直接接口。

MS41(虚线框)是一个MS可选功能，可供独立的缓存服务器或CDN 网络中的媒体服务器使用。卸载功能和缓存功能可进行固有解耦，但二者可 结合用于实现其它优点。

但是，本方法具有很多缺点。首先，所有流量都要在TOF 22上使用 深层数据包检测(DPI)类型的方法进行分析。这大大降低了L2网络20 的性能。其次，为了支持MBB相关服务(如CG 31，LI 32)和PS 33，必 须保持TOF 22与这些功能的直接接口，使CG 31、LI 32和PS 33的相 互作用复杂化。再次，为了实现上述第一和第二两个目的，TOF 22可以变 成具有多种MBB的SGSN普通功能和GGSN功能的复杂功能。

即使存在上述缺点，本方法已采纳为TR23.829标准的第四备用项。 下一个方法旨在改善这第二个方法中的上述缺点。

图3说明了一种在MBB网络中使用的在先技术方法(“本地网关 GPRS支持节点(GGSN)方法”)。在本方法中，L2节点是无线网络控制器 (RNC)，L3节点是本地GGSN。

本方法(再次声明：在MBB域中)旨在使用标准GSN处理已呼叫 的直接隧道，有利于L2网络20中的L2节点21(例如，RNC)创建至 本地L3节点26，例如，本地GGSN的直接隧道。因此，本地GGSN位 于RNC(L2节点21)侧，从而有利于RNC通过本地GGSN(本地L3节 点26)将某些类型的流量(如网络流量)卸载到互联网。在本方法中，现 有SGSN和GGSN功能位于非卸载路径中。

已针对本方法提出了两种稍微不同的配置：静态卸载和动态卸载。首 先，在静态卸载配置中，设置之后，卸载流量会以静态方式通过本地L3节 点26(本地GGSN)，而非卸载流量将继续通过L3节点36(GGSN)。如 图3所示，在设置分组数据协议(PDP)时，SGSN(另一个L2/L3节点) 可以确定静态配置。这需要对SGSN进行修改，以处理卸载策略和识别本 地GGSN。

或者，动态卸载配置用虚线显示在本地L3节点26和L3节点36 之间。在这一情况下，所有数据流量流入本地L3节点26(本地GGSN)， 其会作出卸载决定，包括在单个PDP内的不同数据流上适用不同的卸载策 略。SGSN总会选择L3节点36(宏GGSN)和本地L3节点26(本地 GGSN)作为宏GGSN的代理。

在向核心L3节点(MBB环境中的SGSN和GGSN)提供服务方面， 本方法与第二个方法具有相似的优势。但是，因为GGSN是一种标准的 MBB功能，而且其与CG 31、LI 32和PS 33等等之间的接口已有定义且 标准化，所以在L2节点21位置上引入本地GGSN(例如，RNC)应该 可解决许多问题。然而本方法也存在其它缺点，具体可见下方的描述。

第一，L3节点36，例如GGSN，是一种复杂功能，其实施过程相对 昂贵且难以管理。因此，部署多个GGSN节点并不符合成本效益。第二， 网络中若有多个GGSN，则CG 31、LI 32和PS 33等等之间的交互会变 得更加复杂。例如，实时计费功能将须要接收两个GGSN(本地L3节点26 和L3节点36)的输入，以确定活动的会话是否已达到额定限值。第三， 在一个所有服务都使用单个APN的单一接入点名称(APN)设置过程中， 这一方案可能会面临挑战。尤其是在分组数据协议(PDP)设置好后，上述 的静态卸载配置，即从L2节点21(RNC)至本地L3节点26(本地 GGSN)之间以静态方式确定的卸载不可更改。

在本发明的各实施例中，我们将描述任何L2接入网(如RAN网络 或XDSL接入网，亦或电缆网络)中基于L3的内容交付网络(CDN)媒 体服务器(MS)的部署方法。这种CDN媒体服务器的部署可在维持具有 处理面向MBB网络和FBB网络的OTT、B2B和B2C服务能力的CDN 网络的统一、通用和开放的同时，还可用于缓存和处理更接近于用户装置的 媒体内容。

如果CDN媒体服务器在缓存通过接入网络(MBB或FBB)向终端 用户交付的OTT内容时位于更接近终端用户装置的位置，则现有网络基础 设施的成本节约潜能会更大。这是因为无线接入网(RAN)节点的基础设施 成本相较于分组交换(PS)网络来说更加高。因此，沿着接入路径，将媒体 服务器向终端用户装置进一步移动，会比较有利。

然而，最后一英里的接入网可能是L2网络或者是非IP闭环网络，如 RAN(在3G无线网络中)或XDSL。媒体服务器在这些网络中的部署至 少会面临两种挑战。第一，媒体服务器(通常它会是一个L3节点)需要 特殊接口以便与L2网络相交互。第二，定期卸载(TOF)方式，需要一种 DPI流程来确定OTT流是否可缓存，然后进行本地卸载或缓存。这种DPI 流程可能会要求相当密集的CPU处理，并可能会降低接入节点的功能。

本发明的实施例通过将L3媒体服务器部署到具有解耦功能的L2接 入网中，克服了这些问题和其他问题。尤其是，如OTT流量检测、缓存决 定和OTT流量请求路由决定等部分功能，均保留在L3 CDN网络中。本 发明的实施例还包括对MBB网络域中以下多种功能的独特处理：如合法 监听(LI)、与处理相关的在线计费系统(OCS)、QoS处理和支持，以及 MBB和FBB网络的很多其它功能支持。

下文将首先采用图4的系统基础设施架构以描述本发明的实施例；采 用图5-6和图8-9以描述单元的详细结构实施例；分别采用图7、图22 和图23描述本发明适用于移动宽带网络、XDSL网络、电缆宽带网络的实 施例。下文将采用图11以描述适用于MBB网络的流操作实施例；采用 图12-15以描述本发明涉及有关处理漫游/重定位的实施例；采用图17-19 以描述本发明适用于合法监听的实施例；根据图20，描述本发明适用于处 理计费、报告和分析以及体验规定的质量的实施例；根据图21，描述本发 明适用于处理媒体服务器故障的实施例。

图4根据本发明的其中一个实施例说明了用于MBB和/或FBB网 络的统一内容交付网络解决方案。

在图4中，UE 10表示终端用户装置，如移动装置或具有无线网卡的 装置。关于图4，具有多个L2节点21的L2网络20和具有多个L3节 点36的L3网络30形成了一个通向互联网70的接入网络。除L2节点 21之外，各实施例在L2网络20内都包含一个互通功能IWF 23和一个 基于L3的媒体服务器MS-A 24。IWF 23在L2网络20中的层2节点 与MS-A 24之间充当接口和路由功能。

位于L2网络中的媒体服务器将标记为MS-A，而位于L3网络中的 媒体服务器将标记为MS-B，以便于区分不同类型的媒体服务器。在L3网 络30中，深层数据包检测(DPI)37功能检查UE的签名匹配请求，以确 定请求是否需要转移至内容交付网络(CDN)80以进行下一步处理。因此， DPI 37将特定的UE请求转移至CDN 80以进行下一步处理。

可以配置DPI 37来检测通过它的数据包，例如，搜索协议不合规性、 病毒、垃圾邮件、入侵，或预定义标准以决定对数据包采取哪些措施，包括 收集统计信息。DPI 37可新增对OSI模型层2至层7的检查功能，这可 包括标头、数据协议结构和消息的实际有效载荷。基于从数据包数据部分中 提取的信息的签名数据库，DPI 37可识别流量并对其进行分类，从而实现 比仅基于标头信息的分类更精细的控制。在其他实施例中，DPI 37可识别 流量是否包含OTT类别。经分类的数据包可以在网络中重定向、标记/标 签、拦截、设置额定限制和/或报告给报告代理。

CDN 80是一组战略部署在所有IP网络上的典型服务器，可分层也可 不分层。CDN 80拥有多个不同的设备，可在地理上分布开来。示例中，CDN  80所含的设备包括位于CDN 80中各点上的服务器。例如，UE 10可访问 距其最近的服务器的数据副本，而不需从中心服务器进行访问。或者，位于 相似位置的多个用户可从不同服务器访问相同的文件，防止单个仓库服务器 超载。对于存储在CDN 80中的内容，其类型包括网络对象、可下载对象 (媒体文件、软件和文档)、应用程序、实时媒体流和互联网交付的其他组 件(DNS、路由和数据库查询)。

在多个实施例中，内容交付网络(CDN)80中异常路径内容层级的深 层数据包检测单元(DPI-C)81理解OTT请求并决定由哪一个媒体服务器 为提出媒体请求的UE提供服务。通过使用外部DPI-C 81，最大程度地降 低对现有网络组件的影响。这是因为DPI 37通常已整合至L3节点36。 所以，其他功能会从现有DPI 37中区别开来。

在多个实施例中，MS-A 24被引入到更加接近UE 10的L2网络20 中，同时尽可能对CDN 80与L2网络20及L3网络30的功能进行解 耦。在不同的实施例中，密集型操作，如DPI-C 81功能，在CDN 80上予以 处理这相比L2节点21，其装备更优良，更适合执行复杂任务。这避免了 为执行密集型操作而为L2节点增加昂贵资源的需要。有利的一点是，通 过结合上述方法，接入网络(MBB或FBB)和CDN 80可保持它们在功 能上的相对独立性，同时相互协调以最大限度地提高处理OTT流量，并在 常见的统一方法中存在B2B与B2C服务(如果这两项)的情况下，最大 程度地提高这些服务的效率。

L2网络20和L3网络30中插入的功能可处理图5和图6中所 示的多份不同的配置表单。

图5包括图5A至图5D，说明了根据本发明实施例制定的L2网络 的配置。

图5A说明了其中L2节点21、IWF 23和MS-A 24作为独立单元 (如物理上独立的机器)的一个实施例。在图5B中，L2节点21和IWF  23是同一个整合单元(同一个箱/机器)，而MS-A 24则独立构成。在图5C 中，IWF 23和MS-A 24作为一体化单元，而L2节点21是独立单元。 在图5D中，所有组件都整合至同一个物理单元。

在图5中，图5A和5C中演示的配置为MS-A 24向L2网络20 的透明引入带来了益处，而不会对L2节点21带来任何影响。这需要IWF  23在将MS-A 24引入到L2网络20时为L2节点21提供完整的透明 度。这种方式的优点之一就是L2节点21可以由不同的供应商提供，然 后由供应商提供IWF 23和MS-A 24。

相反的是，图5B中的配置可大大简化IWF 23，因为L2通信的消息 和数据流信息已大部分存在于L2节点21。

图6包括图6A至图6D，说明了根据本发明实施例所进行的L3网 络和内容交付网络的配置。

图6A说明了其中L3节点36、DPI 37和DPI-C 81作为独立单元 (如物理上独立的机器)的一个实施例。在图6B中，L3节点36和DPI  37是同一个整合单元(同一个箱/机器)，而DPI-C 81则独立构成。在图6C 中，DPI 37和DPI-C 81作为一体化单元，而L3节点36是独立单元。 在图6D中，所有组件都整合到单一物理单元中。

关于图6，图6A和6B的配置为非OTT流量带来最小延迟的益处， 并可使接入网络30(L3节点36和DPI 37)与CDN网络80(DPI-C 81) 年之间解耦。为了实现OTT流量识别而对内容层级DPI和基本DPI进 行解耦，这具有一定的优势，原因在于用于处理OTT的内容层级DPI要 求对DPI签名进行持续调谐，并不断准备DPI算法，以应对OTT内容 和流量剖析中的变动。

因此，图6C和图6D所示的配置无法实现这些优势。因为当前已经 部署的许多L3节点36也具备执行DPI 37的能力，所以图6B的配置 具备另一个优势，即重新使用内置于L3节点36的DPI 37的功能。但是 图6C和图6D所示的配置可部署于新的架构方案，其中向后兼容性和之 前存在的设备问题已不复存在。

L3网络30顶层的相关功能(CG 31、LI 32和PS 33)提供计费、合 法监听和策略服务器功能，以使接入网服务更加完整。关于与上述功能之间 的交互，存在其它几种创新功能，具体可参见下文的讨论。为确保清晰，与 本发明的说明及理解无密切关联的功能将予以省略。

图7说明了根据本发明实施例应用于MBB网络的统一内容交付解 决方案。本发明应用于MBB网络的实施例尤其具有许多优势，即使图4， 其说明了一种一般性方法和设备，相关描述提及的本发明实施例既适用于移 动宽带(MBB)网络，又适用于固定宽带(FBB)网络。

图7演示了映射到图4一般描述的MBB功能组件。参照图7，在 本实施例中，节点B(NB)121和/或RNC 122可以是图4中的L2节点 21，而GGSN 136可以是图4中的L3节点36。如图4所示，在无线接 入网络120内部署缓存媒体服务器MX-A 124。图7中的虚线是替换的 MX-A 124’(连同替换的IWF 123’)部署位置(在NB中)，通过在RNC 122 中部署MX-A 124来缓存媒体服务器，这样针对实用目的保留了MX-A的 部署位置。图4中的CDN控制(CC)82功能可以是图7中的媒体控制 器(MC)182功能。MC 182会选择和分配最佳定位的媒体服务器MX (MX-A和MX-B)来为UE 110中的给定请求提供服务。

IWF 123与MX-A 124之间的连接为L2/L3连接，以使流向和来自 MX-A 124中的流量可以通过IWF 123正确路由到L2网络中以及从L2 网络中路由出来。实际上，可以将所有MX-A 124的IP地址规定为适用 于RNC 122和IWF 123(如在无线应用协议网关WAP GW中的情况下) 的相同地址，但是MX-A 124具有指向网络的CDN/互联网一侧的单独且 唯一的可路由IP地址。如下文更深入的描述，在其他实施例中，也可以按 照后文描述，采用其他通过IP地址池为MX-A分配IP地址的方法。

TMX-A 124和CDN 180之间的虚线表示大多数MBB部署中可能 可用的所有IP传输网络。在另一个实施例中，通过RNC 122/IWF 123- SGSN 135-GGSN 136-DPI 137的隧道/路径可用于与CDN 180中的组件 进行通信。这一实施例要求IWF 123在隧道协议(如适用于传输用户数据 GTP-U的GPRS隧道协议)的限制下提供所需的MX-A 124和CDN 180 之间的路由转换。因此，如果IWF 123与RNC 122相整合，将会使这种 方法更有效，从而使GTP消息和上下文的分组在从MX-A 124中路由消 息时即可落实。

在其他实施例中，GGSN 135与MC 180之间至少存在两种形式的的 通信。

在第一个实施例中，如图7所示，GGSN 136和MC 182可设计有直 接的专用接口Gmc(简单的RESTful API，例如符合表述性状态转移约束 的应用程序编程接口)以便GGSN 136向MC 182提供相关的PDP上下 文信息并请求处理。这种专用接口有两种额外的操作模式。在其他实施例中， 在GGSN 136和MC 182之间提供了直接接口，这样对熟悉该技术的技术 人员就可以使用其他类型的协议来处理请求。

首先，GGSN 136可以将活动PDP上下文的新创建、更新和删除等操 作推送到MC 182。假设每个GGSN直接与至多一个MC 182连接，则每 个GGSN 136只需将信息推送到与其相连的MC 182。

其次，MC 182可以随时使用UE 110的当前IP地址作为查询密钥， 查询GGSN 136以获取PDP上下文信息。MC 182仅查询直接与MC 182 连接的GGSN 136。除非DPI 137包含GGSN 136在先前请求中的信息， 并且MC 182针对此目的进行解析，否则，在将多个GGSN连接到单个 MC的情况下，可以将查询发送到所有多个GGSN上。

在第二个实施例中，如图7所示，可以依据UE HTTP消息参数扩充， 通过DPI 137和DPI-C 181将PDP信息从GGSN 136传递到MC 182。 在这种情况下，GGSN 136包含扩充的HTTP头中的这些PDP内容参数 (参见表1)。这个选项可能会影响GGSN 136的性能，因为HTTP消息 在GGSN 136中扩充时需要进行额外处理。

图8(包括图8A至图8D)根据本发明实施例，演示了用于配置内容 交付网络组件的各种配置。

在其他实施例中，DPI-C 181、MC 182和MX-B 184可以在单独的单 元中实施(例如另一台计算机)或整合。图8A演示了DPI-C 181、MC 182 和MX-B 184在CDN 180中作为单独单元实施的实施例，而图8D则演 示了它们整合到单个单元中的实施例。在图8B中，DPI-C 181和MX-B  184在单个单元中同时实施，而在图8C中，DPI-C 181和MC 182同时 整合。

图9演示了根据本发明实施例所部署的媒体服务器层次结构。本发明 的实施例包括一组具有层次结构的媒体服务器：位于无线接入网络120中 的第一媒体服务器MX-A 124，位于CDN 180中第二媒体服务器MX-B  184，以及位于较高层级(如分组交付网络(PDN)对等点或边界网关)中 的第三媒体服务器MX-C 194。CDN 180中的媒体控制器(图7中的MC  182)在为UE请求提供服务时会选择适当的媒体服务器MX。因此，本发 明的实施例创建了一个分层缓存网络，该网络可在CDN控制下，从MBB  RAN网络向PDN的对等点进行缓存。

媒体服务器的层次结构让CDN 180能够处理MBB网络的独有特 征。例如，热点、普通和过时内容(最常请求的是热点内容)可在缓存层次 结构的不同层级上进行缓存。.在一个或多个实施例中，可以分配MX-A、 MA-B和MC来分别保持本地、地区和整体内容的热度，从而在各个级别 上优化缓存效率和在CDN网络中平衡请求处理。

图10说明了根据本发明实施例对媒体控制器中存储的分组数据协议 (PDP)上下文数据所制定的表。

根据图10中的表，MC 182可以在表中保存一小组PDP上下文数 据，例如，让MC 182负责处理的那些用户根据UE IP地址进行索引，从 而与GGSN 136中的PDP状态同步。在第一个实施例以及上述探讨的第 一个操作模式中，GGSN 136可仅在PDP上下文中发生任何更改时促成对 MC 182的更新。MC 182可使用当前的UE IP地址来维护其PDP上下文 表。

图4-9、12、14、15、17-24的实施例还可根据包含功能步骤和/或非功 能操作的方法进行描述或说明。下列(及上述)说明和相关流程图说明了本 发明实施例实践中使用的步骤和/或行动。通常情况下，功能步骤从所取得 的成效这一角度来描述本发明，而非功能行动的描述重点则在于用来实现特 定成效或步骤的动作。尽管功能步骤和/或非功能行动可按特定顺序进行描 述或声明，但是当前发明不必限定于任何特定顺序或步骤和/或操作的组合。 此外，声明详述的“步骤”和/或“操作”使用(或非使用)方法，以及下文图11、 18B和19B的流程图描述，都用于表示这种术语所需的具体使用方法(或 非使用方法)。

图11说明了根据本发明实施例可在一般情况下进行的流操作。

当UE(如图4中的UE 10或图7中的UE 110)请求查看某个视频 门户网站的视频(如youtube、hulu、amazon视频等)时，会向视频门户 网站发送一则HTTP消息。这将要求先在UE和视频流服务器之间建立一 个DNS查询和一个相对应的TCP连接。

在其他实施例中，建立和/或激活(第201步)UE与GGSN之间的 PDP上下文。PDP上下文会存储用于请求UE所包含的PDP上下文数 据。在一个或多个实施例中，PDP上下文包括RAN侧MX IP地址，例 如7中RAN 120侧的MX-A的IP地址。PDP上下文还可能包括图10 中描述的标准参数。

然后，UE通过RNC/IWF(消息210和211)将HTTP GET请求传 送到GGSN/DPI。GGSN/DPI节点会处理收到的HTTP GET请求。DPI可 搜索HTTP请求的特定签名(例如，目的地IP地址和端口编号)，如果此 请求将要获取OTT内容，还会将它们与预存储的OTT签名列表进行对 比。对于某些OTT站点，签名分析不仅涉及五元组分析，还可能会要求 HTTP标头参数分析的实际DPI，但这会要求采用其他类型的签名。

在流程图中，假设本请求与存储于DPI的签名相匹配(DPI确定请求 是否为OTT内容)。DPI通过DPI与DPI-C功能之间的IP连接(消息 212)将本HTTP GET请求转发到DPI-C(深层内容URL DPI)。DPI将 不对本HTTP GET请求消息的任何部分作出更改。在一些实施例中，本次 转发可通过通用路由封装(GRE)隧道或网络缓存通信协议(WCCP)进行 实施。

下一步，将由DPI-C决定内容是否为可缓存内容。DPI-C功能会从 DPI接收经转发的HTTP GET请求。DPI-C进行深层URL和HTTP标 头分析，尝试将DPI-C函数上所存储的签名与所转发的消息进行匹配。必 需的DPI-C签名和算法可以根据待处理的特定视频门户网站(适用于 Youtube、BBC、Hulu等视频)和/或软件下载网站(适用于windows更新 等大文件)的不同而变化。在一个或多个实施例中，DPI-C集中于HTTP的 消息类型和用户代理方面，而其他参数可以包含在各个实施例中。

在图11的演示中，假设对于此串流，初始视频门户媒体请求(以及大 多数其他视频网站)与上文描述的签名部匹配(例如，DPI-C确定内容不 可缓存)。例如，此请求可以发送到将要初始化的媒体播放器所在的HTML 页面上，媒体播放器会初始化单独的请求，从而“获取”视频文件。DPI-C将 此请求转发至MBB分组数据网络(PDN)中的BG(或路径上的路由器) 而不计费，HTTP请求继续传送至Youtube服务器(消息213)。

在其它多条HTTP消息交换之后，DPI从UE接收另一条HTTP Get 请求，确定请求是OTT内容，并将其转发给DPI-C(消息220、222和 224)。这一次，GET请求来自媒体播放器(如shockwave播放器)。GET请 求可包含与DPI-C上所存储的签名相匹配的签名。因此DPI-C会决定内 容是否为可缓存内容。

下一步，DPI-C会通知MC，告知其对内容是否可缓存所进行的评估。 在多个实施例中，如图8所示，DPI-C可在MX-B、MC或独立的DPI-C 框上运行，具体取决于运营商的流量规划方案。为方便进行本讨论，我们假 设DPI-C、MX-B和MC在IP层级上互连且可路由，而不在本文详述 DPI-C、MX-B和MC之间内部连接和转发。如果DPI-C在MX-B上运 行，对于那些需要由CDN提供服务的请求，请求消息将从MX-B/DPI-C 转发到MC，这是因为MC会选择适用于服务任何给定请求的媒体服务器 (MX)。

在DPI-C确定请求为可缓存内容并且MC收到来自DPI-C的 HTTP请求之后，CDN就必须要参与服务本请求。在一个或多个实施例中， 位于CDN中的MC会执行以下一系列MBB网络指定任务，从而为服务 本HTTP请求而选择适合的缓存媒体服务器(MX)。

如上所述，MC会存储一小组通过Gmc(一个指向GGSN的RESTful 控制信息API，请参见图7)获取的PDP信息。在各实施例中，MC可以 使用不同的替换方法来确定哪一个MX-A位于服务当前UE的PDP路 径中。

在一个实施例中，可以使用位置信息(如路由器区域标识或服务区域 标识(RAI/SAI))来选择媒体服务器。例如，RNC是根据RAI/SAI，使用 映射到RNC和RAI/SAI之间的表选择得到的。媒体服务器的位置取决于 RNC。MC可以存储一个包含所有RNC-RAI/SAI映射的MC表。

在另一个实施例中，如果存在这种决定性的关系，可使用UE IP范围 和指向RNC的映射。在另一个实施例中，RAN侧MX-A IP地址是一种 可选的参数，可以在GGSN中添加到PDP上下文，在初始PDP设置或 参数的任何随后更改期间转发给MC。在另一个替换实施例中，通过GGSN 与SGSN之间的通信，可以获得RNC IP地址或ID，MC会保持RNC  IP/ID与其本地MX-A IP之间的映射表。

如图9所示，MC从分层结构媒体服务器组合中选择媒体服务器。下 文将进一步描述此选择所用的方法。MX作为CDN MX云的一部分，会与 MC(在MC云中)保持状态和心搏，因此，在MC中可立即知晓MX的 加载条件和可用性。

在一个实施例中，MC可以随着UE在RNC中重定位/漫游，决定将 当前请求重定向到众多MX-A(RAN侧的MX-A)之一。在一个替换实施 例中，MC在GGSN级别上，从多个MX-B中选择其一，或者在一个分 组数据网络(PDN)对等点或BG级别(如图7和9所示)选择其中一个 MX-C。

在其他实施例中，可以以多种方式来完成用于确定最佳服务MX的策 略和/或启发。

在一个实施例中，MC可以具有这样的一种策略：除非MX-A过载， 否则给定UE(即，UE的PDP路径上的IWF/MX-A)将不断恢复当前服 务MX-A。随着UE经过RNC的RAI/SAI，服务MX-A可以根据重定 位的方案而改变。下文漫游/重定位中将对此进行更深入的探讨。根据本策 略，MC总是会选择当前的服务MX-A。下文策略处理中将对此进行更深 入的探讨。

在一个替换实施例中，运营商可以拥有多个CDN请求服务策略，根 据传统的CDN实施可以作为B2B和B2C服务的一部分。同样地，它们 可以通过相同的方法引入特定于OTT的请求路由策略。这些方法的实施形 式包括通过CDN的网络操作中心(NOC)，或通过下载至MX或下载至两 者的配置表，分配给MC的一组策略。如果在服务MX-A过程中存在缓 存缺失的情况，可以配置本地配置表以提高缓存分层结构，从而尝试获取请 求内容或尝试咨询MC的意见，看是否应将该内容当做是配置表中的一个 条目。

在其他实施例中，选择用于服务UE的MX，HTTP GET请求将重定 向到此UE的服务MX-A上(消息226、228、230、240和242)。在一 个或多个实施例中，MX-A重定向的执行方式如下所述。

MC或DPI-C会建立重定向消息并将其发送给UE。MC或DPI-C 会创建一个HTTP 302(或HTTP 303重定向)消息，其中的目的地IP为 UE、源IP为视频门户网站服务器IP地址(例如，正在处理的当前HTTP  GET的目的地)。URL会根据原始服务URL而扩充，这对MX-A来说， 在缓存缺失情况下检索内容会非常有用。由于MC/DPI-C和GGSN/DPI现 已存在TCP连接，因此MC能够简单地将这个假HTTP 302消息转发给 GGSN/DPI(即消息226)，这样，便能够通过UE与媒体门户网站服务器 之间现有的TCP连接，将请求自然路由到目的UE(消息228和230)。 这种情况是假设通过在DPI函数进行分析，使TCP序列号与媒体门户端 相匹配。

如果上述的重定向不可能实现或者难以实现，那么在替换实施例中， UE与媒体门户服务器之间的TCP连接已损坏(强制断开连接)，并且在 DPI-C上采用两个单独的TCP连接建立了TCP代理。通过GGSN/DPI 在UE与DPI-C之间建立第一个连接，通过BG在DPI-C与媒体门户网 站服务器之间建立第二个连接。

使用上述方法，UE将从DPI-C/MC中收到一个HTTP 302(或303) 重定向消息。UE将尝试联系新的URI/IP地址，该地址指向连接到RNC 和IWF的服务MX(MX-A)。UE会向RNC/IWF传输一个HTTP GET (消息240)。

RNC/IWF收到UE HTTP GET，然后将其转发给媒体服务器MX-A。 在其他实施例中，可使用以下实施例其中之一来执行此操作。

在一个或多个实施例中，如果IWF嵌入在RNC中，那么IWF功能 将尝试打开GTP-U消息的用户数据以查找UE通信的目的地IP地址。 如果目的地IP地址映射到预存储在RNC/IWF上的IP地址中，可假设消 息将会被传送到已连接到RNC/IWF的服务MX-A。此预存储的IP表需 要分配到所有RNC/IWF中，因为MX-A已部署在RAN网络中，且 RNC/IWF必须将GTP-U消息重新封装为HTTP/TCP/IP消息才可以转发 给MX-A。

或者，在另一个实施例中，IWF可以是位于IuPS接口路径上RNC以 外的一个单独的框。IWF会透明地通过RNC与SGSN之间的所有 RANAP或GTP-C消息。相反，IWF会拦截GTP-U消息并打开用户数据 以筛选目的地IP地址如果与预存储的IP表中的IP地址相匹配，那么 IWF功能会重新封包消息并将其转发到与其相连的MX-A上。

MX-A收到HTTP GET，这便是UE的HTTP请求(根据MC的重 定向)(消息242)。由于MX-A已经收到UE的HTTP请求(根据MC重 定向)，MX-A会在其他实施例中执行以下HTTP请求处理。

MX-A会生成一个代表服务内容的索引。MX-A会为URL解析 HTTP请求和其他相关信息，以获得内容的索引关键字。视频门户网站的 URL结构没有既定的标准，其变更相对频繁。在其他实施例中，可以采用 任何常见的标识方法，只要这种方法能够针对每个给定的内容文件生成独一 无二的ID即可。例如，各个URL都可以不同，但是内容标识部分需保持 相同。因此，在各实施例中，可以提取内容标识部分并将其用作缓存内容文 件的索引关键字(可能需要使用散列法来处理)。可能需要对合适的HTTP 交付做进一步的调整，因为MX-A需要查看大量的小型视频片段文件。

在MX-A上会生成一个独特的文件名。MX-A会从HTTP GET请求 的URL中获得一个独特的内容/文件ID。这一独特的URL部分将用于创 建独特的散列关键字，这个关键字可以用于在MX-A缓存系统中定位内容 /文件。这可能不是100％可靠，并可能随时更改，因为媒体的内容为OTT。 因此，内容/文件都相同的两个请求可以映射到不同的文件ID，这样就可以 创建相同内容/文件的多个副本。在某些情况下，内容/文件相同的两个请求 可以映射到相同内容中。

如果MX-A在MX-A缓存中找到数据，便可以在缓存中检索该数据 并将其传输至UE(消息244和246)。如果有匹配的缓存，那么MX-A将 尝试按照UE请求为UE文件提供服务。在各实施例中，可以应用CDN 媒体适配(转码、转换分级、文件格式适配等)、PCRF QoS导向处理(基 于用户组或分级组的QoS保证和带宽限制/设限)。在下文有关策略处理的 讨论中将进行深入的探讨。在根据需要而应用媒体适配后，MX-A会将第 一个HTTP响应连同媒体数据一起发送到UE。这可以凭借RNC/IWF节 点的GTP-U的路由功能，通过UE与GSN之间的现有GTP-U隧道， 使用RNC/IWF上正确的GTP-U序列号来实现。如果IWF功能是IuPS 接口上独立于RNC的节点，且结合的RNC/IWF功能不要求复制此GTP 处理功能就能够将MX-A发送给UE的消息路由至UE现有的GTP隧 道时，IWF功能便需要自行保存序列号。

在各实施例中，与UE的会话终止之后，会计算日志并将其发送到 CDN以执行各种操作，如计帐、收费和分析等。从MX-A交付到UE的 媒体将会继续，直到会话结束；在此情况下，MX-A会生成交付日志。这 些交付日志会发送到CDN网络的媒体数据(MD)云，按下述计费、报告 和分析方法进行处理。

但是，如果MX-A缓存中没有请求数据(例如发生缓存缺失)，MX-A 会遵循其已存储的策略规则(现有CDN/MX功能)，尝试在缓存分层结构 的下一个缓存服务器或原始服务器(媒体门户网站服务器，303/302重定向 消息中列出了其URL)中查找内容。GGSN/DPI会接收来自MX-A的消 息250。DPI和DPI-C会识别出，来自MX-A的本HTTP请求(消息 250)路由不是UE请求，然后将此请求转发给媒体门户网站服务器(消息 252)。这样可以避免再次为MC造成无限循环的可能性。媒体门户网站服 务器会将在GGSN/DPI上作为HTTP响应(消息254)而接收到的请求数 据发送出去。GGSN/DPI会通过GTP隧道将数据转发给MX-A(消息256 和258)。MX-A会将内容缓存在其缓存系统中并为UE提供数据(消息 260)。

但是，在某些实施例中，MX-A还会联系MC以查找内容在CDN网 络中的位置。对于这种从上层缓存服务器进行提取的操作，MX-A可能会 使用原始用户HTTP请求URL(嵌入在MC发出的重定向消息中)，需使 用通过IP传输网络而与上层缓存服务器或原始服务器建立起来的新TCP 连接，如图7所示。

本发明的实施例具有几个独特的优势。使用本发明的实施例，能够有 效地实现接入网和CDN网络的解耦，以便缓存OTT流量。本发明的实施 例能够实现根据媒体服务器(媒体缓存和适配)在L2网络上部署L3，有 优势在于能够免去平时的L2 DPI复杂性和决策，而更接近终端用户。本发 明的实施例支持在单一CDN上实现更集中化的内容层级DPI(DPI-C)和 决策，它能够同时为MBB和FBB提供服务，从而避免在接入网络中加 入DPI-C(内容层级)。本发明的实施例可能会利用分层缓存网络以增加缓 存匹配率和降低缓存缺失检索时间。本发明的实施例还会在已分发MS服 务器之间提供缓存分层结构(MS)备份，以备有任何MS服务器发生故障。 本发明的实施例采用拥有相同网络配置的、常见、统一的CDN，通过MBB 和FBB网络以支持OTT、B2B和B2C服务，大幅简化网络部署、管理 和操作。

图12和13说明了根据本发明实施例的重定位和漫游方案。

尤其是，会话过程中，UE可能会在多个网络之间漫游。本发明的实施 例描述了在漫游过程中/之后进行缓存的方法。取决于UE的行为，可采用 不同的方案。图13列出这些方案，图12则对其做出了说明。

图12说明当UE在多个网络中/之间漫游时，可实行的资源重新分 配。图13说明了当UE在多个网络中/之间漫游时，根据本发明实施例可 对资源进行的重新分配，并强调了可能的影响。在第一个方案(方案I)中， UE的重定位可能需要重定位服务基站，例如，在相邻的基站(NB1 1211和 NB2 1212)之间。第二个方案(方案II)涉及到一次重定位，它要求在RNC 中重定位，例如从RNC1 1221到RNC2 1222。第三种方案(方案III)涉 及到在不更改GGSN的情况下，在SGSN中的重定位，从SGSN1 1351到 SGSN2 1352。在第四个方案(方案IV)中，要重定位服务GGSN，例如从 GGSN1 1361到GGSN2 1362。最后，部分UE重定位可能会涉及到从 MBB向FBB网络的更改，反之亦然(图中未有显示)。

参阅图12-13，在第一个方案(方案I)中，在相同的RAN 120中， UE从第一个基站(NB1 1211)移动到另一个基站(NB2 1212)。但是，NB1  1211和NB2 1212受同一个RNC 1221控制。因此，这个重定位对IWF1  1231和MX-A1 1241来说是透明的，因为MX-A1 1241和IWF1 1231通 过常见的RNC1 1221(图12中未显示，请参见14A)实现共享。因此， 无需进行修改。

参阅图12-13，在第二个方案中，UE从第一个SGSN(SGSN1 1221)移 动到第二个SGSN(SGSN2 1222)。此方案具有多个处理选项。

图14演示了根据本发明实施例可在MBB网络中重定位和漫游的一 般网络体系结构，其中，图14A演示了图12中方案II下的漫游实施例， 图14B演示了图13中方案III下的漫游实施例。

在第一个实施例中，会话可能已中断，MC 182将请求重定向到RNC2  1222本机上的新MX-A(MX-A2 1242)。因此，在此实施例中，重定位时需 要遵照标准的3GPP流程，而且MX-A1 1241与UE 110之间的会话也可 能会中断。UE的自动重试方式(存在于大多数媒体播放器中)会重试通过 新的RNC2 1222发送HTTP GET请求，而RNC2 1222会将请求转发到 MC 182。MC 182会将该请求重定向到新的MX-A2 1242(RNC2 1222本 机上)。新MX-A2 1242会按照上文所述，从该位置继续内容交付。但是， 媒体会从头重新开始，而不是从UE中断的地方开始。

在第二个实施例中，继续使用与RNC1 1221关联的旧MX-A1 1241。 然后执行经修改的标准3GPP流程，该流程在SGSN 135上限制了重定位 流程。因此，旧MX-A1 1241会继续通过旧的顺序(即RNC1 1221/IWF1  1231→IuR→新的RNC2 1222→新的NB2 1212→UE 110)交付，直到 会话自然结束为止。但是，来自UE的任何新请求都会重定向到新的 MX-A2 1242，并通过新的RNC2/IWF2提供服务。如上文提到，SGSN 135 修改后用于实施该选项，即识别出MX-A1 1241与UE 110之间仍然持续 进行交付会话，因此，SGSN 135没有发出重定位请求。RNC1 1221和 RNC2 1221需要重新配置，让它们能够将UE请求转发回到旧RAN1 1201 网络中的旧MX-A1 1241。

与第一个实施例相似，在第三个实施例中会话同样会中断，但由于采 用了智能缓存管理，UE 110会收到一段不间断的流畅视频。与第一个实施 例相似，在会话终端后，需执行标准的3GPP流程。特殊媒体播放器会隐 瞒错误，让用户会看到流畅的播放效果，而在后台进行重定向过程。在一个 实施例中，媒体播放器包含了智能缓存管理，可提供充足的缓冲区。在多个 实施例中，媒体播放器还拥有使用修改后的Byte Range参数重试发送无响 应HTTP请求的能力，让UE的媒体播放器可以从停止的位置重新尝试开 始。

由于UE目前位于新的RNC2 1222下新的RAN2 1202中，重试消 息会被DPI 137/DPI-C 181/MC 182截获，然后MC 182会将请求重定向 到新的MX-A2 1242。其余的交付在收到UE的Byte Range请求后会继续 开始发送。

如此一来，便可让UE避免从会话开头重新开始媒体。

在第四个实施例中，MC 182被通知即将进行重定位，然后MC 182和 /或MX-A1 1241会使用智能会话在串流中段进行重定向。因此，MC 182和 /或MX-A1 1241会收到即将重定位的通知(通过SGSN 135或RNC1  1221)。MC 182和/或MX-A1 1241会发出中段重定向请求，以重定位UE  110。通信过程可以通过现有的顺序(即IWF1 1231/RNC1 1221→NB1 121 →UE 110或IWF1 1231/RNC1 1221→IuR→RNC2 1222→NB2 122→ UE 110)进行传输。UE 110媒体播放器将接受配置，以支持该中段重定向 请求。媒体播放器将接受配置，以便向新的MX-A2 1242提出请求(Byte  Range从当前播放时间编码偏移开始)，以此作为对发自MC 182和/或 MX-A1 1241的重定向指令的响应。同时，UE会接收来自媒体播放器缓冲 区的播放内容，且不会发生中断。来自新的MX-A2 1242的交付会在播放 器缓冲区耗尽前开始，从而为用户带来流畅的播放体验。

参阅图12-13，在第三个方案中，UE从第一个SGSN(SGSN1 1351)移 动到第二个SGSN(SGSN2 1352)中。此方案的处理方式与之前方案的处理 方式相似，但在标准3GPP消息流方面有一些差别。因此，在多个实施例 中，可以通过以下方式实施第三个方案：(a)中断会话并重定向到新的 MX-A 1241；(b)使用当前的(旧的)MX-A 1241，直到会话终止；(c)使用 智能会话管理流程，同时中断会话并重定向到新的MX-A 1242；或(d)使 用智能会话管理流程和串流中段重定向流程。

图15说明了根据本发明的实施例，一套经修改的在SGSN间进行 UE重定位的程序。

虽然描述内容与方案III相关，下文描述的流程也可实施在方案II的 第二个实施例中。

MX-A只与分组数据相关。因此，MBB网络缓冲重定位流程中的所有 其他信号消息都与3GPP的重定位流程相同。分组数据转发中的不同之处， 在上述的消息交换流程图中用虚线表示。在SRNS重定位流程中，源RNC1  1221和目标RNC2 1222通过LuR(各RNC之间接口)转发旧MX-A1  1241与UE 110之间的分组数据。如图15中的第六步所示，来自旧 MX-A 1241的分组数据会被传输到源RNC1 1221。在第七步中，来自源 RNC1 1221的分组数据会通过IuR被传输到目标RNC2 1222。在第八步 中，来自目标RNC2 1222的分组数据被传输到UE 110。

上述重定位方案(图15中的第六步、第七步和第八步)在不同实施 例中可以通过不同的方式实施。

在第一个实施例中，会对源RNC1 1221和目标RNC2 1222进行修 改。尤其是，源RNC1 1221会被配置为在重定位状态时，将分组数据(其 目的地是MX-A1 1241地址)转发到MX-A2 1242。新RNC2会被配置为 在重定位状态时，将分组数据(其目的地是MX-A1地址)转发到RNC1  1221。

在第二个实施例中，目标RNC2 1222可以使用服务MX-A1 1241(旧 的)的IP地址，路由穿越连接所有RNC和PS核心的VPN/IP运输网 络。在这种情况下，为了使路由生效，每个MX-A都会有一个唯一的IP地 址。

图16-19将描述用于实现合法监听的本发明实施例。

图16说明了一种供用于根据3GPP 33.107进行分组交换合法监听 (LI)的在先技术参考配置，据此并入本发明，以供参考。

在图16中，参考配置仅可从逻辑上表示合法监听涉及的实体，而不 能对独立的物理实体实施监管。这可实现高度的整合。

执法监听设备(LEMF)连接到管理功能实体ADMF和两个具有调解 功能的交付功能实体DF2和DF3。网络中有一个管理功能实体(ADMF)。 ADMF与拦截网络中需要监听的所有LEA相连。ADMF会将各个LEA 的监听活动区分开来并连接到拦截网络。

由同一个目标上不同执法机构(LEA)执行的多种激活和交付功能，对 于3G拦截控制元件(ICE)它们都是隐藏起来的。ICE可以是3G MSC 服务器、3G GMSC服务器、P-CSCF、S-CSCF、SGSN、GGSN、HLR、AAA 服务器、PDG、MME、S-GW、PDN-GW、HSS。

管理功能和交付功能分别通过标准化转换接口HI1、HI2和HI3连接 到LEMF，并会通过接口X1、X2和X3连接到电信系统(GSN，可以 是SGSN或GGSN)。ADMF通过HI1和X1接口连接，DF2通过HI2 和X2接口连接，而DF3则通过HI3和X3接口连接。

通过HI1接口从LEMF发送到ADMF的消息，和通过X1接口从 ADMF发送到GSN的消息，都包含了需要监控的目标的标识。DF2通过 X2接口从网络接收监听相关信息(IRI)，并通过HI2接口将IRI交付到 相关执法机构。交付功能DF3收到通信内容CC(例如通过X3接口收到 演说和数据)，并通过HI3接口将CC交付到LEA。

图17-19依据本发明的实施例说明了适用于MBB网络和CDN的 合法监听。

图17描述了一种合法监听实施方法的实施例。该实施例最容易实施， 所以占据优势。在本实施例中，如果某个UE成为监听目标，则不会把该 UE分配到缓存媒体服务器(如MX-A 124)。因此，包括来自和传送至UE 的OTT流量在内的所有通信都可以在GGSN 136(和/或SGSN 135)上进 行监听，并根据上文描述与LEMF进行通信。

要实施本实施例，可以将附加功能添加到DPI 137中，以确定是否要 监听UE 110。DPI 137会检查UE请求并确定UE请求是否属于含有LI 标志设置(如UE为LI目标)的PDP上下文。如果UE是目标，则DPI  137不会将UE请求转发给CDN 180以监听内容深层数据包和分配至缓 存媒体服务器。相反，该UE请求转发给BG 160或路径中路由器，以便 使用GGSN 136处理本请求而不进行缓存。

为确定UE是否为已被定目标，DPI 137会使用源IP地址作为索引， 检查GGSN 136中的PDP上下文。如上所述，GGSN 136可以与LEMF 相连接，并获取有关UE是否已被定为目标的最新信息。在某些实施例中， 只有UE请求与分配的签名相匹配时，DPI 137才会检查GGSN 136中的 LI信息。这是因为DPI 137仅转发那些与分配的签名相匹配的UE请求 (请参见图11)。

DPI 137和GGSN 136可以是单个单元，也可能位于不同单元中，例 如图6所示。如下所述，LI监听检查功能的位置可以有多个分支结构。

如果GGSN 136和DPI 137整合在同一设备中，信息交换会更为方 便，原因是PDP上下文数据已经存在可用；此外，UE的IP地址与国际 移动用户识别码(IMSI)之间的映射也很容易建立，原因是该数据也可从 GGSN 136获取。此选项在图17中显示为选项A。

或者，如果DPI 137是与GGSN 136无关的独立功能，则也可能至少 出现两个实施例。

在第一个实施例中，专有API经构造可使用UE IP作为索引，从 GGSN 136获取PDP数据。其结构可以与Gmc接口相似，既可以是拉模 型也可以是推模型。如果DPI 137与DPI-C 181相整合，便可以使用现有 的Gmc接口。

在第二个实施例中，DPI 136可能只会延迟对DPI-C 181和/或MC  182的检查。DPI-C 181和/或MC 182会从GGSN 136获取强制更新的 LI信息，例如通过Gmc接口获取。在图17中，此方案附有参考标签选 项B。

但是，由于监听点所在位置就是GGSN 136所在位置，所以图17中 描述的实施例仍有一些局限。因此在通过MX-A 124建立UE会话后，对 LI标志进行的任何更新都不会影响到在会话期间监听通信的能力。但是， 将UE定为目标后，便可以监控任何新的UE会话请求。也就是说，无法 监控UE正在进行的会话，而只能监控从该点开始的新会话。但是，在大 多数LI规定中，这种限制还是可以接受的，例如在北美地区就可以接受。

图18和图19描述了本发明实施例，这些实施例主要针对能够克服 上述和其他限制的}法监听。

图18包括图18A和图18B，说明了另一个适用于合法监听方法的实 施例，其中，层2网络中的媒体服务器决定并交付与目标UE的通信，图 18A说明了实施LI的上下文图，及图18B说明了LI消息流。

参阅图18A可发现，要实施该实施例，需要额外增加两个接口X1’和 X3’。

在本实施例中，GGSN 136配置为将LEA对LI的任何更新都通知给 服务MX-A 124 MX-A IP地址会根据Gmc接口的要求在PDP上下文中 进行定期维护。因此，GGSN 136会将任何为UE而激活LI的操作(以UE  IP为标识)通知给服务MX-A 124。GGSN 136还会就LI目标UE的任 何去激活操作发出通知。因此，MX-A会存储一个列有所有LI目标UE的 列表。在多个实施例中，MX-A 124会被配置为拥有执行询问的能力，下文 将就此作出描述。尤其是，可对MX-A 124作出配置，让任何分组数据都 可以以标记为目标的UE为目的地或源，进行镜像交付。

在多个实施例中，X1’和X3’接口可以通过不同方式实施。在多个实 施例中，X1’接口可以用来传输来自GGSN的控制消息，例如在ADMF做 出控制决策后。X3’接口可以用来与GGSN传输媒体数据，例如监听期间 的数据。

在一个实施例中，RNC 122和GGSN 126之间的GTP-U/GTP-C消息 可通过隧道实施，例如使用IWF 123实施。

在其他实施例中，可以使用将MX-A 124和CDN 180连接起来的IP 传输。但是，基于安全原因，使用IP传输时，必须使用VPN或IPSec。 此外，必须配置GGSN以便正确识别MX-A 124的IP连接上的分组数据 流是否有效的UE流量，然后将其转发给DF3。

下文将通过图18B，描述图18A中描述的LI框架的LI消息流。消 息1801、1803、1805、1806和1808是指符合3GPP标准(TS 3GPP 33.107) 的消息。消息1802、1804和1807根据本发明的实施例添加在此处。

首先会描述目标激活流程。ADMF将Target Activation 1801(即“目标 激活”，包括目标ID、报告类型等)发送至GGSN。GGSN为PDP上下 文中的监听目标设置标志。GGSN将结果回复到ADMF。

GGSN检查监听目标是否带有活跃的PDP上下文。如果目标有一个 活动的PDP上下文，GGSN会通知MX-A(目标ID、GGSN IP等)对该 目标进行监控(消息1802)。如果该目标没有活动的PDP上下文，GGSN会 等待，直到下一次该目标建立起活动的PDP上下文为止。

下文将描述目标去激活流程。ADMF将Target deactivation(即“目标 去激活”，包括目标ID等)发送至GGSN(消息1803)。GGSN会清除监 听目标的标志。GGSN对ADMF做出响应，确认进行去激活(消息1803)。 GGSN通知MX-A(目标ID等)清除该目标的监控标志(消息1804)。 MX-A会清楚将要去激活的UE的标志。

下文将描述目标查询流程。ADMF将Target Interrogation(即“目标查 询”，包括目标ID等等)发送至GGSN(消息1805)。GGSN将结果回复 到ADMF。

下文将描述受监听通信内容报告流程。UE从MX-A接收请求的分组 数据(消息1806)。如果将该UE被标志为需要监听，MX-A还会将分组 数据(包括目标ID、发到UE的数据包内容、GSN IP等)报告给GGSN (消息1807)。在多个实施例中，MX-A会向GGSN输出交付流镜像，该 镜像与发送到UE的数据相匹配。GGSN将就来自MX-A的监听分组数 据(例如所含目标ID、内容、GGSN IP等)做出报告。

在另一个实施例中，MX-A会直接向DF3传送询问(X3)，而不是使 用GGSN转传询问的分组数据流。要实施此流程，必须将MX-A配置为 使用以下X3消息头信息传送询问。X3消息头包含目标身份、相关编号和 可选时间戳，还可能包含方向(指出T-PDU是移动台发起(MO)还是移 动台终结的(MT))，以及目标位置(如果有)。

但是，这些参数通常位于GGSN，因此自MX-A至DF3的直接连接 可能实用性不够。

图19包括图19A和19B，说明了合法监听方法的第三种实施例，其 中，层2网络中的媒体服务器决定并交付(但通过媒体控制器)与目标UE 的通信，图19A说明了实施LI的上下文图，及图19B说明了LI消息 流。

与之前实施例不同，本实施例中，媒体控制器MC连接在MX-A和 GGSN之间。参阅图19A可发现，要实施该实施例，需要额外增加三个接 口X1”、X3’和X3”。

参阅图19A可发现，MC 182是GGSN 136而非MX-A 124的接口。 使用GGSN 136和MC 182之间的Gmc接口。因此，MX-A 124从MC  182获得通知，而不是由GGSN 136直接通知。本实施例进一步简化了接 入网与CDN网络之间的交互。这是因为Gmc接口已为MC 182提供更 新的LI通知(通过PDP上下文更新发出LI激活或去激活等通知)。因 此，不需使用X1’接口以传送LI激活或去激活等控制信息。X3’接口是 MC 182与GGSN 136之间的询问分组数据流，并体统给目标LIUE。MC  182与MX-A 124之间的X1”接口可用于传输LI激活和去激活等控制 信息。

下文将通过图19B，描述图19A中描述的LI框架的LI消息流。

如上所述，激活UE以将其当作为目标时，ADMF可与GGSN进行 通信(第1901步)。目标激活可通过Gmc接口与MC通信(第1902步)， 还可通过X1”接口与MX-A通信(第1903步)。同样地，目标去激活会 与GGSN通信(第1904步)，然后GSGSN与MC通信(第1905步) 并转发到MX-A(第1906步)。下一步，ADMF可以发出目标询问请求(第 1907步)。MX-A可以初始化与被标记为目标的UE的分组数据传输(第 1908步)。MX-A生成与UE的数据包数据通信相匹配的流镜像。MX-A会 通过X3”接口将镜像分组数据传输到MC(第1909步)。MC将镜像分 组数据转发至GGSN(第1910步)。GGSN将从MC收到的监听分组数 据转发至DF3(第1911步)。或者，MX-A与DF3之间具有直接接口， 避免通过MC和GGSN(第1912步)。

如果服务MX-A变为另一个MX-A(例如重定位在同一个SGSN 下)，那么即使在漫游期间，本实施例也有助于合法监听。这是因为MC知 道此变动，因而重定向新的服务MX-A，以继续合法监听。但是，如果UE 重定位在新GGSN下或MX-A出现故障，本实施例则可能无效。

在本实施例中，与之前实施例不同，MC和GGSN之间的接口X3’是 媒体路径而不是控制路径，且可能存在一些限制。因此，在某些实施例中， 来自MX-A的受监听分组数据可能会如之前实施例所述，直接发送至 GGSN。

在另一个替换实施例中，服务MX-A会执行一个指向MX-B的串流 中段重定向，该操作部署在GGSN层级，使所有流量都受能到监控并从 GGSN发送到DF3。在多个实施例中，UE不会检测对当前会话的任何明 显更改，但是提供服务的媒体服务器会被移动到位于网络中较高层级的媒体 服务器上。这可能依次取决于MX-A执行串流中段重定向的方式、媒体和 交付协议的类型(假设视频内容HTTP交付、MX-B上相同内容的可用性 和UE客户端对串流中段重定向的支持)，以及在视频重定向点的MX-B 上开始执行的能力。

有一点非常重要：这些询问流程属于资源密集型和安全敏感型操作。 因此，在某些实施例中，将图17-19中描述的实施例结合起来也许会比较 有利。例如，图17中的实施例可以用于正常处理，而图18和/或图19中 的实施例则可以用于极端情况下。例如，LEA可能会请求监听部分所含目 标UE被选定的所有会话。在此类极少数情况下，可以部署图18和/或图 19中描述的实施例。这样可确保优化资源消耗，而不会影响到合法监听通 信内容的能力。

图20根据本发明的实施例说明了计费、报告和分析方法的处理方法。

在多个实施例中，计费及收费可以包括后付费和预付费两种计费/收费 支持。下图对计费和其他一些后勤支援功能的环境进行了说明。

本发明的实施例包括离线计费和实时计费，下文将做进一步描述。

首先会描述与离线计费有关的一个本发明实施例。经过一定的预定时 间(如10分钟，可配置)后，CDN 180中的媒体数据(MD)186会收集 使用信息并上报到计费中心(BC)191。

根据本发明的实施例，可以使用滤波算法。对于费率套餐(即无限制 的数据套餐)用户，可以不实施控制。相反，对于其他用户，其费用取决于 所使用的数据量，实际监控可取决于用户套餐的类型。

对于某些用户，即使其流量超过了合同上规定的限额，仍可允许他们 使用流量。不过，这些被称为超额流量的流量，其计费方式有所不同。本发 明实施例实现了对具有分层流量订阅包的用户实施准实时计费。根据一个或 多个实施例，MD 186会从所有MX-A节点收集用户信息，并每隔一段预 定义的分钟间隔，将该信息报告给BC 191。因此，任何用户设备的会话， 如超过预先分配的限额或其他限额，便会通过实施计费的方式将其终止。实 时计费指向BC 191的用户活动是持续的通信。对于此类计费方式，用户流 量超额使用是被容许的。

或者，对于没有任何合同(预付费)的用户，或当运营商想避免此类 用户的流量超额时，可要求实施实时收费。

因此，下文将会描述与实时计费有关的本发明实施例。

GGSN 136通过Gmc接口通知MC 182新UE的PDP包括在线计 费网关(OCG)标识，该标识表示此特定的UE需要实时收费。将此UE请 求重定向到MX-A 124前，MC 182会检查其本地PDP信息是否带有 OCG标志。根据本发明的实施例，如果OCG标志显示需要进行实时计费， MC 182不会将该请求重定向到MX-A 124。相反MC 182会将请求转发到 BG 160或路径中路由器，这样便可以使用GGSN 136对该请求进行实时 计费。因此，在实时计费时，不会执行缓存。

下文将描述与报告和分析相关的实施例。

出于非计费目的生成报告(例如，NOC/运营量、网络优化和DPI签 名/算法微调)可在MD 186上进行。在多个实施例中，MD 186可为基于 云的联机分析处理(OLAP)，用于处理来自CDN网络的日志和运营数据。

根据本发明的实施例，由于MBB网络和CDN 180之间的交互，所 以可收集到其它数据(MBB数据)。这些其它数据可包括用户的PDP上下 文数据，例如，存储在MC 182的数据、其它PCRF数据(其中一部分已 可从Gmc接口获得)、从PCRF 133获取其它QoS策略规定和参数的直 接接口，以及AAA 231和SUR 232功能中的数据。在MD 186上可新增 并支持与AAA 231、SUR 232和PCRF 133之间的接口，以访问这些其它 数据。本发明实施例还包括AAA 231、SUR 232、PCRF 133和MD 186之 间的接口。使用此类其它数据及通过进一步处理，网络运营能更好地了解 OTT流量(或B2B、B2C流量等等)。

以下将通过下述方法和图20，描述与QoS方法相关的发明的实施例。

QoS策略是通讯网络中的一个重要环节。与固定宽带网络相比，在移 动网络下其重要性更为明显。这是因为相比FBB网络基础设施，移动基础 设施受限更多，成本更高，例如空中接口和远程回程。在要求对付费更多的 用户进行区别待遇的MBB网络中，从VIP用户获得的收入要比从低端用 户获得的收入高出100倍甚至更多。

参阅图20可发现，在第一种方法中，MC 182接收QoS/PCC参数并 用以向用户提供区别待遇。MC 182可以传递很多QoS/PCC参数，并通过 Gmc接口定期更新。例如，基于用户配置文件计费、基于服务类型计费、 基于位置计费、基于拥塞计费、基于时间范围计费、基于用户累积使用量计 费、基于终端类型计费等QoS/PCC参数MC 182可在MC 182上获取。 其他例子包括用户服务计划信息(如VIP或高级用户)、用户设备类型(如 3G功能设备)、用户常用位置(如RAI和SAI)、用户漫游状态(如漫游 用户)、用户分组类型(如企业与个人用户)，以及用户计费偏好类型(如预 付费用户)。

MC 182可以使用上述信息，并根据这些QoS/PCC参数以及MBB和 CDN网络的状况来分配或选择合适的媒体服务器(MX-A、MX-B或 MX-C)。

在一个实施例中，通过结合路由请求策略/探试和PCRF 133或GGSN  136的UE配置文件和/或QoS参数，可提高UE的客户感知体验(QoE)。 例如，对于VIP用户，MC 182上的PDP上下文数据子集可指明发出UE 请求的UE具有VIP身份，并应予以特别的请求路由处理。例如，此VIP 始终可以优先路由至提供服务的MX-A，如通过进一步(暗示/明示)的指 令，要求UE提供最高比特率(适用于有多种比特的情况下)，其中的比特 率与PS/RAN链路中保证的吞吐量相匹配。与此相似，如果UE不是VIP 用户，这些请求可能会被转发至其它媒体服务器，例如，MX-B 184或MX-C (位于对等点/BG)或在服务提供商(SP)站点以检索内容，另外其在PS网 络中的吞吐量也较低，以便为VIP用户保留资源。在其他实施例中，可以 从转码视频速率列表中选择视频速率。例如，MC 182或媒体服务器可以选 择以不同编码速率传输视频。例如，根据UE配置文件(如网络状况)，可 选择发送以较高视频编码速率编码的文件，以代替以较低编码速率编码的文 件。例如，可以为高带宽连接的用户选择高分辨率视频，而为低带宽连接的 用户选择低分辨率视频。另外，在某些实施例中，可以对视频速率进行周期 性的动态调整(如每隔几秒)。例如，如果带宽质量在传输期间有所下降， 则选择采用较低编码速率的文件作为后续的视频片断。同样地，可以为屏幕 分配率较低的设备(如智能手机)选择低分配率视频，而为屏幕分配率较高 的设备(如1080p大屏幕电视)选择较高的编码速率。

在第二个实施例中，MC 182直接从PCRF检索信息，并通过MBB和 FBB网络，使用此信息为UE提供服务。在本实施例中，MC 182通过使 用与IP承载的线径上方PCRF 133直接连接的接口(AAA/半径状接口)， 从PCRF 133获取策略规定。这让MC能够获取其他未能专用GGSN  Gmc接口获取的策略规定。例如，PCRF 133可控制MBB和FBB QoS策 略规定，因此，MC 182能够获取适用于特定用户的常用策略规定。所以， 在本实施例中，在MBB和FBB之间，CDN 180直接配合一组常见的 PCRF节点运作。

在第三个实施例中，MC 182将QoS数据子集转发至提供服务的媒体 服务器(例如，MX-A 124)，之后媒体服务器使用该信息以有区别地向UE 提供服务。

也可以将QoS策略参数和规定从MC 182转发到MX-A 124、MX-B  184、MX-C和MD 186等其他功能组件(以进行分析)和/或转发到媒体 存储云以提供B2B和B2C服务。根据转发的QoS参数和规定、功能/节 点的现状，以及根据UE类型提供给适合QoS的其他相关环境参数，这 些组件的反应可能会有所不同。

将QoS规定和参数转发到媒体服务器的目的之一，是这些媒体服务器 能够适应日益变化的即时交付要求。例如，比特率适配(已缓存的多速率文 件/片段)、MX上的按需码流转换或更改媒体文件格式或特点(如解像度、 比特率、移动屏幕尺寸、媒体档案等等)等方法可在运作中执行，向UE提 供PCRF 133等策略实体需要的最合适的QoS。

本发明实施例还包括媒体播放器和/或媒体服务器MX-A或MX-B 等等的配置，以便更高效地为客户提供各种高级功能，例如快速启动、智能 缓冲控制以确保流畅播放、HTTP率设限、串流中段重定向至另一台媒体服 务器、媒体服务器故障恢复和/或媒体服务器对CDN 180进行QoS数据收 集与交付，以改善操作和积累业务智能。

图21说明了根据本发明实施例媒体服务器故障处理方法。

如上文多个实施例所述，每个MX-A都为大量的实时用户提供服务。 因此，如果没有实施任何规避流程，那么MX-A的故障将会对许多用户造 成重大影响。

下文首先会描述故障恢复的第一个实施例。如图21所示，IWF 123被 配置为立即检测MX-A 124是否出现故障或停止为UE 110提供服务(请 参阅图21中标为2201的虚线)。

IWF 123或保持与MX-A 124一致的心跳，或每当IWF 123将消息 从UE 110转发至MX-A 124时设置一个定时器。如果MX-A 124未在心 跳定时器之后作出响应或消息响应定时器超时，IWF 124被配置为在此时将 此UE请求(或UE重试消息)转发至位于穿过DPI 137和DPI-C 181的 PS路径(图21中的线2211)上提供服务的MC 182。DPI 137和DPI-C  181被配置为将此消息转发给MC 182，但其心跳可能会与故障的MX-A  124不一致。MC 182选择可能与GGSN 136/DPI 137/DPI-C 181相连的其 他媒体服务器(例如MX-B 184)，并将UE请求重定向至新的媒体服务器 MX-B 184。这样，UE 110便能够继续获取媒体，此媒体由MX-B 184(图 21中的虚线2221)交付。

上述描述方法要求加强IWF 123和/或RNC 122，以便能够探测 MX-A 124故障并正确地将请求路由到MC 182。

下面我们将描述故障恢复方法的第二个实施例。本实施例说明了上述 实施例在RNC 122和/或IWF 123未修改情况下的简化。在本实施例中， MC 182探测MX-A 124故障，例如，MX-A 124心跳中断导致故障。MC  182按照上文所述选择一个新的媒体服务器，例如，可能会选择MX-B 184。 MC 182构建一条以每一台当前受影响的UE为目的地的HTTP消息 (HTTP 302)，同时将源地址掩饰为MX-A 124的IP地址。这可能是因为 MC 182能够根据UE的IP地址而轻松地获取活动的PDP的列表。MC  182将这些消息传输至各个UE。当IWF 123/RNC 122收到MC 182的每 一条这些消息，IWF 123/RNC 122只会将它们转发至指定的UE，因为消息 是通过正确的GTP-U隧道和正确的隧道端点标识符(TEID)而进行传输 的。收到此消息的UE会联系新的媒体服务器(例如MX-B 184)以进行 交付。

上述的第一个及第二个实施例可能存在一些局限。例如，用户的媒体 会话可能突然终止，并在新媒体服务器MX-B 184开始串流时，从媒体剪 辑开始处开始新会话。在使用HTTP适应串流的实施例中，媒体播放器可 能会从上一次会话的故障点请求新反馈，让用户无须从头观看媒体剪辑。但 是，在使用常规HTTP渐进式下载的本发明第一个及第二个实施例中难以 避免这一问题。

下文描述的第三个实施例至少能够克服第一个及第二个实施例的上述 故障恢复局限。下文所述第三个实施例是对第一个及第二个实施例的增强。

根据本实施例，媒体服务器可得到增强，以处理从第一媒体服务器 (MX-A 124)向另一个媒体服务器(MX-B 184)的会话传输。如果UE 110 上的媒体播放器探测到在播放会话中间阶段被重定向到另一个媒体服务器 (也就是发生了服务中断)，媒体播放器会加入关于该会话的其它信息。例 如，媒体播放器可通过始于当前时间代码(TC)或字节范围的BYTE  RANGE请求，而修改指向新媒体播放器(如MX-B 184)的HTTP Get请 求。对于HTTP适应串流，只需获取当前片段(几秒的内容)就已足够， 而剩下部分将继续取自MX-B 184。

本发明的实施例还包括用于在备份媒体服务器(MX-B 184)出现故障 的情况下，最大程度地降低用户体验恶化的方法。例如，根据本发明的一个 实施例，如果备份媒体服务器MX-B 184也出现故障，便可以实施上述第 一个、第二个和/或第三个实施例。例如，IWF 123或MC 182可探测到 MX-B 184的故障并将UE请求重分配至新的媒体服务器，例如在运营商 的PDN的对等点上与BG 160或核心路由器相连的MX-C。或者，MC 182 可重定向至CDN 180中的其它MX-B。

上述网络功能和组件中，有一部分需要重新配置和分配，具体请见下 文说明。下文讨论可能不包括为实施本发明实施例而需要的所有配置更改

在一个或多个实施例中，可能需要配置交互功能和无线电网络控制器， 以根据不同条件(例如IP范围)，识别IWF将要连接(例如，可能基于) 的本地MX-A。可能需要配置IWF/RNC，以便按照上文所述使用定时器等 等方法等，识别本地媒体服务器的故障。可能需要配置IWF/RNC，以识别 媒体控制器的IP地址，从而能在本地媒体服务器出现故障是转发UE请 求。IWF/RNC可能需要为其正在服务的UE配置一个IP地址映射和隧道 端点标示符(TEID)。可能需要配置IWF/RNC，以便将来自IuR的新 RNC数据包转发至IWF/MX-A，以实现持续的串流漫游/重定位或媒体故 障。

在一个或多个实施例中，可能需要配置GGSN，以识别媒体控制器的 IP地址。可能需要配置GGSN，以识别GGSN范围内的MX-A IP地址。 可能需要配置GGSN，以便在DPI查询GGSN以获得决策制定所需的上 下文信息时，识别DPI。可能需要配置GGSN，以便将PDP上下文更新 (创建、修改及删除)发送至提供服务的MC。可能需要配置GGSN，以 便为任何给定的PDP上下文(UE)保留当前提供服务的MX-A。

在一个或多个实施例中，可能需要配置SGSN，以防止在重定位过程 中/之后发生终止，使旧的MX-A可继续向UE交付媒体流。在一些实施 例中，SGSN不会做出任何更改，除非我们使用它以通过GTP扩展名传送 RNC IP或ID，从而将该信息传送至GGSN并将其作为一个定制参数加入 到PDP上下文字段。

在一个或多个实施例中，L2接入网中的本地媒体服务器(MX-A)可能 需要根据为实现L1相关功能而需要连接的GGSN IP地址进行配置。 MX-A可能需要根据CDN默认内容检索算法和CDN网络操作中心对 MX-A作出的任何动态分配更新而进行配置在服务UE请求时出现缓存 缺失的情况下，便可使用此配置文件。可能需要配置MX-A，以便将MX-A 本地日志发送至CDN的MD服务器，以进行计费、收费和分析等。为实 施合法监听，可能需要配置MX-A，以便在采用直接连接至DF3的方法 时，识别DF3。在一个或多个实施例中，可能需要配置MX-A，以便接收 PDP相关的信息，从而支持指向DF3的X3接口，如目标身份、相关编 号、可选时间戳、方向(指出出传输协议数据单元(T-PDU)是移动台发起 的还是移动台终结)，以及目标位置(如果有)。

在一个或多个实施例中，媒体控制器根据其服务的GGSN IP地址进行 配置(每个媒体控制器都可能向多个GGSN提供服务)。可能需要配置媒 体控制器，以识别较高层级媒体服务器(MX-B)和DPI-C功能和它们的 IP地址，从而转发消息。媒体控制器可能需要根据RNC IP/ID之间静态映 射表及其本地MX-A IP地址进行配置媒体控制器可能需要根据PCRF 的IP地址进行配置。

在一个或多个实施例中，可能需要配置媒体数据单元，以识别计费服 务器(BS)IP地址并能够与IP承载的RESTful接口上的BS进行通信。 可能需要配置媒体数据单元，以识别PCRF IP地址、AAA服务器IP地址 和SUR服务器IP地址。

在一个或多个实施例中，可能需要配置BS、PCRF、AAA和SUR， 以识别CDN组件(例如MD和MC)。在一个或多个实施例中，可能需 要配置合法监听时使用的DF3，以便在使用了将MX-A导向至DF3选项 时，识别MX-A IP地址。

上述发明实施例可能适用于MBB网络之外的其他类型的网络。

在多个实施例中，MBB网络可以是2G、2.5G、3G、4G或更高的蜂 窝无线网络。本发明的实施例可适用于其它无线网络，如WiMAX(或更 高)网络。同样地，本发明的实施例还适用于FBB网络，包括数字用户线 路(XDSL)网络、有线带宽网络、光纤到家/户(FTTX)网络、电力线通信 (PLC)网络等。无线网络(例如WiMAX和其它固定宽带网络或受限移动网 络等)可能都要面对OTT流量造成的压力，通过上述本发明实施例可降低 这种压力。

图22说明了实施上述本发明实施例的XDSL网络。如图22所示， 多个UE 2310(如UE-1、UE-2和UE-3)通过接入网2320接收服务，该 接入网与核心网络2350通过城域网2330耦合。接入网络2320包含数字 用户线接入复用器(DSLAM)2321，这是一个L2交换机，使用多工技术将 多个数字用户线路(DSL)(UE 2310)连接至高速互联网主干线。DSLAM  2321的流量将切换到宽带远程接入服务器(BRAS)2322，终端用户流量将 从此位置路跨越ISP网络而路由至互联网2370。BRAS 2322通过服务路 由器2336(其中可能含有DPI 2337)耦合。或者，DPI 2337可以是城域 网2330中的独立单元。DPI 2337与核心网络2350中的核心路由器2361 及CDN 2480中的DPI-C 2381耦合。

根据本发明实施例，具有DPI-C 2381的CDN 2380会决定UE请求 是否涉及可缓存内容，然后CDN 2380中的MC 2382会分配媒体服务器 向UE 2310提供服务。MC 2382会在接入网2320中分配一个本地媒体服 务器(如MX-A 2424)。在一个实施例中，如多个实施例所述，MX-A 2324 通过IWF 2323耦合，让MX-A 2324成为提供服务的媒体服务器，并如多 个实施例中所述，执行缓存功能。如上述多个实施例所述，DPI-C 2481可 与DPI 2337、MX-B 2384和/或MC 2382整合。

图23说明了实施上述发明实施例的有线宽带网络。如图23所示， 多个UE 2410(如UE-1、UE-2和UE-3)通过头端2420接收服务，该头 端与核心网络2450通过城域网2430耦合。头端2420包含正交调幅单元 (QAM)2421，该单元使用多工技术将UE 2410连接至高速互联网主干线。 QAM 2421的流量通过L3节点2422进行切换，然后在此节点，将终端 用户流量跨越ISP网络路由至互联网2470。L3节点2422通过服务路由 器2436(其中可能包含DPI 2437)耦合。或者，DPI 2437可为城域网2430 中的独立单元。DPI 2437与核心网络2450中的核心路由器2461及CDN  2480中的DPI-C 2481耦合。

根据本发明的实施例，具有DPI-C 2481的CDN 2480会决定UE是 否涉及可缓存内容。然后，CDN 2480中的MC 2482会分配一个媒体服务 器向UE 2410提供服务。MC 2482可能会在头端2420中分配一个本地媒 体服务器(如MX-A 2424)。在有线宽带网络(如CATV网络上使用的) 中，缆线头端可以是一个适合设置MX-A 2424的好位置。在一个实施例中， 如多个实施例所述，MX-A 2424通过IWF 2423耦合，让MX-A 2424成 为提供服务的媒体服务器，并如多个实施例所述，运行缓存功能。如上述多 个实施例所述，DPI-C 2481可与DPI 2437、MX-B 2484和/或MC 2482整 合。

如上所述，本发明的实施例包括PLC网络。在PLC网络中，本地媒 体服务器(MX-A)可部署在PLC网络的低电压或中等电压头端单元中。

图24说明了符合本发明实施例的代表性媒体设备。

媒体设备2400包括接收器2410，其中可能含有用于接收媒体内容的 无线天线接收器和/或有线网络连接端口，例如，在媒体内容存储在远程位 置的情况下。媒体设备2400还包含内存2430，其可包括非易失性内存和 易失性内存。在一个实施例中，图4-15及图17-23所述操作的执行指令 可存储于非临时性存储介质，例如，存储器2430中的磁存储介质或固态存 储介质。

媒体设备2400可能包括更多用于输入及输出数据的I/O设备2450。 例如，I/O设备2450可能包括激光可读介质之类的碟片，例如，光盘播放 器、蓝光碟播放器和/或数字视频播放器等。在一个或多个实施例中，图4-15 及图17-23所述操作的执行指令可存储于碟片(非临时性存储介质)。

媒体设备2400还可能包括显示器2460和用于传送压缩数据的发射 器2440。发射器2440可能包括多个无线天线和/或有线端口。在某些实施 例中，发射器2440和接收器2410可整合在一起。

媒体设备2400包括一个经配置以执行图4-15及图17-23所述操作 指令的处理器2420。处理器2420可能包含单个处理器或多个处理器。

在多个实施例中，媒体设备2400可以是L2节点(例如，无线电网 络控制器和/或eNB、IWF)，可以是网关服务器等L3节点(例如，GGSN、 SGSN)，可以使媒体服务器(包括MX-A、媒体控制器、媒体数据函数、 DPI、DPI-C、PCRF、CG、DSLAM、BRAS、SRC、QAM)，还可以是上文 多个实施例中描述的其他单元(相关例子，请参阅图4、7、20、22-23)。

图25说明了用于根据本发明实施例以串流媒体的媒体控制器组件。 媒体控制器可包括图24所述的一般组件。另外，根据图25，媒体控制器 (例如，图24中的处理器2420)包含接收器2510，此接收器经配置以接 收将媒体内容提供至用户设备的请求。缓存信息接收器2520经配置可接收 与媒体内容有关的缓存信息。缓存信息包括有关用户设备请求的媒体内容是 否可以缓存的信息。媒体控制器2500还包含分配器2530，此分配器经配 置，能够分配媒体服务器层次集中的第一媒体服务器，以便在将要提供的媒 体内容是可缓存内容时，向用户设备提供服务。媒体服务器层次集包含部署 在多个L2接入网的多个第一类媒体服务器。用户设备通过多个L2接入 网中的一个L2接入网与内容交付网络耦合。

在一个实施例中，媒体控制器的处理器包含能够执行接收器2510、缓 存信息接收器2520和分配器2530的一个或多个功能的多个独立芯片。在 另一个实施例中，接收器2510、缓存信息接收器2520和分配器2530的 功能可由同一处理器在不同时间执行。也就是说，处理器在媒体处理不同阶 段作可当做接收器2510、缓存信息接收器2520和分配器2530使用。

图26说明了用于根据本发明实施例以串流媒体的媒体服务器2600 组件。媒体服务器2600可包括图24所述的一般组件。另外，根据图26， 媒体服务器2600(例如，图24中的处理器2420)包含接收器2610，此 接收器经配置以接收将可缓存媒体内容提供至用户设备的请求。用户设备通 过L2接入网与内容交付网络耦合。测定装置2620经配置可用于确定可 缓存媒体内容是否存储在第一媒体服务器的缓存中。媒体服务器2600不会 确定可缓存媒体内容是否为可缓存内容。服务器2630经配置，当媒体内容 已存储在第一媒体服务器的缓存时，便会从缓存将可缓存媒体内容提供给用 户设备。

在一个实施例中，媒体服务器2600的处理器包含能够执行接收器 2610、测定装置2620和服务器2630的一个或多个功能的多个独立芯片。 在另一个实施例中，接收器2610、测定装置2620和服务器2630的功能 可由同一处理器在不同时间执行。也就是说，处理器在媒体处理不同阶段可 当做接收器2610、测定装置2620和服务器2630使用。

图27说明了用于根据本发明实施例以串流媒体的内容处理器2700 组件。内容处理单元2700可能包括图24所述的一般组件。另外，根据图 27，内容处理单元2700(例如，图24中的处理器2420)包含接收器2710， 此接收器经配置以接收将媒体内容提供至用户设备的请求。用户设备通过多 个L2接入网的一个L2接入网与内容分发网络耦合。测定装置2720经 配置可用于确定将要提供的媒体内容是否可缓存。重定向器2730经配置， 当将要提供的媒体内容可缓存时，便会将要求提供媒体内容的请求重定向至 第一媒体服务器。第一媒体服务器是媒体服务器层次集中的一台媒体服务 器。媒体服务器层次集包括部署在多个L2接入网的多个第一类媒体服务 器。

在一个实施例中，内容处理单元2700的处理器包含能够执行接收器 2710、测定装置2720和重定向器2730的一个或多个功能的多个独立芯 片。在另一个实施例中，接收器2710、测定装置2720和重定向器2730的 功能可由同一处理器在不同时间执行。也就是说，处理器在媒体处理不同阶 段可作为接收器2710、测定装置2720和重定向器2730使用。

图28说明了用于根据本发明实施例以串流媒体的交互功能单元 2800组件。交互功能单元2800可包括图24所述的一般组件。另外，根 据图28，交互功能单元2800包含接收器2810，此接收器经配置以接收将 可缓存媒体内容提供至用户设备的请求。测定装置2820经配置可用于确定 请求的目的地IP地址。转发器2830经配置，当目的地IP地址与存储列 的目的地IP地址列表中的地址相匹配时，会将收到的请求转发至L2接入 网的第一媒体服务器。重新打包工具2840经配置可将收到的请求重新打包 成一个TCP/IP消息。转发器2830经配置可将收到的请求转发至第一媒体 服务器。

在一个实施例中，交互功能单元2800的处理器包含能够执行接收器 2810、测定装置2820、转发器2840和重新打包工具2840的一个或多个 功能的多个独立芯片。在另一个实施例中，接收器2810、测定装置2820、 转发器2840和重新打包工具2840的功能可由同一处理器在不同时间执 行。也就是说，处理器在媒体处理不同阶段可当做接收器2810、测定装置 2820、转发器2840和重新打包工具2840使用。

图29说明了用于根据本发明实施例以串流媒体的第二媒体服务器 2900组件。第二媒体服务器2900包含接收器2910，此接收器经配置以接 收将可缓存媒体内容提供至用户设备的请求。当用户设备自第一个L2接 入网中的第一个L2节点移交至第二个L2接入网中的第二个L2节点， 以及在可缓存媒体内容从第一媒体服务器串流至用户设备的会话终止时，大 概会在此时收到请求。第二媒体服务器2900还包含一个测定装置2920(经 配置，可用于确定可缓存媒体内容是否存储在仪器缓存中)和一个服务器 2930(经配置，如果媒体内容存储在仪器缓存中，便将缓存中的可缓存媒体 内容提供给用户设备)。第二媒体服务器2900可能包括图24所述的一般 组件。

在一个实施例中，第二媒体服务器2900的处理器包含能够执行接收 器2910、测定装置2920和服务器2930的一个或多个功能的多个独立芯 片。在另一个实施例中，接收器2910、测定装置2920和服务器2930的 功能可由同一处理器在不同时间执行。也就是说，处理器在媒体处理不同阶 段可当做接收器2910、测定装置2920和服务器2930使用。

图30说明了用于根据本发明实施例以串流媒体的媒体控制器3000 组件。媒体控制器3000可能包括图24所述的一般组件。媒体控制器 3000包含一个接收器3010，此接收器经配置可接收来自用户设备的有关串 流可缓存媒体内容的第二个请求。当用户设备自第一个L2接入网中的第 一个L2节点移交至第二个L2接入网中的第二个L2节点，以及在可缓 存媒体内容从第一媒体服务器串流至用户设备的会话终止时，会收到第二个 请求。分配器3020经配置可分配第L2接入网中的第二媒体服务器以 便为用户设备提供服务。

在一个实施例中，媒体控制器3000的处理器包含能够执行接收器 3010和分配器3020的一个或多个功能的多个独立芯片。在另一个实施例 中，接收器3010和分配器3020的功能可由同一处理器在不同时间执行。 也就是说，处理器在媒体处理不同阶段可当做接收器3010和分配器3020 使用。

图31说明了用于根据本发明实施例以串流媒体的L3节点3100组 件。L3节点3100可包括图24所述的一般组件。L3节点3100包含一 个监视器3110，此监视器经配置可监控用户设备是否正进行移交。L3节点 3100经配置可终止用户设备与为用户设备提供服务的第一媒体服务器之间 的会话。识别器3120经配置可识别在用户设备自首个L2节点移交至第 二个L2节点时，媒体内容是否从第一媒体服务器串流至用户设备。L3节 点3100经配置可向第一个L2节点和第二个L2节点提供服务。L3节点 3100经配置，当用户设备从第一个L2节点移交至第二个L2节点时，不 终止来自第一媒体服务器的媒体内容串流。

在一个实施例中，L2节点3100的处理器包含能够执行监视器3110 和识别器3120的一个或多个功能的多个独立芯片。在另一个实施例中，监 视器3110和识别器3120的功能可由同一处理器在不同时间执行。也就是 说，处理器在媒体处理不同阶段可当做监视器3110和识别器3120使用。

图32说明了用于根据本发明实施例以串流媒体的媒体服务器3200 组件。媒体服务器3200可能包括图24所述的一般组件。媒体服务器 3200包含服务器3210，此服务器经配置可向位于第一接入网服务区的用户 设备提供服务。服务器3210经配置，在用户设备从第一接入网移交至第二 接入网后，可向位于第二接入网服务区的用户设备提供服务。上述服务包含 通过第一接入网中第一L2节点、第二接入网中第一L2节点和第L2 节点之间的接口，以及用户设备的第L2节点与用户设备进行通信。

在一个实施例中，媒体控制器3200的处理器包含能够执行服务器 3210的一个或多个功能的多个独立芯片。在另一个实施例中，服务器3210 的功能可由同一处理器在不同时间执行。也就是说，处理器在媒体处理不同 阶段可当做服务器3210使用。

图33根据本发明实施例说明了深层数据包检测节点3300的组件。 深层数据包检测节点3300可包括图24所述的一般组件。深层数据包检测 节点3300包含接收器3310(经配置，可接收向用户设备提供媒体内容服 务的请求)和测定装置3320(经配置，可用于确定用户设备是否为合法监 听的目标)。测定装置3320经配置，当用户设备是合法监听的目标时，可 用于确定将要提供的媒体内容是否可缓存。转发器3330经配置，当用户设 备是合法监听的目标时，可转发不缓存便提供媒体内容的请求。

在一个实施例中，深层数据包检测节点3300的处理器包含能够执行 接收器3310、测定装置3320和转发器3330的一个或多个功能的多个独 立芯片。在另一个实施例中，接收器3310、测定装置3320和转发器3330 的功能可由同一处理器在不同时间执行。也就是说，处理器在媒体处理不同 阶段可当做接收器3310、测定装置3320和转发器3330使用。

图34根据本发明实施例说明了媒体服务器3400的组件。媒体服务 器3400可包括图24所述的一般组件。媒体服务器3400包含接收器 3410，此接收器经配置可接收有关用户设备的合法监听(LI)信息。接收器 3410经进一步配置，可接收向用户设备提供可缓存媒体内容的请求。用户 设备通过L2接入网耦合。测定装置3420经配置可用于根据收到的LI信 息，确定用户设备是否为合法监听的目标。服务器3430经配置可向用户设 备提供可缓存媒体内容。生成器3440经配置可生成交付流镜像，当用户设 备是合法监听的目标时，将与用户设备进行的所有通信传输到执法监控设 施。

在一个实施例中，媒体服务器3400的处理器包含能够执行接收器 3410、测定装置3420、服务器3430和生成器3440的一个或多个功能的 多个独立芯片。在另一个实施例中，接收器3410、测定装置3420、服务器 3430和生成器3440的功能可由同一处理器在不同时间执行。也就是说， 处理器在媒体处理不同阶段可当做接收器3410、测定装置3420、服务器 3430和生成器3440使用。

图35根据本发明实施例说明了媒体服务器3500的组件；媒体服务 器3500可包括图24所述的一般组件。媒体服务器3500包含接收器 3510，此接收器经配置可接收有关L3节点的用户设备的合法监听(LI)信 息。接收器3510经进一步配置，可接收向用户设备提供可缓存媒体内容的 请求。分配器3520经配置可分配第一媒体服务器以便为用户设备提供媒体 内容。发射器3530经配置可将LI信息传输至第一媒体服务器。接收器 3510经进一步配置，当用户设备为合法监听的目标时，可接收与用户设备 之间的所有通信的交付流镜像。发射器3530经进一步配置可将交付流镜像 传输至L3节点。

在一个实施例中，媒体服务器3500的处理器包含能够执行接收器 3510、分配器3520和发射器3530的一个或多个功能的多个独立芯片。在 另一个实施例中，接收器3510、分配器3520和发射器3530的功能可由 同一处理器在不同时间执行。也就是说，处理器在媒体处理不同阶段可当做 接收器3510、分配器3520和发射器3530使用。

图36根据本发明实施例说明了媒体控制器3600的组件。媒体控制 器3600可包括图24所述的一般组件。媒体控制器3600包含接收器 3610，此接收器经配置可从接入网中的L3节点接收用户配置文件。用户 配置文件包括与用户账号有关的信息和/或用户设备的网络特性。接收器 3610经配置可接收向用户设备提供媒体内容的请求。分配器3620经配置 可根据用户配置文件中的用户设备信息，分配第一媒体服务器。分配器3620 经配置，当将要提供的媒体内容可缓存时，可分配媒体服务器层次集中的第 一媒体服务器以便向用户设备提供服务。媒体服务器层次集包括部署在多个 L2接入网的多个第一类媒体服务器。用户设备通过多个L2接入网中的一 个L2接入网与内容交付网络耦合。

在一个实施例中，媒体控制器3600的处理器包含能够执行接收器 3610和分配器3620的一个或多个功能的多个独立芯片。在另一个实施例 中，接收器3610和分配器3620的功能可由同一处理器在不同时间执行。 也就是说，处理器在媒体处理不同阶段可当做接收器3610和分配器3620 使用。

图37根据本发明实施例说明了媒体服务器3700的组件。媒体控制 器3700可包括图24所述的一般组件。媒体控制器3700包含接收器 3710，此接收器经配置可从内容交付网络的媒体控制器接收用户配置文件。 用户配置文件包括与用户账号有关的信息和/或用户设备的网络特性。接收 器3710经进一步配置可接收向用户设备提供可缓存媒体内容的请求。用户 设备通过L2接入网与内容交付网络耦合。测定装置3720经配置根据用 户配置文件中的用户设备信息，确定用户设备的体验质量。服务器3730经 配置可根据用户设备的体验质量，将可缓存媒体内容提供给用户设备。

在一个实施例中，媒体控制器3700的处理器包含能够执行接收器 3710、测定装置3720和服务器3730的一个或多个功能的多个独立芯片。 在另一个实施例中，接收器3710、测定装置3720和服务器3730的功能 可由同一处理器在不同时间执行。也就是说，处理器在媒体处理不同阶段可 当做接收器3710、测定装置3720和服务器3730使用。

图38根据本发明实施例说明了媒体数据单元3800的组件。媒体数 据单元3800可包括图24所述的一般组件。媒体数据功能3800包含接收 器3810，此接收器经配置可接收用户设备的每个第一时间间隔之后产生的 流量使用情况交付记录。用户设备是用户实时计费类别的一部分。流量使用 情况包含用户设备与L2接入网的媒体服务器通信期间的数据使用情况。 发射器3820经配置可将交付记录中的用户流量信息传送至计费及收费策 略服务器。接收器3810经进一步配置可接收来自计费及收费策略服务器的 账户状态信息。当用户设备超过用户帐户的度量值时，会收到帐户状态信息。 发射器3820经进一步配置可根据账户状态信息而传送会话终止信息。

在一个实施例中，媒体数据功能3800的处理器包含能够执行接收器 3810和发射器3820的一个或多个功能的多个独立芯片。在另一个实施例 中，接收器3810和发射器3820的功能可由同一处理器在不同时间执行。 也就是说，处理器在媒体处理不同阶段可当做接收器3810和发射器3820 使用。

图39根据本发明实施例说明了L2接入网中的媒体服务器3900的 组件。媒体服务器3900可包括图24所述的一般组件。媒体服务器3900 包含生成器3910，此生成器经配置可生成一份交付记录，其中包含与用户 设备之间持续会话的流量使用情况。生成器3910经配置可在每个第一时间 间隔之后定期生成交付记录。发射器3920经配置可每隔一段时间定期传送 交付记录。接收器3930经配置可接收会话终止信息。当用户设备超过用户 账户的度量值时，会收到终止信息。终止器3940经配置可终止与用户设备 之间的持续会话。

在一个实施例中，媒体服务器3900的处理器包含能够执行生成器 3910、发射器3920、接收器3930和终止器3940的一个或多个功能的多 个独立芯片。在另一个实施例中，接收器3910、发射器3920、接收器3930 和终止器3940的功能可由同一处理器在不同时间执行。也就是说，处理器 在媒体处理不同阶段可当做接收器3910、发射器3920、接收器3930和终 止器3940使用。

图40根据本发明实施例说明了媒体控制器4000的组件。媒体控制 器4000可包括图24所述的一般组件。媒体控制器4000包含接收器 4010，此接收器经配置可接收向用户设备提供媒体内容的请求。接收器4010 经配置可接收分组数据协议(PDP)信息的子集。PDP包含一种可表示用户 设备计费类型的标志。测定装置4020经配置可根据上述标志确定用户设备 的收费模型。测定装置4020经配置，当用户设备的计费类型是实时计费类 型时，可用于确定将要提供的媒体内容是否可缓存。转发器4030经配置， 当用户设备采用实时收费类型时，可转发提供媒体内容而不进行缓存的请 求。

在一个实施例中，媒体控制器4000的处理器包含能够执行接收器 4010、测定装置4020和转发器4030的一个或多个功能的多个独立芯片。 在另一个实施例中，接收器4010、测定装置4020和转发器4030的功能 可由同一处理器在不同时间执行。也就是说，处理器在媒体处理不同阶段可 当做接收器4010、测定装置4020和转发器4030使用。

图41根据本发明实施例说明了互通功能单元4100的组件。互通功 能单元4100可包括图24所述的一般组件。互通功能单元(IWF)4100包 含第一数据库4110(经配置，可保存一份部署在第一个L2接入网中的本 地媒体服务器的列表)和第二数据库4120(经配置，可保存一份内容交付 网络中媒体控制器的互联网协议(IP)地址)。媒体控制器经配置可分配一台 媒体服务器以便为用户设备提供服务。互通功能单元4100还包含故障监视 器4130(经配置，可测定一列本地媒体服务器中的一个本地媒体服务器是 否出现故障)、接收器4140和转发器4150。接收器4140经配置可接收来 自用户设备有关提供媒体内容服务的请求。转发器4150经配置，当IWF  4100确定本地媒体服务器出现故障时，可将用户设备的请求转发至媒体控 制器。

在一个实施例中，互通功能单元4100的处理器包含能够执行第一数 据库4110、第二数据库4120、故障监视器4130、接收器4140和转发器 4150的一个或多个功能的多个独立芯片。在另一个实施例中，第一数据库 4110、第二数据库4120、故障监视器4130、接收器4140和转发器4150的 功能可由同一处理器在不同时间执行。也就是说，处理器在媒体处理不同阶 段可当做第一数据库4110、第二数据库4120、故障监视器4130、接收器 4140和转发器4150使用。另外，第一数据库4110和第二数据库4120可 存储在图24中的内存2430中。

图42根据本发明实施例说明了媒体控制器4200的组件。媒体控制 器4200可包括图24所述的一般组件。媒体控制器4200包含分配器 4210(经配置，可分配一台第一媒体服务器以便向用户设备提供服务，响应 向用户设备提供可缓存媒体内容服务的请求)和故障监视器4220(经配置， 可监视第一媒体服务器的状态，以确定第一类媒体服务器是否出现故障)。 媒体控制器4200还包含生成器4230和发射器4240。生成器4230经配 置可生成一个重定向消息，其中包含第一媒体服务器发送至用户设备的源消 息。发射器4240经配置可传送重定向消息。如果故障监视器4220确定第 一媒体服务器出现故障，分配器4210便会分配一个第二媒体服务器以便向 用户设备提供服务。如果故障监视器4220确定第一媒体服务器出现故障， 生成器4230便会生成一个重定向消息。重定向消息将用户设备重定向到第 二媒体服务器上。如果故障监视器4220确定第一媒体服务器出现故障，发 射器4240便会传送重定向消息。

在一个实施例中，媒体服务器4200的处理器包含能够执行分配器 4210、故障监视器4220、生成器4230和发射器4240的一个或多个功能 的多个独立芯片。在另一个实施例中，分配器4210、故障监视器4220、生 成器4230和发射器4240的功能可由同一处理器在不同时间执行。也就是 说，处理器在媒体处理不同阶段可当做分配器4210、故障监视器4220、生 成器4230和发射器4240使用。

如上述具体说明，本发明的多个实施例具有许多优势。第一，使用本 发明的实施例，能够有效地解耦接入网和CDN网络，以便缓存OTT流量。 第二，本发明的实施例能够在L2网络中部署基于L3的媒体服务器(媒 体缓存和适配)，其优势在于L2网络更接近终端用户，同时能够免除平时 的L2 DPI复杂性和决策。第三，本发明的实施例支持在单一CDN上实现 更集中化的内容层级DPI(DPI-C)和决策，它能够同时为MBB和FBB 网络提供服务。因此，接入网不再需要DPI-C(内容层级深层数据包检测) 功能。第四，本发明的实施例可能会利用分层缓存网络以增加缓存匹配率和 降低缓存缺失检索时间。本发明的实施例还会在已分发的服务器之间提供缓 存媒体服务器备份的分层结构，以备有任何特定服务器发生故障。第五，本 发明的实施例采用拥有相同网络配置的、常见的、统一的CDN，通过MBB 和FBB网络支持OTT、B2B和B2C服务，大幅简化网络部署、管理和 操作。

虽然详细描述了实施例及其优势，但请理解这一点：在不背离专利申 请中定义的发明实质和范畴的情况下，可进行各种变化、变动和替换。例如， 上述的许多特性和功能可在软件、硬件、固件或它们的组合中实施。

另外，本申请的范围并不局限于规格中描述的流程、机器、制造、物 质成分、装置、方法和步骤的特定实施例。这些流程、机器、制造、物质成 分、工具、方法或步骤，不管是目前已存在还是有待日后开发，只要是能够 与本文描述的相应的实施例发挥本质上相同的功能或取得本质上相同的结 果，都可以根据本发明而予以采用，作为相关技术中的一个普通技巧。本发 明披露后，技术人员应对这一点有所理解。相应地，随附的权利要求书旨在 将这些流程、机器、制造、物质成分、工具、方法或步骤纳入权利要求的范 围中。