ak 02726831 2012-11-23
=
' 74420-472
METHOD FOR MAPPING SIGNALING INFORMATION TO ANNOUNCEMENT
INFORMATION AND BROADCAST RECEIVER
BACKGROUND OF THE INVENTION
Field of the Invention
[0001] The present invention relates to a signaling method
for a service type of a service transmitted by non-real time
(hereinafter abbreviated NRT) and detailed information on the
service through a terrestrial broadcast network and an
operation of an NRT receiver for receiving to process the
corresponding information, and more particularly, to a
broadcast receiver and a method of mapping signaling
information for an NRT service to announcement information
therein. Although the present invention is suitable for a
wide scope of applications, it is particularly suitable for
the receiver to obtain additional information on the
corresponding NRT service using the service relevant
signaling information, determine how to process and output
the corresponding service to a user and determine an
operation of an associated application module.
Discussion of the Related Art
[0002] Generally, an NRT (non-real time service) is one of
powerful applications that will be utilized for future DTV
1
CA 02726831 2012-11-23
74420-472
services. The NRT is accompanied by non-real time transmission
(not real-time streaming), storage and viewing operations and
transmits a content of a file type on a surplus bandwidth via a
broadcast medium such as terrestrial and the like. And, it is
expected that the NRT will be implemented various kinds of
service functions including push VOD, targeted advertising and
the like.
SUMMARY OF THE INVENTION
[0003] According to an aspect of the present invention,
there is provided a method of transmitting a non-real time
service, the method comprising: generating internet protocol
(IP) datagrams containing the non-real time service and
signaling data for the non-real time service; and transmitting
a broadcast signal including the generated IP datagrams,
wherein the IP datagrams are encapsulated based on a User
Datagram Protocol/Internet Protocol (UDP/IP) method, wherein
the non-real time service includes one or more content items,
each of the one or more content items composed of one or more
files delivered via File Delivery over Unidirectional Transport
(FLUTE) file delivery sessions, wherein the signaling data
includes first signaling data containing service-level
attributes for the non-real time service, wherein each of the
FLUTE file delivery sessions includes one or more FLUTE
channels, and wherein all of the FLUTE channels in each of the
FLUTE file delivery sessions have a same IP address and
consecutively numbered UDP ports signaled with a single
component descriptor in the first signaling data.
[0003a] According to another aspect of the present invention,
there is provided an apparatus for receiving a non-real time
2
CA 02726831 2014-03-20
* 74420-472
service, the apparatus comprising: a tuner configured to
receive a broadcast signal including internet protocol (IP)
datagrams, the IP datagrams containing the non-real time
service that is delivered in advance of its use and stored in a
receiving device and signaling data for the non-real time
service; a demodulator configured to demodulate the received
broadcast signal; a decoder configured to decode the IP
datagrams from the demodulated broadcast signal; a processor
configured to process the non-real time service and the
signaling data from the IP datagrams; and a storage unit
configured to store the processed non-real time service,
wherein the IP datagrams are encapsulated based on a User
Datagram Protocol/Internet Protocol (UDP/IP) method, wherein
the non-real time service includes one or more content items,
each of the one or more content items composed of one or more
files delivered via File Delivery over Unidirectional Transport
(FLUTE) file delivery sessions, wherein the signaling data
includes first signaling data containing service-level
attributes for the non-real time service, wherein each of the
FLUTE file delivery sessions includes one or more FLUTE
channels, and wherein all of the FLUTE channels in each of the
FLUTE file delivery sessions have a same IP address and
consecutively numbered UDP ports signaled with a single
component descriptor in the first signaling data.
[0003b] According to another aspect of the present invention,
there is provided an apparatus for receiving a non-real time
service, the apparatus comprising: a tuner configured to
receive a broadcast signal including internet protocol (IP)
datagrams, the IP datagrams containing the non-real time
service and signaling data for the non-real time service; a
processor configured to process the non-real time service and
3
CA 02726831 2014-03-20
' 74420-472
the signaling data from the IP datagrams; and wherein the non-
real time service includes one or more content items, each of
the one or more content items composed of one or more files
delivered via File Delivery over Unidirectional Transport
(FLUTE) file delivery sessions, wherein the signaling data
includes first signaling data containing service-level
attributes for the non-real time service, wherein each of the
FLUTE file delivery sessions includes one or more FLUTE
channels, and wherein all of the FLUTE channels in each of the
FLUTE file delivery sessions have a same IP address and
consecutively numbered UDP ports signaled with a single
component descriptor in the first signaling data.
[0004] Some embodiments are directed to a broadcast receiver
and a method of mapping signaling information to announcement
information therein that may substantially obviate one or more
problems due to limitations and disadvantages of the related
art.
3a
CA 02726831 2012-11-23
74420-472
[0005] Some embodiments may provide a broadcast receiver and
a method of mapping signaling information to announcement
information, wherein the signaling data for an NRT service can
be defined.
[0006] Some embodiments may provide a broadcast receiver and
a method of mapping signaling information to announcement
information, wherein a scheme for transmitting the above-
defined signaling data can be defined.
[0007] Some embodiments may provide a broadcast receiver and
a method of mapping signaling information to announcement
information, wherein an NRT service is accessible in a manner
that the receiver receives and process signaling data for the
transmitted NRT service.
[0008] Some embodiments may provide a method of mapping a
content identifier of the signaling data to an identifier of a
selected and transmitted content in a receiver.
[0009] Some embodiments may provide a method of receiving
and processing a content selected from a service guide
configured by using the signaling data in the receiver, which
can provide the processed content to a user.
[0010] Additional advantages and features of some
embodiments of the invention will be set forth in part in the
description which follows and in part will become apparent to
those having ordinary skill in the art upon examination of the
following or may be learned from practice of the invention.
The objectives and other advantages of some embodiments of the
invention may be realized and attained by the structure
4
CA 02726831 2012-11-23
74420-472
particularly pointed out in the written description and claims
hereof as well as the appended drawings.
[0011] In another aspect, a method of providing a Non-Real-
Time (NRT) service includes receiving a file configuring the
NRT service, first signaling information and second signaling
information encapsulated with an IP packet and contained in a
single ensemble, configuring and displaying a service guide
using the first signaling information acquired from the
ensemble, acquiring a first content identifier of a content
selected from the displayed service guide, accessing a FLUTE
session using the second signaling information acquired from
the ensemble and acquiring a second content identifier matched
with the first content identifier, and receiving and storing at
least one file configuring the content based on the acquired
second content identifier.
[0012] In some embodiments, the method may further include
receiving Fast Information Channel (FIC) data containing cross
layer information for acquiring the NRT service and Transport
Parameter Channel (TPC) data containing FIC version information
for identifying the update of the FIC.
[0013] In some embodiments, the FIC data may contain an
ensemble identifier and a transport stream identifier.
[0014] In some embodiments, the second signaling information
may be received in a state of being encapsulated by a User
Datagram Protocol/Internet Protocol (UDP/IP) header having a
predetermined IP address and UDP port number.
[0015] In some embodiments, a slot corresponding to the
ensemble may be received according to a time slicing scheme.
5
CA 02726831 2012-11-23
74420-472
[0016] In some embodiments, the first signaling information
may be an Open Mobile Alliance (OMA) Mobile Broadcast Services
Enabler Suite (BCAST) Service Guide (SG), and the second
signaling information may be a Service Map Table (SMT).
[0017] In some embodiments, the acquired first content
identifier may contain globalContentID of the content or a
content identifier which is separately defined in association
with the NRT service.
[0018] In some embodiments, the acquired first content
identifier may be mapped based on the acquired second content
identifier, and the second content identifier may be a 16-bit
binary number.
[0019] In some embodiments, the transport stream identifier
in the received FIG and the service identifier in the received
second signaling information may be combined so as to be
converted into a specific type, and mapping may be performed
based on the service identifier in the first signaling
information.
[0020] In another aspect, a mobile broadcast receiver
include a baseband processor receiving a single ensemble
including a file configuring a Non-Real-Time (NRT) service,
first signaling information and second signaling information
encapsulated with an IP packet, a first handler acquiring the
first signaling information from the received ensemble and
configuring and displaying a service guide using the acquired
first signaling information, a second handler acquiring a first
content identifier of a content selected from the displayed
service guide, a third handler acquiring the second signaling
information from the ensemble, accessing a FLUTE session using
6
CA 02726831 2012-11-23
74420-472
the acquired second signaling information, and acquiring a
second content identifier matched with the first content
identifier, a controller controlling at least one file
configuring the content to be received based on the acquired
second content identifier, and a storage storing the received
at least one file.
[0021] In some embodiments, fast Information Channel (FIC)
data containing cross layer information for acquiring the NRT
service and Transport Parameter Channel (TPC) data containing
FIC version information for identifying the update of the FIC
may be received.
[0022] In some embodiments, the FIC data may contain an
ensemble identifier and a transport stream identifier.
[0023] In some embodiments, the second signaling information
may be received in a state of being encapsulated by a User
Datagram Protocol/Internet Protocol (UDP/IP) header having a
predetermined IP address and UDP port number.
[0024] In some embodiments, a slot corresponding to the
ensemble may be received according to a time slicing scheme.
[0025] In some embodiments, the first signaling information
may be an Open Mobile Alliance (OMA) Mobile Broadcast Services
Enabler Suite (BCAST) Service Guide (SG), and the second
signaling information may be a Service Map Table (SMT).
[0026] In some embodiments, the acquired first content
identifier may contain globalContentID of the content and a
content identifier which is separately defined in association
with the NRT service.
7
CA 02726831 2012-11-23
74420-472
[0027] In some embodiments, the transport stream identifier
in the received FIC and the service identifier in the received
second signaling information may be combined so as to be
converted into a specific type, and mapping is performed based
on the service identifier in the first signaling information.
[0028] Some embodiments may provide the following effects
and/or advantages.
[0029] First of all, a transmitting side is able to include
signaling data to enable an NRT service, which is provided by a
receiver, to be properly recognized, received and processed.
[0030] Secondly, the receiver is able to receive, process
and provide the received NRT service to a user using the
transmitted signaling data.
[0031] Thirdly, the receiver is able to configure and
provide a service guide to a user using the transmitted
signaling data.
[0032] Fourthly, the receiver is able to receive and process
a content selected from the above-configured service guide
accurately using signaling information.
[0033] It is to be understood that both the foregoing
general description and the following detailed description of
8
ak 02726831 2012-11-23
74420-472
some embodiments of the present invention are exemplary and
explanatory and are intended to provide further explanation of
the invention as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0034] The accompanying drawings, which are included to
provide a further understanding of the invention and are
incorporated in and constitute a part of this application,
illustrate embodiment(s) of the invention and together with
the description serve to explain the principle of the
invention. In the drawings:
[0035] FIG. 1 is an exemplary conceptual diagram of an
Non-Real-Time (NRT) service;
[0036] FIG. 2 is an exemplary block diagram showing the
configuration of a reception system according to an
embodiment of the present invention;
[0037] FIG. 3 is an exemplary diagram explaining relations
between an NRT service, content items and files;
[0038] FIG. 4 is a diagram for a protocol stack of a
mobile NRT service configured according to An embodiment of
the present invention
[0039] FIG. 5 is a view showing an embodiment of the
. structure of a data group according to the present invention;
9
ak 02726E31 2012-11-23
74420-472
[0040] FIG. 6 is a view showing the structure of an RS
frame containing a mobile NRT service configured according to
, an embodiment of the present invention;
[0041] FIG. 7 is a view showing an example of an M/H frame
structure for transmission or reception of mobile service
data according to an embodiment of the present invention;
[0042] FIG. 8 is a view showing an example of the
structure of a VSB frame;
[0043] FIG. 9 is a view showing a data transmission
structure in a physical layer according to an embodiment of
. the present invention;
[0044] FIG. 10 is a view showing a hierarchical signaling
structure according to an embodiment of the present
invention;
[0045] FIGs. 11 and 12 are views showing the bitstream
syntax of an SMT configured according to an embodiment of the
present invention;
[0046] FIG. 13 is a view showing the structure of a
' Service Guide (SG) according to an embodiment of the present
invention;
[0047] FIG. 14 is a view explaining the bitstream syntax
of an NRT component descriptor configured according to an
embodiment of the present invention;
ak 02726831 2012-11-23
74420-472
[0048] FIG. 15 is a view explaining the bitstream syntax
of NRT component data when a component type value is 38 in
the NRT component descriptor of FIG. 14;
[0049] FIG. 16 is a view explaining a relationship among
an M/H service, a FLUTE session and an NRT service according
to an embodiment of the present invention;
[0050] FIG. 17 is a view explaining a File Description
Table (FDT) schema for mapping a file to content_id according
to an embodiment of the present invention;
[0051] FIG. 18 is a view explaining an FDT schema for
mapping a file to content Id according to another embodiment
of the present invention;
[0052] FIG. 19 is a block diagram showing an example of a
receiver used for mapping of signaling information configured
according to an embodiment of the present invention;
[0053] FIG. 20 is a view explaining a connection process
for converting and mapping Service Map Table (SMT) data and
Open Mobile Alliance (OMA) Mobile Broadcast Services Enabler
Suite (BCAST) Service Guide (SG) data according to an
embodiment of the present invention;
[0054] FIG. 21 is a view explaining an Extensible Markup
Language (XML) schema of OMA BCAST SG broadcast service
delivery for providing access information through an NRT
service according to an embodiment of the present invention;
11
CA 02726831 2012-11-23
74420-472 -
[0055] FIG. 22 is a view illustrating a method of
converting service id;
[0056] FIG. 23 is a flowchart illustrating a method of
providing an NRT service according to an embodiment of the
present invention; and
[0057] FIG. 24 is a flowchart illustrating a method of
providing an NRT service according to another embodiment of
the present invention.
DETAILED DESCRIPTION OF EMBODIMENTS
[0058] Reference will now be made in detail to the
preferred embodiments of the present invention, examples of
which are illustrated in the accompanying drawings. Wherever
possible, the same reference numbers will be used throughout
the drawings to refer to the same or like parts.
Definitions of Terminologies Used for the Invention
[0059] Terminologies used for the present invention are
selected from general terminologies, which are currently and
widely used, in consideration' of functions in the present
invention but may vary according to intentions of a person
having an ordinary knowledge in the technical field,
practices or the advent of new technology, etc. In specific
case, a terminology may be arbitrarily chosen by the
applicant(s). In this case, its detailed meaning shall be
12
CA 02726831 2010-12-02
=
described in Detailed Description of Invention. Therefore,
, the terminology used for the present invention needs to be
defined based on the intrinsic meaning of the terminology and
the contents across the present invention instead of a simple
name of the terminology.
[0060] Among the terms used in the description of the
present invention, main service data correspond to data that
can be received by a fixed receiving system and may include
audio/video (A/V) data. More specifically, the main service
. data may include A/V data of high definition (HD) or standard
definition (SD) levels and may also include diverse data
types required for data broadcasting. Also, the known data
correspond to data pre-known in accordance with a pre-
= arranged agreement between the receiving system and the
transmitting system.
[0061] Additionally, among the terms used in the present
invention, "M/H" (or MH) corresponds to the initials of
' "mobile" and "handheld" and represents the opposite concept
of a fixed-type system.
Furthermore, the M/H service data
may include at least one bf mobile service data, and handheld
service data, and will also be referred to as "mobile service
data" for simplicity.
Thereafter, the M/H, MH, and mobile
are used as the same meaning. Herein, the mobile service data
not only correspond to M/H service data but may also include
any type of service data with mobile or portable
13
CA 02726831 2010-12-02
=
characteristics.
Therefore, the mobile service data
. according to the present invention are not limited only to
the M/H service data.
[0062] The above-described mobile service data may
correspond to data having information, such as program
execution files, stock information, and so on, and may also
correspond to A/V data.
Most particularly, the mobile
service data may correspond to A/V data having lower
resolution and lower data rate as compared to the main
service data. For example, if an A/V codec that is used for
a conventional main service corresponds to a MPEG-2 codec, a
MPEG-4 advanced video coding (A.VC) or scalable video coding
(Svc) having better image compression efficiency may be used
as the A/V codec for the mobile service.
Furthermore, any
type of data may be transmitted as the mobile service data.
For example, transport protocol expert group (TPEG) data for
broadcasting real-time transportation information or non-real
time (NRT) service data may be transmitted as the main
service data.
[0063] Also, a data service using the mobile service data
may include weather forecast services, traffic information
services, stock information services, viewer participation
quiz programs, real-time polls and surveys, interactive
education broadcast programs, gaming services, services
providing information on synopsis, character, background
14
CA 02726831 2010-12-02
music, and filming sites of soap operas or series, services
providing information on past match scores and player
profiles and achievements, and .services providing information
on product information and programs classified by service,
medium, time, and theme enabling purchase orders to be
processed. Herein, the present invention is not limited only
to the services mentioned above,
[0064] A transmission system of the present invention can
multiplex and transmit mobile service data containing an NRT
service and main service data in the same or different
physical channels, without influencing the reception of main
service data by an existing reception system (backward
compatibility).
[0065] Furthermore, the transmitting system according to
the present invention performs additional encoding on the
mobile service data and inserts the data already known by the
. receiving system and transmitting system (e.g., known data),
thereby transmitting the processed data.
[0066] Therefore, when using the transmitting system -
according to the present invention, the receiving system may
. receive the mobile service data during a mobile state and may
also receive the mobile service data including an NRT service
with stability despite various 'distortion and noise occurring
within the channel.
=
1.5
ak 02726831 2010-12-02
_==
A conceptional diagram of an NRT service
[0067] FIG. 1 is an exemplary conceptional diagram for an
NRT service.
[0068] First of all, a broadcasting station transmits an
RT (real time) service according to a conventional method. In
doing so, the broadcasting station transmits the RT service
or an NRT (non-real time) service using a bandwidth left in
the due course. In this case, the NRT service can contain a
news clip, weather information, advertisements, content for
Push VOD (video on demand), etc.
[0069] Yet, a related art DTV receiver, i.e., a legacy
device .has the principle that the operation is not affected
' by an NRT stream included within a channel. However, the
related art DTV receiver has a problem in receiving and
processing an NRT service provided by a broadcasting station
properly.
[0070] On the contrary, a broadcast receiver according to
the present invention, i.e., an NRT device is able to
properly receive and process an NRT service combined with an
RT service, thereby providing a viewer with more various
functions than those of the related art DTV.
[0071] In this case, the RT service and the NRT service
are transmitted on the same DTV channel or different DTV
channels and are transmitted through MPEG-2 TP (transport
packet) or IP datagram. Hence, a receiver needs to identify
16
CA 02726831 2010-12-02
, = =
;
the two kinds of services transmitted on the same channel.
For this, this specification discloses a method of defining
and providing signaling information to enable a receiver to
receive and process an NRT service properly. In this case, a
broadcasting station provides signaling information via
PSI/PSIP (program specific information/program and system
information protocol). Specifically, at least one unique PID
(packet identifier) for identifying an NRT service can be
allocated.
A Receiving System
[0072] FIG. 2 is an exemplary block diagram of a receiving
system according to an embodiment of the present invention.
[0073] Referring to FIG. 2, the receiving system according
to the present invention may include an operation controller
100, a tuner 111, a demodulator 112, an equalizer 113, a
known sequence detector (or known data detector) 114, a block
decoder 115, a primary Reed-Solomon (RS) frame decoder 116, a
secondary RS frame decoder 117, a signaling decoder 118, and
, a baseband controller 119. The receiving system according to
the present invention may further include an FIC handler 121,
a service manager 122, a service signaling handler 123, and a
first storage unit 124. The receiving system according to the
, present invention may further include a primary RS frame
buffer 131, a secondary RS frame buffer 132, and a transport
17
ak 02726831 2010-12-02
= =
.=
,
packet (TS) handler 133. The receiving system according to
the present invention may further include an Internet
Protocol (IP) datagram handler 141, a descrambler 142, an
. User Datagram Protocol (UDP) datagram handler 143, a Real-
time Transport Protocol/Real-time Transport Control Protocol
(RTP/RTCP) datagram handler 144, a Network Time Protocol
(NTP) datagram handler 145, a service protection stream
= handler 146, a second storage unit 147, an Asynchronous
Layered Coding/Layered Coding Transport (ALC/LCT) stream
handler 148, a decompressor 149, an Extensible Mark-up
Language (XML) parser 150, and a Field Device Tool (FDT)
' handler 151. The receiving system according to the present
invention may further include an Audio/Video (A/V) decoder
161, a file decoder 162, a third storage unit 163, a middle
ware (M/W) engine 164, and a Service Guide (SG) handler 165.
The receiving system according to the present invention may
further include an Electronic Program Guide (EPG) manager 171,
an application manager 172, .and an User Interface (UI)
manager. 173.
[0074] Herein, for simplicity of the description of the
present invention, the operation controller 100, the tuner
111, the demodulator 112, the equalizer 113, the known
sequence detector (or known data detector) 114, the block
decoder 115, the primary RS .frame decoder 116, the secondary
RS frame decoder 117, the signaling decoder 118, and the
18
ak. 02726831 2010-12-02
baseband controller 119 will be collectively referred to as a
baseband processor 110. The FIC handler 121, the service
manager 122, the service signaling handler 123, and the first
storage unit 124 will be collectively referred to as a
service multiplexer 120. The primary RS frame buffer 131, the
secondary RS frame buffer 132, and the TS handler 133 will be
collectively referred to as an IP adaptation module 130. The
IP datagram handler 141, the descrambler 142, the UDP
datagram handler 143, the RTP/RTCP datagram handler 144, the
NTP datagram handler 145, the service protection stream
handler 146, the second storage unit 147, the ALC/LCT stream
handler 148, the XML parser 150, and the FDT handler 151 will
be collectively referred to as a common IP module 140. The
A/V decoder 161, the file decoder 162, the third storage unit
163, the M/W engine 164, and the SG handler 165 will be
collectively referred to as an application module 160.
(0075] In addition, although the terms used in FIG. 2 are
selected from generally known and used terms, some of the
terms mentioned in the description of FIG. 19 have been
selected by the applicant at his or her discretion, the
detailed meanings of which are 'described in relevant parts of
the description herein. Furthermore, it is required that the
, present invention is understood, not simply by the actual
terms used but by the meaning of each term lying within.
19
CA 02726831 2010-12-02
[0076] Referring to FIG. 2,, the operation controller 100
controls the operation of each block included in the baseband
processor 110.
[0077] By tuning the receiving system to a specific
physical channel frequency (or' physical transmission channel
frequency, PTC), the tuner 111 enables the receiving system
to receive main service data, which correspond to broadcast
signals for fixed-type broadcast receiving systems, and
mobile service data, which correspond to broadcast signals
for mobile broadcast receiving systems. At this point, the
. tuned frequency of the specific physical channel is down-
converted to an intermediate frequency (IF) signal, thereby
being outputted to the demodulator 112 and the known sequence
detector 114. The passband digital IF signal being outputted
= from the tuner 111 may only include main service data, or
only include mobile service data, or include both main
service data and mobile service data.
[0078] The demodulator 112 performs self-gain control,
' carrier recovery, and timing recovery processes on the
pasSband digital IF signal inputted from the tuner 111(
thereby modifying the IF signal to a baseband signal. Then,
the demodulator 112 outputs the baseband signal to the
equalizer 113 and the known sequence detector 114. The
demodulator 112 uses the known data symbol sequence inputted
from the known sequence detector 114 during the timing and/or
ak 02726831 2010-12-02
carrier recovery, thereby 'enhancing the demodulating
performance.
[0079] The equalizer 113 compensates channel-associated
distortion included in the signal demodulated by the
demodulator 112.
Then, the equalizer 113 outputs the
distortion-compensated signal to the block decoder 115. By
. using a known data symbol sequence inputted from the known
sequence detector 114, the equalizer 113 may enhance the
equalizing performance.
Furthermore, the equalizer 113 may
receive feed-back on the decoding result from the block
' decoder 115, thereby enhancing the equalizing performance.
[0080] The known sequence detector 114 detects known data
place (or position) inserted by the transmitting system from
the input/output data (i.e., data prior to being demodulated
or data being processed with partial demodulation).
Then,
the known sequence detector 114 outputs the detected known
data position information and known data sequence generated
from the detected position information to the demodulator 112,
the equalizer 113, and the baseband controller 119.
Additionally, in order to allow the block decoder 115 to
identify the mobile service data that have been processed
with additional encoding by the transmitting system and the
main service data that have not been processed with any
additional encoding, the known sequence detector 114 outputs
such corresponding information to the block decoder 115.
21
CA 02726831 2010-12-02
[0081] If the data channel-equalized by the equalizer 113
and inputted to the block decoder 115 correspond to data
processed with both block-encoding of serial concatenated
convolution code (SCCC) method and trellis-encoding by the
transmitting system (i.e., data within the RS frame,
signaling data), the block decoder 115 may perform trellis-
decoding and block-decoding as inverse processes of the
transmitting system. On the other hand, if the data channel-
equalized by the equalizer 113 and inputted to the block
decoder 115 correspond to data processed only with trellis-
encoding and not block-encoding by the transmitting system
(i.e., main service data), the block decoder 115 may perform
only trellis-decoding.
[0082] The signaling decoder 118 decodes signaling data
that have been channel-equalized and inputted from the
equalizer 113. It
is assumed, that the signaling data (or
signaling information) inputted to the signaling decoder 118
correspond to data processed with both block-encoding and
trellis-encoding by the transmitting system.
Examples of
such signaling data may include transmission parameter
channel (TPC) data and fast information channel (FTC) data.
, For example, among the data that are being inputted, the
signaling decoder 118 performs regressive turbo decoding of a
parallel concatenated convolution code (PCCC) method on data
corresponding to the signaling information region.
22
CA 02726831 2010-12-02
Subsequently, the signaling decoder 118 separates FIC data
and TPC data from the regressive-turbo-decoded signaling data.
Additionally, the signaling decoder 118 performs RS-decoding
as inverse processes of the transmitting system on the
separated TPC data, thereby outputting the processed data to
the baseband controller 119. Also, the signaling decoder 118
performs deinterleaving in sub-frame units on the separated
FIC data, so as to perform RS-,decoding as inverse processes
of the transmitting system on the deinterleaved FIC data,
thereby outputting the processed data to the FIC handler 121.
The FIC data being deinterleaved and RS-decoded from the
signaling decoder 118 and outputted to the FIC handler 121
are transmitted in units of FIC segments.
[0083] The FIC handler 121 receives FIC data from the
signaling decoder 118, so as to extract signaling information
for service acquisition (i.e., mapping information an
ensemble to a mobile service). In
order to do so, the FIC
handler 121 may include an FIC segment buffer, an FIC segment
parser, and an FIC chunk parser.
[0084] The FIC segment buffer buffers FIC segment groups
being inputted in M/H frame units from the signaling decoder
118, thereby outputting the buffered FIC segment groups to
the FIC segment parser. Thereafter, the FIC segment parser
extracts the header of each FIC segment stored in the FIC
segment buffer so as to analyze the extracted headers. Then,
23
ak 02726831 2010-12-02
based upon the analyzed result, the FIC segment parser
outputs the payload of the respective FIC segments to the FIC
chunk parser. The FIC chunk parser uses the analyzed result
outputted from the FIC segment parser so as to recover the
FIC chunk data structure from the FIC segment payloads,
thereby analyzing the received FIC chunk data structure.
Subsequently, the FIC chunk parser extracts the signaling
information for service acquisition. The signaling
information acquired from the FIC chunk parser is outputted
to the service manager 122.
[0085] Meanwhile, the service signaling handler 123
consists of a service signaling buffer and a service
signaling parser. Herein, the service signaling handler 123
buffers table sections of a. service signaling channel being
transmitted from the UDP datagram handler 143, thereby
analyzing and processing the buffered table sections.
Similarly, the signaling information processed by the service
signaling handler 123 is .also outputted to the service
manager 122.
(00861 The service signaling channel transferring a
service map table (SMT) section is received via the RS frame
according to one embodiment of the present invention. The RS
frame is a type of UDP/IP packet having a well-known IP
destination address and well-known destination UDP port
24
ak 02726831 2010-12-02
.-*
number. Accordingly, a receiver can process the SMT section
and therein the descriptor without separate information.
[0087] In this case, the SMT section provides signaling
information related to all services in the Ensemble including
the corresponding SMT section. Accordingly, the receiver can
access an IP stream component in wanted service using the SMT
section data and provide corresponding service to user.
[0088] The SMT section data is stored the first storage
unit 124 collected by the service manager 122. In this case,
the stored SMT section data is changed a service map format
by the service manager 122.
[0089] The service manager 122 uses the signaling
information collected from each of the FTC handler 121 and
the service signaling handler 123, so as to configure a
service map.
Thereafter, the service manager 122 uses a
service guide (SG) collected from the service guide (SG)
, handler 165 so as to draw up a program guide.
Then, the
service manager 122 controls the baseband controller 119 so
that a user can receive (or be provided with) a user-
requested mobile service by referring to the service map and
. service guide. Furthermore, the service manager 122 may also
control the receiving system so that the program guide can be
displayed on at least a portidn of the display screen based
upon the user's input.
=
CA 02726831 2010-12-02
[0090] The
first storage unit 124 stores the service map
and service guide drawn up by the service manager 122. Also,
based upon the requests from the service manager 122 and the
EPG manager 171, the first storage unit 124 extracts the
required data, which are then transferred to the service
manager 122 and/or the EPG manager 171.
[0091] The operation controller 100 stores a service map
and a service guide provided by the service manager 122.
. Moreover, the operation controller 100 extracts required data
according to a request of the service manager 122 or the EPG
manager 171 and transfers the .extracted data to the service
manager 122 or the EPG manager 171.
[0092] The operation controller 100 receives the known
data place information and TPC data, thereby transferring M/H
frame time information, information indicating whether or not
a data group exists in a selected parade, place information
of known data within a corresponding data group, power
control information, and so on to each block within the
baseband processor 110. The TPC data will be described in
detail in a later process.
[0093] Meanwhile, according to the present invention, the
transmitting system uses RS frames by encoding units. Herein,
the RS frame may be divided into a primary RS frame and a
secondary RS frame. However, according to the embodiment of
= the present invention, the primary RS frame and the secondary
26
ak 02726831 2010-12-02
=
RS frame will be divided based upon the level of importance
of the corresponding data.
[0094] The primary RS frame decoder 116 receives the data
outputted from the block decoder 115. At
this point,
' according to the embodiment of the present invention, the
primary RS frame decoder 116 receives only the mobile service
data that have been Reed-Solomon (RS)-encoded and/or cyclic
redundancy check (CRC)-encoded from the block decoder 115.
[0095]
Herein, the primary RS frame decoder 116 receives
at least one of the mobile service data, the NRT service data,
the SMT section data, OMA BCAST SG data, and not the main
service data. The primary RS frame decoder 116 performs
inverse processes of an RS frame encoder (not shown) included
in the digital broadcast transmitting system, thereby
correcting errors existing within the primary RS frame. More
specifically, the primary RS frame decoder 116 forms a
primary RS frame by grouping a plurality of data groups and,
then, correct errors in primary RS frame units. In
other
words, the primary RS frame decoder 116 decodes primary RS
frames, which are being transmitted for actual broadcast
services. The primary RS frame decoded by the primary RS
frame decoder 116 outputs to the primary RS frame buffer 131.
The primary RS frame buffer 131 buffers the primary RS frame,
and then configures an M/H TP in each row unit. The M/H TPs
of the primary RS frame outputs to the TP handler 133.
27
CA 02726831 2010-12-02
[0096] Additionally, the secondary RS frame decoder 117
receives the data outputted from the block decoder 115. At
this point, according to the embodiment of the present
invention, the secondary RS frame decoder 117 receives only
the mobile service data that have been RS-encoded and/or CRC-
encoded from the block decoder .115. Herein, the secondary RS
frame decoder 117 receives only the mobile service data and
not the main service data. The secondary RS frame decoder 117
performs inverse processes of an RS frame encoder (not shown)
included in the digital broadcast transmitting system,
thereby correcting errors existing within the secondary RS
frame. More specifically, the secondary RS frame decoder 117
forms a secondary RS frame by grouping a plurality of data
groups and, then, correct errors in secondary RS frame units.
In other words, the secondary RS frame decoder 117 decodes
. secondary RS frames, which are being transmitted for mobile
audio service data, mobile 'video service data, guide data,
and so on. The secondary RS frame decoded by the secondary RS
frame decoder 117 outputs to the secondary RS frame buffer
. 132. The secondary RS frame buffer 132 buffers the secondary
RS frame, and then configures an M/H TP in each row unit. The
M/H TPs of the secondary RS frame outputs to the TP handler
133.
[0097] The
TP handler 133 consists of a TP buffer and a TP
parser. The TP handler 133 buffers the M/H TPs inputted from
28
ak 02726831 2010-12-02
the primary RS frame buffer 131 and the secondary RS frame
buffer 132, and then extracts and analyzes each header of the
buffered M/H TPs, thereby recovering IP datagram from each
. payload of the corresponding M/H TPs. The recovered IP
datagram is outputted to the IP datagram handler 141.
[0098] The IP datagram handler 141 consists of an IP
datagram buffer and an IP datagram parser. The IP datagram
handler 141 buffers the IP datagram delivered from the TP
handler 133, and then extracts and analyzes a header of the
buffered IP datagram, thereby recovering UDP datagram from a
payload of the corresponding IP datagram. The recovered UDP
' datagram is outputted to the UDP datagram handler 143.
[0099] If
the UDP datagram is scrambled, the scrambled UDP
datagram is descrambled by the descrambler 142, and the
descrambled UDP datagram is outputted to the UDP datagram
handler 143. For example, when the UDP datagram among the
received IP datagram is scrambled, the descrambler 142
descrambles the UDP datagram by inputting an encryption key
and so on from the service protection stream handler 146, and
outputs the descrambled UDP datagram to the UDP datagram
handler 143.
[00100] The UDP datagram handler 143 consists of an UDP
datagram buffer and an UDP datagram parser. The UDP datagram
handler 143 buffers the UDP. datagram delivered from the IP
datagram handler 141 or the descrambler 142, and then
29
ak 02726831 2010-12-02
. = =
extracts and analyzes a header of the buffered UDP datagram,
thereby recovering data transmitted through a payload of the
corresponding UDP datagram. If the recovered data is an
RTP/RTCP datagram, the recovered data is outputted to the
RTP/RTCP datagram handler 144. If the recovered data is also
an NTP datagram, the recovered data is outputted to the NTP
datagram handler 145. Furthermore, if the recovered data is a
service protection stream, the recovered data is outputted to
the service protection stream handler 146. And, if the
recovered data is an ALC/LCT stream, the recovered data is
outputted to the ALC/LCT steam handler 148.
[00101] The IP datagram handler 141 and UDP datagram
handler 143 can output data including the SMT section data to
the service signaling section handler 123.
[00102] The RTP/RTCP datagram handler 144 consists of an
RTP/RTCP datagram buffer and an RTP/RTCP datagram parser. The
RTP/RTCP datagram handler 144 .buffers the data of RTP/RTCP
structure outputted from the UDP datagram handler 143, and
then extracts A/V stream from the buffered data, thereby
outputting the extracted A/V.stream to the A/V decoder 161.
[00103]
The A/V decoder 161. decodes the audio and video
streams outputted from the RTP/RTCP datagram handler 144
, using audio and video decoding algorithms, respectively. The
decoded audio and video data is outputted to the presentation
manager 170. Herein, at least one of an AC-3 decoding
ak 02726831 2010-12-02
."
algorithm, an MPEG 2 audio decoding algorithm, an MPEG 4
audio decoding algorithm, an AAC decoding algorithm, an AAC+
. decoding algorithm, an HE AAC decoding algorithm, an AAC SBR
decoding algorithm, an MPEG surround decoding algorithm, and
a BSAC decoding algorithm can be used as the audio decoding
algorithm and at least one of an MPEG 2 video decoding
. algorithm, an MPEG 4 video decoding algorithm, an H.264
decoding algorithm, an SVC decoding algorithm, and a VC-1
decoding algorithm can be used as the audio decoding
algorithm.
. [00104] The NTP datagram handler 145 consists of an NTP
datagram buffer and an NTP datagram parser. The NTP datagram
handler 145 buffers data having an NTP structure, the data
being outputted from the UDP datagram handler 143. Then, the
= NTP datagram handler 145 extracts an NTP stream from the
buffered data. Thereafter, the extracted NTP stream is
outputted to the A/V decoder 161 so as to be decoded.
[00105] The service protection stream handler 146 may
= further include a service protection stream buffer. Herein,
the service protection stream handler 146 buffers data
designated (or required) for service protection, the data
being outputted from the UDP datagram handler 143.
= Subsequently, the service protection stream handler 146
extracts required information for descrambling from the
extracted data. The information required for descrambling
31
CA 02726831 2010-12-02
=
includes a key value, such as STKM and LTKM. The information
for descrambling is stored in the second storage unit 147,
. and, when required, the information for descrambling is
outputted to the descrambler 142.
[00106] The
ALC/LCT stream 'handler 148 consists of an
ALC/LCT stream buffer and an ALC/LCT stream parser. And, the
ALC/LCT stream handler 148 buffers data having an ALC/LCT
structure, the data being outputted from the UDP datagram
handler 143. Then, the ALC/LCT stream handler 148 analyzes a
header and a header expansion of an ALC/LCT session from the
buffered data. Based upon the analysis result of the header
and header expansion of the ALC/LCT session, when the data
being transmitted to the ALC/LCT session correspond to an XML
structure, the corresponding data are outputted to an XML
' parser 150. Alternatively, when the data being transmitted
to the ALC/LCT session correspond to a file structure, the
corresponding data are outputted to a file decoder 162. At
this point, when the data that are being transmitted to the
ALC/LCT session are compressed, the compressed data are
decompressed by a decompressor 149, thereby being outputted
to the XML parser 150 or the file decoder 162.
[00107] If the data transferred through the ALC/LCT session
is compressed, the decompressor 149 decompresses the
transferred data and outputs the decompressed data to the
file decoder 162.
.32
CA 02726831 2010-12-02
[00108] The FDT handler 151 analyzes and processes a file
description table of a FLUTE protocol, which is transmitted
in an XML structure through the ALC/LCT session.
[00109] The
SG handler 165 collects and analyzes the data
designated for a service guide, the data being transmitted in
an XML structure, thereby outputting the analyzed data to the
service manager 122.
[00110] The
file decoder 162 decodes the data having a file
structure and being transmitted through the ALC/LCT session,
thereby outputting the decoded data to the middleware engine
164 or storing the decoded data in a third storage unit 163.
Herein, the middleware engine 164 translates the file
structure data (i.e., the application) and executes the
translated application.
Thereafter, the application may be
outputted to an output device, such as a display screen or
speakers, through the application presentation manager 170.
According to an embodiment of the present invention, the
middleware engine 164 corresponds to a JAVA-based middleware
engine.
[00111] Based upon a user-input, the EPG manager 171
receives EPG data either through the service manager 122 or
through the SG handler 165, so as to convert the received EPG
data to a display format, thereby outputting the converted
data to the presentation manager 170.
33
CA 02726831 2010-12-02
[00112] The application manager 172 performs overall
management associated with the processing of application data,
which are being transmitted in object formats, file formats,
and so on. Furthermore, based upon a user-command inputted
through the UI manager 173, the operation controller 100
controls at least one of the service manager 122, the EPG
manager 171, the application manager 172, and the
presentation manager 170, so as to enable the user-requested
function to be executed. The
UI manager 173 transfers the
user-input to the operation controller 100 through the UI.
[00113]
Finally, the presentation manager 170 provides at
least one of the audio and video data being outputted from
the A/V decoder 161 and the EPG data being outputted from the
EPG manager 171 to the user through the speaker and/or
display screen.
[00114] Regarding the present, invention, the NRT service is
include d the mobile broadcast service. The NRT service is
signaled by the SMT section. In this case, the SMT section,
for example, is extracted from the primary RS frame decoder
116 or the second RS frame decoder 117. The extracted SMT
section data is processed by IP module through the IP
adaptation module. At this time, the IP datagram including
the extracted SMT section is processed by IP datagram handler
141. And the UDP datagram is processed by the UDP datagram
handler 143. The UDP datagram handler 143 extracts the SMT
34
CA 02726831 2010-12-02
section data from the processed UDP datagram. The extracted
SMT section data is processed by service signaling section
handler 123. Moreover, the FDT data and the NRT service data
except the SMT section data may provide an NRT service
processed by the mobile broadcast receiver through ALC/LCT
processor.
A description for relations among NRT service, content item
and file
[00115] FIG. 3 is an exemplary diagram explaining relations
between an NRT service, content items and files.
[00116] Referring to FIG. 3, an NRT service can include one
or more content items. And, each of the content items can
include one or more files. And, each of the content items is
an independently playable entity and may correspond to a
program or an event in a real time broadcast. Therefore, the
NRT service means a group that is serviceable with a
. combination of the above content items. And, the NRT service
corresponds to a channel concept in real time.
[00117] In a mobile service environment-, since signaling
information of received mobile NRT service data is
' insufficient, it is difficult for a receiver to properly
process a mobile NRT service, even when the mobile NRT
service is received.
CA 02726831 2010-12-02
[00118] In order for a receiver to properly process the
above NRT service, signaling for the corresponding NRT
service is required. The present invention intends to
properly process an NRT service received by a receiver by
defining and providing the signaling information. Besides,
details of the signaling information shall be described in
the description of the corresponding part.
[00119] Hereinafter, in the present specification, the use
of a Service Map Table (SMT) and an Open Mobile Alliance
(OMA) Mobile Broadcast Services Enabler Suite (BCAST) Service
Guide (SG) for signaling of a mobile NRT service will be
described.
[00120] First, the receiver may, for example, identify
whether a mobile service is a mobile NRT service by referring
to a service category field in the SMT. One or more content
items in the mobile NRT service may be identified using a
content id field in a File Description Table (FDT) and a
content identifier in the OMA BCAST SG. In
addition, the
mobile NRT service may be, for example, identified using a
service identifier in the OMA BCAST SG and NRT service id in
the SMT.
[00121] The signaling information is defined in different
formats. Accordingly, in the present specification, a method
of mapping identifiers in different formats is also provided
in order to enable the receiver to process the signaling
36
ak 02726831 2010-12-02
information. Accordingly, the receiver can properly process
the received NRT service.
[00122] The mobile NRT service is transmitted in a FLUTE
session, and FDT information is extracted from the FLUTE
session. The content id in the extracted EDT information may
be mapped to the content identifier of the OMA BCAST SG, and
NRT service content selected by a user or the like may be
checked and received. The
mapping method is given below.
For example, files configuring a content item are identified
using a Transport Object Identifier (TOT) and Content-
Location field defined in the .EDT within the FLUTE session,
and the connection of the TOT or the Content-Location and the
content item may be accomplished by mapping the content ID
field of the EDT to the content identifier field of the OMA
BCAST SG. Only
the concept .of the present invention is
described herein and the detailed description thereof will be
, described later in detail.
A protocol for a Mobil NRT service
[00123] First of all, NRT services can be mainly
categorized into a fixed NRT service and a mobile NRT service
according to a type of acquiring an IP datagram. In the
following description, the mobile NRT service is specified
for clarity and convenience of explanation.
3.7
ak 02726831 2010-12-02
[00124] FIG. 4 is a diagram for a protocol stack of a
mobile NRT service configured according to an embodiment of
the present invention.
[00125] In FIG. 4, an IP datagram containing signaling
information may be transmitted without using an MPEG-2 TS
format, by inserting an adaption layer between an IP layer
and a physical layer.
[00126] In FIG. 18, an NRT service for a mobile service is
packetized according to a User Datagram Protocol (UDP) scheme
in the IP layer, and a UDP packet is packetized again
according to an IP scheme, thereby obtaining UDP/IP packet
data. In
the present specification, the packetized UDP/IP
. packet data is referred to as an IP datagram for simplicity.
In addition, a signaling information channel containing an
SMT is also packetized according to a UDP scheme and a UDP
packet is packetized again according to an IP scheme, thereby
. obtaining UDP/IP packet data.
[00127] In FIG. 4, an OMA BCAST SG and NRT content
items/files are packetized according to a FLUTE scheme and
are packetized again according to an Asynchronous Layered
Coding/Layered Coding Transport (ALC/LCT) scheme. An ALC/LCT
packet is packetized again according to an IP scheme, thereby
obtaining ALC/LCT/UDP/IP packet data.
[00128] Moreover, an RS frame including the packetized IP
= datagram is generated. The generated RS frame is transmitted
38
ak 02726831 2010-12-02
to a receiving system modulated by pre-defined transmission
method (e.g. VSB).
A Structure of Data Format for the Mobile NRT service
[00129] Meanwhile, the data structure used in the mobile
broadcasting technology according to the embodiment of the
present invention may include a data group structure and an
RS frame structure, which will now be described in detail.
. [00130]
FIG. 5 illustrates an exemplary structure of a data
group according to the present invention.
FIG. 5 shows an
example of dividing a data group according to the data
structure of the present invention into 10 M/H blocks (i.e.,
M/H block 1 (B1) to M/H block 10 (B10)). In
this example,
each M/H block has the length of 16 segments. Referring to
FIG. 5, only the RS parity data are allocated to portions of
the 5 segments before the M/H block 1 (B1) and the 5 segments
' following the M/H block 10 (B10). The
RS parity data are
excluded in regions A to D of the data group.
More
specifically, when it is assumed that one data group is
divided into regions A, B, C, and D, each M/H -block may be
= included in any one of region A to region D depending upon
the characteristics of each M/H block within the data group.
[00131] Herein, the data group is divided into a plurality
of regions to be used for different purposes.
More
specifically, a region of the main service data having no
3'9
ak 02726831 2010-12-02
interference or a very low interference level may be
considered to have a more resistant (or stronger) receiving
performance as compared to regions having higher interference
levels.
Additionally, when using a system inserting and
transmitting known data in the data group, wherein the known
data are known based upon an agreement between the
transmitting system and the receiving system, and when
consecutively long known data are to be periodically inserted
in the mobile service data, the known data having a
predetermined length may be periodically inserted in the
region having no interference from the main service data
(i.e., a region wherein the main service data are not mixed).
However, due to interference from the main service data, it
is difficult to periodically insert known data and also to
insert consecutively long known data to a region having
interference from the main service data.
(00132]
Referring to FIG. 5, M/H block 4 (B4) to M/H block
7 (B7) correspond to regions without interference of the main
service data. M/H
block 4 (B4) to M/H block 7 (B7) within
the data group shown in FIG. 2 correspond to a region where
no interference from the main service data occurs. In this
example, a long known data sequence is inserted at both the
beginning and end of each M/H block. In the description of
the present invention, the region including M/H block 4 (B4)
to M/H block 7 (B7) will be referred to as "region A
=
" CA 02726831 2010-12-02
(=B4+B5+B6+B7)". As
described above, when the data group
includes region A having a long known data sequence inserted
at both the beginning and end of each M/H block, the
receiving system is capable of performing equalization by
using the channel information that can be obtained from the
known data. Therefore, the strongest equalizing performance
may be yielded (or obtained) from one of region A to region D.
[00133] In
the example of the data group shown in FIG. 2,
M/H block 3 (B3) and M/H block 8 (B8) correspond to a region
having little interference from the main service data.
Herein, a long known data sequence is inserted in only one
, side of each M/H block B3 and B8. More specifically, due to
the interference from the main service data, a long known
data sequence is inserted at the end of M/H block 3 (B3), and
another long known data sequence is inserted at the beginning
. of M/H block 8 (88). In
the present invention, the region
including M/H block 3 (B3) and M/H block 8 (B8) will be
referred to as "region B (=B3+B8)". As described above, when
the data group includes region B having a long known data
sequence inserted at only one side (beginning or end) of each
M/H block, the receiving system is capable of performing
equalization by using the channel information that can be
obtained from the known data.
Therefore, a stronger
' equalizing performance as compared to region C/D may be
yielded (or obtained).
41
ak. 02726831 2010-12-02
[00134]
Referring to FIG. 5, M/H block 2 (B2) and M/H block
9 (29) correspond to a region having more interference from
the main service data as compared to region B. A long known
data sequence cannot be inserted in any side of M/H block 2
(B2) and M/H block 9 (B9). Herein, the region including M/H
block 2 (B2) and M/H block 9 (B9) will be referred to as
"region C (=B2+B9)". Finally, in the example shown in FIG. 2,
M/H block 1 (B1) and M/H block 10 (B10) correspond to a
region having more interference from the main service data as
compared to region C. Similarly, a long known data sequence
cannot =be inserted in any side of M/H block 1 (B1) and M/H
block 10 (B10).
Herein, the region including M/H block 1
(B1) and M/H block 10 (B10) will be referred to as "region D
(=B1+B10)". Since
region C/D is spaced further apart from
the known data sequence, when the channel environment
undergoes frequent and abrupt changes, the receiving
performance of region C/D may be deteriorated.
[00135] Additionally, the data group includes a signaling
information area wherein signaling information is assigned
(or allocated). In
the present invention, the signaling
information area may start from the 1st segment of the 4th M/H
block (B4) to a portion of the 2nd segment. According to an
embodiment of the present invention, the signaling
information area for inserting signaling information may
start from the 1st segment of. the 4th M/H block (B4) to a
42
ak. 02726831 2010-12-02
portion of the 2nd segment. More specifically, 276(=207+69)
bytes of the 4th M/H block (B4) in each data group are
assigned as the signaling information area. In other words,
the signaling information area consists of 207 bytes of the
1st segment and the first 69 bytes of the 2'd segment of the
4th M/H block (B4). The 1st segment of the 4" M/H block (B4)
corresponds to the 17th or 173rd segment of a VSB field.
[00136] Herein, the signaling data transmitted through the
signaling information area may be identified by two different
types of signaling channel data: a transmission parameter
channel (TPC) data and a fast information channel (FIC) data.
[00137] Also, the TPC data includes parameters that are
mostly used in a physical layer module. And, since the TPC
data are transmitted without being interleaved, the TPC data
may be accessed by slot unit in the receiving system. The
FIC data are provided in order to enable the receiving system
to perform fast service acquiSition.
Herein, the FIC data
include cross layer information between a physical layer and
. an upper layer. The
FIC data are interleaved in sub-frame
units and then transmitted.
[00138] For example, when the data group includes 6 known
data sequences, as shown in FIG. 2, the signaling information
area is located between the first known data sequence and the
second known data sequence.
More specifically, the first
known data sequence is inserted in the last 2 segments of the
43
CA 02726831 2010-12-02
=
3rd M/H block (B3), and the second known data sequence in
inserted in the 2hd and 3'd segments of the 4th M/H block (B4).
Furthermore, the 3rd to 6th known data sequences are
respectively inserted in the last 2 segments of each of the
4th, 5th, 6th, and 7th M/H blocks. (B4, B5, BE, and B7) . The
1st
and 3rd to 6th known data sequences are spaced apart by 16
segments.
A RS Frame including the Mobile, NRT service
[00139] FIG. 6 is a view showing the structure of an RS
frame containing a mobile NRT.service configured according to
an embodiment of the present 'invention.
[00140] The RS frame is received for each M/H frame in a
condition where the receiving system is switched to a time-
slicing mode.
Each RS frame includes IP streams of each
mobile service data or signaling data, and service map table
(SMT) section data may exist in all RS frames. The
SMT
section data may be an IP stream type, or a different data
. type. The RS frame data is allocated to region corresponding
to a plurality of data groups, and transmitted to a receiving
system.
[00141] The RS frame according to the embodiment of the
present invention consists of at least one M/H transport
packet (TP). Herein, the M/H TP includes an M/H header and
an M/H payload.
,44
CA 02726831 2010-12-02
[00142] The M/H payload may include mobile service data as
well as signaling data.
More specifically, an M/H payload
= may include only mobile service data, or may include only
signaling data, or may include both mobile service data and
signaling data. In this case, the mobile service data can
include an NRT service according to the present invention.
= [00143] Also, when the M/H TP includes a second M/H header,
this indicates that the M/H payload includes both the
signaling data and the mobile service data.
Finally, when
M/H TP includes a third M/H header, this indicates that the
M/H payload includes only the mobile service data. In the
example shown in FIG. 6, the RS frame is assigned with an IP
datagram (IP datagram 1) for a SMT and IP datagrams (IP
datagram 2 and IP datagram 3) for two service types.
A structure of transmission data
[00144] FIG. 7 is a view showing an example of a structure
of an M/H frame for transmitting and receiving mobile service
data according to the present invention.
[00145] In the example shown in FIG. 4, one M/H frame
consists of 5 sub-frames, wherein each sub-frame includes 16
slots. In this case, the M/H frame according to the present
invention includes 5 sub-frames and 80 slots.
Also, in a
packet level, one slot is configured of 156 data packets
(i.e., transport stream packets), and in a symbol level, one
= 45
CA 02726831 2010-12-02
slot is configured of 156 data segments. Herein, the size of
one slot corresponds to one half (1/2) of a VSB field. More
specifically, since one 207-byte data packet has the same
amount of data as a data segment, a data packet prior to
being interleaved may also be used as a data segment. At
this point, two VSB fields are grouped to form a VSB frame.
[00146] FIG.
8 illustrates an exemplary structure of a VSB
frame, wherein one VSB frame consists of 2 VSB fields (i.e.,
an odd field and an even field).
Herein, each VSB field
includes a field synchronization segment and 312 data
segments. The
slot corresponds to a basic time unit for
multiplexing the mobile service data and the main service
data.
[00147] Herein, one slot may either include the mobile
service data or be configured only of the main service data.
If the first 118 data packets within the slot correspond to a
data group, the remaining 38 data packets become the main
service data packets. In another example, when no data group
exists in a slot, the corresponding slot is configured of 156
main service data packets.
[00148] Meanwhile, the mobile service data within one RS
frame may be assigned either to all of regions A/B/C/D within
the corresponding data group, or to at least one of regions
A/B/C/D. In
the embodiment Of the present invention, the
mobile service data within one RS frame may be assigned
46
CA 02726831 2010-12-02
either to all of regions A/B/C/D, or to at least one of
regions A/9 and regions C/D. If the mobile service data are
assigned to the latter case (i.e., one of regions A/B and
regions C/D), the RS frame being assigned to regions A/B and
the RS frame being assigned to regions C/D within the
corresponding data group are different from one another.
[00149] According to the embodiment of the present
invention, the RS frame being assigned to regions A/9 within
the corresponding data group will be referred to as a
"primary RS frame", and the RS frame being assigned to
regions C/D within the corresponding data group will be
referred to as a "secondary RS frame", for simplicity. Also,
the primary RS frame and the secondary RS frame form (or
configure) one parade.
More specifically, when the mobile
service data within one RS frame are assigned either to all
of regions A/B/C/D within the corresponding data group, one
parade transmits one RS frame. Conversely, when the mobile
' service data within one RS frame are assigned either to at
least one of regions A/B and regions C/D, one parade may
transmit up to 2 RS frames. More specifically, the RS frame
mode indicates whether a parade transmits one RS frame, or
whether the parade transmits two RS frames.
Such RS frame
mode is transmitted as the TPC data. Table 1 below shows an
example of the RS frame mode. The following Table 4 is an
exemplary diagram for the RS frame mode.
47
ak 02726831 2010-12-02
[Table 1]
Value Application Identifier Format
Ox0000 DASE application
Ox0001 ATSC reserved
0x0002 ATSC A/92 Application
0x0003 NRT Application
0x0004-0x7FFF ATSC reserved
Ox8000-0xFFFF User private
[00150] Table 1 illustrates an example of allocating 2 bits
in order to indicate the RS frame mode. For
example,
referring to Table 1, when the RS frame mode value is equal
. to '00', this indicates that one parade transmits one RS
frame. And, when the RS frame mode value is equal to '01',
this indicates that one parade transmits two RS frames, i.e.,
the primary RS frame and the secondary RS frame. More
= specifically, when the RS frame mode value is equal to '01',
data of the primary RS frame for regions A/B are assigned and
transmitted to regions A/B of the corresponding data group.
Similarly, data of the secondary RS frame for regions C/D are
= assigned and transmitted to regions C/D of the corresponding
data group.
[00151] As described in the assignment of data groups, the
parades are also assigned to be spaced as far apart from one
another as possible within the sub-frame.
Thus, the
receiving system can be capable of responding promptly and
effectively to any burst error that may occur within a sub-
frame. Furthermore, the method of assigning parades may be
48
CA 02726831 2010-12-02
identically applied to all M/H frames or differently applied
to each M/H frame.
According to the embodiment of the
present invention, the parades may be assigned differently
for each M/H frame and identically for all sub-frames within
an M/H frame. More specifically, the M/H frame structure may
vary by M/H frame units.
Thus, an ensemble rate may be
adjusted on a more frequent and. flexible basis.
[00152] That is, the concept of an M/H ensemble is applied
in the embodiment of the present invention, thereby defining
a collection (or group) of services.
Each M/H ensemble
carries the same QoS and is coded with the same FEC code.
Also, each M/H ensemble has the same unique identifier (i.e.,
ensemble ID) and corresponds to consecutive RS frames.
[00153] FIG. 9 illustrates a data transmission structure in
a physical layer according to, an embodiment of the present
invention. More specifically, FIG. 9 shows an example of FIC
, data being included in each data group and transmitted. As
described above, an M/H frame for approximately 0.968 seconds
is divided into 5 sub-frames, wherein data groups
corresponding to multiple ensembles exist in combination
. within each sub-frame. Also, the data groups corresponding
to each ensemble are interleaved in M/H frame units, so as to
configure an RS frame belonging to one ensemble. In FIG. 9,
2 ensembles (wherein NoG=4 and N0G=3) exist in each sub-frame.
. Furthermore, a predetermined portion (e.g., 37 bytes/data
4.9
ak 02726831 2010-12-02
group) of each data group is used for the purpose of
separately delivering encoded FTC data apart from the RS
frame data channel. The
FTC region assigned to each data
group consists of one FTC segment. Herein, each of the FTC
segments is interleaved in sub-frame units. For example, RS-
encoding and SCCC encoding processes are applied to the RS
frame data, and RS encoding and PCCC encoding processes are
applied to the FTC data. Also, as well as the FTC data, the
RS encoding and PCCC encoding processes are applied to the
TPC data. More specifically, (187+P,187)-RS encoding process
is applied to the RS frame data, (51,37)-RS encoding process
is applied to the FTC data, and (18,10)-RS encoding process
is applied to the TPC. Herein, P is the number of parity
bytes.
Hierarchical signaling structure
, [00154] FIG. 10 illustrates a hierarchical signaling
structure according to an embodiment of the present invention.
As shown in FIG. 10, the mObile broadcasting technology
according to the embodiment of the present invention adopts a
. signaling method using FIC and SMT (Service Map Table). In
the description of the present invention, the signaling
structure will be referred to as a hierarchical signaling
structure.
ak. 02726831 2010-12-02
[00155] More specifically, FIG. 10 illustrates a
hierarchical signaling structure that provides data required
for service acquisition through an FIC chunk and a service
map table (SMT), among IP-level mobile service signaling
channels. As shown in FIG. 10, the FIC chunk uses its fast
characteristic, so as to deliver a mapping relation between a
service and an ensemble to the receiving system.
More
specifically, the FIC chunk quickly locates (or finds) an
ensemble that can deliver a service requested by the
receiving system, thereby providing the receiving system with
signaling data that can enable the receiving system to
swiftly receive RS frames of a respective ensemble.
A Service Map Table (SMT)
[00156] Next, signaling information of NRT services
transmitted through the IP datagram in the RS frame of FIG. 6
will be described. Hereinafter, the SMT, which is one type
of signaling information, will be described.
[00157] FIGs. 11 and 12 are views showing the bitstream
syntax of an SMT configured according to an embodiment of the-
.
present invention.
[00158] In
FIGs. 11 and 12, 'shown an example that the SMT
is written in an MPEG format, by which the present invention
is non-limited. Alternatively, the SMT can be defined in a
different format.
51
CA 02726831 2010-12-02
[00159] The SMT describes service information and IP access
information in an ensemble in which the SMT is transmitted,
and also provides broadcast stream information of a service
. using Transport Stream ID which is an identifier of a
broadcast stream to which each service belongs. The
SMT
according to the present embodiment contains description
information of each mobile service in a single MH ensemble,
' and other supplementary information may be contained in a
descriptor section.
[00160] Referring to FIGs. 11 and 12, an SMT section may be
transmitted in a state of being included in an RS frame in an
IP stream format. In this case, the RS frame decoders of the
below-described receiver decode an input RS frame and output
the decoded RS frame to RS frame handlers. Each of the RS
frame .handlers divides the input RS frame into rows,
configures an MH TP, and outputs the MH TP to an MH TP
handler.
[00161] An example of the fields that may be transmitted
through. the SMT will now be described.
=
[00162] A table id file is an 8-bit unsigned integer number
that indicates the type of table section being defined in
Service Map Table (SMT).
[00163] A section_syntax_indicator field (1-bit) shall be
set to '0' to always indicate that this table is derived from
the short form of the MPEG-2 private section table.
52
ak 02726831 2010-12-02
[00164] A private indicator field (1-bit) shall be set to
'1' .
[00165] A section length field (12-bit)
specifies the
number of remaining bytes this table section immediately
following this field. The value in this field shall not
exceed 4093 ('OxFFD1).
[00166] A table id extension field (16-hit) is
table-
dependent. It shall be considered to be logically part of the
table id field providing the scope for the remaining fields.
Herein, the table _ id_ extension field may include a
SMT protocol version field.
[00167] A SMT_protocol version field is an 8-bit unsigned
integer field whose function is to allow, in the future, this
NRT Service Map Table to carry parameters that may be
structured differently than those defined in the current
protocol. At present, the value for the SMT_protocol_version
shall be zero. Non-zero values .of SMT_protocol_version may be
used by a future version of this standard to indicate
structurally different tables.
[00168] An ensemble id field is an 8-bit unsigned integer
field in the range Ox00 to OX3F shall be the Ensemble ID
associated with this MH Ensemble. The value of this field
shall be derived .from the parade_id carried from the baseband
processor of MH physical layer subsystem, by using the
parade id of the associated MH Parade for the least
53
CA 02726831 2010-12-02
significant 7 bits, and using' '0' for the most significant
bit when the MH Ensemble is carried over the Primary RS frame,
. and using '1' for the most significant bit when the MH
Ensemble is carried over the Secondary RS frame.
[00169] A version number field (5 bits) represents version
number of the SMT.
. [00170] A current next indicator field is a one-
bit
indicator, which when set to '1' shall indicate that the
Service Map Table sent is currently applicable. When the bit
is set to '0', it shall indicate that the table sent is not
' yet applicable and will be the next table to become valid.
This standard imposes no requirement that next tables (those
with current next indicator set to '0') must be sent. An
update to the currently applicable table shall be signaled by
incrementing the version number field.
[00171] A section number field (8-bit) shall give the
section number of this NRT Service Signaling table section.
The section number of the first section in an NRT Service
Signaling table shall be '0x00'. The section number shall be
incremented by 1 with each additional section in the NRT
Service Signaling table.
[00172] A last section number field (8-bit) shall give the
number of the last section (i.e., the section with the
highest section number) of the Service Signaling table of
which this section is a part.
= 54
CA 02726831 2010-12-02
[00173] A num services field (8 bit) specifies the number
of services in this SMT section.
[00174] According to one embodiment of the present
invention, the NST provides information for a plurality of
components using 'for' loop. Field information related to
each service is provided as follows.
[00175] A service id is a. 16-bit unsigned integer number
that shall uniquely identify this M/H Service within the
scope of this MH Broadcast. The MH_service_id of a service
shall not change throughout the life of the service. To avoid
confusion, it is recommended that if a service is terminated,
then the MH service id for the service should not be used for
another service until after a suitable interval of time has
elapsed.
[00176] A multi ensemble service field
is a two-bit
enumerated field that shall identify whether the M/H Service
is carried across more than one M/H Ensemble. Also, this
field shall identify whether or not the M/H Service can be
rendered only with the portion of M/H Service carried through
this. M/H Ensemble.
=
[00177] A MH service status field is a 2-bit enumerated
field that shall identify the status of this M/H Service. The
most significant bit shall indicate whether this M/H Service
is active (when set to '1') or 'inactive (when set to '0') and
the least significant bit shall indicate whether this M/H
. 55.
CA 02726831 2010-12-02
Service is hidden (when set to '1') or not (when set
to '0'). Hidden services are normally used for proprietary
applications, and ordinary receiving devices should ignore
them.
[00178] A SP indicator field (1-bit) indicate, when set,
that service protection is applied to at least one of the
components needed to provide a meaningful presentation of
this M/H Service.
[00179] A short service name length field is a three-bit
, unsigned integer that shall indicate the number of byte pairs
in the short service name field. This value is shown as m in
the No. of Bits column for the short service name field.
When there is no short name of this M/H service, the value of
, this field shall be '0'.
[00180] A short service name field is the short name of the
M/H Service, each character of' which shall be encoded. When
there is an odd number of bytes in the short name, the second
. byte of the last of the byte pair per the pair
count indicated by the short service name length field
shall contain '0x001.
[00181] An MH service category field is a 6-bit enumerated
= type field that shall identify the type category of service
carried in this M/H Service as defined in Table 5. When the
value of this field is set to the value which is indicated
Informative only, the value of this field shall be
56
= CA 02726831 2010-12-02
treated as an informative description to the category of
service, and the receiver is required to examine the
component level descriptors() of the SMT-MH to identify the
actual category of service carried through this M/H Service.
For services that have a video and/or audio component, they
shall have an NTP timebase component.
[Table 2]
Value Encapsulated Protocol
Ox00 ot in a MPEG-2 Transport Stream
Asynchronous non-flow controlled scenario of the DSM-
Ox01 CC
Download protocol encapsulated in DSM-CC sections
Ion-streaming Synchronized Download
protocol
0x02 encapsulated
in DSM-CC sections
0x03 Asynchronous multiprotocol datagrams in Addressable
Sections using LLC/SNAP header
0x04 Asynchronous IP datagrams in Addressable Sections
0x05 Synchronized streaming data encapsulated in PES
0x06 Synchronous streaming data encapsulated in PES
O x07 Synchronized streaming multiprotocol datagrams in PES
sing LLC/SNAP header
Synchronous streaming multiprotocol datagrams in PES
Ox08 using
LLC/SNAP header
0x09 Synchronized streaming IP datagrams in PES
Ox0A Synchronous streaming IP datagrams in PES
Ox0B Proprietary Data Piping
Ox0C SCTE DVS 051 asynchronous protocol [19]
Ox0D Asynchronous carousel scenario of the DSM-CC Download
protocol encapsulated in DSM-CC sections
Ox0E Reserved for harmonization with another standard body
Ox0E-
ATSC reserved
Ox7F
Ox80-
OXff User defined
[00182] If the value of the field is, for example, '0x0E',
it can be seen that the mobile service is a mobile NRT
service.
Accordingly, the receiver determines that the.
57
CA 02726831 2010-12-02
mobile service is an NRT service if the value of the
MH service category field is '0x0E' and, as a result, should
=
check the component descriptor of a component level
containing information about a FLUTE session in which the
identified NRT service is transmitted. In
the checking of
component descriptor, if the value of the component_type
field in the descriptor is '38', information about the FLUTE
session received by component data is extracted.
[00183] A num components field (5-bit) specifies the number
, of IP stream components in this M/H Service.
[00184] An IP version flag field is a 1-bit indicator,
which when set to 0 shall indicate that source IP address,
_ _
MH service destination IP address, and
_ _
component_destination_IP_address fields are IPv4 addresses.
The value of 1 for this field is reserved for possible future
indication that
source IP address,
_ _
MH service destination IP _address, and
_
component_destination_IP address fields are. for IPv6. Use of
IPv6 addressing is not currently defined.
[00185] A source IP address flag field is a 1-bit Boolean
_ _
flag that shall indicate, when set, that a source IP address
. value for this M/H Service is present to indicate a source
specific multicast.
[00186] A MH service destination IP address flag field is a
1-bit Boolean flag that indicates, when set to 1, that a
58
= CA 02726831 2010-12-02
MH service destination IP address value is present, to serve
_ _
as the default IP address for the components of this M/H
Service.
[00187] A source IP address field shall be present if the
_ _
source IP address flag is set to 1 and shall not be present
_ _
if the source IP address flag is set to 0. If present, this
_ _
field shall contain the source IP address of all the IP
datagrams carrying the components of this M/H Service. The
conditiOnal use of the 128 bit-long address version of this
field is to facilitate possible use of IPv6 in the future,
although use of IPv6 is not currently defined.
[00188] A NH service destination IP address field shall be
_ _
present if the MH_service_destination_IP_address_flag is set
to 1 and shall not be present if the
NH service destination IP address flag is set to 0. If this
_ _ . _
NH service destination IP address is not present, then the
_ _
component destination IP address field shall be present for
_ _
each component in the num components loop. The conditional
use of the 128 bit-long address version of this field is to
facilitate possible use of IPv6 in the future,
although use of IPv6 is not currently defined.
[00189] According to an embodiment of the present invention,
the SMT provides information for a plurality of components
using a 'for' loop.
59
CA 02726831 2010-12-02
[00190] An essential component indicator field is a one-bit
indicator which, when set to 1, shall indicate that this
component is an essential component for the M/H Service.
Otherwise, this field indicates that this component is an
optional component.
[00191] A component destination IP address flag field is a
_ _
1-bit Boolean flag that shall 'indicate, when set to 1, that
the component destination_IP_address is present for this
=, component.
[00192] A port_num_count field shall indicate the number of
destination UDP ports associated with this UDP/IP stream
component. The values of the destination UDP port numbers
. shall start from the component_destination_UDP port num field
and shall be incremented by one, except in the case of RTP
streams, when the destination UDP port numbers shall start
from the component_estination_UPD_port_num field and shall be
. incremented by two, to allow for the RTCP streams associated
with the RTP streams.
[00193] A component destination UDP port num field (16-bit
unsigned integer) represents the destination 'UDP port number
' for this UDP/IP stream component. For RTP streams, the value
of component_estination_UDP port num shall be even, and the
next higher value shall represent the destination UDP port
number of the associated RTCP stream.
CA 02726831 2010-12-02
[00194] A component destination IP address field shall be
_ _
present if the component_destination_IP address flag is set
to 1 and shall not be present if the
component_destination_IP_address_flag is set to 0. When this
field is present, the destination address of the IP datagrams
carrying this component of the NH Service shall match the
address in this field. When this field is not present, the
destination address of the IP datagrams carrying this
component shall match the address in the
NH service destination IP address field. The conditional use
_ _
of the 128 bit-long address version of this field is to
facilitate possible use of IPv6 in the future, although use
of IPv6 is not currently defined.
[00195] A num component level descriptors field (4 bit)
specifies the number of component level descriptors for this
component.
[00196] A component level descriptor() field may have one
or more descriptors providing additional information for this
IP stream component, may be included.
[00197] A num MH service level descriptors field (4 bit)
_ _ _ _
specifies the number of service level descriptors for this
=
service.
[00198] A NH service level descriptor() has zero or more
, descriptors providing additional information for this M/H
Service, may be included.
61
CA 02726831 2010-12-02
[00199] A num ensemble level descriptors field (4
bit)
specifies the number of ensemble level descriptors for this
ensemble.
, [00200] An ensemble level descriptor() is zero or more
descriptors providing additional information for the M/H
Ensemble which this SMT-MH desci.ibes, may be included.
[00201] The Source IP address becomes a source IP address
_ _
. of the same server for transmitting all the channels of the
FLUTE session if the service is an NRT service.
[00202] The MR service destination IP Adress is signaled if
_ _
a destination IP address having the session level of this
FLUTE session is present.
[00203] The component may be mapped to a channel in the
FLUTE session, and a separate destination IP address
(different from an IP address signaled in the session units)
' may be signaled through component destination IP address
_ _
according to channels. In
addition, a destination port
number may be signaled
through
component_destination_UDP port_num, and the destination port
number started from component_destination_UDP_port_num may be
further specified through port_num count.
An OMA-BCAST Service Guide
[00204] FIG. 13 illustrates the structure of a service
guide according to the present invention.
62
CA 02726831 2010-12-02
[00205] The provisioning group corresponds to a group
providing information on the fees charged for receiving
services. Herein, the provisioning group includes a purchase
item fragment, a purchase data fragment, and a purchase
channel fragment. The
core group corresponds to a group
providing information on the service itself.
Herein, the
core group includes a service fragment, a schedule fragment,
and a content fragment. The access group includes an access
fragment and a session description fragment. In addition to
the above-described groups, =the service guide may also
include a previewData fragment and an interactiveData
fragment. The arrows shown in FIG. 13 indicate the reference
relation between each fragment.
According to the example
shown in FIG. 13, the schedule fragment, the content fragment,
the purchase item fragment, and the access fragment may refer
to the service fragment. And,
the schedule fragment may
refer the service fragment and the content fragment. The
numbers shown above each arrow in FIG. 13 respectively
indicate the available number of lower-level unit information.
Also, these numbers indicate the available number of
fragments.
[00206] The essential fragments among the above-mentioned
fragments will now be described in detail.
63
CA 02726831 2010-12-02
[00207] The service fragment includes information on a
service provided to a user (e.g., information on a service
such as a conventional television channel).
[00208] The content fragment includes metadata on the
corresponding content. For example, a content type, such as
A/V data, text data, image data, may be included in the
content fragment.
[00209] Also, the NRT service guide data is acquired from
the service fragment, the schedule fragment and the content
fragment. In this case, the acquired NRT service guide data
may include content version, content_id, content available
time and so on.
[00210] The schedule fragment includes schedule information
on a single content within the provided service. For example,
a broadcast time of the corresponding content may correspond
to the schedule information.
[00211] The purchase item fragment includes item
information associated with purchasing.
, [00212] The purchase data fragment includes information
associated with the purchase of a service, which may be
purchased by the user. The
purchase channel fragment
indicates an interface used by the user or a terminal in
= order to communicate with a purchase system. The purchase
channel fragment includes one of a parameter associated with
64
CA 02726831 2010-12-02
,6
the purchase system and information on managing a purchase
channel.
. [00213] The access fragment includes information associated
with accessing a service or content.
A Mobile NRT service signaling architecture
' [00214] The signaling of information about individual M/H
NRT content items is done at two levels:
[00215] First, the File Delivery Table (FDT) of the FLUTE
sessions used to deliver the items lists all the content
items and gives their sizes, data types, and other
information relevant to the acquisition of the items.
[00216] Second, the OMA BCAST Service Guide (SG) gives more
detailed descriptive information about the items and their
delivery schedules).
An NRT component descriptor()
[00217] Content items/files
for an NRT service are
transferred through FLUTE and corresponding FLUTE session
information is signaled using access information in the SMT
table.
[00218] FIG. 14 is an exemplary diagram for a bit-stream
syntax of NRT_component_descriptor() configured according to
one embodiment of the present invention.
CA 02726831 2010-12-02
[00219] An NRT component descriptor() shall appear in the
component descriptor loop of each component of each NRT
Service in the SMT and all parameters in the descriptor shall
correspond to the parameters in use for that component of the
NRT Service.
[00220] In the following description, each field carried on
NRT component descriptor shown in FIG. 13 is described.
[00221] A descriptor tag field (8-bit unsigned integer)
shall have the value, identifying this descriptor as the
NRT component descriptor.
[00222] A descriptor length field (8-bit unsigned integer)
shall specify the length (in. bytes) immediately following
this field up to the end of this descriptor.
, [00223] A component_type field (7-bit) shall identify the
encoding format of the component. The value may be any of the
values assigned by IANA for the payload_type of an RTP/AVP
stream [10], or it may be any of the values in Table 3
assigned by this document, or it may be a "dynamic value"
within the range of 96 to127. For components consisting of
media carried via RTP, the value of this -field shall match
the value in the payload_type field in the RTP header of the
. IP stream carrying this component.
[00224] Note that additional values of the component_type
field within the range of 43 to 71 can be defined in future
versions of this standard. The NRT service stream transmitted
66
CA 02726831 2010-12-02
"
through FLUTE protocol further requires parameters to signal
, a FLUTE session as a Table 3. In the Table 3, '38' of
component_type being defined for FLUTE component in the ATSC
or '43' of component_type newly being defined for
transmission NRT may be used.
= [Table 3]
component_type Meaning
0-34 Assigned or reserved by IANA, except that 20,
4, 27, and 29-30 are unassigned
35
H.264/AVC video stream component (assigned by
ATSC use)
36 SVC enhancement layer stream component
(assigned by ATSC use)
HE AAC v2 audio stream component (assigned by
37
ATSC use)
38
FLUTE file delivery session (assigned by ATSC
use)
39
STKM stream component (assigned by ATSC use)
40
LTKM stream component (assigned by ATSC use)
41 OMA-RME DIMS stream component (assigned by
ATSC use)
42 NTP
timebase stream component (assigned by
ATSC use)
43-71
[Unassigned by IANA and reserved by ATSC use]
72-76 Reserved by IANA
77-95 Unassigned by IANA
96-127 Designated by IANA for dynamic use
[00225] A num STKM streams field (8-bit unsigned integer)
shall identify the number of STKM streams associated with
this component.
[00226] A STKM stream id field (8-bit unsigned integer)
shall identify an STKM stream where keys to decrypt this
protected component can be obtained, by reference to the
STKM stream id in the component descriptor for the STKM
stream.
=
67
CA 02726831 2010-12-02
[00227] An NRT component data (component type) provides the
' encoding parameters and/or other parameters necessary for
rendering this component. The structure of the
NRT component data is determined by the value of
component type field.
[00228] The File Delivery Table (FDT) of the FLUTE sessions
used to deliver the items lists all the content items and
gives their sizes, data types, and other information relevant
to the acquisition of the items.
[00229] For example, the receiver may configure and display
a service guide using an OMA BCAST SG. The receiver acquires
information for accessing a FLUTE session in which content
selected from the displayed service guide is transmitted. In
addition, the receiver receives a file by mapping information
about the transmitted file through the file information (FDT)
in the accessed FLUTE session based on the access information
acquired from the SMT to the content identifier of the OMA
BCAST SG. The
content identifier of the OMA BCAST SG may
contain globalContentID for globally and uniquely identifying .
a content item using XML or NRT_content_id which is
separately defined in association with an NRT service, and
conversion thereof is necessary for mapping with the file
information in the FLUTE session, which is the value of a
binary type. The
conversion process will be described in
detail later and will be omitted herein.
68
CA 02726831 2010-12-02
"
[00230] In order to signal the FLUTE session, parameters
are necessary. Such parameters include necessary parameters
and parameters which are selectively necessary in association
with the FLUTE session.
First, the necessary parameters
, include a "source IP address" parameter, a "number of
channels in the session" parameter, a "destination IP address
and port number for each channel in the session" parameter, a
"Transport Session Identifier (TSI) of the session" parameter
and a "start time and end time of the session" parameter, and
the parameters which are selectively necessary in association
with the FLUTE session include an "FEC object transmission
information" parameter, a "some information that tells
receiver in the first place, that the session contains files
that are of interest", and a "bandwidth specification"
parameter.
[00231] The "number of channels in the session" parameter
may be explicitly provided or may be obtained by summing the
number of streams configuring the session.
Among the
parameters, the "start time and end time of the session"
parameter may be signaled through the SMT suggested by the
present invention, and the "source IP address" parameter, the
"destination IP address and port number for each channel in
the session" parameter, the "Transport Session Identifier
(TSI) of the session" parameter and the "number of channels
69
= CA 02726831 2010-12-02
in the session" parameter may be signaled through
session_description_descriptor.
An NRT component data
[00232] FIG. 15 is a diagram for a bit-stream syntax of
NRT component data descriptor for FLUTE file
delivery
configured according to an embodiment of the present
invention.
[00233] A single NRT service may contain multiple FLUTE
sessions. Each session may be signaled using one or more
FLUTE component descriptors, depending on the IP addresses
and ports used for the sessions.
[00234] In the following description, each field of
NRT component data descriptor is explained in detail.
[00235] A TSI is a 16-bit unsigned integer field, which
shall be the Transport Session Identifier (TSI) of the FLUTE
session.
[00236] A session start time indicates the time at which
the FLUTE session starts. If the value of this field is set
to all zero, then it shall be interpreted -to mean that the
session has already started.
[00237] A session _ end _time indicates the time at which the
FLUTE session ends. If the value of this field is set to all
zero, then it shall be interpreted to mean that the session
continues indefinitely.
..* ak 02726831 2010-12-02
[00238] A tias bandwidth indicator is a 1-bit field that
flags the inclusion of TIAS bandwidth information. This bit
shall be set to 1 to indicate the TIAS bandwidth field is
present, and it shall be set to 0 to indicate the TIAS
bandwidth field is absent.
[00239] An as bandwidth indicator is a 1-bit field that
flags the inclusion of AS bandwidth information. This bit
shall be set to 1 to indicate the AS bandwidth field is
present, and it shall be set to 0 to indicate the AS
bandwidth field is absent.
[00240] A FEC OTI indicator is a 1-bit indicator that
_ _
indicates whether FEC Object Transmission Information is
provided.
[00241] A tias bandwidth field has a value. This value
shall be one one-thousandth of the Transport Independent
. Application Specific maximum bandwidth, rounded up to the
next highest integer if necessary. (Note: this gives the TIAS
bandwidth in kilobits per second).
[00242] An as bandwidth has a value. This value shall be
the Application Specific maximum bandwidth. (Note: this gives
the AS bandwidth in kilobits per second).
[00243] A FEC encoding id field identifies a FEC encoding
ID used in this FLUTE session.
' [00244] A FEC instance id field identifies a FEC instance
ID used in this FLUTE session.
71
ak 02726831 2010-12-02
[00245] By signaling the above described parameters via
FLUTE component data bytes, it is able to provide all
information mandatory to receive a FLUTE session. And, it is
able to use a method of receiving FDT via this session,
obtaining information all files carried on a FLUTE session
via the received FDT and receiving these files.
[00246] This FLUTE component descriptor can be delivered
via component level descriptor loop of NST. In case that
_ _
there is a plurality of FLUTE channels, such parameters at a
session level as TSI, session start time, session end time
_ _
and the like should be signaled only once. Hence, one of the
components of several channels can transmit a FLUTE component
descriptor via Component level_descriptor loop.
A Relationship among M/H service, FLUTE session and NRT
service
[00247] FIG. 16 is a view explaining a relationship among
an M/H service, a FLUTE session and an NRT service according
to the present invention.
[00248] The M/H services include one or more M/H components
and each of the M/H services is transmitted through a FLUTE
channel. The FLUTE channel corresponds to an MH service
component. In addition, a single M/H NRT service contains
multiple FLUTE sessions and each of the FLUTE sessions
contains multiple FLUTE channels. The MH component may be
72
ak 02726831 2010-12-02
'
defined by a single destination IP address and a single UDP
port number.
[00249] For example, an MH NRT service A includes a FLUTE
session 1, the FLUTE session 1 is indicated by TSI 1
information of an MH component .1 and an MH component 2 of the
MH services. In addition, an MH NRT service B contains FLUTE
sessions 2 and 3. The FLUTE session 2 is indicated by TSI 2
information of an MH component 3 and an MH component 4 of the
MH services, and the FLUTE session 3 is indicated by TSI 3
information of an MH component 5.
A FDT schema
[00250] FIG. 17 is an exemplary diagram to explain a FDT
schema for mapping a file to content_id according to an
embodiment of the present invention, and FIG. 18 is an
exemplary diagram to explain a FDT schema for mapping a file
to content id according to another embodiment of the present
invention, which represents a FDT instant level entry file
, designating method.
[00251] In the following description, a FDT instance level
refers to a level containing a portion, in which the common
attribute is defined, if the common attribute of all files
, declared in the FDT needs to be defined. The FDT file level
is used to indicate a level containing definition of the
individual attribute of each of thefiles.
73
ak 02726831 2010-12-02
= [00252] The receiver identifies whether transferred service
via corresponding channel is an NRT service based upon the
NST and NCT. Also, the receiver identifies content items and
files of corresponding NRT service.
= [00253] As mentioned in the foregoing description, the
receiver may identify files and content items in the fixed
NRT service. However, the receiver can not be matched the
files to the content items because of not having information
. on mapping the files to the content items. Accordingly, the
receiver can not process the received fixed NRT service.
[00254] Therefore, the present invention can provide a
method for mapping the files to the content items. In this
' case, the receiver can properly process the received fixed
NRT services. In this disclosure, the method may be specified
based on the FDT information in the FLUTE session
transmitting fixed NRT services. For instance, each file
constructing the content items is identified based on
content-location and TOI field specified in the FLUTE session.
Moreover, the TOI field or content-location field and content
item is corresponded to be matched a content identifier in
the FDT with the content id field in the NCT.
[00255] Referring to FIGs. 17 and 18, a part indicated by
#1 declares content id at FDT-Instance level. In this case,
the declared content id is given to all files declared within
the corresponding FDT-Instance. Of course, by newly giving
74
CA 02726831 2010-12-02
_*.
content id at a file level, it is able to overdrive this
information. Alternatively, if a specific file belongs to
another content item instead of a content item defined at the
FDT-Instance level, this can be announced by giving a file
level content id that will be explained in the following
description. In the present embodiment, content_id is
represented using 16 bits.
. [00256] A part indicated by #2 declares content id at a
file level. If a file included within FDT Instance belongs to
a different content item, it is signaled that each file
belongs to a prescribed content item using this method.
[00257] A part indicated by #3 is a method for informing
each file whether the corresponding file is an entry file. In
particular, a file, which is played back in the first place,
or a file corresponding to a root file, which should be
' executed first to access a content item, among several files
constructing a content item is called an entry file. This
part indicates a method of announcing this information. It is
able to omit 'entry' attribute. If it is omitted as 'false',
a basic value means that a corresponding file is not an entry
file.
[00258] By signaling a presence or non-presence of an entry
according to a group belonging at a file level, a specific
file plays a role as an entry in a specific group but may
fail to play the role in another group.
ak 02726831 2010-12-02
*
[00259] Regarding an embodiment of an entry file, if a
content item is constructed as a web page, assume that
index.htm and other several associated pictures and text
files exist, the index.htm becomes the entry file.
[00260] As a method of announcing a presence or non-
presence of an entry file in case of granting content
identifier at FDT-instance level, the following two kinds of
methods can be taken into consideration.
[00261] 1) Method of granting File-level content
identifier to a file corresponding to an entry file in
addition and setting its entry attribute to 'true': In this
case, it is disadvantageous in that content identifier is
overlapped at FDT-Instance level and file level. Yet, this
case can provide a most flexible structure.
[00262] 2) It
is able to consider a method of directly
referencing files playing a role as an entry file in the
content identifier definition' at FDT-instance level like
another embodiment of the FDT scheme shown in FIG. 20. For
this, in the embodiment shown in FIG. 20, FDT-Content-ID-Type
is separately defined for FDT-instance level content
identifier. This is extended td include a content location of
an entry file as indicated by #2.
. [00263] In case of this method, it may be disadvantageous
in that a content location is repeatedly signaled. But, it
76
CA 02726831 2010-12-02
becomes advantageous in that entry file configuring
information can be directly obtained per content item.
A Mapping of SMT, FDT and OMA-BCAST SG
[00264] FIG. 19 is a block diagram showing an example of a
receiver used for mapping of signaling information configured
according to an embodiment of the present invention.
[00265] According to the present invention, a mobile
broadcast receiver tunes to a desired ensemble and then
extracts and processes an SMT of RS frame data of the
ensemble. The extracted/processed SMT contains information
necessary for mapping of a mobile service (or an NRT service)
and IP access information and acquisition of an IP stream
component of the mobile service (or NRT service) in the form
of a table or descriptor. In addition, the SMT is transmitted
in a state of being divided into sections, and the sections
may be individually processed. A single SMT section contains
virtual channel information of the ensemble in which the SMT
sections are transmitted. Each of the SMT sections is divided
into ensemble id and section _number. Each of the SMT sections
is encapsulated by UDP/IP, and an IP address and a UDP port
number use well-known values such that the mobile broadcast
receiver can receive the SMT sections without separate IP
access information. Each of the SMT sections is transmitted
77
ak 02726831 2010-12-02
. = '
in binary form, and the mobile broadcast receiver processes
the SMT sections in binary form.
[00266] The data of each of the SMT sections is basically
in binary form and the data of the OMA-BCAST SG is in XML
form. Accordingly, in order to enable such data to be used
. for mapping, such data should be converted.
That is, the
mobile broadcast receiver converts data elements of the SMT
sections in binary form into XML form so as to maintain
consistency with the OMA-BCAST SG. The SMT in binary form is
, processed by an SMT binary parser in a handler, is stored in
a storage 124, is extracted from the storage 124 for mapping,
is converted into XML form by an SMT converter, and is input
to an SG handler 165. When the OMA-BCAST SG in XML form is
input to the SG handler 165, mapping is performed using both
data.
[00267] The conversion process for mapping both data will
now be described in detail.
= [00268] FIG. 20 is a view explaining a connection process
for converting and mapping SMT data to OMA-BCAST SG data
according to an embodiment of the present invention, and FIG.
22 is a view illustrating a method of converting service_id.
' [00269] Referring to FIGs. 20 and 22, the mobile broadcast
receiver converts the SMT section in binary type into XML
form, for mapping.
78
CA 02726831 2010-12-02
[00270] For example, transport stream id in the FIC and
service id of the 16-bit binary form in the SMT are combined,
are converted into an anyURI form, and are mapped with a
service identifier (e.g., globalServiceID) on the OMA-BCAST
SG. The converted anyURI form may be, for example, a format
such as URI:://atsc.<transport_stream_id>service_id>.
Accordingly, the receiver may search for a service fragment
using the service identifier (e.g., globalServiceID) on the
OMA-BCAST SG.
[00271] In addition, a content identifier (e.g.,
globalContentID or NRT_content_id) on the OMA-BCAST SG is
mapped with based on content_id in the EDT. Accordingly, the
receiver may search for a content fragment and a schedule
fragment which refers to the content fragment in the OMA-
BCAST SG, using the mapping. In addition, content_id in the
FDT may be, for example, a 16-bit binary number.
[00272] Therefore, according to the present invention, an
MH reception system which is a mobile broadcast system may
convert the SMT and the FDT in binary form transmitted
through a well-known IP address and UDP port number into XML
. form and map them to information corresponding to the OMA-
BCAST SG originally transmitted in XML form so as to maintain
consistency. =
, An NRT Signaling Architecture description
79
ak 02726831 2010-12-02
= [00273] FIG. 21 is a view explaining SML schema of an OMA
BOAST SG broadcast service delivery for providing access
information through an NRT serVice according to an embodiment
of the present invention.
= [00274] In the above-described process, in order to signal
access information of a service transmitted through the NRT
service in an access fragment of the BCAST SG, the following
method may be used.
[00275] The access information for the service delivery
through a broadcast is provided through a broadcast service
delivery structure. As shown in FIG. 21, the access
information of the service delivered through the NRT service
may be provided. As a method for session description, if an
NRTServiceRef element is added to provide the access
information of the NRT service, the NRT service access
information on the SMT is referred to and used by referring
to the NRT service.
[00276] As shown in FIG. 21, a method of using an NRT-
Broadcast-Locator as a Universal Resource Identifier (URI)
for uniquely identifying an ensemble carried by the NRT
service and providing an NRT service ID through an NRT-
Service-Reference so as to uniquely identify the NRT service
can be implemented.
[00277] The NRT-Broadcast-Locator is extended as follows
such that the NRT service can be identified by a single URI.
CA 02726831 2010-12-02
[00278] atsc://f=<frequency>.<program_number>[.m=<modulatio
n format>][/<NRT service ID>]
[00279] The NRT service may be uniquely identified by the
single URI by containing the NRT service ID in the URI.
A Method of providing NRT service
[00280] FIG. 23 is a flowchart illustrating a method of
providing an NRT service according to an embodiment of the
present invention.
[00281] The receiver receives an OMA BCAST SG, processes
the received OMA BCAST SG, and configures and displays a
service guide (S2301).
[00282] When a user or the like selects a specific content
item in at least one mobile NRT service from the displayed
service guide, a content identifier associated with the
selected specific content item is acquired (S2302).
[00283] The receiver processes and reads an SMT of
signaling information in order to receive the selected
specific content item (S2303).
. [00284] If an M/H service contains single or multiple M/H
NRT services, an MH_service category field is searched for
and an NRT service is identified (S2304). The receiver may
identify a desired NRT service using an MH service id field.
81
CA 02726831 2010-12-02
[00285] The receiver reads and stores session information
such as an IP address and a UDP port number for a component
corresponding to the NRT service in the SMT (S2305).
[00286] The receiver processes component descriptor() of
the NRT service and reads information about a FLUTE session
(S2306).
[00287] The receiver processes component descriptor with
respect to the component (M/H component data with type 38)
and checks a TSI value of the component. The receiver joins
in a FLUTE file delivery =session using the acquired
information, reads an FDT, and acquires content_id for the
selected content item (S2307).
[00288] The content_id acquired in step S2307 and the
content identifier acquired in step S2302 are mapped (S2308).
The mapping is performed because the content_id acquired in
step S2307 and the content identifier acquired in step S2302
are defined in different formats. The mapping process may,
for example, refer to FIGs. 20 to 22.
[00289] If the content_id acquired in step S2307 and the
content identifier acquired in step S2302 are matched to each
other as the mapping result, a file in the selected content
item is downloaded (S2309). -
[00290] FIG. 24 is a flowchart illustrating a method of
providing an NRT service according to another embodiment of
the present invention.
82
CA 02726831 2010-12-02
[00291] The receiver processes and reads an SMT of
signaling information in order to receive a content item in
an NRT service (S2401).
' [00292] If an M/H service contains a signal or multiple M/H
NRT services, an MR service category field is searched for
and the NRT service is identified (S2402). The receiver may
identify a desired NRT service using an MH_service_id field.
[00293] The receiver reads and stores session information
such as an IP address and a UDP port number for a component
corresponding to the NRT service in the SMT (S2403).
[00294] The receiver processes component_descriptor of the
component and reads information about a FLUTE session (S2404).
[00295] The receiver processes component_descriptor with
respect to the component (M/H component data with type 38)
and checks a TSI value of the component. The receiver joins
in a FLUTE file delivery session using the acquired
information, reads an FDT, and acquires content id for the
content item in the NRT service. Files transmitted through
the FLUTE session and the acquired content id are stored
(S2405).
[00296] The receiver receives an OMA BCAST SG, processes
the received OMA BCAST SG, and configures and displays a
service guide (S2406).
[00297] When a user or the like selects a specific content
item in at least one mobile NRT service from the displayed
83
CA 02726831 2010-12-02
service guide, a content identifier associated with the
selected specific content item is acquired (S2407).
[00298] The content id acquired in step S2405 and the
content identifier acquired in step S2407 are mapped (S2408).
The mapping is performed because the content_id acquired in
step S2405 and the content identifier acquired in step S2407
are defined in different formats. The mapping process may,
for example, refer to FIGs. 20 to 22.
[00299] If the content id acquired in step S2405 and the
content identifier acquired in step S2407 are matched to each
other as the mapping result, a file in the selected content
item is downloaded (S2409).
[00300] In the embodiment of the service providing method
of FIG. 23, the SMT is processed first, the FLUTE session for
. providing the NRT service is accessed, the content items in
the service are received and stored, and a content item,
which is desired by the user, 'from among the stored content
items is reproduced using the OMA-BCAST SG.
[00301] In contrast, in the embodiment of the service
providing method of FIG. 24, the OMA-BCAST SG is processed
first, the service guide is provided, the SMT is processed
when the user or the like selects the specific content item,
. the FLUTE session in which the selected content item is
transmitted is accessed, and the content is received, stored
and reproduced.
84
ak 02726831 2012-11-23
74420-472
[00302] The service providing method of FIG. 23 and the
service providing method of FIG. 24 are different from each
. other as described above. In FIG. 23, since all associated
content items are received and stored, the range of choice of
the user broadens. Since the desired content is already
stored, the desired content can be rapidly reproduced, but
. there is a limitation in terms of storage space. Since all
the content items in the service are received, unnecessary
content items are also received and thus system efficiency
may deteriorate. In FIG. 24, since only the desired content
' item is received, system efficiency can be improved. However,
if the user wants another content item, since the service
guide is provided again and the selected content item is
received, the time consumed for reproducing the desired item
may be increased.
[00303] It will be apparent to those skilled in the art
that various modifications and variations can be made
to the embodiments described herein. Thus, it is intended that
the present invention covers the modifications and variations
of this invention provided they come within the scope of the
appended claims and their equivalents.
