U.S. patent application number 14/299363 was filed with the patent office on 2014-09-25 for method and system for updating firmware of terminals in a broadcast system.
This patent application is currently assigned to Samsung Electronics Co., Ltd.. The applicant listed for this patent is Samsung Electronics Co., Ltd.. Invention is credited to Sung-Oh HWANG, Bo-Sun JUNG, Ji-Eun KEUM, Jong-Hyo LEE, Kook-Heui LEE.
Application Number | 20140289721 14/299363 |
Document ID | / |
Family ID | 41114473 |
Filed Date | 2014-09-25 |
United States Patent
Application |
20140289721 |
Kind Code |
A1 |
LEE; Jong-Hyo ; et
al. |
September 25, 2014 |
METHOD AND SYSTEM FOR UPDATING FIRMWARE OF TERMINALS IN A BROADCAST
SYSTEM
Abstract
A method and apparatus for updating firmware of terminals in a
mobile broadcast system including a Broadcast Service
Distribution/Adaptation fragment (BSDA) and a Broadcast service
Subscription Management (BSM) are provided. The method includes
transmitting a request for creation of a content fragment, by the
BSM, to the BSDA; delivering, by the BSM, a firmware package to the
BSDA; broadcasting, by the BSDA, a service guide including the
content fragment to at least one terminal; and distributing, by the
BSDA, the firmware package to the at least one terminal.
Inventors: |
LEE; Jong-Hyo; (Gyeonggi-do,
KR) ; KEUM; Ji-Eun; (Gyeonggi-do, KR) ; HWANG;
Sung-Oh; (Gyeonggi-do, KR) ; JUNG; Bo-Sun;
(Gyeonggi-do, KR) ; LEE; Kook-Heui; (Gyeonggi-do,
KR) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Samsung Electronics Co., Ltd. |
Gyeonggi-do |
|
KR |
|
|
Assignee: |
Samsung Electronics Co.,
Ltd.
Gyeonggi-do
KR
|
Family ID: |
41114473 |
Appl. No.: |
14/299363 |
Filed: |
June 9, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12414231 |
Mar 30, 2009 |
8775318 |
|
|
14299363 |
|
|
|
|
Current U.S.
Class: |
717/172 |
Current CPC
Class: |
H04H 60/13 20130101;
H04H 20/72 20130101; H04H 20/91 20130101; G06F 8/65 20130101; H04H
20/57 20130101; H04H 40/27 20130101 |
Class at
Publication: |
717/172 |
International
Class: |
G06F 9/445 20060101
G06F009/445 |
Foreign Application Data
Date |
Code |
Application Number |
Mar 28, 2008 |
KR |
10-2008-0029378 |
Claims
1. A method of updating firmware of terminals in a mobile broadcast
system including a Broadcast Service Distribution/Adaptation
fragment (BSDA) and a Broadcast service Subscription Management
(BSM), the method comprising: transmitting a request for creation
of a content fragment, by the BSM, to the BSDA; delivering, by the
BSM, a firmware package to the BSDA; broadcasting, by the BSDA, a
service guide including the content fragment to at least one
terminal; and distributing, by the BSDA, the firmware package to
the at least one terminal, wherein the content fragment includes a
terminal provisioning element to provide information that enables
targeted terminals to retrieve the firmware package, and wherein
the content fragment includes sub-elements of the terminal
provisioning element that are subject to a firmware update, the
sub-elements of the terminal provisioning element including a
manufacturer identifier element of a terminal, a model identifier
element of the terminal, and a firmware version element provided
for the firmware update.
Description
PRIORITY
[0001] This application is a Continuation of U.S. application Ser.
No. 12/414,231, which was filed in the U.S. Patent and Trademark
Office on Mar. 30, 2009, and claims priority under 35 U.S.C.
.sctn.119(a) to an application filed in the Korean Industrial
Property Office on Mar. 28, 2008 and assigned Serial No.
10-2008-0029378, the contents of which are hereby incorporated by
reference.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The present invention relates generally to a mobile
broadcast system supporting a broadcast service, and more
particularly to a method and an apparatus for updating firmware of
terminals through a service guide of a mobile broadcast system.
[0004] 2. Description of the Related Art
[0005] The mobile communication market has continuously met
requirements for the production of new services through the
recombination or unification of existing technologies. With the
development of communication and broadcast technologies, current
broadcast systems or mobile communication systems provide a
broadcast service through a portable terminal (or mobile terminal;
hereinafter, referred to simply as "terminal"), such as a mobile
phone or a Personal Digital Assistant (PDA).
[0006] In addition to potential and actual market demands, rapidly
increasing user demands for multimedia services, enterprisers'
strategy to provide a new service such as a broadcast service
beyond the existing voice service, and interests of Information
Technology (IT) companies that are enhancing mobile communication
businesses in response to consumer demands have enabled the
convergence between a mobile communication service and the Internet
Protocol (IP) to become a big stream in the development of next
generation mobile communication technology. This convergence has
introduced that application of various services existing in
wireless communication or broadcast even into the wire
communication market as well as the mobile communication market.
Such a convergence has created the same consumption environment for
various services regardless of them being wired, wireless, or
broadcast.
[0007] The Open Mobile Alliance (OMA), which is an organization
studying standards for interaction between individual mobile
solutions, determines the standards for various applications mainly
relating to mobile games, Internet services, etc. Within the
working groups of the OMA, especially in the Open Mobile Alliance
Broadcast (OMA BCAST) working group, technology standards are being
studied for providing a broadcast service (BCAST) using a mobile
terminal.
[0008] In order to receive a broadcast service in a broadcast
system, a terminal should receive service guide information
including description of the service itself, cost information for
the service, and information on a method of receiving the service.
That is, the terminal receives the service using the received
service guide information of the service.
[0009] FIG. 1 is a block diagram illustrating a mobile broadcast
system to which the present invention is applied. More
specifically, FIG. 1 illustrates a logical structure between
working groups in a BCAST system having established technology
standards of an application layer of a mobile broadcast service and
sub-layers thereof up to the transport layer in order to provide a
mobile broadcast service.
[0010] Referring to FIG. 1, a content provider or Content Creation
(CC) 101 provides content, which is the basis for the BCAST
service. The content may include a file for a typical BCAST, such
as data for movie, audio, and video. Further, the CC 101 provides a
BCAST Service Application (BSA) 102 with an attribute of the
content in order to generate a service guide and determine a
transport bearer for the transmission of the service.
[0011] The BSA 102 receives data of the BCAST service from the CC
101, and converts the data into a type suitable for media encoding,
content protection, interactive service provision, etc. Further,
the BSA 102 provides the attribute of the content supplied from the
CC 101 to a BCAST Service Distribution/Adaptation (BSDA) 103 and a
BCAST Subscription Management (BSM) 104.
[0012] The BSDA 103 performs various tasks using the BCAST service
data supplied from the BSA 102. These various tasks include file
and streaming transmission, service collection, service protection,
service guide creation and delivery, and service notification.
Further, the BSDA fragment 103 adjusts the service to be suitable
for a Broadcast Distribution System (BDS) 112.
[0013] The BSM 104 manages, by hardware or software, service
regulation including subscription and charge-related functions of a
BCAST service user, regulation of information used for the BCAST
service, and a terminal receiving the BCAST service.
[0014] The terminal 105 receives content and program support
information such as service guide and content protection, and
provides a user with a broadcast service. The BDS Service
Distribution 111 transmits a mobile broadcast service to multiple
terminals through inter-communication with the BDS 112 and an
interaction network 113.
[0015] The BDS 112 transmits a mobile broadcast service through a
broadcast channel, such as Multimedia Broadcast Multicast Service
(MBMS) of the 3rd Generation Project Partnership (3GPP), Broadcast
Multicast Service (BCMCS) of 3rd Generation Project Partnership 2
(3GPP2), which is the 3.sup.rd generation synchronous mobile
communication standard organization, and Digital Video Broadcasting
(DVB)-Handheld (DVB-H) or Internet Protocol (IP)-based
broadcast/communication network of DVB, which is a digital
broadcast standard organization. The interaction network 113
provides an interactive channel, an example of which is as a
cellular network.
[0016] In FIG. 1, BCAST-1 121 is a transmission path for content
and a content attribute, and BCAST-2 122 is a transmission path for
a content-protected or content-unprotected BCAST service, an
attribute of the BCAST service, and a content attribute. BCAST-3
123 is a transmission path for an attribute of a BCAST service, an
attribute of content, user preference and subscription information,
a user request, and a response to the user request. BCAST-4 124 is
a transmission path for a notification Message, an attribute used
for a service guide, and a key used for content Protection and
service protection.
[0017] BCAST-5 125 is a transmission path for security materials,
such as a Digital Right Management Right Object (DRM RO) and a key
value, which are used for a protected BCAST service, an unprotected
BCAST service, a content-protected BCAST service, a
content-unprotected BCAST service, a BCAST service attribute, a
content attribute, a notification, a service guide, and BCAST
service protection, and all data and signals transmitted through
the broadcast channel.
[0018] In FIG. 1, BCAST-6 126 is a transmission path for security
materials, such as a DRM RO and a key value, which are used for a
protected BCAST service, an unprotected BCAST service, a
content-protected BCAST service, a content-unprotected BCAST
service, a BCAST service attribute, a content attribute, a
notification, a service guide, and BCAST service protection, and
all data and signals transmitted through an interaction
channel.
[0019] BCAST-7 127 is a transmission path for user preference
information transmitted through an interaction channel of control
information relating to reception of security materials, such as a
DRM RO and a key value, used for service provisioning, subscription
information, device management, and BCAST service protection. The
BCAST-8 128 is a transmission path in which user data for the BCAST
service comes into interaction.
[0020] BDS-1 129 is a transmission path for security materials,
such as a DRM RO and a key value, used for a protected BCAST
service, an unprotected BCAST service, a BCAST service attribute, a
content attribute, a notification, a service guide, and BCAST
service protection. BDS-2 130 is a transmission path for security
materials, such as a DRM RO and a key value, used for service
provisioning, subscription information, device management, and
BCAST service protection.
[0021] X-1 131 is a reference point between the BDS service
distribution 111 and the BDS 112. X-2 132 is a reference point
between the BDS service distribution 111 and the interaction
network 113. X-3 133 is a reference point between the BDS 112 and
the terminal 105. X-4 134 is a reference point between the BDS
service distribution 111 and the terminal 105 through a broadcast
channel. X-5 135 is a reference point between the BDS service
distribution 111 and the terminal 105 through an interaction
channel. X-6 136 is a reference point between the interaction
network 113 and the terminal 105.
[0022] FIG. 2 illustrates a configuration of a service guide for
receiving a broadcast service to which the present invention is
applied. More specifically, the configuration illustrated in FIG. 2
is proposed for providing a broadcast service to terminals by a
BCAST system.
[0023] Referring to FIG. 2, the service guide data model includes
an administrative group 200, a provisioning group 210, a core group
220, and an access group 230. The administrative group 200 provides
basic information for enabling a terminal to receive a service
guide. That is, the administrative group 200 provides higher
configuration information of the entire service guide. The
administrative group 200 includes a service guide delivery
descriptor fragment 201.
[0024] The provisioning group 210 includes purchase and cost
information. The provisioning group 210 includes a purchase item
fragment 211, a purchase data fragment 212, and a purchase channel
fragment 213.
[0025] The core group 220 is a core part of the service guide, such
as service, content, and schedule. The core group 220 includes a
service fragment 221, a schedule fragment 222, and a content
fragment 223.
[0026] The access group 230 provides access information for access
to the service or content and includes an access fragment 231 and a
session description fragment 232.
[0027] In addition to the four groups described above (200, 210,
220, and 230), the service guide includes a preview data fragment
241 and an interactivity data fragment 251. Each of the
configuration units described above is referred to as a fragment,
which is the minimum unit of the service guide. That is, one
service guide includes fragments, which can be bundled into groups
according to their purposes. In FIG. 2, solid lines interconnecting
the fragments refer to inter-reference between the fragments.
[0028] The service guide delivery descriptor fragment 201 includes
delivery session information including a location of a Service
Guide Delivery Unit (SGDU) including fragments of the service
guide, and information on an entry point for receiving a
notification message and grouping information for the SGDU.
[0029] The purchase item fragment 211 provides a bundle including
service, contents, time, etc., thereby helping the user to
subscribe or purchase a corresponding purchase item fragment 211.
The purchase data fragment 212 includes detailed information
relating to the purchase and subscription, such as price
information on a service or service bundle and promotion
information. The purchase channel fragment 213 provides access
information for subscription or purchase.
[0030] The service fragment 221 includes information of service
contents, genre, service area, etc., as higher collections of the
contents included in the broadcast service around the general
service guide. The schedule fragment 222 indicates time information
of each of the contents included in the services such as streaming
and downloading. The content fragment 223 includes a detailed
description of the broadcasted content, a target user group, a
service area, and genre.
[0031] The access fragment 231 provides access-related information
that enables a user to see the service, and provides a delivery
method for a corresponding access session, session information,
etc. The session description fragment 232 may be included in the
access fragment 231 and notifies location information in the form
of a URI so that the terminal can identify information of a
corresponding session description fragment 232. The session
description fragment 232 provides codec information and address
information on multimedia contents existing in a corresponding
session.
[0032] Further, it is possible to provide preview information on
the service, schedule, and contents through the preview fragment
241, or to provide an interactive service during broadcast
according to the corresponding service, schedule, and contents
through the interactive fragment 251.
[0033] More detailed information on the service guide may be
defined through various element values and attribute values for
providing detailed contents and values based on the higher data
model illustrated in FIG. 2.
[0034] In the BCAST system described above, terminals receiving a
service can use the latest software and can more stably and
efficiently operate only after updating firmware periodically
provided by a manufacturer of the terminals. Therefore, in the
BCAST system, OMA Device Management (OMA DM) standards have been
defined for use of terminal firmware update standards, which is
referred to as "terminal provisioning" Herein.
[0035] The exponential increase in the number of mobile terminals
has caused a necessity for a standardized method for management of
mobile devices, and has thus resulted in requirement for a mobile
terminal management method that enables a mobile network provider
or service provider to manage firmware or software of terminals
while performing wireless communication with the terminals. The OMA
DM can manage firmware or software within a mobile terminal by
reading, adding, changing, or executing an object of the mobile
terminal by using its own a DM protocol standardized by itself.
[0036] In general, the OMA DM is designed for use within a terminal
of a mobile communication system, and thus enables all
communications to be interactive. However, the number of terminal
models will be far less compared to the actual number of subscribed
terminals. Therefore, a mobile communication system of the OMA DM
requires a very large quantity of resources if the firmware update
of each terminal is interactively performed one-to-one.
Consequently, the OMA DM uses a large quantity of resources to
perform updates. Further, in a communication environment having
limited radio resources, it is often impossible to perform
one-to-one firmware update for the multiple terminals therein.
SUMMARY OF THE INVENTION
[0037] Therefore, the present invention has been made to solve the
above-mentioned problems occurring in the prior art, and provide
the advantages and improvements as will be described below.
Accordingly, the present invention provides a method, an apparatus,
and a system for updating firmware of terminals in a mobile
broadcast system.
[0038] Also, the present invention provides a method, an apparatus,
and a system capable of simultaneously updating firmware of
multiple terminals by using a service guide in a broadcast
system.
[0039] In accordance with an aspect of the present invention, a
method of updating firmware of terminals in a mobile broadcast
system including a Broadcast Service Distribution/Adaptation
fragment (BSDA) and a Broadcast service Subscription Management
(BSM) is provided. The method includes transmitting a request for
creation of a content fragment, by the BSM, to the BSDA;
delivering, by the BSM, a firmware package to the BSDA;
broadcasting, by the BSDA, a service guide including the content
fragment to at least one terminal; and distributing, by the BSDA,
the firmware package to the at least one terminal, wherein the
content fragment includes a terminal provisioning element to
provide information that enables targeted terminals to retrieve the
firmware package, and wherein the content fragment includes
sub-elements of the terminal provisioning element that are subject
to a firmware update, the sub-elements of the terminal provisioning
element including a manufacturer identifier element of a terminal,
a model identifier element of the terminal, and a firmware version
element provided for the firmware update.
BRIEF DESCRIPTION OF THE DRAWINGS
[0040] The above and other aspects, features, and advantages of the
present invention will be more apparent from the following detailed
description taken in conjunction with the accompanying drawings, in
which:
[0041] FIG. 1 is a block diagram illustrating a logical structure
of a broadcast system;
[0042] FIG. 2 illustrates a configuration of a service guide;
[0043] FIG. 3 is a block diagram illustrating an apparatus of a
broadcast system according to an embodiment of the present
invention; and
[0044] FIG. 4 is a message flow diagram of a broadcast system
according to an embodiment of the present invention.
DETAILED DESCRIPTION OF EMBODIMENTS OF THE PRESENT INVENTION
[0045] Hereinafter, embodiments of the present invention will be
described with reference to the accompanying drawings. In the
following description, the same elements will be designated by the
same reference numerals although they are shown in different
drawings. Further, various specific definitions found in the
following description are provided only to help general
understanding of the present invention, and it is apparent to those
skilled in the art that the present invention can be implemented
without such definitions. Further, in the following description of
the present invention, a detailed description of known functions
and configurations incorporated herein will be omitted when it may
make the subject matter of the present invention rather
unclear.
[0046] The following detailed description of the embodiments of the
present invention is based on a BCAST system, which is one of
mobile broadcast technology standards. However, a BCAST system is
only one example for helping the understanding of the present
invention and should not limit the applicable scope of the present
invention to the only BCAST system. Further, it should be noted
that a broadcast system used herein includes various communication
systems providing a broadcast service, such as a BCAST system and a
DVB-H system.
[0047] Further, for convenience of description, the following
description of the present invention will use the same names of the
entities defined in the 3rd Generation Project Partnership (3GPP),
which is an asynchronous mobile communication standard
organization, or BCAST of the Open Mobile Alliance (OMA), which is
an organization for standards of applications of mobile terminals.
However, such standards and names should not limit the scope of the
present invention.
[0048] Further, in a BCAST system providing a mobile broadcast
service, a receiver relating to a downlink link service is called a
"terminal."
[0049] Further, the OMA BCAST is standardizing technologies for
providing an IP-based broadcast service in a mobile terminal
environment, such as service guide, download and streaming
transport technology, service and content protection technology,
service subscription, and roaming. With the market trend of
synthetic service provisions due to the convergence between wired
and wireless environments as described above, the mobile broadcast
technologies, such as the OMA BCAST, are expected to evolve to a
level capable of providing the service in a wired/wireless united
environment beyond the mobile environment.
[0050] Table 1 demonstrates a message schema table used in an
embodiment of the present invention.
TABLE-US-00001 TABLE 1 Name Type Category Cardinality Description
Data type
[0051] In Table 1, "Name" refers to names of element values and
attribute values of a message. "Type" refers to which of the
element value and the attribute value a name corresponds to. The
element values include values, such as E1, E2, E3, and E4, wherein
E1 refers to a super-element value of an entire message, E2 refers
to a sub-element value of E1, E3 refers to a sub-element value of
E2, and E4 refers to a sub-element value of E3. The attribute value
is expressed by A, which indicates an attribute value of a
concerned element. For example, A under E1 indicates an attribute
value of E1.
[0052] "Category" indicates if an element value or attribute value
is required or optional. The "Category" has an M value when an
element value or attribute value is required, and has O value when
the element value or attribute value is optional.
[0053] "Cardinality" indicates the relation between elements and
has a value of 0, 0 . . . 1, 1, 0 . . . n, or 1 . . . n, wherein 0
refers to an optional relation, 1 refers to an indispensable
relation, and n refers to the possibility of having multiple
values. For example, "0 . . . n" implies that there may be either
no, i.e., 0, element values or n values. "Description" indicates
the meaning of an element or attribute value, and "Data Type"
indicates the data type of an element or attribute value.
[0054] FIG. 3 is a block diagram illustrating an apparatus for
providing a firmware update for a broadcast service to a terminal
in a broadcast system according to an embodiment of the present
invention. More specifically, the apparatus illustrated in FIG. 3
includes logical entities in accordance with the present invention,
further to the existing BCAST structure as illustrated in FIG.
1.
[0055] Referring to FIG. 3, the broadcast system includes a
terminal 301, a BSDA 302, and a BSM 303. The terminal 301, the BSDA
302, and the BSM 303 of FIG. 3 are similar to the terminal 105, the
BSDA 103, and the BSM 104, respectively, as illustrated in FIG.
1.
[0056] The terminal 301 includes a Terminal Provisioning-Client
(TP-C) 304, a File Delivery-Client (FD-C) 305, a BACST Service
Provisioning-Client (BSP-C) 306, and a Service Guide-Client (SG-C)
307. The TP-C 304 receives a terminal provisioning message and
performs an operation according to the terminal provisioning
message. Further, the TP-C 304 performs functions of the terminal
side according to the standards of the OMA DM, and manages firmware
of a terminal. The FD-C 305 receives a firmware file delivered
through a broadcast, and the BSP-C 306 subscribes to a service
provided by the BCAST and performs a report function relating to
use of the service. The SG-C 307 processes the service guide
information received by the terminal 301 so that a user or the
terminal 301 can use the processed information.
[0057] The BSM 303 includes a Service Guide-Subscription Source
(SG-SS) 308, a Terminal Provisioning-Management (TP-M) 309, and a
BCAST Service Provisioning-Management (BSP-M) 310. The SG-SS 308
provides information including service provisioning and terminal
provisioning necessary for the service guide, service purchase, and
service subscription. The TP-M 309 manages a terminal provisioning,
generates a terminal provisioning message, and transmits the
terminal provisioning message to the terminal 301. Further, as
described above, the TP-M 309 performs functions of the server side
in the OMA DM, and manages firmware of a terminal in the present
invention. The BSP-M 310 performs functions of subscription
management and purchase/charge management for the BCAST
service.
[0058] FIG. 4 is a message flow diagram according to an embodiment
of the present invention.
[0059] Referring to FIG. 4, in step 411, the TP-M 409 requests the
SG-SS 408 to create an update service, for operation of the
terminal provisioning service.
[0060] Upon receiving the request for creation of the update
service, the SG-SS 408 requests the BSDA 402 to create a service
fragment for the terminal provisioning update service in step 412.
Table 2 below shows an example of the message sent from the SG-SS
408 to the BSDA 402 in step 412. The message of Table 2 corresponds
to a delivery message defined in the BCAST.
[0061] In accordance with an embodiment of the present invention,
in the delivery message in Table 2, a new parameter named "terminal
provisioning service fragment" is added to the "type" element. The
type element of the delivery message notifies the usage of a
delivery message and notifies the BSDA 402 of establishment of the
terminal provisioning service. A service fragment to actually be
provided or information necessary for generation of the service
fragment is inserted in the body element.
TABLE-US-00002 TABLE 2 Name Type Category Cardinality Description
Data Type SGDelivery E Specifies the delivery message of Service
Guide data over interface SG-4which is used for generating Service
Guide in SG-G. Contains the following elements: BSMSelector
BSMSelectorID SGData PrivateExt BSMSelector E1 M 0 . . . N This
element provides the details on the complexType visibility of the
enclosed `SGData`. All the `BSMSelectorID` values used in the
request SHALL have one and only one of these `BSMSelector` elements
instantiated with matching identifier. Element `BSMSelector` is
specified in section 5.4.1.5.2. BSMSelectorID E1 M 0 . . . N This
element represents constraints on the anyURI visibility of the all
enclosed `SGData` elements. This identifier corresponds to the `id`
attribute of the `BSMSelector` element. See the corresponding
description in the `SGDD` for more details. SGData E1 M 1 . . . N
Contains source information to be included into the Service Guide.
It is RECOMMENDED that the information is delivered in the form of
BCAST Service Guide fragments. Contains the following attributes:
id transportID version validFrom validTo encoding type Contains the
following element: Body id A M 0 . . . 1 Identifier of the data
enclosed in element anyURI `Body`. See also the description of the
`id` attribute in the `SGDeliveryRes` message. transportID A O 0 .
. . 1 Transport identifier of the data enclosed in unsignedLong
element `Body`. version A M 1 Version of the data enclosed in
element unsignedint `Body`. validFrom A M 1 Start time of the
validity of the data enclosed unsignedInt in element `Body`.
validTo A M 1 End time of the validity of the data enclosed
unsignedInt in element `Body`. encoding A M 1 Fragment encoding
type of the data enclosed unsignedByte in element `Body`. 0 - XML
encoded OMA BCAST Service Guide fragment 1 - SDP 2 - MBMS User
Service Bundle Description (MBMS-USBD) as specified in [3GPP TS
26.346] section 5.2.2. It may contain one or more SDP descriptions.
3 - AssociatedDeliveryProcedure for File and Stream Distribution as
specified in [BCAST10-Distribution] section 5.3.4 4 - 127 Reserved
for future use 128-255 Reserved for proprietary use type A M 0 . .
. 1 Fragment encoding type of the data enclosed unsignedByte in
element `Body`. This SHALL be present and set to one of the values
listed below f the `Body` contains a Service Guide XML fragment and
the value of `encoding` is set to `0`. 5 - Purchaseitem Fragment 6
- PurchaseData Fragment 7- PurchaseChannel Fragment 8 - Terminal
Provisioning Service Fragment Body E2 M 1 Contains the delivered
Service Guide data. complexType The value SHALL be an instance of
`PurchaseItem`, `PurchaseData`, `PurchaseChannel` or `Service`
element as specified in 5.1.2.6, 5.1.2.7 and 5.1.2.8 of
[BCAST10-SG]. PrivateExt E1 O 0 . . . 1 An element serving as a
container for proprietary or application-specific extensions.
<proprietary E2 O 0 . . . N Proprietary or application-specific
elements elements> that are not defined in this specification.
These elements may further contain sub-elements or attributes.
[0062] Upon receiving the request for creation of a terminal
provisioning service fragment, the BSDA 402 receives a fragment as
shown in Table 3 through a delivery message or creates a fragment
as show in Table 3 below by using information provided through the
delivery message. The type of the service is "terminal
provisioning"
[0063] In accordance with an embodiment of the present invention,
an element named "AutoSubscribe" is added to the service fragment.
The AutoSubscribe element is an element forcing the terminal 401 to
subscribe to the update service, so that the terminal can
automatically subscribe to a terminal provisioning service proposed
by as embodiment of the present invention and receive a provided
service.
TABLE-US-00003 TABLE 3 Name Type Category Cardinality Description
Data type Service E `Service` fragment contains the following
attributes: id version validFrom vaildTo globalServiceID baseCID
emergency Contains the following elements: ProtectionKeyID
ServiceType Name Description AudioLanguage TextLanguage
ParentalRating TargetUserProfile Genre Extension
PreviewDataReference BroadcastArea TermsOfUse PrivateExt id A NM/ 1
ID of the `Service` fragment. The value of this attribute anyURI TM
SHALL be globally unique." version A NM/ 1 Version of this
fragment. The newer version overrides the unsignedInt TM older one
starting from the time specified by the `validFrom` attribute, or
as soon as it has been received if no `vaildFrom` attribute is
given. This field contains the 32 bits integer part of an NTP time
stamp. validFrom A NM/ 0 . . . 1 The first moment when this
fragment is valid. If not given, unsignedInt TM the validity is
assumed to have started at some time in the past. This field
contains the 32 bits integer part of an NTP time stamp. validTo A
NM/ 0 . . . 1 The last moment when this fragment is valid. If not
given, unsignedInt TM the validity is assumed to end in undefined
time in the future. globalServiceID A NM/ 0 . . . 1 The globally
unique identifier identifying the service this anyURI TM `Service`
fragment describes. Omitted PreviewDataIDRef E2 NO/ 0 . . . N
Reference to the `PreviewData` fragment, which carries the anyURI
TM representation of Terms of Use. If this element is not present,
the `TermsOfUseText` SHALL be present. TermsOfUseText E2 NO/ 0 . .
. 1 Terms of Use text to be rendered. String TO If
`PeviewDataIDRef` element is present under the `TermsOfUse`, this
element SHALL NOT be present. AutoSubscribe E1 NO/ 0 . . . 1
Signals to be terminals whether to automatically subscribe boolean
TM to this service. PrivateExt E1 NO/ 0 . . . 1 An element serving
as a container for proprietary or TO application-specific
extensions. <proprietary E2 NO/ 0 . . . N Proprietary or
application-specific elements that are not element> TO defined
in this specification. These elements may further contain
sub-elements or attributes.
[0064] In step 413, the BSDA 402 broadcasts the created service
guide fragment to terminals.
[0065] Upon receiving the upgraded service guide through the
broadcasted created service guide fragment, the SG-C 407 determines
if there is a changed portion in the service guide. Then, the
terminal 401 discovers a newly added terminal provisioning service
in the changed service guide through the SG-C 407, and then
requests subscription to the update service to the BSP-M 410
through the BSP-C 406 according to the indication of the
AutoSubscribe element included in the update service fragment in
step 414. According to the implementation or business model, the
AutoSubscribe element may be omitted. Then, in step 415, a security
process for using the BCAST service is performed.
[0066] When the TP-M 409 wants to update firmware of terminals of a
particular model, the TP-M 409 requests the SG-SS 408 to create
content fragment for firmware files for firmware update in step
416. The firmware package file delivered in step 416 is, for
example, a compressed file in the form of gzip, which includes a
file for firmware update and a file storing OMA DM firmware update
commands indicating execution of update. The firmware package file
may be another type of compressed file other than the gzip type
compressed file.
[0067] Upon receiving the request for creation of the content
fragment for the firmware package file, the SG-SS 408 adds a new
type element value named "Content Fragment" to the delivery message
used in step 412 (step 417). An example of the delivered message is
shown below in Table 4.
TABLE-US-00004 TABLE 4 Name Type Category Cardinality Description
Data Type SGDelivery E Specifies the delivery message of Service
Guide data over interface SG-4which is used for generating Service
Guide in SG-G. Contains the following elements: BSMSelector
BSMSelectorID SGData PrivateExt BSMSelector E1 M 0 . . . N This
element provides the details on the complexType visibility of the
enclosed `SGData`. All the `BSMSelectorID values used in the
request SHALL have one and only one of these `BSMSelector` elements
instantiated with matching identifier. Element `BSMSelector` is
specified in section 5.4.1.5.2. BSMSelectorID E1 M 0 . . . N This
element represents constraints on the anyURI visibility of the all
enclosed `SGData` elements. This identifier corresponds to the `id`
attribute of the `BSMSelector` element. See the corresponding
description in the `SGDD` for more details. SGData E1 M 1 . . . N
Contains source information to be included into the Service Guide.
It is RECOMMENDED that the information is delivered in the form of
BCAST Service Guide fragments. Contains the following attributes:
id transportID version validFrom validTo encoding type Contains the
following element: Body id A M 0 . . . 1 Identifier of the data
enclosed in element anyURI `Body`. See also the description of the
`id` attribute in the `SGDeliveryRes` message. transportID A O 0 .
. . 1 Transport identifier of the data enclosed in unsignedLong
element `Body`. version A M 1 Version of the data enclosed in
element unsignedInt `Body`. validFrom A M 1 Start time of the
validity of the data enclosed unsignedInt in element `Body`.
validTo A M 1 End time of the validity of the data enclosed
unsignedInt in element `Body`. encoding A M 1 Fragment encoding
type of the data enclosed unsignedByte in element `Body`. 0 - XML
encoded OMA BCAST Service Guide fragment 1 - SDP 2 - MBMS User
Service Bundle Description (MBMS-USBD) as specified in [3GPP TS
26.346] section 5.2.2. It may contain one or more SDP descriptions.
3 - AssociatedDeliveryProcedure for File and Stream Distribution as
specified in [BCAST10-Distribution] section 5.3.4 4 - 127 Reserved
for future use 128-255 Reserved for proprietary use type A M 0 . .
. 1 Fragment encoding type of the data enclosed unsignedByte in
element `Body`. This SHALL be present and set to one of the values
listed below the `Body` contains a Service Guide XML fragment and
the value of `encoding` is set to `0`. 5 - PurchaseItem Fragment 6
- PurchaseData Fragment 7- PurchaseChannel Fragment 8 - Terminal
Provisioning Service Fragment 9 - Content Fragment Body E2 M 1
Contains the delivered Service Guide data. complexType The value
SHALL be an instance of `PurchaseItem`, `PurchaseData`,
`PurchaseChannel`, `Service` or `Content` element as specified in
5.1.2.6, 5.1.2.7 and 5.1.2.8 of [BCAST10-SG]. PrivateExt E1 O 0 . .
. 1 An element serving as a container for proprietary or
application-specific extensions. <proprietary E2 O 0 . . . N
Proprietary or application-specific elements elements> that are
not defined in this specification. These elements may further
contain sub-elements or attributes. indicates data missing or
illegible when filed
[0068] The BSDA 402 either receives the content fragment created as
shown in Table 5 below through the delivery message or creates the
fragment based on the information provided through the delivery
message in step 417.
[0069] Here, in a content fragment according to an embodiment of
the present invention, an element named "TerminalProvisioning" and
its sub-elements named "manufacturer", "model", "fwVersion", and
"command" are added to the existing content fragment. The
manufacture (vendor) element has a value for identifying a terminal
manufacturer to be subjected to the firmware update, and the model
element has a value for identifying the terminal model. The
fwVersion element indicates a firmware version provided for the
firmware upgrade. The elements of manufacturer, model, and
fwVersion are filtering elements used for firmware filtering of the
terminal.
TABLE-US-00005 TABLE 5 Name Type Category Cardinality Description
Data type Content E `Content` fragment contains the following
attributes: id version validFrom vaildTo globalContentID emergency
serviceContentProtection baseCID Contains the following elements:
ServiceReference ProtectionKeyID ServiceType Name Description
StartTime EndTime AudioLanguage TextLanguage Length ParentalRating
TargetUserProfile Genre Extension PreviewDataReference
BroadcastArea TermsOfUse PrivateExt id A NM/ 1 ID of the `Content`
fragment. The value of this attribute anyURI TM SHALL be globally
unique. version A NM/ 1 Version of this fragment. The newer version
overrides the unsignedInt TM older one starting from the time
specified by the `validFrom` attribute, or as soon as it has been
received if no `vaildFrom` attribute is given. validFrom A NM/ 0 .
. . 1 The first moment when this fragment is valid. If not given,
unsignedInt TM the validity is assumed to have started at some time
in the past. This field contains the 32 bits integer part of an NTP
time stamp. validTo A NM/ 0 . . . 1 The last moment when this
fragment is valid. If not given, unsignedInt TM the validity is
assumed to end in undefined time in the future. This field contains
the 32 bits integer part of an NTP time stamp. globalContentID A
NM/ 0 . . . 1 The globally unique identifier identifying the
service that this anyURI TM `Service` fragment describes. Omitted
TermsOfUseText E2 NO/ 0 . . . 1 Terms of Use text to be rendered.
String TM If `PeviewDataIDRef` element is present under the
`TermsOfUse`, this element SHALL NOT be present.
TerminalProvisioning E1 NO/ 0 . . . 1 Terminal Provisioning
specific information consists of the TM following elements:
Manufacturer Model FwVersion Command Manufacturer E2 NO/ 0 . . . 1
Terminal manufacturer ID. The terminal manufacturer ID String TM
must be recognizable by the terminal. Model E2 NO/ 0 . . . 1
Terminal model ID. The terminal model ID must be String TM
recognizable by the terminal FwVersion E2 NO/ 0 . . . 1 Firmware
version number. The terminal must recognize the String TM firmware
version PrivateExt E1 NO/ 0 . . . 1 An element serving as a
container for proprietary or TO application-specific extensions.
<proprietary E2 NO/ 0 . . . N Proprietary or
application-specific elements that are not elements. TO defined in
this specification. These elements may further contain sub-elements
or attributes.
[0070] In step 418, the TP-M 409 delivers the firmware package file
to the BSDA 402. The current BCAST standards do not include a
definition on a method of delivering a file between the TP-M 409
and the BSDA 402. However, because there is a definition for a
method of delivering a file between the BSDA 402 and the BSM 102
and the same type of delivery is necessary in the process of the
present invention, an embodiment of the present invention follows
the file delivery method between the BSDA 402 and the BSM 102
defined in the BCAST standards.
[0071] In step 419, the BSDA 402 broadcasts the content fragment
created in step 417 to multiple terminals.
[0072] When the terminals having subscribed to the terminal
provisioning service in step 414 recognize the content update in
the terminal provisioning service of the service guide updated
through the SG-C 407 having received the broadcasted content
fragment, they check the terminal provisioning elements of a
concerned content fragment.
[0073] As illustrated in FIG. 4, the terminal 401 checks the
manufacturer, model, and FwVersion among the terminal provisioning
elements added in Table 5 of the present invention. As a result of
the checking, when the manufacturer and the model are identical to
the manufacturer and model of the terminal 401 and the updated
firmware version is newer than the current firmware version
installed in the terminal, the terminal 401 receives the firmware
package file broadcasted through the FD-C 405 in step 420. In step
421, the terminal 401 acquires the firmware package file through
the FD-C 405 and decompresses the firmware package file. Further,
the terminal 401 delivers an actual firmware file in the firmware
package file and a firmware update command of the OMA DM in the
firmware update command file to the TP-C 404 in step 422. In step
423, the TP-C 404 performs firmware update by the actual firmware
file according to the received firmware update command file, and
(although not shown) may send an installation success message to
the TP-M 409.
[0074] Although the above description is directed to firmware
updates, the embodiments of the present invention are also
applicable to updating typical software, other than firmware,
according to the implementation or service scenario in providing a
terminal provisioning service.
[0075] As described above, a firmware update is provided through a
broadcast service. Therefore, it is possible to reduce the overhead
of individual upgrade of the firmware of each terminal in the prior
art. That is, it is possible to simultaneously update the firmware
of multiple terminals through a broadcast service. Therefore, the
embodiments of the present invention can achieve a more efficient
use of limited radio resources, thereby improving the efficiency of
firmware update.
[0076] While the present invention has been shown and described
with reference to certain embodiments thereof, it will be
understood by those skilled in the art that various changes in form
and details may be made therein without departing from the spirit
and scope of the present invention as defined by the appended
claims.
* * * * *