Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
The Digital Media Project
Source J.Y. Lee, H.G. Choo, and J. Nam          Date: 2008/04/25
Title Proposal for Domain Disco...
2   Registration form

Company:                   ETRI
Contact name:              Jooyoung Lee
Address:                   ...
Signature:

3    Domain Discovery Protocol

3.1 Scenarios of Domain Discovery
  A Domain consists of Domain members. Domai...
End-user
                                                                                    DMD
                         ...
<complexContent>
     <extension base="msdp:DomainProtocolType">
        <sequence minOccurs="0" maxOccurs="unbounded">
  ...
</extension>
  </complexContent>
</complexType>
                            Figure 4. dmp-msdpx:DiscoveryResponse message
...
Upcoming SlideShare
Loading in …5
×

Proposal for Domain Discovery Protocol in Localised Domain

307 views

Published on

  • Be the first to comment

  • Be the first to like this

Proposal for Domain Discovery Protocol in Localised Domain

  1. 1. The Digital Media Project Source J.Y. Lee, H.G. Choo, and J. Nam Date: 2008/04/25 Title Proposal for Domain Discovery Protocol in No. 1119/Lausanne Localised Domain Proposal for Domain Discovery Protocol in Localised Domain 1 Introduction IDP provides Domain model to allow more flexible licensing mechanism and distribution of contents. Domain systems of IDP consist of DMD, EUD, DID, LPD, and Users, as described in [1]. IDP also has defined various Domain management protocols and messages for creating/renewing/deleting/adding/leaving Domains and adding/renewing users or devices [2]. This IDP Domain model and its protocols enable the IDP specification to be adapted to various service models, such as IPTV, VOD and Contents download services. However, the current Domain protocols of IDP cannot provide the means for the EUD to find the location of DMD and available Domains, so that it prevents the IDP domain model to be used on localized Domain environment, such as home Domain sharing Free-To-Air broadcast contents, in which one of the Devices in the Domain makes a role of DMD. In this environment, a device that newly access to the Domain does not know which Device is in charge of Domain management and what Domain is available. To support this, IDP should provide the means to discover the Domain and its management Device. In [3], DMP has approved Domain discovery technology as one of the requirements of IDP. Accordingly, in this document, we propose a modified protocol and its messages for Domain Discovery, based on [4], our previous input document. 1
  2. 2. 2 Registration form Company: ETRI Contact name: Jooyoung Lee Address: 161 Gajung-dong, Yusong-ku, Daejon 305-600, Korea Phone number: +82-42-860-1851 Fax: +82-42-860-5479 Email: leejy1003@etri.re.kr Title of submission: Proposal for Domain Discovery Protocol in Localised Domain Abstract: IDP provides Domain model to allow more flexible licensing mechanism and distribution of contents. Domain systems of IDP consist of DMD, EUD, DID, LPD, and Users, as described in [1]. IDP also has defined various Domain management protocols and messages for creating/renewing/deleting/adding/leaving Domains and adding/renewing users or devices [2]. This IDP Domain model and its protocols enable the IDP specification to be adapted to various service models, such as IPTV, VOD and Contents download services. However, the current Domain protocols of IDP cannot provide the means for the EUD to find the location of DMD and available Domains, so that it prevents the IDP domain model to be used on localized Domain environment, such as home Domain sharing Free-To-Air broadcast contents, in which one of the Devices in the Domain makes a role of DMD. In this environment, a device that newly access to the Domain does not know which Device is in charge of Domain management and what Domain is available. To support this, IDP should provide the means to discover the Domain and its management Device. In [3], DMP has approved Domain discovery technology as one of the requirements of IDP. Accordingly, in this document, we propose a modified protocol and its messages for Domain Discovery, based on [4], our previous input document. IPR status Time requested for 5 minutes presentation (subject to review by organisers): Demo intended: No Equipment and other None support required for demo: Name: Jooyoung Lee Date: 2008-04-25 2
  3. 3. Signature: 3 Domain Discovery Protocol 3.1 Scenarios of Domain Discovery A Domain consists of Domain members. Domain members share Domain membership and the rights on the contents. For this, Domain Management Device(DMD) manages the domain and provides the Domain members with the functions of joining, leaving, renewing, updating, and so on. Therefore, at least, Domain members should be able to communicate with DMD. However, when a device makes a connection to a Domain, the device might have no information about the location, availability, or capability of the DMDs. A localised Domain such as home Domain for Free-to-Air broadcast content is one representative example, as shown in the figure 1. On this localised Domain environment, Domain management is performed by arbitrary capable device in the home Domain. In this case, a user can choose the device to makes a role of DMD, and sometimes, the DMD device might be changed or shut down. In this variable Domain, a device to newly access the Domain may not know how to communicate with the DMD, so a means for the devices to discover the domain information such as DMD location is necessary, and Domain Discovery Protocol could provide the functionalities to solve the problem mentioned above. Home Domain Domain Device 1 Does any Domain exist? Who’s the DMD? Domain Discovery Free to Air Protocol Broadcast Signal STB New Device Domain Device 2 (with DMD role) Accessing the Domain Boradcast Station Local Network Domain Device 3 Figure 1. Sample Scenario of Domain Discovery Domain Discovery Protocol could be used for two purposes as follows:  Domain device uses Domain Discovery protocol to find the location of the DMD.  Domain device uses Domain Discovery protocol to find the Domain information. 3.2 Normal Walkthrough Domain Discovery Protocol is composed of DiscoveryRequest and DiscoveryResponse messages. Figure 3 shows the message sequence of Domain discovery. 3
  4. 4. End-user DMD Device Broadcasting DiscoveryRequest DiscoveryResponse (Domain Information, DMD Location) Timeout Duration Waiting for other responses Analysis the responses Mutual Authencation and Domain Creation Messages Figure 2. Sample Walkthrough of Domain Discovery This includes Discovery of available DMD location and Domain information: 1) Domain discovery of the locations of available DMDs  End-User Device broadcasts a DiscoveryRequest message to all devices in the network.  The DiscoveryRequest message can carry the conditions for the discovery such as Domain ID, Device ID, User ID, etc. Semantics of each condition is described in the next section.  DMD receives the DiscoveryRequest message. If the DMD satisfies the conditions in DiscoveryRequest message, the DMD sends DiscoveryResponse with its location and Domain information as a response.  End-user Device receives DiscoveryResponse messages from DMDs during the pre- defined time.  When pre-defined time has elapsed, End-User Device (or Domain Administrator) analyzes the received responses and start to communicate with DMDs. 3.3 Protocol Messages This section describes the Messages for Domain Discovery. 3.3.1 DiscoveryRequest <element name="DiscoveryRequest" type="dmp-msdpx:DiscoveryRequestType"/> <complexType name="DiscoveryRequestType"> 4
  5. 5. <complexContent> <extension base="msdp:DomainProtocolType"> <sequence minOccurs="0" maxOccurs="unbounded"> <element name="Condition"> <complexType> <choice minOccurs="0" maxOccurs="unbounded"> <element ref="msd:DomainID"/> <element ref="msd:DeviceID"/> <element ref="msd:UserID"/> </choice> </complexType> </element> </sequence> </extension> </complexContent> </complexType> Figure 3. dmp-msdpx:DiscoveryRequest message The DiscoveryRequest message shown above is a message sent from an User or a Device to Domain Management Device for the purpose of finding available DMDs. The semantics are given below: • Condition: This element specifies the conditions for the discovery. DomainID, DeviceID, UserID can be included as conditions. When the request has more than one Condition elements, those conditions are bound using “or” operation, while all the conditions in the Condition element are bound using “and” operation. • DomainID: The Domain Identifiers of the Domain. This element is used when the user or the device want to find the DMDs which manage the specified Domains. If a DMD receives the DiscoveryRequest message and it manages the Domains specified in this DomainID parameter, the DMD sends response to the EUD. • DeviceID: The Identifier of a Device. This element is used when the user or the device want to find the DMDs which manage the Domains that includes the specified Device as a Domain member. • UserID: The Identifier of a User. This element is used when the user or the device want to find the DMDs which manage the Domains that includes the specified User as a Domain member. If no condition is specified, all DMDs receiving DiscoveryRequest will send the response. 3.3.2 DiscoveryRequestResponse <element name="DiscoveryResponse" type="dmp-msdpx:DiscoveryResponseType"/> <complexType name="DiscoveryResponseType"> <complexContent> <extension base="msdp:DomainProtocolType"> <sequence> <element name="DomainManagerID" type="msd:DeviceID"/> <element name="Location" type="anyURI" minOccurs="0"/> <element ref="msd:DomainID" maxOccurs="unbounded"/> </sequence> 5
  6. 6. </extension> </complexContent> </complexType> Figure 4. dmp-msdpx:DiscoveryResponse message The DiscoveryResponse message shown above is a message sent from the Domain Management Device to User or End-User Device in order to notify the location of DMD and the Domain information. This DiscoveryResponse is sent when the conditions of DiscoveryRequest are satisfied. The semantics are given below: • DomainManagerID: The Identifier of the DMD which sends the response. • Location: The location of the DMD. Any type of location information can be included, and this element is even skipped when sending response itself is enough to give the location information. • DomainID: The Domain Identifiers managed by the DMD. The Domains are decided according to the conditions in the request message. 4 Conclusions and Recommendations In this contribution, we proposed a modified protocols and messages for Domain Discovery. The Domain Discovery protocol allows Domain members to start communication with DMD by locating the DMD in the network. Domain Discovery protocol will provide more complete ways for other Domain Management protocols to communicate with the DMDs, and it also allows IDP Domain model to be applied to the extended area of digital contents. Therefore, we suggest that IDP-3.2 adopt the Domain Discovery protocol. 5 Reference [1] DMP1002, Approved Document No 2 – Technical Reference: Architecture, Version 3.0 [2] DMP1003, Approved Document No. 3 – Technical Specification: Interoperable DRM Platform, Version 3.1 [3] DMP1029, Requirements for technologies in GA15 Call for Proposals [4] DMP0966, Proposal for New Domain Protocol Messages 6

×