CA2748940A1 - Rich media-enabled service guide provision method and system for broadcast service - Google Patents

Rich media-enabled service guide provision method and system for broadcast service Download PDF

Info

Publication number
CA2748940A1
CA2748940A1 CA2748940A CA2748940A CA2748940A1 CA 2748940 A1 CA2748940 A1 CA 2748940A1 CA 2748940 A CA2748940 A CA 2748940A CA 2748940 A CA2748940 A CA 2748940A CA 2748940 A1 CA2748940 A1 CA 2748940A1
Authority
CA
Canada
Prior art keywords
rich media
service guide
rms
template
service
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.)
Abandoned
Application number
CA2748940A
Other languages
French (fr)
Inventor
Jong Hyo Lee
Seo Young Hwang
Jae Yeon Song
Sung Oh Hwang
Bo Sun Jung
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.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics 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 Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Priority claimed from PCT/KR2010/000260 external-priority patent/WO2010082782A2/en
Publication of CA2748940A1 publication Critical patent/CA2748940A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/08Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/44Receiver circuitry for the reception of television signals according to analogue transmission standards
    • H04N5/445Receiver circuitry for the reception of television signals according to analogue transmission standards for displaying additional information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

A service guide provision method and system for a digital broadcast service is provided for distributing a rich media-enabled service guide. A rich media-enabled service guide provisioning method for a digital broadcast service includes creating a Rich Media Solution (RMS) template for a service guide with reference to service guide fragments; creating a service guide delivery descriptor containing RMS information on the RMS template and service guide fragment information on the service guide fragments; and broadcasting the service guide fragments, the RMS
template, and the service guide delivery descriptor.

Description

Description Title of Invention: RICH MEDIA-ENABLED SERVICE GUIDE
PROVISION METHOD AND SYSTEM FOR BROADCAST
SERVICE
Technical Field [1] The present invention relates to broadcast services and, in particular, to a service guide provision method and system for a digital broadcast service that is capable of distributing a rich media-enabled service guide.
Background Art [2] Broadcasting is a service that may be received by all users having broadcast receivers. The broadcast services can be roughly divided into two categories:
a radio broadcasting service carrying only audio, and a multimedia broadcasting service carrying audio and video plus data. Such broadcasting services have developed from analog services to digital services. Recently, various types of broadcasting systems (such as cable broadcasting systems, satellite broadcasting systems, and hybrid broadcasting systems using both a cable network and a satellite) have been developed to provide high quality audio and video broadcasting services along with high speed data services.
[3] The mobile communication market is confronted with the need for new services through a recombination or reintegration of existing technologies. The development of communication and broadcast technologies has allowed users to enjoy broadcasting services on the move using portable devices such as mobile phones and Personal Digital Assistants (PDAs). Due to potential and actual market needs and increasing user demand for multimedia services, service providers' intended strategies for providing new services such as broadcast service in addition to the existing voice service, and the identified interests of Information Technology (IT) companies, which are bolstering their mobile communication businesses to meet the user's demands, and the convergence of mobile communication services and Internet Protocol (IP) technology has become a priority in the development of the next generation mobile communication technologies. The convergence has come to introduce and apply various wireless/broadcast services not only in the mobile communication market but also in the general wired communication market, and the all-around convergence has enabled the same consumption environment for different services no matter whether they are wired or wireless broadcast services.
[4] Open Mobile Alliance (OMA), a group developing the standard for interworking between individual mobile solutions, serves to define various application standards for mobile games and Internet services. OMA Mobile Broadcast Services Enabler Suite (OMA BOAST) is an open global specification designed to support mobile broadcast technologies. The OMA BCASTdeals with the standardizations of technologies for providing the IP-based mobile content delivery such as a variety of functional areas including service guides, downloading and streaming, service and content protection, service subscription, and roaming.
[5] With the trend of fixed-mobile convergence, the mobile broadcast technologies such as OMA BCAST are evolving to provide the service in a fixed-mobile integrated en-vironment.
[6] The conventional mobile broadcast systems provide service guides configured to be processed by only the terminals designed to receive the corresponding broadcast system.
[7] In such mobile broadcast systems, the service guide is provided with the content-related informationbut not the display method, such that the display format of the service guide is determined depending on the implementation of the terminal.
Since the service guide as a start point of all the broadcast services provided by the service provider may be displayed in different formats depending on the manufacturer and model of the terminal, it is difficult to provide the broadcast users with uniform service accessibility. In order to solve this problem, there is a need for a rich media technology to define a display format adaptive to various terminal displays. Moving Pictures Experts GroupLightweight Application Scene Representation (MPEG-LASeR), 3rd Generation Partnership-Dynamic and Interactive Multimedia Scenes (3GPP-DIMS), and Open Mobile Alliance-Rich Media Environment (OMA-RME) are representative rich media integrated solutions. In the case of applying the rich media technology to the service guide, however, compatibility problems occur such that the service guide can be displayed normally only on the rich media-enabled terminal display.
There is therefore a need to developa method for providing the rich media-enabled service guide adapted to the terminal capability.
Disclosure of Invention Technical Problem [8] In order to overcome at least the problems of the prior art, the present invention provides a rich media-enabled service guide provisioning method and system for a broadcast service.
[9] Also, the presentinvention provides a rich media-enabled service guide provisioning method and system for a broadcast service that is capable of rendering a rich media-enabled service guide without compromisingbackward compatibility by using a rich media-based service guide template.

Solution to Problem [10] In accordance with an embodiment of the present invention, a rich media-enabled service guide provisioningmethod for a digital broadcast service includes creating a Rich Media Solution (RMS) template for a service guide with reference to service guide fragments; creating a service guide delivery descriptor containing RMS
in-formation on the RMStemplate and service guide fragment information on the service guide fragments; and broadcasting the service guide fragments, the RMS
template, and the service guide delivery descriptor.
[11] In accordance with another embodiment of the present invention, arich media-enabled service guide handling method for a digital broadcast service includes receiving at least one service guide delivery descriptor; extracting service guide fragments with reference to information on the service guide fragment contained in the service guide delivery descriptor; receiving a Rich Media Solution (RMS) template with reference to RMS information of the service guide delivery descriptor;
and outputting a service guide rendered with the service guide fragments using the RMS
template.
[12] In accordance with still another embodiment of the present invention, a rich media-enabled service guide provisioning system for a digitalbroadcast service includes a broadcast distribution/adaptation unit which transports a service guide delivery de-scriptor comprising information on service guide fragments, a Rich Media Solution (RMS) template, service guide fragment information, and RMS template information;
and a terminal which extracts the service guide fragments with reference to the service guide fragment information of the service guide delivery descriptor, receives the RM-Stemplate with reference to the RMS template information of the service guide delivery descriptor, and outputs a service guide rendered with the service guide fragments using the RMS template.
Advantageous Effects of Invention [13] As described above, the rich media-enabled service guide provision method and system of the present invention is capable of providing the rich media-enabled service guide to the terminals having different capabilities in a service provider's intended format by using RMS templates.
[14] Also, the rich media-enabled service guide provision method and system of the present invention is capable of distributing the rich media-enabled service guide without compromising backward compatibility.
Brief Description of Drawings [15] The above and other objects, features and advantages of the present invention will be more apparent from the following detailed description in conjunction with the ac-companying drawings, in which:
[16] FIG. 1 is a block diagram illustrating the logical architecture of a BCAST system specified by OMA BCAST working group dealing with applicationlayer and transport layer;
[17] FIG. 2 is a diagram illustrating a structure of a Service Guide Data Model for use in the OMA BCAST system;
[18] FIG.3 is a block diagram illustrating a relationship between a Service Guide Delivery Descriptor (SGDD) and a Service Guide Delivery Unit (SGDU) in a Service Guide Data Model of FIG. 2;
[19] FIG.4 is a flowchart illustrating a rich media-enabled service guide provisioning method according to an embodiment of the present invention;
[20] FIG.5 is a flowchart illustrating a procedure for handling a received rich media-enabled-service guide in the rich media-enabled service guide provision method according to an embodiment of the present invention; and [21] FIG. 6 is a block diagram illustrating a configuration of the terminal according to an embodiment of the present invention.
[22] FIG. 7 is a block diagram illustrating a Service Guide Data Model based on a rich media.
Mode for the Invention [23] Embodiments of the present invention are described with reference to the ac-companying drawings in detail. The same reference numbers are used throughout the drawings to refer to the same or like parts. Detailed descriptions of well-known functions and structures incorporated herein may be omitted to avoid obscuring the subject matter of the present invention.
[24] The terms and words used in the following description and claims are not limited to their dictionary meanings, but are merely used by the inventor to enable a clear and consistent understanding of the invention. Accordingly, it should be apparent to those skilled in the art that the following description of embodiments of the present invention are provided for illustration purpose only and not for the purpose of limiting the invention as defined by the appended claims and their equivalents.
[25] In the following, the description is made using the terms and expressions specified in the 3GPP DIMS and OMA BCAST standards, however, the present invention is not limited to these standards as it can be applied to other technologies and systems developed under the similar concept.
[26] A digital broadcast system according to an embodiment invention is described hereinafter. Although the description on the digital broadcast system is made with the OMA BCASTtechnology as a representative mobile broadcast standard, the present invention is not limited thereto.
[27] FIG. 1 is a block diagram illustrating the logical architecture of a BCAST system specified by OMA BCAST working group dealing with application layer and transport layer.
[28] As shown in FIG. 1, the logical architecture of the BCASTsystem includes a Content Creation (CC) 101, a BCAST Service Application 102, a BCAST Service Distribution/
Adaptation 103, a BCASTSubscription Management 104, a Terminal 105, a BDS
Service Distribution 111, a Broadcast Distribution System 112, and an Interworking Network 113.
[29] The Content Creation (CC) 101 provides content that is the basis of the BCAST
services. The content can be files for common broadcast services, e.g. data for movie, audio and video. The Content Creation 101 provides the BCAST Service Application 102 with attributes for the content, which are used to create a service guide and determine a transmission bearer over which the services will be delivered.
[30] The BCAST Service Application 102 receives data for the BCAST services provided from the Content Creation 101, and converts the received data into a form suitable to provide media encoding, content protection, interactive services, etc. The BCAST
Service Application 102 provides the attributes for the content, which are received from the Content Creation 101, to the BCAST Service Distribution/Adaptation (BSDA) 103 and the BCAST Subscription Management (BSM) 104.
[31] The BCAST Service Distribution/Adaptation 103 performs operations such as file/
streaming delivery, service gathering, service protection, service guide creation/
delivery and service notification, using the BCAST service data provided from the BCAST Service Application 102. The BCAST Service Distribution/Adaptation 103 adapts the services to the Broadcast Distribution System (BDS) 112.
[32] Particularly in an embodiment of the present invention, the BCAST Service Dis-tribution/Adaptation 103 creates a Rich Media Solution (RMS) template and transmits RMS template information with the RMS template to the terminal 105.
[33] The BCAST Subscription Management 104 manages, via hardware and/or software, service provisioning suchas subscription and charging-related functions for BCAST
service users, information provisioning used for BCAST services, and mobile terminals that receive the BCAST services.
[34] The terminal 105 receives content/service guide and program support information such as content protection, and provides a broadcast service to a user.
Particularly in an embodiment of the presentinvention, the terminal 105 receives the RMS
information and the RMS template based on the RMS information. The terminal 105 also receives the service guide and outputs the service guide using the RMS template.
[35] The BDS Service Distribution 111 delivers mobile broadcast services to a plurality of terminals through mutual communication with the Broadcast Distribution System and the Interaction Network 113.
[36] The Broadcast Distribution System 112 delivers mobile broadcast services over a broadcast channel, and may include, for example, Multimedia Broadcast Multicast Service (MBMS) by 3rdGeneration Project Partnership (3GPP), Broadcast Multicast Service (BCMCS) by 3rdGeneration Project Partnership 2 (3GPP2), DVB-Handheld (DVB-H) by Digital Video Broadcasting (DVB), or Internet Protocol (IP) based broadcasting/communication networks. The Interaction Network 113 provides an in-teraction channel, and may include, for example, a cellular network and the like.
[37] A description is now made of reference points which are connection paths between the above logical entities. The reference points have a plurality of interfaces according to their purposes. The interfaces are used for communication between two or more logical entities for their specific purposes, and a message format, a protocol and the like, for the interfaces are applied.
[38] BCAST-1 121 in FIG. 1 is a transmission path for content and content attributes, and BCAST-2 122 is a transmission path for a content-protected or a content-unprotected BCAST service, attributes of the BCAST service, and content attributes.
[39] BCAST-3 123 is a transmission path for attributes of a BCAST service, attributes of content, user preference/subscription information, a user request, and a response to the request. BCAST-4 124 is a transmission path for a notification message, attributes used for a service guide, and a key used for content protection and service protection.
[40] BCAST-5 125 is a transmission path for a protected BCAST service, an unprotected BCAST service, a content-protected BCAST service, a content-unprotected BCAST
service, BCAST service attributes, content attributes, a notification, a service guide, security materials such as Digital Right Management (DRM) Rights Object (RO) and key values used for BCASTservice protection, and all data and signaling transmitted through a broadcast channel.
[41] BCAST-6 126 is a transmission path for a protected BCAST service, an unprotected BCAST service, a content-protected BCAST service, a content-unprotected BCAST
service, BCAST service attributes, content attributes, a notification, a service guide, security materials such as DRM RO and key values used for BCAST service protection, and all data and signaling transmitted through an interaction channel.
[42] BCAST-7 127 is a transmission path for service provisioning, subscription in-formation, device management, and user preference information transmitted through an interaction channel for control information related to receipt of security materials such as DRM RO and key values used for BCAST service protection.
[43] BCAST-8 128 is a transmission path through which user data for a BCAST
service is interacted.
[44] BDS- 1 129 is a transmission path for a protected BCAST service, an unprotected BCAST service, BCAST service attributes, content attributes, a notification, a service guide, and security materials such as DRM RO and key values used for BCAST
service protection.
[45] BDS-2 130 is a transmission path for service provisioning, subscription information, device management, and security materials such as DRM RO and key values used for BCAST service protection.
[46] X-1 131 is a reference point between the BDS Service Distribution 111 and the Broadcast Distribution System 112. X-2 132 is a reference point between the BDS
Service Distribution 111 and the Interaction Network 113. X-3 133 is a reference point between the Broadcast Distribution System 112 and the terminal 105. X-4134 is a reference point between the BDS Service Distribution 111 and the terminal 105 over a broadcast channel. X-5 135 is a reference point between the BDS Service Distribution 111 and the terminal 105 over an interaction channel. X-6 136 is a reference point between the Interaction Network 113 and the terminal 105.
[47] A description is now made of a service guide data model for providing the service guide according to an embodiment of the presentinvention.
[48] FIG. 2 is a diagram illustrating a structure of a service guide data model for use in the OMA BCAST system. In FIG. 2, each block is called fragment, the solid arrows between the fragments indicate reference directions between the fragments.
[49] As shown in FIG. 2, the service guide data model includes an Administrative Group 200 for providing basic information about the entire service guide, a Provisioning Group 21Ofor providing subscription and purchase information, a Core Group 220 as a core part of the service guide, and an Access Group 230for providing access in-formation to control access to services and contents.
[50] The Administrative Group 200 includes a Service Guide Delivery Descriptor (SGDD) 201. The Provision Group 210 includes a Purchase Item 211, a Purchase Data 212, and a Purchase Channel 213. The Core Group 220 Includes a Service 221, a Schedule 222, and a Content 223. The Access Group 230 includes an Access 231 and a Session Description 232.
[51] The service guide data model further includes Preview Data 241 and Interactivity Data 251 in addition to the four information groups 200, 210, 220, and 230.
[52] The aforementioned components are referred to as fragments and are the basic units constituting the service guide.
[53] Hereinafter, descriptions are made of the individual fragments of the service guide data model.
[54] The SGDD fragment 201 provides information about a delivery session where a Service Guide Delivery Unit (SGDU) containing the fragments constituting the service guide is located.The SGDU is a container for containingthe service guide fragments 211, 212, 213, 221, 222, 223, 231, 232, 241, and 251 constituting the service guide.
The SGDD 201 also provides the information on the entry points for receiving the grouping information and notification messages.
[55] The Service Fragment 221, which is an upper aggregate of the content included in the broadcast service, and includes informationon service content, genre, service location and so forth.
[56] The Schedule Fragment 222 defines the timeframes in which associated content items are available for streaming, downloading, and/or rendering.
[57] The Content Fragment 223 provides a detailed description of a specific content item and information about the targeted user group or geographical area as well as genre.
[58] The Access fragment 231 provides access-related information for allowing the user to view the service and delivery method, and session information associated with the corresponding access session.
[59] The Session Description fragment 232 may be included in the Access fragment 231, and provides location information in a Uniform Resource Identifier (URI) form so that the terminal may detect information on the Session Description fragment 232.
The Session Description fragment 232 provides address information, codec information and so forth about multimedia content existing in the session.
[60] The Purchase Item fragment 211 provides a bundle of service, content, time, etc. to help the user subscribe to or purchase the Purchase Item fragment 211.
[61] The Purchase Data fragment 212 includes detailed purchase and subscription in-formation such as price information and promotion information for the service or content bundle.
[62] The Purchase Channel fragment 213 provides access information for a subscription or purchase.
[63] The Preview Data fragment 241 can be used to provide preview information for a service, schedule, and content. Thelnteractivity Data fragment 251 can be used to provide an interactive service according to the service, schedule, and content in the middle of broadcasting.
[64] The detailed information about the service guide can be defined with various elements and attributes for providing detailed contents and values based on the upper data model in FIG. 2.
[65] Although not described, the fragments constituting the service guide can include element and attribute values for fulfilling their purposes.
[66] A message schema table according to an embodimentof the present invention is described hereinafter. Table 1 shows an exemplary schema table for use in an em-bodiment of the present invention.
[67] Table 1 [Table 1]
[Table ]

Name Type Category Cardinality Description Data Type [68] As shown in Table 1, the schema table includes a name field, a type field, a category field, a cardinality field, a description field, and a data type field.
[69] The name field indicates the name of an element value or an attribute vale. The type field indicates the type of the element or the attribute. An element has one of the values, i.e. E1, E2, E3, and E4. E1 is a sub-element of element E, E2 is a sub-element of El, E3 is a sub-element of E2, and E4 is a sub-element of E3. An attribute has a value A and indicates the attribute of an element. For instance, A below El means the attribute of element El.
[70] The category field is used to indicate whether the element/attribute is mandatory or optional, and marked by M for mandatory element/attribute and 0 for optional element/attribute.
[71] The cardinality field indicates the relationship between elements and has a value of "0", "0..1", "l", "O..n", and "1..n". If an element or attribute has a cardinality of 0, it is optional. If an element or attribute has a cardinality of 1, it is mandatory.
Also, if an element or attribute has a cardinality of n, it can have multiple values. For instance, the cardinality "O..n" means that the element or attribute can have no value or n values.
[72] The description field provides detailed description of the element or attribute. The data type field indicates the data type of the element or attribute.
[73] FIG.3 is a block diagram illustrating a relationship between SGDD and SGDU in a Service Guide Data Model of FIG. 2.
[74] Referring to FIG.3, the Service Guide Deliver Descriptor (SGDD) fragment 301 (201 in FIG. 2) includes the session information, grouping information, and notification message access informationrelated to all the fragments containing service information.
Particularly in an embodiment of the present invention, the SGDD 301 includes the in-formation on an RMS template. The description on the information of the RMS
template is made later in more detail.
[75] If a terminal supporting the mobile broadcast service powers on and starts receiving the service guide, the terminal accesses a Service Guide Announcement Channel (SG
Announcement Channel) 300.
[76] The SG Announcement Channel 300 includes at least one SGDD 301 (e.g. SGDD
#1. ......, SGDD #2. ......, SGDD #3) formatted as shown in Table 2.
[77] Table 2 [Table 2]
[Table ]

Name Typ Catego Cardinal Description Data Type e ry ity ServiceGuideDeliveryDe E The Service Guide scriptor Delivery Descriptor-Contains the following attributes:idversionCon tains the following elements:NotificationR
eceptionBSMListDescr iptorEntry Id A NM/T 0.. 1 Unique identifier of anyURI
M the SGDD within one specific SG

Version A NM/T 0.. 1 Version of SGDD. The unsignedln M newer version t overrides the older version as soon as it is received.

NotificationReception E1 NM/T 0.. 1 Reception information M for general Noti-fication Messages. In the case of delivery over Broadcast channel, IPBroadcast-Delivery specifies the address information for receiving Notification Messages.In the case of delivery over In-teraction channel, Re-questURL specify address information for subscribing noti-fication, PollURL

specify address in-formation for polling notification.When the Notification Messages resource pointed to by this element provides Notification Messages carrying a Service Guide update, those SHALL relate to the currently bootstrapped Service Guide.lf this element is present, at least one of the at-tributes "IPBroadcast-Delivery", "Re-questURL", or "PollURL" SHALL be present. Contains the following elements:IPBroadcast DeliveryRequestURLP
o11URL

TimeGroupingCriteria E3 NM/T 0.. 1 Specifies the period of M time this Descrip-torEntry describes.
(For example: declares a certain subgroup of valid Service Guide fragments for next 2 hours). This field contains the 32 bits integer part of an NTP
time stamp.Contains the following at-tributes: startTimeendT
imeA fragment matches the TimeGroupingCriteria if it describes in-formation related to content or interactivity that can be distributed, consumed, or activated during a time interval that is not disjoint with the time interval specified by startTime and/or endTime.

IPBroadcastDelivery E2 NM/T 0.. 1 Provides IP multicast M address and port number for reception of Notification Messages over the broadcast channel.
Contains the following attributes:portaddress startTime A NM/T 1 Start of the time period unsignedln M of TimeGroup- t ingCriteria. This field contains the 32 bits integer part of an NTP
time stamp.

endTime A NM/T 1 End of the time period unsignedln M of TimeGroup- t ingCriteria. This field contains the 32 bits integer part of an NTP
time stamp.

GenreGroupingCriteria E3 NM/T 0.. 1 Specifies the classi- string M fication of the services/content as-sociated with the fragments in this Service Guide Delivery Unit (e.g.
comedy, action, drama).The OMA
BCAST Service Guide allows describing the format of the Genre element in the Service Guide in two ways:The first way is to use a free stringThe second way is to use the "href"
attributes of the Genre element to convey the information in the form of a controlled vocabulary (classification scheme as defined in [TVA-Metadata] or classification list as defined in [MIGFG]).The built-in XML attribute xml:lang MAY be used with this element to express the language.The Network MAY instantiate several different sets of Genre element, using it as a free string or with a href attribute. The Network SHALL
ensure the different sets have equivalent and non-conflicting meaning, and the terminal SHALL select one of the sets to interpret for the end-user.Contains the following at-tributes:typehref Port A NM/T 1 General Notification unsignedln M Message delivery UDP t destination port number; delivery over Broadcast Channel.

Address A NM/T 1 General Notification String M Message delivery IP
multicast address;
delivery over Broadcast Channel.

RequestURL E2 NM/T 0.. 1 URL through which anyURI
M the terminal can subscribe to general Notification Messages;
delivery over In-teraction Channel.

Po11URL E2 NM/T 0.. 1 URL through which anyURI
M the terminal can poll general Notification Messages over In-teraction Channel.

BSMList E1 NM/T 0.. 1 Declaration of the M BSM Selectors which can be used in the GroupingCriteria sections defined below.Contains the following element:BSMSelector BSMSelector E2 NM/T 1..N Specifies the BSM as-M sociated with the fragments in this Service Guide Delivery Unit Allows a terminal to determine whether the SGDUs in this SGDD Descrip-torEntry among the SGDUs that are announced in various DescriptorEntries in various SGDDs is as-sociated with the terminals affiliated BSM(s). The terminals affiliated BSM(s) are represented within terminal as Management Objects with identifier <X>/
BSMSelector/BSMFilt erCodeor as codes on the Smartcard as defined by [3GPP TS
22.0221, [3GPP2 C.S0068-01, [3GPP TS
31.1021, [3GPP2 C.S0023-C], or [3GPP2 C.S0065-01...
For the interpretation of the BSMSelector within the SGDD the following SHALL
apply:lf the BSM-FilterCode present in this element matches to any of the <X>BSMSelector//BS

MFilterCode entries within the terminal, or to any of the codes on the Smartcard, i.e. all of the instantiated at-tributes of BSM-FilterCode have matching instantiated attributes under the <X>/BSMFilterCode or matching codes on the Smartcard, the terminal is able to process, render, interpret and handle the fragments without restrictions. Note that it is considered a match when the in-stantiated attributes under the BMS-FilterCode matches a subset of the in-stantiated attributes of <X>/BSMSelector/BS
MFilterCode or matches a subset of the codes on the SmartCard. However, when the instantiated BSMFilterCode represents a superset of attributes of the <X>/BSMSelector/BS
MFilterCode or a superset of the codes on the Smartcard, it is not considered a match, because not all instantiated attributes under the BSM-FilterCode matches to instantiated attributes of <X>/BSMSelector/BS
MFilterCode or codes on the Smartcard. If the BSMFilterCode present in this element does not match to any of the <X>/BSMSelector/BS
MFilterCode entries within the terminal, i.e.
not all of the in-stantiated attributes of BSMFilterCode have matching instantiated attributes under the <X>/BSMSelector/BS
MFilterCode or codes on the Smartcard, the terminal can render, interpret and handle the fragments according to Roam-ingRules associated with this BSMSelector (identified by the attribute id). In the case the terminal does not have these Roam-ingRules the terminal SHALL NOT render the fragments to the user. The terminal MAY acquire the rules by sending a Roamin-gRuleRequest to address indicated by attribute "roamin-gRuleRequestAddress"
.In the case the terminal has no <X>/BSMSelector/BS
MFilterCode entries or no codes on the Smartcard, for the in-terpretation of the BSMSelector within the SGDD the following SHALL
apply: The terminal can render, interpret and handle the fragments according to RoamingRules as-sociated with this BSMSelector (identified by the attribute id). In the case the terminal does not have these Roam-ingRules the terminal SHALL NOT render the fragments to the user. The terminal MAY acquire the rules by sending a Roamin-gRuleRequest to address indicated by attribute "roamin-gRuleRequestAddress"
.Note: Roamin-gRuleRequest message and associated roaming methods are specified in [BCASTIO-Services].
Contains the following attributes:id roamin-gRuleRequestAddress Contains the following elements : B S MFilterC o deName RoamingRule Type A NO/TO 0..1 This attribute signals string the level of this Genre element.The following values are allowed: "main" "secon dary" "other"

Href A NO/TO 0..1 This attribute signals anyURI
the controlled vo-cabulary used for this Genre element. If this attribute is supported, the following applies to the support and use of classification schemes according to [TVA-Metadata]: for values of the type attribute equal to "main" or "secondary", the terminal MAY
support levels 1-4 of the TV Anytime ContentCS classi-fication scheme identified by the classi ficationSchemeURl urn:tva:metadata:cs:Co ntentCS:2005 as defined in Annex A.8 of [TVA-Metadata] for a value of the type attribute equal to "other", the terminal MAY support levels 1-3 of the TV Anytime IntendedAudienceCS
classification scheme identified by the classi ficationSchemeURl urn:tva:metadata:cs:Int endedAudienceCS:200 5 as defined in Annex A.11 of [TVA-Metadata].
When the IntendedAu-dienceCS is provided simultaneously with an instantiation of the TargetUserProfile, the two SHALL have equivalent meaning.
The network SHALL
use the following URI
syntax to signal terms from classification schemes:
<classificationScheme URI> ":" <termlD> If this attribute is in-stantiated by the network, the element Genre SHALL be an empty string and the xml:lang attribute SHALL NOT be used.If this attribute is supported, the following applies to the support and use of the classification from [MIGFG]: This classi-fication SHALL be signaled with the URI
"http://www.loc.gov/rr/
mopic/miggen.html"
The string value carried in the Genre element SHALL be used to convey the actual value of the classification as given in [MIGFG] The Network MAY use the values "main" and "secondary" of the type attribute so as to provide an ordering of two classifications applying to the same Service.Other Classi-fication Schemes MAY be signaled with the href attribute, however how they are used is out of scope of this specification. If this attribute is not in-stantiated, the Genre element SHALL be a free string.

BSMSelector E3 NM/T O..N Specifies theBSM as-M sociated with the fragments in this Service Guide Delivery Unit by ref-erencing a BSM-Selector structure declared above.Contains the following attribute:idRef idRef A NM/T 1 Reference to the anyURI
M identifier of the BSM-Selector declared within the BSMList above.

ServiceCriteria E3 NM/T 0.. 1 Allows to group anyURI
M fragments by service.
The value of this field is the fragment ID of the Service fragment related to that service.

Transport E2 NM/T 0.. 1 The pointer to the M transport session de-livering the Service Guide fragments within Service Guide Delivery Units announced in this De-scriptorEntry. Contains the following at-tributes:ipAddress, port, srcIpAddress, transmissionSessionlD
, hasFDT

Id A NM/T 1 Identifier of the BSM- anyURI
M Selector. This id is unique within network.
roamingRuleRequestAd A NO/T 0.. 1 Address to which the anyURI
dress M terminals can send the RoamingRuleRequests to request Roam-ingRules associated with this BSMSelector (identified with the id attribute).

BSMFilterCode E3 NM/T 0.. 1 The code that specifies M this BSMSelector.
Contains the following attributes:typeserviceP
roviderCodecorporate CodeserviceProviderN
amenonSmartCardCod eContains the following elements:NetworkCod e3GPPNetworkCode3 GPP2Note: At most either Net-workCode3GPP or NetworkCode3GPP2 SHALL be present.
Implementation in XML Schema should use <choice>.

ipAddress A NM/T 1 Destination IP address String M of the target delivery session Port A NM/T 1 Destination port of unsignedS
M target delivery session hort srcIpAddress A NM/T 0.. 1 Source IP address of string M the delivery sessionln the case where source specific multicast scheme is applied in the transmission, then the 'srcIpAddress' attribute SHALL have as its value the IP
address found in the IP-packets belongingto the IP-stream in question.In the case where this attribute is omitted, there SHALL
only be one source IP
address from which the file delivery session originates which is defined by the com-bination of destination IP address, port and transmission session ID given.

Type A NM/T 1 The type of bsm- unsignedB
M FilterCode.1 yte BSMCode (Smart Card Code) This is used if the determination is made based on the country and operator code in the (U)SIM/(R-)UIM/CSI
M2 BSMCode (Non Smart Card Code):This is used if the deter-mination is made based on the country and operator code in the terminalOther values are reserved.
transmissionSessionlD A NM/T 1 This is the unsignedS
M Transmission Session hort Identifier (TSI) of the session at ALC/LCT
level hasFDT A NO/T 0.. 1 If FDT is transmitted Boolean M in the transport session delivering the Service Guide fragments, this attribute SHALL be set to "true". Otherwise this attribute SHALL
be set to "false". The default value of this attribute is "true".If this element is set to "false", the FEC pa-rameters related to transport objects de-livering SGDUs in the transport session SHALL be signaled using EXT_FTI [RFC
3926].the optional compression of SGDUs SHALL be signaled using EXT_CENC [RFC
3926]. Note that EXT_CENC was originally defined in [RFC 3926] for signaling the encoding of the FDT, but is assigned to a different usage in this speci-fication for the specific case of SGDU delivery directly using ALC.

serviceProviderCode A NO/T 0.. 1 Service Provider Code unsignedB
M as specified by [3GPP yte TS 22.022] or [3GPP2 C. S006 8 -01. Applicable only when "type" == 1 corporateCode A NO/T 0.. 1 Corporate Code as unsignedB
M specified by [3GPP TS yte 22.022] or [3GPP2 C. S006 8 -01. Applicable only when "type" == 1 serviceProviderName A NO/T 0.. 1 Service Provider Name String M (SPN) as specified by [3GPP TS 31.1021, [3GPP2 C.S0023-C], or [3GPP2 C. S0065 -01. Applicable only when "type" == 1 nonSmartCardCode A NO/T 0.. 1 Value of BSM- String M FilterCode when ""type" == 2 NetworkCode3GPP E4 NO/T 0.. 1 IMSI-based Network, M Network Subset or SIM/USIM codes as specified by [3GPP TS
22.0221. Applicable only when "type"==
1.Contains the following at-tributes: -mobileCountr yCode-mobileNetwork Code-networkSubsetC
ode-networkSubsetCod eRangeStart-networkS

ubsetCodeRangeEnd-c odeRangeStart-codeRa ngeEnd AlternativeAccessURL E2 NM/T O..N Declares the al- anyURI
M ternative URL for re-trieving the Service Guide fragments, declared in the parent DescriptorEntry element, via the in-teraction channel. In addition, fragments not declared in the parent DescriptorEntry MAY
also be available.
Terminal MAY check the availability of un-declared fragments by issuing an unspecific Service Guide request against the Alterna-tiveAccessURL, as specified in section 5.4.3.2 of the present document.If there are multiple instances of AlternativeAccessURL
signaled, the terminal SHALL randomly select one of them to use. Note: usage of this element is specified in section 5.4.1.5.4 of the present document.

mobileCountryCode A NO/T 0.. 1 Mobile Country Code string of 3 M (3 digits) as specified digits by [3GPP TS 22.022].

networkSubsetCodeRan A NO/T 0.. 1 Instead of providing an string of 2 geStart M explicit code in digits attribute network-SubsetCode, the network MAY instead provide a continuous range of codes. In such a case the network SHALL provide the smallest code for the terminal to accept in this attribute, the greatest code in the attribute networkSub-setCodeRangeEnd and SHALL not instantiate attribute network-SubsetCode.The terminal SHALL
interpret all the code values between the smallest and the greatest code as values to be accepted.
ServiceGuideDeliveryU E2 NM/T 1..N A group of nit M fragments. Contains the following at-tributes:transportObjec tID,versionIDLength,c ontentLocation,validFr om,validToContains the following element:Fragment [78] Table 2 describes the elements and attributes constituting a SGDD
fragment 301. The SGDD 301 can be expressed in the form of an eXtensible Markup Language (XML) schema. Table 2 is partitioned into a plurality of parts for convenience, and individual parts describe corresponding items.
[79] Actual data is provided in XML format according to the content of the SGDD 301.
The information related to the service guide can be provided in various data format(such as binary) having the elements and attributes set to corresponding values, depending on the broadcast system.
[80] The SGDD 301 transported on the SG Announcement Channel 300 includes the De-scription Entry 302. The Description Entry 302 contains the transport information about the SGDU312 carrying the fragment information, and the terminal 105 checks the transport information of the SGDU 312 by means of the Description Entry 302. As shown in Table 2, the Description Entry 302 includes "GroupingCriteria", "Ser-viceGuideDeliveryUnit", "Transport", and "AlternativeAccessURI".
[81] The transport-related channel information is provided by the "Transport"
or "Alterna-tiveAccessURI", and the actual value of the corresponding channel is provided by "Ser-viceGuideDeliveryUnit".
[82] Also, the upper layer group informationabout the SGDU 312 such as "Service" and "Genre" can be provided by "GroupingCriteria". The terminal 105 can receive and present all of the SGDUs 312 to the user according to the corresponding group in-formation.
[83] Once the transport information has been checked, the terminal 105 accesses all of the Delivery Channels acquired from the SGDD 301 on the SG Delivery Channel 310 to receive the actual SGDU 312.
[84] The SG Delivery Channels 310 can be identified by using the "GroupingCriteria". In the case of time grouping, the SGDU can be transported with a time-based transport channel such as Hourly SG Channel 311 and Daily SG Channel.
[85] Accordingly, the terminal 105 can selectively access the channels and receive all the SGDUs existing on the corresponding channels. Once all of the SGDUs have been completely receivedon the SG Delivery Channels 310, the terminal 105 checks all of the SG fragments 320 (211, 212, 213, 221, 222, 223, 231, 232, 241, and 251 in FIG. 2) carried by the SGDUs received on the SG Delivery Channels and assembles the SG
fragments to displays an actual service guide on the screen.
[86] In an embodiment of the present invention, all of the service guide fragments can be output with the RMS template. The description of the service guide provisioning method based the RMS template according to an embodiment of the present invention is described hereinafter.
[87] RMSis the acronym standing for "Rich Media Solution" which is defined in the OMA BCAST standard to comprehensively express the rich media technologies.
[88] If the RMSis directly applied to the service guide fragment including the service guide information in order to display the service guide, the legacy BCAST
terminals do not interpret or process the newly introduced service guide due the lack of com-patibility. In order to solve the compatibility problem, the RMStemplate is configured such that the terminals supporting the RMS, display the service guide using the RMS
template, while the legacy terminals display the service guide in their own display format.
[89] The information on the RMS template (hereinafter called RMS information) is transported on the SGDD. In a first embodiment of the present invention, the SGDD
includes the RMS information as shown in FIG. 7 and Table 3 in addition to the in-formation as shown in Table 2.
[90] Table 3 describes the RMS informationaccording to the first embodiment of the present invention.
[91] Table 3 [Table 3]
[Table ]

Name Ty Category Cardinali Description pe ty RMS El NO/TO 1 An entry in the Service Guide Delivery Descriptor. Signals the existence of Rich Media Solution template documents for SG.Contains the following elements:RMSTemplate RMSTemplate E2 NO/TM 1. .n Access details for retrieving Rich Media Solution template document.
Contains the following elements: ScreenSizeContains the following attributes:typeversion Type A NM/TM 1 The RMS used to create the Service Guide template document. Allowed values are:O - W3C SVG Tinyl -OMA RME2 - MPEG LASeR3 -3GPP DIMS4 - 127 reserved for future use128 - 255 reserved for pro-prietary use Version A NM/TM 1 Version of the RMS used to create the Service Guide template.
ScreenSize E3 NM/TM 1. .n Provides the screen size to allow terminals to correctly retrieve the RMS template applicable to the terminal.Contains the following elements:TransportAltemativeURLC
ontains the following at-tributes:valuecompression Value A NM/TM 1 The minimum screen resolution required for rendering the RMS
template. Allowed values are: (width * height)O -Applies to all screensl -320 * 2402 - 240 * 3203 - 480 3204 - 320 * 4805 - 640 * 4806 - 480 * 6407 - 800 * 4808 - 480 * 8009 -127 reserved for future use 128 - 255 reserved for proprietary use compression A NM/TM 1 The compression algorithm used to-compress the RMS template.
Allowed values are:0 - None 1 -Gzip2 - BIM3 - 127 reserved for future use128 - 255 reserved for pro-prietary uses Transport E4 NM/TM 1 The pointer to the transport session delivering the RMS
template. Contains the following at-tributes: ipAddressportsrcIpAddresstr ansmissionSessionlDhasFDTtransmi ssionObjectlDcontentLocation ipAddress A NM/TM 1 Destination IP address of the target delivery session Port A NM/TM 1 Destination port of target delivery session srcIpAddress A NM/TM 0.. 1 Source IP address of the delivery sessionln the case where source specific multicast scheme is applied in the transmission, then the 'srcl-pAddress' attribute SHALL have as its value the IP address found in the IP-packets belonging to the IP-stream in question.In the case where this attribute is omitted, there SHALL
only be one source IP address from which the file delivery session originates which is defined by the combination of destination IP
address, port and transmission session ID given.

transmissionSession A NM/TM 1 This is the Transmission Session ID Identifier (TSI) of the session at ALC/LCT level hasFDT A NO/TM 0..1 If FDT is transmitted in the transport session delivering the RMS template, this attribute SHALL be set to "true".
Otherwise this attribute SHALL be set to "false". The default value of this attribute is "true".If this element is set to "false", (1) the FEC pa-rameters related to transport objects delivering SGDUs in the transport session SHALL be signaled using EXT_FTI[RFC 39261, and(2) the optional compression of SGDUs SHALL be signaled using EXT_CENC [RFC 39261. Note that EXT_CENC was originally defined in [RFC 3926] for signaling the encoding of the FDT, but is assigned to a different usage in this speci-fication for the specific case of SGDU delivery directly using ALC.

transmissionObjectl A NMTM 1 The Transport Object ID of the RMS
D template. If hasFDT is assigned with value true, then the value of trans-portObjectlD SHALL match the value of the TOI paired in the FDT
instance with the Content-Location having as its value the value of the contentLocation attribute below.

contentLocation A NM/TM 0..1 The location of the RMS template. It corresponds to the Content-Location attribute in the FDT.If and only if attribute hasFDT is instantiated, SHALL this attribute be instantiated.

AlternativeURL E4 NM/TM 0..1 Declares the alternative URL for re-trieving the RMS template, declared in the parent RMSTemplate element, via the interaction channel.
[92] In Table 3, the data type field as described with reference to Table 1 is omitted.
[93] Referring to Table 3, the RMS information according to an embodiment of the present invention includes information on an RMS template flag for indicating whether the RMS template exists, information about the RMS template, information about the requirement for executing the RMS template, and information on the transport of the RMS template.
[94] The RMS information includes the elements and attributes such as RMS, RM-STemplete, Type, Version, ScreenSize, Value, Compression, Transport, IpAddress, port, srclPAddress, TransmissionSessionlD, hasFDT, TransmissionObjectlD, content-Location, and AlternativeURL.
[95] The RMS is a higher element used to indicate whether an RMS template for use to display the service guide exists.
[96] The RMSTemplate is an element for indicating the at least one RMS
technology available with the RMS template.
[97] The Type is an attribute that indicates the RMS used to create the service guide template document.
[98] The Version is an attribute that indicates the version of the RMS used to create the service guide template.
[99] In Table 3, the value "W3C" of the Type attribute includes the SVG, SVB
Basic, SVG mobile, etc. that are derived from the Scalable Vector Graphics (SVG).
[100] The ScreenSize is an element for providing the screen size to allow the terminals to correctly retrieve the RMS template applicable to the terminal.
[101] The Value is an attribute indicating the minimum screen resolution required for rendering the RMS template. Although the value of this attribute is expresses by "width * height" in Table 3, the value can also be expressed by pixel resolution, diagonal length of the screen, or standardized formats such as Common Intermediate Format/Quarter Common Intermediate Format (CIF/QCIF).
[102] The Compression is an attribute indicating whether or not the RMS is compressed and, if compressed, the compression algorithm used to compress the RMS
template.
[103] The Transport is an element for indicating the pointer to the transport session de-livering the RMS template.
[104] The IpAddress is an attribute for providing the information the destination address of the target delivery session, and the Port is an attribute for providing the information on the Destination port of the target delivery session.
[105] The srclpAddress is an attribute for providing the information on the source IP

address of the delivery session, i.e. the IP address required for the source specific mul-ticasting.
[106] The TransmissionSessionlD is an attribute indicating the Transmission Session Identifier (TSI) of the session.
[107] The has FDT is an attribute for indicating whether the FDT is transmitted in the transport session delivering the RMS template. If this attributed is set to "true", the file name of the RMS template is indicated by using the contentLocation attribute such that the terminal 105 receives the RMS template.
[108] The TransmissionObjectlD is an attribute indicating the Transport Object ID of the RMS template.
[109] The AlternativeURL is an element for providing the information used when the RMS
template is delivered via one-to-one interaction channel.
[110] In accordance with an embodiment of the present invention, the RMS
information is transported on the SGDD, and the terminal receives the RMS template using the RMS
information. As described with reference to FIGs. 2, 3, and 7, the terminal receives the service guide (service guide fragment) and outputs the received service guide using the RMS template.
[111] In the second embodiment of the present invention, the SGDD includes the RMS in-formation as shown in FIG. 7 and Table 4 in addition to the information as shown in Table 2. Table 4 describes the RMS information according to the second embodiment of the present invention. The RMS information represented by Table 4 is defined to support the case where multiple BCAST Subscription Managements (BSMs) share the SGDD.
[112] Table 4 [Table 4]
[Table ]

Name Type Categor Cardinali Description y ty ServiceGuideDeliveryDescript E The Service Guide or Delivery Descriptor-Contains the following attributes:idversionContai ns the following elements:NotificationRec eptionBSMListDescriptor EntryTerminalCapability Id A NM/TM 0.. 1 Unique identifier of the SGDD within one specific SGThis attribute SHALL be instantiated if the SGDD is delivered over broadcast channel version A NM/TM 0.. 1 Version of SGDD. The newer version overrides the older one as soon as it has been received.This attribute SHALL be in-stantiated if the SGDD is delivered over broadcast channel NotificationReception El NO/TO 0.. 1 Reception information for general Notification Messages. In the case of delivery over Broadcast channel, IPBroadcast-Delivery specifies the address information for receiving Notification message.In the case of delivery over Interaction channel, PollURL specify address information for polling notification and 'PollPeriod' specifies the associated polling period.When the Noti-fication Message resource pointed by this element provides Notification Messages carrying Service Guide update, those SHALL relate to the currently boot-strapped Service Guide.If this element is present, at least one of the elements "IPBroadcastDelivery", or "PollURL" SHALL be present. This element SHALL be supported by the Network when it supports the Notification function. Similarly, this element SHALL be supported by the Terminal when it supports the Notification function. Contains the following elements:IPBroadcastDeli veryPollURLPollPeriod IPBroadcastDelivery E2 NM/TM 0.. 1 Provides IP multicast address and port number for reception of Noti-fication Messages over the broadcast channel.
Contains the following attributes:portaddress Port A NM/TM 1 General Notification Message delivery UDP
destination port number;
delivery over Broadcast Channel.

address A NM/TM 1 General Notification Message delivery IP
multicast address;
delivery over Broadcast Channel.

Po11URL E2 NM/TM O..N URL through which the terminal can poll general Notification Messages over Interaction Channel.If there are multiple instances of "PollURL" signaled, the terminal SHALL balance polling requests, within the set of "PollURL".
Further, after having selected randomly, at a given time, a given URL, the terminal SHOULD
use it for a while to benefit from cache management information as specified in HTTP 1.1 [ RFC 2616], as it is reminded that this in-formation is scoped to one given URL.

PollPeriod E2 NO/TM 0.. 1 While polling the Noti-fication Messages, the NTC is expected to poll every "PollPeriod"

seconds. When this attribute is instantiated, no caching mechanisms of HTTP 1.1 [RFC 2616]
SHOULD conflict with the fact that the NTC is expected to request for a fresh set of Notification Messages every "PollPeriod" value.The unit of this attribute is seconds.

BSMList El NM/TM 0.. 1 Declaration of the BSM
Selectors which can be used in the Group-ingCriteria sections defined below.Contains the following element:BSMSelector BSMSelector E2 NM/TM 1..N Specifies the BSM as-sociated with the fragments in this Service Guide Delivery Unit Allows a terminal to determine whether the SGDU's in this SGDD
DescriptorEntry - among the SGDU's that are announced in various De-scriptorEntries in various SGDD's - is associated with the terminal's af-filiated BSM(s). The terminal s affiliated BSM(s) are represented within terminal as Management Objects with identifier <X>BSMSelector/BSMF
ilterCode or as codes on the Smartcard as defined by [3GPP TS 22.022], [3GPP2 C.S0068-01, [3GPP TS 31.1021, [3GPP2 C.S0023-C], or [3GPP2 C.S0065-01...
For the interpretation of the BSMSelector within the SGDD the following SHALL apply: If the BSMFilterCode present in this element matches to any of the <X>BSMSelector/BSMF
ilterCode entries within the terminal, or to any of the codes on the Smartcard, i.e. all of the instantiated attributes of BSMFilterCode have matching instantiated at-tributes under the <X>/BSMFilterCode or matching codes on the Smartcard, the terminal is able to process, render, interpret and handle the fragments without re-strictions. Note that it is considered a match when the instantiated attributes under the BMSFilter-Codematches a subset of the instantiated attributes of <X>/BSMSelector/BSM
FilterCode or matches a subset of the codes on the SmartCard. However, when the instantiated BSMFilterCode represents a superset of attributes of the <X>/BSMSelector/BSM
FilterCode or a superset of the codes on the Smartcard, it is not considered a match, because not all in-stantiated attributes under the BSMFilterCode matches to instantiated attributes of <X>/BSMSelector/BSM
FilterCode or codes on the Smartcard. If the BSMFilterCode present in this element does not match to any of the <X>/BSMSelector/BSM
FilterCode entries within the terminal, i.e. not all of the instantiated attributes of BSMFilterCode have matching instantiated at-tributes under the <X>/BSMSelector/BSM
FilterCode or codes onthe Smartcard, the terminal can render, interpret and handle the fragments according to Roam-ingRules associated with this BSMSelector (identified by the attribute id). In case the terminal does not have these RoamingRules the terminal SHALL NOT
render the fragments to the user. The terminal MAY acquire the rules by sending a Roamin-gRuleRequest to address indicated by attribute roamingRuleRequestAdd ress.In the case where the terminal has no <X>/BSMSelector/BSM
FilterCode entries or no codes on the Smartcard, for the interpretation of the BSMSelector within the SGDD the following SHALL apply: The terminal can render, interpret and handle the fragments according to RoamingRules associated with this BSMSelector (identified by the attribute id). In the case where the terminal does not have these Roam-ingRules the terminal SHALL NOT render the fragments to the user.
The terminal MAY
acquire the rules by sending a Roamin-gRuleRequest to address indicated by attribute roamingRuleRequestAdd ress.Note: Roamin-gRuleRequest message and associated roaming methods are specified in [BCAST 10-Services] .Co ntains the following at-tributes:id roamin-gRuleRequestAddressCo ntains the following elements : B S M FilterCode Name RoamingRuleNoti-ficationReceptionRMS

Id A NM/TM 1 Identifier of the BSM-Selector. This id is unique within the network.

roamingRuleRequestAddress A NO/TO 0.. 1 Address to which the terminals can send the RoamingRuleRequests to request RoamingRules associated with this BSMSelector (identified with the id attribute).Terminals supporting Broadcas-tRoaming SHALL
support this attribute.

BSMFilterCode E3 NM/TM 0.. 1 The code that specifies this BSMSelector.
Contains the following attributes:typeservicePro viderCodecorporateCode serviceProviderNamenon SmartCardCodeContains the following elements : NetworkCode 3 GPPNetworkCode3GPP2 Note: At most either 'Net workCode3GPP' or 'Net-workCode3GPP2' SHALL be present. Im-plementation in XML
Schema should use <choice>.

Type A NM/TM 1 The type of bsm-FilterCode. 1 - BSMCode (Smart Card Code) This is used if the deter-mination is made based on the country and operator code in the (U)SIM/(R-)UIM/CSIM2 - BSMCode (Non Smart Card Code):This is used if the determination is made based on the country and operator code in the terminalOther values are reserved.

serviceProviderCode A NO/TM 0.. 1 Service Provider Code as specified by [3GPP TS
22.022] or [3GPP2 C.S0068-01.Applicable only when "type" == 1 corporateCode A NO/TM 0.. 1 Corporate Code as specified by [3GPP TS
22.022] or [3GPP2 C.S0068-01.Applicable only when "type" == 1 serviceProviderName A NO/TM 0.. 1 Service Provider Name (SPN) as specified by [3GPP TS 31.1021, [3GPP2 C.S0023-C], or [3GPP2 C.S0065-01.Applicable only when "type" == 1 nonSmartCardCode A NO/TM 0.. 1 Value of BSMFilterCode when "type" == 2 NetworkCode3GPP E4 NO/TM 0.. 1 IMSI-based Network, Network Subset or SIM/
USIM codes as specified by [3GPP TS 22.022].
Applicable only when "type" == 1.Contains the following at-tributes:mobileCountryC
odemobileNetworkCoden etworkSubsetCodenetwor kSubsetCodeRangeStartn etworkSubsetCodeRange EndcodeRangeStartcode RangeEnd mobileCountryCode A NO/TM 0.. 1 Mobile Country Code (3 digits) as specified by [3GPP TS 22.0221.

mobileNetworkCode A NO/TM 0.. 1 Mobile Network Code (2-3 digits) as specified by [3GPP TS 23.003].

networkSubsetCode A NO/TM 0.. 1 Network Subset Code (2 digits) as specified by [3GPP TS 22.0221.

networkSubsetCodeRangeStar A NO/TM 0.. 1 Instead of providing an t explicit code in attribute 'networkSubsetCode' the network MAY instead provide a continuous range of codes. In such a case the network SHALL

provide the smallest code for the terminal to accept in this attribute, the greatest code in the attribute 'networkSubset-CodeRangeEnd' and SHALL not instantiate attribute 'network-SubsetCode'The terminal SHALL interpret all the code values between the smallest and the greatest code as values to be accepted.

networkSubsetCodeRangeEnd A NO/TM 0.. 1 This attribute signals the end of the range of Network Subset Codes as specified above.

codeRangeStart A NO/TM 0.. 1 This attribute signals the lowest code value from a continuous range of one or more codes, which is used by the BCAST
Terminal to determine whether a match exists with the local SIM/USIM
code. The Terminal SHALL accept all code values between (and inclusive of) the lowest and highest code value for matching against the local SIM/USIM code.

codeRangeEnd A NO/TM 0.. 1 This attribute signals the highest code value for the BCAST Terminal to be considered valid for matching against the local SIM/USIM code, as described above.

NetworkCode3GPP2 E4 NO/TM 0.. 1 IMSI and/or NAI based Network or (R-)UIM/CSIM codes as specified by [3GPP2 C.S0068-01. Applicable only when "type" ==
1.Contains the following attributes:mobileCountry CodemobileNetworkCod eiRMBasedMlNhRPDRe almruimCSlMCodeRang eStartruimCSIMCodeRan geEnd mobileCountryCode A NO/TM 0.. 1 Mobile Country Code (3 digits) as specified for Network Type 1 by [3GPP2 C.S0068-01.

mobileNetworkCode A NO/TM 0.. 1 Mobile Network Code (2-3 digits) as specified for Network Type 1 by [3GPP2 C.S0068-01.

iRMBasedMlN A NO/TM 0.. 1 First 4 digits of IRM-based MIN as specified for Network Type 2 by [3GPP2 C.S0068-01.

hRPDRealm A NO/TM 0.. 1 REALM code of the relevant HRPD network as specified by [3GPP2 C.S0068-0].

ruimCSlMCodeRangeStart A NO/TM 0.. 1 (R-)UIM or CSIM code, as specified in [3GPP2 C.S0023-C], [3GPP2 C.S0065-0] or [3GPP2 C.S0068-0].This attribute signals the lowest code value from a continuous range of one or more codes, which is used by the BCAST Terminal to determine whether a match exists with the local (R-)UIM/CSIM
code. The Terminal SHALL accept all code values between (and inclusive of) the lowest and highest code value for matching against the local (R-)UIM/CSIM
code.

ruimCSlMCodeRangeEnd A NO/TM 0.. 1 (R-)UIM or CSIM code, as specified in [3GPP2 C.S0023-C], [3GPP2 C.S0065-0] or [3GPP2 C.S0068-0].This attribute signals the lowest code value from a continuous range of one or more codes, which isused by the BCAST Terminal to determine whether a match exists with the local (R-)UIM/CSIM
code. The Terminal SHALL accept all code values between (and inclusive of) the lowest and highest code value for matching against the local (R-)UIM/CSIM

code.
Name E3 NM/TM 1. .N Provides a user readable name for the BSM_Selector, possibly in multiple languages.The language is expressed using built-in XML
attribute xml:lang with this element.This element can be used to provide in-formation to the user so he can select the BSM-Selector the terminal has to use.

RoamingRule E3 NO/TO O..N Specifies a Roaming Rule associated with BSMSelector. The Roaming Rule specified by this element is not specific to any Home BSM. Such Roaming Rule can be interpreted as generic to any Home BSM, although the validity of the Roaming Rule for a particular pair of Visited BSM (as declared by the parent BSMSelector element) and Home BSM is not guaranteed. Contains the following attributes:
allowAlldenyAllContain s the following elements: TimeFrameAll owPurchaseltemAllowP
urchaseDataAllowServi ceAllowContentDenyPu rchaseltemDenyPurcha seDataDenyServiceDen yContentTerminals supporting Broadcast Roaming SHALL
support this element.
The terminal SHALL
interpret RoamingRule for each fragment so that in case 'allow' rule and 'deny' rule apply si-multaneously, the 'deny' rule takes precedence.

allowAll A 0 0..1 Rule that, when set to "true", allows the Terminal to use all the fragments associated with BSMFilterCode as-sociated with these RoamingRules.The default value of this attribute is "false".This attribute SHALL not be present if attribute 'denyAll' is present.

denyAll A 0 0..1 Rule that, when set to "true", prohibits the Terminal to use any the fragments associated with BSMFilterCode as-sociated with these RoamingRules.The default value of this attribute "false".This attribute SHALL not be present if attribute 'allowAll' is present.
TimeFrame E4 0 O..N Rule that defines the time frame(s) this RoamingRule is applies to.Contains the following attributes:
startTimeendTime startTime A 0 0..1 Start of the time frame.
If not given, the time frame is assumed to have started at some time in the past. This field is expressed as the first 32bits integer part of NTP time stamps.

endTime A 0 0..1 End of the time frame.
If not given, the time frame is assumed to end at some time in the future. This field is expressed as the first 32bits integer part of NTP time stamps.

AllowPurchaseltem E4 0 0..1 Rule that allows the Terminal to use the listed Purchaseltems.
This element SHALL
not be present if one of "allowAll" or "denyAll" attribute is present.Contains the following element:Id Id E5 M 1..N This element contains value that represents GlobalPurchaseItemlD
that is allowed to be in-terpreted, rendered and accessed.

AllowPurchaseData E4 0 0..1 Rule that allows the Terminal to use the listed PurchaseData items.This element SHALL not be present if one of "allowAll" or "denyAll" attribute is present.Contains the following element:Id Id E5 M 1..N This element contains value that represents PurchaseData fragment ID that is allowed to be interpreted, rendered and accessed.

AllowService E4 0 0..1 Rule that allows the Terminal to use the fragments corre-sponding to listed glob-alServicelDs.This element SHALL not be present if one of "allowAll" or "denyAll" attribute is present.Contains the following element:Id Id E5 M 1..N This element contains value that represents globalServiceID.
Fragments associated with this glob-alServiceID are allowed to be interpreted, rendered and accessed.

AllowContent E4 0 0..1 Rule that allows the Terminal to use the fragments corre-sponding to listed glob-alContentlDs. This element SHALL not be present if one of "allowAll" or "denyAll" attribute is present.Contains the following element:Id Id E5 M 1..N This element contains value that represents globalContentlD.
Fragments associated with this global-ContentlD are allowed to be interpreted, rendered and accessed.

DenyPurchaseltem E4 0 0..1 Rule that denies the Terminal to use the listed Purchaseltems.
This element SHALL
not be present if one of "allowAll" or "denyAll" attribute is present.Contains the following element:Id Id E5 M 1..N This element contains value that represents globalPurchaseltemlD
that is denied to be in-terpreted, rendered and accessed..

DenyPurchaseData E4 0 0..1 Rule that denies the Terminal to use the listed PurchaseData items.This element SHALL not be present if one of "allowAll" or "denyAll" attribute is present.Contains the following element:Id Id E5 M 1..N This element contains value that represents PurchaseData fragment ID that is denied to be interpreted, rendered and accessed..

DenyService E4 0 0..1 Rule that denies the Terminal to use the fragments corre-sponding to listed glob-alServicelDs.This element SHALL not be present if one of "allowAll" or "denyAll" attribute is present.Contains the following element:Id Id E5 M 1..N This element contains value that represents globalServiceID.
Fragments associated with this glob-alServiceID are denied to be interpreted, rendered and accessed.

DenyContent E4 0 0..1 Rule that denies the Terminal to use the fragments corre-sponding to listed glob-alContentlDs. This element SHALL not be present if one of "allowAll" or "denyAll" attribute is present.Contains the following element:Id Id E5 M 1..N This element contains value that represents globalContentlD.
Fragments associated with this global-ContentlD are denied to be interpreted, rendered and accessed.

NotificationReception E3 NO/TM 0..1 Reception information for Notification messages specific to the parent BSMSelector.
The terminal SHALL
scope the information provided in Notification messages delivered via the children 'IPBroad-castDelivery' or 'PollURL' to the parent 'BSMSelector'.In case of delivery over Broadcast channel, IP-BroadcastDelivery specifies the address in-formation for receiving Notification message.In case of delivery over In-teraction channel, Po11URL specify address information for polling notification, and 'PollPeriod' specifies the associated polling period.If this element is present, at least one of the elements "IPBroad-castDelivery", or "PollURL" SHALL be present. Contains the following elements: IP-BroadcastDeliveryPollU
RLPollPeriod IPBroadcastDelivery E4 NM/TM 0.. 1 Provides IP multicast address and port number for reception of Notification Messages over the broadcast channel. Contains the following attributes:
portaddress port A NM/TM 1 BSM-specific Noti-fication Message delivery UDP des-tination port number;
delivery over Broadcast Channel.

address A NM/TM 1 BSM-specific Noti-fication Message delivery IP multicast address; delivery over the Broadcast Channel.

Po11URL E4 NM/TM O..N URL through which the terminal can poll Noti-fication messages over the Interaction Channel.If there are multiple instances of "Po11URL" signaled, the terminal SHALL
balance polling requests, within the set of "PollURL". Further, after having selected randomly, at a given time, a given URL, the terminal SHOULD use it for a while to benefit from cache management in-formation as specified in HTTP 1.1 [RFC
2616], as it is reminded that this information is scoped to one given URL.

PollPeriod E4 NO/TM 0..1 While polling the related service-specific Notification Messages, the NTC is expected to poll every "PollPeriod"
seconds. When this attribute is instantiated, no caching mechanisms of HTTP 1.1[RFC 2616]
SHOULD conflict with the fact that the NTC is expected to request for a fresh set of Noti-fication Messages every "PollPeriod" value.The unit of this attribute is seconds RMS E3 NO/TO 0..1 Signals the existence of Rich Media Solution template documents for SG.Contains the following elements:RMSTemplate RMSTemplate E4 NO/TM 1..n Access details for re-trieving Rich Media Solution template document. Contains the following elements:CriteriaUpdateC
apabilitiesTransportAlter nativeURLGlobalContent Id Criteria E5 NO/TO O..N Declares the criteria required for receiving this template Contains the following attributes:
template V ersionattribut eNameattributeValue templateVersion A NO/TM 1 The version of the template. If the template version is newer than the one stored on the terminal then the terminal is ap-plicable to receive the RMS template.

attributeName A NO/NM 1 Profile attribute name attributeValue A NO/TM 1 Profile attribute value Capabilities E5 NO/TM 1 Contains the following attributes : typeversionC
ontains the following element:MIMETypeCom plexity type A NM/TM 1 Indicate the type of RM
content. Allowed values are:O according to MIME

typel W3C SVG Tiny2 LASeR4 3GPP DIMS5 127 reserved for future use 128 - 255 reserved for proprietary use version A NM/TM 1 Defines the version as-sociated with the type MIMEType E6 NM/TM O..N MIME Media type of the rich media content.
Contains the following attribute: Codec codec A NM/TM 0..1 The codec parameters for the associated MIME Media type. If the file's MIME type definition specifies mandatory parameters, these MUST be included in this string.
Optional parameters containing information that can be used to determine as to whether the terminal can make use of the file SHOULD
be included in the string. One example of the parameters defined for video/
richmedia+xml is defined in Section 7 of 3GPP DIMS speci-fication.

Complexity E6 NM/TM 1 The complexity the rich media engine has to deal with. Contains the following attributes:
profilesceneUpdateCom mandsscreenOrientatio nContains the following elements:AnimationsE
mbeddedMediaElement sDOMnodesScriptingC
ompression profile A NO/TO 0..1 Defines the profile/level of the RMSExample:
For DIMS: mobile profile level l0For LASeR: 2006 amdl Note: it is conditional on the 'type' and 'version' attributes sceneUpdateCommands A NO/TM 1 Indicates whether the rich media content requires the processing of scene update commands to render the content.Default: False screenOrientation A NO/TM 1 Indicates whether the rich media scene requires scene ori-entation management Default: False Animations E6 NO/TM 1 The number of an-imations in the rich media scene.Contains the following attributes:
Maximum maximum A NM/TM 0.. 1 The maximum number of animations in the rich media scene EmbeddedMediaElements E6 NM/TM 1 The number of embedded media elements (i.e. video and audio) in the rich media scene. Contains the following attributes: em-beddedVideoembedded Audio embeddedVideo A NM/TM 0..1 The number of con-currently running embedded video elements in the rich media scene.

embeddedAudio A NM/TM 0..1 The number of con-currently running embedded audio elements in the rich media scene.

DOMNodes E6 NO/TM 1 The number of DOM
nodes required to render the rich media contentContains the following attributes:
Maximum maximum A NM/TM 1 The maximum number of active DOM nodes in a rich media scene at any given time.

Scripting E6 NO/TM 1 Indicates whether the rich media scene requires the processing of scripts (for e.g. EC-MAScript) to render the content.Contain the following attribute:
MIMEType MIMEType A NM/TM 0..1 Indicates the MIMEtype of the script used within the Rich Media content.If not present is indicates that the content does not contain any script.

Compression E6 NO/TM 1 Indicates whether the delivered rich media scene is compressed/
encoded or not.
Contains the following attribute: contentEncodi ng content Encoding A NM/TM 1 Scheme used to encode/
compress the rich media contentO- None 1- XML
2- Gzip3- LASeR4- BiM
127 reserved for future use 128 - 255 reserved for proprietary useNote:
default value is 0.

Transport E5 NM/TM 0.. 1 The pointer to the transport session de-livering the RMS
template.Contains the following at-tributes:ipAddressportsrc IpAddresstransmissionSe ssionlDhasFDTtransmissi onObjectlDcontentLocati on ipAddress A NM/TM 1 Destination IP address of the target delivery session Port A NM/TM 1 Destination port of target delivery session srcIpAddress A NM/TM 0.. 1 Source IP address of the delivery sessionIn the case where source specific multicast scheme is applied in the transmission, then the 'sr-cIpAddress' attribute SHALL have as its value the IP address found in the IP-packets belonging to the IP-stream in question.In the case where this attribute is omitted, there SHALL
only be one source IP
address from which the file delivery session originates which is defined by the com-bination of destination IP
address, port and transmission session ID
given.

transmissionSessionlD A NM/TM 1 This is the Transmission Session Identifier (TSI) of the session at ALC/
LCT level hasFDT A NO/TM 0.. 1 If FDT is transmitted in the transport session de-livering the RMS
template, this attribute SHALL be set to "true".
Otherwise this attribute SHALL be set to "false".
The default value of this attribute is "true".If this element is set to "false", (1) the FEC parameters related to transport objects delivering SGDUs in the transport session SHALL be signaled using EXT_FTI[RFC 3926](2) the optional compression of SGDUs SHALL be signaled using EXT_CENC [RFC 39261.
Note that EXT_CENC
was originally defined in [RFC 3926] for signaling the encoding of the FDT, but is assigned to a different usage in this specification for the specific case of SGDU
delivery directly using ALC.

transmissionObjectlD A NM/TM 1 The Transport Object ID
of the RMS template. If 'hasFDT' is assigned with value "True" then the value of 'Trans-portObjectlD' SHALL
match the value of the TOI paired in the FDT
instance with the Content-Location having as its value the value of the ContentLocation attribute below.

contentLocation A NM/TM 0.. 1 The location of the RMS
template. It corresponds to the Content-Location attribute in the FDT.If and only if attribute 'hasFDT' is instantiated, SHALL this attribute be instantiated.

AlternativeURL E5 NO/TM 0.. 1 Declares the alternative URL for retrieving the RMS template, declared in the parent RM-STemplate element, via the interaction channel.
GlobalContentld E5 NO/TM 0.. 1 If a RMSTemplate is in-stantiated as a content then this element contains value that represents the related globalContentlD.

DescriptorEntry El NM/TM 1..N An entry in the Service Guide Delivery De-scriptor. Contains the following attribute: type-Contains the following elements : Group ingCriteri a,Transport,AlternativeA
ccessURL,ServiceGuide DeliveryUnit Omitted [1131 The RMS information according to the second embodiment of the presentinvention is defined in consideration of the case where multiple service providers are sharing a single network. In the case where multiple service providers are sharing the network, the RMS information can provide the rich media service guide templates of the in-dividual service providers.
[1141 Referring to Table 4, when multiple BSMs share the SGDD, this informationis provided by using the BSMSelector element which is a sub-element of a BSMList element. In an embodiment of the present invention, the BSMSelector element also contains the information on whether the RMS template exists.
[1151 That is, the RMS element is contained in the BSMSelector element and contains the RMSTemplate element.
[116] The RMSTemplate element contains the Criteria, Capabilities, Transport, Alter-nativeURL, and GlobalContentlD elements.
[117] The BSMSelector is an element to provide the information for identifying the service provider in BCAST. The BSMSelector element provides important criteria to dis-criminate between the service guides of the multiple service providers when the SGDD
is shared by them. For this reason, the RMSTemplate element is added as a sub-element of the BSMSelector to support the provider-specific service guide templates.
By inserting the RMS element into the SGDD, the terminal can prepare the RM-Sprocess before the receipt of the metadata delivered by the service guide fragment in advance, and thus display the service guide in the rich media format quickly.
[118] The Criteria element provides a filtering rule such that only the terminals fulfilling specific conditions to use the RMS template.
[119] The Criteria elementis not defined specifically such that the service provider can define various conditions required and contains the templateVersion and, at-tributeName, and attributeValue attributes. The templateVersion attribute allows the terminal to receive the RMS template which is newer than the one stored in the terminal based on the time. The attributeName and attributeValue attributes can be defined per service provider.
[120] The Capabilities element provides the information on the capability required for the terminal to display the RMS template. Since a problem may occur with the terminal which does not fulfill the requirements of the Capabilities element, such terminal does not receive the template.
[121] The Transport element contains the information required for the terminal 105 to receive the RMS template via the broadcast channel. The Transport element is identical with that in Table 3 according to the first embodiment of the present invention.
[122] The AlternativeURL element provides the information on the alternative URL for re-trieving the RMS template via one-to-one interaction channel.
[123] The GlobalContentld element provides identifier of the content fragment when the service provider wants to provide the RMS template as content.
[124] Although the RMS template is transported accordingto the file transport method of the conventional BCAST in the above method, it may be delayed for the terminal to display the service guide using the RMS template as compared to use the Transport element contained in the SGDD.
[125] The structure of RMS information according to a third embodiment of the present invention is described hereinafter. FIG. 7 and Table 5 describes the structure of the RMS information according to the third embodiment of the presentinvention. The third embodiment is identical with the second embodiment in terms of supporting the SGDD
share of multiple BSMs except that the RMS element is a higher element containing the BSM information.
[126] Table 5 [Table 5]
[Table ]

Name Type Categor Cardinali Description y ty RMS El NO/TO 0..1 Signals the existence of Rich Media Solution template documents for the presentation of SG. If the terminal has delays in rendering the Rich Media Solution template, it may render the SG using its native rendering engine during the meantime. Contains the following elements: B SMSelectorRMSTe mplate BSMSelector E2 NM/TM 0.. 1 Specifies the BSM associated with the RMSTemplate by referencing a BSMSelector structure declared above.
Note that if this element is not instantiated, then any terminal that fetches this given SGDD SHALL
consider that the related RMSTemplate applies to its affiliated BSM. Contains the following attribute: idRef idRef A NM/TM 1 Reference to the identifier of the BSMSelector declared within the 'BSMList' above.

RMSTemplate E2 NO/TM 1..N Access details for retrieving Rich Media Solution template document. Contains the following at-tributes:templateVersionConta ins the following elements:CriteriaCapabilitiesT
ransportAltemativeURLGloba lContentld templateVersion A NO/TM 1 The version of the template. If the template version is newer than the one stored on the terminal then the terminal is applicable to receive the RMS
template.

Criteria E3 NO/TO O..N Declares the criteria required for receiving this template Contains the following attributes: at-tributeNameattribute Value attributeName A NO/NM 1 Criteria attribute name attributeValue A NO/TM 1 Criteriaattribute value Capabilities E3 NO/TM 1 Contains the following at-tributes: typeversionContains the following element: MIMETypeComplexit y type A NM/TM 1 Indicate the type of RM
content. Allowed values are:O
according to MIME type 1 W3C SVG Tiny2 OMA
RME3 MPEG LASeR4 3GPP
DIMS5 127 reserved for future use 128 255 reserved for pro-prietary use version A NM/TM 1 Defines the version as-sociated with the type MIMEType E4 NM/TM O..N MIME Media type of the rich media content. Contains the following attribute:
Codec codec A NM/TM 0.. 1 The codec parameters for the associated MIME Media type. If the file's MIME type definition specifies mandatory parameters, these MUST be included in this string. Optional pa-rameters containing in-formation that can be used to determine as to whether the terminal can make use of the file SHOULD be included in the string. One example of the parameters defined for video/
richmedia+xml is defined in Section 7 of 3GPP DIMS
specification.

Complexity E4 NM/TM 1 The complexity the rich media engine has to deal with. Contains the following attributes: profilesceneUpdat eCommandsscreenOrientati onContains the following elements:AnimationsEmbed dedMediaElementsDOMnod esScriptingCompression profile A NO/TO 0..1 Defines the profile/level of the RMSExample: For DIMS: mobile profile level 10For LASeR: 2006 amdl Note: it is conditional on the 'type' and 'version' at-tributes sceneUpdateCommands A NO/TM 1 Indicates whether the rich media content requires the processing of scene update commands to render the content.Default: False screenOrientation A NO/TM 1 Indicates whether the rich media scene requires scene orientation management Default: False Animations E4 NO/TM 1 The number of animations in the rich media scene.
Contains the following at-tributes: Maximum maximum A NM/TM 0.. 1 The maximum number of animations in the rich media scene EmbeddedMediaEleme E4 NM/TM 1 The number of embedded nts media elements (i.e. video and audio) in the rich media scene. Contains the following attributes: embeddedVideoe mbeddedAudio embeddedVideo A NM/TM 0..1 The number of concurrently running embedded video elements in the rich media scene.

embeddedAudio A NM/TM 0..1 The number of concurrently running embedded audio elements in the rich media scene.

DOMNodes E4 NO/TM 1 The number of DOM nodes required to render the rich media contentContains the following attributes:
Maximum maximum A NM/TM 1 The maximum number of active DOM nodes in a rich media scene at any given time.

Scripting E4 NO/TM 1 Indicates whether the rich media scene requires the processing of scripts (for e.g.
ECMAScript) to render the content.Contain the following attribute:
MIMEType MIMEType A NM/TM 0.. 1 Indicates the MIMEtype of the script used within the Rich Media content.If not present is indicates that the content does not contain any script.

Compression E6 NO/TM 1 Indicates whether the delivered rich media scene is compressed/encoded or not.
Contains the following attribute : contentEncoding content Encoding A NM/TM 1 Scheme used to encode/
compress the rich media contentO- None 1- XML2-Gzip3- LASeR4- BiM5- 127 reserved for future use 128 -255 reserved for proprietary useNote: default value is 0.

Transport E3 NM/TM 0.. 1 The pointer to the transport session delivering the RMS
template.Contains the following at-tributes: ipAddres sportsrcIpAd dresstransmissionSessionlDha sFDTtransmissionObjectlDco ntentLocation ipAddress A NM/TM 1 Destination IP address of the target delivery session Port A NM/TM 1 Destination port of target delivery session srcIpAddress A NM/TM 0.. 1 Source IP address of the delivery sessionIn the case where source specific multicast scheme is applied in the transmission, then the 'srcI
pAddress' attribute SHALL
have asits value the IP address found in the IP-packets belonging to the IP-stream in question.In the case where this attribute is omitted, there SHALL only be one source IP
address from which the file delivery session originates which is defined by the com-bination of destination IP
address, port and transmission session ID given.

transmissionSessionlD A NM/TM 1 This is the Transmission Session Identifier (TSI) of the session at ALC/LCT level hasFDT A NO/TM 0.. 1 If FDT is transmitted in the transport session delivering the RMS template, this attribute SHALL be set to "true". Otherwise this attribute SHALL be set to "false". The default value of this attribute is "true".If this element is set to "false", (1) the FEC pa-rameters related to transport objects delivering SGDUs in the transport session SHALL
be signaled using EXT_FTI[RFC 3926] (2) the optional compression of SGDUs SHALL be signaled using EXT_CENC [RFC
3926]. Note that EXT_CENC
was originally defined in [RFC
39261 for signaling the encoding of the FDT, but is assigned to a different usage in this specification for the specific case of SGDU
delivery directly using ALC.

transmissionObjectlD A NM/TM 1 The Transport Object ID of the RMS template. If 'hasFDT' is assigned with value 'True' then the value of 'Trans-portObjectID' SHALL match the value of the TOI paired in the FDT instance with the 'Content-Location' having as its value the value of the 'con-tentLocation' attribute below.

contentLocation A NM/TM 0.. 1 The location of the RMS
template. It corresponds to the Content-Location attribute in the FDT.If and only if attribute 'hasFDT' is instantiated, SHALL this attribute be in-stantiated.

AlternativeURL E3 NO/TM 0.. 1 Declares the alternative URL
for retrieving the RMS
template, declared in the parent RMSTemplate' element, via the interaction channel.

GlobalContentld E3 NO/TM 0.. 1 If a RMSTemplate is in-stantiated as a content then this element contains value that represents the related globalContentlD.
[127] Descriptions are made of the elements that are newly introduced in the RMS in-formation of Table 5 included and described in the RMS information of Table 4.
[128] The BSMSelector element contains an idRef attribute containing the service provider value to designate a BSM value representing the service provider. It is determined whether to apply the RMStemplate depending on the value of the idRdf attribute.
[129] An RMS transmissionmethod according to an embodiment of the present invention is described hereinafter.
[130] FIG. 4 is a flowchart illustrating a rich media-enabled service guide provisioning method according to an embodiment of the present invention.
[131] Referring to FIG.4, the BSDA 103 creates a Service Guide (SG) with the required service guide fragments in step S401.
[132] Once the Service Guide has been created, the BSDA 103 creates an RMS
template for the terminal 105 to display the Service Guide in step S403. At step S403, the BSDA 130 selects an RMS technology to be used for creating the RMS template among the W3C SVT Tiny, OMA RME, MPEG LASeR, and 3GPP DIMS.
[133] In the case where there is no previously created template, the BSDA 103 can create a new template and, if any, selects one of the previously created templates.
[134] Once a template has been selected or created, the BSDA 103 creates an SGDD
containing the RMS information in step S405. The RMS information can be provided in one of the formats described in Tables 3, 4, and 5. That is, the BSDA 103 generates the SGDD containing the information about the service guide fragments required for forming the service guide as described in Table 2 along with the RMS
information formatted as shown in Tables 3, 4, or 5.
[135] Finally, the BSDA 103 broadcasts the SGDD, Service Guide, and RMS
template such that the terminal 105 receives them in step S407.
[136] In the case where the RMS template is transmitted via an interaction channel, the BSDA 103 adds the RMS information notifying of the transmission of the RMS
template via the interaction channel to the SGDD at step S405, and broadcasts the service guide fragment and transmits the RMStemplate via the interaction channel at step S407.
[137] Aprocedure for the terminal to receive the service guide with the RMS
template in the rich media-enabled service guide provision method according to an embodiment of the present invention is described hereinafter.
[138] FIG. 5 is a flowchart illustrating a procedure for handling a received rich media-enabled-service guide in the rich media-enabled service guide provision method according to an embodiment of the present invention.

[1391 Referring to FIG. 5, the terminal 105 first receives the SGDDs transmitted by the BSDA 103 in step S501. At this time, the terminal 105 access an SG
Announcement Channel to receive the SGDDs as shown in FIG. 3. As shown in FIG. 3, at least one SGDD 301 is transmitted on the SG Announcement Channel 300, and the terminal receives the SGDDs destined to itself.
[1401 Sequentially, the terminal 105 receives the SGDUs destined to itself by referencing the SGDDs in step S503 and extracts the service guide fragment from the received SGDU in step S505. The service guide fragment can be metadata.
[1411 Next, the terminal 105 analyzes the received SGDDs to detect the RMS
information (formatted as shown in Table 3, 4, or 5) from the SGDDs in step S507. If the RMS in-formation has been detected at step S507, the terminal 105 determines whether the RMS template contained in the RMS information is supportable in step S509.
Whether the RMS template is supportable or not can be determined based on the RMS in-formation described in Tables 3, 4, and 5. For instance, the RMS information is formatted as shown in Table 3, the terminal 105 references the Type attribute and the Version attribute contained in the RMSTemplate element to determine whether it supports the RMS template.
[1421 In the case where the RMS information is formatted as shown in Table 4, the terminal 105 references the Criteria elementand the Capability element contained in the RMSTemplate element to determine whether the terminal 105 supports the RMS
template.
[1431 If it has been determined that the terminal supports the RMS template at step S590, the terminal receives the RMS template in step S511. Here, the RMS information includes the information on the transmission. Transmission information includes the Transport element (containing the IpAddress attribute, the Port attritute, the srcl-pAddress attribute, the transmissionSessionlD attribute, the hasFDT attribute, the con-tentLocation attribute, and the transmissionObjectlD attribute), and AlternativeURL
element. The terminal 105 receives the RMS template with reference to these elements and attributes.
[1441 Once the RMStemplate has been received, the terminal 105 displays the service guide (service guide fragments) extracted from the SGDUs at step S505 using the RMS template in step S513. In this manner, the terminal 105 can outputs the services in the environment intended by the service provider.
[1451 If no RMS informationhas been detected at step S507, or if it has been determined that the RMS template is not supportable at step S509, the terminal 105 renders the service guide using its native rendering engine in step S515.
[1461 The structure and operations of the terminal supporting the rich media-enabled service guide provision method according to an embodiment of the present invention is described hereinafter.
[147] FIG.6 is a block diagram illustrating a configuration of the terminal according to an embodiment of the present invention.
[148] As shown in FIG.6, the terminal 105 includes a reception module 601, an RMS
engine 603, and a BCAST client 605.
[149] The reception module 601 receives the SGDDs, acquires the SGDUs with reference to the SGDDs, and extracts the service guide fragments from the SGDUs. The reception module 601 also acquires the RMS template with reference to the RMS
in-formationcontained in the SGDDs.
[150] The RMSengine 603 interprets the RMS template and outputs the result to the BCAST client 605.
[151] The BCAST client 605 interprets the service guide fragments and output the service guide using the RMS template provided by the RMS engine 603. The service guide can be provided in the form of metadata.
[152] Detailed description is made of the RMS engine 603 for rendering the service guide.
In an embodiment of the present invention, the description is made under the as-sumption that the RMS engine 603 is the Lightweight Applicationfor Scene Repre-sentation (LASeR) engine. However, the RMS engine 603 can be implemented with other rich media rending engine. In case that the RMS engine 603 (or system) is sub-stituted by other type of rending engine (or other system), the related terms can be changed in consistency with the substituted technology, and this is obvious to those skilled in the art.
[153] In an embodiment of the present invention, the RMS engine 603 decodes the receive RMS template, i.e. LASeR template. In case that the LASeR template is delivered in the form of raw service content without compression, the decoding process is omitted.
[154] The RMSengine 603 checks the LASeR commands in the decoded LASeR
template and executes the commands.
[155] The LASeRcommands express the change of scene in declarative manner and include 'NewScene' element (command) to instruct the drawing of a new scene, 'Insert' element (command) to instruct the insertion of an attribute, and 'Delete' element (command) to instruct the deletion of an attribute.
[156] The components of a scene, based on the LASeR, include the elements and attributes representing the properties of the elements that are expressing the media and graphic objects constituting a scene in the declarative manner, events, and scripts.
[157] The LASeRtemplate includes the information about the links and references for displaying the service guide using the information contained in the service guide fragments acquired from the SGDUs. The RMS engine 603 interprets the link and reference information of the LASeRtemplate and checks the information contained in the service guide fragments based on the interpreted information.
[158] The LASeRengine 603 renders the LASeR content in the format appropriate for the terminal using the information contained in the service guide fragments. The LASeRengine 603 outputs the rendered service guide through the user interface means supporting video and audio.
[159] The informationprovided by the service guide fragments is the metadata for outputting the service guide. A description is made of the service guide metadata (hereinafter called SG metadata).
[160] Table 6 shows an exemplary SG metadata according to an embodiment of the present invention.
[161] Table 6 [Table 6]
[Table ]

...<Content id="urn:bbc:2891" version="5">
<Name>Spendaholics </Name><Genre>NON-FICTION</Genre></Content>... <Purc haseTable><Purchase ... ><ServiceBundleRef IDRef=" ServiceBundleid_A"/>... <MediaTitle><Mpeg7:Titlelmage><mpeg7:MediaU
ri>EasterTitle.jpg</
mpeg7:MediaUri></Mpeg7:Titlelmage></MediaTitle> ... </Purchase></PurchaseTabl e>...

[162] Table 6 is a structured XML data format expressing a SG metadata to be displayedon the LASeR template.
[163] As aforementioned, the SG metadata is displayed to the user through the RMS
template. Table 7 shows an RMS template according to an embodiment of the present invention.
[164] Table 7 [Table 7]
[Table ]

...<text id="Genre"...><tref xlink:href="ESG.xml# xmlns(ESGMain/ESG/Content [@id=' urn:bbc:2891']/Genre/textO)"/> </text><image id=" ServiceBundleImage"xlink:href="ESG.xml#
xmins(ESGMain/ESG/PurchaseTable/Purchase/MediaTitle/ mpeg7:Titlelmage/
mpeg7:MediaUri/textQ)" .../>...

[165] Table 7 shows the information provided by the service guide fragments, i.e. the SG
metadata of Table 6, expressed in the LASeR template as the RMS template.
[166] Here, the LASeRtemplate includes a text identified by an id having the attribute value of "genre" and an image identified and id having the attribute value "Service-Bundlelmage".
[167] In order to indicate the actual data and image file of the "text"
element and the image file of "image" element, the file name or the file location can be used as shown in Table 7. For instance, it can be used to express the file name (such as "a.jpg") or the file location (such as ".../.../.../a.jpg"). That is, in order to present the information provided by the acquired service guide fragments by means of the RMS engine 603, e.g. LASeRengine, the file name, file path, and location are provided for the RMS
engine 603 to access the files.
[168] In Table 7, the LASeR engine references the external data using "tref"
attribute and presents the reference data in the form of 'text' data of the LASeR service content.
[169] The data such as 'image', 'video', and 'audio' can be presented as the component elements of the LASeR service content using the 'xlink:href' attribute providing a link to external data, e.g. 'xlink:href=' ESG.xml#xmins(ESGMain/ESG/PurchaseTable/Purchase/MediaTitle/mpeg7:Titlelma ge/ mpeg7:MediaUri/textO)'.
[170] In this case, the text data of the 'text' of which 'id' attribute has the attribute value 'Genre' is presented as the information 'NON_FICTION' provided by the service guide fragments when the LASeR template of Table 7 is displayed on the screen. Also, the actual image file of the 'image' of which 'id' attribute has the attribute value Service-Bundlelmage' is presented as the information 'EasterTitle.jpg' provided by the service guide fragments.
[171] Table 8 shows an RMS template according to another embodiment of the present invention.
[172] Table 8 [Table 8]
[Table ]

...<xsl:template match="PurchaseTable"> ... <xsl:if test="@ id =
../../ESGMainBCAST/Content[@id='BBCThree_dOe1052'] "> <svg:text ... >
<xsl:value-of select="./Genre"/> </svg:text> </xsl:if>... <svg:image ...><xsl:attribute name="href"> <xsl:value-of select= "ESG.xml#
xmins(ESGMain/ESG/PurchaseTable/Purchase/MediaTitle/ mpeg7:Titlelmage/
mpeg7:MediaUri/textQ)" /> </xsl: attribute> </svg:image >...</xsl:template>...

[173] Table 8 shows the information provided by the service guide fragments expressed in the W3C SVG template and the result is identical with that of Table 7.
[174] In this case, the RMS engine 603 references the external data using various ex-pressions and referencing methods such as Xpath, Xpointer, and eXtensible Stylesheet Language Transformations (XSLT).
[175] Although the description is directed to the method for the RMS engine to reference the SG metadata, the present invention is not limited thereto but can be implemented using various referencing methods.
[176] Although the description on the terminal is made with reference to the RMS in-formation formatted as shown in Table 3, the mobile terminal can be configured to support the RMS information formats of Tables 4 and 5 as well as Table 3.
[177] As described above, the rich media-enabled service guide provision method and system of the present invention is capable of providing the rich media-enabled service guide to the terminals having different capabilities in a service provider's intended format by using RMS templates.
[178] Also, the rich media-enabled service guide provision method and system of the present invention is capable of distributing the rich media-enabled service guide without compromising backward compatibility.
[179] Although embodiments of the present invention have been described in detail hereinabove, it should be clearly understood that many variations and/or modifications of the basic inventive concepts herein taught which may appear to those skilled in the present art will still fall within the spirit and scope of the present invention, as defined in the appended claims.

Claims (14)

  1. [Claim 1] A method of creating a rich media-enabled service guide for a digital broadcast service, comprising the steps of:
    collecting content information of one or more broadcast services to be delivered to a user device;
    generating a service guide delivery descriptor (SGDD) based on the collected content information, the SGDD including rich media content information, the rich media content information including capability data of the user device; and broadcasting the SGDD to the user device.
  2. [Claim 2] The method of claim 1, wherein the capability data of the user device is provided in a rich media solution (RMS) template descriptor.
  3. [Claim 3] The method of claim 2, wherein the RMS template descriptor includes a transport pointer to an RMS template for rendering the rich media-enabled service guide on the user device.
  4. [Claim 4] The method of claim 3, wherein the transport pointer includes at least one of a destination address, port number, source address, and a transmission session identifier.
  5. [Claim 5] The method of claim 1, wherein the rich media content information further includes a broadcast subscription manager (BSM) identifierthat identifies a BSM affiliated with an RMS template for rendering the rich media-enabled service guide.
  6. [Claim 6] A method of rendering a rich media-enabled service guide for a digital broadcast service on a user device, comprising the steps of:
    receiving a service guide delivery descriptor (SGDD) that is based on content information of one or more broadcast services to be delivered to the user device, the SGDD including rich media content information, the rich media content information including capability data of the user device;
    determining compatibility of the user device with the rich media content information and rendering the rich media-enabled guide on the user device based on the SGDD if the user device is determined to be compatible with the rich media content information.
  7. [Claim 7] The method of claim 6, wherein the capability data of the user device is provided in a rich media solution (RMS) template descriptor.
  8. [Claim 8] The method of claim 7, wherein the RMS template descriptor includes a transport pointer to an RMS template for rendering the rich media-enabled service guide on the user device.
  9. [Claim 9] The method of claim 8, wherein the transport pointer includes at least one of a destination address, port number, source address, and a transmission session identifier.
  10. [Claim 10] The method of claim 6, wherein the rich media content information further includes a broadcast subscription manager (BSM) identifierthat identifies a BSM affiliated with an RMS template for rendering the rich media-enabled service guide.
  11. [Claim 11] A data structure embodied on a processor readable medium for a rich media-enabled service guide in a digital broadcast service, the data structure comprising:
    a service guide delivery descriptor (SGDD) that is based on content in-formation of one or more broadcast services to be delivered to a user device;
    a rich media solution (RMS) fragment containing rich media content information of the rich media-enabled service guide; and an RMS template descriptor including capability data of the user device for determining compatibility of the user device with the rich media content information.
  12. [Claim 12] The data structure of claim 11 further comprising a transport pointer to an RMS template for rendering the rich media-enabled service guide on the user device.
  13. [Claim 13] The data structure of claim 12, wherein the transport pointer includes at least one of a destination address, port number, source address, and a transmission session identifier.
  14. [Claim 14] The data structure of claim 11 further comprising a broadcast sub-scription manager (BSM) identifier that identifies a BSM affiliated with an RMS template for rendering the rich media-enabled service guide.
CA2748940A 2009-01-15 2010-01-15 Rich media-enabled service guide provision method and system for broadcast service Abandoned CA2748940A1 (en)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
KR20090003185 2009-01-15
KR10-2009-0003185 2009-01-15
KR1020090049958A KR20100084104A (en) 2009-01-15 2009-06-05 A method for offering service guide using rich media in a digital broadcast system and a system thereof
KR10-2009-0049958 2009-06-05
KR10-2009-0052574 2009-06-12
KR1020090052574A KR20100084105A (en) 2009-01-15 2009-06-12 A method for offering service guide using rich media in a digital broadcast system and a system thereof
KR10-2009-0056688 2009-06-24
KR1020090056688A KR20100084107A (en) 2009-01-15 2009-06-24 A method for offering service guide using rich media in a digital broadcast system and a system thereof
PCT/KR2010/000260 WO2010082782A2 (en) 2009-01-15 2010-01-15 Rich media-enabled service guide provision method and system for broadcast service

Publications (1)

Publication Number Publication Date
CA2748940A1 true CA2748940A1 (en) 2010-07-22

Family

ID=42643638

Family Applications (1)

Application Number Title Priority Date Filing Date
CA2748940A Abandoned CA2748940A1 (en) 2009-01-15 2010-01-15 Rich media-enabled service guide provision method and system for broadcast service

Country Status (6)

Country Link
JP (1) JP2012515496A (en)
KR (4) KR20100084104A (en)
CN (1) CN102356639A (en)
CA (1) CA2748940A1 (en)
RU (1) RU2011129329A (en)
TW (1) TW201108653A (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016521500A (en) * 2013-04-16 2016-07-21 エルジー エレクトロニクス インコーポレイティド Broadcast transmission apparatus, broadcast reception apparatus, operation method of broadcast transmission apparatus, and operation method of broadcast reception apparatus
JP6151152B2 (en) * 2013-10-11 2017-06-21 ソニー株式会社 Receiving device, receiving method, transmitting device, and transmitting method
KR101865299B1 (en) 2014-04-27 2018-06-07 엘지전자 주식회사 Broadcast transmitting apparatus, method for operating broadcast transmitting apparatus, broadcast receiving apparatus, and method for operating broadcast receiving apparatus
CA2978534C (en) * 2015-03-27 2019-05-21 Sharp Kabushiki Kaisha Systems and methods for content information message exchange
US11140521B2 (en) * 2018-11-26 2021-10-05 Samsung Electronics Co., Ltd. Methods and user equipment for enabling reception of multimedia broadcast multicast services (MBMS)
JP7328039B2 (en) * 2019-07-11 2023-08-16 日本放送協会 transmitter and receiver

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4036307B2 (en) * 1997-12-09 2008-01-23 松下電器産業株式会社 Electronic program guide
KR101270275B1 (en) * 2005-08-17 2013-05-31 삼성전자주식회사 Apparatus and method for providing notification message in broadcasting system
KR101230181B1 (en) * 2005-10-08 2013-02-06 연세대학교 산학협력단 Methdo and apparatus for transmitting/receiving a service guide context in a mobile broadcasting system
KR101277195B1 (en) * 2005-11-07 2013-06-19 삼성전자주식회사 Methdo for transmitting/receiving a service guide in a mobile broadcasting system and constructing service guide context

Also Published As

Publication number Publication date
KR20110117159A (en) 2011-10-26
CN102356639A (en) 2012-02-15
KR20100084104A (en) 2010-07-23
TW201108653A (en) 2011-03-01
KR20100084105A (en) 2010-07-23
KR20100084107A (en) 2010-07-23
RU2011129329A (en) 2013-01-20
JP2012515496A (en) 2012-07-05

Similar Documents

Publication Publication Date Title
US20100180310A1 (en) Rich media-enabled service guide provision method and system for broadcast service
US20100037258A1 (en) Mobile broadcasting system and method for enhancing mobile broadcasting services with rich media including an enhanced service guide
KR20180088383A (en) Receiving device, transmitting device, and data processing method
CA2977718C (en) Service signaling extensions
CN109964486B (en) Broadcast identifier signaling
US8555319B2 (en) Service guide transmission/reception method and apparatus for broadcast service
US20170238061A1 (en) Method for decoding
CA2748940A1 (en) Rich media-enabled service guide provision method and system for broadcast service
US10389461B2 (en) Method for decoding a service guide
CA3081282C (en) Service list
US20170118503A1 (en) Methods for xml representation of device capabilities
US20170250771A1 (en) Syntax and semantics for device capabilities
KR20180104679A (en) Display of components in service announcements
US20170085921A1 (en) Method for decoding a service guide

Legal Events

Date Code Title Description
FZDE Discontinued

Effective date: 20150115