CN103201734A - 上下文知晓的内容传送 - Google Patents

Abstract

一种用于统一资源定位符的灵活的且上下文知晓的传送方案建立在可以用于向客户端传送不论哪一个二进制内容的通用表示上。该方案还可以被应用以改善网络运营商的网络操作、用户的感知的体验质量以及不需要编码和支持不同的编解码器和传输机制的内容提供商的成本。

Description

上下文知晓的内容传送

技术领域

本发明涉及电子通信网络，更具体地说，涉及分组交换通信网络中的内容传送。

背景技术

在当前的通信网络中，移动运营商和固定运营商面临越来越大量的“过顶传球”(OTT)内容，也即是说，在运营商的主要传送基础设施的替代物上传送的音频、视频或者其它内容或应用。因此，运营商和网络提供商逐渐沦为诸如YouTube、LLC和其它流式媒体提供商等的数据密集型内容提供商的单纯的比特管道。

例如，在2009年12月，Amazon.com有限公司宣布了用于内容传送的CloudFront网络服务，该网络服务使用来自Adobe Systems有限公司的Flash流式传送和实时消息传送协议(RTMP)，从而使得甚至没有经验的用户也可以容易地使用流式传送并且进一步增加了网络中的OTT业务。可以在http://aws.amazon.com/about-aws/whats-new/2009/12/15/announcing-cloudfront-streaming/处得到关于CloudFront服务的信息。在可以在http://www.adobe.com/devnet/rtmp/pdf/rtmp_specification_1.0.pdf处得到的实时消息传送协议块流(2009年6月)中描述了RTMP。

大多数OTT内容在某种意义上讲是冗余的，即，在很多情况下，OTT内容表示只是由不同的服务和提供商根据不同的通信协议所提供的相同的信息或者甚至相同的媒体。

在客户端设备上运行的网络浏览器通常用于通过互联网来访问服务器或主机、计算机上的信息，并且浏览器通常用作超文本传输协议(HTTP)客户端。虽然浏览器是通用应用，但是浏览器如今运行在很多不同的设备和平台上。移动电话、上网本、平板电脑、膝上型计算机和个人计算机、电视机(TV)、机顶盒(STB)以及甚至厨房电器是可以具有网络浏览器的客户端设备或用户设备(UE)的示例。

当前的浏览器通过统一资源定位符(URL)来识别信息资源，并且当前的URL标识信息的一个相应表示，在最佳的情况下，恰好是适合于运行浏览器的设备的表示。URL包含或编码对于传送相应的信息而言所需的所有事物：资源、资产(asset)、传输和可能有助于对传送进行计费的可能的传送参数。URL最初是由互联网工程任务组(IETF)的征求评议文件(RFC)1738(1994年12月)规定的，并且已经被概括和更新为由IETF RFC3986(2005年1月)规定的统一资源标识符(URI)。URI可以是定位符、名称或者这二者，并且URL是指URI的除了标识资源以外还提供了通过描述其主要的访问机制(例如，其网络“位置”)来定位资源的方式的子集。

任何信息资源可能由相应的URL标识，并且经由根据适当的协议的消息传送来访问。用户的客户端软件应用(例如，浏览器)直接从用户输入或者从超链接读取URL作为输入参数，然后客户端应用下载由URL标识的资源并且向用户显示该内容(如果它能够这样做的话)。通常，可以按如下方式来描述URL的语法：

<protocol>://<host>:<port>/<path>

其中，<protocol>指示消息传送的类型(例如，HTTP、文件传输协议(FTP)、实时流式传送协议(RTSP)等)，<host>通常是信息的互联网地址，<port>通常是由主机使用以经由<protocol>进行通信的端口的号，<path>是信息的主机操作系统位置。RTSP是由IETF RFC2326(1998年4月)规定的。

因为主机可以删除或移除信息，因此URL可能失去其有效性，因而HTTP定义了针对无效URL的错误消息的结构。错误消息可以声明资源不再可用或者资源现在通过新的URL而可用。后一种错误消息称作HTTP重定向消息，并且重定向可以是静态的或临时的。现代的客户端应用能够解释HTTP重定向消息并且使用HTTP从新的URL获得资源。越来越多的客户端支持改变传输协议的重定向消息。此外，资源标识和重定向有时用于传送调整的超文本标记语言(HTML)信息(例如，网页)，例如，具体地说，用于向移动设备传送该信息。

当前，存在用于将语义资产(semantic asset)和这些资产的实际表示分开的不同的方法。例如，持久URL(PURL)项目维护用作永久标识符的地址的数据库，而不论网络基础设施如何改变。PURL不是直接解析为网络资源，而是提供一定程度的间接性，该间接性允许资源的潜在网络地址(例如，URL和URI)在不会对依赖于它们的系统造成负面影响的情况下随着时间而改变。这种能力提供了对可能由于商业、社会或技术原因而在机器之间迁移的网络资源的参考的持续性。在http://purl.oclc.org/docs/index.html处可以得到关于PURL项目的信息。

用于将语义资产和这些资产的实际表示分开的现有方法假设每一个表示具有可能随着时间而改变的相应的URL。因此，必须针对例如媒体节目(或者资产)的每一个不同的编码(或者表示)来定义新的URL。该一对一的需求导致多个问题。

诸如文档、照片、音频文件、电影等的单个资产可以具有多种不同的可用格式(表示)，其中对于每一种格式而言具有不同的URL，但是典型的用户仅对访问资产本身而不是其很多可能的表示中的任意特定的表示感兴趣。简单地向用户呈送用户必须从其中进行选择的超链接列表导致运营商和提供商失去对有价值的良好“带宽”的控制，这是因为用户不知道或者不考虑运营商或提供商的需要。简单的列表还减少了可用性，这是因为典型的用户将不了解所列出的不同URL所表示的不同的格式以及传输机制之间的差别。此外，可以在多个位置(例如，内容传送网络(CDN)、流式传送服务等)处得到相同的资产，但是用户已知的URL可能不是在内容位置、网络带宽和用户位置方面适合的资产的表示。此外，可以通过诸如HTTP、FTP等的多个传输协议来得到相同的资产，但是用户已知的URL可能不适合于用户的设备的传输能力。

因为URL直接寻址资产的一个相应的表示，因此该表示是直接地或者通过一个或多个静态的重定向被传送到用户的，因而没有关于传送上下文的额外信息可以被考虑以改善传送。当前的技术的静态属性缺乏在传送时调整URL的参考的能力。

为了基于RTSP的传送建立，会话描述协议(SDP)和实时控制协议(RTCP)可以用于经由会话邀请协议(SIP)消息传送来协商传送参数。SDP、RTCP和SIP分别是由IETF RFC3556(2003年7月)、RFC3605(2003年10月)和RFC3261(2002年6月)规定的。SIP是用于找出端点并且在端点之间路由控制信号的机制，并且是包括REGISTER、INVITE、ACK和BYE的简单操作的集合。SDP是用于宣布媒体的协议。

例如，如Magnus Svensson等在WO2010/018421A1中针对“Extended Television Reminders”所描述的，由第三代合作伙伴计划(3GPP)规定的蜂窝通信网络中的互联网协议多媒体子系统(IMS)使用SIP和SDP作为其基本信令机制，并且媒体传输尤其基于RTSP。3GPP技术规范(TS)24.229V7.11.0(基于会话发起协议(SIP)和会话描述协议(SDP)的IP多媒体呼叫控制协议，阶段3，版本7(2008年3月))的第5部分规定了UE处的SIP使用，并且3GPP TS24.229的第6部分规定了SDP使用。

但是，基于RTSP的传送对于客户端而言不是透明的，这意味着用户必须以复杂的不熟悉的方式来与用户的设备进行交互，并且不可用于基于HTTP的传送。

诸如YouTube等的提供商已经向用户提供了不同格式的资产并且自动地选择使用哪一个流式传送格式，但是提供商当前不能改变所选择的流式传送协议。选择传送哪一个流是基于服务器和客户端上的可用信息来做出的，而不是基于与传送网络本身有关的信息做出的。因此，选择错失了网络运营商传送比特的重要方面，例如传输成本等。

现有的解决方案通常束缚于特定类型的资源，例如，电影片段。对于每一种其它资源类型，必须调整该解决方案。此外，由于大多数解决方案的专有的单客户端/单服务器架构，因此现有的解决方案不能容易地扩展为考虑更相关的信息。

发明内容

我们引入了一种用于URL的灵活的且上下文知晓的传送方案，该方案建立在可以用于向客户端传送不论哪一种二进制内容的通用表示上。该方案还可以被应用以改善网络运营商的网络操作、用户的感知的体验质量和不需要编码和支持不同的编解码器和传输机制的内容提供商的成本。

根据本发明的各个方面，提供了一种利用与要向电子通信网络的用户显示的信息相对应的语义URL的方法。该方法包括：生成信息请求消息，其中，所述信息请求消息包括语义URL和用户设备的标识符；向所述通信网络中的URL逻辑节点发送所述信息请求消息；基于所述信息请求消息，收集对于传送与所述语义URL相对应的信息而言有关的信息；以及基于所收集的信息，确定适合于所述用户设备的与所述语义URL相对应的信息的表示。

此外，根据本发明的各个方面，提供了一种用于利用与要向电子通信网络的用户显示的信息相对应的语义URL的URL逻辑节点。该节点包括：收发机，其被配置为与电子通信网络的一个或多个实体交换电子信号；电子处理器，其被可编程地配置为管理由所述电子信号携带的信息；以及存储器，其被配置为存储可取回的信息。所述处理器被配置为收集对于传送与从用户设备接收的信息请求消息中包括的所述语义URL相对应的信息而言有关的信息，并且基于所收集的信息来确定适合于所述用户设备的与所述语义URL相对应的信息的表示。

附图说明

将通过结合附图阅读说明书来理解本发明的多个特征、目的和优点，其中，类似的参考字符指示类似的部分，并且：

图1描绘了通信网络、和通信网络实体之间的信号以及通信网络实体进行的活动的流程图；

图2是用户设备的框图；以及

图3是URL逻辑节点的框图。

具体实施方式

如下面更详细描述的，发明人已经认识到URL不需要暗示URL与信息资源之间的一对一的关系，但是可以定义语义项(例如，电影、新闻项等)。用户仅需要使用这样的语义URL，即，这些语义URL中的每一个是语义URL与语义项的表示的URL之间的一对多的映射。跟踪语义URL的系统逻辑针对每一个请求，基于由系统动态地从统计资源和静态资源收集的上下文信息来决定传送哪一个表示。

本领域技术人员将理解到，语义URL和表示URL可以被认为是传统的URL，其中一对多映射作为重定向而向客户端侧暴露。这是有利的，其原因在于它实现了在客户端侧对现有技术的重新使用，并且使本发明的新技术对于用户设备(UE)而言是透明的。

下面在URL逻辑管理的用户请求的示例的上下文中描述本发明，并且可以如下面所描述的来概括该示例。

图1描绘了根据本发明的方法中的通信网络100中的实体之间的典型的信号流。将理解到，在IP网络的上下文中采用适合于IP网络的消息描绘了这些方法，但是通常可以使用其它上下文和其它类型的消息。

用户使用诸如移动电话等的UE110来访问网页，其中，该UE110运行诸如网络浏览器等的客户端应用。网页向用户提供针对诸如媒体项等的信息资产的超链接，并且超链接包含或参考语义URL，该语义URL指向URL逻辑节点(URLLN)120。将理解到，现有的网站上的超链接可被修改为包含适合的语义URL。这种修改被预计为针对静态网站是容易完成的，其中，静态网站通常在相应的数据库中存储超链接或者通过简单地更新超链接数据库或发生器来自动地生成超链接。如图1所示，点击超链接导致UE110上的客户端软件向URLLN120发送针对语义项的HTTP GET请求消息(步骤1)。HTTP GET请求包含关于与语义URL相对应的资产和进行请求的UE的信息。

响应于HTTP GET请求消息，URLLN120收集对于用户请求触发的传送过程而言有关的信息。如图1所示，收集信息包括下面描述的步骤2-12中的各种步骤，这取决于所请求的资产的类型。例如，当前认为如果请求单纯的资产传送，则与静态重定向基本相对应的步骤4、5、10、11和12是足够的。如果请求适合于特定设备的资产传送，则添加步骤2、3、8和9。如果请求具有传送路径优化的适合于特定设备的资产传送，则还添加步骤6和7，其中，步骤6和7提供关于网络的信息(例如，通信链路利用率、传送路径上的节点的处理功率等)。

在步骤2，URLLN120针对与进行请求的UE有关的信息来查询设备能力数据库DevCapDB130。如同针对UE110的标识符一样，URLLN120可以根据HTTP GET请求向数据库130提供用户代理字符串。在步骤3，设备能力数据库130向URLLN120提供关于UE110支持的视频和音频代码、比特速率和分辨率的信息。

为了找到所请求的语义项的适合的表示，URLLN130查询元数据数据库MetaDB140(步骤4)，该MetaDB140包含关于语义项的可用表示的元信息。关于表示的元信息可以包括但不限于以下各项中的一项或多项：表示的媒体语言、分辨率、编解码器、位置和URL。在步骤5，元数据数据库140向URLLN120提供其存储的关于所请求的语义项的元信息。

在图1中描绘的布置中，URLLN120还可以通过使URLLN针对网络信息(例如，去往UE的通信链路上的链路质量和可用吞吐量)查询网络监控节点NetMon150来考虑关于当前的网络状态的信息(步骤6)。响应于URLLN的查询，网络监控节点150向URLLN120提供该信息(步骤7)。关于链路质量和吞吐量的信息以及其它网络信息可以用于避免拥塞的链路，并且因此提供更好的端对端链路质量，以及用于基于关于要发送的数据的已知信息来更高效地使用链路。包括例如抖动和分组延迟的链路质量对于媒体流式传送而言是特别重要的参数。例如，当通信链路几乎拥塞(即，在接近其最大吞吐量处操作)时，在链路上提供高清(HD)电影将必然使链路完全拥塞，但是提供较低分辨率的电影(例如，适合于手持设备的小屏幕的电影)可以非常适合剩余的链路容量。

NetMon节点150是从整个网络中的不同节点获取不同的信息(例如，不同的对等点上的对等业务的量)的网络节点。在诸如根据第三代合作伙伴计划的标准的长期演进网络等的典型的无线网络中，当前认为NetMon节点150是最好实现在核心网络节点中的或者与核心网络节点相关联的监控节点，而不是实现在无线接入网络中的监控节点。

基于来自数据库130、140和节点150的信息，URLLN120确定适合于UE110并且适合于优化其它方面(例如，针对提供商和网络运营商的传送成本)的所请求的语义项的表示(步骤8)。该确定可以由被实现为URLLN120中的硬件和软件中的任意一个或者这二者的决策逻辑做出，其中，该决策逻辑结合用于确定适合的编解码器(具体地说，由UE110支持的编解码器)的决策树来评估预定的成本函数。所确定的表示可以包括所请求的资产的多于一个的表示，例如，视频流和具有适合的语言的字幕流。

适合的成本函数的示例是下式：

Cost＝A·Codec_Cost+B·Resolution_Cost

其中，Cost是要确定的值；A和B是可选择的权重；Codec_Cost是基于感知的编解码器“质量”主观指派的值、或者是基于表示的比特速率、帧速率等客观计算出的值；Resolution_Cost是所预计的主观质量的客观测量值。网络运营商可以基于诸如网络状态、UE订购等的多个因素通过选择权重来调整Cost值。具体地说，权重可以根据去往UE110的通信链路的当前状态而改变。例如，选择使得传送到UE的表示被高度压缩的权重节省了网络带宽或吞吐量，同时其降低了用户体验的质量。

Resolution_Cost参数的示例是下式：

Resolution_Cost＝0.5·|(resX_a-resX_b)/(resX_a+resX_b)|+0.5·Distance_Aspect其中，resX_a是源表示的分辨率；resX_b是将在其上呈现表示的显示器的分辨率；如果aspect_ratio_b＝aspect_ratio_a，则Distance_Aspect＝0，否则，Distance_Aspect＝1。分辨率resX_a的公共值当前是1920×1080个像素、1280×720个像素和720×480个像素，而分辨率resX_b的公共值当前是960×640个像素、640×360个像素和480×320个像素，但是将清楚的是，可以使用任何适当的值。公共宽高比值当前是16∶10、16∶9和4∶3。

在步骤9，URLLN120将所确定的表示的URL封装在HTTP重定向消息中，并且响应于UE的HTTP GET消息，包含所确定的表示的URL的重定向消息被发送到UE110(步骤10)。然后，UE的客户端向源160请求由URLLN120确定的语义项的表示(步骤11)，并且响应于其请求，UE110根据SIP OK过程从源160接收信息资产的所确定的表示(步骤12)。

本领域技术人员将理解的是，在图1中所示的示例中使用的传输协议是HTTP，但是该协议并不总是必需的。通常，支持如所描绘的重定向消息的任何传输协议是可能的，例如，RTSP。此外，由URLLN120发送的重定向消息(步骤10)可能导致协议之间的改变(例如，从HTTP改变为RTSP)，这对于诸如移动电话等的可能具有有限的功率和处理能力的UE而言可能是有利的。此外，将理解的是，网络节点110、120、130、140、150、160使用一个或多个适当编程的电子数字信号处理器或者等同物以及管理网络100中的UE和其它实体交换的信号所携带的信息的存储器来执行本申请中描述的功能。

还将理解的是，表示的URL不需要指向诸如源160等的所请求的资产的实际位置，而是可以指向完全不同的位置并且再次重定向至那里而被管理。这种布置的示例是指向CDN的表示URL，其自身将UE重定向至与UE最近的位置。

URLLN120还可以从UE自身获取关于传送上下文的信息(步骤6、7)。当前，SDP可以用于协商设备特定的传送参数，但是正在开发用于在设备自身上暴露设备能力的方法。例如，传送上下文客户端接口(DCCI)是万维网联盟(W3C)进行的项目，该项目是W3C的传送上下文本体(DCO)项目的子项目。

本领域技术人员将理解到，在本申请中描述的方法和装置可以实现在诸如移动无线网络等的很多类型的电子通信网络中。

图2是用于如本申请所描述的访问内容的诸如移动电话、STB、计算机等的典型的UE110的框图。UE110包括收发机202，该收发机202适合于与图1中描绘的网络实体中的一个或多个交换电子信号。这些信号携带的信息是由处理器204管理的，该处理器204可以包括一个或多个子处理器，并且执行包括例如网络浏览器的一个或多个软件模块和应用，以执行上文所描述的UE110的操作。通过键盘、远程控制或其它设备206来向UE110提供用户输入，并且呈送给用户的信息被提供给显示器208。如果显示器具有触摸屏能力，则可以通过该显示器来提供用户输入。可以在适当的应用存储器210中存储软件应用，并且UE还可以下载期望的信息和/或在适当的存储器212中缓存期望的信息。UE110还可以包括接口214，接口214可以用于将诸如计算机、麦克风等的其它组件连接到UE110。

用户经由键盘206或接口214请求语义项，并且使用存储器210、212中的信息来使得处理器204生成适当的HTTP GET请求消息(步骤1、10)并且经由收发机202将该消息发送给URLLN120。收发机202和处理器204还执行SIP消息传送以进行内容传送(步骤12)，并且处理器214然后可以经由显示器208向用户呈送内容。

图3是用于如本申请中所描述的收集对于由用户请求触发的传送过程而言有关的信息并且对用户请求做出响应的典型的URLLN120的框图。URLLN120包括收发机302，收发机302适合于与图1中描绘的网络实体中的一个或多个交换电子信号。这些信号携带的信息是由处理器304管理的，处理器304可以包括一个或多个子处理器，并且执行一个或多个软件模块和应用，以执行上文所描述的URLLN120的操作。具体地说，处理器304执行对于查询和接收来自数据库130、140和节点150的信息以及确定适合于UE110的所请求的语义项的表示而言所需的消息传送，并且执行对于以信号形式将所确定的表示传送给UE而言所需的消息传送。处理器304可以使用存储在适当的存储器306中的信息和可以存储在适当的应用存储器308中的软件应用来执行这些操作。将理解的是，典型的URLLN120是网络100中的服务器，因此对于用户输入/输出而言，通常不需要键盘/显示器310，但是这些接口可以被提供以用于管理功能。

本发明通过使用URL的不同协议增加了对互联网上的媒体传送的控制。根据本发明，在客户端侧上使用现有的协议和技术，因此实现对于UE而言可以是完全透明的。网络运营商可以提供更智能的传送路径，并且因此减少了网络中的链路上的业务并且通过将UE重定向至外部流式服务而节约了流式传送能力和其它能力。此外，运营商可以通过以最适合于客户端的方式传送内容来向内容提供商提供增值。从其在内容传送路径中的位置开始，运营商还可以为其自身以及为第三方提供额外的服务，例如，计费和数字版权管理(DRM)。对于用户而言有利的是他们可以将注意力集中于所请求的信息并且避免处理多个表示、格式、协议和指向相同信息的超链接。

将清楚的是，例如如果必要的话，上文所描述的过程被重复地执行，以对发射机和接收机交换的通信信号的时变属性做出响应。执行本发明的装配可以包括在例如计算机、服务器、无线通信网络基站等中。

因此，本发明可以以多种不同的形式体现，上文并未描述所有这些形式，并且所有这些形式被设想为落入本发明的范围内。

应当强调的是，当在本申请中使用时，术语“包括”和“包含”规定存在声明的特征、整数、步骤或组件，而不排除存在或添加一个或多个其它特征、整数、步骤、组件或其组合。

上文所描述的特定实施方式仅仅是说明性的而不应当以任意方式理解为是限制性的。本发明的范围是由所附权利要求来确定的，并且落入权利要求的范围内的所有变形和等价物旨在包含在其中。

Claims (14)

1.一种利用与要向电子通信网络(100)的用户显示的信息相对应的语义统一资源定位符(URL)的方法，包括：

(a)生成信息请求消息，其中，所述信息请求消息包括语义URL和用户设备(110)的标识符；

(b)向所述通信网络中的URL逻辑节点(120)发送所述信息请求消息；

(c)基于所述信息请求消息，收集对于传送与所述语义URL相对应的信息而言有关的信息；以及

(d)基于所收集的信息，确定适合于所述用户设备的与所述语义URL相对应的信息的表示。

2.根据权利要求1所述的方法，其中，收集信息包括以下步骤中的至少一个：针对与所述用户设备相对应的信息来查询设备能力数据库，针对关于与所述语义URL相对应的所述信息的可用表示的信息来查询元数据数据库，以及针对关于去往所述用户设备的通信链路上的吞吐量的信息来查询网络监控节点(150)。

3.根据权利要求1所述的方法，还包括：

向所述用户设备发送标识所确定的表示以及用于访问所确定的表示的通信协议的重定向消息。

4.根据权利要求3所述的方法，其中，所述信息请求消息的通信协议不同于在所述重定向消息中标识的所述通信协议。

5.根据权利要求1所述的方法，其中，确定所述表示包括：评估预定的成本函数。

6.根据权利要求5所述的方法，其中，所述预定的成本函数由下式给出：

Cost＝A·Codec_Cost+B·Resolution_Cost

其中，Cost是要确定的值；A和B是可选择的权重；Codec_Cost是基于所述用户设备中的编解码器的值、或者是基于所述表示的比特速率和帧速率中的至少一个所计算出的值；并且Resolution_Cost值是针对所述表示所预计的主观质量的测量值。

7.根据权利要求6所述的方法，其中，所述Resolution_Cost值由下式给出：

Resolution_Cost＝0.5·|(resX_a-resX_b)/(resX_a+resX_b)|+0.5·Distance_Aspect其中，resX_a是源表示的分辨率；resX_b是所述用户设备的显示器的分辨率；如果所述源表示的宽高比与所述用户设备的所述显示器的宽高比基本上相同，则Distance_Aspect＝0，否则，Distance_Aspect＝1。

8.一种用于利用与要向电子通信网络(100)的用户显示的信息相对应的语义统一资源定位符(URL)的统一资源定位符逻辑节点(120)，包括：

收发机(302)，其被配置为与所述电子通信网络(100)的一个或多个实体(110；130；140；150)交换电子信号；

电子处理器(304)，其被可编程地配置为管理由所述电子信号携带的信息；以及

存储器(306；308)，其被配置为存储可取回的信息；

其中，所述处理器被配置为收集对于传送与从用户设备(110)接收的信息请求消息中包括的所述语义URL相对应的信息而言有关的信息，并且基于所收集的信息来确定适合于所述用户设备的与所述语义URL相对应的信息的表示。

9.根据权利要求8所述的节点，其中，所述处理器被配置为通过以下步骤中的至少一个来收集信息：针对与所述用户设备相对应的信息来查询设备能力数据库，针对关于与所述语义URL相对应的所述信息的可用表示的信息来查询元数据数据库，以及针对关于去往所述用户设备的通信链路上的吞吐量的信息来查询网络监控节点(150)。

10.根据权利要求8所述的节点，其中，所述处理器被进一步配置为使得所述节点向所述用户设备发送重定向消息，所述重定向消息标识所确定的表示和用于访问所确定的表示的通信协议。

11.根据权利要求10所述的节点，其中，所述信息请求消息的通信协议不同于在所述重定向消息中标识的所述通信协议。

12.根据权利要求8所述的节点，其中，所述处理器被配置为通过评估预定的成本函数来确定所述表示。

13.根据权利要求12所述的节点，其中，所述预定的成本函数由下式给出：

Cost＝A·Codec_Cost+B·Resolution_Cost

其中，Cost是要确定的值；A和B是可选择的权重；Codec_Cost是基于所述用户设备中的编解码器的值、或者是基于所述表示的比特速率和帧速率中的至少一个所计算出的值；并且Resolution_Cost值是针对所述表示所预计的主观质量的测量值。

14.根据权利要求13所述的节点，其中，所述Resolution_Cost值由下式给出：

Resolution_Cost＝0.5·|(resX_a-resX_b)/(resX_a+resX_b)|+0.5·Distance_Aspect其中，resX_a是源表示的分辨率；resX_b是所述用户设备的显示器的分辨率；如果所述源表示的宽高比与所述用户设备的所述显示器的宽高比基本上相同，则Distance_Aspect＝0，否则，Distance_Aspect＝1。

Images