CN1625882A - 定义数字项适配的协商机制的方法 - Google Patents

定义数字项适配的协商机制的方法 Download PDF

Info

Publication number
CN1625882A
CN1625882A CNA038030268A CN03803026A CN1625882A CN 1625882 A CN1625882 A CN 1625882A CN A038030268 A CNA038030268 A CN A038030268A CN 03803026 A CN03803026 A CN 03803026A CN 1625882 A CN1625882 A CN 1625882A
Authority
CN
China
Prior art keywords
peers include
dia
message
description
peers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CNA038030268A
Other languages
English (en)
Inventor
黄仲阳
申省梅
吉明
妹尾孝宪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Holdings Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Publication of CN1625882A publication Critical patent/CN1625882A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4541—Directories for service discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1068—Discovery involving direct consultation or announcement among potential requesting and potential source peers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85403—Content authoring by describing the content as an MPEG-21 Digital Item
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明涉及数字项适配，特别是涉及在不同的MPEG－21对等端之间需要协商的MPEG－21数字项适配(DIA)。定义了广告元数据，以保留数字项适配描述，例如使用环境描述、BSDL描述、XDI描述以及在其描述元素中的MPEG－7媒体描述。由此，定义了类属DIA协商机制(协议)，使用了用于DIA描述发送/交换/更新的基于一些XML计划的消息。还定义了类属和高层DIA协商消息，所述消息独立于任何网络协议，因此，可以将用于数字项适配的描述直接包含在所定义的用于登记、发送和更新的消息中，以实现在数字项适配中所涉及的那些应用中的DIA描述协商。

Description

定义数字项适配的协商机制的方法
技术领域
本发明涉及数字项适配，特别是涉及在不同的MPEG-21对等端之间需要协商的MPEG-21数字项适配(DIA)。
背景技术
数字项适配(DIA)是一种新定义的MPEG-21部分，用于指定用于适配数字项的描述符工具。其主要关注于“终端和网络”，DIA的总体目标是通过将用户与网络和终端安装、管理和实现问题相屏蔽，来实现对高级多媒体内容的可互操作的透明访问。这将能够根据需要来提供网络和终端资源，以形成能够创建并共享多媒体内容的用户互通，始终具有所约定/协议的质量、可靠性和灵活性，允许多媒体应用程序连接用户的不同集合。
当前的DIA描述已经定义了使用环境描述符工具，所述工具指定了用于描述用户特性、终端性能、网络特性和自然环境特性等的工具；会话移动性XDI(上下文(context)数字项)描述工具；以及BSDL(比特流语法描述语言)描述。所有这些描述均是在客户端或服务器侧的数字项配置所需的工具。
为了使内容适配变得使用，非常需要对等端之间的DIA传输和协商，以便按照可互操作的方式来定义。需要定义协商机制和协议，以有助于将多媒体资源传送到不同终端。存在几种需要数据适配的情景，例如对于不同终端的单向广播应用，用于内容适配的交互式双向应用，到不同网络的实时流适配，等等。其中，一旦需要，用于终端、网络的DIA描述、以及用户选项(user preference)必须交换和协商。应当定义DIA协商机制，以便于诸如终端、服务器、网关、代理等对等端之间的通信，以便实时地发送DIA描述和更新DIA描述，通过以下的MPEG-21DIA描述以及这里要定义的MPEG-21协商机制的集合，能够建立通用多媒体框架，该框架能够处理不同的多媒体终端、网络、以及具有内容适配的使用环境。
本发明试图解决以下问题：
能够在任意多媒体终端和对等端之间交换、更新和发送DIA描述，所述任意多媒体终端和对等端运行于具有不同操作系统的不同物理机器上，并且工作于不同的安全、应用程序和工具环境中，但是在高层的基础上建立协商。
无论终端和对等端使用何种网络协议，独立地进行对等端之间的DIA描述的协商，从而有效并无缝地实现数字项适配。
通过在两个所包含的对等端中实现协商机制，将会使数字项动态地适配不同的终端、网络和用户。
发明内容
在本发明的一方面，提供了一种手段，用于定义利用XML计划(schema)的广告元数据的位置，以使其包括MPEG-21 DIA描述和多个其它类属消息，针对对等端解析器、对等端发现、信道绑定和端点路由。这里用作高层协议定义，以便根据端对端对等连接，使用对等端发现来交换或更新DIA描述信息。
更具体地，提供了一种用于定义数字项适配(DIA)的协商机制的方法。该方法包括：根据针对作为MPEG-21兼容终端的对等端的标准化DIA描述计划来创建MPEG-21 DIA描述，所述描述包括至少下列之一：使用环境、XDI(上下文数字项)和BSDL(比特流语法描述语言)描述，；将DIA描述设置于适当的位置，用于在协商协议中的交换、发送或更新；指定和定义某些类属协议消息计划，以实现类属协议的功能；以及使用所定义的协议，交换、更新或发送DIA描述。
以上方法包括指定和定义灵活的广告元数据描述计划，以描述不同类型的资源，包括对等端、对等域和信道中的至少一个；以及将DIA描述合并到广告元数据中。在这种情况下，所述方法还包括实现广告元数据描述计划解析器，以解译对等端的广告元数据描述。
以上方法可以包括通过使用信道绑定协议通过使用端点路由协议来路由协议消息；以及通过使用对等端解析器协议来使对等端彼此了解，来建立信道以建立在对等域中需要交换、发送或更新DIA描述的对等端的连接。
以上方法可以包括根据对等发现协议来使能本质发现消息的基本结构，以便查询和响应包括DIA描述的广告元数据，交换、更新或发送DIA描述。
在第一方面的方法中，指定和定义类属协议消息包括在实现所有协议中包含的所有对等端中实现消息计划解析器。
在本发明的第二方面，提供了一种手段，用于定义类属高层DIA协商消息，所述协商消息与多种网络协议相绑定，并携带了MPEG-21DIA描述，以便根据基本网络连接来登记、发送或更新DIA描述信息。
更具体地，提供了一种用于定义数字项适配(DIA)的协商机制的方法。所述方法包括：根据类属高层对等协议和实际网络协议来创建需要DIA协商的对等端之间的连接，所述对等端是MPEG-21兼容终端；根据针对对等端的标准化DIA描述计划来创建MPEG-21 DIA描述，所述描述包括至少下列之一：使用环境、XDI(上下文数字项)和BSDL(比特流语法描述语言)描述，；指定和定义包括DIA描述和DIA描述元素的类属和本质DIA协商消息，用于实现协商机制；以及利用需要DIA协商的对等端之间的DIA协商消息来登记、发送或更新DIA描述。
以上方法可以包括将DIA描述指定为Reference，使用“Reference”以指向位于万维网的DIA描述的实体，或将DIA描述指定为消息净荷，使用DIADescription元素下的“DIADescriptionData”，。
以上方法包括当第一对等端希望向第二对等端发或更新当前DIA描述时，利用第一对等端的消息ID来建立用于第一对等端的登记消息；将登记消息发送到第二对等端；以及从第二对等端向第一对等端发送具有相同消息ID和消息类型的响应消息以及“响应”信息，所述“响应”信息包含“真”，表示第二对等端准备好接收来自第一对等端的DIA描述，或“假”，表示第二对等端以任意原因拒绝接收来自第一对等端的DIA描述。
以上方法包括利用第一对等端的消息ID来建立用于第一对等端的发送消息，从而将当前DIA描述发送到第二对等端；将发送消息发送到第二对等端，以及从第二对等端向第一对等端发送具有相同消息ID和消息类型的响应消息以及“响应”信息，所述“响应”信息包含“真”，表示从第一对等端到第二对等端的所发送DIA描述的成功接收，或“假”，表示由于任意原因的从第一对等端到第二对等端的所发送DIA描述的不成功接收。
以上方法包括利用第一对等端的消息ID来建立用于第一对等端的发送消息，从而更新到第二对等端的当前DIA描述；将更新消息发送到第二对等端；以及从第二对等端向第一对等端发送具有相同消息ID和消息类型的响应消息以及“响应”信息，所述“响应”信息包含“真”，表示从第一对等端到第二对等端的所发送DIA描述的成功接收，或“假”，表示由于任意原因的从第一对等端到第二对等端的所发送DIA描述的不成功接收。
在第二方面的方法中，指定和定义类属和本质DIA协商消息计划包括在交换DIA描述中包含的所有对等端中实现DIA协商消息计划剖析器。
使用第一手段，根据所定义的广告XML元数据计划，通过使用所定义的协商协议能够发送、交换或更新用户特性、终端可容性、网络特性、自然环境特性的描述，XDI描述，和BSDL描述。在“具体实施方式”的第1部分中进一步进行了阐述。
使用第二手段，根据所定义的类属协商消息，能够登记、发送或更新用户特性、终端可容性、网络特性、自然环境特性的描述，XDI描述，和BSDL描述。在“具体实施方式”的第2部分中进一步进行了阐述。
通过实现与多个网络协议相绑定的高层通信消息来建立MPEG-21对等端。在对等端中还需要实现消息解析器。
本发明设计用于具有所定义消息的协商机制，从而用于与市场上不同类型的设备的内容适配，并且通过提供用于包括所定义广告元数据的协议的所有高层类属消息，解决了设计MPEG-21数字项适配协商中使用的标准方式的问题。
附图说明
图1示出了具有DIA协商的多媒体分布网络。
图2示出了DiscoveryQuery XML消息示例。
图3示出了具有更新DIA实例的DiscoveryQuery XML消息。
图4示出了用于协商的MPEG-21类属DIA消息层。
图5示出了两个对等端之间的MPEG-21类属DIA协商消息流程图。
图6示出了DIA描述协商消息计划的语法和语义的框图。
具体实施方式
图1所示是现有技术，示出了需要在网络中的任意相连设备(模块1.2，1.3，1.4)之间发送的MPEG-21 DIA描述(模块1.1)，所述网络的范围从无线蜂窝电话和PDA到PC和服务器/网关/代理(模块1.5，1.6，1.7)。
通常，这里，对于模块1.7中的数字多媒体服务器，无法将具有相同格式的相同内容传送到不同种类的设备。即使能够按照对等方式连接这些设备，如果没有定义协商机制，根据其不同的能力和甚至用户选项，仍然不能够将相同的内容适配到不同种类的设备。这将限制内容适配，使媒体访问应用的范围变窄。
1.根据类属协议的DIA描述的协商
在这部分，我们试图示出类属对等协商协议，以便有效地交换所需的DIA描述，需要在特定网络条件和用户选项下，将内容适配到终端。该协议应该非常适合正在开发的目前和将来的网络协议。
应当注意，在客户端侧DIA描述的自动/手动配置不是在本发明中需要讨论的项。例如，无论在本发明按照何种方式描述，通过所接收的用于会话移动的相关XDI(上下文数字项)，能够重构CDI(内容数字项)会话。但是，当将XDI描述用于在本发明所定义的基于协议的DIA协商元数据时，终端合服务器之间的XDI请求和传送变得较为实际，并且能够实现数字项的会话移动。
这里简要解释一些术语(部分2也可以使用对等端的概念)：
对等端：对等端是能够实现协议的任意网络化设备。每个对等端与其它所有对等端相独立并异步地进行操作。由于特殊关系(网关或路由器)，一些对等端更依赖于其它对等端。对等端可以在网络上彼此发现以构成对等域。对等端可以向其它对等端发布资源。对等端点是一种唯一地识别对等网络接口的URI。由对等端使用对等端点来建立两个对等端之间的直接点对点连接。对等端可以必须使用一个或多个中间对等端来将消息路由到另一个对等端。由唯一的对等端ID来唯一地识别每个对等端。
对等域：对等域是具有某些共同利益的对等端的集合。还可以静态地预定义对等域。对等端自己组织为对等域。通过唯一的对等域ID也可以识别每个对等域。协议描述了对等端如何发布、发现、加入并监视对等域。
信道：信道是用于在端点上的服务或应用程序之间发送和接收消息的虚拟通信管道。信道提供了对等端点传输上的网络抽象。对等端点与能够用于从另一个对等端发送和接收数据的可用对等网络接口相对应。信道提供了独立于任何单一的对等端位置和网络拓扑的虚拟输入和输出邮箱的错觉。信道能够提供通信的点对点模式。
消息：使用信道发送且位于在端点之间的信息被打包为消息。将协议指定为对等端之间交换的XML消息的集合。使用XML消息来定义协议允许多种不同种类的对等端加入协议。每个对等端按照适于其能力和作用的最佳方式来自由地实现协议。
广告元数据：通过广告元数据来表示所有资源，例如对等端、对等域、信道和业务。
DIA元数据：在广告元数据描述中，通过DIA元数据来表示所有数字项适配描述，例如使用环境描述、BSDL描述、XDI(仅在DID中所包装的DIA描述)以及MPEG-7媒体描述。
ID：在所定义的协议内，存在多个需要唯一识别的实体(对等端、对等域、管道和内容)。ID唯一地识别实体并充当参考该实体的规范方式。URI用于ID的表达。
在MPEG-21中定义的协商协议包括一组开放协议，且目标在于按照类属方式，利用穿过公共网络的对等端来传送DIA元数据的对等通信。协议中所定义的对等端创建了虚拟网络，其中，即使某些对等端在防火墙后面或在不同的网络传输上，任意对等端也能够直接与其它对等端和资源交互。所定义的协议应当满足可互操作性的要求，这意味着相互连接的对等端必须横跨不同的系统和团体，彼此容易地通信。此外，对等网络应当支持不同的编程语言、操作系统和在TCP/IP、HTTP、蓝牙、家庭PDA和多个其它协议上实现的网络平台。此外，其可以支持广播数字设备，包括CE、PDA、设备、网络路由器、PC、服务器和存储系统等等。
协议是针对对等网络计算而专门设计的机制集合。使用这些机制，对等端能够协同操作，以形成独立于其在网络中位置的自组织和子配置对等域，并且无需集中管理的基础设施。
对等端使用协议来通知其DIA元数据并从其它对等端发现可用的网络资源(业务、信道等)。对等端形成并加入对等域，以创建特定的关系。对等端协同操作以路由允许完全对等连接的消息。所有协议允许对等端进行通信，而无需理解或管理潜在的复杂而动态的网络拓扑。该协议允许对等端动态地将消息横跨多个网络跳跃而路由到网络中的任意目的地。每个消息携带了网关对等端的完整或部分顺序表，通过该表来路由消息。如果路由信息是不正确的，则中间对等端能够有助于动态地发现新路由。
协议是共同工作以实现对等端之间发现、组织、监视和通信的多种机制，即以下机制：
-一种机制，对等端通过该机制能够向一个或多个对等端发送查询并接收针对查询的一个(或多个)响应。该机制实现了查询/响应协议。将该响应消息通过包括在消息主体中的唯一ID来与查询相匹配。当发现了对等端时，可以将查询发送到该对等端。
-一种机制，对等端通过该机制能够广告其自身的资源，并发现来自其他对等端的资源(对等域、信道和另外的对等端)。使用广告元数据来描述并发布每个对等资源。将元数据表示为XML文件。
-一种机制，对等端通过该机制能够建立一个或多个对等端之间的虚拟通信信道。信道提供了对等端之间的基础通信机制。
-一种机制，对等端通过该机制能够发现用于将消息发送到另一个对等端的路由。如果对等端A希望将消息发送到对等端C，而不存在A和C之间的之间路由，则对等端A需要发现一个或多个中间对等端，以便将消息路由到C。
使用公共消息层来实现所有这些协议。
1.1基于协议消息的XML计划
对等端解析器：对等端解析器允许将类属查询分布到所述域内的一个或多个处理程序，并使其与响应相匹配。将每个查询寻址到特定的处理程序名称。该处理程序名定义了查询的特定语义及其响应，但不与任意特定对等端相关联。可以由域中任意数目的对等端来接收给定的查询，如果在该对等端上定义了这样的查询名称，则根据处理程序名称进行处理。对等端解析器的目的在于提供本质类属查询/响应基础结构，用于建立高层解析器服务。在许多情况下，高层服务可以更好地了解域拓扑。
查询消息(QueryMessage)
<xs:complexType name＝“ResolverQuery”>
   <xs:sequence>
      <xs:element name＝“SrcPeerID”type＝“xs:anyURI”/>
      <xs:element name＝“HandlerName”type＝“xs:string”/>
      <xs:element name＝“QueryID”type＝“xs:string”/>
      <xs:element name＝“Query”type＝“xs:anyType”/>
</xs:sequence></xs:complexType>
HandlerName：指定应当如何处理该查询的字符串。
SrcPeerID：发起查询的对等端的ID。
QueryID：查询ID。该ID应当包括在针对该查询的响应中。
Query：查询结构。
响应消息(ResponseMessage)
<xs:complexType name＝“ResolverResponse”>
   <xs:sequence>
   <xs:element name＝“HandlerName”type＝“xs:string”/>
   <xs:element name＝“QueryID”type＝“xs:string”/>
   <xs:element name＝“Response”type＝“xs:anyType”/></xs:sequence></xs:complexType>
HandlerName：指定应当如何处理响应。
QueryID：对其作出响应的查询的ID。
Response：响应结构。
端点路由：网络中所定义协议的连接可以是瞬时的，且消息路由是非确定的。这里，端点路由定义了通过路由业务来处理的一组请求/查询消息，以有助于对等端路由消息到达目的地。当请求对等端向给定的对等端点地址发送消息时，其在本地高速缓冲器中查找是否具有到该对等端的路由。如果其没有发现路由，则向路由解析器发送请求路由信息的可用对等路由器的查询消息。对等路由器提供高速缓存路由信息的能力，以及桥接不同的物理或逻辑网络。当对等路由器接收到路由查询时，如果其知道目的地，则通过返回路由信息作为跳跃枚举来应答该查询。可以将该消息发送到第一路由器，该路由器将使用路由信息来把该消息路由到目的对等端。在任意点处，路由信息可能是过时的，请求当前路由器找到新路由。这里所定义的端点路由用于提供用于操纵和更新路由的用户定义路由服务所必需的接通(hook)。两个正在通信的对等端可能需要使用对等路由器，以便根据其网络位置来路由消息。典型地，对等路由器将高速缓存路由信息。任意对等端能够向对等路由器询问路由信息。对等域中的任意对等端都可以被称为对等路由器。
查询消息(QueryMessage)
<xs:complexType name＝“EndpointRouteQuery”>
   <xs:sequence>
      <xs:element name＝“DestPeerID”type＝“xs:anyURI”/>
      <xs:element name＝“Cached”type＝“xs:boolean”/>
</xs:sequence></xs:complexType>
DestPeerID：目的对等端的ID。
Cached：当应答可以是高速缓存的应答时，为真；当应答肯定不来自高速缓冲器时，为假。
应答消息(AnswerMessage)
<xs:complexType name＝“EndpointRouteAnswer”>
   <xs:sequence>
      <xs:element name＝“DestPeerID”type＝“xs:anyURI”/>
      <xs:element name＝“RoutPeerID”type＝“xs:anyURI”/>
      <xs:element name＝“AdvMetadata”type＝“xs:anyType”/>
      <xs:element name＝“GatewayID”type＝“xs:anyURI”
minOccurs＝“0”maxOccurs＝“unbounded”/></xs:sequence></xs:complexType>
DestPeerID：目的对等端的ID。
RoutPeerID：知道到目的对等端的路由的路由器的对等端ID。
AdvMetadata：路由对等端的广告元数据
GatewayID：网关的序列ID。
信道绑定：由应用程序和服务使用信道绑定，以便与与其它对等端进行通信。信道是两个端点之间的虚拟信道。信道绑定可以使用不同的传输协议，例如HTTP、TCP/IP或TLS传输。可以将信道看作是抽象命名的消息队列，支持创建、打开/解析(绑定)、关闭(解绑)、删除、发送和接收操作。可以发送多绑定查询消息。可以不接收零个、一个或多个响应。
查询消息(QueryMessage)   <xs:complexType name＝“ChannelResolverQuery”>
  <xs:sequence>
     <xs:element name＝“ChannelID”type＝“xs:anyURI”/>
     <xs:element name＝“Cached”type＝“xs:boolean”minOccurs＝
“0”/>
      <xs:element name＝“PeerID”type＝“xs:anyURI”minOccurs＝
“0”/>
</xs:sequence></xs:complexType>
ChannelID：正在解析的信道ID。
Cached：当应答可以是高速缓存的应答时，为真；当应答必须不来自缓冲器时，为假。请求者可以请求不从高速缓冲器中获得信息。从对等端获得最近更新的信息，以解决过时的连接。
PeerID：给出对等端ID，表示期望来自其中的响应的对等端的对等端ID。将忽略来自任何其它所有对等端的响应。这不能保证将由对等端进行的对信道绑定请求的响应。
响应消息(ResponseMessage)
<xs:complexType name＝“ChannelResolverResponse”>
   <xs:sequence>
      <xs:element name＝“ChannelID”type＝“xs:anyURI”/>
      <xs:element name＝“Found”type＝“xs:boolean”minOccurs＝
“0”/>
      <xs:element name＝“PeerAdvMetadata”type＝“xs:any Type”
   minOccurs＝“0”/>
</xs:sequence></xs:complexType>
ChannelID：正在解析的信道ID。
Found：用于表示是否在指定的对等端是否找到了输入信道。
PeerAdvMetadata：解析输入信道的对等端的广告元数据。
对等端发现：对等端发现用于发现任何发布的对等资源并且还广告其自身的资源。将资源表示为广告元数据。对等发现使对等端能够在其域中发现元数据。目的在于提供本质发现基础结构，用于建立高层发现服务。在多种情况下，高层服务较好地知道发现信息，这是因为该服务可以更好地了解域拓扑。对等发现提供了发现广告元数据的基本机制，同时提供接通，因此高层服务和应用程序能够参与发现过程。
查询消息(QueryMessage)
<xs:complexType name＝“DiscoveryQuery”>
   <xs:sequence>
      <xs:element name＝“Number”type＝“xs:unsignedInt”/>
      <xs:element name＝“Attribute”type＝“xs:string”/>
      <xs:element name＝“Value”type＝“xs:string”/>
      <xs:element name＝“PeerAdvMetadata”type＝“xs:anyType”
   minOccurs＝“0”/>
      <xs:element name＝“Update”type＝“xs:boolean”/>
</xs:sequence></xs:complexType>
Number：指定了每个响应对等端可以提供的广告元数据的最大数目。
Attribute和Value：只有包含名称Attribute和值Value的元素的元数据才适合被找到。
PeerAdvMetadata：请求对等端的广告元数据。
Update：表示在PeerAdvMetadata中所传送的DIA描述是刚更新的描述(真)还是完整的描述(假)。
响应消息(ResponseMessage)
<xs:complexType name＝“DiscoveryResponse”>
   <xs:sequence>
      <xs:element name＝“Number”type＝“xs:unsignedInt”/>
      <xs:element name＝“Attribute”type＝“xs:string”/>
      <xs:element name＝“Value”type＝xs:string”/>
      <xs:element name＝“PeerAdvMetadata”type＝“xs:any Type”
   minOccurs＝“0”/>
      <xs:element name＝“Update”type＝“xs:boolean”/>
      <xs:element name＝“Response”type＝“xs:anyType”
   maxOccurs＝“unbounded”/>
</xs:sequence></xs:complexType>
Number：指定了所接收响应元素的数目。
Attribute和Value：反映了对其进行响应的DiscoveryQuery。
PeerAdvMetadata：响应对等端的广告元数据。
Update：表示在PeerAdvMetadata中所传送的DIA描述是刚更新的描述(真)还是完整的描述(假)。
Response：响应结构。
1.2基于XML计划的元数据
在XML计划中存在的广告元数据用于描述对等端、对等域、信道、媒体资源、服务和多种其它类型的资源。这里，将用于提供适配媒体资源所必需信息的DIA描述放置于广告信息中。所定义的协议取决于这种关键信息，用于在对等端之间通过这种元数据。
下面示出了广告元数据描述计划及其语义：
<xs:schema    xmlns:xs＝“ http://www.w3.org/2001/XMLSchema”elementFormDefault＝“qualified”attributeFormDefault＝“qualified”>
<xs:element name＝“AdvMetadata”>
   <xs:annotation>
      <xs:documentation>Decribe all types of resources<xs:documentation>
<xs:annotation></xs:complexType>
</xs:sequence><xs:element name＝“Name”type＝“xs:string”minOccurs＝“0”/><xs:element name＝“PeerID”type＝“xs:anyURI”minOccurs＝“0”/><xs:element name＝“PeerDomainID”type＝“xs:anyURI”minOccurs＝“0”/><xs:element name＝“ChannelID”type＝“xs:anyURI”minOccurs＝“0”/><xs:element name＝“Description”type＝“xs:anyType”minOccurs＝“0”/><xs:element name＝“Service”type＝“xs:anyType”minOccurs＝“0”/>
       </xs:sequence>
   </xs:complexType>
</xs:element></xs:schema>
Name：这是与对等端、对等域、信道相关的可选字符串。名称不需要是唯一的，除非从确保名称唯一性的集中命名服务中获得了名称。
PeerID：这是用于唯一识别对等端的元素。
PeerDomainID：该元素提供了对等域ID。每个对等域具有唯一的ID。
ChannelID：这是唯一识别信道的元素。
Description：这是能够用于给出详细DIA描述元数据的可选任意类型的元素。
Service：该元素描述了由其类表示的域服务和指定的任意参数之间的关系。可选地，该Service部分还可选地包括表示该服务不可用的元素。该元素用于传递由对等端的所有者作出的配置选择。
最后，我们利用图2和3中的DIA描述更新分别示出DiscoveryQuery和DiscoveryResponse XML消息示例。图1中因特网中的移动电话客户端和数字多媒体服务器彼此了解，并通过经过有线和无线网络来发送对等端解析器、端点路由器、信道绑定消息，建立了其间的有效连接。服务器将对等端发现消息发送到与“attribute”和“value”相匹配的所有移动电话，并且试图更新DIA更新响应，例如图3所示的DIA“diaplay”元素。
2.使用XML计划(schema)，在分布的对等端之间的通用DIA协商消息
MPEG-21中所定义的DIA协商目标在于：按照类属方式，横跨公共网络来对等传输DIA元数据。可以设计开放的网络平台，用于对等计算。能够定义一组开放的协议，所述协议允许范围从蜂窝电话和无线PDA到PC和服务器/网关/代理的网络上任何相连设备能够按照对等的方式进行通信和合作，例如部分1中的对等解析器、端点路由、对等发现和信道绑定。用于按照可互操作方式进行DIA描述协商的其它解决计划在于：在携带DIA描述元数据的高层中定义类属DIA描述协商消息。部分1.2中所定义的广告元数据不需要保留DIA描述元数据。可以在所定义类属协议的上层和/或例如HTTP/TCP/IP之类的通常已有的最低层物理网络协议上来设计所有这些协商消息。图4示出了该概念。
模块4.1是DIA描述，包括URI能够访问或在协商消息中作为净荷(DIADescriptionData)携带的使用环境、XDI(上下文数字项)和BSDL(比特流语法描述语言)描述等。模块4.2、4.3和4.4是用于协商机制的独立层，分别定义了用于DIA协商的消息、用于对等通信的协议、以及物理网络传输。模块4.5给出了在用于DIA协商的最高层中携带模块4.1的DIA描述的三个类属消息(DIARegister，DIATransmit和DIAUpdate)。图5还示出了协商消息的流程图。
模块5.1示出了为对等端A创建MPEG-21 DIA描述，包括基于标准化DIA描述计划的使用环境、XDI(上下文数字项)和BSDL(比特流语法描述语言)描述。
模块5.2示出了当对等端A希望向对等端B发送或更新当前DIA描述时，对等端A构建登记消息(或发送消息或更新消息)。登记消息用于请求一个对等端到其它对等端的DIA描述的登记。发送消息用于在对等端之间传送详细的终端说明。当一个对等端的终端信息变化时，使用更新消息，以便将终端信息的改变从一个对等端通知到另一对等端。
模块5.3示出了对等端A将具有用于对等端A的DIA描述的登记消息(或发送消息或更新消息)发送到对等端B。
模块5.4示出了对等端B建立响应消息，用于利用“响应”信息登记(或发送或更新)到对等端A。
模块5.5示出了对等端B发回响应消息，用于利用“响应”信息登记(或发送或更新)到对等端A。
对等端A检查包括在响应消息中的“响应”信息的值，以便得知对等端A和B之间的DIA描述协商是否成功，由模块5.6示出。当“响应”值是“真”时，表示对等端B接受了来自对等端A的登记，并且准备好接收来自对等端A的DIA描述，用于对等端A的新的或更新的DIA描述，如模块5.7所示。否则，当“响应”值是“假”时，表示对等端B拒绝来自对等端A的登记，并且不希望接收来自对等端A的DIA描述，或对于接收新的或更新的DIA描述存在问题，如模块5.8所示。
以下示出了图6所示的DIA描述协商消息计划的语法和语义。
<？xml version＝”1.0”encoding＝“UTF-8”？>
 <xs:schema           xmlns:xs＝“ http://www.w3.org/2001/XMLSchema”elementFormDefault＝“qualified”attributeFormDefault＝“unqualified”>
<xs:element name＝DIADescriptionMessage”>
  <xs:annotation>
     <xs:documentation>Message for DIA Descriptionnegotiation<xs:documentation>
<xs:annotation>
  </xs:complexType>
    </xs:sequence>
      <xs:element name＝“Type”>
         <xs:simple type>
              <xs:restriction base＝“xs:string”>
                     <xs:enumeration value＝“DIARegister”/>
               <xs:enumeration value＝“DIATransmitting”/>
          <xs:enumeration value＝“DIAUpdating”/>
     </xs:restriction>
</xs:simple type>
      </xs:element><xs:element name＝“Msg_ID”type＝“xs:nonNegtiveInteger”/>
<xs:element name＝“SenderPeer_ID”type＝“xs:ID”/>
   <xs:element name＝“RecipientPeer_ID”type＝“xs:ID”/>
      <xs:element name＝“DIADescription”/>
         </xs:complex type>
             </xs:choice>
               <xs:element name＝“Reference”type
＝“xs:anyURI”/>
     <xs:element name＝“DIADescriptionData”type
     ＝“DIADescription type”/>
        </xs:choice>
    </xs:complex type>
</xs:element><xs:element name＝“Response”type＝“xs:boolean”minOccurs＝“0”/></xs:sequence>
</xs:complex type>
    </xs:element>
        <xs:complexType name＝“DIADescriptionType”>
           </xs:sequence><xs:element name＝“UsageEnvironmentDescription”minOccurs＝“0”/>
  <xs:element name＝“BSDLDescription”minOccurs＝“0”/>
    <xs:element name＝“XDIDescription”minOccurs＝“0”/>
         </xs:sequence>
             </xs:complexType>
                 </xs:schema>
Type：表示DIA协商消息类型，例如“DIARegistering”、“DIATransmitting”和“DIAUpdating”；
DIARegistering：当对等端试图发送或更新当前DIA描述时，用于登记DIA描述的消息类型；
DIATransmitting：用于发送当前对等端DIA描述的消息类型；
DIAUpdating：用于更新当前对等端DIA描述的消息类型；
Msg_ID：由消息发起者指定的消息标识符。响应消息而发送的所有消息都应当包括初始消息的标识符；
SenderPeer_ID：表示消息发起者的对等端ID；
RecipientPeer_ID：表示消息的目的接收者的对等端ID；
DIADescription：需要发送、交换或更新的所有数字项适配描述，例如使用环境描述、BSDL描述和XDI(在DID中包装的用于会话移动的DIA描述)；可以在消息中携带DIA描述，作为净荷“DIADescriptionData”，或者使用“Reference”来指向位于万维网的DIA描述的实体。
Response：用于携带响应消息，所述响应消息响应具有相同“Msg_ID”和“Type”的初始输入消息。
在DIARegistering的情况下，“真”表示数据发送者同意在处理DIARegistering消息之后接收DIA描述；在DIATransmitting的情况下，“真”表示消息发送者成功地接收了DIA描述；而在DIAUpdating的情况下，“真”表示消息发送者成功地接收了更新的DIA描述。
在以上三种情况下，“假”分别表示“不同意”、“接收DIA描述出现错误”和“接收更新的DIA描述出现错误”。当使用“Response”元素时，不使用“DIADescription”。
由协商机制的高层DIA消息按照标准化方式提供了另一种解决问题的手段。
尽管已经结合特定实施例对本发明进行了说明，对于本领域技术人员，多种其它的修改、改正和应用都是显而易见的。因此，本发明并不局限于这里所提供的公开，而是受到所附权利要求的范围的限制。
本公开涉及2002年7月12日递交的日本专利申请No.2002-204286所包含的主题，该申请的内容一并包括在此作为参考。

Claims (12)

1.一种定义数字项适配(DIA)的协商机制的方法，包括：
根据作为MPEG-21兼容终端的对等端的标准DIA描述计划，创建MPEG-21DIA描述，所述MPEG-21DIA描述包括至少下列之一：使用环境、XDI(上下文数字项)和BSDL(比特流语法描述语言)描述；
将DIA描述设置于适当的位置，以用于在协商协议中的交换、发送或更新；
指定和定义一些类属协议消息计划，以实现类属协议的功能；以及
使用所定义的协议，交换、更新或发送DIA描述。
2.根据权利要求1所述的方法，其特征在于还包括：
指定和定义灵活的广告元数据描述计划，以描述不同类型的资源，至少包括对等端、对等域和信道中的至少一个；以及
将DIA描述并入广告元数据中。
3.根据权利要求2所述的方法，其特征在于还包括实现广告元数据描述计划解析器，以解译对等端中的广告元数据描述。
4.根据权利要求1所述的方法，其特征在于还包括：通过使用信道绑定协议来建立信道，通过使用端点路由协议来路由协议消息；以及通过使用对等端解析器协议来使对等端彼此了解，来建立在对等域中需要交换、发送或更新DIA描述的对等端的连接。
5.根据权利要求1所述的方法，其特征在于还包括：通过根据对等发现协议来启用本质发现消息基本结构，以便查询和响应包括DIA描述的广告元数据，来交换、更新或发送DIA描述。
6.根据权利要求1到5之一所述的方法，其特征在于指定和定义类属协议消息计划包括在实现所有协议中所涉及的所有对等端中实现消息计划解析器。
7.一种定义数字项适配(DIA)的协商机制的方法，包括：
根据类属高层对等协议和实际网络协议来创建需要DIA协商的对等端之间的连接，所述对等端是MPEG-21兼容终端；
根据针对对等端的标准DIA描述计划，创建MPEG-21DIA描述，所述描述包括至少下列之一：使用环境、XDI(上下文数字项)和BSDL(比特流语法描述语言)描述；
指定和定义包括DIA描述和DIA描述元素的类属和本质DIA协商消息，用于实现协商机制；以及
利用需要DIA协商的对等端之间的DIA协商消息来登记、发送或更新DIA描述。
8.根据权利要求7所述的方法，其特征在于还包括：使用“Reference”以指向位于万维网中的DIA描述的实体，将DIA描述指定为Reference，或者使用DIADescription元素下的“DIADescriptionData”，将DIA描述指定为消息净荷。
9.根据权利要求7所述的方法，其特征在于还包括
当第一对等端希望向第二对等端发送或更新当前DIA描述时，利用第一对等端的消息ID来建立针对第一对等端的登记消息；
将登记消息发送到第二对等端；以及
从第二对等端向第一对等端发送具有相同消息ID和消息类型的响应消息，并且“响应”信息包含“真”，表示第二对等端准备好接收来自第一对等端的DIA描述，或“假”，表示第二对等端由于任意原因而拒绝接收来自第一对等端的DIA描述。
10.根据权利要求7所述的方法，其特征在于还包括
利用第一对等端的消息ID来建立针对第一对等端的发送消息，从而将当前DIA描述发送到第二对等端，
将发送消息发送到第二对等端，以及
从第二对等端向第一对等端发送具有相同消息ID和消息类型的响应消息，“响应”信息包含“真”，表示成功接收到从第一对等端到第二对等端的所发送DIA描述，或“假”，表示由于任意原因而未成功接收从第一对等端到第二对等端的所发送DIA描述。
11.根据权利要求7所述的方法，其特征在于还包括
利用第一对等端的消息ID来建立针对于第一对等端的更新消息，以便将当前DIA描述更新到第二对等端，
将更新消息发送到第二对等端，以及
从第二对等端向第一对等端发送具有相同消息ID和消息类型的响应消息，并且“响应”信息包含“真”，表示成功接收到从第一对等端到第二对等端的更新DIA描述，或“假”，表示由于任意原因而未成功接收从第一对等端到第二对等端的更新DIA描述。
12.根据权利要求7到11之一所述的方法，其特征在于：指定和定义类属和本质DIA协商消息计划包括：在交换DIA描述中所涉及的所有对等端中实现DIA协商消息计划解析器。
CNA038030268A 2002-07-12 2003-07-07 定义数字项适配的协商机制的方法 Pending CN1625882A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2002204286 2002-07-12
JP204286/2002 2002-07-12

Publications (1)

Publication Number Publication Date
CN1625882A true CN1625882A (zh) 2005-06-08

Family

ID=30112705

Family Applications (1)

Application Number Title Priority Date Filing Date
CNA038030268A Pending CN1625882A (zh) 2002-07-12 2003-07-07 定义数字项适配的协商机制的方法

Country Status (5)

Country Link
US (1) US20050120123A1 (zh)
EP (1) EP1495620A1 (zh)
CN (1) CN1625882A (zh)
AU (1) AU2003281130A1 (zh)
WO (1) WO2004008714A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101554049B (zh) * 2006-09-25 2011-10-26 韩国电子通信研究院 用于使用场景表现语言的数字项描述和处理的设备和方法
CN104661045A (zh) * 2013-11-21 2015-05-27 青岛海尔电子有限公司 多媒体内容自适应方法和多媒体播放系统

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200408227A (en) * 2002-10-15 2004-05-16 Matsushita Electric Ind Co Ltd Digital item adaptation system via URL
WO2006001565A1 (en) * 2004-06-24 2006-01-05 Electronics And Telecommunications Research Institute Extended description to support targeting scheme, and tv anytime service and system employing the same
KR100597308B1 (ko) 2004-10-05 2006-07-05 주식회사 현대오토넷 피투피 방식의 데이터 공유 시스템에서 엠페그 검색을이용한 검색 시스템 및 방법
KR100628655B1 (ko) * 2004-10-20 2006-09-26 한국전자통신연구원 상이한 디지털 저작권 관리 도메인간의 콘텐츠 교환을 위한방법 및 시스템
CN101138244B (zh) * 2005-01-07 2010-05-19 韩国电子通信研究院 利用使用环境描述的分类方案提供自适应广播服务的装置和方法
WO2007006090A1 (en) * 2005-07-08 2007-01-18 Smart Internet Technology Crc Pty Ltd Systems and methods for use in transforming electronic information into a format
WO2007025560A1 (en) * 2005-08-31 2007-03-08 Telefonaktiebolaget Lm Ericsson (Publ) Multimedia transport optimisation
EP1903455A1 (en) * 2006-09-22 2008-03-26 Research In Motion Limited Schema updating for synchronizing databases connected by wireless interface
US7730028B2 (en) * 2006-09-22 2010-06-01 Research In Motion Limited Schema updating for synchronizing databases connected by wireless interface
US8375014B1 (en) * 2008-06-19 2013-02-12 BioFortis, Inc. Database query builder

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6401085B1 (en) * 1999-03-05 2002-06-04 Accenture Llp Mobile communication and computing system and method
ATE372639T1 (de) * 2000-12-08 2007-09-15 Sony Deutschland Gmbh Schnittstelle auf hoher ebene für dienstqualitätbasierte mobile multimedia- anwendungen
AU2002234258A1 (en) * 2001-01-22 2002-07-30 Sun Microsystems, Inc. Peer-to-peer network computing platform
US20030156108A1 (en) * 2002-02-20 2003-08-21 Anthony Vetro Consistent digital item adaptation

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101554049B (zh) * 2006-09-25 2011-10-26 韩国电子通信研究院 用于使用场景表现语言的数字项描述和处理的设备和方法
CN104661045A (zh) * 2013-11-21 2015-05-27 青岛海尔电子有限公司 多媒体内容自适应方法和多媒体播放系统
CN104661045B (zh) * 2013-11-21 2017-09-01 青岛海尔电子有限公司 多媒体内容自适应方法和多媒体播放系统

Also Published As

Publication number Publication date
WO2004008714A1 (en) 2004-01-22
AU2003281130A1 (en) 2004-02-02
EP1495620A1 (en) 2005-01-12
US20050120123A1 (en) 2005-06-02

Similar Documents

Publication Publication Date Title
CN1236583C (zh) 域间路由选择系统
CN1183717C (zh) 桥连HAVi子网络和UPnP子网络的方法及实施所述方法的装置
CN1324898C (zh) 用于为移动通信设备提供远程数据访问的系统和方法
CN1751492A (zh) 在网络通信中压缩报文的系统和方法
CN1242593C (zh) 源地址选择系统、路由器装置、通信节点和源地址选择方法
CN1665221A (zh) 多点发送控制装置及方法
CN1260090A (zh) 因特网上的数据高速缓冲存储器
CN101060464A (zh) 地址变换装置、消息处理方法及网络系统
CN1947106A (zh) 通知方法、连接装置、通信方法以及程序
CN100343835C (zh) 信息处理方法和设备
CN1848766A (zh) 管理专用网络之间的网络服务的系统和方法
CN101039247A (zh) 一种点到点网络系统及重叠网间节点的互通方法
CN1640074A (zh) 移动管理方法和移动终端
CN1855847A (zh) 公共与专用网络服务管理系统和方法
CN1192098A (zh) 分布式网络计算系统及该系统用的信息交换装置和方法
CN1859332A (zh) 一种采用数据同步处理电子邮件的系统、装置及方法
CN1925462A (zh) 高速缓存系统
CN1794692A (zh) 通信系统和在通信系统中查询信息的方法
CN1503526A (zh) 地址转换装置和地址转换规则的管理方法
CN1444147A (zh) 服务器设备和信息处理方法
CN1774893A (zh) 会话端点管理协议
CN1625882A (zh) 定义数字项适配的协商机制的方法
CN101068262A (zh) 动态联合内容传送系统和方法
CN101056339A (zh) 回铃音与振铃音相互转换的方法、系统及装置
CN1801231A (zh) 紧急通报系统和紧急通报方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication