CN101107854A - 用于向移动数据处理单元发送数据的方法和设备 - Google Patents

Abstract

本发明涉及用于向移动数据处理单元发送数据的方法，该方法包括以下步骤：a.利用数字音频和/或电视接收设备(100)接收数据，其中所述数据被包括在数字音频和/或电视信号的传输流中；b.从数字音频和/或电视信号的传输流中提取出所述数据；以及c.利用数字音频和/或电视接收设备(100)发送电磁信号，以将提取出的数据从数字音频和/或电视接收设备(100)发送到移动数据处理单元(200)，其中d.所述提取出的数据是响应于从移动数据处理单元(200)到数字音频和/或电视接收设备(100)的周期性请求被从数字音频和/或电视接收设备(100)发送到移动数据处理单元(200)的。

Description

用于向移动数据处理单元发送数据的方法和设备

技术领域

本发明涉及用于向移动数据处理单元发送数据的方法和设备。

背景技术

诸如手持计算机、PDA、智能移动电话等的移动数据处理单元变得越来越流行。一个原因在于这些设备的多媒体能力在持续增长。例如，当今的移动电话包括超出了基本的通信需求的很多种功能。

但是，这种移动数据处理系统遇到的一个困难在于数据的下载，具体而言，如果数据大小相对较大，则经由标准移动通信网络的下载会很慢并且很昂贵。例如，经由GSM网络获得并安装诸如新游戏之类的新处理应用到移动电话只有在该游戏可被压缩成小量数据的情况下才是可行的。

另一种选择是将移动数据处理单元连接到个人计算机，该个人计算机进而连接到因特网。在个人计算机能够进行高速因特网访问的情况下，这种方法允许快速下载大量数据并将数据转发到被连接的移动数据处理单元。但是，希望以这种方式将来自提供者的数据发送到移动数据处理单元上的用户需要大量关于计算机、因特网等的技术专业知识。

为了克服这种困难，现有技术(例如WO 2004/088983、WO03/088027和WO 03/088655所述的技术)中已知提供了用于接收数据的机顶盒等等，所述数据包括卷积的(convoluted)电视信号和附加数据。附加数据与电视信号相分离，并被以无线方式发送到PDA或移动电话以使其可被用户访问。

在这样的系统中，存在两种冲突的目标。一方面，附加数据的提供者可能希望影响将显示在用户的移动单元上的内容。另一方面，移动单元的用户本身希望以有点类似于在因特网上浏览的方式来保持控制数据是否被显示在移动单元上以及哪些数据将被显示在移动单元上。

因此，本发明的问题是要提供一种用于从机顶盒等向移动数据处理单元发送数据的改进的方法，该方法为附加数据的提供者和移动单元的用户两者提供平衡的影响实际发送到移动单元的数据的可能性。

发明内容

根据本发明的一个方面，该问题被一种用于向移动数据处理单元发送数据的方法所解决，该方法包括以下步骤：

-利用数字音频和/或电视接收设备接收数据，其中所述数据被包括在数字音频和/或电视信号的传输流中；

-从所述数字音频和/或电视信号的传输流中提取出所述数据；以及

-利用所述数字音频和/或电视接收设备发送电磁信号，以将来自所述数字音频和/或电视接收设备的提取出的数据发送到移动数据处理单元，其中所述提取出的数据是响应于从移动数据处理单元(200)到数字音频和/或电视接收设备(100)的周期性请求被从数字音频和/或电视接收设备(100)发送到移动数据处理单元(200)的。

本发明基于这样的思路：使用日益流行的数字音频和/或电视接收设备(也被称为机顶盒)，其不仅用于接收广播数字电视信号，还用于将附加数据包括到广播媒体的主要传输流中。一旦组合的信号被接收，附加数据就被提取出来并被作为电磁信号从机顶盒发送到移动数据处理单元，即优选地与数字音频和/或电视接收设备分开并且与其普通功能不相关的单元。

从移动数据单元到数字音频和/或电视接收设备的周期性请求优选地向内容提供者提供向移动数据处理单元发送新数据的规则的可能性。新数据可以是用户请求的数据，也可以是提供者希望由移动数据处理单元接收并且可能被显示的数据，例如重要消息。另一方面，用户还可以影响整个通信，因为优选地总是移动台或用户本身启动与数字音频和/或电视接收设备的通信。此外，对其它可用数据的请求可以通过从移动数据处理单元到数字音频和/或电视接收设备的周期性请求或附加的异步请求来发布。

优选地，该方法还包括将提取出的数据存储在数字音频和/或电视接收设备中，并在例如接收设备和/或连接的电视机上将关于提取出的数据的可用性的消息呈现给用户。因此，用户可以控制是否以及何时将存储在数字音频和/或电视接收设备中的数据最终发送到他的移动数据处理单元上。例如，代表具有足球比赛(其作为相关数字电视广播的主题)的所有结果的表的数据可被用户获得以转移到他的移动电话或PDA上。

在一个实施例中，从数字音频和/或电视接收设备到移动数据处理单元的数据传输是响应于在数字电视接收设备或互连的电视机处的用户输入而被执行的。这例如可以通过在数字音频和/或电视接收设备的遥控器或设备本身上提供一个或多个合适的按钮来实现。在另一替换方式中，到移动数据处理单元的最终传输是响应于数字音频和/或电视接收设备从移动数据处理单元接收到信号而被执行的。而且，两种发起事件的组合也是可能的。

优选地，来自移动数据处理单元的周期性请求用于使移动数据处理单元中的数据的至少一部分与存储在数字音频和/或电视接收设备中的一组数据同步。因此，内容提供者可以通过利用数字音频和/或电视信号的传输流向数字音频和/或电视接收设备发送新数据来影响最终发送到移动台的数据的内容，其中这些数据在随后的同步期之一中被转发到移动数据处理单元。

在优选实施例中，移动数据处理单元的周期性请求被自动执行，并且优选地无需用户输入。此外，周期性请求之间的刷新间隔优选地可被改变。刷新间隔的值优选地与用于同步的新数据一起被从数字音频和/或电视接收设备发送到移动数据处理单元。作为结果，内容提供者可以容易地确定移动数据处理单元将以多快的速度利用新数据被更新。此外，用户不会被移动数据处理单元的重复背景轮询(background polling)所打扰。优选地，刷新间隔的长度为1s≤t≤10s。

当前优选地，如果数字音频和/或电视信号的传输流的内容和所包括的数据的内容相关，则特别有利。本发明的这个方面特别有价值，因为它能够以简单的方式使内容提供者确保与某一广播相关的数据(例如游戏或一段音乐)在没有很大延迟的情况下就可以在移动数据处理单元上获得。在另一情况下，降低移动数据处理单元的轮询频率可能是有利的，这例如用于减小处理负载并提供用于在移动数据处理单元上运行下载的应用的更多的处理容量。

在优选实施例中，传输流包括针对多个频道的数字音频和/或电视信号，其中从传输流中提取出并被发送到移动数据处理单元的数据取决于数字音频和/或电视接收设备被调谐到的频道。这一方面扩展了经由数字音频和/或电视接收设备将数据下载到移动数据处理单元的基本功能，从而创建了全新的多媒体系统，其中用户可以在移动数据处理单元上获得与当前选择的电视节目一起呈现并且与其相关的附加信息、游戏、音乐或其它数据。

优选地，针对数字音频和/或电视接收设备被调谐到的第一频道的提取出的数据被存储在数字音频和/或电视接收设备的存储器中。在一个实施例中，除非将被发送到移动数据处理单元的针对第一频道的提取出的数据与针对第二频道的提取出的数据相同，否则在从第一频道改变到第二频道的情况下，存储在存储器中的数据被清除(purged)。作为结果，数字音频和/或电视接收设备的最大存储器量可被用于新频道的数据。在另一实施例中，在从第一频道改变到第二频道的情况下，存储在存储器中的数据被保留。该实施例使得被发送到移动数据处理单元的数据能够更快速地在另一改变之后返回到第一频道。

根据本发明的另一方面，提供了一种用于向移动数据处理单元发送数据的方法，该方法包括以下步骤：

-将要被发送的数据包括在将被广播的数字音频和/或电视信号的传输流中；

-以适合于数字音频和/或电视接收设备接收数字音频和/或电视信号的数字格式广播具有被包括的数据的数字音频和/或电视信号的传输流，以提取出被包括的数据并将它们发送到移动数据处理单元，

其中：

-被包括的数据被适配为响应于从移动数据处理单元到数字音频和/或电视接收设备的周期性请求而被发送。

因此，数字电视信号的发送者发射包括将被广播的标准数字电视信号和供最终传输(即下载)到移动数据处理单元上的附加信号的卷积信号。根据本发明的这个方面，卷积信号的格式特别适合于数字音频和/或电视接收设备从主信号流中提取出所包括的数据，以使得用户可以观看数字电视，并且另外可以响应于从移动数据处理单元到数字音频和/或电视接收设备的周期性请求获得用于他的移动数据处理单元的附加数据。优选地，所包括的数据使得移动数据处理单元的周期性请求之间的刷新间隔改变。

在一个实施例中，第一和/或第二方法步骤是响应于数据的提供者接收到来自数字音频和/或电视接收设备和/或移动数据处理单元的信号而被执行的。该高级实施例允许用户交互地影响附加数据是否被发送到一个或多个数字音频和/或电视接收设备以便随后下载到一个或多个移动数据处理单元上。

根据另一方面，本发明涉及一种数字音频和/或电视接收设备，该设备包括第一接收单元，其接收数字音频和/或电视信号的传输流以显示在电视和/或无线电系统上，所述数字音频和/或电视信号的传输流包括附加数据。该数字音频和/或电视接收设备还包括：提取单元，其从数字信号的传输流中提取出附加数据；发送单元，其将提取出的附加数据发送到外部的移动数据处理单元，其中所述数字音频和/或电视接收设备还包括第二接收单元，其适合于接收来自移动数据处理单元的周期性请求以发起提取出的附加数据的发送。

最后，本发明涉及一种移动数据处理单元，其包括：第一收发机单元，用于与移动电话网络通信；第二收发机单元，用于与数字音频和/或电视接收设备通信；和带有指令的控制装置，其使得第二收发机单元向数字音频和/或电视接收设备周期性地发送请求，该请求发起向移动数据处理单元的第二收发机发送附加数据，所述附加数据与数字音频和/或电视信号一起被数字音频和/或电视接收设备接收。

要求保护的方法和要求保护的设备的其它修改是其它从属权利要求的主题。

附图说明

在以下详细描述中，参考附图描述了本发明的当前优选实施例，在附图中：

图1：在本发明的上下文中使用的数字电视接收设备的各个组件的示意图；

图2：在本发明的上下文中使用的移动数据处理单元的各个组件的示意图；

图3：在当前优选的实施例中，本发明的各个元件的更详细的概观；

图4：在图3的实施例中，用于STB和移动设备之间的通信的通信层的堆栈的概观；以及

图5：在图3的实施例中，用于移动设备和STB之间的通信的主要命令的概观。

具体实施方式

在下文中，引用能够接收数字电视或无线电信号的机顶盒100描述根据本发明的方法和设备。机顶盒100的所有功能单元布置在图1中的虚线框所指示的单个电子设备中不是必要的。在以下描述中所述的机顶盒100的一个或多个组件可以被实现在被适当地连接到机顶盒100的其它功能单元的附加设备中。此外，虽然在以下描述中引用机顶盒100作为连接到标准电视机102的设备，但是本发明也可以利用具有用于接收广播数字电视信号或无线电信号的合适的电子器件的卡(例如用在个人计算机中的PC卡)来实现，只是这不是当前最优选的。此外，注意，在本申请的上下文中，术语“机顶盒”不仅包括用于接收数字电视信号的设备，还包括附加地或可替换地适合于接收数字无线电节目的设备。最后，机顶盒不一定必须是单独的设备。它也可以被集成到另一设备(例如电视)中。

图1示出了机顶盒100的概观。在数字电视信号中的数据传输流中运载附加数据集合的广播信号被天线101所接收，其中所述附加数据集合定义例如针对移动数据处理单元200的特殊应用。代替天线101所接收的卫星信号，传输流也可作为地面数字TV节目或经由电缆(未示出)被接收。数字电视信号的提供者(未示出)已经例如通过在数据分组中包括特定头部而将附加数据集合调制在标准的数字电视数据流上，所述特定头部允许机顶盒在下面所述的进一步的步骤期间提取出附加数据集合。各种用于数字电视信号和附加数据集合的卷积技术都是可能的，其中包括对卷积流的进一步压缩，以最大化用于向机顶盒100传输数据的带宽。

在一个实施例中(未示出)，附加数据集合的传输是响应于提供者接收到来自一个或多个用户的信号而被执行的。可以利用调制解调器连接等经由从机顶盒100到提供者的标准返回线路接收这样的发起信号，或者移动数据处理单元200(例如移动电话)经由其通信网络(例如GSM、GPRS或UMTS网络)向提供者传送对附加数据的请求。

附加数据集合的内容优选地与广播信号的内容相关。一个示例是与实况转播事件(例如足球比赛)相关的附加信息。附加数据可以包括多种数据内容，例如关于正在进行的比赛的进一步的统计信息或者甚至是用户要在移动数据处理单元200上播放的相关计算机游戏。另一应用是与在数字电视信号的频道中当前被广播的电影相关的声音文件的下载。用户因而可以将电影的声轨(sound track)存储在该移动数据处理单元(例如MP-3播放器)上以便以后再次收听。这些仅仅是两个示例，本领域技术人员显而易见，很多有用的应用可被设想，其中附加数据的内容以有意义的方式补充数字电视信号的内容。

可以使用遥控器3来操作机顶盒100，该遥控器3与遥控传感器7交互以向机顶盒100的一个或多个中央处理单元(未示出)发布命令。可替换地或可附加地，机顶盒100还可以包括输入装置，例如按钮或开关(图1中未示出)。机顶盒100的显示器18允许向用户显示消息。

在机顶盒100的前端单元5中，从天线101提供的广播信号被解调。随后，利用数据过滤器6过滤出附加数据集合。数字电视信号进一步以标准方式被机顶盒100处理。在图1中，这仅仅由单元20示意性地指示，该单元20代表机顶盒100的标准音频和/或视频处理。

请注意存在很多实现数据过滤器6的方法，例如利用硬件或利用软件的方法。软件方案可能更灵活，使得机顶盒100容易适应新的数据格式，但是硬件方案可能更快速。而且，两种可选方式的组合也是可能的。此外，对接收到的信号(包括数字电视信号和附加数据集合两者)的初始解调的功能和随后的过滤可被组合在单个单元中，或者甚至可以在电视信号被解调之前，从接收到的信号中过滤出数据集合。

在附加数据集合已经被过滤出来之后，它被存储在存储器8中并且保持“等待”状态。存储器可以按很多不同的方式实现，例如作为RAM或甚至作为诸如盘驱动器或闪存ROM之类的永久性存储器。存储器8也可以只是机顶盒100的普通存储器范围的某个范围。附加数据集合一直保留在存储器8中，直到其被下载到移动数据处理单元200上(如下所述)或响应于用户的命令被擦除为止。此外，在机顶盒100中还可能包括计时器功能，以使得在预定时间量内尚未被下载的附加数据集合将被自动擦除或被新数据覆写。在更简单的实施例中，提取出的数据不被存储在机顶盒中，而是被立即发送到移动数据处理单元，如下所述。

为了通知用户关于用于下载到移动数据处理单元200上的附加数据的可用性，机顶盒100可以在其自己的显示器8上呈现消息，如图1示意性地示出的(“数据文件1信息...”)，或者该消息将被呈现在所连接的电视机102的屏幕上。而且，这两种显示功能的组合也是可能的，其中例如显示器18仅通知关于附加数据集合的一般可用性，而电视机102的显示器基于用户请求呈现关于数据集合的附加信息，例如与数据下载到移动数据处理单元200相关的内容、大小和可能成本。

被存储的附加数据集合从机顶盒100到移动数据处理单元200的实际转移可以由各种装置触发。一种选择是直接或经遥控器3在机顶盒100处的用户输入。在这种情况下，机顶盒100将尝试利用其收发机4建立到移动数据处理单元200的通信链路(优选地是无线链路)。这种收发机4例如可以被实现为红外端口，该红外端口与单元200的相应红外端口(图1中未示出)通信。在另一实施例中，使用RF信号，例如遵循蓝牙协议(参见下面的描述)。优选地，机顶盒100包括多于一种用于无线通信的可能性，从而使其可以灵活地适合于不同类型的移动数据处理单元200。最后，还可能利用经由电缆(未示出)的连接将包含数据的电磁信号传送到移动数据处理单元上。

可替换地，被存储的数据到移动数据处理单元200的转移还可以由单元200触发。在该替换实施例中，用户将简单地将单元200放置在发射机4的发送范围内，并向机顶盒100发送相应的请求，机顶盒100随后将发起被存储数据的下载。很明显，组合也是可能的，其中一方(机顶盒100或移动数据处理单元200)首先发送请求，该请求随后被另一设备处的用户输入确认以启动发送。

图2示意性地示出了根据本发明的方面的移动数据处理单元200。一般而言，存在很多可以结合本发明使用的移动设备，例如PDA、手持计算机、笔记本、MPEG-3播放器。但是，由于蜂窝电话是最常见的，并且蜂窝电话不仅允许处理接收到的数据，还允许通过通信网络(例如GSM网络或CDMA网络)传送关于被处理的数据的信号，因此以下描述将集中在为了与上述机顶盒100合作而对这种设备所作的修改。

蜂窝电话优选地包括两个收发单元，第一收发机15用于标准通信网络，例如GSM、GPRS或CDMA(UMTS)网络，而另一收发机9用于与机顶盒100的收发机4通信。第二收发机9可以被提供为红外端口和/或用于RF信号的蓝牙收发机。在优选实施例中，蜂窝电话200包括处理器和具有指令的存储器，从而收发机4将向机顶盒100发送传输可用数据的请求。当蜂窝电话开机时，来自蜂窝电话的请求可以响应于用户输入被发送或者自动被发送。在后一情况下，当蜂窝电话200与机顶盒100的收发机4足够靠近并且开机时，存储在机顶盒中的附加数据的下载将自动启动。这与利用个人计算机从因特网下载数据并随后将数据转移到蜂窝电话上以备后用的情况相比，对用户而言要容易得多。下载的数据被存储在蜂窝电话200中的存储器11中，数据在存储器11中可用于进一步的处理。

根据本发明更先进的方面，下载的数据可以包括交互特征，这种交互特征要求用户将信息从蜂窝电话200发回提供者(未示出)或数字电视信号的另一用户。例如，交互式游戏可能被很多用户在玩，其中一般信息和/或结果被广播在电视102上，并且其中每个用户利用他自己的蜂窝电话200通过蜂窝网络玩游戏。

由于交互式游戏(等)本身被提供者创建为包括在数字电视信号中的附加数据，因此对这种游戏或类似事件的总体设置对用户而言很容易，并且不需要特定的技术能力。蜂窝电话的其它功能单元，例如照相机或麦克风，可能在对接收自机顶盒100的数据的交互式处理中被涉及到。

在图2中，到蜂窝网络的连接由蜂窝电话200的数据过滤器12反映出。在蜂窝电话的处理器和操作系统等(未示出)的控制下，通过处理经收发机9接收的数据而得到的数据可以经由第一收发机15和附接的天线被发出。数据过滤器12确保该数据的发送不会干扰蜂窝电话的其它语音和数据服务17。

在本说明书中的以下部分中，将进一步描述本发明当前优选的实施例。另外，附录的两个关于“Blucom”接收机要求和“Blucom”浏览器应用的说明书将说明机顶盒100和在移动设备200或在本发明的上下文中使用的另一种移动数据处理单元上运行的浏览器应用的当前优选实施例的所有方面。但是，注意，实际实施例不需要实现下面或附录说明书中描述的所有特征。相反，某些实施例将仅使用下述系统的单个或一些方面。具体而言，所描述的大多数特征可以在独立于系统的其它特征的情况下被实现。

图3呈现出体系结构的概观。可以看出，内容提供者通过使用适当的创作系统来创建附加数据的内容。另外，广播者被示出，其负责根据所使用的数据轮播(carousel)格式对附加数据内容进行格式化，并将卷积数据发送到卫星。可替换地，卷积数据可以利用线缆网络或地面广播被广播。

包含电视信号和附加数据的卷积数字数据的传输流被数字接收机或机顶盒100所接收。数字接收机或机顶盒(STB)充当面向任意客户端设备(例如移动电话200)的内容服务器。附加数据从一个或多个数据轮播中被解析出来，所述数据轮播在传输流中以与任意MPEG节目的数据组分类似的方式被运载。STB将适当版本(见下文)的所有附加数据轮播的完整有效载荷存储在布置在STB的RAM中的缓存中。STB的缓存可以被视为被填充有来自卫星的数据的共享存储器资源。数据被数据服务器组件请求从缓存中读出，所述数据服务器组件专用于处理例如来自移动电话200的对附加数据的客户端请求。

缓存中的目录结构是根据从包含在传输流中的头部获得的路径和文件名信息的。该结构被用作针对客户端请求的引用。另外，数据轮播包括更多的信息，例如控制参数。对附加数据的数据轮播的更新(即新版本)通过合适的标识的改变被检测到。

更详细地，STB的缓存按如下方式被管理：一旦STB在实际调谐的MPEG节目上检测到有效的附加数据组分，STB就立即启动捕获附加数据并将其写入缓存。缓存在实际调谐的服务改变到运载附加数据的另一服务时被清除，并被填充以随后调谐的服务的附加数据。但是，如果新服务的标识与先前调谐的服务的标识匹配，STB则维持缓存，以便在数据在服务间共享的情况下，可以实现更好的性能。

如果为缓存预留的RAM空间不需要被完全分配用于存储新服务的附加数据，STB则可以保留先前的数据，以便如果STB被调谐回先前服务，可以加快访问。如果新服务没有提供附加数据，则先前下载的附加数据被保留在缓存中，以便在用户切换回先前调谐的服务的情况下，可以允许快速访问。

无论新服务是否运载附加数据，与某一服务或频道的附加数据相关的控制参数都在服务改变时立即被删除。这一规定确保了只有任意给定服务的附加数据是可用的。但是，如果新服务的标识与先前调谐的服务的标识匹配，STB则保留控制参数，以便在附加数据在服务间共享的情况下，可以实现更好的性能。

为了发送与附加数据相关的控制参数，控制文件优选地被包括在到STB的传输流中。控制文件的目的是要指定接收机对客户端的附加数据请求的反应。与具有将在无需任何在先解释的情况下被存储在接收机的文件系统中的内容的实际数据文件不同，STB需要在接收到控制文件之后，立即解析控制文件的内容并存储控制参数。

在从卫星发送来的轮播中，控制文件通过存在于各个数据头部中的控制文件描述符来标识。一旦STB在接收到的数据轮播中检测到新的控制文件，它就更新在接收机的RAM中的控制文件数据。针对下一客户端请求，STB根据新控制文件中确定的规则做出反应。在优选实施例中，控制文件基于XML文件格式。

STB 100和移动设备200(电话、PDA等)之间的通信依赖于硬件和接口协议。以下，将简要论述优选实施例。

如上所述，STB 100优选地包括能够利用蓝牙标准与移动设备200通信的接口。优选地，接口的性能确保在下面指示的条件下，对客户端请求的反应时间不超过所限定的界限。所述条件如下：

●只有一个客户端连接到STB。

●蓝牙数据速率500kb/s的网络。

●测量点是蓝牙无线电层。

●被请求的文件已经存在于STB的缓存中。

对于针对10kB文件的客户端请求，STB在发布客户端请求之后的250ms内完成整个文件的递送。

为了满足以上要求，STB的优选硬件包括将被分配给上述缓存的至少16 MB的存储量。对于与移动设备200的通信，STB优选地包括功率类2的蓝牙无线电设备，该设备在距离STB的前面板至少10米的距离上提供稳定连接。

STB 100和移动设备200之间的接口协议优选地也基于XML文件格式。为了使协议数据的量尽可能的小，推荐使用XML短形式(short-form)来建立XML协议。低层通信优选地基于蓝牙无线技术。图4示出用于访问在蓝牙协议栈顶部的附加数据的所述服务的协议的布置。

因此，为了建立移动设备200和STB之间的连接，移动电话上的蓝牙设备(未示出)需要被使能并准备好在启动通信软件(即“浏览器”)之前连接远程蓝牙设备。在启动浏览器之后，验证移动设备200的蓝牙设备是否被使能并准备好。如果没有可用的蓝牙设备或者如果蓝牙设备未被接通，浏览器则将建议用户如何接通蓝牙设备。

通过运行在移动设备200上的浏览器应用来起动蓝牙设备和服务发现。为了找到正确的设备，浏览器在每个被发现的设备上执行服务查询，以便确保移动设备仅连接到相应的应用。当发现多于一个设备提供了在STB上访问附加数据的服务时，蓝牙专用的用户友好设备名称的列表被呈现给用户以供选择。

在正确的设备(STB)被发现或被用户选择之后，浏览器尝试建立到其的连接。取决于STB侧的配置，可能需要输入认证id(PIN)以获得连接。在成功地连接到STB之后，如果远程设备支持正确的列表管理，则该远程设备需要被添加到被信任设备列表中，以避免在随后连接到该设备时重发pin请求。

在成功的设备和服务发现之后，浏览器优选地向STB发送初始请求，以获得与其在STB侧的对应部分相对照的版权字符串。在被配置的期满时段内收到否定响应或者甚至是丢失响应的情况下，浏览器显示表示STB未被授权访问附加数据的服务的消息。版权字符串是没有更深的意义的静态文本字符串。其仅仅是出于法律原因而需要的，并且可以由系统提供者定义。

在成功的连接之后，浏览器需要显示第一页面。因此，浏览器需要执行同步命令(下面将描述)以获得与STB提供的当前服务的同步。假设存在具有可用的附加数据的频道，则浏览器接收需要针对其取得并显示内容的URL。

以下，将进一步描述浏览器的内容获取。附加数据的内容可以由不同的内容提供者准备。提供者使用页面来从逻辑上组织内容。浏览器一次显示一个页面。每个页面被附接到特定上下文。上下文id针对从服务器取得的每个页面被递送。上下文对于页面请求和上下文变量的维护而言很重要。

内容被移动设备200从STB 100中取出。对于内容如何从STB中被取出，存在两种方式。

对于自动页面请求，浏览器根据刷新间隔自动请求来自服务器的新页面，所述刷新间隔在协议中被确定。该刷新间隔可以在每一后续页面或内容请求之后改变。所有自动页面请求被静静地执行：由于用户不触发获取，因此如果这些页面的请求、获取或处理失败，则可能不显示消息。

自动页面请求还使得内容提供者能够频繁地更新内容。要区分以下两种更新：

-提供者确定新的不同页面，该页面必须被浏览器尽快显示，例如以使得所显示的内容适合于频道中当前运行的电视节目。

-提供者生成对浏览器当前显示的页面的更新，该当前页面被显示以取代旧(过时)页面。

因此，哪个页面接下来将被显示完全受控于STB。除非与当前显示的页面相关的页面名称、页面版本和上下文没有改变，否则浏览器请求并显示STB指示的每个新页面。

另一方面，由于除非浏览器请求，否则STB不递送新页面，因此浏览器必须周期性地轮询服务器并请求页面更新。优选地，浏览器能够处理1秒或更短的查询间隔。优选地，刷新间隔为动态值。

除了自动页面请求之外，优选地，可以选择手动页面请求。用户可以通过选择当前显示的页面中的链接来异步地触发页面请求。浏览器尝试获取显示该页面所需的所有内容。所有手动页面请求被主动执行，即用户获得关于浏览器行为的可读且可视的反馈。如果被请求的页面由于差错而无法被显示，则显示差错消息。

图5呈现出五个不同命令的概观，这五个不同命令被用于移动设备200和STB 100之间的通信。

发起命令是针对所有进一步命令的前提。如果STB无法以OK应答发起命令，则所有后面的请求(除非有进一步的发起命令)都将被以返回码FAILED应答。

利用同步命令，浏览器向STB请求当前有效的同步页面URL，即存储在将与移动设备同步的STB中的数据。除了当前同步页面的URL之外，响应还递送关于当前上下文和新的刷新间隔的信息。返回码告知响应状态。一旦响应被成功地处理并且进一步的条件被实现，浏览器则获取新页面URL的内容以显示新页面。

利用刷新命令，浏览器发送在显示器上当前被显示的页面和当前同步页面(其可能不同于当前页面)的URL和文件版本。一旦对刷新命令的响应被成功处理并且进一步的条件被实现，浏览器就获取被递送的新页面URL的内容以显示新页面。返回码告知响应状态。

新页面可能是对当前显示的页面的更新或者被立即显示的新同步页面，如上所述。另外，响应码递送关于当前上下文的信息、新的刷新间隔和确定所提供的URL是否是同步页面的标志。在新页面被标记为同步页面的情况下，浏览器保存该URL和版本，作为其当前的同步页面。

进一步的命令“获取命令”用于向STB请求某一页面的内容，而第五命令“获取上下文”用于获得相关参数，例如STB当前被调谐到的当前服务的标识。

本发明的当前优选实施例的其它方面在两个附录中被描述。

附录：

“Blucom”接收机要求版本1.53a

功能规范“Blucom”浏览器应用版本1.6

《Blucom》

接收机要求

版本1.53a

2007-6-18

机密

责任/版权

版权bei APS，Astra Platform Services GmbH，

Betastraβe 1-9，D-85774 Unterfhring，

电话：+49(89)1896-03

2005年7月

该文件受版权保护，所有权利被保留。在未经APS明确书面许可的情况下，该文件不可被全文、部分或以修改版本形式复制或公开。

文档历史

版本	日期	作者	改变
				1.0	2005/03/15	Jrg Eich，Uwe Wiedow	文档创建
1.1	2005/03/25	Jrg Eich，Uwe Wiedow	应用层的会话处理不再需要，因此基于该主题的所有章节已被从文档中删除。此外，数据交换协议和某些应用流程图已据此被修改。第4.1节中添加了澄清和示例。第4.2.2节中添加了对在服务改变时删除控制参数的要求.第4.2.2节中添加了流程图。第4.4.1节中添加了对性能要求的描述.
				1.2	2005/04/05	Jrg EichUwe Wiedow	添加双轮播选项。添加mosaic要求.在通信协议中添加返回代码值“DATA_NOT_YET_AVAILABLE”；针对应用流程的图据此被改变。小更正。
1.3	2005/04/13	Jrg EichUwe Wiedow	在蓝牙章节中进行更正：在无格式RFCOMM顶部添加SPP。删除PMT描述符中的transaction_id(不需要，因为STB必须一直监听DSI)。通信协议中的GetCommand被改变；针对应用流程的图据此被改变。出于PDR要求而添加“提醒”。小更正.

1.4	2005/04/28	Jrg EichUwe Wiedow	用Blucom替代术语BluLink。第3和4.2.3节中介绍blucom_uid参数。将DSM-CC消息中的name_descriptors移到新创建的Blucom头部中。GetCommand被改变。添加GetContext命令。通信协议应用流程图被修订。从Blucom控制文件中删除上下文元素c。上下文值现在由blucom_data_descriptor(3)确定。小更正。
				1.5	2005/05/03	Jrg EichUwe Wiedow	属性“可视的”被添加到GetContext命令；Blucom协议差错处理被指定；用于blucom控制文件的xml图表被添加到附录；返回代码“NOT_TUNED”被添加到ContextResponse；GetCommand被改变；RefreshCommand被改变；blucom_data_descriptor中的nb_of_carousels参数被省略；小更正
1.5.2	2005/05/31	Uwe WiedowJrg Eich	STX和ETX被添加到通信协议(4.5.1.1)。RefreshResponse被改变：IsSyncPage属性已被从元素DisplayPage移到根元素RefreshResponse(4.5.4)；针对BLUCOM UUID的Hex值被更正。添加数据轮播的描述符.。轮播中对控制文件的引用被改变。小更正。
				1.5.2a	2005/06/01	Uwe Wiedow	IsSyncPage属性再次移到元素DisplayPage，此处其属于(4.5.4)；相应的应用流程据此被改变。
1.5.3	2005/07/18	Jrg EichUwe Wiedow	对UI要求的澄清，blucom数据头部中描述符的使用，以及模块的压缩。公司名从DPC改变到APS。注意：认证字符串被改变值“BLUCOM”不再指定UUID，而是指定基于串行端口轮廓(7.4)的服务的名称。
				1.5.3a	2005/07/22	Jrg Eich	在所有地方将DPC改为APS。

目录

1     介绍.......................................................24

1.1   文档目的...................................................24

1.2   受众.......................................................24

1.3   产品范围...................................................24

2     系统概述...................................................25

2.1   内容提供者.................................................25

2.2   广播中心...................................................25

2.3   机顶盒.....................................................26

2.4   浏览器应用.................................................27

3     TS-Blucom数据的信令........................................28

4     接收机软件要求.............................................30

4.1   数据轮播...................................................30

4.1.1 DSM-CC解析器的性能.........................................30

4.1.2  数据轮播结构..............................................30

4.1.3  数据轮播中的描述符........................................30

4.1.4 Blucom数据头部.............................................31

4.1.5 Blucom数据头部中的描述符...................................32

4.1.6 Blucom数据头部的示例.......................................34

4.2   Blucom缓存.................................................36

4.2.1 Blucom缓存分配.............................................36

4.2.2 Blucom缓存管理：数据捕获...................................36

4.2.3 Blucom缓存管理：服务改变...................................36

4.2.4 Blucom缓存管理：更新.......................................39

4.2.5 Blucom缓存管理：清除.......................................39

4.2.6 Blucom缓存管理：溢出例外处理...............................39

4.3   控制文件...................................................40

4.3.1   性能.....................................................40

4.3.2   格式.....................................................40

4.3.3   控制文件下载.............................................41

4.3.4   示例.....................................................41

4.4   移动设备接口...............................................42

4.4.1   性能.....................................................42

4.4.2   接口协议.................................................42

4.4.3   发起连接.................................................42

4.5   移动设备接口协议定义.......................................43

4.5.1   一般定义.................................................43

4.5.2   发起命令(InitiateCommand)................................47

4.5.3    同步命令(SyncCommand)...................................49

4.5.4    刷新命令(RefreshCommand)................................52

4.5.5    获取命令(GetCommand)....................................58

4.5.6    获取上下文(GetContext)..................................61

5      UI要求....................................................65

5.1    信息通栏标题..............................................65

5.2    当STB被调谐到根据PMT信令不提供Blucom数据组分的服务时，将不在信息通栏标题设置菜单中显示与Blucom相关的图标。.....................65

5.3    Mosaic....................................................65

6      硬件要求(蓝牙，缓存存储器大小)............................66

6.1    存储器....................................................66

6.2    蓝牙......................................................66

7      蓝牙实现方式要求..........................................67

7.1    蓝牙协议栈................................................67

7.2    网络拓扑..................................................67

7.3    通用访问轮廓(GAP)要求.....................................68

7.3.1    可视性设置..............................................68

7.3.2    设备名称................................................68

7.3.3    可连接模式..............................................68

7.3.4    设备类型和设备类别......................................68

7.3.5    安全性方面..............................................68

7.3.6  Blucom服务的安全性级别....................................69

7.3.7    配对....................................................70

7.3.8    新设备的访问............................................70

7.3.9    受信设备的访问..........................................70

7.3.10   设备数据库中的改变......................................71

7.3.11   总密钥(Passkey)推荐.....................................72

7.4    服务发现协议..............................................73

7.5    串行端口轮廓..............................................73

7.6    蓝牙认证..................................................73

8      有条件的访问要求..........................................74

9      PDR要求...................................................75

相关文档

[1]ISO/IEC 13818-1/ITU-T H.222.0″Information technology-Generic codingof moving pictures and associated audio information：Systems“

[2]ISO/IEC 13818-6“Information technology-Generic coding of moving picturesand associated audio information-Part 6：Extension for Digital Storage MediaCommand and Control”

[3]ETSI EN 300 468“Digital Video Broadcasting；Specification for Service In-formation(SD in DVB systems”

[4]ETSI EN 301 192“Digital Video Broadcasting；DVB specification for databroadcasting”

[5]Technical Specification-ASTRA DVB Mosaic Application for TV/Radio andData Channels

[6]Extensible Markup Language(XML)1.0(Third Edition)”W3C Recommenda-tion，http://www.w3.org/TR/REC-xml

[7]IETF RFC 1950(1996)：″ZLIB Compressed Data Format Specification version3.3″

惯用语

惯用语	用法
		DEFINE	类型，定义和列举
ObjectProperty	对象属性和方法
		Filename	文件名和分类的用户输入

缩写

缩写	意思
		BL	Blucom
DPC	数字播放中心
		PDA	个人数字助理
GSM	全球移动通信系统
		GPRS	通用分组无线电服务
HTML	超文本标记语言
		XHTML	可扩展的超文本标记语言
BCD	二进制编码的十进制
		DVB	数字视频广播
MPEG	运动图像专家组
		PMT	节目映射表
STB	机顶盒(等价表述：接收机)
		DSM-CC	数字存储介质-命令&控制
U-N	网络用户

规定表述的口头形式

口头形式	指示	等价表述
			将	要求	必须
将不	要求	必须不
			应该	推荐	推荐的做法是...
应该不	推荐	不推荐的做法是...
			可以	允许	允许...

不需要	允许	不需要...
			可以	可能性/能力	能够...
无法	可能性/能力	不能够...

1介绍

1.1文档目的

本文档指定了用于数字接收机(STB)的“Blucom”扩展的要求。

1.2受众

本文档针对希望在其产品中实现Blucom扩展的STB生产者。

1.3产品范围

Blucom扩展允许数字接收机捕获Blucom数据流，该Blucom数据流与任意数字TV或无线电服务一起被广播。

接收机将完整的Blucom数据缓存在其RAM中，以便在客户端请求时提供快速响应时间。

Blucom客户端(例如，像移动电话或PDA之类的手持设备)可以经由蓝牙无线连接连接到Blucom接收机并请求来自接收机的Blucom数据。

2系统概述

图1示出了总体Blucom体系结构的概观。

图1-Blucom体系结构概观

2.1内容提供者

内容提供者通过使用适当的创作系统来创建Blucom内容。

本文档中未覆盖其规范。

2.2广播中心

广播中心负责根据本文档中指定的数据轮播格式对Blucom内容进行格式化，广播数据轮播并根据本文档中指定的规范发信号。

2.3机顶盒

在Blucom系统的上下文中，数字接收机充当面向任意客户端设备的内容服务器。

Blucom数据被从一个或多个DSM-CC数据轮播中解析出，所述DSM-CC数据轮播作为任意MPEG节目的数据组分被运载在MPEG传输流中。STB将具有适当版本(参见3)的所有Blucom数据轮播的完整有效载荷存储在Blucom缓存中，该Blucom缓存被设置在STB的RAM中。

Blucom缓存可以被视为共享存储器资源，它被DSM-CC客户端填充以数据。数据被专用于处理客户端对Blucom数据的请求的数据服务器组件从Blucom缓存中请求读出。

Blucom扩展的接收机软件实现方式由STB制造者选择。APS不提供任何软件库，并且在Blucom扩展的上下文中不要求任何中间件实现方式。

但是，本文档中所描述的要求必须被制造者的实现方式所满足，并将由APS或APS的转包商进行测试，并且在通过成功的测试之后，被APS授予合格证书。

图2示出了功能性接收机软件结构的概观。

图2-功能性接收机软件结构概观

针对Blucom扩展的接收机要求的功能性规范被本文档所覆盖。

2.4浏览器应用

浏览器应用通常运行在手持设备上。其建立手持设备和STB之间的连接，并经由所建立的链接从STB请求Blucom数据。Blucom数据将被浏览器应用处理和显示。

其规范未被本文档所覆盖。

3 TS-Blucom数据的信令

任意MPEG节目的PMT中的流循环可以包含对运载相关Blucom数据的一个或多个基本流的引用(通过基本PID字段)。Blucom数据流的流类型被设置为0x0B以指示Blucom数据流包含DSM-CC U-N消息，如[2]中指定的。

对Blucom数据流的流引用包含private_data_specifier_descriptor，如[3]中所指定的，其中private_data_specifier字段被设置为0x00000001(SES)。紧随该pri-vate_data_specifier_descriptor之后的是blucom_data_descriptor，其中私有数据字段长度为0。

给定的MPEG节目可以包含多于一个Blucom数据轮播，以允许针对特定数据(例如控制文件和实际同步页面)的独立更新和高速循环。如果MPEG节目运载多于一个具有适当版本的Blucom数据轮播，则STB将解析所有这些Blucom数据轮播。

注意：该信令方法必须针对传统接收机群体被验证。它可以被改变，直到该验证过程完成。

语法	位数	标识符
			blucom_data_descriptor(){descriptor_tagdescriptor_lengthblucom_versionblucom_uid{blucom_uid_onidblucom_uid_tsidblucom_uid_sid}for(i＝0；i＜N；i++){private_data_byte}}	8881616168	uimsbfuimsbfuimsbfuimsbfuimsbfuimsbfuimsbf

表1：Blucom_Data_Descriptor的语法

Blucom_Data_Descriptor的语义：

descriptor_tag：这个8位字段标识blucom_data_descriptor并将被设置为0xD0。

descriptor_length：这个8位字段指示紧接在descriptor_length字段后面的描述符的数据部分的字节数目。

blucom_version：这个8位字段定义所引用的Blucom数据轮播的版本。接收机将只在版本号被设置为0x01的情况下解析Blucom数据流。

blucom_uid：这个字段由3个16位字段构成，并希望作为每个Blucom服务的唯一标识符，其中每个Blucom服务可以由一个或多个Blucom轮播构成。一个Blucom服务的所有轮播将具有同样的blucom_uid。

blucom_uid将被唯一地分配。因此，该字段将由作为数据组件运载Blucom轮播的服务之一的原始网络ID、传输流ID和服务ID构成。

示例：

ONID：0x0085

TSID：0x0001

SID：0x001B

合成的blucom_uid：0x00850001001B

该字段的目的是允许一个或多个Blucom轮播在给定传输流上的若干服务之间共享，同时保持最优性能。在操作者在同一传输流上提供例如3个电影频道的情况下，他可能希望在这3个频道之间共享相同的Blucom数据。在此情况下，他将在所有3个电影服务的PMT中引用相同的Blucom PID。STB通过评估blucom_uid而知道它是否将删除控制参数并清除Blucom缓存，或者它是否将保留数据以便允许在服务改变时共享的Blucom服务有更好的性能。

private_data_byte：这是一个8位字段，该字段的值被私下定义。

4接收机软件要求

4.1数据轮播

4.1.1DSM-CC解析器的性能

DSM-CC解析器在后台将一直是活动的。

STB将能够捕获速率高达6Mb/s的Blucom数据流，而不会影响接收机的总体性能(即A/V解码，UI响应时间，广告跳过性能，图文电视处理)，并且不会丢弃一轮轮播中的任何Blucom数据模块和控制参数，假设关于轮播的所有结构信息(例如DSI和DII)都已获得。

如果Blucom服务被分成多于一个轮播，则6Mb/s的性能要求将应用于所有轮播的总比特速率。

4.1.2数据轮播结构

Blucom数据轮播基于DVB数据轮播规范，如[4]所定义的。

Blucom数据轮播被格式化为两层数据轮播，并且据此使用以下3种消息类型：

DDB-下载数据块

DII-下载信息指示

DSI-下载服务器发起

所有Blucom消息都在单个PID上被运载。

Blucom数据文件被构造为模块，这些模块在一个或多个DDB消息中被发送。模块被DH消息所引用。在一个DH中被引用的所有模块构成一组，该组通过DII消息的事务ID来标识。由相关的DII消息的事务ID标识的组在一个DSI消息中被引用。DSI消息中的组ID等于DII消息的事务ID。所有Blucom数据文件将被存储在专用的Blucom目录(例如“/blucom”)下，该目录将是所有Blucom相关操作的根。

Blucom服务所需要的DSM-CC消息在附录A中描述。

4.1.3数据轮播中的描述符

Blucom数据轮播支持在[4]中指定的将被STB评估的以下描述符的子集。每个描述符的语法和语义在附录A中描述。

●描述符：crc32 descriptor

  支持：强制的

  位置：DII-模块信息

  用途：该描述符将被STB评估，以确保数据模块已被正确地接收。如果在该描述符中接收的CRC 32与从相应的数据模块计算出的CRC 32不匹配，则该数据模块将被丢弃并在下一轮轮播时被重载。

●描述符：compressed_module_descriptor

  支持：强制的

  位置：DII-模块信息

  用途：当检测到该描述符时，STB将在进一步处理数据(即评估blucom头部)并将数据部分存储在blucom缓存中之前，对相关模块进行解压缩。

注意：控制文件将绝不被压缩。

●描述符：group_link_descriptor

  支持：强制的

  位置：DSI-群组信息

  用途：该描述符将被STB评估，以支持大群组。当群组中的模块的描述超过单个DII消息的最大尺寸并且不得不被扩散到多个这样的消息时，该描述符被轮播发生器使用。

●描述符：name_descriptor

  支持：可选的

  位置：DSI-群组信息

  用途：该描述符运载顶层目录的名称，相应群组的所有文件都被存储在顶层目录下，resp.将被存储在blucom缓存中。STB可以评估该描述符，以优化blucom缓存管理。

4.1.4Blucom数据头部

根据表2指示的结构，Blucom数据头部在所有Blucom文件之前。在接收到完整的模块时，STB将Blucom头部与有效载荷剥离，评估Blucom数据头部信息并根据Blucom数据头部中提供的信息来处理有效载荷(排除Blucom数据头部之外)。

语法	字节数
		blucom_data_header(){
blucom_version	1
		blucom_info_length	2
for(I＝0；I＜N；I++){blucom_info_byte}	1

语法	字节数
		private_data_length	2
for(I＝0 ；I＜N；I++){private_data_byte}	1
		}

表2：Blucom数据头部语法

Blucom数据头部的语义：

blucom_version：该字段在Blucom版本1.0中将被设置为0x01。STB将只处理blucom_version字段被设置为0x01的文件。

blucom_info_length：该16位的字段指示循环跟随的描述符的字节长度。

blucom_info_byte：该字段包括描述符的列表，其中每个描述符定义在实际模块中传输的Blucom文件的一个或多个属性。

对于Blucom数据文件而言，该字段至少运载指示相关文件的文件名信息和完整路径的name_descriptor。如果该字段没有运载name_descriptor，则STB将不会把相关文件视为Blucom数据文件。

对于Blucom控制文件而言，该字段将至少包含control_file_descriptor。如果Blucom头部不包含name_descriptor或control_file_descriptor，则STB将不处理相关模块中所传输的文件。这种规定将允许头端系统以后使用附加描述符而不会影响任何遗留STB。

private_data_length：该字段定义了后面的私有数据字段的字节长度。STB将忽略任何后面的私有数据字节。

private_data_byte：这些字段是用户定义的，并且将不被STB所评估。

4.1.5Blucom数据头部中的描述符

4.1.5.1名称描述符

对于Blucom数据文件，根据表3中提出的语法，Blucom数据头部将至少包含名称描述符。未在本文档中定义的blucom数据头部中的附加描述符将被STB所忽略。

name_descriptor(){	字节数	值
			descriptor_tag	1	0x02
descriptor_length	1

for(I＝0 ；I＜N；I++){text_char}	1	文件名和全路径信息
			}

表3：名称描述符的语法

名称描述符的语义：

descriptor_tag：该8位字段标识描述符。对于name_descriptor，该字段被设置为0x02。

descriptor_length：该8位字段指定紧跟在该字段之后的描述符的字节数。

text_char：这是一个8位字段。“char”字段中的字符串指定STB文件系统中的相关文件的文件名和路径信息，所述路径信息将被用作相对于Blucom根目录的存储位置。利用[3]的附录A中描述的方法和字符集合对文本信息编码。

4.1.5.2控制文件描述符

Blucom控制文件将由Blucom数据头部中的control_file_descriptor所指示。如果在blucom数据头部中存在附加描述符，则这些将被STB所忽略。

control_file_descriptor的出现总是表示跟在blucom数据头部之后的模块有效载荷作为控制文件数据。

control_file_descriptor(){	字节数	值
			descriptor_tag	1	0x01
descriptor_length	1
			for(I＝0；I＜N；I++){descriptor_data}	1
}

表4：control_file_descriptor的语法

control_file_descriptor的语义：

descriptor_tag：该8位字段标识描述符。对于control_file_descriptor，该字段被设置为0x01。

descriptor_length：该8位字段指定紧接在该字段之后的描述符的字节数。该字段可被设置为0，以指示没有跟随的描述符字节。

descriptor_data：该字段可以包含多个描述符字节，如descriptor_length字段所指示的。

4.1.6Blucom数据头部的示例

图3中的示例将示出Blucom数据文件的Blucom数据头部的格式。

图3-Blucom数据头部的示例

一旦接收到完整模块，STB将有效载荷部分与头部剥离，并将有效载荷部分保存在以下位置：/blucom/tv_show/pic/picl.png，其中/tv_show/pic/picl.png指定Blucom GetRequest(4.5.5)中的Blucom名称。在该示例中，假设STB的Blucom根目录被命名为/blucom。

示例GetRequest：

<GetRequest

  requestId＝″00-02-72-80-EC-FE-00004″

  context＝″0x00850001001B″>

  <FileUrl name＝″/tv_show/pic/picl.png″version＝″1″/>

</GetRequest>

4.2Blucom缓存

为了允许任意被连接的客户端设备快速访问Blucom数据，STB将所有Blucom数据缓存在Blucom缓存中。Blucom缓存可被视为数据轮播捕获和客户端数据服务器之间的链接元件。在该方面，它可被视为共享的存储器资源。

Blucom缓存中的目录结构将根据从Blucom头部获得的文件名和路径信息。该结构被用作对客户端请求的引用。

从广播轮播侧，维护Blucom缓存所需的信息是每个文件的群组ID、模块ID和模块版本。

Blucom数据轮播的更新将根据DSI的事务id的变化被检测到。

4.2.1Blucom缓存分配

Blucom缓存将被分配在STB的RAM中。

Blucom数据缓存大小将由第6.1节指定。

4.2.2Blucom缓存管理：数据捕获

一旦STB检测到实际调谐的MPEG节目上的有效的Blucom数据组分(根据第3章)，STB就将立即启动捕获Blucom数据并将其写入Blucom缓存。

4.2.3Blucom缓存管理：服务改变

Blucom缓存将在实际调谐的服务改变到运载Blucom数据的另一服务时被清除，并被填充以随后调谐的服务的Blucom数据。

例外：如果新服务的blucom_uid与先前调谐的服务的blucom_uid匹配，则STB将保持Blucom缓存，以便在Blucom数据在服务之间共享的情况下实现更好的性能。

注意：如果为Blucom缓存预留的RAM空间不需要被完全分配用于存储新服务的Blucom轮播数据，则STB可以保留先前的Blucom数据，以便在STB被调谐回先前Blucom服务的情况下加速数据访问。

如果新服务不支持Blucom，则先前下载的Blucom数据将被保留在Blucom缓存中，以便在用户调谐回先前调谐的Blucom服务的情况下实现快速访问Blucom数据。

Blucom控制参数将在服务改变时被立即删除，无论新服务是否运载Blucom数据。该规定将确保如果STB实际被调谐到所述服务，则任意给定服务的Blucom数据只能被移动设备并从而被用户获得。

例外：如果新服务的blucom_uid与先前调谐的服务的blucom_uid匹配，则STB将保留Blucom控制参数，以便在Blucom数据在服务间共享的情况下实现更好的性能。

在服务改变时所需的Blucom缓存和控制参数管理如图4和图5所示。

图4-在服务从Blucom服务改变时的Blucom缓存管理

图5-在服务从非Blucom服务改变时的Blucom缓存管理

4.2.4Blucom缓存管理：更新

存储在接收机的Blucom缓存中的Blucom数据文件将在相关模块的模块版本号改变时被更新。

被加载在Blucom缓存中的所有Blucom文件的模块版本号必须被STB保留，以允许：

a)针对被缓存的Blucom文件的高性能更新过程

b)重新使用模块版本作为用于服务于移动设备接口的透明版本信息。如果在模块更新(即模块版本号改变)时在Blucom头部中指示的存储位置改变，则STB将删除旧文件并将更新后的文件存储在新存储位置中。

在Blucom缓存中的文件删除后留下的任意空目录将被从Blucom缓存中删除。

4.2.5Blucom缓存管理：清除

一旦Blucom数据文件(即相关模块id)不再在相关DII中被引用，该Blucom数据文件就将从接收机的Blucom缓存中被清除。

一旦相关群组ID不再在相关轮播的DSI中被引用，具有该群组ID的所有Blucom数据文件将从Blucom缓存中被清除。

在清除操作后留下的任意空目录将从Blucom缓存中被删除。

注意：这要求在任意时刻来自头端系统的数据有效载荷是一致的。

4.2.6Blucom缓存管理：溢出例外处理

如果在实际调谐的Blucom服务的上下文中广播的Blucom数据的量大于所定义的Blucom缓存尺寸，则STB将丢弃Blucom缓存中的最旧数据。Blucom数据的年龄的确定将通过评估存储时间戳来完成。

例外：实际同步页面在被实际控制参数集合引用时将不被丢弃。

该规定的意图在于确保接收机在过大的轮播被播出的情况下不会崩溃。但是，在此情况下，Blucom服务的可用性将是无法预测的。因此，头端系统将确保Blucom服务的总有效载荷绝不超过6.1中指定的界限。

4.3控制文件

控制文件的目的是要指定接收机对于客户端针对Blucom数据的请求的反应。与将被存储在接收机的文件系统中而无需任何在先解释的Blucom数据文件不同，STB需要在接收到控制文件之后立即解析控制文件的内容并存储控制参数。在轮播中，控制文件是通过Blucom数据头部中control_file_descriptor的存在来标识的。

一旦STB检测到Blucom数据轮播中的新控制文件，它就将更新接收机的RAM中的控制文件数据。一旦有下一客户端请求，STB将根据新控制文件确定的规则来做出反应。

4.3.1性能

STB将在接收到新控制文件之后立即解析该控制文件并存储和激活相应参数。

4.3.2格式

Blucom控制文件基于XML文件格式。

以下，简要的XML图表描述示出了Blucom控制文件的结构。

4.3.3控制文件下载

控制文件必须从被解析的数据频道轮播(参见4.1)中被下载，并且所获取的设置必须被存储在内部变量中，以便用于Blucom协议。

在实际调谐的Blucom服务(参见3)的PMT中的blucom_data_descriptor中所引用的blucom_uid将被分配作为上下文。

如果实际被调谐的服务不包含Blucom数据组分，则上下文将是空字符串。

图6-来自数据轮播的应用流程“加载控制文件”

4.3.4示例

<？xml version＝″1.0″encoding＝″UTF-8″？>

<BlControl

  xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

  xsi：noNamespaceSchemaLocation＝″blucomctrl.xsd″>

   <SyncPage na＝″/index.htm″fd＝″1″ri＝″10000″/>

</BlControl>

4.4移动设备接口

4.4.1性能

移动设备接口性能定义将确保在预定条件下，对客户端请求的反应时间不超过所定义的界限。

条件：

●只有一个客户端被连接到STB。。

●BT数据速率500kb/s的网络。

●测量点是蓝牙无线电层。

●被请求的文件已经存在于STB的Blucom缓存中。

对于针对10kB文件的客户端请求，STB将在发布该客户端请求之后250ms内完成整个文件的递送。

如果在原型的实现期间发现所需性能无法通过任何技术上合理的实现方式所达到，则该性能要求可以据此被改变。但是，STB实现方式将确保达到最高的可能性能。

4.4.2接口协议

机顶盒(STB)和移动设备之间的接口协议基于XML文件格式。所有xml标签将根据[6]建立。为了保持协议数据量尽可能的小，推荐使用XML短形式来建立XML协议。

示例性长形式：

<InitiateResponse requestId＝”00-02-72-80-EC-FE-00001”retCode＝″OK″>

</InitiateResponse>

示例行短形式(推荐的)：

<InitiateResponse requestld＝”00-02-72-80-EC-FE-00001”retCode＝″OK″/>

协议定义在4.5中提出。低层通信基于蓝牙无线技术。对蓝牙实现方式的要求在7中描述。

4.4.3发起连接

移动设备发起到STB的通信信道。在完成设备和服务发现之后，移动设备调用初始请求来递送版权字符串，该版权字符串必须匹配存储在STB应用中的对应部分。STB本身通过发送返回代码来做出反应，该返回代码表明接受还是拒绝移动设备连接请求。

4.5移动设备接口协议定义

存在五种不同命令，它们在以下部分中被描述。

4.5.1一般定义

4.5.1.1标记命令

每个BLUCOM命令将开始于引导的Start Text(STX)字节并结束于End Text(ETX)字节。

相应值被定义：

■对于STX字节：0x02

■对于ETX字节：0x03

示例：

ff02<InitiateRequest

requestId＝″00-02-72-80-EC-FE-00001″

cprString＝″Copyright by APS，ASTRA Platform Services

GmbH″/>ff03

为了避免与二进制内容中的值有任何冲突，STB将在每个STX或ETX字节之前放置附加的0xff字节。关于二进制内容中的每个常规oxff，STB在这些字节前面放置另一0xff字节。

示例：

二进制代码序列(4字节)：0x01 0xa0 0xff 0x40

将被STB改变到(5字节)：0x01 0xa0 0xff 0xff 0x40

注意：

关于BLUCOM获取命令(4.5.5)，获取响应(GetReponse)命令的长度属性始终指定不包括所有扩展的oxff字节的原始内容的长度(字节数)。

关于BLUCOM命令评估，STB可以使用字节组合0xff 0x02(STX序列)来检测由移动设备发送的BLUCOM命令的开始，并用组合0xff 0x03(ETX序列)来检测当前处理的BLUCOM命令的结束。

在STB检测到不期望的STX序列或oxff之后的无效后继字节的情况下，所收集的针对当前处理的命令的所有数据可被丢弃，并且STB将启动对新STX序列的监听。

4.5.1.2请求Id

每个Blucom命令包含请求Id，该请求Id对于由连接的移动设备发送的所有命令而言是唯一的。当建立对从移动设备接收的相应请求的响应部分时，STB将使用相同的请求Id。

4.5.1.3同时请求

STB将能够存储每个被连接的设备的最多10个传入请求。STB将按照与请求被移动设备发送并被STB接收相同的顺序对每个请求做出响应。

为了对于每个被连接的移动设备存储10个请求(这意味着对于7个同时被连接的设备有最多70个请求)，需要STB预留至少50kB的RAM空间。

4.5.1.4情况敏感性

所有属性值(包括URL和内容文件名)都是对情况不敏感的。

4.5.1.5Blucom URL/文件名

对于在所有Blucom命令中找到的所有Blucom URL和内容文件名的最大长度被设置为256字节。

4.5.1.6协议处理

指定STB将如何对不完整或不正确的Blucom命令做出反应。

■不完整的xml命令

STB在当前处理的命令的结束标签被检测到之前发现新的开始标签。

反应：

如果STB能够识别请求Id和命令类型，则对应于命令类型的命令响应retCode＝”FAILED”将被返回，并且不完整的命令将被丢弃。否则，STB将在不发送响应的情况下丢弃不完整的命令。

■未知属性

STB在完整的Blucom命令中检测到未知属性。

反应：

STB忽略所有未知的属性。

■丢失所需属性

如果STB能够识别请求Id和命令类型，则对应于命令类型的命令响应retCode＝”FAILED”将被返回，并且不完整的命令将被丢弃。否则，STB将在不发送响应的情况下丢弃不完整的命令。

■语法错误

STB在Blucom命令中发现一个或多个语法错误。

反应：

如果STB能够识别请求Id和命令类型，则对应于命令类型的命令响应retCode＝”FAILED”将被返回，并且不完整的命令将被丢弃。否则，STB将在不发送响应的情况下丢弃不完整的命令。

4.5.1.7DATA_NOT_YET_AVAILABLE与DATA_NOT_AVAILABLE

Blucom协议区分两种内容不可用性的状态。

DATA_NOT_AVAILABLE意思是所请求的内容不可用。如果实际调谐的服务的所有Blucom数据已被下载到缓存，但是请求的文件未存在于缓存中，则通常发生这种情况。

DATA_NOT_YET_AVAILABLE意思是所请求的内容当前不可用，但很快可能就可用了。如果实际调谐的服务的Blucom数据尚未完全下载到STB的Blucom缓存中，即存在所请求的文件是剩余轮播数据的一部分的可能，则通常发生这种情况。这还适用于Blucom数据轮播的更新。

4.5.1.8父辈控制

在任意情况下，即，即使实际服务的视频和音频呈现由于父辈控制实现方式被阻挡，STB也将继续分别启动在后台中的Blucom数据的缓存和更新。

根据本说明书，与针对视频和音频呈现的任何阻挡规则无关，STB将在所有时刻服务于移动设备接口。

4.5.2发起命令(InitiateCommand)

移动设备发送发起请求(InitiateRequest)，该发起请求将被STB使用发起响应(InitiateResponse)来应答。

备注：

发起命令将被看作所有进一步的blucom命令的前提。如果STB无法以retCode＝OK应答发起请求，则所有后面的请求(除了发起请求)将被以retCode＝FAILED应答。

示例：

<InitiateResponse

   requestId＝″00-02-72-80-EC-FE-00001″retCode＝″OK″/>

图7-应用流程“发起命令”

4.5.3同步命令(SyncCommand)

发送同步请求的目的在于使移动设备与上一Blucom控制文件提供的当前同步页面同步。

示例：

   <SyncRequest

      requestId＝″00-02-72-80-EC-FE-00002″

context＝″0x00850001001B″/>

备注：

同步页面元素是可选的，并且对于retCode不等于“OK”，可以不被填充。

示例：

<SyncResponse

   requestId＝″00-02-72-80-EC-FE-00002″

   retCode＝″OK″

   context＝″0x00850001001B″

   refreshInterval＝″10000″>

   <SyncPage name＝″/index.htm″version＝″1″/>

</SyncResponse>

图8-应用流程“同步命令”

4.5.4刷新命令(RefreshCommand)

发送刷新请求的目的在于向STB请求当前显示的页面的新版本。STB将递送接下来将显示的页面URL。它可以是被请求的页面的当前版本或者由Blucom控制文件提供的当前同步页面(参见以下应用流程)。

示例：

<RefreshRequest

   requestId＝″00-02-72-80-EC-FE-00003″

   context＝″0x00850001001B″>

  <RefreshPage name＝″/link1.htm″version＝″1″/>

  <Syncpage name＝″/index.htm″version＝″2″/>

</RefreshRequest>

备注：

显示页面元素是可选的，并且对于retCode不等于“OK”，可以不填充。

示例：

<RefreshResponse

  requestId＝″00-02-72-80-EC-FE-00003″

  retCode＝″OK″

  context＝″0x00850001001B″

  refreshInterval＝″10000″/>

    <DisplayPage

       name＝″/link1.htm″version＝″2″isSyncPage＝″0″/>

</RefreshResponse>

图9-应用流程“刷新命令”

4.5.5获取命令(GetCommand)

发送获取命令的目的在于向STB请求由元素FileUrl递送的某一页面的内容。

备注：

版本属性是可选的。如果其被省略，则STB将递送针对当前可用版本的内容。否则，STB将仅在其当前版本不等于FileUrl元素递送的版本的情况下发送内容(参见应用流程)。

示例：

<GetRequest

  requestId＝″00-02-72-80-EC-FE-00004″

  context＝″0x00850001001B″>

  <FileUrl name＝″/pic/picl.png″version＝″1″/>

</GetRequest>

备注：

文件数据(FileData)元素是可选的，并且对于retCode不等于“OK”或者retCode等于“DATA_UP_TO_DATE”的响应，可以不被填充。

如果在GetRequest的FileUrl元素中省略了可选属性“版本”，则DATA_UP_TO_DATE将不再返回。

在retCode＝“OK”的情况下，数据块被存储到文件数据元素的文本节点中。数据块的第一字节紧接在结束文件数据元素的属性列表的“＞”符号之后。

注意：

长度属性总是指定根据4.5.1.1.不包括所有扩展的oxff字节的原始内容的长度(字节数)。

示例：

<GetResponse

  requestId＝″00-02-72-80-EC-FE-00004″

  retCode＝″OK″

  context＝″0x00850001001B″

  refreshInterval＝″10000″>

  <FileData

     name＝″/pic/picl.png″

     version＝″1″

     length＝″1000″>

     <！-data block according to attribute″length″→

  </FileData>

</GetResponse>

图10-应用流程“获取命令”

4.5.6获取上下文(GetContext)

发送获取上下文命令的目的在于向STB请求当前的Blucom上下文。另一目的是取得与STB当前被调谐到的服务相对应的服务ID、传输流ID和原始网络ID的DVB值。除了该三元组之外，还返回一个标志(可视的)以显示当前服务在TV屏幕上是否是可视的。例如如果当前服务被串扰(scramble)或者智能卡未被授权解密服务的ECM，则该当前服务可能是不可视的。后者的值在任何情况下都必须独立于该服务上可用的现有Blucom服务被发回。

示例：

<ContextRequest requestId＝″00-02-72-80-EC-FE-00005″/>

备注：

在任何情况下，STB必须独立于频道上的现有Blucom服务递送onid、tsid、sid的值和可视标志。在丢失Blucom服务的情况下，Blucom上下文的值可被省略。

示例：

<ContextResponse

  requestId＝″00-02-72-80-EC-FE-00005″

  retCode＝″OK″

  onid＝″0x0085″

  tsid＝″0x0001″

sid＝″001B″

visible＝″1″

context＝″0x00850001001B″/>

图11-应用流程“获取上下文”

5UI要求

5.1信息通栏标题

如果STB被调谐到正在根据PMT信令提供Blucom数据组分的服务并且存在实际连接到STB的一个或多个Blucom客户端，则将在信息通栏标题中显示“带有活动客户端连接的Blucom图标”如附录C所示。

如果STB被调谐到正在根据PMT信令提供Blucom数据组分的服务并且并且不存在实际连接到STB的Blucom客户端，则将在信息通栏标题中显示“不带有活动客户端连接的Blucom图标”如附录C所示。

5.2当STB被调谐到根据PMT信令不提供Blucom数据组分的服务时，将不在信息通栏标题设置菜单中显示与Blucom相关的图标。

接收机的设置菜单将包含蓝牙设置条目，该条目至少允许改变以下设置：

引用	格式	动作	缺省值	项目名(将被显示在STB UI中)
					设备名称	Char[248]	改变设备名称	将由STB制造商定义	BluetoothGertename
可视性	可发现的|不可发现的	改变模式	可发现的	Für andereBluetooth Gertesichtbar(ja|nein)
					成对设备列表	设备名称列表	删除所选设备	-(空)	GekoppelteGerte
蓝牙授权	开|关	改变模式	开	AuthentisierungvonMobilfunkgerten(ein|aus)

注意：在上表中将被显示在STB的菜单中的项目名显示了针对德语市场的文本。针对其他市场的翻译将在需要时被手工协定并添加到本说明书中。

5.3Mosaic

STB的导航器将支持mosaic信令，如[5]中SES Astra所指定的。STB mosaic实现方式将符合[5]中指定的强制要素。

Mosaic特征将允许支持Blucom服务入口，该Blucom服务入口提供各种Blucom服务，其中每个服务作为带有至少包含静态图片的视频组分的MPEG节目的一部分被广播。对这些Blucom服务的访问将通过mosaic导航功能来实现，所述mosaic导航功能在一个或多个mosaic服务上通过信号被发送。

6硬件要求(蓝牙，缓存存储器大小)

该部分描述STB为了支持Blucom服务而将达到的最低硬件要求。

6.1存储器

STB将为Blucom缓存分配16MB RAM的存储量。

6.2蓝牙

STB将提供功率类2的蓝牙无线电设备，该设备将在距离STB的前面板至少10米的距离上提供稳定的连接。

7蓝牙实现方式要求

7.1蓝牙协议栈

STB将支持蓝牙协议栈中在图12中被标记为红色的那些元素，以便支持Blucom扩展。但是，STB制造商可以自由地支持其他蓝牙相关协议和服务，只要在本文档中提到的Blucom性能要求和有条件的访问要求不受到影响即可。蓝牙相关实现方式将满足蓝牙特殊兴趣组(Bluetooth Special Interest Group)的实际蓝牙规范。

图12-Blucom需要的蓝牙协议元素

7.2网络拓扑

STB将同时处理7个客户端连接，这反映了一个Piconet的大小。

7.3通用访问轮廓(GAP)要求

7.3.1可视性设置

当STB被开启时，根据其可视性设置，它将是可发现的。显而易见，当STB被调谐到不运载任何Blucom数据的服务时，根据其可视性设置，它也将是可发现的。

对于Blucom实现方式，设备发现由客户端设备来初始化。

7.3.2设备名称

设备名称将可以由用户在STB的设置菜单中改变。STB将支持最多248个字符的蓝牙设备名称。

7.3.3可连接模式

当STB被开启时，它将一直是任意客户端设备都可连接的。显而易见，当接收机被调谐到不运载任何Blucom数据的服务时，它也将处于可连接模式。

7.3.4设备类型和设备类别

这些参数将在原型开发期间与STB制造商协定。

7.3.5安全性方面

STB将支持蓝牙安全性模式2，即服务级强制的安全性将应用。

在STB中实现的蓝牙栈将包括图13中所述的蓝牙安全性模型。

图13-蓝牙安全性体系结构

安全性管理器将执行以下任务：

●存储关于服务的安全性相关信息

●存储关于设备的安全性相关信息

●利用协议实现方式或应用应答访问请求

●在连接到应用之前强制进行认证和/或加密

●发起或处理来自用户接口的输入，以建立设备级别上的受信关系

●由用户发起配对和查询PIN条目。

7.3.6Blucom服务的安全性级别

Blucom服务的安全性级别将根据STB的设置菜单条目“蓝牙授权”中的设置被设置。

设置菜单设置

Blucom服务安全性级别

蓝牙授权＝“开”	需要授权和认证
		蓝牙授权＝“关”	服务对所有设备开放，不需要认证

7.3.7配对

STB将是可以配对的，即它将维护安全性管理器的设备数据库中的受信设备列表。

如果STB的设置菜单中的蓝牙认证设置被改变，这将不会影响存储在安全性管理器的设备数据库中的信息。

7.3.8新设备的访问

在此上下文中，术语“新设备”意思是未被存储在安全性管理器的设备数据库中作为受信设备的设备。

情况1-当在设置菜单中蓝牙授权被设置为“开”时应用：

当客户端设备第一次连接到STB时，安全性管理器将触发PIN代码(即通过密钥)输入对话框的呈现，该对话框请用户输入与他以前在其移动设备中用于认证所使用的PIN代码相同的PIN代码。一旦客户端设备根据该情况1被成功配对，设备信息和相应的链路密钥则将被存储在安全性管理器的设备数据库中，作为受信设备。

情况2-当在设置菜单中蓝牙授权被设置为“关”时应用：

当客户端设备连接到STB时，蓝牙栈将接受连接请求而无需任何蓝牙层上的认证并且无需咨询安全性管理器的设备数据库的情况下。在该情况2下，没有客户端设备信息将被存储在安全性管理器的设备数据库中。

7.3.9受信设备的访问

如果已经在安全性管理器的设备数据库中被列为受信设备的客户端连接到STB并且在STB的设置菜单中蓝牙授权被设置为“开”，则将在无需用户交互(即无需输入PIN代码)的情况下进行认证。

图14示出了受信设备的访问的信息流序列。

图14-来自受信设备的访问的信息流

在受信设备的连接请求序列期间，以下步骤被执行：

1.连接请求到L2CAP

2.L2CAP请求访问来自安全性管理器的数据

3.安全性管理器：在服务数据库中查找

4.安全性管理器：在设备数据库中查找

5.取决于服务数据库设置，安全性管理器强制进行认证和加密

6.安全性管理器授权访问

7.L2CAP继续建立连接。

7.3.10设备数据库中的改变

当用户在设置菜单中从受信设备列表中删除客户端设备时，STB将刷新与该设备相关的所有密钥，以避免在蓝牙授权被设置为“开”时在没有进行用户交互的情况下接受该先前被信任的设备的任何连接请求。

7.3.11总密钥(Passkey)推荐

STB将支持全长总密钥(16个数)。

7.4服务发现协议

STB的蓝牙栈将支持服务发现协议并且在此上下文中，维护服务发现数据库(SDDB)以存储服务记录。

由于BLUCOM服务基于串行端口轮廓(SPP)，因此服务的UUID必须等于标准值0x1101(16位短形式)。另外，STB将服务属性“ServiceName”(属性ID0x0100)的值设置为“BLUCOM”，以便将BLUCOM与其他串行端口相关服务区分开。

Blucom客户端将查询来自STB的蓝牙服务记录，并且将只连接到那些支持被命名为“BLUCOM”的服务的Blucom数据服务器。

7.5串行端口轮廓

STB将具有按照蓝牙特殊兴趣组所指定的方式实现的串行端口轮廓。Blucom协议实现方式将使用串行端口轮廓作为接下来的更低层。

7.6蓝牙认证

STB中的蓝牙实现方式应当已根据蓝牙认证流程成功地通过鉴定过程。鉴定测试将由官方认可(即蓝牙认证委员会认可的)的品质认证测试机构来执行。

8有条件的访问要求

如果STB具有嵌入式的有条件的访问实现方式，则STB将满足CA系统供应商(如果可用的话)所定义的针对数字接口的特定安全性要求。

9PDR要求

如果STB制造商希望在PDR STB中实现Blucom功能，则将考虑关于Blucom数据轮播流的记录的特殊规则。

这些规则将在本文档以后的版本中定义。

附录A：DSM-CC消息(信息性的)

该附录将提供Blucom服务所使用的DSM-CC消息的消息结构。在本附录中提供的信息是从文档[2]和[4]中提取出的并在适当地增加了字段的Blucom专用用途。

A.1DSM-CC消息头部

DSM-CC消息头部在[2]中被定义。

语法	字节数
		DsmccMessageHeader(){
ProtocolDiscriminator	1
		DsmccType	1
MessageId	2
		TransactionId	4
Reserved	1
		AdaptationLength	1
MessageLength	2
		if(adaptationLength>0){dsmccAdaptationHeader()}
}

表5：DSM-CC消息头部的语法

DSM-CC消息头部的语义：

protocolDiscriminator：该字段被用于指示该消息是MPEG-2DSM-CC消息。该字段的值被设置为0x11。

dsmccType：该字段被一直设置为0x03，以指示所有消息都是U-N下载的消息。

messageId：该16位字段根据下表被编码：

消息Id	消息类型
		0x1006	DSI消息
0x1002	DH消息
		0x1003	DDB消息

表6：用在Blucom数据轮播中的消息类型

transactionId：对于DSI消息，transactionID的2个最低有效字节将被设置为0x0000或0x0001。对于DII消息，transactionID的2个最低有效字节将被分配在0x0002到0xFFFF的范围内。

adaptationLength：Blucom不使用DSM-CC适配头部。因此，该字段被设置为0x00。

messageLength：该字段被用于指示在该字段之后的消息的总字节长度。该长度包括在adaptationLength中指示的任意适配头部和由messageId字段指示的消息有效载荷。

A.2DSI消息格式

DSI消息根据标准[2]和[4]被格式化。

语法	字节数
		DownloadServerInitiate(){
DsmccMessageHeader()
		serverId	20
compatibilityDescriptor()	2
		privateDataLength	2
groupInfoIndication(){
		numberOfGroups	2
for(i＝0；i＜NumberOfGroups；i++){
		groupID	4
groupSize	4
		groupCompatibility()	2
groupInfoLength	2
		for(i＝0；I＜N；i++){groupInfoByte}	1
}
		privateDataLength	2
for(i＝0；i＜privateDataLength；i++){privateDataByte}	1
		}
}

表7：DSI消息的语法

DSI消息的语义：

serverId：该字段被设置为20字节，其值为0xFF。

compatibilityDescriptorO：该字段仅包含[2]中定义的compatibilityDescriptor的compatibilityDescriptorLength字段。其被设置为值0x0000。

privateDataLength：该字段传达[4]中定义的GroupInfoIndication结构。

numberOfGroups：这是一个16位字段，其指示在该字段之后的循环中描述的群组数目。

groupId：这是一个32位字段，其将等于描述该群组的DII消息的transactionId。

groupSize：这是一个32位字段，其将描述以字节为单位的群组中所有模块的累计尺寸。

groupCompatibility：该groupCompatibility结构等于[2]中定义的DSM-CC的compatibilityDescriptor结构。STB将仅下载groupCompatibilityDescriptorLength被设置为0x0000的群组的数据模块。

groupInfoLength：这是一个16位字段，其指示其后跟随的描述符循环以字节为单位的长度。

groupInfoByte：该字段传达描述符列表，其中每个描述符定义一个或多个属性。

privateDataLength：该字段定义随后的privateDataByte字段以字节为单位的长度。

privateDataBytes：这些字段是用户定义的，并且在Blucom版本1中不使用。它们将被Blucom版本1的STB所忽略。

A.3DII消息格式

该DII消息根据标准[2]和[4]被格式化。

语法	字节数
		DownloadInfoIndication(){
dsmccMessageHeader()
		downloadId	4
blockSize	2
		windowSize	1
ackPeriod	1
		tCDownloadWindow	4
tCDownloadScenario	4
		compatibilityDescriptor()
numberOfModules	2
		for(i＝0；i＜numberOfModules；i++){
moduleId	2
		moduleSize	4
moduleVersion	1
		moduleInfoLength	1
for(i＝0；i＜moduleIn-foLength；i++){moduleInfoByte}	1
		}
privateDataLength	2
		for(i＝0；i＜privateDataLength；i++){privateDataByte}	1
}

表8：DII消息的语法

DII消息的语义：

downloadId：该字段是正在发生的下载情形的标识符。DownloadId在网络中将是唯一定义的。该标识符将被用于正在发生的下载情形所使用的所有后续的DownloadDataBlock消息。

blockSize：该字段是在DownloadDataBlock消息中运载的每个块中的数据以字节为单位的长度，其中不包括可能小于blockSize的每个模块的最后一个块。

windowSize：该字段不被使用并被设置为0。

ackPeriod：该字段不被使用并被设置为0。

tcDownloadWindow：该字段不被使用并被设置为0。

tcDownloadScenario：该字段不被使用并被设置为0。

compatibilityDescriptor()：该字段仅包含[2]中定义的compatibilityDescriptor的compatibilityDescriptorLength字段。它被设置为值0x0000。

numberOfModules：该字段是在该字段之后的循环中描述的模块的数目。

moduleID：该16位字段是由moduleSize，moduleVersion和moduleInfoByte字段所描述的模块的标识符。moduleId在downloadId的范围内是唯一的。moduleId将在范围0x0000到0xFFEF中(0xFFF0到0xFFFF是为DAVIC预留的)。

moduleSize：该字段是所述模块以字节为单位的长度。

moduleVersion：该字段是所述模块的版本。在moduleVersion改变时，STB将更新Blucom数据缓存中的相关文件。

moduleInfoLength：该字段定义了所述模块的moduleInfo字段以字节为单位的长度。

moduleInfoByte：该字段传达描述符的列表，其中每个描述符定义一个或多个属性。

privateDataLength：该字段定义了随后的privateDataByte字段以字节为单位的长度。

privateDataBytes：这些字段是用户定义的，并且在Blucom版本1中不使用。它们将被Blucom版本1的STB所忽略。

A.4DDB消息格式

该DDB消息根据标准[2]和[4]被格式化。

语法	字节数
		DownloadDataBlock(){
dsmccDownloadDataHeader()
		moduleId	2
moduleVersion	1
		reserved	1
blockNumber	2
		for(i＝0 ； i＜N； i++){blockDataByte}	1
}

表9：DDB消息的语法

DDB消息的语义：

moduleId：该字段标识该块所属的模块。

moduleVersion：该字段标识该块所属模块的版本。所有文件的模块版本都必须被维护在STB的文件系统中，以便允许文件的更新。

reserved：该字段是[2]预留的并将被设置为0xFF。

blockNumber：该字段标识块在模块中的位置。块号0将是模块中的第一个块。

bockDataByte：该字段传达块的数据。

The dsmccDownloadDataHeader()根据以下语法被格式化：

语法	字节数
		dsmccDownloadDataHeader(){
protocolDiscriminator	1
		dsmccType	1
messageId	2
		downloadId	4
reserved	1
		adaptationLength	1
messageLength	2
		for(adaptationLength＞0){dsmccAdaptationHeader()}
}

表10：dsmccDownloadDataHeader的语法

dsmccDownloadDataHeader的语义：

protocolDiscriminator：该字段被用于指示该消息是MPEG-2 DSM-CC消息。该字段的值被设置为0x11。

dsmccType：该字段一直被设置为0x03，以指示所有消息都是U-N下载的消息。

messageId：该字段指示正被传递的消息的类型。DDB消息的messageId的值被设置为0x1003。

downloadId：该字段被用于关联下载情形的单个实例的下载数据消息和下载控制消息。downloadid字段的值将等于相关DII消息中的downloadid字段的值。

reserved：该字段被[2]预留并将被设置为0xFF。

adaptationLength：Blucom不使用DSM-CC适配头部。因此，该字段被设置为0x00。

messageLength：该字段被用于指示跟在该字段之后的消息以字节为单位的总长度。该长度包括在adaptationLength中指示的dsmccAdaptationHeader和由messageId字段指示的消息有效载荷。

A.5在blucom数据轮播中使用的描述符

A.5.1CRC32描述符

该CRC32_descriptor指示完整模块上的CRC32的计算。表11示出CRC32_descriptor的语法。

CRC32_descriptor(){	字节数	值
			descriptor_tag	1	0x05
descriptor_length	1
			CRC32	4
}

表11：CRC32_descriptor的语法

CRC32_descriptor的语义：

descriptor_tag：该8位字段标识描述符。对于CRC32_descriptor，该字段被设置为0x05。

descriptor_length：该8位字段指定紧跟在该字段之后的描述符的字节数。

CRC_32：这是一个32位字段，其包含基于该模块计算出的CRC，该CRC将根据MPEG-2系统ISO/IEC 13818-1[1]的附录B来计算。

 A.5.2压缩模块描述符

 compressed_module_descriptor的存在指示模块中的数据具有RFC 1950[16]定义的“zlib”结构。表12示出了compressed_module_descriptor的语法。

compressed_module_descriptor(){	字节数	值
			descriptor_tag	1	0x09
descriptor_length	1
			compression_method	1
original_size	4
			}

表12：compressed_module_descriptor的语法

compressed_module_descriptor的语义：

descriptor_tag：该8位字段标识描述符。对于compressed_module_descriptor，该字段被设置为0x09。

descriptor_length：该8位字段指定紧跟在该字段之后的描述符的字节数目。

compression_method：这是一个标识所用压缩方法的8位字段。该标识遵循RFC1950[7]的zlib结构的定义。

original size：这是一个32位字段，其指示压缩之前的模块以字节为单位的大小。

A.5.3群组链接描述符

group_link_descriptor包含关于哪些群组描述将被链接以描述单个更大群组的信息。当对群组中的模块的描述超过单个downloadInfoIndication消息的最大尺寸并且不得不扩散到多个这样的消息时，这是必要的。它还以链接的群组描述的顺序通知解码器。这不是严格必需的，因为链接的顺序不重要。其仅仅为了提供一种标识将被链接的所有群组描述的手段。表13示出了group_link_descriptor的语法。

group_link_descriptor(){	字节数	值
			descriptor_tag	1	0x08
descriptor_length	1
			Position	1
group_id	4
			}

表13：group_link_descriptor的语法

group_link_descriptor的语义：

descriptor_tag：该8位字段标识描述符。对于group_link_descriptor，该字段被设置为0x08。

descriptor_length：该8位字段指定紧跟在该字段之后的描述符的字节数目。

position：这是一个8位字段，其标识该群组描述在链接中的位置。值0x00将指示列表中的第一个群组描述。值0x01指示列表中的中间群组描述，值0x02指示列表中的最后一个群组描述。

group_id：这是一个32位字段，其标识列表中的下一群组描述。该字段对于列表中的最后一个值将被忽略。

A.5.4名称描述符

name_descriptor包含模块或群组的名称。表14示出了name_descriptor的语法。

name_deseriptor(){	字节数	值
			descriptor_tag	1	0x02
descriptor_length	1
			for(i＝0；i＜N；i++){
text_char	1	模块的名称，例如″index″
			}
}

表14：name_descriptor的语法

name_descriptor的语义：

descriptor_tag：该8位字段标识描述符。对于name_descriptor，该字段被设置为0x02。

descriptor_length：该8位字段指定紧跟在该字段之后的描述符的字节数目。

text_char：这是一个8位字段。″char″字段中的字符串指定模块或群组的名称。文本信息是利用[3]的附录A中描述的字符集合和方法被编码的。

附录B：Blucom控制文件的XML图解

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！--edited with XMLSPY v2004 rel.4U(http://www.xmlspy.com)

by SW Developement(APS GmbH)-->

<xs:schema elementFormDefault＝″qualified″

           attributeFormDefault＝″unqualified″

           xmlns:xs＝″http://www.w3.org/2001/XMLSchema″>

  <xs:element name＝″BlControl″>

    <xs:complexType>

      <xs:sequence>

        <xs:element name＝″SyncPage″>

          <xs:complexType>

            <xs:attribute

                name＝″na″type＝″xs:string″use＝″required″/>

            <xs:attribute

                name＝″fd″type＝″xs:boolean″use＝″required″/>

            <xs:attribute

                name＝″ri″type＝″xs:integer″use＝″required″/>

          </xs:complexType>

        </xs:element>

      </xs:sequence>

    </xs:complexType>

  </xs:element>

</xs:schema>

附录C：Blucom图标

以下图案示出将被显示在STB信息通栏标题中的Blucom图标。

具有活动客户端连接的Blucom图标：

不具有活动客户端连接的Blucom图标：

------文档结束------

功能规范

《BLUCOM》浏览器应用

03.08.2005

版本1.6修改请求2

APS SW开发

责任/版权

版权属于APS，Astra Platform Services GmbH，

Betastraβe l-9，D-85774 Unterfhring，

Telefon：+49(89)1896 3000

Juli 2005

该文件受版权保护，所有权利被保留。在未经APS明确书面许可的情况下，该文件不可被全文、部分或以修改版本形式复制或公开。

技术改进

本文档一直基于产品的最新版本。然而，APS无法确保本文档没有错误。另外，软件开发总是“不断流动的”，这可能导致程序和其文档之间存在小差异。

APS保留在任意时候不提供专门通知而修改文档的权利。对产品进行的影响本文档的改变将使得文档丧失有效性。

客户支持

N/n对于本产品

文档历史

Version	Date	Author	Changes
				草案	2005/02/13	M.Kreilein，U.Wiedow	文档创建
草案	2005/03/24	M.Kreilein，U.Wiedow	撰写
				1.0	2005/04/05	M.Kreilein	小改变以形成完成的版本1.0
1.1	2005/04/13	U.Wiedow，M.Kreilein	-在通信协议中添加返回代码值“DATA_NOT_YET_AVAILABLED”；据此修改应用流程的图(4.2)-GetCommand被改变(4.2.9)-添加蓝牙要求(4.1)-添加垂直排列(vertical-align)样式(3.5.3，3.6.4.2)-澄清DATA_NOT_YET_AVAILABLE反应(3.6.1.1)-提到base64编码(3.5.5)-改变内容解码(3.3)
				1.2	2005/04/14	U.Wiedow	-对于缺省频道的base64编码被标准ULR编码替代(3.5.5)；文档引用[4]据此被改变。

1.3	2005/05/02	M.KreileinU.Wiedow	根据文档“nderungsliste FunctionalSpec1_290405.xls”进行改变和修订；添加获取上下文命令(4.2.10)；改变获取命令(4.2.9)；添加规定表述的口头形式。
				1.4	2005/05/13	M.KreileinU.Wiedow	-根据文档“Anderungsliste Functional Spec.xls”进行改变和修订-在第5章中添加内容
1.4RCl	2005/05/20	M.KreileinU.Wiedow	-根据文档“Anderungsliste Functional Spec.xls”进行改变和修订
				1.4RC2	2005/05/23	U.Wiedow	小更正(措辞)
1.4RC3	2005/06/01	U.Wiedow	刷新命令改变(4.2.8)；isSyncPage属性从根元素的RefreshResponse移到子元素的DisplayPage；图5据此被改变
				1.5CR1	2005/06/20	M.Kreilein	●BLUCOM Uuid被服务名“BLUCOM”替换，以指示在发现期间的服务(3.1.1)●处理指令‘bl’是可选的(3.5.4)●对于<div>元素，没有缺省的background-color，单元‘px’将在样式表中被支持(3.5.3)●<object>标签支持“数据”属性而不是“href”(3.5.2.2)●在措辞方面的小更正
1.6CR2	2005/07/12	M.Kreilein	●‘home’动作取代“sync”变为缺省动作(3.5.4)●变量缺省值部分未改变地被移动(3.5.8.2)●应用启动被充分修改(3.1)，第3.1.6节“启动序列”由于与状态图[5]冗余而被删除。●在措辞方面的小更正和纠正
				1.7CR2	2005/07/20	M.Kreilein	●认证字符串被改变(4.2.6)●DPC因此被APS替换

目录

1      介绍.........................................................96

1.1    文档目的.....................................................96

1.2    产品范围.....................................................96

1.3    文档概述.....................................................96

2      系统概述.....................................................97

2.1    STB..........................................................97

2.2    浏览器应用...................................................97

3      功能要求.....................................................98

3.1    应用启动.....................................................98

3.1.1    上次连接设备的恢复.........................................98

3.1.2    设备和服务发现.............................................98

3.1.3    连接.......................................................99

3.1.4    认证.......................................................99

3.1.5    首次请求...................................................99

3.1.6    启动序列...................................................99

3.2    内容取得.....................................................99

3.2.1    一般定义...................................................99

3.2.2    自动内容取得..............................................100

3.2.3    手动内容取得..............................................104

3.2.4    链接历史..................................................104

3.2.5    页面重载..................................................105

3.3    内容解密....................................................105

3.4    用户接口....................................................106

3.4.1    输出频道..................................................106

3.4.2    输入频道..................................................108

3.4.3    导航和滚动................................................109

3.4.4    本地化....................................................110

3.5    内容编码....................................................110

3.5.1    编码格式..................................................110

3.5.2    允许的标签................................................110

3.5.3    样式......................................................113

3.5.4    处理指令..................................................117

3.5.5    链接......................................................118

3.5.6    页面命令..................................................119

3.5.7    表格处理..................................................120

3.5.8    变量......................................................122

3.6    内容呈现....................................................125

3.6.1    内容处理..................................................125

3.6.2    内容的定位和定尺寸........................................128

3.6.3    图像呈现..................................................128

3.6.4    文本呈现...................................................129

3.6.5    声音呈现...................................................130

3.6.6    表格呈现...................................................130

4      外部接口要求.................................................132

4.1    蓝牙通信.....................................................132

4.1.1    蓝牙栈要求.................................................132

4.1.2    串行端口轮廓通信...........................................132

4.1.3    超时处理...................................................133

4.1.4    连接丢失...................................................133

4.2    BLUCOM通信协议定义...........................................134

4.2.1    标记命令...................................................134

4.2.2    请求Id分配.................................................135

4.2.3    情况敏感性.................................................136

4.2.4  BLUCOM URL/文件名............................................136

4.2.5  DATA_NOT_YET_AVAILABLE与DATA_NOT_AVAILABLE...................136

4.2.6    发起命令(InitiateCommand)..................................137

4.2.7    同步命令(SyncCommand)......................................139

4.2.8    刷新命令(RefreshCommand)...................................141

4.2.9    获取命令(GetCommand).......................................144

4.2.10   获取上下文(GetContext).....................................146

4.3    内容提供者交互...............................................148

4.3.1  SMS..........................................................149

4.3.2  WAP..........................................................149

5      未来方面.....................................................152

5.1    持续性.......................................................152

5.2    嵌入式表格...................................................152

5.3    本地化.......................................................152

5.4    版本控制文件.................................................152

5.4.1    语法BlVersion.xml..........................................153

5.5    增强的可用性.................................................153

5.5.1   滚动........................................................153

5.5.2   页面维护....................................................154

5.5.3   优先内容维护................................................154

相关文档

[1]“XHTML^TM Basic”W3C Recommendation，http://www.w3.org/TR/XHTML- basic

[2]“Extensible Markup Language(XML)1.0(Third Edition)”W3C Recommenda-tion，http://www.w3.org/TR/REC-xml

[3]“Cascading Style Sheets，level 1”W3C Recommendation，http://www.w3.org/TR/REC-CSS1

[4]”URL Encoding”，http://www.w3schools.com/html/html ref urlencode.asp

[5]“State Diagram BLUCOM Rrowser Application”，APS

惯用语

惯用语	用法
		DEFINE	类型，定义和列举
ObjectProperty	对象属性和方法
		Filename	文件名和分类的用户输入

缩写

缩写	意思
		BL	BlueLink
CSS	层叠样式表单
		DOM	文档目标模型
APS	Astra平台服务
		PDA	个人数字助理
GSM	全球移动通信系统
		GPRS	通用分组无线电服务
HTML	超文本标记语言
		UMTS	通用移动电信系统
SAX	用于XML的简单API
		W3C	万维网联盟
XHTML	可扩展的超文本标记语言
		XML	可扩展的标记语言

规定表述的口头形式

口头形式	指示	等同表述
			将	要求	必须
将不	要求	必须不
			应该	推荐	推荐的做法是...
应该不	推荐	不推荐的做法是...
			可以	允许	允许...
不需要	允许	不需要...
			可以	可能性/能力	能够...
无法	可能性/能力	不能够...

1介绍

1.1文档目的

本文档指定“BLUCOM”浏览器应用(BL浏览器)的功能要求，并对系统环境给出简要描述。

1.2产品范围

BL浏览器是在诸如移动电话或PDA之类手持设备上驱动的应用。用户可以支付并下载应用。

一旦被安装，BL浏览器就使用无线蓝牙连接从附近的内容服务器取得时常改变的信息。信息被可视地、可听地并且可感知地呈现给用户。用户将通过利用手持设备的输入能力与被呈现的数据交互。

用户的交互产生反馈，该反馈经由GSM、GPRS或UMTS通过内置的返回频道被发送回内容提供者，以方便提供者。

1.3文档概述

第2章给出对系统环境的简要描述。

第3章指定BL浏览器(包括用户接口)的功能要求。

第4章指定BL浏览器应用的外部接口要求。

2系统概述

图1-系统概述

2.1STB

机顶盒被视为提供移动设备所请求的所有数据的内容服务器。蓝牙连接一直由BL浏览器发起。STB一直准备接受经授权的连接请求。一旦连接被建立，STB就具有为移动设备侧的BL浏览器提供数据的服务器的角色。

在本文档中未被覆盖。

2.2浏览器应用

BLUCOM浏览器应用(BL浏览器)的角色是要发起到STB的连接并提取所提供的数据，以将其呈现在移动屏幕上。

在本文档中被覆盖。

3功能要求

3.1应用启动

在移动电话上的蓝牙设备需要被使能并准备好在BL浏览器被启动之前连接远程蓝牙设备。

在启动BL浏览器之后，应用必须检查蓝牙设备是否被使能并且被准备好。如果不存在可用的蓝牙设备或者如果蓝牙设备未被接通，则BL浏览器将告知用户如何接通蓝牙设备。

3.1.1上次连接设备的恢复

在核实了蓝牙的可用性之后，浏览器将从永久参数中恢复上次连接的设备。设备的连接资源呈现所需要的所有参数必须被恢复，即用户友好的设备名和连接URL。

如果上次连接的设备已知，则BL浏览器将设备的名称和用于发现其他设备的选项呈现给用户。如果用户选择重新连接到恢复的设备，则浏览器直接尝试利用被恢复的连接URL建立连接，而不进行冗长的设备和服务发现。如果用户的目的是连接到不同设备，浏览器则不得不执行设备和服务发现。

如果没有上次连接可被恢复，则浏览器直接进入设备和服务发现，而无需请求用户的确认。

3.1.2设备和服务发现

蓝牙设备和服务发现是由BL浏览器应用发起的。为了找到合适的设备，BL浏览器将对每个被发现的设备执行服务查询，以确保移动设备只连接到相应的BLUCOM应用。

当发现至少一个提供BLUCOM服务的设备时，蓝牙专用的用户友好的设备名称列表被呈现给用户以供选择。该列表将一直包括重复发现过程的选项。当用户选择列表所呈现的设备时，BL浏览器尝试建立到其的连接。如果用户选择重复发现，浏览器则不得不这样做。

3.1.2.1BLUCOM服务标识

为了标识BLUCOM服务，BL浏览器必须评估服务的蓝牙UUID和名称。

由于BLUCOM服务基于串行端口轮廓(SPP)，因此服务的UUID必须等于标准化的值0x1101(16位短形式)。另外，服务属性“ServiceName”(属性ID0x0100)的值必须匹配“BLUCOM”，以将BLUCOM与其它串行端口相关的服务区分开。可能需要属性值的情况不敏感的评价和空白规范化来接收纯服务名称。

3.1.3连接

取决于STB侧的配置，可能必须输入认证id(PIN)以获得连接。在成功连接STB之后，如果移动设备支持正确的列表管理，则远程设备必须被添加到受信设备列表，以避免重现对随后到该设备的连接的pin请求。

3.1.4认证

在成功连接之后，BL浏览器必须向STB发送发起请求(4.2.6)，以便获取与其在STB侧的对应部分相对照的版权字符串。在否定响应或者甚至在所配置的超时时段内丢失响应的情况下，BL浏览器将显示指示STB未被授权进行BLUCOM服务的消息。当浏览器在连接丢失之后重新连接到STB时，认证(即初始请求)也必须完成(重复)，否则，STB可能拒绝与浏览器的进一步通信。版权字符串是静态文本字符串，其对BL协议或认证而言没有进一步的意义。其仅仅是出于法律原因而需要的并将由APS来定义。示例可以参见4.2.6。只要BL浏览器尚未成功核实其版权字符串，它就将显示内置的溅射屏幕。

3.1.5首次请求

在成功认证或处理版本控制文件之后(参见5.4)，BL浏览器必须显示第一页面。因此，BL浏览器必须执行同步命令(4.2.7)以获得与STB提供的当前BLUCOM服务之间的同步。假设存在可用的BLUCOM频道，则BL浏览器接收必须取得并显示其内容的URL。

3.1.6启动序列

对于完整的启动序列，请参考[5].

3.2内容取得

3.2.1一般定义

BL内容是由不同内容提供者来准备的。提供者使用页面来从逻辑上组织其内容。BL浏览器一次显示单个页面。

只要BL浏览器尚未成功地核实其版本字符串(3.1.3)，它就将显示内置的溅射屏幕。一旦STB已经确认认证，浏览器就一直尝试显示其基于请求从STB接收的页面。

每个页面被附接到特定上下文。上下文id被递送给从服务器取得的每个页面。上下文对页面请求以及上下文变量的维护而言很重要(3.5.7)。

存在两种如何从STB取得(取出)内容的方式。

3.2.1.1自动页面请求

BL浏览器根据由BLUCOM协议(4.2)确定的刷新间隔来自动请求来自服务器的新页面。它可以在每个随后的页面或内容请求之后改变。内容请求本身被分到三个步骤中。

■步骤1：BL浏览器通过向STB发送同步(4.2.7)或刷新命令(4.2.8)来请求新页面URL。是否需要执行同步或刷新命令由在当前显示的页面内定义的处理指令确定(3.5.4)。

如果BL浏览器无法获得处理指令，例如在丢失页面等的情况下，缺省处理指令是“同步”。

■步骤2：BL浏览器将递送的URL名称和版本与当前显示的页面相比较。如果这些值中的至少一个存在差异，递送的URL的内容就将被取得和显示。如果被递送的上下文与当前已知的不同，被递送的URL的所有内容就将被取得和显示，即使URL和版本等于当前显示的页面也要如此。

■步骤3：在已经成功地之行了步骤1和步骤2之后，BL浏览器取得显示该页面所需的所有内容。

所有自动页面请求都被静态地执行：由于用户没有触发取得，因此如果对这些页面的请求、取得或处理失败，将不会显示消息。

3.2.1.2手动页面请求

用户可以通过选择当前显示的页面中的超引用链接来异步地触发页面请求。BL浏览器尝试取得显示该页面所需的所有内容。

所有手动页面请求被主动地执行，即用户获得关于浏览器行为的可读、可视的反馈。如果被请求的页面由于错误而无法被显示，则显示错误消息。

3.2.2自动内容取得

内容提供者频繁地更新内容。两种更新被区分：

1.)提供者确定新的不同页面，该页面必须尽可能快地被BL浏览器(BL-Slang:“Hotsync”)所显示。

2.)提供者生成BL浏览器当前显示的页面的更新，该更新将被显示以取代旧的(过时)页面。

接下来将显示哪个页面完全受控于STB。BL浏览器请求并显示STB指示的每个新页面，除非页面名称、页面版本和上下文相对于当前显示的页面没有改变。

由于除非BL浏览器请求新页面，否则STB不递送新页面，因此BL浏览器必须周期性地轮询服务器并请求页面更新。BL浏览器将能够处理1秒的查找间隔。

除了浏览器内部查找间隔之外，刷新间隔必须被视为动态值，最终由BLUCOM协议(4.2)递送的内容提供者所驱动。

注意：在本文档中的所有应用流程图都将只描述原理，并且不能被视为BL浏览器的完整实现方式指南。

图2-应用流程“自动取得”

更新请求工作如下：

根据包括在当前显示的页面中的处理指令(3.5.4)，BL浏览器调用以下命令之一：

3.2.2.1同步命令(4.2.7)

条件：实际页面的req指令被设置为“同步”(3.5.4)。

利用同步命令，BL浏览器向STB请求当前有效的同步页面URL。除了当前同步页面的URL之外，同步响应还递送关于当前上下文和新的刷新间隔的信息。

返回代码通知同步响应状态。BL浏览器如何对某些返回代码作出反应在文档[5]中描述。

一旦同步响应被成功处理，并且根据步骤2的条件(3.2.1.1)被实现，BL浏览器就将获取新页面URL的内容，以显示新页面。

图3-应用流程“同步命令”

3.2.2.2刷新命令(4.2.8)

条件：实际页面的req指令被设置为“刷新”(3.5.4)。

利用刷新命令，BL浏览器发送当前显示器上显示的页面和当前同步页面(可能是不同的)的URL和文件版本。一旦刷新响应被成功处理，并且根据步骤2的条件(3.2.1.1)被实现，BL浏览器就将获取被递送的新页面URL的内容以便显示新页面。返回代码通知刷新响应的状态。BL浏览器如何对某些返回代码作出反应在文档[5]中描述。

新页面可能是对当前显示的页面的更新或者是将被立即显示的新同步页面(Hotsync)。另外，刷新响应递送关于当前上下文、新刷新间隔和其上一个标志的信息，所述标志确定所提供的URL是否是同步页面。在新页面被通知作为同步页面的情况下，BL浏览器将保存该URL和版本作为其当前同步页面。

图4-应用流程“刷新命令”

3.2.2.3上下文改变查找

如上所述，刷新间隔可以由内容提供者或广播中心定义。在任意一种情况下，BLUCOM协议(4.2)将递送它。因此，可能发生间隔值太长而无法在可接受的时段内注意到频道或上下文切换的情况。

因此，当BL浏览器处于空闲状态时，有必要不时地查找上下文改变。为了实现这个目的，BL浏览器必须能够同时处理两个计时器循环(还参见图2)。下图示出这种上下文改变查找序列的原理。

图5-应用流程“上下文改变查找”

注意：

如果在显示器上实际示出BLUCOM页面，则条件“显示器上的页面”被满足。在由于各种原因BL浏览器无法显示从STB取得的上一页面情况下，下次将执行同步命令，而非获取上下文命令。

3.2.2.4锁定的更新

条件：实际页面的req指令被设置为“锁定”(3.5.4)。

如果当前显示的页面指示刷新通过处理指令被锁定，则没有自动内容取得必须被执行。因此，针对这些页面，刷新计时器不启动并且不进行评价，只有上下文查找将被执行。页面只在用户自己请求新页面或者上下文查找指示上下文已经改变的情况下被保留。

3.2.3手动内容取得

除了自动取得内容更新的能力之外，BL浏览器还必须提供通过当前显示的页面根据用户的手动导航来更新内容的方式。

用户可以通过选择当前显示的页面中的链接(3.4.3.2)，发起可经由功能键(3.5.6)访问的暴露页面命令之一(3.4.2.2)或者重载页面(3.2.5)来手动请求页面。

在任意一种情况下，BL浏览器都必须评估链接以确定哪个数据连接必须被使用(3.5.5)。如果数据必须从BL服务器请求，则必须发送获取命令(4.2.9)。

3.2.4链接历史

为了实现保存所有取得的页面的个人缓存(像WEB缓存一样)，希望建立RAM池，其保存所有取得的URL，而非每个页面的内容。

BL浏览器将被请求(和显示)的每个页面的URL(包括名称、版本和上下文)保存到这个称为链接历史的池中。对于将被保存在历史中的页面，处理指令“his”必须设置为1(3.5.4)。对于经由WAP取得的不存储在历史中的页面存在例外(4.3.2.4)。

BL浏览器不对存储在链接历史中的页面的内容的存在负责。因此，由BL浏览器根据移动电话的存储能力配置所述池的大小。

3.2.4.1历史管理

链接历史被实现为具有有限大小5k的LIFO缓冲器。对于每个将被添加的新页面数据集合，如果需要BL浏览器可以自由删除池中的过去(最旧)的条目。如果用户从历史中恢复链接并且启动必须再次添加到历史中的新链接，则历史中的所有较新链接都被删除。

链接历史将被保持活跃，直到应用被停止或者BL服务器指示了新的上下文(注意：如果没有BLUCOM是可用的，则该历史将被保留)。

3.2.4.2历史访问

如果内容提供者允许的话，用户可以访问该历史。内容提供者使用处理指令来使能或禁止用于历史访问的相应页面命令。

如果被使能，将仅显示页面命令“后退”或“前进”，并且如果历史中存在相应链接，则可访问。如果用户从历史中选择一个链接，则浏览器必须通过获取命令来请求页面(4.2.9)。

3.2.5页面重载

BL浏览器的选项菜单向用户提供了重载当前显示的页面的功能。用户将使用该功能来手动刷新页面，例如如果某些嵌入图像丢失或者用户希望再次播放页面声音的话。

如果用户发起当前页面的重载，则BL浏览器将发送获取请求(GetRequest)以检查是否有页面的更新版本可用。另外，嵌入在页面中的所有资源都必须被检查以用于更新，尤其是在页面本身的版本没有改变的情况下。针对更新的资源进行检查的必要性独立于页面的处理指令而存在(3.5.4)。

3.3内容解密

经由BLUCOM协议的获取命令(4.2.9)取得的所有文件都包括引导字节(前序字节)，该字节指示后面代表有效载荷(内容)的数据块是否被加密。当接收到数据块时，BL浏览器应用必须首先读取该字节，以判断后面的数据块是否需要被传递到解密单元。

前序字节可能具有以下值：

0x00后面的数据块未被加密

0x01后面的数据块被加密

BL浏览器必须确保只有不带有前序字节的有效的数据块被分别传递到解密单元以进一步处理。

在无效的前序字节(既不是0x00也不是0x01)的情况下，BL浏览器将以与其检测到无效的XHTML代码时相同的方式工作。

3.3.1.1所用算法

所用算法是遵循高级加密标准(AES)的Rijndael。

所用密钥长度为128位。

3.4用户接口

3.4.1输出频道

BL浏览器将利用所有设备能力来呈现内容。典型的手持设备提供视觉、听觉和/或触觉的输出频道，但是这些频道在功能范围方面有所不同。

BL浏览器识别以下输出频道：

频道	类型	可用性	限制
				显示	视觉的	一直	不同分辨率，不同颜色深度
背光	视觉的	可选的	无
				声音	听觉的	可选的	支持的声音格式
振动	触觉的	可选的	无

表3.4-A支持的输出频道

BL浏览器支持所有以上输出频道。特定设备不支持的那些输出频道将在该设备的浏览器版本中被禁止。如果输出频道被禁止，即使被内容提供者请求，浏览器也将跳过该输出。如果没有支持的声音格式被提供，则还将影响声音输出。

3.4.1.1显示

BL浏览器区分若干设备媒体类型以总结变化的显示限制。媒体类型决定具有类似限制(主要是x轴上的显示分辨率)的所有设备。

内容提供者将利用受控于定义的媒体类型(3.5.3.1)的样式(style)来解决已知的显示限制。

媒体类型	描述
		x128	总结出所有配件以128像素的显示宽度工作
x176	总结出所有配件以176像素的显示宽度工作
		x240	总结出所有配件以240像素的显示宽度工作

表3.4-B显示类型区别

3.4.1.2状态条

BL浏览器分裂显示并预留一小部分用于状态信息。该状态条的高度和位置可以是依赖于媒体类型的。根据[5]，该状态条将显示以下信息：

1.)连接状态

2.)可用功能键的描述

3.)滚动指示符

为了符合2.)，状态条必须被放置在靠近功能键(3.4.2.2)的位置上。功能键f1总是打开选项菜单(3.4.2.3)，因此，状态条显示本地化文本以描述该键。功能键f2总是触发由提供者分配的特定于页面的动作，因此，状态条显示本地化文本以描述该键。

滚动指示符用符号表示页面内容超出可用显示尺寸。指示符的可视化可以通过一对箭头来实现，这对箭头指示页面可被滚动的方向。

3.4.1.3活动性指示符

活动性指示符总是在浏览器忙或等待时被显示并且不接受用户输入。活动性是通过显示图标(例如时钟符号)或通过操作状态条(例如改变其颜色)来指示的。

3.4.1.4背光

背光可以通过处理指令(3.5.4)根据源代码来解决。背光被打开一段特定于设备的时段，该时段无法由内容提供者的标记来控制。内容提供者将知道背光可以在各种目标设备上闪烁，这取决于供应商的背光控制实现方式。如果背光控制在目标设备上不可用，则BL浏览器跳过该指令。

3.4.1.5声音

BL浏览器将确定目标设备所支持的声音格式(MIDI、MP3等)。

BL浏览器对于每种支持的声音格式具有内置的BL-branded听觉事件。内容提供者可以通过处理指令(3.5.4)来呈现该声音以发信号通知特定(可能是重要的)页面正被显示。如果目标设备根本不支持声音，则BL浏览器跳过该指令。内容提供者可能希望在其内容中嵌入不同的或附加的声音。提供者再负责提供具有不同声音格式的多个声音文件。在内容标记中，提供者必须列出所有声音文件，其中每个声音文件被分配了专用mime类型。BL浏览器随后将通过评估mime类型来选择合适的声音文件(3.6.5)。

Mime类型	描述
		音频/mpeg	MPEG音频，将被用于所有mpeg音频格式，主要是mpeg2第3层(mp3)
音频/midi	MIDI音频，需要midi解释器
		音频/x-wav	WAV音频，未经压缩的音频
音频/amr	AMR音频(自适应多速率)，用于高压缩音频(例如铃声)

表3.4-C所支持的声音mime类型

3.4.1.6振动警报

内容提供者可以通过处理指令(3.5.4)来应对内容标记内的振动警报。如果在目标设备上可访问，则BL浏览器在特定于设备的时段(例如一次)中触发振动警报，否则浏览器简单地跳过该指令。

3.4.2输入频道

BL浏览器需要用于要被呈现在任意目标设备上的触觉输入的频道。浏览器将接受键和/或指针控制的用户输入。取决于设备，可选的语音控制可被应用。BL浏览器区分两种键，导航键和功能键。

3.4.2.1导航键

键	可用性	动作
			up	强制的	在页面上向上移动光标/标记到前一链接
down	强制的	在页面上向下移动光标/标记到后一链接
			ok	强制的	激活当前关注的链接(3.4.3.2)或确认实际输入并执行附属动作
left	可选的	在页面上向上移动光标/标记到前一链接
			right	可选的	在页面上向下移动光标/标记到后一链接

表3.4-D支持的导航键

导航键的布局是依赖于设备的。BL浏览器将检查哪些键可用并适当地分配功能：首先所有强制的键被分配，然后可选的键被使能。

3.4.2.2功能键

功能键(也称为软键)向用户提供对页面命令(3.5.6)或表格动作(3.6.6.2)的访问。这些命令是由内容提供者在页面代码(3.5.4)中针对页面确定的。

键	功能	效果
			f1	选项	当按下该键时，BL浏览器呈现选项菜单，该菜单允许用户访问所有被分配的选项
f2	动作	当按下该键时，BL浏览器执行当前分配给该功能键的动作

表3.4-E支持的功能键

功能键的布局是依赖于设备的。BL浏览器检查哪些键可用被适当地分配功能：功能键假设被布置得靠近显示器，从而当前分配的功能可以在状态条(3.4.1.2)中被指示。左功能键是f1，右侧的键是f2。

3.4.2.3选项菜单

选项菜单保存了提供者为当前显示的页面分配的所有页面命令(3.5.6)。另外，菜单总是保存退出命令和重载命令，退出命令允许用户退出应用，重载命令可被调用以重载当前显示的页面(对照3.2.5)。

选项菜单在用户按下功能键f1时被打开。选项菜单在用户取消菜单时或在一个选项被选择和执行时被关闭。

3.4.3导航和滚动

BL浏览器必须能够在页面被显示时马上确定页面的总高度(以像素为单位)。如果页面不适合显示高度，则滚动将被指示(3.4.1.2)。滚动指示符在用户导航通过该页面时被适当地适配。水平滚动将不被支持。

3.4.3.1初始页面状态

一旦加载的页面被显示，页面的左上角就匹配显示器的左上角。没有项目(链接)被关注。

3.4.3.2导航方案

用户将使用导航键‘up’，‘down’，‘left’和‘right’(3.4.2.1)来步进通过页面的内容。

BL浏览器将支持以下基本导航方案：

BL浏览器在交互式项目生现在HTML标记中时确定这些交互式项目的顺序。内容提供者负责将以合适的顺序放置超级链接。如果用户点击‘down’或‘right’，则BL浏览器基于当前关注的项目瞄准在HTML标记中向下的下一超级链接。如果用户点击‘up’或‘left’，BL浏览器则基于当前关注的项目瞄准在HTML标记中向上的下一超级链接。

如果所描述的项目至少部分被拉出，浏览器则聚焦于新项目。否则，浏览器尝试在所需方向上滚动该页面。

当当前关注的项目由于滚动而变得不可见时，其不再被关注。甚至由于上面被拉出的项目而使其不可见或不完全可见的项目也被关注，不过该关注对用户而言可能不是显而易见的。用户可以按下“ok”导航键来激活当前关注的链接。

3.4.3.3滚动

如果浏览器检测到需要页面滚动来满足用户输入(寻找将关注的下一链接或显示页面其余部分)，它将使页面向上或向下移动可配置的像素量。该配置被需要以允许功能强大的设备(少量像素，最少为1个像素)比功能不太强大的设备(大量像素，最大为显示器高度)具有更平滑的滚动。

保守估计，页面方式的滚动是BL浏览器的原型可接受的。甚至弱移动设备将能够跳过HTML内容页面。对于更强大的移动设备，用于最佳用户经验的滚动值将在应用针对这些设备被定制时被计算出。

浏览器应该在空闲状态中预处理滚动，以增强指定的滚动行为的可用性。

3.4.3.4关注表示法

在BL浏览器中，交互式项目链接一直被表示为填充有颜色、图像等的矩形框。内容提供者可以针对每个交互式项目的关注和未被关注的状态提供专用样式(参见3.5.3.2代码示例)。如果提供者没有提供针对被关注状态的样式(利用伪选择器‘a:hover’)，则1个像素宽度的行内边界被画出以划分表示该关注。如果针对被关注状态的样式被提供并且包括边界颜色样式分配，则该边界也可用指定颜色画出。在所有其他情况下，不画出边界。

当链接被关注时，BL浏览器应用提供者所提供的样式。如果提供者没有提供针对被关注的项目的专用样式，BL浏览器则应用缺省样式(例如以醒目颜色画出矩形边界)。

3.4.4本地化

所有针对状态或错误消息的内置文本和功能键的描述将被本地化。BL浏览器仅使用一种语言，但是将实现这样一种机制，该机制使得所有文本可以在应用的不同版本中很容易地被本地化。

3.5内容编码

3.5.1编码格式

内容提供者使用XHTML来标记其内容。XHTML为内容的布局和品牌化提供了灵活性，同时它是一种用于面向页面的内容呈现的已被接受的公知编码标准。在BL浏览器中实现的X(HT)ML解析器必须能够识别任何被允许的语法元素，例如标签、注释、DTD、符号、CDATA部分等等。所有识别出的元素(除了在本章的其余部分指定的那些之外)将被放弃而不作解释。

所有HTML页面都以UTF-8 Unicode表示被编码。

3.5.2允许的标签

在XHTML Basic[1]的W3C建议上找到XHTML的所需部分。BL浏览器将支持的XHTML的范围最初被限制为以下元素：

模块	元素
		结构	body，div，head，html，style1
超文本	a
		基本模块	form，input，option，select，textarea
对象	object

表3.5-1支持的XHTML元素

3.5.2.1标签层次结构

BL浏览器支持的XHTML标签必须以特定分层结构出现。下表示出允许的标签的层次结构。

标签	父	子	标签条件
				html	-	head，body	一直是根元素

                                  

¹在[1]中排除了style元素，但是其必须被BL浏览器支持，因为外部样式表将被消除。

head	html	style	每个页面只有1个实例，在body之前
				body	html	div，form	每个页面只有1个实例，在head之后
style	head	-	每个祖先有多个实例
				form	body	div	每个祖先只有1个实例
div	body，form	a，object，input，select，textarea中的一个或没有	每个祖先有多个实例
				a	div	-	每个祖先只有1实例
object	div	-	每个祖先有多个实例
				input	div	-	每个祖先只有1实例
select	div	option	每个祖先只有1实例
				option	select	-	每个祖先有多个实例
textarea	div	-	每个祖先只有1实例

表3.5-2BL标签层次结构

BL浏览器所不知道的标签可被解析器忽略，在预定层次结构之外被注释的已知标签也可被忽略。

3.5.2.2属性

XHTML标准[1]定义了每个元素的属性。BL浏览器必须支持以下属性和值的子集。其他属性和值可以被浏览器忽略。

标签	属性	值	描述
				html	-		-
head	-
				body	class	see[1]	向主体分配样式
style	media	see 3.4.1.1	选择样式应用的媒体类型
				div	class	see[1]	为分区分配样式
a	href	see 3.5.5	当链接被激活时定义将被请求的URL
				target	see 3.5.5	针对SMS链接定义跟随页面的URL
	object	data	see 3.5.5				定义对象的URL
type				see 3.4.1.5	选择对象的mime类型
		form	action			see 3.5.5	定义将被调用的URL以完成该表格
method	POSTGETsee 3.5.7.5			定义表格数据必须如何被发送到(HTTP)服务器的方法

	target	see 3.5.5	针对SMS链接定义跟随页面的URL
				input	type	textpasswordcheckboxradiosubmitresetsee 3.5.7.2	定义表格输入元素的类型
name	see 3.5.8.1	定义连接到输入元素的变量的名称(不是类型submit或reset)
			value		see 3.5.8.1	定义变量的(缺省)值
checked	checked	定义类型为radio或checkbox的输入元素的缺省状态
			maxlength		see[1]	定义类型为text或password的输入元素的值的最大长度
select	name	see 3.5.8.1					定义连接到选择元素的变量的名称
			option	value	see 3.5.8.1	定义在选择情况下针对附属变量的(缺省)值
selected	selected	定义缺省选择的选项
				textarea	name	see 3.5.8.1	定义连接到textarea元素的变量的名称
rows	see[1]	定义textarea的行数，用于计算允许的符号的数目
			cols		see[1]	定义用于计算允许的符号的数目的textarea的栏数(宽度)

表3.5-3BL标签层次结构

3.5.2.3文本节点

HTML元素可能具有文本节点，所述文本节点通常维护将被显示的文本。BL浏览器必须知道用于以下专用标签的文本节点：

标签	文本含义
		style	将由BL解析器解析和解答的样式表
div	将被显示的流文本的一段
		a	将被显示为链接的文本
input	将被显示为无线电按钮或复选框的声明的文本
		option	将被列为选择选项的文本
textarea	文本框中的预定文本

表3.5-4支持文本节点的标签

对于与上表中列出的标签不同的所有标签，BL浏览器可能省略文本信息。文本将不被显示。

特殊处理应用到那些可以包含文本或进一步的子元素(<div>-元素)的元素(对照3.5.2.1)。如果分区包含文本和进一步的子元素，则解析器可以省略该文本。

3.5.2.4预定的字符实体引用

除了XML[2]中预定的那些之外，其他实体不需要被BL浏览器支持。以下预定实体在被用于躲避(escape)XHTML语法时必须被识别和解释：

表示	实体含义
		&lt；	‘＜’小于
&gt；	‘＞’大于
		&apos；	‘’’撇号
&quot；	‘”’引用标记
		&amp；	‘&’(＝and)

表3.5-5预定字符实体引用

3.5.3样式

利用用于内容标记的XHTML Basic，内容提供者在语法上将信息与呈现相分离。用于声明样式的语法在[3]中定义。以下样式列表代表[3]中定义的样式的子集，并且必须被BL浏览器支持：

样式	值	缺省	应用到	描述
					top	number[px]	see 3.6.2	div	从显示器的上边界按像素测量的框的绝对y位置
left	number[px]	0，see 3.6.2	div	从显示器的左边界按像素测量的框的绝对x位置
					width	number[px]	displaywidth，see 3.6.2	div	按像素测量的框的绝对宽度
height	number[px]	see 3.6.2	div	按像素测量的框的绝对高度
					background-color	#RRGGBB	#FFFFFF(for bodyonly)	bodydiv	显示器、框或活动链接的背景颜色
background-image	URL	-	bodydiv	显示器、框或活动链接的背景图像
					color	#RRGGBB	#000000	bodydiv	文本颜色

font-size	smallmediumlarge	medium	bodydiv	取决于目标设备的字体大小
					font-weight	normalbold	normal	bodydiv	指示文本是否将被显示为粗体
font-style	normalitalic	normal	bodydiv	指示文本是否将被显示为斜体
					text-decoration	noneunderline	none	bodydiv	指示文本是否将被加上下划线
text-align	leftcenterright	left	bodydiv	指示文本如何在框中被水平对齐
					vertical-align	topmiddlebottom	top	div	指示文本如何在框中被垂直对齐
border-color	#RRGGBB	#000000	div	针对被关注的链接的矩形边界的颜色，只应用到a:hover伪选择器

表3.5-6支持的样式声明

每种样式声明的重要性取决于该样式被分配到的HTML元素。特定样式仅应用于上表所示的特定元素，不同分配可以被BL浏览器跳过。

不管CSS[3]的说明怎样，BL浏览器都不需要强制的单元标识符，用于height，width，top和left的非零值。如果没有给定单元标识符，则BL浏览器将期望“px”作为缺省值。除了“px”之外的单元标识符不需要被支持。

3.5.3.1依赖于媒体类型的样式

为了使内容呈现最好地符合设备的关于显示尺寸、颜色深度等的性能，BL浏览器区分若干媒体类型(3.4.1.1)。

内容提供者将向其内容添加不同的样式，其中每种样式是针对一种专用媒体类型而设计的。BL浏览器必须通过检测目标设备的媒体类型来决定所需样式并在呈现内容时应用所涉及的样式。

提供者利用HTML文档头部的<style>元素来定义样式。外部样式表不需要被支持。

除了预定的媒体类型之外，还允许应用到任意媒体类型的全局的无条件的样式。全局样式不具有“媒体”属性或者“媒体”属性为空。

被分配了BL浏览器不知道的任何其它(定制的)媒体类型的<style>元素将被忽略。

示例：

以下XHTML摘录标记了所有被支持的媒体类型的样式，包括应用于所有媒体类型的全局的无条件的样式声明。

<head>

     <style><！——global style for all media types--></style>

     <style media＝″x128″><！——styles for type x128--></style>

     <style media＝″x176″><！——styles for type x176--></style>

     <style media＝″x240″><！——styles for type x240--></style>

</head>

样式总是被“相加地”应用，意思是可以定义针对同一媒体类型的若干<style>元素(包括全局<style>)，这些<style>元素必须被逐个解析，其中每个元素补充或覆写其前面的元素的样式定义。

示例：

在x128移动设备的情况下，<style>元素1(全局的)，2和4将被应用，其中每个元素补充样式定义。

<head>

     <style><！——global style for all media types--></style>

     <style media＝″x128″><！——styles for type x128--></style>

     <style media＝″x176″><！——styles for type x176--></style>

     <style media＝″x128″><！——styles for x128 again--></style>

</head>

3.5.3.2样式分配

CSS[3]的说明定义了各种所谓的选择器，用于给内容分配样式。BL浏览器必须基本上支持类选择器，以向HTML元素分配样式。因此，提供者可以仅对类属性应用到的元素分配样式(3.5.2.2)。

示例：

以下HTML摘录定义了类“divl”的样式，该类被HTML主体中的专用分区所引用。实际上，由<div>元素构成的框的背景将被涂黑，文本将是白色的。

<head>

     <style>

                .divl{    background-color:#000000；

                          color:#FFFFFF}

     </style>

</head>

<body>

     <div class＝“divl“>white text on black ground</div>

</head>

另外，伪选择器“a:hover”必须被支持，以增强用户关注链接时可视反馈的样式。

示例：

以下HTML摘录定义了包括a:hover选择器的类“divl”的样式。当用户激活辅助链接时，背景色从黑色变为白色，文本色由白色变为黑色，并且矩形边界显示为红色。

<head>

     <style>

                .divl{    background-color:#000000；

                          color:#FFFFFF}

                .divl a:hover{color:#000000；

                           background-color:#FFFFFF；

                           border-color:#CC0000}

     </style>

</head>

<body>

     <div class＝“divl“>

                 <a href＝“#“>Hover me to change my color！</a>

     </div>

</body>

同样的机制适合转滚(rollover)图像的效果。当链接被挂起(hover)时，不活动的背景图像被涂上了活动图像。

<head>

     <style>

                .divl{background-image:url(/inactive.png)}

                .divl a:hover{background-image:url(/active.png)}

     </style>

</head>

<body>

     <div class＝“divl“>

                 <a href＝“/yesno.htm“>&nbsp；</a>

     </div>

</body>

3.5.3.3样式继承

CSS[3]的说明定义了样式的继承，被称为“层叠的”。BL浏览器必须支持继承，继承的样式声明由下表列出。所有其他样式声明都不能被继承。

样式	描述
		color	继承文本颜色
font-size	继承字体尺寸(小、中或大)
		font-weight	继承字体重量(粗体或非粗体)
font-style	继承字体样式(斜体或非斜体)
		text-decoration	继承文本装饰(带下划线或不带下划线)
text-align	继承水平文本对齐(左、中或右)
		vertical-align	继承垂直文本对齐(上、中或下)
border-color	继承所关注链接的矩形边界颜色

表3.5-7继承样式声明

样式的继承允许提供者一次指定文本的通用外观，例如指定HTML主体。文本样式随后被应用到页面的所有文本项目，只要没有其他样式被分类用于子元素即可。

示例:

以下HTML摘录示出样式继承。所有文本按常规尺寸(缺省的)、常规重量(缺省的)被写成黑色，并且不带有装饰(缺省的)和斜体样式。该样式被所有文本分区所继承，但是类p1的分区将通用斜体样式覆写成“常规的”。

<head>

     <style>

                .general{color:#000000；

                                   font-style:italic；

                                   text-align:center}

                .p1{               font-style:normal}

     </style>

</head>

<body class＝“general“>

     <div>

                  Text style inherited(font style italic)

     </div>

     <div class＝“p1“>

                  Text style inherited but font style normal

     </div>

</body>

3.5.4处理指令

在每个HTML标记顶部，内容提供者可以添加处理指令，该处理指令告诉BL浏览器除了页面的可视化之外，还有哪些特定于应用的动作需要被执行。处理指令被编码以符合W3C XML标准[2]，特定于BL的指令由名称“bl”指示。

以下处理指令必须被BL浏览器所理解。如果一个指令丢失(即未由内容提供者提供)，则浏览器必须使用缺省值。

指令	值	缺省	处理
				req	sync|refresh|lock	刷新	确定页面的更新将如何被请求(3.2.2)
his	0|1	1	指示页面是否将被添加到历史(3.2.2.4)
				var	0|1	0	指示变量是否将被解答(resolve)(3.5.7)
snd	0|1	0	指示页面是否将从听觉上被宣布(3.4.1.5)
				vib	0|1	0	指示页面是否将通过触觉反馈(振动警报)被宣布
lit	0|1	0	指示背光是否将被打开(3.4.1.4)
				img	0|1	0	指示页面是否利用动态图像(3.6.3.3)

backnext	action|option		确定用户可以如何经由功能键(3.4.2.2)来访问被指示的页面命令(3.5.6)
				next	action|option
home	action|option	动作
				sync	action|option

表3.5-8强制的处理指令

示例：

以下XHTML摘录将触发以下行为：页面更新被同步，变量将被解答并且页面被添加到历史(缺省的)。命令“前进”和“同步”被添加到选项菜单，同时命令“回主页”被用作缺省动作。

<？xml version＝″1.0″encoding＝″UTF-8″？>

<？bl req＝”sync”var＝”1”next＝”option”sync＝”option”？>

<html>

...

</html>

在以下示例中，提供者省略或完全忘记添加处理指令。然而，BL浏览器发送针对页面的刷新命令，将其添加到历史并提供命令“回主页”作为动作。

<html>

...

</html>

动作的分配是排他性的。如果提供者将多于一个命令标记为页面的动作，则BL浏览器可以选择页面代码中被通报的最后一个动作。

3.5.5链接

提供者嵌入链接(通常被标签为<a href＝”link”>或<form action＝”link”>)，以允许用户与内容交互。链接可以请求来自内容服务器的另一页面，可以启动内置命令(3.5.6)或者可以触发诸如发送SMS或经由GPRS发送表格数据之类的专用手持功能。

链接语法被提出，以满足唯一标识BL浏览器将执行的动作的要求。链接被表示如下：

link::＝[action]url

BL浏览器必须检测和执行以下动作：

动作	处理
		action omitted	如果链接不指定动作，则将利用获取命令(参见4.2.9)从BL内容服务器请求给定URL。URL一直代表文件在BL内容服务器上的绝对路径，因此，它必须一直以符号“/”开始。示例：<a href＝”/news/overview.htm”>Nachrichten</a>

sms：	发送SMS(关于细节，参见4.3.1).示例：<form action＝”sms:0190666666？Domina”>
		http：	打开缺省数据频道(WAP)并请求URL(关于细节，参见4.3.2).示例：<a href＝http://www.aps.tv“>Ihr Provider</a>
bl：	动作‘bl’指示URL将被解释为页面命令(3.5.6)示例：<a href＝”bl:back”>Zurück</a>

表3.5-9链接解析

链接中的URL必须不超过256个字符的限制。BL浏览器不需要检查URL的最大长度，内容提供者负责做这个工作。

3.5.5.1SMS链接编码

指示必须发送SMS的链接包含格式化和发送SMS所需的所有数据。BL浏览器必须解释链接以准备SMS：

sms:<TelephoneNumber>[？<MessageText>]

<TelephoneNumber>包含SMS将被发送的号码。问号将消息主体与电话号码分离开并且将被忽略。<MessageText>运载将被发送的消息。消息主体的指示“？<MessageText>”是可选的并且可以缺失。在此情况下，空的SMS将被发送。内容提供者可以使用变量来定制链接(3.5.8.6)。

3.5.5.2HTTP链接编码

BL浏览器必须知道HTTP链接是作为用于请求HTML页面的<a>元素中的超引用或者作为用于完成表格的<form>标签中的动作发生的。用于样式定义中的资源(例如背景图像)的HTTP链接将被浏览器忽略。

在这两种有效情况下，链接根据以下方案被编码：

http:<url>

并且可以包含用于定制的变量(3.5.8.6)。

3.5.6页面命令

BL浏览器支持内置命令的列表，所述命令允许提供者使得来自XHTML代码内的特定于应用的页面导航特征可访问：

命令	处理
		next	请求历史中的下一页面(3.2.4)
back	请求历史中的前一页面(3.2.4)
		home	利用获取命令来请求固定起始页面‘index.htm’(4.2.9)
sync	强迫显示当前同步页面，使用获取命令(4.2.9)，参考[5]

表3.5-10页面命令解析

提供者通过处理指令(3.5.4)或者作为其XHTML标记中的链接(3.5.5)来分配页面命令。

3.5.7表格处理

内容提供者可以使用表格来交互式地收集用户输入。BL浏览器必须支持所有常见的HTML表格元素(3.5.1)。

由于涉及可执行的BL浏览器尺寸的技术限制，应用可以切换到专用表格模式，该模式利用本地的内置输入控制。

3.5.7.1表格模式

BL浏览器在<body>元素的第一孩子是<form>元素的情况下将进入表格模式。如果<form>元素出现在HTML标签层次结构的不同点处，则浏览器可以完全跳过它。

示例：

<body>

     <form>

             ...

     </form>

     <div>...</div>

</body>

在前一示例中，浏览器将进入表格模式，但是可以跳过随后的<div>标签。

在下一示例中，浏览器应该显示分区，但是可以完全跳过该表格。

<body>

     <div>...</div>

     <form>

             ...

     </form>

     <div>...</div>

</body>

3.5.7.2表格元素

将被支持的表格元素在以下列表中列出。未列出的标签可以被浏览器跳过。

标签	父	描述
			div	form	添加描述性文本或图片到表格
input	div	取决于类型属性，定义不同类型的输入字段：text定义公共编辑框password定义公共编辑框，其中输入被进行扰码checkbox定义检查框(群组中非排他性的选择)radio定义无线电按钮(群组中排他性的选择)submit定义文本以完成表格reset定义文本以重置表格
			select	div	定义下拉框

option	select	定义一对文本和值，用于下拉框
			textarea	div	定义具有多行多列的区域，其中用户可以输入长文本

表3.5-11BL表格元素

所有表格元素input，select和textarea将具有分区，作为其在内容提供者的标记中的祖先，但是由于这里不应用样式，因此这在表格模式中不一定需要(对照3.5.7.3)。但是：当应用的未来版本不再依赖专用表格模式时，BL浏览器将知道嵌入在分区中的表格元素以使得内容标记向上兼容。

示例：

以下代码摘录将形成表格，其开始于具有输入字段和下拉框的图片，每个由一行文本命名

<head>

     <sytle>

                .logo{background-image:url(/pic/logo.png)}

     </style>

</head>

<body>

 <form action＝“#“>

     <div class＝“logo“/>

     <div>Name:</div>

     <div><input name＝“name“type＝“text“/></div>

     <div>Ihr Anliegen:</div>

     <div>

      <select name＝“anliegen“>

               <option>Nichts besonderes</option>

               <option>BLUCOM</option>

      </select>

     </div>

 </form>

</body>

3.5.7.3表格样式

在表格模式中，BL浏览器可以省略分配给任意元素(包括<body>标签)的所有样式。唯一例外是应用到<div>元素的background-image定义，其被用于向表格添加图片。但是，背景图像仅仅在分区为空的情况下被显示，即其不包含子元素或文本。否则，图像被省略并且子元素被显示。注意：该行为是特定于表格模式的。

3.5.7.4受限的表格输入

提供者可以将用户输入限制到最大字符数。该行为应用于具有类型“text”或“password”的<input>元素和<textarea>元素两者。

对于<input>元素，限制由属性“maxlength”设置。BL浏览器必须调查该限制，但是输入控制无法在表格模式中被充分地确定尺寸。

对于<textare>元素，限制通过将属性“rows”和“cols”的值相乘来计算出。BL浏览器必须调查该限制，但是textarea控制无法在表格模式中被充分地确定尺寸。

如果操作数之一丢失，则缺省值为1。

3.5.7.5表格完成

表格在用户执行提交动作时完成(对照3.6.6.2)。BL浏览器必须首先存储表格变量(3.5.8.1)，然后调用编码在<form>元素的action属性中的URL以完成表格。

如果action属性丢失或者不包含有效的URL，浏览器则将不请求URL，而是至少必须存储表格变量。

示例：

form元素具有不具有有效的URL的action属性(实际上，“#”是有效的URL，其引用当前显示的页面)。BL浏览器在表格被提交时停留在当前页面上，但是将所有表格数据存储在变量中。

<form action＝“#“>...</from>

在动作指示BL或SMS链接(3.5.5)的情况下，浏览器调用该URL而不结束与表格数据的链接，除非URL本身需要变量替换(3.5.8.6)。

示例：

表格提供了名称为“anliegen”的选择，用户可能已经选择了一个。当表格被提交时，首先变量被存储，然后动作URL利用这些变量被解析。

“BLUCOM”的选择将产生URL“/foo/BLUCOM.htm”。

<form action＝“/foo/$$anliegen$$.htm“>...</form>

在动作指示http链接的情况下，BL浏览器必须遵守经由HTTP的表格发送的公共规则(参见4.3.2.1)。

3.5.8变量

要求在一个页面上输入或确定的动态数据对随后页面可用。与因特网上已知的客户端/服务器情形不同，BL内容服务器无法处理或存储从用户交互产生的动态数据，因此BL浏览器必须能够这样做。

示例：

页面包含表格，该表格提供例如利用无线电按钮从一组项目中选择一个项目的功能。在随后页面中，所选项目将被再次显示并最终被通过SMS发送到内容提供者。

在因特网上，所选项目将被张贴到服务器，该服务器将项目插入动态生成的随后页面上。由于BL内容服务器不能这样做，因此BL浏览器必须可变地存储项目并在需要时将其插入随后页面中以用于显示和SMS文本。

BL浏览器必须提供上下文变量来存储动态数据。内容提供者可以按两种方式声明变量，即利用表格或链接。

3.5.8.1以表格形式的变量声明

在表格中，变量总是通过表格元素input，select和textarea的name属性来声明。表格变量的初始值由input元素或预先选择的option元素的value属性来确定(参见3.5.8.2)。该值可以通过用户的交互而改变。

示例：

在本示例中，分区(<div>标签)被省略：

<form action＝”/form/complete.htm”method＝”GET”>

  <input name＝”start_time”value＝”12:45”type＝”text”/>

  <input name＝”title”value＝”Matrix”type＝”text”/>

  <input value＝”Abschicken”type＝”submif”/>

</form>

BL浏览器必须在用户提交表格时存储/更新表格变量。另外，随后页面被请求，其由跨越form元素的action属性给出。

3.5.8.2缺省值声明

对于所有表格元素，可以通过属性或文本节点来定义缺省值：

元素	标记
		Editbox	<input type＝”text”value＝”default”/>
Cheekbox	<input type＝”checkbox”checked＝”checkead”/>
		Radio Button	<input type＝”radio”checked＝”checked”/>
Textarea	<textarea>default</textarea>
		DropdownList	<select><option selected＝”selected”>default</option></select>

表3.5-12表格元素缺省值标记

缺省值需要在表格首次显示并且附属变量不存在时被分配。如果变量已经具有从任意早先变量声明分配的值(参考3.5.8)，BL浏览器则将忽略缺省值而显示适当文本。

示例：

变量名＝“ME”.在以下表格中，“ME”将被显示在编辑框中，而不是缺省值“Your Name”：

<form>

     <input type＝″text″name＝″name″value＝″Your Name″/>

</form>

变量类别＝“news”。在以下表格中，选项“news”将被预先选择，并且“Nachrichten”将被显示，而不是显示缺省类别“erotic”文本“Erotik &Sex”：

<form>

     <select name＝“category“>

      <option value＝“news“>Nachrichten</option>

       <option value＝“erotic“selected＝“selected“>

                Sex &amp；Erotik

       </option>

      </select>

</form>

3.5.8.3以链接形式的变量声明

提供者可以使用链接来编码变量。提供者扩展URL作为因特网，浏览器将变量数据传递到服务器。扩展以问号“？”开始，然后列出变量名和值的元组(tuple)。变量的名称和值由等号“＝”分开，元组用符号“&”分开。

示例：

<a href＝”/ent/complete.htm？start_time＝12:45&title＝Matrix”>

BL浏览器必须在链接被用户激活时存储/更新变量。在URL请求来自BL内容服务器的数据的情况下(如以上示例所示)，BL浏览器必须省略URL的开始于问号的变量部分。

3.5.8.4变量的存储

上下文(3.2.1)保证变量名不会冲突。变量总是被不带类型地存储(仅文本)。

变量总是“像”在文本表示中一样被使用，对变量的算术操作不被BL浏览器所支持。

一旦变量被存储，它就将是可利用的，直到新的上下文被指示或者应用停止为止。如果浏览器由于STB被调谐到不带有BLUCOM的频道(SERVICE_NOT_AVAILABLE)而丢失上下文，变量则需要被保留。

BL浏览器应该预留5k的存储器以存储变量(名称和值)。如果用于变量的缓冲器超出，则将删除“最旧”的变量。

3.5.8.5变量解析

变量可以通过根据以下规定“$$VariableName$$”在XHTML源代码中的任何位置命名它们而被引用，其中VariableName是从表格或链接变量声明发起的名称。

页面是否需要变量解析受控于内容提供者，内容提供者必须在页面顶部添加处理指令(3.5.4)。如果变量解析被指示，BL浏览器则用附属值替换任意$$VariableName$$代码段，如果该附属值在显示页面前已知的话。

BL浏览器将在以下专用位置上解析变量：

-用于定制图像、对象或页面路径的URLs

-所显示的文本

-表格值

3.5.8.6URL中的变量解析

BL浏览器必须在从服务器请求了URL之前对URL中的变量进行解析。

示例：

<a href＝”/weather/$$CityName$$.htm”>

对变量currentContext.CityName＝“Munich”的解析将产生URL

“/wheather/Munich.htm”

<sytle>

.cityWeather{background-image:url(/w/pic/$$CityName$$.png)}

</style>

对于将从BL服务器请求的图像，该解析将产生URL“/w/pic/Munich.png”。如果URL由于未知的变量值而无法被解析，则BL浏览器将不请求URL，而是显示错误消息。

3.5.8.7文本中的变量解析

BL浏览器必须在文本被显示之前对文本中的变量进行解析(3.6.4)。将被显示的文本被存储在元素<div>，<input>，<option>，<textarea>或<a>的文本节点中。

示例：

<div>Ihr Wetter in $$CityName$$:</div>

对currentContext.CityName＝München的解析将产生“Ihr Wetter inMünchen:”。

如果文本由于未知的变量值而无法被解析，则完全删除变量声明并且显示文本。

3.5.8.8属性中的变量解析

BL浏览器必须在属性的值被评估之前对表格元素的某些属性中的变量进行解析。这只应用于<input>元素的value属性。

如果属性值由于未知的变量值而无法被解析，则完全删除变量声明并且应用属性值。

3.6内容呈现

3.6.1内容处理

以下图给出了以有效的方式处理HTML页面所需的步骤，其中假设页面已经在先前的步骤中被成功的解密。所给出的过程基于通过HTML代码的标签方式迭代。因此，除了本地编码之外，解析器利用SAX或DOM的实现方式也是可能的，其中SAM将比DOM更快。

由于其仅仅是建议性的，因此可以选择不同算法来实现BL浏览器的解析引擎。

图6-应用流程“处理页面”

3.6.1.1请求外部资源

BL浏览器将确定所需外部资源，同时通过HTML标记进行迭代。这在向<body>和<div>标签应用样式时涉及背景图像，而在评估<object>标签的属性时涉及声音。

外部资源的URL可以包含变量。解析器必须在请求URL之前解析变量(3.5.8.6)。

只要可能，图像将被本地缓存，因为它们可能也是随后页面上所需的。只有当在本地缓存中无法获得时，才必须从服务器请求外部资源。另外，处理指令“img”可以指示图像将被刷新(3.5.4)。在此情况下，BL浏览器必须在缓存的图像版本被使用之前检查所涉及的图像以用于更新(对照3.6.3.3)。

在服务器上不存在外部资源的情况下，服务器告诉浏览器重复请求(DATA_NOT_YET_AVAILABLE)还是不重复请求(DATA_NOT_AVAILABLE)有意义。在浏览器已经尝试接收一次每个资源之后，它再次尝试尚不可用的所有丢失的资源(但是跳过不可用的那些)。这是一种迭代，只要浏览器获得丢失资源中的至少一个就会被重复。

最终无法从服务器取得的资源将不被显示(图像)或播放(声音对象)。

3.6.1.2样式应用

样式从<style>标签的文本节点中被提取出。解析器必需知道坏的样式表标记，即解析器必须确保在第一样式必须被应用到任意<body>，<div>元素等之前所有相关样式表都已被处理。

示例：

手持媒体类型是x128并且内容提供者已经将相关样式分裂成3种相关样式

定义(对照3.5.3.1)。

<head>

     <style media＝″x128″><！——styles for type x128--></style>

     <style media＝″x176″><！——styles for type x176--></style>

     <style media＝″x240″><！——styles for type x240--></style>

     <style media＝″x128″><！——more styles for x128--></style>

     <style><！--global style for all media types--></style>

</head>

如果提供者没有提供针对在手持设备上检测到的媒体类型的样式表，则BL浏览器必须仅尝试全局样式。如果全局样式也丢失了，则BL浏览器必须显示不带样式的内容，分配缺省值(3.5.3)。

3.6.1.3解析器行为

在完整页面被解析并且所有外部资源都已被尝试取得之前，页面将不被显示(3.6.1.1)。在页面被显示时，由处理指令定义的所有BL内置动作被执行并且所包含的声音被播放。

同时，BL浏览器将可视地指示解析器行为(3.4.1.3)。

当解析器是活动的时(即准备将显示的页面)，BL浏览器可以拒绝任意用户输入。此外，BL浏览器可以在解析器活动时中止所有分别刷新的查找计时器或不对它们作出反应。

当前显示的页面只要可能就将被保留，至少是可视的。如果需要，BL浏览器可以丢弃存储器中该页面的HTML代码表示以解析新页面。因此，用户既不能与该页面交互，也不能返回到该页面，并且如果新页面的处理失败，则将没有页面被显示。该行为未来将被改变(5.5)。

3.6.2内容的定位和定尺寸

所有布局，即内容的定位和定尺寸是利用分区(<div>元素)来实现的。HTML标记可能包含多个分区，所有分区的父元素都是元素<body>或<form>。

3.6.2.1分区的定位

BL浏览器将从后往前按照它们出现在标记中的顺序显示分区，即每个分区在其前辈之前被提取出。

<div>元素是BL浏览器支持用于定义屏幕上的x和y坐标的样式‘left‘和‘top‘的唯一元素。如果提供者指定这两种样式，则分区独立于分区维护的内容被绝对定位。

如果提供者对于特定<div>元素，省略了样式‘top‘，则分区在y坐标上被相对地定位。BL浏览器随后必须通过总结前一分区的‘top‘+’height‘来确定y坐标。

如果提供者省略了样式‘left‘，则x轴上的位置缺省为0。

3.6.2.2分区的尺寸确定

<div>元素是BL浏览器支持用于定义屏幕上的宽度和高度的样式‘width‘和‘height‘的唯一元素。如果提供者指定这两种样式，则分区的尺寸独立于分区保持的内容被绝对地确定。

如果提供者对于特定<div>元素，省略了样式‘height‘，则分区在y坐标上被相对地扩展。BL浏览器随后必须从分区维护的内容确定高度。如果分区包含文本和图像，则BL浏览器将预测更大值。

如果提供者省略了样式‘width‘，则分区在其包含文本的情况下被扩展到屏幕的右边界。如果分区仅包含图片，则分区的宽度将等于图像尺寸。

分区的尺寸不再被重新确定，但是在关注状态下，链接内部可能对文本或不同尺寸的图像应用不同样式。

3.6.3图像呈现

BL浏览器利用背景图像样式(3.5.3)来支持提供者添加到其标记的图像。通用<img>元素不需要被BL浏览器所支持。

浏览器将能够处理JPEG和PNG图像格式。

3.6.3.1循环图像

图像被分配到HTML主体或分区(3.5.3)。BL浏览器必须确定将被填充以图像的区域。在HTML主体的情况下，该区域是完整的背景画布。在分区的情况下，该区域必须从所应用的样式信息(3.6.2)中计算出。

在任意一种情况下，图像必须被重复以在x和y轴上填充整个区域。BL浏览器必须能够确定图像的原始宽度和高度，以便正确地处理图像的循环再现。

通过使图像循环再现，提供者可以减小图像数据到所需最小值，例如背景中的颜色梯度可以由只有一个像素高的图像提供。该图像在y轴上的重复扩展梯度以填充整个屏幕。这减轻了BL系统的总体负载。

3.6.3.2滚动图像

分配给<body>标签的背景图像被附接resp.以固定到显示背景画布并且从不被滚动，而<div>标签内的图像随页面滚动。

3.6.3.3刷新图像

动态图像可被内容提供者所使用，以便更新一个或多个页面的特定图形部分，而无需提供每一页面的新版本。提供者必须通过设置每个涉及到的HTML页面的处理指令“img＝1”(3.5.4)来明确指示动态图像的使用。

如果图像的刷新被页面所指示，则BL浏览器必须在页面最初被解析和显示时或在对页面的刷新请求被发送时对嵌入在页面中的每个图像尝试刷新。获取命令可被用于向STB请求图像的新版本。如果新版本在服务器侧被呈现，则图像数据被包含在获取响应中，否则服务器指示该图像是最新的(4.2.9)。图像还必须在用户经由选项菜单手动重载页面时被刷新(3.2.5)。

运载刷新的图像的分区的尺寸和位置不改变，即使图像的新版本在宽度和/或高度上不同于其旧版本也是如此。但是，用于循环再现图像的规则在图像被刷新时必须被注意。

3.6.4文本呈现

3.6.4.1文本框

文本将在其中被显示的框由父分区的尺寸确定(3.6.2)。如果框的高度被绝对地确定，则BL浏览器掩蔽不适合该框的所有文本。

如果框的高度被相对地确定，则浏览器在y轴上扩展该框，以使得完整的文本符合该框并在显示时是可视的。框的所需高度就是分区的高度以用于进一步的计算。

3.6.4.2文本样式

提供者可以指定用于维护文本的元素的文本样式(3.5.2.3)。应用到文本的样式是color，font-size，font-weight，font-style，text-decoration，text-align和vertical-align。文本总是利用框的整个尺寸，在水平或垂直方向上都不应用填充。

BL浏览器必须在显示前将样式应用到文本。此外，所应用的样式(例如font-weight＝bold)可能影响文本流的计算。样式定义vertical-align仅在文本框的高度被绝对地确定的情况下被分配，否则应用缺省值top。

文本可以包含变量(3.5.8.7)。解析器必需在对文本长度和流进行任何计算之前解析变量。

3.6.4.3连字符

BL浏览器不需要支持连字符。但是，BL浏览器必须能够识别不适合围绕框的宽度的词。在此情况下，所涉及的词在命中框的边界时在右侧被切掉。

3.6.4.4字符集

没有特定字符集需要定义，因为所有文本都是UTF-8编码的Unicode。另外，BL浏览器必须在显示文本之前解析任意字符实体引用(3.5.2.4)。

3.6.5声音呈现

内容提供者可以利用<object>元素将声音嵌入页面中。

3.6.5.1Mime类型匹配

为了提供不同的声音格式，提供者将使用多个<object>元素，其中每个元素被分配以声音文件的相应mime类型(3.4.1.5)。

BL浏览器将检测HTML标记中的第一声音对象，其格式匹配目标设备的回放性能。

3.6.5.2声音回放

确定的声音文件被从服务器请求并在页面被显示时被播放一次。

BL浏览器不需要向用户提供诸如播放、停止、暂停等的声音控件。一旦提供声音的页面被刷新或重载(例如相对历史)，声音必须被再次播放。

声音的播放不能干扰用户的交互，例如阻挡光标导航。如果用户导航到另一页面，声音必须在显示新页面时停止。

3.6.6表格呈现

BL浏览器的第一版本可以输入专用表格模式以呈现和允许与表格的交互(3.5.7.1)。表格模式利用建立在设备中的控件。因此，不同设备的表格呈现可能有所不同。内容提供者和BL浏览器必须意识到这一点。即使在表格模式中，也应该应用某些指导方针来使得表格呈现稍微可预测。

3.6.6.1表格元素的定位和定尺寸

表格模式由于未应用样式而不知道表格元素的绝对定位。

因此，显示器被暗自划分成一列和多行。每个表格元素(由其分区代表)成为按元素出现在HTML标记中的顺序被显示的行。每一行跨越可用的显示尺寸。

为了确定行的高度，应用与针对相对定位相同的规则(3.6.2.2)。

对于BL浏览器的未来版本，表格模式可能变得陈旧，因此用于定位和定尺寸的相同的规则将被应用到所有分区。

3.6.6.2表格动作

针对表格元素的HTML语法定义了两个动作‘提交’和‘重置’，它们通过任一类型的input元素来声明。内容提供者可以通过分配value属性来针对这些动作定制将被显示的文本。

示例：

<form>

     <input type＝″submit″value＝″Ab Damit″/>

     <input type＝″reset″value＝″Nochmal Neu″/>

</form>

在以上示例中，BL浏览器将针对提交动作显示文本“Ab Damit”并针对重置动作显示文本“Nochmal Neu”。

在表格模式中，由于表格模式不支持链接，因此动作通常被分配给功能键(3.4.2.2)。“重置”动作将被添加到由功能键f1触发的选项菜单，“提交”动作将一直分配给功能键f2。分配到f2的任意页面命令(3.5.6)在此情况下被否决。被否决的页面命令随后应该被移动到选项菜单。

“提交”动作将一直呈现给用户。如果内容提供者在其标记中不提供提交动作，则BL浏览器将分配缺省文本“OK”。

4外部接口要求

我们在这里描述所有接口，从应用的角度看，这些接口是“外部的”。

4.1蓝牙通信

4.1.1蓝牙栈要求

图7中的所有红框单元代表STB和移动设备之间的BLUCOM通信所需的蓝牙组件。所有这些单元还需要在STB侧实现(除了用SDP服务器代替SDP客户端)。

BLUCOM通信协议被定位在蓝牙串行端口轮廓(SPP)之外。

图7-BLUCOM所需的蓝牙协议元素

4.1.2串行端口轮廓通信

BL浏览器使用串行端口轮廓来在蓝牙级上与STB通信。

通信可以是异步的，即浏览器可以将BL请求的发送和BL响应的接收之间去耦合。STB被指定异步地处理最多10个BL请求。服务器将顺序处理所有传入的请求。

但是，BL浏览器将实现用于将请求的发送与响应的接收耦合的机制，以便将异步发送的请求的量限制为可配置的数值。当不同STB的性能可被评估时，合适的数值将在原型阶段被确定。

4.1.3超时处理

BL浏览器必须处理每个被发送的请求的超时。STB被指定在250ms内应答任意请求，该250ms指定从请求检测点到在STB侧的响应发送点之间的持续时间。对于其间的蓝牙通信等待时间，BL浏览器将应用从请求发送点到响应检测点之间的可配置的超时。当若干请求可被异步发送时，该计时器将在任意进一步的响应未完结的情况下根据每次检测到的响应被重置。

针对超时的初始值将是1秒。合适的超时值将在原型阶段被确定。

一旦请求在未接收到附属响应的情况下超时，请求必须被重复。

4.1.4连接丢失

到STB的蓝牙连接可能出于各种原因而丢失：

●STB被关断

●用户偏离STB的蓝牙传输半径

●移动设备由于传入的电话呼叫而中止蓝牙连接

BL浏览器必须检测蓝牙连接的丢失并尝试重新建立连接。一旦连接再次建立，浏览器将恢复实际状态。

4.2BLUCOM通信协议定义

机顶盒(STB)和移动设备之间的接口协议基于XML文件格式。所有xml标签将根据[2]建立。为了保持协议数据量尽可能的小，推荐使用XML短形式来建立XML协议。

示例性长形式：

<InitiateResponse requestId＝”00-02-72-80-EC-FE-00001”retCode＝″OK″>

</InitiateResponse>

示例性短形式(推荐的)：

<InitiateResponse requestId＝”00-02-72-80-EC-FE-00001”retCode＝″OK″/>

存在五种不同命令，它们在以下部分中被描述。

4.2.1标记命令

每个BLUCOM命令将开始于引导的Start Text(STX)字节并结束于End Text(ETX)字节。

相应值被定义：

■对于STX字节：0x02

■对于ETX字节：0x03

示例：

ff02<ImitiateRequest

requestId＝”00-02-72-80-EC-FE-00001”

cprString＝”Copyright by APS，ASTRA Platform Services GmbH”/>ff03

为了避免与从STB取得的二元内容中的值有任何冲突，每个STX或ETX字节之前将放置附加的oxff字节。

关于二元内容中的每个常规oxff，STB在这些字节前面放置另一oxff字节。

示例：

二元代码序列(4字节)：0x01 0xa0 0xff 0x40

将被STB改变到(5字节)：0x01 0xa0 0xff 0xff 0x40

注意：

关于BLUCOM获取命令(4.2.99)，获取响应(GetReponse)命令的长度属性一直指定原始内容的长度(字节数)不包括所有扩展的oxff字节。

根据上述规则，每个0xff可以只具有以下跟随字节之一：

0x02，0x03，0xff

在跟随的0xff的情况下，该0xff可能仅出现在取得扰码的或二元内容数据时，BL浏览器必须读取一个0xff字节以上。

如果BL浏览器在读取0xff之后的新字节时没有检测到有效的跟随字节(0x02，0x03，0xff)，则BL浏览器将中止当前命令的读取并等待新0xff 0x02(STX)组合。所有在这点之前收集的数据可以被丢弃。

STB能够存储最多10个请求，因此，BL浏览器可能不需要在发送第二请求之前等待其第一请求的响应。

4.2.2请求Id分配

所有BL请求和响应都运载参数“请求Id”。请求Id将由BL浏览器分配并允许在异步通信时请求和响应的匹配。

请求Id将包含移动设备的蓝牙MAC地址和运行号以使得该id在整个BLUCOM会话中是唯一的。

RequestId:＝<Bluetooth MAC>-<RunningNumber>

运行号(RunningNumber)必须随发送的每个请求改变，即使请求重复也要如此。但是，运行号的递增不一定需要没有间隙。

4.2.3情况敏感性

所有属性值(包括URL和内容文件名)都是非情况敏感性的。

4.2.4BLUCOM URL/文件名

对于在所有Blucom命令中找到的所有Blucom URL和内容文件名的最大长度被设置为256字节。

4.2.5 DATA_NOT_YET_AVAILABLE与DATA_NOT_AVAILABLE

The BLUCOM协议区分两种内容不可用性的状态。

DATA_NOT_AVAILABLE意思是所请求的内容不可用。

DATA_NOT_YET_AVAILABLE意思是所请求的内容当前不可用，但很快可能就可用了。

4.2.6发起命令(InitiateCommand)

移动设备发送发起请求(InitiateRequest)，该发起请求将被STB使用发起响应(InitiateResponse)来应答。输入参数是版权字符串，它被硬编码在两侧。

示例：

<InitiateRequest

requestId＝”00-02-72-80-EC-FE-00001”

cprString＝″Copyright by APS，ASTRA Platform Services GmbH″/>

备注：

发起命令将被看作所有进一步blucom命令的前提。如果STB无法以retCode＝OK应答发起请求，则所有随后的请求(除了发起请求)将被以retCode＝FAILED应答。

示例：

<InitiateResponse

requestId＝”00-02-72-80-EC-FE-00001”retCode＝″OK″/>

4.2.7同步命令(SyncCommand)

发送同步命令的目的在于使移动设备与STB可用的当前同步页面同步。

注意：只要没有已知的上下文，就必须发送空字符串。

示例：

<SyncRequest

requestId＝″00-02-72-80-EC-FE-00002″

context＝″0x00850001001B″/>

备注：

同步页面元素是可选的，并且对于retCode不等于“OK”，可以不被填充。

示例：

<SyncResponse

 requestId＝”00-02-72-80-EC-FE-00002”

 retCode＝″OK”

 context＝″0x00850001001B″

 refreshInterval＝″10000″>

 <SyncPage name＝″/index.htm″version＝”1”/>

</SyncResponse>

4.2.8刷新命令(RefreshCommand)

发送刷新请求的目的在于向STB请求当前显示的页面的新版本。STB将递送接下来将显示的页面URL。它可以是被请求的页面的当前版本或者是接下来必须显示的同步页面。在显示页面是同步页面的情况下，BL浏览器将存储该URL(包括版本)作为其当前同步页面。

示例：

<RefreshRequest

 requestId＝“00-02-72-80-EC-FE-00003“

 context＝″0x00850001001B″>

 <RefreshPage name＝″/link1.htm″version＝″1″/>

 <SyncPage name＝″/index.htm″version＝″2″/>

</RefreshRequest>

备注：

显示页面元素是可选的，并且对于retCode不等于“OK”，可以不填充。

示例：

<RefreshResponse

 requestId＝”00-02-72-80-EC-FE-00003”

 retCode＝″OK″

 context＝″0x00850001001B″

 refreshInterval＝″10000″>

  <DisplayPage

  name＝″/link1.htm″version＝″2″isSyncPage＝″0″/>

</RefreshResponse>

4.2.9获取命令(GetCommand)

发送获取命令的目的在于向STB请求由元素FileUrl递送的某一页面的内容。

备注：

版本属性是可选的。如果其被省略，则STB将递送针对当前可用版本的内容。否则，STB将仅在其当前版本高于(新于)FileUrl元素递送的版本的情况下发送内容(参见应用流程)。

示例：

<GetRequest

 requestId＝″00-02-72-80-EC-FE-00004″

 context＝″0x00850001001B″>

 <FileUrl name＝″/pic/picl.png″version＝″1″/>

</GetRequest>

备注：

文件数据(FileData)元素是可选的，并且对于retCode不等于“OK”或者retCode等于“DATA_UP_TO_DATE”的响应，可以不被填充。

如果在FileUrl元素中省略了可选版本属性，则DATA_UP_TO_DATE将不再被返回。

在retCode＝“OK”的情况下，数据块被存储在文件数据元素的文本节点中。数据块的第一字节紧接在结束文件数据元素的属性列表的“>”符号之后。

注意：

根据4.2.1，长度属性总是指定包括前导字节(3.3)但不包括所有扩展的oxff字节的原始内容的长度(字节数)。

示例：

<GetResponse

 requestId＝”00-02-72-80-EC-FE-00004”

 retCode＝”OK”

 context＝”0x00850001001B”

 refreshInterval＝”10000”>

 <FileData

  name＝”/pic/pic 1.png”

  version＝”1”

  length＝”1000”>

  <！——data block according to attribute“length”-->

 </FileData>

</GetResponse>

4.2.10获取上下文(GetContext)

发送获取上下文命令的目的在于向STB请求当前的Blucom上下文。另一目的是取得与STB当前被调谐到的服务相对应的服务ID、传输流ID和原始网络ID的DVB值。在任何情况下，后者的值都将独立于该服务上可用的现有Blucom服务被发回。

示例：

<ContextRequest requestId＝″00-02-72-80-EC-FE-00005″/>

备注：

在任意情况下，STB必需独立于频道上的现有Blucom服务递送onid、tsid、sid和可视标志的值。在丢失Blucom服务(retCode＝“SERVICE_NOT_AVAILABLE”)的情况下，属性上下文被省略。

当前，DVB三元组onid，tsid，sid和可视标志不影响BLUCOM功能，因此，BL浏览器可以忽略这些值。

示例：

<ContextResponse

 requestId＝″00-02-72-80-EC-FE-00005″

 retCode＝”OK”

 onid＝”0x0085”

 tsid＝”0x0001”

 sid＝”001B”

 visible＝”1”

 context＝”0x00850001001B”/>

4.3内容提供者交互

本部分覆盖与内容提供者直接交互的所有浏览器功能，不包括蓝牙通信路径。

4.3.1SMS

内容提供者可以使用专用链接语法(3.5.5)来编码在链接被激活时将被BL浏览器发送的SMS。

4.3.1.1SMS发送

一旦SMS链接被解释并且消息被准备好，BL浏览器就将其发送。移动设备可以弹出对话框以向用户要求对发送SMS的确认。

BL浏览器必须等到设备返回关于成功的SMS发送或发送失败的状态。在等待该状态的同时，BL浏览器将不接受任何用户输入，而是显示活动指示符

(3.4.1.3)。当移动设备确实有必要实现用于发送SMS的超时时，BL浏览器不需要跟踪超时本身。

一旦设备返回错误，BL浏览器将显示错误消息并停留在当前页面上。

4.3.1.2SMS跟随页面

一旦设备指示成功的SMS发送，BL浏览器就请求和显示通过<a>或<form>标签的“target”属性编码的跟随页面(3.5.5.1)。如果没有指定目标，则BL浏览器显示SMS被成功发送的消息并且停留在当前页面上。

示例：

<form action＝“sms:+4918756273？Forum entry＝$$fb$$“

   target＝“/forum/thanks.htm“forum>

      <div><textarea name＝“fb“/>Ihr Eintrag ins Forum</div>

      <div><input type＝“submit“value＝“Eintragen“/></div>

</form>

一旦以上示例中的表格经由“Eintragen”被确认，action属性中的URL就被解析成“sms:+4918756273？Forum entry＝Ihr Eintrag ins Forum”(缺省值)。链接指示将被发送到+4918756273的SMS，“Forum entry＝Ihr Eintrag ins Fo-rum”作为消息文本。一旦SMS被成功发送，浏览器就请求页面“/forum/thanks.htm”并显示它。

4.3.2WAP

内容提供者可以使用公共链接语法(3.5.5)来指示特定HTML页面将使用HTTP协议经由WAP被获取。提供者将主要使用该特征来从表格输入(3.5.7.5)收集个性化用户数据。

4.3.2.1HTTP请求

任何利用HTTP请求发送的URL都必须被URL编码。[4].

在HTTP链接作为<a>元素中的超级引用出现的情况下，BL浏览器简单地发送链接的URL部分，作为HTTP GET请求。

在HTTP链接作为完成表格的动作出现的情况下，内容提供者可以选择由<form>元素的“method”属性指示的方法“GET”或“POST”发送数据。如果method属性丢失，POST则将是缺省值。

在方法“GET”的情况下，动作URL将利用表格数据(url编码的)被扩展。在方法“POST”的情况下，表格数据(如果存在)在HTTP请求的主体中被发送。

示例：

<form action＝“http://www.aps.tv/feedback.htm“method＝“GET“>

     <div><input name＝“name“type＝“text“value＝“Me“/></div>

     <div><textarea name＝“feedback“/>Sehr Gut</div>

</form>

在以上示例中，表格的提交将导致URL“http://www.aps.tv/feedback.htm？-name＝Me&feeback＝Sehr+gut“被调用，只要用户不改变表格缺省值即可。

注意：

在提供者使用与方法“GET”一起的变量的情况下，BL浏览器不应将表格数据本身应用于URL。提供者随后负责这样做。因此，在下一示例中的action链接将被解析为“http://www.aps.tv/feedback.htm？name＝Me”，省略反馈值。

<form action＝“http://www.aps.tv/feedback.htm？name＝$$name$$“

method＝“GET“>

     <div><input name＝“name“type＝“text“value＝“Me“/></div>

     <div><textarea name＝“feedback“/>Sehr Gut</div>

</form>

4.3.2.2HTTP响应

内容提供者必须确保从BL平台外部经由HTTP请求的内容是符合BL编码标准的HTML页面。所有其他数据可被BL浏览器所省略。浏览器将评价必须是“text/html”的HTTP响应的MIME/Type。

返回的HTML页面未经加密，此外不运载任何前序字节(对照3.3)。

4.3.2.3WAP通信

一旦用户请求HTTP链接，BL浏览器就将打开缺省数据通道(例如GPRS)。移动设备或浏览器自身必须请求用户对打开通道的确认。

虽然数据通道打开了，但是BL浏览器或移动设备自身必须可视地指示连接。BL浏览器可以在成功地取得所请求的数据或发生错误时关闭连接。

一旦通道打开，BL浏览器就发送HTTP请求。在等待响应时，浏览器将不对任何用户输入作出反应，也不对刷新或查找计时器的时间流逝作出反应。动作指示符同时被显示(3.4.1.3)。

HTTP获取请求可以类似于本地BL获取命令(4.2.9)被处理，只是应用更长的超时(例如10秒)。

一旦HTTP响应被接收到，HTML页面就被提取出，并且解析器被激活以处理页面(3.6.1)。如果发生错误或响应时间超时，则显示错误消息(类似于“DATA_NOT_AVAILABLE”)。

4.3.2.4WAP上下文

经由WAP取得的任意HTML页面不属于任何上下文。因此，这些页面从不被添加到浏览器的历史中，即使在被处理指令指示时也如此(3.2.4)。

此外，这些页面从不被刷新，即使在被处理指令指示时也如此(3.2.2.2)。当页面被显示时，BL浏览器将一直在刷新计时器的时间流逝时发送同步命令到BL服务器。

5未来方面

本章覆盖了已经论述但不需要在BL浏览器的原型中实现的特征。这里所提到的功能用于促进对应用核心组件的设计中的所需特征的敏感性。

5.1持续性

持续性将被引入以在手持设备上存储包括嵌入图像的页面以用于离线读取。

BL浏览器将支持附加处理指令(3.5.4)，其允许内容提供者例如在新闻入口的范围内实现诸如“保存”和“加载”之类的附加页面命令(3.5.6)。用户可以使用该命令来本地地处理被存储的BL内容。

指令	值	缺省	处理
				Save	action|option		确定被指示的页面命令如何可被用户经由功能键(3.4.2.2)来访问
load	action|option

表5.1-1用于持续性的处理指令

命令	处理
		保存	永久地存储被显示的页面
加载	恢复持续的页面

表5.1-2用于持续性的页面命令

由于BL内容的持续性对本地文件系统有影响，因此一旦目标设备支持，可用的闪存大小就将被实现。

5.2嵌入式表格

在未来版本中，BL浏览器将实现表格控件本身，以充分支持带样式的表格，从而不再需要专用的表格模式。

内容提供者随后可以在HTML内容标记中的任何地方嵌入表格元素，假设针对表格的XHTML语法规则被考虑的话。

5.3本地化

将来，应用将在单一版本中运载不同的本地化。随后语言根据移动设备设置被确定或者由用户选择。

5.4版本控制文件

与BL浏览器的原型不相关，而是在应用的第一版本中实现：

一旦BL浏览器已经成功地处理了认证，它就必须获取文件名为“/BlVersion.xml”的内容(4.2.9)。该文件包含关于BL浏览器版本是否是最新的以及在版本不匹配的情况下是否推荐或者甚至要求更新的信息。

5.4.1语法BIVersion.xml

BlVersion.xml基于XML文件格式。

BIVersion.xml包括曾经采用的所有BL浏览器版本的历史。版本标签的列表按降序排列。BL浏览器应用必须找到与其自己匹配的正确版本号，然后必须评价updCtrl参数。

■UPD_RECOMMD

用户必须被告知推荐更新BL浏览器应用。如果用户拒绝，则BL浏览器将继续。否则用户将被建议停止BL浏览器，以便开始应用下载。

■UPD_REQUIRED

用户必须被告知要求更新BL浏览器应用。如果用户拒绝，则BL浏览器应当停止。

注意：版本控制文件的全部范围不是完全固定的，必须被再次论述。

5.5增强的可用性

一旦BL浏览器的原型可获得，增强的可用性就将被评价。

5.5.1滚动

浏览器将对所有页面实现平滑滚动。

5.5.2页面维护

在解析将被显示的新HTML页面时，当前显示的页面将被完全地保持，以使得用户仍旧能够与该页面交互。交互包括关注的导航以及页面的滚动和激活链接。所述交互还希望用于静态行为，例如丢失资源的加载或刷新图像的更新。当用户在新页面准备好时激活链接时，准备好的页面被放弃，已经取得的针对该页面的资源可被清除并且激活的链接被执行。

5.5.3优先内容维护

浏览器将发送针对当前显示的页面中的所有BL链接的优先获取请求。一旦用户选择链接之一，取得的页面就被解密并在后台被处理，以便加速页面的显示。

优先可以包括对历史中的第一页面的维护。

Claims (26)

1.一种用于向移动数据处理单元(200)发送数据的方法，该方法包括以下步骤：

a. 利用数字音频和/或电视接收设备(100)接收数据，其中所述

数据被包括在数字音频和/或电视信号的传输流中；

b.从所述数字音频和/或电视信号的传输流中提取出所述数据；

以及

c.利用所述数字音频和/或电视接收设备(100)发送电磁信号，以将所述提取出的数据从所述数字音频和/或电视接收设备(100)发送到所述移动数据处理单元(200)，所述方法的特征在于：

d.所述提取出的数据是响应于从所述移动数据处理单元(200)到所述数字音频和/或电视接收设备(100)的周期性请求被从所述数字音频和/或电视接收设备(100)发送到所述移动数据处理单元(200)的。

2.如权利要求1所述的方法，其中来自所述移动数据处理单元的所述周期性请求用于使在所述移动数据处理单元(200)中的数据的至少一部分与存储在所述数字音频和/或电视接收设备(100)中的一组新数据同步。

3.如权利要求2所述的方法，其中所述周期性请求被自动执行。

4.如权利要求2或3所述的方法，其中所述周期性请求之间的刷新间隔可以被改变。

5.如权利要求4所述的方法，其中所述刷新间隔的值优选地与所述同步的新数据一起被从所述数字音频和/或电视接收设备(100)发送到所述移动数据处理单元(200)。

6.如前述权利要求中的任意一个所述的方法，其中所述移动数据处理单元(200)可以响应于用户输入异步地发布对将从所述数字音频和/或电视接收设备(100)发送的数据的手动请求。

7.如前述权利要求中的任意一个所述的方法，其中所述数字音频和/或电视信号的传输流的内容和所述被包括的数据的内容是相关的。

8.如权利要求7所述的方法，其中所述传输流包括针对多个频道的数字音频和/或电视信号，并且其中从所述传输流中提取出并被发送到所述移动数据处理单元(200)的数据取决于所述数字音频和/或电视接收设备(100)被调谐到的频道。

9.如权利要求8所述的方法，其中针对所述数字音频和/或电视接收设备(100)被调谐到的第一频道的提取出的数据被存储在所述数字音频和/或电视接收设备(100)的存储器中。

10.如权利要求9所述的方法，其中除非将被发送到所述移动数据处理单元(200)的针对所述第一频道的提取出的数据与针对第二频道的提取出的数据相同，否则在从所述第一频道改变到所述第二频道的情况下，存储在所述存储器中的数据被清除。

11.如权利要求9所述的方法，其中在从所述第一频道改变到第二频道的情况下，存储在所述存储器中的数据被保留。

12.一种用于向移动数据处理单元(200)发送数据的方法，包括以下步骤：

a.将所述将被发送的数据包括在将被广播的数字音频和/或电视信号的传输流中；

b.以适合于数字音频和/或电视接收设备(100)接收所述数字音频和/或电视信号的数字格式广播带有所述被包括的数据的所述数字音频和/或电视信号的传输流，以提取出所述被包括的数据并将它们发送到所述移动数据处理单元(200)，所述方法的特征在于：

c.所述被包括的数据适合于响应于从所述移动数据处理单元(200)到所述数字音频和/或电视接收设备(100)的周期性请求而被发送。

13.如权利要求12所述的方法，其中所述被包括的数据使得所述移动数据处理单元(200)的所述周期性请求之间的刷新间隔改变。

14.如权利要求12或13所述的方法，其中所述方法步骤a.和/或b.响应于所述数据的提供者接收到来自所述数字音频和/或电视接收设备(100)和/或所述移动数据处理单元(200)的信号而被执行。

15.如权利要求1到14中任意一个所述的方法，其中所述刷新间隔的长度为1s≤t≤10s。

16.一种数字音频和/或电视接收设备(100)，包括：

a.第一接收单元(5)，其接收数字音频和/或电视信号的传输流以显示在电视和/或无线电系统(102)上，所述数字音频和/或电视信号的传输流包括附加数据；

b.提取单元(6)，其从所述数字信号的传输流中提取出所述附加数据；

c.发送单元(4)，其将所述提取出的附加数据发送到外部的移动数据处理单元(200)，所述数字音频和/或电视接收设备的特征在于该设备还包括：

d.第二接收单元，其适合于接收来自所述移动数据处理单元(200)的周期性请求以发起所述提取出的附加数据的发送。

17.如权利要求16所述的数字音频和/或电视接收设备(100)，还包括存储器，其适合于响应于来自所述移动数据处理单元(200)的所述周期性请求使所述移动数据处理单元(200)中的数据与新数据同步。

18.如权利要求17所述的数字音频和/或电视接收设备(100)，还适合于优选地与发送所述同步的新数据一起改变所述周期性请求之间的刷新间隔。

19.如权利要求16到18中任意一个所述的数字音频和/或电视接收设备(100)，其中所述传输流包括针对多个频道的数字音频和/或电视信号，并且其中针对所述数字音频和/或电视接收设备(100)被调谐到的第一频道的将被发送到所述移动数据处理单元(200)的提取出的数据被存储在所述数字音频和/或电视接收设备(100)的存储器中。

20.如权利要求19所述的数字音频和/或电视接收设备(100)，还适合于：除非将被发送到所述移动数据处理单元(200)的针对所述第一频道的提取出的数据与针对第二频道的提取出的数据相同，否则在从所述第一频道改变到所述第二频道的情况下，存储在所述存储器中的数据被清除。

21.如权利要求19所述的数字音频和/或电视接收设备(100)，还适合于在从所述第一频道改变到第二频道的情况下保留存储在所述存储器中的数据。

22.一种移动数据处理单元(200)，包括：

a.第一收发机单元(15)，用于与移动电话网络通信；

b.第二收发机单元(9)，用于与数字音频和/或电视接收设备(100)通信；

c.带有指令的控制装置，其使得所述第二收发机单元(9)向所述数字音频和/或电视接收设备(100)周期性地发送请求，所述数字音频和/或电视接收设备(100)发起附加数据到所述移动数据处理单元(200)的所述第二收发机(9)的发送，其中所述附加数据与数字音频和/或电视信号一起被所述数字音频和/或电视接收设备(100)所接收。

23.如权利要求22所述的移动数据处理单元(200)，其中来自所述移动数据处理单元的周期性请求用于使所述移动数据处理单元中的数据与存储在所述数字音频和/或电视接收设备(100)中的新数据同步。

24.如权利要求23所述的移动数据处理单元(200)，还适合于接收后续的周期性请求之间的刷新间隔的值，该值优选地作为同步数据的一部分发送自所述数字音频和/或电视接收设备(100)。

25.如权利要求23或24所述的移动数据处理单元(200)，其中所述控制装置包括用于响应于用户输入而异步地发布对更多数据的附加请求的指令。

26.如权利要求22到25中任意一个所述的移动数据处理单元(200)，其中所述控制装置还包括用于使所述第一收发机单元(15)向所述数字音频和/或电视信号的提供者发送对所述附加数据的请求的指令。

Images