RICH MEDIA-ENABLED SERVICE GUIDE PROVISION METHOD AND SYSTEM FOR BROADCAST SERVICE

PRIORITY

This application claims priority to an application entitled “RICH MEDIA-ENABLED SERVICE GUIDE PROVISION METHOD AND SYSTEM FOR BROADCAST SERVICE” filed in the Korean Intellectual Property Office on Jan. 15, 2009, Jun. 5, 2009, Jun. 12, 2009 and Jun. 24, 2009 and assigned Serial No. 10-2009-0003185, 10-2009-0049958, 10-2009-0052574 and 10-2009-0056688, respectively, the contents of each of which are hereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

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.

2. Description of the Related Art

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.

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.

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 BCAST) is an open global specification designed to support mobile broadcast technologies. The OMA BCAST deals 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.

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 environment.

The conventional mobile broadcast systems provide service guides configured to be processed by only the terminals designed to receive the corresponding broadcast system.

In such mobile broadcast systems, the service guide is provided with the content-related information but 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 Group Lightweight Application Scene Representation (MPEG-LASeR), 3^rdGeneration 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 develop a method for providing the rich media-enabled service guide adapted to the terminal capability.

SUMMARY OF THE INVENTION

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.

Also, the present invention 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 compromising backward compatibility by using a rich media-based service guide template.

In accordance with an embodiment of the present invention, 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.

In accordance with another embodiment of the present invention, a rich 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.

In accordance with still another embodiment of the present invention, a rich media-enabled service guide provisioning system for a digital broadcast service includes a broadcast distribution/adaptation unit which transports a service guide delivery descriptor 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 RMS template 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.

BRIEF DESCRIPTION OF THE DRAWINGS

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 accompanying drawings, in which:

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;

FIG. 2 is a diagram illustrating a structure of a Service Guide Data Model for use in the OMA BCAST system;

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;

FIG. 4 is a flowchart illustrating a rich media-enabled service guide provisioning method according to an embodiment of the present invention;

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;

FIG. 6 is a block diagram illustrating a configuration of the terminal according to an embodiment of the present invention; and

FIG. 7 is a block diagram illustrating a Service Guide Data Model based on a rich media.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Embodiments of the present invention are described with reference to the accompanying 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.

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.

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.

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 BCAST technology as a representative mobile broadcast standard, the present invention is not limited thereto.

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.

As shown in FIG. 1, the logical architecture of the BCAST system includes a Content Creation (CC) 101, a BCAST Service Application 102, a BCAST Service Distribution/Adaptation 103, a BCAST Subscription Management 104, a Terminal 105, a BDS Service Distribution 111, a Broadcast Distribution System 112, and an Interworking Network 113.

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.

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 zo 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.

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.

Particularly in an embodiment of the present invention, the BCAST Service Distribution/Adaptation 103 creates a Rich Media Solution (RMS) template and transmits RMS template information with the RMS template to the terminal 105.

The BCAST Subscription Management 104 manages, via hardware and/or software, service provisioning such as subscription and charging-related functions for BCAST service users, information provisioning used for BCAST services, and mobile terminals that receive the BCAST services.

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 present invention, 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.

The BDS Service Distribution 111 delivers mobile broadcast services to a plurality of terminals through mutual communication with the Broadcast Distribution System 112 and the Interaction Network 113.

The Broadcast Distribution System 112 delivers mobile broadcast services over a broadcast channel, and may include, for example, Multimedia Broadcast Multicast Service (MBMS) by 3rd Generation Project Partnership (3GPP), Broadcast Multicast Service (BCMCS) by 3rd Generation 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 interaction channel, and may include, for example, a cellular network and the like.

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.

BCAST-1121 in FIG. 1 is a transmission path for content and content attributes, and BCAST-2122 is a transmission path for a content-protected or a content-unprotected BCAST service, attributes of the BCAST service, and content attributes.

BCAST-3123 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-4124 is a transmission path for a notification message, attributes used for a service guide, and a key used for content protection and service protection.

BCAST-5125 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 BCAST service protection, and all data and signaling transmitted through a broadcast channel.

BCAST-6126 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.

BCAST-7127 is a transmission path for service provisioning, subscription information, 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

BCAST-8128 is a transmission path through which user data for a BCAST service is interacted.

BDS-1129 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.

BDS-2130 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.

X-1131 is a reference point between the BDS Service Distribution 111 and the Broadcast Distribution System 112. X-2132 is a reference point between the BDS Service Distribution 111 and the Interaction Network 113. X-3133 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-5135 is a reference point between the BDS Service Distribution 111 and the terminal 105 over an interaction channel. X-6136 is a reference point between the Interaction Network 113 and the terminal 105.

A description is now made of a service guide data model for providing the service guide according to an embodiment of the present invention.

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.

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 210 for providing subscription and purchase information, a Core Group 220 as a core part of the service guide, and an Access Group 230 for providing access information to control access to services and contents.

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.

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.

The aforementioned components are referred to as fragments and are the basic units constituting the service guide.

Hereinafter, descriptions are made of the individual fragments of the service guide data model.

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 containing the 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.

The Service Fragment 221, which is an upper aggregate of the content included in the broadcast service, and includes information on service content, genre, service location and so forth.

The Schedule Fragment 222 defines the timeframes in which associated content items are available for streaming, downloading, and/or rendering.

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.

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.

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.

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.

The Purchase Data fragment 212 includes detailed purchase and subscription information such as price information and promotion information for the service or content bundle.

The Purchase Channel fragment 213 provides access information for a subscription or purchase.

The Preview Data fragment 241 can be used to provide preview information for a service, schedule, and content. The Interactivity Data fragment 251 can be used to provide an interactive service according to the service, schedule, and content in the middle of broadcasting.

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.

Although not described, the fragments constituting the service guide can include element and attribute values for fulfilling their purposes.

A message schema table according to an embodiment of the present invention is described hereinafter. Table 1 shows an exemplary schema table for use in an embodiment of the present invention.

TABLE 1

Name
Type
Category
Cardinality
Description
Data Type

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.

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 E1, 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 E1 means the attribute of element E1.

The category field is used to indicate whether the element/attribute is mandatory or optional, and marked by M for mandatory element/attribute and O for optional element/attribute.

The cardinality field indicates the relationship between elements and has a value of “0”, “0 . . . 1”, “1”, “0 . . . 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 “0 . . . n” means that the element or attribute can have no value or n values.

The description field provides detailed description of the element or attribute. The data type field indicates the data type of the element or attribute.

FIG. 3 is a block diagram illustrating a relationship between SGDD and SGDU in a Service Guide Data Model of FIG. 2.

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 information related to all the fragments containing service information. Particularly in an embodiment of the present invention, the SGDD 301 includes the information on an RMS template. The description on the information of the RMS template is made later in more detail.

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.

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.

TABLE 2

Name
Type
Category
Cardinality
Description
Data Type

ServiceGuideDeliveryDescriptor
E

The Service Guide

Delivery Descriptor

Contains the

following attributes:

id

version

Contains the

following elements:

NotificationReception

BSMList

DescriptorEntry

Id
A
NM/TM
0 . . . 1
Unique identifier of
anyURI

The SGDD within one

specific SG

Version
A
NM/TM
0 . . . 1
Version of SGDD.
unsignedInt

The newer version

overrides the older

version as soon as it

is received.

NotificationReception
E1
NM/TM
0 . . . 1
Reception

information for

general Notification

Messages.

In the case of

delivery over

Broadcast channel,

IPBroadcastDelivery

specifies the address

information for

receiving Notification

Messages.

In the case of

delivery over

Interaction channel,

RequestURL specify

address information

for subscribing

notification, PollURL

specify address

information 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.

If this element is

present, at least one

of the attributes

“IPBroadcastDelivery”,

“RequestURL”, or

“PollURL” SHALL be

present.

Contains the

following elements:

IPBroadcastDelivery

RequestURL

PollURL

TimeGroupingCriteria
E3
NM/TM
0 . . . 1
Specifies the period

of time this

DescriptorEntry

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 attributes:

startTime

endTime

A fragment matches

the

TimeGroupingCriteria

if it describes

information 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/TM
0 . . . 1
Provides IP multicast

address and port

number for reception

of Notification

Messages over the

broadcast channel.

Contains the

following attributes:

port

address

startTime
A
NM/TM
1
Start of the time
unsignedInt

period of

TimeGroupingCriteria.

This field contains

the 32 bits integer

part of an NTP time

stamp.

endTime
A
NM/TM
1
End of the time
unsignedInt

period of

TimeGroupingCriteria.

This field contains

the 32 bits integer

part of an NTP time

stamp.

GenreGroupingCriteria
E3
NM/TM
0 . . . 1
Specifies the
string

classification of the

services/content

associated 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 string

The 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 attributes:

type

href

Port
A
NM/TM
1
General Notification
unsignedInt

Message delivery

UDP destination port

number; delivery over

Broadcast Channel.

Address
A
NM/TM
1
General Notification
String

Message delivery IP

multicast address;

delivery over

Broadcast Channel.

RequestURL
E2
NM/TM
0 . . . 1
URL through which
anyURI

the terminal can

subscribe to general

Notification

Messages; delivery

over Interaction

Channel.

PollURL
E2
NM/TM
0 . . . 1
URL through which
anyURI

the terminal can poll

general Notification

Messages over

Interaction Channel.

BSMList
E1
NM/TM
0 . . . 1
Declaration of the

BSM Selectors which

can be used in the

GroupingCriteria

sections defined

below.

Contains the

following element:

BSMSelector

BSMSelector
E2
NM/
1 . . . N
Specifies the BSM

TM

associated with the

fragments in this

Service Guide

Delivery Unit

Allows a terminal to

determine whether

the SGDUs in this

SGDD

DescriptorEntry

among the SGDUs

that are announced in

various

DescriptorEntries in

various SGDDs is

associated with the

terminals affiliated

BSM(s). The

terminals affiliated

BSM(s) are

represented within

terminal as

Management Objects

with identifier <X>/

BSMSelector/BSMFilter

Codeor as codes

on the Smartcard as

defined by [3GPP TS

22.022], [3GPP2

C.S0068-0], [3GPP

TS 31.102], [3GPP2

C.S0023-C], or

[3GPP2 C.S0065-0] . . .

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//BSM

FilterCode 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

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

instantiated attributes

under the

BMSFilterCode

matches 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 instantiated

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 attributes

under the

<X>/BSMSelector/BSM

FilterCode or codes

on the Smartcard, the

terminal can render,

interpret and handle

the fragments

according to

RoamingRules

associated with this

BSMSelector

(identified by the

attribute id). In the

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

RoamingRuleRequest

to address indicated

by attribute

“roamingRuleRequest

Address”.

In the case 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 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

RoamingRuleRequest

to address indicated

by attribute

“roamingRuleRequest

Address”.

Note:

RoamingRuleRequest

message and

associated roaming

methods are

specified in

[BCAST10-Services].

Contains the

following attributes:

id

roamingRuleRequest

Address

Contains the

following elements:

BSMFilterCode

Name

RoamingRule

Type
A
NO/
0 . . . 1
This attribute signals
string

TO

the level of this

Genre element.

The following values

are allowed:

“main”

“secondary”

“other”

Href
A
NO/
0 . . . 1
This attribute signals
anyURI

TO

the controlled

vocabulary 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

classification scheme

identified by the

classificationScheme

URI

urn:tva:metadata:cs:

ContentCS: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

classificationScheme

URI

urn:tva:metadata:cs:Intended

AudienceCS:

2005 as defined in

Annex A.11 of [TVA-

Metadata]. When the

IntendedAudienceCS

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> “:” <termID>

If this

attribute is

instantiated 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

classification 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 Classification

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

instantiated, the

Genre element

SHALL be a free

string.

BSMSelector
E3
NM/
0 . . . N
Specifies the BSM

TM

associated with the

fragments in this

Service Guide

Delivery Unit by

referencing a

BSMSelector

structure declared

above.

Contains the

following attribute:

idRef

idRef
A
NM/TM
1
Reference to the
anyURI

identifier of the

BSMSelector

declared within the

BSMList above.

ServiceCriteria
E3
NM/TM
0 . . . 1
Allows to group
anyURI

fragments by service.

The value of this field

is the fragment ID of

the Service fragment

related to that

service.

Transport
E2
NM/TM
0 . . . 1
The pointer to the

transport session

delivering the Service

Guide fragments

within Service Guide

Delivery Units

announced in this

DescriptorEntry.

Contains the

following attributes:

ipAddress,

port,

srcIpAddress,

transmissionSessionID,

hasFDT

Id
A
NM/TM
1
Identifier of the
anyURI

BSMSelector. This id

is unique within

network.

roamingRuleRequestAddress
A
NO/TM
0 . . . 1
Address to which the
anyURI

terminals can send

the

RoamingRuleRequests

to request

RoamingRules

associated with this

BSMSelector

(identified with the id

attribute).

BSMFilterCode
E3
NM/TM
0 . . . 1
The code that

specifies this

BSMSelector.

Contains the

following attributes:

type

serviceProviderCode

corporateCode

serviceProviderName

nonSmartCardCode

Contains the

following elements:

NetworkCode3GPP

NetworkCode3GPP2

Note: At most either

NetworkCode3GPP

or

NetworkCode3GPP2

SHALL be present.

Implementation in

XML Schema should

use <choice>.

ipAddress
A
NM/TM
1
Destination IP
String

address of the target

delivery session

Port
A
NM/TM
1
Destination port of
unsignedShort

target delivery

session

srcIpAddress
A
NM/TM
0 . . . 1
Source IP address of
string

the delivery session

In 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 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.

Type
A
NM/
1
The type of
unsignedByte

TM

bsmFilterCode.

1 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/CSIM

2 BSMCode (Non

Smart Card Code):

This is used if the

determination is

made based on the

country and operator

code in the terminal

Other values are

reserved.

transmissionSessionID
A
NM/TM
1
This is the
unsignedShort

Transmission

Session Identifier

(TSI) of the session

at ALC/LCT level

hasFDT
A
NO/TM
0 . . . 1
If FDT is transmitted
Boolean

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

parameters related to

transport objects

delivering 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

specification for the

specific case of

SGDU delivery

directly using ALC.

serviceProviderCode
A
NO/TM
0 . . . 1
Service Provider
unsignedByte

Code as specified by

[3GPP TS 22.022] or

[3GPP2 C.S0068-0].

Applicable only when

“type” == 1

corporateCode
A
NO/TM
0 . . . 1
Corporate Code as
unsignedByte

specified by [3GPP

TS 22.022] or

[3GPP2 C.S0068-0].

Applicable only when

“type” == 1

serviceProviderName
A
NO/TM
0 . . . 1
Service Provider
String

Name (SPN) as

specified by [3GPP

TS 31.102], [3GPP2

C.S0023-C], or

[3GPP2 C.S0065-0].

Applicable only when

“type” == 1

nonSmartCardCode
A
NO/TM
0 . . . 1
Value of
String

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 attributes:

mobileCountryCode

mobileNetworkCode

networkSubsetCode

networkSubsetCodeRange

Start

networkSubsetCodeRange

End

codeRangeStart

codeRangeEnd

AlternativeAccessURL
E2
NM/TM
0 . . . N
Declares the
anyURI

alternative URL for

retrieving the Service

Guide fragments,

declared in the parent

DescriptorEntry

element, via the

interaction channel.

In addition, fragments

not declared in the

parent

DescriptorEntry MAY

also be available.

Terminal MAY check

the availability of

undeclared fragments

by issuing an

unspecific Service

Guide request

against the

AlternativeAccessURL,

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/TM
0 . . . 1
Mobile Country Code
string of 3

(3 digits) as specified
digits

by [3GPP TS 22.022].

mobileNetworkCode
A
NO/TM
0 . . . 1
Mobile Network Code
string of 2-3

(2-3 digits) as
digits

specified by [3GPP

TS 23.003].

networkSubsetCode
A
NO/TM
0 . . . 1
Network Subset Code
string of 2

(2 digits) as
digits

specified by [3GPP

TS 22.022].

networkSubsetCodeRangeStart
A
NO/TM
0 . . . 1
Instead of providing
string of 2

an explicit code in
digits

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

networkSubsetCodeRange

End and

SHALL not

instantiate attribute

networkSubsetCode.

The terminal SHALL

interpret all the code

values between the

smallest and the

greatest code as

values to be

accepted.

ServiceGuideDeliveryUnit
E2
NM/TM
1 . . . N
A group of fragments.

Contains the

following attributes:

transportObjectID,

versionIDLength,

contentLocation,

validFrom,

validTo

Contains the

following element:

Fragment

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.

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.

The SGDD 301 transported on the SG Announcement Channel 300 includes the Description Entry 302. The Description Entry 302 contains the transport information about the SGDU 312 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”, “ServiceGuideDeliveryUnit”, “Transport”, and “AlternativeAccessURI”.

The transport-related channel information is provided by the “Transport” or “AlternativeAccessURI”, and the actual value of the corresponding channel is provided by “ServiceGuideDeliveryUnit”.

Also, the upper layer group information about 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 information.

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.

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.

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 received on 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.

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.

RMS is the acronym standing for “Rich Media Solution” which is defined in the OMA BCAST standard to comprehensively express the rich media technologies.

If the RMS is 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 compatibility. In order to solve the compatibility problem, the RMS template 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.

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 3a in addition to the information as shown in Table 2.

Table 3a describes the RMS information according to the first embodiment of the present invention.

TABLE 3a

Name
Type
Category
Cardinality
Description

RMS
E1
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:

ScreenSize

Contains the following attributes:

type

version

Type
A
NM/TM
1
The RMS used to create the Service

Guide template document. Allowed values

are:

0 - W3C SVG Tiny

1 - OMA RME

2 - MPEG LASeR

3 - 3GPP DIMS

4-127 reserved for future use

128-255 reserved for proprietary 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:

Transport

AlternativeURL

Contains the following attributes:

value

compression

Value
A
NM/TM
1
The minimum screen resolution required

for rendering the RMS template. Allowed

values are: (width * height)

0 - Applies to all screens

1 - 320 * 240

2 - 240 * 320

3 - 480 * 320

4 - 320 * 480

5 - 640 * 480

6 - 480 * 640

7 - 800 * 480

8 - 480 * 800

9-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 - Gzip

2 - BIM

3-127 reserved for future use

128-255 reserved for proprietary uses

Transport
E4
NM/TM
1
The pointer to the transport session

delivering the RMS template.

Contains the following attributes:

ipAddress

port

srclpAddress

transmissionSessionID

hasFDT

transmissionObjectID

contentLocation

ipAddress
A
NM/TM
1
Destination IP address of the target

delivery session

Port
A
NM/TM
1
Destination port of target delivery session

srclpAddress
A
NM/TM
0 . . . 1
Source IP address of the delivery session

In the case where source specific

multicast scheme is applied in the

transmission, then the ‘srclpAddress’

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.

transmissionSessionID
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 parameters related to

transport objects delivering SGDUs in the

transport session SHALL be signaled

using EXT_FTI[RFC 3926], and

(2) 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

specification for the specific case of

SGDU delivery directly using ALC.

transmissionObjectID
A
NMTM
1
The Transport Object ID of the RMS

template. If hasFDT is assigned with

value true, then the value of

transportObjectID 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

retrieving the RMS template, declared in

the parent RMSTemplate element, via the

interaction channel.

In Table 3a, the data type field as described with reference to Table 1 is omitted.

Referring to Table 3a, 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.

The RMS information includes the elements and attributes such as RMS, RMSTemplete, Type, Version, ScreenSize, Value, Compression, Transport, IpAddress, port, srcIPAddress, TransmissionSessionID, hasFDT, TransmissionObjectID, contentLocation, and AlternativeURL.

The RMS is a higher element used to indicate whether an RMS template for use to display the service guide exists.

The RMSTemplate is an element for indicating the at least one RMS technology available with the RMS template.

The Type is an attribute that indicates the RMS used to create the service guide template document.

The Version is an attribute that indicates the version of the RMS used to create the service guide template.

In Table 3a, the value “W3C” of the Type attribute includes the SVG, SVB Basic, SVG mobile, etc. that are derived from the Scalable Vector Graphics (SVG).

The ScreenSize is an element for providing the screen size to allow the terminals to correctly retrieve the RMS template applicable to the terminal.

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 3a, 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).

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.

The Transport is an element for indicating the pointer to the transport session delivering the RMS template.

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.

The srcIpAddress 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 multicasting.

The TransmissionSessionID is an attribute indicating the Transmission Session Identifier (TSI) of the session.

The hasFDT 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.

The TransmissionObjectID is an attribute indicating the Transport Object ID of the RMS template.

The AlternativeURL is an element for providing the information used when the RMS template is delivered via one-to-one interaction channel.

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.

In the second embodiment of the present invention, the SGDD includes the RMS information as shown in FIG. 7 and Table 3b in addition to the information as shown in Table 2. Table 3b describes the RMS information according to the second embodiment of the present invention. The RMS information represented by Table 3b is defined to support the case where multiple BCAST Subscription Managements (BSMs) share the SGDD.

TABLE 3b

Name
Type
Category
Cardinality
Description

ServiceGuideDeliveryDescriptor
E

The Service Guide

Delivery Descriptor

Contains the following

attributes:

id

version

Contains the following

elements:

NotificationReception

BSMList

DescriptorEntry

TerminalCapability

Id
A
NM/TM
0 . . . 1
Unique identifier of the

SGDD within one specific

SG

This 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

instantiated if the SGDD is

delivered over broadcast

channel

NotificationReception
E1
NO/TO
0 . . . 1
Reception information for

general Notification

Messages.

In the case of delivery

over Broadcast channel,

IPBroadcastDelivery

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 Notification

Message resource pointed

by this element provides

Notification Messages

carrying Service Guide

update, those SHALL

relate to the currently

bootstrapped 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:

IPBroadcastDelivery

PollURL

PollPeriod

IPBroadcastDelivery
E2
NM/TM
0 . . . 1
Provides IP multicast

address and port number

for reception of

Notification Messages over

the broadcast channel.

Contains the following

attributes:

port

address

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.

PollURL
E2
NM/TM
0 . . . 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

information is scoped to

one given URL.

PollPeriod
E2
NO/
0 . . . 1
While polling the

TM

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

Notification Messages

every “PollPeriod” value.

The unit of this attribute is

seconds.

BSMList
E1
NM/TM
0 . . . 1
Declaration of the BSM

Selectors which can be

used in the

GroupingCriteria sections

defined below.

Contains the following

element:

BSMSelector

BSMSelector
E2
NM/
1 . . . N
Specifies the BSM

TM

associated 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

DescriptorEntries in

various SGDD's - is

associated with the

terminal's affiliated

BSM(s). The terminal's

affiliated BSM(s) are

represented within

terminal as Management

Objects with identifier

<X>BSMSelector/BSMFilter

Code or as codes on the

Smartcard as defined by

[3GPP TS 22.022],

[3GPP2 C.S0068-0],

[3GPP TS 31.102],

[3GPP2 C.S0023-C], or

[3GPP2 C.S0065-0] . . .

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/BSM

FilterCode

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

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

instantiated

attributes under the

BMSFilterCode

matches a subset

of the instantiated

attributes of

<X>/BSMSelector/

BSMFilterCode or

matches a subset

of the codes on the

SmartCard.

However, when the

instantiated

BSMFilterCode

represents a

superset of

attributes of the

<X>/BSMSelector/

BSMFilterCode or a

superset of the

codes on the

Smartcard, it is not

considered a

match, because not

all instantiated

attributes under the

BSMFilterCode

matches to

instantiated

attributes of

<X>/BSMSelector/

BSMFilterCode or

codes on the

Smartcard. If the

BSMFilterCode

present in this

element does not

match to any of the

<X>/BSMSelector/

BSMFilterCode

entries within the

terminal, i.e. not all

of the instantiated

attributes of

BSMFilterCode

have matching

instantiated

attributes under the

<X>/BSMSelector/

BSMFilterCode or

codes on the

Smartcard, the

terminal can

render, interpret

and handle the

fragments

according to

RoamingRules

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

RoamingRuleRequest

to address

indicated by

attribute

roamingRuleRequest

Address.

In the case where the

terminal has no

<X>/BSMSelector/BSMFilter

Code 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

RoamingRules the

terminal SHALL

NOT render the

fragments to the

user. The terminal

MAY acquire the

rules by sending a

RoamingRuleRequest

to address

indicated by

attribute

roamingRuleRequest

Address.

Note:

RoamingRuleRequest

message and associated

roaming methods are

specified in [BCAST10-

Services].

Contains the following

attributes:

id

roamingRuleRequestAddress

Contains the following

elements:

BSMFilterCode

Name

RoamingRule

NotificationReception

RMS

Id
A
NM/TM
1
Identifier of the

BSMSelector. This id is

unique within the network.

roamingRuleRequestAddress
A
NO/
0 . . . 1
Address to which the

TO

terminals can send the

RoamingRuleRequests to

request RoamingRules

associated with this

BSMSelector (identified

with the id attribute).

Terminals supporting

BroadcastRoaming SHALL

support this attribute.

BSMFilterCode
E3
NM/TM
0 . . . 1
The code that specifies

this BSMSelector.

Contains the following

attributes:

type

serviceProviderCode

corporateCode

serviceProviderName

nonSmartCardCode

Contains the following

elements:

NetworkCode3GPP

NetworkCode3GPP2

Note: At most either

‘NetworkCode3GPP’ or

‘NetworkCode3GPP2’

SHALL be present.

Implementation in XML

Schema should use

<choice>.

Type
A
NM/
1
The type of

TM

bsmFilterCode.

1 - 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/CSIM

2 - BSMCode (Non Smart

Card Code):

This is used if the

determination is made

based on the country and

operator code in the

terminal

Other values are reserved.

serviceProviderCode
A
NO/
0 . . . 1
Service Provider Code as

TM

specified by [3GPP TS

22.022] or [3GPP2

C.S0068-0].

Applicable only when

“type” == 1

corporateCode
A
NO/
0 . . . 1
Corporate Code as

TM

specified by [3GPP TS

22.022] or [3GPP2

C.S0068-0].

Applicable only when

“type” == 1

serviceProviderName
A
NO/
0 . . . 1
Service Provider Name

TM

(SPN) as specified by

[3GPP TS 31.102],

[3GPP2 C.S0023-C], or

[3GPP2 C.S0065-0].

Applicable only when

“type” == 1

nonSmartCardCode
A
NO/
0 . . . 1
Value of BSMFilterCode

TM

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

attributes:

mobileCountryCode

mobileNetworkCode

networkSubsetCode

networkSubsetCodeRange

Start

networkSubsetCodeRange

End

codeRangeStart

codeRangeEnd

mobileCountryCode
A
NO/
0 . . . 1
Mobile Country Code (3

TM

digits) as specified by

[3GPP TS 22.022].

mobileNetworkCode
A
NO/
0 . . . 1
Mobile Network Code (2-3

TM

digits) as specified by

[3GPP TS 23.003].

networkSubsetCode
A
NO/
0 . . . 1
Network Subset Code (2

TM

digits) as specified by

[3GPP TS 22.022].

networkSubsetCodeRangeStart
A
NO/
0 . . . 1
Instead of providing an

TM

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

‘networkSubsetCode

RangeEnd’ 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/
0 . . . 1
This attribute signals the

TM

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-0].

Applicable only when

“type” == 1.

Contains the following

attributes:

mobileCountryCode

mobileNetworkCode

iRMBasedMIN

hRPDRealm

ruimCSIMCodeRangeStart

ruimCSIMCodeRangeEnd

mobileCountryCode
A
NO/TM
0 . . . 1
Mobile Country Code (3

digits) as specified for

Network Type 1 by [3GPP2

C.S0068-0].

mobileNetworkCode
A
NO/TM
0 . . . 1
Mobile Network Code (2-3

digits) as specified for

Network Type 1 by [3GPP2

C.S0068-0].

iRMBasedMIN
A
NO/TM
0 . . . 1
First 4 digits of IRM-based

MIN as specified for

Network Type 2 by [3GPP2

C.S0068-0].

hRPDRealm
A
NO/TM
0 . . . 1
REALM code of the

relevant HRPD network as

specified by [3GPP2

C.S0068-0].

ruimCSIMCodeRangeStart
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.

ruimCSIMCodeRangeEnd
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.

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 information to

the user so he can select

the BSMSelector the

terminal has to use.

RoamingRule
E3
NO/TO
0 . . . 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:

allowAll

denyAll

Contains the following

elements:

TimeFrame

AllowPurchaseItem

AllowPurchaseData

AllowService

AllowContent

DenyPurchaseItem

DenyPurchaseData

DenyService

DenyContent

Terminals 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 simultaneously,

the ‘deny’ rule takes

precedence.

allowAll
A
O
0 . . . 1
Rule that, when set to

“true”, allows the Terminal

to use all the fragments

associated with

BSMFilterCode associated

with these RoamingRules.

The default value of this

attribute is “false”.

This attribute SHALL not

be present if attribute

‘denyAll’ is present.

denyAll
A
O
0 . . . 1
Rule that, when set to

“true”, prohibits the

Terminal to use any the

fragments associated with

BSMFilterCode associated

with these RoamingRules.

The default value of this

attribute “false”.

This attribute SHALL not

be present if attribute

‘allowAll’ is present.

TimeFrame
E4
O
0 . . . N
Rule that defines the time

frame(s) this RoamingRule

is applies to.

Contains the following

attributes:

startTime

endTime

startTime
A
O
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 32 bits integer part

of NTP time stamps.

endTime
A
O
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 32 bits integer part of

NTP time stamps.

Allow
E4
O
0 . . . 1
Rule that allows the

PurchaseItem

Terminal to use the listed

PurchaseItems.

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

GlobalPurchaseItemID that

is allowed to be

interpreted, rendered and

accessed.

Allow
E4
O
0 . . . 1
Rule that allows the

PurchaseData

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.

Allow
E4
O
0 . . . 1
Rule that allows the

Service

Terminal to use the

fragments corresponding

to listed globalServiceIDs.

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 globalServiceID are

allowed to be interpreted,

rendered and accessed.

Allow
E4
O
0 . . . 1
Rule that allows the

Content

Terminal to use the

fragments corresponding

to listed globalContentIDs.

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

globalContentID.

Fragments associated with

this globalContentID are

allowed to be interpreted,

rendered and accessed.

Deny
E4
O
0 . . . 1
Rule that denies the

PurchaseItem

Terminal to use the listed

PurchaseItems.

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

globalPurchaseItemID that

is denied to be interpreted,

rendered and accessed . . .

Deny
E4
O
0 . . . 1
Rule that denies the

PurchaseData

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 . . .

Deny
E4
O
0 . . . 1
Rule that denies the

Service

Terminal to use the

fragments corresponding

to listed globalServiceIDs.

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 globalServiceID are

denied to be interpreted,

rendered and accessed.

Deny
E4
O
0 . . . 1
Rule that denies the

Content

Terminal to use the

fragments corresponding

to listed globalContentIDs.

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

globalContentID.

Fragments associated with

this globalContentID 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

‘IPBroadcastDelivery’ or

‘PollURL’ to the parent

‘BSMSelector’.

In case of delivery over

Broadcast channel,

IPBroadcastDelivery

specifies the address

information for receiving

Notification message.

In case of delivery over

Interaction channel,

PollURL specify address

information for polling

notification, and

‘PollPeriod’ specifies the

associated polling period.

If this element is present,

at least one of the

elements

“IPBroadcastDelivery”, or

“PollURL” SHALL be

present.

Contains the following

elements:

IPBroadcastDelivery

PollURL

PollPeriod

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:

port

address

port
A
NM/TM
1
BSM-specific Notification

Message delivery UDP

destination port number;

delivery over Broadcast

Channel.

address
A
NM/TM
1
BSM-specific Notification

Message delivery IP

multicast address; delivery

over the Broadcast

Channel.

PollURL
E4
NM/TM
0 . . . N
URL through which the

terminal can poll

Notification messages over

the 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

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

Notification 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

retrieving Rich Media

Solution template

document.

Contains the following

elements:

Criteria

Update

Capabilities

Transport

AlternativeURL

GlobalContentId

Criteria
E5
NO/
0 . . . N
Declares the criteria

TO

required for receiving this

template

Contains the following

attributes:

templateVersion

attributeName

attributeValue

templateVersion
A
NO/
1
The version of the

TM

template. If the template

version is newer than the

one stored on the terminal

then the terminal is

applicable to receive the

RMS template.

attributeName
A
NO/
1
Profile attribute name

NM

attributeValue
A
NO/
1
Profile attribute value

TM

Capabilities
E5
NO/
1
Contains the following

TM

attributes:

type

version

Contains the following

element:

MIMEType

Complexity

type
A
NM/
1
Indicate the type of RM

TM

content.

Allowed values are:

0 - according to MIME

type

1 - W3C SVG Tiny

2 - OMA RME

3 - MPEG LASeR

4 - 3GPP DIMS

5 - 127 reserved for future

use

128 - 255 reserved for

proprietary use

version
A
NM/TM
1
Defines the version

associated with the type

MIMEType
E6
NM/
0 . . . N
MIME Media type of the

TM

rich media content.

Contains the following

attribute:

Codec

codec
A
NM/
0 . . . 1
The codec parameters for

TM

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 specification.

Complexity
E6
NM/
1
The complexity the rich

TM

media engine has to deal

with.

Contains the following

attributes:

profile

sceneUpdateCommands

screenOrientation

Contains the following

elements:

Animations

EmbeddedMediaElements

DOMnodes

Scripting

Compression

profile
A
NO/
0 . . . 1
Defines the profile/level of

TO

the RMS

Example:

For DIMS: mobile profile

level 10

For LASeR: 2006 amd1

Note: it is conditional on

the ‘type’ and ‘version’

attributes

sceneUpdateCommands
A
NO/
1
Indicates whether the rich

TM

media content requires the

processing of scene

update commands to

render the content.

Default: False

screenOrientation
A
NO/
1
Indicates whether the rich

TM

media scene requires

scene orientation

management

Default: False

Animations
E6
NO/
1
The number of animations

TM

in the rich media scene.

Contains the following

attributes:

Maximum

maximum
A
NM/
0 . . . 1
The maximum number of

TM

animations in the rich

media scene

EmbeddedMediaElements
E6
NM/
1
The number of embedded

TM

media elements (i.e. video

and audio) in the rich

media scene.

Contains the following

attributes:

embeddedVideo

embeddedAudio

embeddedVideo
A
NM/
0 . . . 1
The number of

TM

concurrently running

embedded video elements

in the rich media scene.

embeddedAudio
A
NM/
0 . . . 1
The number of

TM

concurrently running

embedded audio elements

in the rich media scene.

DOMNodes
E6
NO/
1
The number of DOM nodes

TM

required to render the rich

media content

Contains the following

attributes:

Maximum

maximum
A
NM/
1
The maximum number of

TM

active DOM nodes in a rich

media scene at any given

time.

Scripting
E6
NO/
1
Indicates whether the rich

TM

media scene requires the

processing of scripts (for

e.g. ECMAScript) to render

the content.

Contain the following

attribute:

MIMEType

MIMEType
A
NM/
0 . . . 1
Indicates the MIMEtype of

TM

the script used within the

Rich Media content.

If not present is indicates

that the content does not

contain an script.

Compression
E6
NO/
1
Indicates whether the

TM

delivered rich media scene

is compressed/encoded or

not.

Contains the following

attribute:

contentEncoding

content Encoding
A
NM/
1
Scheme used to

TM

encode/compress the rich

media content

0- None

1- XML

2- Gzip

3- LASeR

4- BiM

5-127 reserved for future

use

128-255 reserved for

proprietary use

Note: default value is 0.

Transport
E5
NM/
0 . . . 1
The pointer to the

TM

transport session

delivering the RMS

template.

Contains the following

attributes:

ipAddress

port

srcIpAddress

transmissionSessionID

hasFDT

transmissionObjectID

contentLocation

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/
0 . . . 1
Source IP address of the

TM

delivery session

In 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 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.

transmissionSessionID
A
NM/
1
This is the Transmission

TM

Session Identifier (TSI) of

the session at ALC/LCT

level

hasFDT
A
NO/
0 . . . 1
If FDT is transmitted in the

TM

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 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 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 specification

for the specific case of

SGDU delivery directly

using ALC.

transmissionObjectID
A
NM/
1
The Transport Object ID of

TM

the RMS template. If

‘hasFDT’ is assigned with

value ‘true’, then the value

of ‘transportObjectID’

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/
0 . . . 1
The location of the RMS

TM

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/
0 . . . 1
Declares the alternative

TM

URL for retrieving the RMS

template, declared in the

parent ‘RMSTemplate’

element, via the

interaction channel.

GlobalContentId
E5
NO/
0 . . . 1
If a RMSTemplate is

TM

instantiated as a content

then this element contains

value that represents the

related globalContentID.

DescriptorEntry
E1
NM/
1 . . . N
An entry in the Service

TM

Guide Delivery Descriptor.

Contains the following

attribute:

type

Contains the following

elements:

GroupingCriteria,

Transport,

AlternativeAccessURL,

ServiceGuideDeliveryUnit

Omitted

The RMS information according to the second embodiment of the present invention 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 individual service providers.

Referring to Table 3b, when multiple BSMs share the SGDD, this information is 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.

That is, the RMS element is contained in the BSMSelector element and contains the RMSTemplate element.

The RMSTemplate element contains the Criteria, Capabilities, Transport, AlternativeURL, and GlobalContentID elements.

The BSMSelector is an element to provide the information for identifying the service provider in BCAST. The BSMSelector element provides important criteria to discriminate 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 RMS process 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.

The Criteria element provides a filtering rule such that only the terminals fulfilling specific conditions to use the RMS template.

The Criteria element is not defined specifically such that the service provider can define various conditions required and contains the templateVersion and, attributeName, 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.

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.

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 3a according to the first embodiment of the present invention.

The AlternativeURL element provides the information on the alternative URL for retrieving the RMS template via one-to-one interaction channel.

The GlobalContentId element provides identifier of the content fragment when the service provider wants to provide the RMS template as content.

Although the RMS template is transported according to 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.

The structure of RMS information according to a third embodiment of the present invention is described hereinafter. FIG. 7 and Table 3c describes the structure of the RMS information according to the third embodiment of the present invention. 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.

TABLE 3c

Name
Type
Category
Cardinality
Description

RMS
E1
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:

BSMSelector

RMSTemplate

BSMSelector
E2
NM/
0 . . . 1
Specifies the BSM associated with

TM

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

attributes:

templateVersion

Contains the following elements:

Criteria

Capabilities

Transport

AlternativeURL

GlobalContentId

templateVersion
A
NO/
1
The version of the template. If

TM

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/
0 . . . N
Declares the criteria required for

TO

receiving this template

Contains the following

attributes:

attributeName

attributeValue

attributeName
A
NO/
1
Criteria attribute name

NM

attributeValue
A
NO/
1
Criteria attribute value

TM

Capabilities
E3
NO/
1
Contains the following

TM

attributes:

type

version

Contains the following element:

MIMEType

Complexity

type
A
NM/
1
Indicate the type of RM content.

TM

Allowed values are:

0 - according to MIME type

1 - W3C SVG Tiny

2 - OMA RME

3 - MPEG LASeR

4 - 3GPP DIMS

5-127 reserved for future use

128-255 reserved for

proprietary use

version
A
NM/TM
1
Defines the version associated

with the type

MIMEType
E4
NM/
0 . . . N
MIME Media type of the rich

TM

media content.

Contains the following attribute:

Codec

codec
A
NM/
0 . . . 1
The codec parameters for the

TM

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

specification.

Complexity
E4
NM/
1
The complexity the rich media

TM

engine has to deal with.

Contains the following

attributes:

profile

sceneUpdateCommands

screenOrientation

Contains the following elements:

Animations

EmbeddedMediaElements

DOMnodes

Scripting

Compression

profile
A
NO/
0 . . . 1
Defines the profile/level of the

TO

RMS

Example:

For DIMS: mobile profile level

10

For LASeR: 2006 amd1

Note: it is conditional on the

‘type’ and ‘version’ attributes

sceneUpdateCommands
A
NO/
1
Indicates whether the rich media

TM

content requires the processing

of scene update commands to

render the content.

Default: False

screenOrientation
A
NO/
1
Indicates whether the rich media

TM

scene requires scene

orientation management

Default: False

Animations
E4
NO/
1
The number of animations in the

TM

rich media scene.

Contains the following

attributes:

Maximum

maximum
A
NM/
0 . . . 1
The maximum number of

TM

animations in the rich media

scene

EmbeddedMediaElements
E4
NM/
1
The number of embedded media

TM

elements (i.e. video and audio)

in the rich media scene.

Contains the following

attributes:

embeddedVideo

embeddedAudio

embeddedVideo
A
NM/
0 . . . 1
The number of concurrently

TM

running embedded video

elements in the rich media

scene.

embeddedAudio
A
NM/
0 . . . 1
The number of concurrently

TM

running embedded audio

elements in the rich media

scene.

DOMNodes
E4
NO/
1
The number of DOM nodes

TM

required to render the rich

media content

Contains the following

attributes:

Maximum

maximum
A
NM/
1
The maximum number of active

TM

DOM nodes in a rich media

scene at any given time.

Scripting
E4
NO/
1
Indicates whether the rich media

TM

scene requires the processing

of scripts (for e.g. ECMAScript)

to render the content.

Contain the following attribute:

MIMEType

MIMEType
A
NM/
0.1
Indicates the MIMEtype of the

TM

script used within the Rich

Media content.

If not present is indicates that

the content does not contain

any script.

Compression
E6
NO/
1
Indicates whether the delivered

TM

rich media scene is

compressed/encoded or not.

Contains the following attribute:

contentEncoding

content Encoding
A
NM/
1
Scheme used to

TM

encode/compress the rich media

content

0- None

1- XML

2- Gzip

3- LASeR

4- BiM

5-127 reserved for future use

128-255 reserved for

proprietary use

Note: default value is 0.

Transport
E3
NM/
0 . . . 1
The pointer to the transport

TM

session delivering the RMS

template.

Contains the following

attributes:

ipAddress

port

srcIpAddress

transmissionSessionID

hasFDT

transmissionObjectID

contentLocation

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/
0 . . . 1
Source IP address of the

TM

delivery session

In 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

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.

transmissionSessionID
A
NM/
1
This is the Transmission

TM

Session Identifier (TSI) of the

session at ALC/LCT level

hasFDT
A
NO/
0 . . . 1
If FDT is transmitted in the

TM

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 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 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

specification for the specific

case of SGDU delivery directly

using ALC.

transmissionObjectID
A
NM/
1
The Transport Object ID of the

TM

RMS template. If ‘hasFDT’ is

assigned with value ‘true’, then

the value of ‘transportObjectID’

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/
0 . . . 1
The location of the RMS

TM

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
E3
NO/
0 . . . 1
Declares the alternative URL for

TM

retrieving the RMS template,

declared in the parent

‘RMSTemplate’ element, via the

interaction channel.

GlobalContentId
E3
NO/
0 . . . 1
If a RMSTemplate is

TM

instantiated as a content then

this element contains value that

represents the related

globalContentID.

Descriptions are made of the elements that are newly introduced in the RMS information of Table 3c but not included and described in the RMS information of Table 3b.

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 RMS template depending on the value of the idRdf attribute.

An RMS transmission method according to an embodiment of the present invention is described hereinafter.

FIG. 4 is a flowchart illustrating a rich media-enabled service guide provisioning method according to an embodiment of the present invention.

Referring to FIG. 4, the BSDA 103 creates a Service Guide (SG) with the required service guide fragments in step S401.

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.

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.

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 3a, 3b, and 3c. 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 3a, 3b, or 3c.

Finally, the BSDA 103 broadcasts the SGDD, Service Guide, and RMS template such that the terminal 105 receives them in step S407.

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 RMS template via the interaction channel at step S407.

A procedure 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.

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 105 receives the SGDDs destined to itself.

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.

Next, the terminal 105 analyzes the received SGDDs to detect the RMS information (formatted as shown in Table 3a, 3b, or 3c) from the SGDDs in step S507. If the RMS information 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 information described in Tables 3a, 3b, and 3c. For instance, the RMS information is formatted as shown in Table 3a, the terminal 105 references the Type attribute and the Version attribute contained in the RMSTemplate element to determine whether it supports the RMS template.

In the case where the RMS information is formatted as shown in Table 3b, the terminal 105 references the Criteria element and the Capability element contained in the RMSTemplate element to determine whether the terminal 105 supports the RMS template.

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 attribute, the srcIpAddress attribute, the transmissionSessionID attribute, the hasFDT attribute, the contentLocation attribute, and the transmissionObjectID attribute), and AlternativeURL element. The terminal 105 receives the RMS template with reference to these elements and attributes.

Once the RMS template 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.

If no RMS information has 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.

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.

FIG. 6 is a block diagram illustrating a configuration of the terminal according to an embodiment of the present invention.

As shown in FIG. 6, the terminal 105 includes a reception module 601, an RMS engine 603, and a BCAST client 605.

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 information contained in the SGDDs.

The RMS engine 603 interprets the RMS template and outputs the result to the BCAST client 605.

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.

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 assumption that the RMS engine 603 is the Lightweight Application for Scene Representation (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 substituted 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.

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.

The RMS engine 603 checks the LASeR commands in the decoded LASeR template and executes the commands.

The LASeR commands 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.

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.

The LASeR template 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 LASeR template and checks the information contained in the service guide fragments based on the interpreted information.

The LASeR engine 603 renders the LASeR content in the format appropriate for the terminal using the information contained in the service guide fragments. The LASeR engine 603 outputs the rendered service guide through the user interface means supporting video and audio.

The information provided 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).

Table 4 shows an exemplary SG metadata according to an embodiment of the present invention.

TABLE 4

...

<Content id=“urn:bbc:2891” version=“5”>

<Name>Spendaholics</Name>

<Genre>NON-FICTION</Genre>

</Content>

...

<PurchaseTable>

<Purchase ... >

<ServiceBundleRef IDRef=“ServiceBundleid_A”/>

...

<MediaTitle>

<Mpeg7:TitleImage>

<mpeg7:MediaUri>EasterTitle.jpg</ mpeg7:MediaUri>

</Mpeg7:TitleImage>

</MediaTitle>

...

</Purchase>

</PurchaseTable>

...

Table 4 is a structured XML data format expressing a SG metadata to be displayed on the LASeR template.

As aforementioned, the SG metadata is displayed to the user through the RMS template. Table 5 shows an RMS template according to an embodiment of the present invention.

TABLE 5

...

<text id=“Genre”...>

<tref xlink:href=“ESG.xml# xmlns(ESGMain/ESG/Content [@id=‘

urn:bbc:2891’]/Genre/text( ))”/>

</text>

<image id=“ServiceBundleImage”xlink:href=“ESG.xml#

xmlns(ESGMain/ESG/PurchaseTable/Purchase/MediaTitle/

mpeg7:TitleImage/mpeg7:MediaUri/text( ))” .../>

...

Table 5 shows the information provided by the service guide fragments, i.e. the SG metadata of Table 4, expressed in the LASeR template as the RMS template.

Here, the LASeR template includes a text identified by an id having the attribute value of “genre” and an image identified and id having the attribute value “ServiceBundleImage”.

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 5. 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. LASeR engine, the file name, file path, and location are provided for the RMS engine 603 to access the files.

In Table 5, 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.

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#xmlns(ESG Mai n/ESG/PurchaseTable/Purchase/MediaTitle/m peg7:Title Image/mpeg7:MediaUri/text( ))'.

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 5 is displayed on the screen. Also, the actual image file of the ‘image’ of which ‘id’ attribute has the attribute value ‘ServiceBundlelmage’ is presented as the information ‘EasterTitle.jpg’ provided by the service guide fragments.

Table 6 shows an RMS template according to another embodiment of the present invention.

TABLE 6

...

<xsl:template match=“PurchaseTable”>

...

<xsl:if test=“@id = ../../ESGMainBCAST/

Content[@id=‘BBCThree_d0e1052’] ”>

<svg:text ... >

<xsl:value-of select=“./Genre”/>

</svg:text>

</xsl:if>

...

<svg:image ...>

<xsl:attribute name=“href”>

<xsl:value-of select=“ESG.xml#

xmlns(ESGMain/ESG/PurchaseTable/Purchase/MediaTitle/

mpeg7:TitleImage/ mpeg7:MediaUri/text( ))” />

</xsl:attribute>

</svg:image >

...

</xsl:template>

...

Table 6 shows the information provided by the service guide fragments expressed in the W3C SVG template and the result is identical with that of Table 5.

In this case, the RMS engine 603 references the external data using various expressions and referencing methods such as Xpath, Xpointer, and eXtensible Stylesheet Language Transformations (XSLT).

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.

Although the description on the terminal is made with reference to the RMS information formatted as shown in Table 3a, the mobile terminal can be configured to support the RMS information formats of Tables 3b and 3c as well as Table 3a.

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.

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.

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.

Number	Date	Country	Kind
10-2009-0003185	Jan 2009	KR	national
10-2009-0049958	Jun 2009	KR	national
10-2009-0052574	Jun 2009	KR	national
10-2009-0056688	Jun 2009	KR	national

RICH MEDIA-ENABLED SERVICE GUIDE PROVISION METHOD AND SYSTEM FOR BROADCAST SERVICE

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

US Classifications

International Classifications

Abstract

Description

Claims

Priority Claims (4)