CN102047637A - 用于预留带宽的方法和用户设备 - Google Patents

用于预留带宽的方法和用户设备 Download PDF

Info

Publication number
CN102047637A
CN102047637A CN2009801205114A CN200980120511A CN102047637A CN 102047637 A CN102047637 A CN 102047637A CN 2009801205114 A CN2009801205114 A CN 2009801205114A CN 200980120511 A CN200980120511 A CN 200980120511A CN 102047637 A CN102047637 A CN 102047637A
Authority
CN
China
Prior art keywords
channel
bandwidth
timer
subscriber equipment
iptv
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.)
Granted
Application number
CN2009801205114A
Other languages
English (en)
Other versions
CN102047637B (zh
Inventor
扬·埃里克·林德奎斯特
埃里克·罗林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of CN102047637A publication Critical patent/CN102047637A/zh
Application granted granted Critical
Publication of CN102047637B publication Critical patent/CN102047637B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols

Abstract

在用户设备处，提供了一种有条件带宽重新协商方法，用于在用户设备参与与IPTV网络的IPTV会话并且请求频道切换时管理带宽重新协商。当确定所请求的频道比当前所选频道需要较小带宽时，发起有条件带宽重新协商过程，其中，在切换至所请求的频道时，启动定时器。如果在另一频道切换请求之前识别出未决定时器超时，则发起带宽重新协商过程，而如果在未决定时器超时之前识别出另一频道切换请求，则不执行带宽重新协商。

Description

用于预留带宽的方法和用户设备
技术领域
本发明总体涉及一种与针对参与IPTV会话的用户设备的频道切换相关联的带宽预留的方法，以及用于执行该方法的用户设备。
背景技术
随着电视(TV)从单向分发服务向为终端用户提供双向交互式服务转变，以及从仅限于分发至静止位置向实际上可分发至任何地方且可分发至可在各种类型和大小的屏幕上观看的服务转变，我们将见证TV节目安排、广告、交互式游戏和不同类型的交互式服务的全新大市场的诞生。
至于将新客户吸引至其相应网络，互联网协议电视(IPTV)提供了电信服务提供商的新的收入机会，以便弥补下降的语音业务收入。关于IPTV的工作在多个不同环境中正在进行，包括例如开放IPTV论坛目前正在进行的开发以及对具有受控服务质量(QoS)性能的管理的网络的开发，开放IPTV论坛规定用于通过互联网向具有实现IPTV功能的用户设备(UE)的终端用户提供多媒体和IPTV服务的端到端平台。功能性IPTV架构的版本1.1规范可在www.openiptvforum.org处得到，其中，所描述的架构基于由第三代伙伴计划(3GPP)规定的IP多媒体子系统(IMS)。UE可以以许多不同方式访问通过IMS而提供的服务：经由有线访问，如经由以太网、电缆调制解调器或数字订户线路；或者无线访问，如经由3GPP规定的蜂窝无线电或者通过使用IEEE 802.11或IEEE 802.16标准。
IMS是在3GPP技术规范(TS)23.228 V8.4.0，IP Multimedia Subsystem(IMS)Stage 2(Release 8)，March 2008以及TS 23.228的先前版本中规定的。此外，基于IMS的IPTV的不同方案在M.Cedervall等人的“Open IPTV Forum-Toward an Open IPTV Standard”，Ericsson Review No.3，pp.74-78(2007)和T.Cagenius等人的“Evolving the TV experience：Anytime，Anywhere，Any Device”，Ericsson Review No.3，pp.107-111(2006)中描述。
对于UE(该UE可以是机顶盒(STB)或集成了STB能力的实体，例如计算机、TV、PDA、移动电话或经由IMS访问IPTV服务的任何其他实现IPTV能力的移动设备)，UE注册至服务呼叫会话控制功能(S-CSCF)中，S-CSCF是本质上作为SIP服务器操作的IMS核心节点。典型的IMS还包括多个附加节点，包括代理CSCF(P-CSCF)、媒体网关控制功能(MGCF)和一个或多个边界网关(BG)，作为媒介而使UE访问核心节点并通过核心节点来访问驻留于一个或多个媒体服务器上的媒体内容。
在传统的基于IMS的IPTV网络中，可以执行会话修改，会话修改可以包括针对已从用户设备建立的会话的带宽预留，以便确保向终端用户提供所需服务。在该上下文中，会话可以是：单播会话，例如经由单播流而传送的视频点播会话；或者广播会话，经由多播流而传送至收听的终端用户。
带宽预留过程确保在网络基础设施的最后一英里中或在汇聚网络中有足够的网络资源，以便IPTV运营商能够以所选服务中断的最小风险来保证足够的用户体验。
如果例如两个会话合起来超过在最后一英里上可用于IP运营商的带宽量，则与这两个会话相关联的分组将竞争可用的网络资源，因此，这两个流的分组将最有可能被丢弃，从而导致至少一个会话的质量下降。一旦针对一个或多个会话预留了带宽，则重要的是不允许新会话对现有会话有负面影响。
图1是根据现有技术的信令方案，示意了如何可以经由由图中的核心网101表示的IMS网络，在UE 100与用于向UE 100提供一个或多个IPTV服务的IPTV网络102之间执行典型的IPTV服务建立。
应当理解，尽管IPTV网络102和由IMS核心网101表示的IMS网络都典型地包括多个网络节点，但是为了简明，这些网络中的每一个已由图1中的一个相应节点表示。
在两个初始步骤1:1和1:2中，UE 100注册至IMS核心网101，IMS核心网101典型地以200 OK消息进行响应。在随后的步骤1:3-1:6中，UE 100经由SIP预订来请求要从IPTV网络102提供的IPTV服务。一旦如步骤1:6所示，通过UE 100从IMS核心网101接收到200OK消息完成了该过程，则已向UE 100提供了IPTV服务数据，典型地称作IPTV服务发现数据，该数据包括频道列表，频道列表指示可由IPTV网络102的相应IPTV服务提供商提供的所有频道。典型的IPTV服务发现信令过程被示意为图1中的步骤1:7-1:10。一旦被提供有与可用频道有关的信息，UE 100可以选择以挑选所需服务。在本示例中，这被示意为在步骤1:11中经由IMS核心网101从UE 100发送至IPTV网络102的HTTP GET消息。
在随后的步骤1:12中，IPTV网络102通过向UE 100提供列表来进行响应，该列表典型地称作线性TV频道列表，除了其他IPTV频道相关信息以外，该列表还包括与从IPTV网络102可用的IPTV频道相关联的带宽需求信息。该信息作为TISPAN服务封包而被提供给UE100，该TISPAN服务封包典型地称作广播服务记录的广播供应(broadcast offering)。
广播供应典型地包括多个元素或属性，其中每一个承载与可用IPTV频道有关的不同类型的信息。对于每个频道，广播供应可以包括如下信息：例如，DVB三元组，实现UE处的IPTV频道标识；文本标识，表示相应IPTV频道名称；服务位置，作为对在哪里找到相应频道的指示；以及最大比特率，作为对相应服务所需的最大比特率的指示。
在下一步骤1:13中，将从广播供应提供的信息存储在UE 100的存储器中。在该阶段，UE 100的终端用户可以进行选择，以便典型地通过激活遥控器或经由与UE 100相关联的另一用户接口，从广播供应中可用的频道中挑选优选的IPTV频道。在步骤1:14中，终端用户进行这种选择，并且，响应于频道选择，UE 100发起带宽预留过程，以针对所选频道预留适当带宽。在图中，这被示意为邀请，典型地称作SIP邀请，该邀请转发至IMS核心网101，如另一步骤1:15中所示。
如果所需的带宽不可用，或者如果由于任何其他原因，所需的带宽不能被分配给UE 100，则向UE 100通知这种情况，如步骤1:16a所示。在这种情形下，终端用户可以选择以进行对相同频道的另一次重试，或尝试挑选另一频道。
然而，如果带宽请求被IMS网络准许，则将带宽预留给UE 100，如另一步骤1:16b所示。然后，通过向IPTV网络102通知所分配的带宽并通过IPTV网络102确认该信息来完成带宽预留过程，如步骤1:17和随后的步骤1:18所示，并且，还向UE 100执行确认，如步骤1:19和随后的步骤1:20所示。
利用被预留给UE 100的所需带宽，现在可以发起所请求的IPTV服务。在本示例中，这是通过UE 100向IPTV网络102发送IGMP Join(加入)来进行的，如步骤1.21所示。如图所示，IPTV网络102通过经由多播流向UE 100传送所选的IPTV频道来对这种服务请求进行响应，如最后的步骤1:22所示。
带宽预留的总体问题在于：如何得到与对所选广播会话进行协商实际需要多少带宽有关的适当信息。如上所述，用于建立从IPTV运营商可用的IPTV会话所必需的、典型地在广播供应中传送的广播频道信息可以包括对相应IPTV频道的最大比特率的指示。这种信息的目的是确保一旦已经分配资源并已经选择IPTV频道，则从IMS核心网101将有可用足够带宽。
然而，根据上述过程使带宽重新协商过程基于最大比特率属性的问题在于：所需的信令将导致处理延迟，该处理延迟可能削弱正在不同频道之间进行切换的用户的用户体验。在终端用户可以观看所选频道之前，必须进行可以包括带宽重新协商在内的会话修改，因此，通过这种带宽重新协商，终端用户将在实际上可以观看频道之前体验到延迟。
当终端用户在决定更持久地观看可用频道之一之前在已指定不同最大比特率的不同频道之间进行转换时，上述问题尤其恼人。重复的延迟可以令终端用户非常恼火，而同时，从运营商的观点来看，通过响应于由终端用户发起的频道切换而立即发起带宽重新协商，也可能几乎什么都得不到。
此外，用于执行带宽重新协商的目前已知的方案也无法向IPTV运营商给出对可用带宽的使用的任何控制。
发明内容
本发明的目的是提供一种用于减少参与IPTV会话的用户设备的带宽重新协商次数的方法。更具体地，本文涉及在特定情形下允许推迟对是否与参与IPTV会话的用户设备的频道切换相关联地执行带宽预留进行决定的机制。通过推迟针对从具有更高带宽要求的频道至需要切换至的频道的频道切换的这种决定，可以减少实际执行的带宽重新协商次数，同时对用户体验或网络性能没有负面影响。
根据第一方面，提供了一种与参与由IPTV网络提供的IPTV会话的用户设备处的频道切换相关联地管理带宽重新协商的方法。
当确定所请求的频道比当前所选频道需要较小带宽时，应用与所请求的频道切换相关联的有条件带宽重新协商过程。这种有条件带宽重新协商过程包括执行多个步骤，从切换至所请求的频道开始，然后启动定时器。定时器的目的是延迟对是否要执行带宽重新协商的决定。如果识别出超时，则典型地根据传统过程步骤，发起并执行带宽重新协商。
如果在定时器超时之前识别出另一频道切换请求，则不针对先前的频道切换执行带宽重新协商，因此，在发起另一评估过程以便确定是否也要响应于最新的频道切换请求而应用有条件带宽重新协商过程之前，终止未决的定时器。
根据所提出的方法，有条件带宽重新协商过程所依赖的带宽需求是通过以下操作来评估的：将与所请求的频道相关联且与所请求的频道所需的带宽相对应的比特率属性的值与用于指示当前可用于用户设备且与被分配给当前频道的带宽相对应的最大比特率的值进行比较。
在典型实施例中，在频道切换之前，已经将比特率属性从IPTV网络提供给用户设备。这可以通过在广播供应中将所述比特率属性典型地与其他比特率属性一起转发来实现。可以基于每频道或者基于每频道组来预定义提供给用户设备的比特率属性。如果基于每频道组来预定义，则这种分组可能已经基于一个或多个不同准则来进行。
此外，典型地，可能已经将用于有条件带宽重新协商过程的定时器值从IPTV网络提供给用户设备。这种定时器值可以是已被指定为针对从IPTV网络提供的所有频道都有效的值，或者可以是已针对特定频道预定义的频道专用定时器值。此外，可能已经在广播供应中将所述定时器值提供给用户设备。
根据另一方面，要求保护的本发明还涉及一种被配置为执行上述方法的用户设备。
所提出的方法提供了一种容易在用户设备中实现的用于限制带宽重新协商次数的机制。
所提出的方法还使运营商至少在有限程度上能够在即将到来的带宽重新协商期间实现如何分配可用资源。
所提出的方法和相关联用户设备的其他细节和特征及其优点将在具体实施方式中更详细地解释。
附图说明
现在将通过示例实施例并参照附图来更详细地描述本发明，在附图中：
-图1是示意了根据现有技术可以如何在用户设备与IPTV网络之间建立IPTV会话的信令图。
-图2是示意了根据一个示例实施例延迟对是否要执行带宽重新协商过程的决定的方法的流程图。
-图3是示意了根据一系列示例情形，用户设备可以如何应用参照图2描述的方法的信令图。
-图4a是示例了根据一个实施例可以作为执行参照图2描述的方法的基础的信息的表。
-图4b是示例了根据另一实施例可以作为执行参照图2描述的方法的基础的信息的另一个表。
-图5是示意了根据一个示例实施例可以如何配置能够执行参照
图2描述的方法的用户设备的简化框图。
具体实施方式
如上所讨论，需要针对可用的IPTV频道定义特定量的带宽需求，以使IMS核心网能够针对需要与IPTV网络建立IPTV会话的UE来执行带宽预留。
现今，可用于该目的的信息是在可以建立相应会话之前已在广播供应中从IPTV网络提供给UE并且给出对何种比特率必须可用于相应会话(即，针对相应IPTV频道必须保证的比特率)的指示的元数据。
从上述内容还应当显而易见的是：从终端用户的观点来看，基于每频道对带宽进行重新协商是应当在最大程度上避免的情况，这是由于仅在已向相应UE授予所选频道所需的带宽之后才能够观看频道。
因此，需要一种用于限制所执行的重新协商的次数的方法。一种方式是尝试避免执行可被视为不必要的带宽重新协商。因此，提出了一种应用有条件重新协商从而减少由完整重新协商过程引入的延迟的数目的带宽重新协商方法。
还需要的是：经由IPTV网络以IPTV频道的形式向终端用户提供IPTV服务的IPTV运营商至少在一定程度上能够对可用资源(更具体地，可用带宽)如何用于IPTV服务分发产生更多影响。
根据所提出的有条件带宽重新协商方法，针对频道组而不是针对单个频道，对带宽进行协商，使得当终端用户在不同IPTV频道之间进行跳转时，可能在某些情形下推迟对实际上是否有必要执行带宽重新协商的决定。通过推迟决定，可能确定在一些情况下带宽重新协商是不必要的，因此，可以减少由所执行的带宽重新协商过程引起的延迟量。
为了根据所提出的方法得到对带宽重新协商的更好控制，在UE处引入定时器。优选地，定时器值将从IPTV运营商提供给UE。为此，引入用于表示一个或多个定时器值的新元素或属性，以下将称作例如TimeToRenegotiation(重新协商时间)(TTR)。
在该上下文中，TTR是在频道切换之前典型地经由广播供应而提供给UE的属性。TTR能够用于响应于由UE的终端用户发起的频道切换而延迟对在UE处是否要执行带宽重新协商过程的决定，而不是无条件地执行带宽重新协商过程。
由于终端用户已将频道切换至比当前观看的频道需要较小带宽的频道这一事实而需要的带宽重新协商过程不是在时间上关键的，这是由于在不执行重新协商的情况下，也将可以通过使用已经针对UE预留的带宽来向终端用户提供所需的新频道。
因此，在这种情形下，可以在不减弱用户体验的情况下，基于由例如TTR指定的特定定时器值来延迟带宽重新协商决定，从而允许根据在定时器值到期之前是否发生任何随后附加的、所请求的频道切换，来推迟重新考虑实际上是否有必要进行重新协商过程。
更具体地，所提出的方法将被配置为使得如果在定时器超时之前选择切换至另一频道，则在针对最新的频道选择也出现对应情形的情况下，即如果最新选择的频道也比最先选择的频道需要较小带宽，则将复位并针对最近的切换再次启动定时器。
另一方面，如果最近选择的频道比当前观看的频道需要较大带宽，则即时发起并执行传统的带宽重新协商过程。
因此，通过引入这种有条件带宽重新协商过程，仅在所观看的频道的定时器超时之前未识别出后续频道切换的情况下，才执行涉及向需要较低带宽的频道切换的重新协商过程。
如上所述，要应用的定时器值可以被IPTV运营商选择为适当值，并可以选自从相对较低值(如5秒)开始直至分钟范围的值(如具有5分钟持续时间的定时器值)的范围。
如何选择定时器值可能取决于一个或多个不同准则，如用户行为、可用频道的数目和/或可用带宽。
作为将定时器属性作为对由IPTV运营商提供的所有频道有效的单一值的备选方案，定时器属性可以代之以被定义为向量，对此，已针对不同频道或频道组指定不同定时器值。如果定时器属性对于不同频道是不同的，则可以根据如相应频道有多么受欢迎、频道类型或相应频道的估计用户行为之类的准则来进行选择。
定时器值可以例如具有针对更受欢迎的频道而指定的更低值，而针对较不受欢迎的频道选择更高的定时器值，以甚至进一步优化重新协商过程。
通过引入所提出的基于定时器的有条件带宽重新协商机制，可以减少带宽重新协商次数，并且，仅在确定了终端用户已维持在特定持续时间内(即，在相关定时器值的持续时间内)调谐的相应所选频道的情形中，才实际上开始带宽重新协商。
现在将根据一个示例实施例，参照图2的流程图来更详细地描述一种在UE中实现这种机制的方式。
应当理解，所描述的流程图仅描述了一种确定何时开始带宽重新协商过程(如果有的话)的可能方式，也可以通过实现方式的其他备选方式来应用基于上述一般原理的机制。
作为前提，假定终端用户被调谐至IPTV频道，并且已经在UE处开始有条件带宽重新协商功能，该UE典型地可以是例如以下任一项：计算机、PDA、机顶盒或包括机顶盒功能的TV、或移动电话、或被配置为请求并显示一个或多个IPTV服务/IPTV频道的任何其他类型的移动设备。利用第一步骤200来指示这种有条件功能的开始。
在下一步骤201中，确定终端用户是否已请求频道切换。一旦UE识别出所请求的频道切换，则确定所选频道所需的带宽是否等于当前观看的频道所需的带宽，即已分配给UE的带宽，从而确定是否可以在无需任何带宽重新协商的情况下执行切换至新频道。该条件在步骤202中进行评估，如果发现所需带宽保持不变，则在下一步骤中执行频道切换，如后续步骤203所示。在执行频道切换之后，重复所描述的循环，从步骤201处开始，等待另一频道切换开始。
然而，如果带宽需求对于不同频道是不同的，则另一评估步骤开始，如下一步骤204所示。在该第二评估步骤中，确定所选频道所需的带宽是否小于当前频道所需的带宽。如果不小于，即需要附加带宽以便能够向终端用户提供所选服务/频道，则将在如步骤203所示执行所请求的频道改变之前，如下一步骤205所示，典型地根据传统过程，执行无条件重新协商过程，此后，再一次重新开始循环，从步骤201开始。
然而，如果反之确定当前分配的带宽大于所选频道所需的带宽，则所提议的方法代之以通过执行所请求的频道切换来继续，如步骤206所示，并与频道切换相关联地，通过启动被设置为针对所选频道或针对相应频道所属的频道组而指定的预定义定时器值的持续时间的定时器来继续，如后续步骤207所示。
只要终端用户未发起新的频道切换，如包括步骤208和在后续步骤210处继续的“否”分支(208b)在内的循环所示，定时器将运行。如所描述的循环所示，如果在定时器超时之前发生新的频道切换，即，根据步骤210的“是”分支(210a)，则现在通过认为先前频道切换不再需要带宽重新协商来采取依赖于当前运行的定时器的、延迟的带宽重新协商决定，从而，在起始于步骤202考虑最新请求的频道切换的条件之前，这种决定之后的下一活动将复位与先前频道切换相关联的未决定时器，如步骤211所示。
如果取而代之地在终端用户激活任何新的频道切换之前发生定时器超时，如步骤208的“是”分支(208a)所示，则典型地根据如另一步骤209所示的传统带宽重新协商过程，将带宽重新协商设置为针对最近请求的频道切换而开始。
根据一个实施例，在步骤202和204执行的带宽需求评估过程可以通过以下操作来执行：将分别针对所选频道和当前频道而指定的、例如已经由广播供应提供给UE的最大比特率属性的相关值进行比较。
现在将参照图3的信令图来描述用于描述UE可以如何执行有条件带宽重新协商过程(例如以上参照图2描述的过程)的示例情形。
应当理解，图3是简化的示意信令图，其中重点在于示出了不同频道切换情形之间的区别，其中应用了根据上述原理的有条件带宽重新协商过程。在图中，要激活所提出的有条件带宽重新协商过程的不同情形是利用标记为“S”的符号来指示的。
为了简明，在发起有条件重新协商过程之后，在图中仅示出对于完全理解将响应于不同备选情形而执行的所提出的有条件带宽重新协商过程的一般原理来说重要的步骤，而适用于所有所描述情形的完整过程可以通过遵照图2的流程图以及以上所附文本而标识。
作为前提，针对该图，还假定适于应用有条件带宽重新协商过程的UE 300经由由IMS核心网101表示的IMS网络连接至IPTV网络102，并参与IPTV会话，即，在UE 300上当前呈现IPTV频道。
在第一步骤3:1中，终端用户典型地通过以传统方式激活遥控器来主动地切换频道，因此，发起有条件带宽重新协商过程。在该具体情况下，假定所请求的频道需要比针对当前所选频道而分配的带宽更大的带宽，因此，不对带宽重新协商决定进行延迟，而是开始典型地包括以上参照图1描述的步骤1:15-1:20的执行在内的带宽重新协商。在图3中，这些步骤由对应的步骤3:2-3:7表示。
一旦已经成功地完成带宽重新协商过程，就可以经由相应的IPTV频道向用户示出所选的节目，即，将执行与图1的步骤1:21和1:22相对应的步骤。在本示例中，这些步骤由图3中的步骤3:8表示。
一旦用户选择以挑选另一频道，将发起新的有条件带宽重新协商过程，如另一步骤3:9所示。然而，在这种情况下，代之以假定当前带宽超过所选频道所需的带宽，因此，可以执行频道切换而不必决定是否要即时执行任何带宽重新协商过程。相应地，执行频道切换并将所请求的IPTV服务提供给UE 300，如下一步骤3:10所示。然而，一旦已选择频道，就启动定时器，从而还启动用于延迟带宽重新协商决定的过程，如下一步骤3:11所示。
在过去了一些时间之后，假定终端用户进行另一频道切换，该另一频道切换启动另一有条件带宽重新协商过程，如与图2的步骤210相对应的后续步骤3:12所示。
假定在由步骤3:9发起的先前频道切换触发的定时器超时之前发生新的频道选择，因此，确定不必要执行在步骤3:9中选择的频道的带宽重新协商。因此，在再一次确定是否要执行延迟的带宽重新协商或者是否要取而代之地启动立即的无条件带宽重新协商之前，终止未决定时器，如步骤3:13所示。
此外，此时假定当前带宽超过所请求的频道所需的带宽，因此，在如步骤3:15(对应于图2的步骤207)所示启动另一定时器并启动另一延迟的带宽重新协商过程之前，可以将所请求的频道提供给用户，如步骤3:14所示，对应于图2的步骤206。
最新的情形可以表示以下事件：用户正在不同频道之间进行切换，以使其自身定向至可用节目，但不决定选择继续观看节目中的任一个。在这种情形下，带宽重新协商将导致不必要的延迟，尤其是在考虑到从争取实现对所分配带宽的高效使用的观点来看运营商几乎没有任何收获的情况下。
然而，此时假定在步骤3:15发起的定时器超时之前未选择新频道。这是利用另一步骤3:16的定时器超时来指示的。由于超时，现在将发起带宽重新协商过程，这是由于用户现在将更可能保持连接至当前频道，因此，UE 300将能够继续使用分给配它的较小带宽来接收所选的IPTV频道。图3中的步骤3:17所示的这种发起步骤与图1的步骤1:15和图2中的步骤208的“是”分支相对应。在该步骤之后，将开始与图1的步骤1:16a或1:16b至1:20相对应的带宽重新协商过程(未示出)。
如上所述，如本文中提出的过程之类的有条件带宽重新协商过程基于指定的带宽需求。此外如上所述，可以典型地经由广播供应，将这种信息从提供一个或多个IPTV服务的IPTV网络提供给UE。
图4a是示例表400a，示意了如何可以典型地由运营商来配置要提供给UE以形成有条件带宽重新协商过程的输入数据的信息。表400a包括对在“最大比特率”栏402中列出的最大比特率的指示，所列出的最大比特率中的每一个是针对在“频道”栏401中列出的相应IPTV频道而指定的。表400a还包括在“TTR”栏403中列出的、针对每个频道而指定的定时器值。
如上所示，通常，例如根据已知的开放IPTV论坛标准，在广播供应中将最大比特率属性提供给UE。除了该信息，还可以例如在广播供应的新TTR属性中将一个或多个相关定时器值提供给UE。
备选地，出于所描述的目的，可以定义和使用另一变量，该变量可以取而代之地是对所指定的频道组的最大比特率的指示，该最大比特率这里称作预留最大比特率，并在“预留最大比特率”栏404中指示。表400b是可能配置的示例性示意，其中，已经将多个频道分组为两个组之一，所述多个频道中的每一个频道均具有指定给它的相关联最大比特率。
在典型实施例中，将最大比特率属性402(如果要考虑各个比特率)或预留最大比特率属性(如果要考虑分组后的比特率)与TTR属性一起提供给UE。此时，有条件带宽重新协商过程将依赖于在所接收的比特率属性和TTR属性中提供的值。
引入预留最大比特率的主要目的是基于针对频道而指定的带宽需求来实现对不同类别的频道的分组。
在图4b中，这是由被分组在一起的两个频道SVT-1和SVT-2，通过对该组给出公共预留最大比特率值来示例的，而canal+、TV-4和TV-3已经被分组在一起并指定有另一更高的预留最大比特率值。
如果示意为图2中的步骤202和204的评估步骤要基于根据预定义策略(例如，基于终端用户行为模式)而指定的预留最大比特率值，则所发起的带宽重新协商过程的数目可能甚至比基于每频道(即，根据被指定给各个频道的最大比特率属性)来指定比特率需求的情况减小得更多，这是由于只要所选频道与当前频道属于相同的组，就不需要新的带宽重新协商。
相应的最大比特率值和/或预留最大比特率值可以由运营商指定，并可以根据一个或多个预定义准则来选择，从而使运营商能够对带宽如何用于分发IPTV频道进行至少一些控制。
所提出的基于定时器的有条件带宽重新协商机制的实现方式不需要在IPTV网络侧进行任何大的修改，并且，如以下将清楚地示出的，该实现方式还将仅需要对被配置为应用这种机制的UE进行小的修改。
现在将参照图5来描述被配置为应用如以上根据简化示例实施例描述的机制的UE。
图5的UE 300包括：处理器501，可以包括一个或多个子处理器，并被配置为管理一个或多个软件模块和/或应用，以使UE能够执行上述操作和过程，以及典型地在所提出类型的通信实体上运行的任何其他传统操作。
UE 300包括：收发器502，适于与由IMS核心网101表示的一个或多个网络实体交换信息，并与由图中的IPTV网络102表示的IPTV运营商进行通信。
可以经由用户接口(UI)503将用户输入提供给UE 300，用户接口(UI)503可能已经与UE 300集成或被配置为单独实体(如遥控器)的一部分。UE 300还包括：显示器504，用于向终端用户呈现与IPTV建立以及IPTV媒体内容相关联的信息。备选地，如果UE 300具有触摸屏能力，则显示器504可以被配置为与用户接口503集成的显示器。
UE 300的软件应用典型地存储在应用存储器505中，如广播供应之类的信息可以下载和/或高速缓存在单独存储器506中，并随后从单独存储器506中检索。
最后，UE 300还包括：定时器507，适于基于预定义定时器值来运行，其中，可能已经例如经由在广播供应中转发的TTR属性将该预定义定时器值从IPTV网络提供给UE 300。
通过针对多个频道或频道组对带宽进行重新协商，运营商将可以实现对可用于由运营商提供的IPTV服务的资源预留的优化。通过针对单独频道或频道组对带宽进行协商，该优化可以适用。如果例如已针对具有标准清晰度(SD)的频道组对带宽进行协商并且用户然后选择高清晰度(HD)频道，则当用户已选择在属于不同频道组的频道之间进行频道切换时，将针对该频道组执行包括带宽重新协商在内的会话修改。然后，将利用针对相应组而指定的最大带宽/比特率来建立会话，并且，如果用户随后选择不同组的频道，则将代之以指定新的最大带宽/比特率。
所提出的基于定时器的机制基于可在各种类型的静止和移动设备中容易地实现的非常简单和直接的方案。
通过引入两个新属性，在广播供应中向UE提供预定义比特率值和一个或多个延迟值，为针对单个频道或频道组执行带宽预留的目的所必需的信息将容易管理，这是由于该输入数据能够容易检索。
不需要对所有频道的最大带宽需求进行解析，而是当确定是否应当推迟带宽重新协商决定时，在存储在UE处的广播供应信息中简单地查找相应字段。
IPTV运营商将得到对在访问线路中如何处理带宽预留的至少一些控制，从而在仅具有稍微不同带宽特性的频道之间进行切换时无需任何额外信令。
还可以提供对HD频道的支持，而无需持久地预留频道。再次利用有条件的基于定时器的重新协商方法，运营商在其部署中具有控制针对HD频道的带宽预留的明确手段。
所提出的机制还提供了对画中画(Picture & Picture)的支持，画中画典型地需要小的带宽以及马赛克类型的视图，其中，在单一显示器上呈现多个流。通过所提出的方法，可以建立许多多播流并可以使用清晰的带宽需求。典型地，这种流被视为对于这种情形来说不正确的SD或HD流，其中，如DSLAM之类的访问设备可以假定3个流表示极限而实际上可以支持潜在地多至15个这种小流。这种缺陷可以由所提出的方法来处理，这是由于导致带宽重新协商的次数减少。
此外，尽管参照特定示例实施例描述了本发明，但该描述一般仅意在示意本发明的构思，而不应被视为限制本发明的范围，本发明的范围由所附权利要求来限定。
缩写
BG边界网关
DSLAM数字订户线接入复用器
IMS IP多媒体子系统
HD高清晰度
MGCF媒体网关控制功能
P-CSCF代理-呼叫会话控制功能
S-CSCF服务-呼叫会话控制功能
SD标准清晰度
STB机顶盒
UE用户设备

Claims (19)

1.一种在用户设备(300)处进行的方法，当所述用户设备参与从IPTV网络(102)提供的IPTV会话时，所述方法与频道切换相关联地管理带宽重新协商，所述方法的特征在于：
当确定(204)所请求的频道比当前所选频道需要较小带宽时，应用与所请求的频道切换(201、210)相关联的有条件带宽重新协商过程，其中，所述有条件带宽重新协商过程包括执行以下步骤：
-切换(206)至所请求的频道；
-启动(207)定时器，所述定时器的目的是延迟对是否要执行带宽重新协商的决定；以及
-响应于识别出(208a)所述未决定时器超时，发起(209)带宽重新协商。
2.根据权利要求1所述的方法，还包括以下步骤：
-在所述定时器超时之前，响应于识别出(210a)另一频道切换请求，终止(211)所述定时器。
3.根据权利要求1所述的方法，其中，在终止未决定时器之后，确定(202、204)是否还要响应于最新的频道切换请求来应用有条件带宽重新协商过程。
4.根据权利要求1或2所述的方法，其中，所述带宽需求是通过以下操作来评估的：将与所请求的频道相关联且与所请求的频道所需的带宽相对应的比特率属性的值与当前可用于用户设备(300)且与被分配给当前频道的带宽相对应的最大比特率进行比较。
5.根据权利要求3所述的方法，其中，所述比特率属性是从所述IPTV网络(102)提供给用户设备(300)的。
6.根据权利要求4所述的方法，其中，所述比特率属性是在广播供应中提供给用户设备(300)的。
7.根据权利要求3或4所述的方法，其中，所述比特率属性包括基于每频道而预定义的比特率值。
8.根据权利要求6所述的方法，其中，所述比特率属性是最大比特率属性。
9.根据权利要求3、4或5所述的方法，其中，所述比特率属性是包括基于每频道组而预定义的值在内的新属性。
10.根据前述权利要求中任一项所述的方法，其中，所述定时器是根据从所述IPTV网络(102)提供给用户设备(300)的定时器值TTR来设置的。
11.根据权利要求9所述的方法，其中，所述定时器值TTR是针对从所述IPTV网络(102)提供的所有频道而预定义的公共定时器值。
12.根据权利要求9所述的方法，其中，所述定时器值TTR是针对特定频道而预定义的频道专用定时器值。
13.根据权利要求9所述的方法，其中，所述定时器值TTR是针对特定频道组而预定义的组专用定时器值。
14.根据权利要求9所述的方法，其中，所述定时器值TTR是在广播供应中提供给用户设备(300)的新属性。
15.一种用户设备(300)，当所述用户设备(300)参与与IPTV网络(102)的IPTV会话时，所述用户设备(300)与执行所请求的频道切换相关联地管理带宽重新协商，所述用户设备(300)的特征在于：
-存储器(506)，被配置为存储与至少两个IPTV频道相关联的带宽需求信息；
-处理器(501)，被配置为在所请求的频道所需的带宽小于当前所选频道所需的带宽的情况下，响应于所请求的频道切换，发起有条件带宽重新协商过程；
-定时器(507)，能够被所述处理器(501)控制，使得在有条件带宽重新协商过程期间，所述定时器被设置为延迟对是否要发起带宽重新协商的决定；
所述处理器(501)还被配置为通过切换至所请求的频道来发起有条件重新协商过程，并响应于识别出超时来发起带宽重新协商，所述超时由所述一个或多个预定义时间值TTR之一来定义。
16.根据权利要求15所述的用户设备(300)，其中，所述存储器还适于存储由所述定时器使用的、与至少两个IPTV频道相关联的至少一个预定义定时器值TTR。
17.根据权利要求14所述的用户设备(300)，其中，在终止未决定时器之后，所述处理器(501)还被配置为确定是否还要响应于最新的频道切换请求来应用有条件带宽重新协商过程。
18.根据权利要求14或15所述的用户设备(300)，其中，所述处理器(501)还被配置为通过以下操作来评估所述带宽需求：将与所请求的频道相关联且与所请求的频道所需的带宽相对应的比特率属性的比特率值与当前可用于用户设备(300)且与被分配给当前频道的带宽相对应的最大比特率进行比较。
19.根据权利要求14、15或16中任一项所述的用户设备(300)，其中，所述用户设备(300)是以下任一项：机顶盒；PDA；TV；计算机或移动电话。
CN200980120511.4A 2008-06-06 2009-02-09 用于预留带宽的方法和用户设备 Active CN102047637B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US5933308P 2008-06-06 2008-06-06
US61/059,333 2008-06-06
PCT/SE2009/050129 WO2009148379A2 (en) 2008-06-06 2009-02-09 A method and a user equipment for reserving bandwidth

Publications (2)

Publication Number Publication Date
CN102047637A true CN102047637A (zh) 2011-05-04
CN102047637B CN102047637B (zh) 2014-12-31

Family

ID=41396037

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200980120511.4A Active CN102047637B (zh) 2008-06-06 2009-02-09 用于预留带宽的方法和用户设备

Country Status (9)

Country Link
US (1) US8443410B2 (zh)
EP (1) EP2291973B1 (zh)
JP (1) JP5211238B2 (zh)
CN (1) CN102047637B (zh)
CA (1) CA2726446C (zh)
HK (1) HK1151909A1 (zh)
TW (1) TWI528830B (zh)
WO (1) WO2009148379A2 (zh)
ZA (1) ZA201008093B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104469541A (zh) * 2013-09-18 2015-03-25 中兴通讯股份有限公司 一种iptv的频道切换方法和装置、终端
CN107409235A (zh) * 2015-03-27 2017-11-28 爱立信股份有限公司 用于使用单播abr流播在交换数字视频网络中提供vod内容的系统和方法
CN110249660A (zh) * 2017-02-02 2019-09-17 三星电子株式会社 用于在移动通信系统中发送和接收数据的方法和装置
US11019544B2 (en) 2017-02-02 2021-05-25 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data in mobile communication system

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101585010B1 (ko) * 2009-03-11 2016-01-14 삼성전자주식회사 무선 인터넷 프로토콜 텔레비전 시스템에서 채널 대역 할당방법 및 이를 위한 시스템
EP2452470A4 (en) * 2009-07-10 2014-04-30 Ericsson Telefon Ab L M METHOD, TERMINAL, ACCESS N UD AND MEDIA SERVER FOR ISSUING MEDIA DIGITAL STREAM RESOURCE ADMISSION CONTROL
US9118745B2 (en) * 2010-01-18 2015-08-25 Telefonaktiebolaget L M Ericsson (Publ) Remote access to a device in an IMS system with a second media access channel
WO2011136560A2 (ko) * 2010-04-27 2011-11-03 엘지전자 주식회사 화이트스페이스 내에서 스테이션의 동작 방법 및 이를 위한 장치
US9769231B1 (en) * 2011-04-01 2017-09-19 Arris Enterprises Llc QoS for adaptable HTTP video
CN102271281B (zh) 2011-08-08 2013-07-10 华为技术有限公司 快速频道切换的实现方法和装置
KR101259748B1 (ko) * 2011-09-28 2013-04-30 서울대학교산학협력단 모바일 ｉｐｔｖ 서비스 제공 방법 이를 실행하는 시스템
US9201719B2 (en) * 2012-03-16 2015-12-01 Infineon Technologies Ag Method and system for timeout monitoring
US9894599B2 (en) 2012-06-13 2018-02-13 Qualcomm, Incorporated Method and apparatus for WLAN initial link setup
KR20160004186A (ko) * 2014-07-02 2016-01-12 삼성전자주식회사 방송신호수신장치 및 그 제어방법
US10028317B2 (en) * 2015-05-08 2018-07-17 Federated Wireless, Inc. Policy and billing services in a cloud-based access solution for enterprise deployments

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1685671A (zh) * 2002-09-23 2005-10-19 诺基亚有限公司 带宽适应
US20070056015A1 (en) * 2005-09-08 2007-03-08 Philip Kortum System and method of managing IPTV bandwidth in non-observation scenarios
CN101166182A (zh) * 2006-10-18 2008-04-23 中国电信股份有限公司 基于面板操作的宽带接入带宽调节方法及系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030093515A1 (en) 2001-11-14 2003-05-15 Kauffman Marc W. Quality of service control of streamed content delivery
FI116498B (fi) * 2002-09-23 2005-11-30 Nokia Corp Kaistanleveyden mukauttaminen
JP3987852B2 (ja) 2004-04-08 2007-10-10 シャープ株式会社 サービス受信装置
JP2008530835A (ja) 2005-02-08 2008-08-07 テレフオンアクチーボラゲット エル エム エリクソン（パブル） パケット交換ネットワーク上のオンデマンドマルチチャネルストリーミングセッション
KR100677462B1 (ko) 2005-06-23 2007-02-02 엘지전자 주식회사 스트리밍서비스를 위한 휴대단말기의 대역폭산정시스템 및방법
CN101438256B (zh) 2006-03-07 2011-12-21 索尼株式会社 信息处理设备、信息通信系统、信息处理方法
JP5003690B2 (ja) 2007-01-19 2012-08-15 日本電気株式会社 映像音声ストリーム配信システム、配信方法、および配信用プログラム
US7761902B2 (en) * 2007-05-11 2010-07-20 At&T Intellectual Property I, L.P. System and method of providing video content

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1685671A (zh) * 2002-09-23 2005-10-19 诺基亚有限公司 带宽适应
US20070056015A1 (en) * 2005-09-08 2007-03-08 Philip Kortum System and method of managing IPTV bandwidth in non-observation scenarios
CN101166182A (zh) * 2006-10-18 2008-04-23 中国电信股份有限公司 基于面板操作的宽带接入带宽调节方法及系统

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104469541A (zh) * 2013-09-18 2015-03-25 中兴通讯股份有限公司 一种iptv的频道切换方法和装置、终端
CN107409235A (zh) * 2015-03-27 2017-11-28 爱立信股份有限公司 用于使用单播abr流播在交换数字视频网络中提供vod内容的系统和方法
CN107409235B (zh) * 2015-03-27 2020-10-27 爱立信股份有限公司 用于使用单播abr流播在交换数字视频网络中提供vod内容的系统和方法
CN110249660A (zh) * 2017-02-02 2019-09-17 三星电子株式会社 用于在移动通信系统中发送和接收数据的方法和装置
US11019544B2 (en) 2017-02-02 2021-05-25 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data in mobile communication system
CN110249660B (zh) * 2017-02-02 2023-07-21 三星电子株式会社 用于在移动通信系统中发送和接收数据的方法和装置
US11765632B2 (en) 2017-02-02 2023-09-19 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data in mobile communication system

Also Published As

Publication number Publication date
CA2726446C (en) 2017-03-14
EP2291973B1 (en) 2018-01-10
CA2726446A1 (en) 2009-12-10
WO2009148379A2 (en) 2009-12-10
US20110099595A1 (en) 2011-04-28
ZA201008093B (en) 2012-02-29
JP5211238B2 (ja) 2013-06-12
TW201004348A (en) 2010-01-16
CN102047637B (zh) 2014-12-31
WO2009148379A3 (en) 2010-02-25
JP2011526098A (ja) 2011-09-29
TWI528830B (zh) 2016-04-01
HK1151909A1 (zh) 2012-02-10
US8443410B2 (en) 2013-05-14
EP2291973A2 (en) 2011-03-09

Similar Documents

Publication Publication Date Title
CN102047637B (zh) 用于预留带宽的方法和用户设备
US20230084473A1 (en) Unicasting and multicasting multimedia services
RU2480936C2 (ru) Способ, устройство и система для распространения информации на основе ip-телевидения
US8973057B2 (en) Method and equipment for providing unicast preparation for IPTV
EP2175591B1 (en) A method, a system, a device and a computer program readable medium for realizing the services of network televison
US9226002B2 (en) Method, device and system for realizing broadcast TV
CN101326826B (zh) 网络电视的业务控制方法、系统以及装置
CN102439941A (zh) 用于处理指示要参与到至少一个用户应用会话中的期望的信息条的方法和装置
US20090147779A1 (en) Methods, iptv (internet protocol television) terminal, and iptv control server for iptv bandwidth management
WO2010028589A1 (zh) 业务推送协商方法及装置、推送业务系统
JP2012515484A (ja) ネットワークにおける関連付けられたセッションの管理
RU2532263C2 (ru) Интерактивная система iptv и способ распространения в ней контента
US9246695B2 (en) Method and apparatus for providing virtual closed circuit television
CN101547402B (zh) 一种建立iptv多播业务的方法及设备
CN101360095A (zh) 会话初始协议网络中提供电视业务的方法、装置和系统
CN101668173A (zh) 基于网际协议电视的信息推送方法、装置及系统
CN102026024A (zh) 一种ppv业务的实时控制方法、系统和设备
CN101340362A (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
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1151909

Country of ref document: HK

C14 Grant of patent or utility model
GR01 Patent grant
REG Reference to a national code

Ref country code: HK

Ref legal event code: GR

Ref document number: 1151909

Country of ref document: HK