WO2009151266A2 - 서비스 제공 방법 및 모바일 방송 수신기 - Google Patents

서비스 제공 방법 및 모바일 방송 수신기 Download PDF

Info

Publication number
WO2009151266A2
WO2009151266A2 PCT/KR2009/003097 KR2009003097W WO2009151266A2 WO 2009151266 A2 WO2009151266 A2 WO 2009151266A2 KR 2009003097 W KR2009003097 W KR 2009003097W WO 2009151266 A2 WO2009151266 A2 WO 2009151266A2
Authority
WO
WIPO (PCT)
Prior art keywords
service
information
data
nrt
content
Prior art date
Application number
PCT/KR2009/003097
Other languages
English (en)
French (fr)
Other versions
WO2009151266A3 (ko
Inventor
송재형
서종열
이철수
토마스고머
김진필
홍호택
이준휘
Original Assignee
엘지전자(주)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자(주) filed Critical 엘지전자(주)
Priority to CA2726831A priority Critical patent/CA2726831C/en
Priority claimed from KR1020090051202A external-priority patent/KR101598518B1/ko
Publication of WO2009151266A2 publication Critical patent/WO2009151266A2/ko
Publication of WO2009151266A3 publication Critical patent/WO2009151266A3/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4382—Demodulation or channel decoding, e.g. QPSK demodulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/482—End-user interface for program selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors

Definitions

  • the present invention receives a signaling method for a service type and detailed information about a service for a service transmitted in a non real time (NRT) method through a terrestrial broadcasting network, and receives the corresponding information. And more specifically, the receiver acquires additional information on the NRT service using such service-related signaling information, how to process and output the service to a user, and an associated application module. (operation module) operation can be determined.
  • the present invention relates to a mapping method and a broadcast receiver between signaling information and announcement information for an NRT service.
  • NRT service Non Real Time service
  • NRT literally involves non-real-time transmission, storage, and viewing, not real-time streaming, and transmits file-type content through extra bandwidth through broadcast media such as terrestrial waves.
  • Push VOD targeted advertising It is a technology that is expected to implement a variety of service functions, such as.
  • An object of the present invention is to define signaling data for an NRT service.
  • Another object of the present invention is to define a method of transmitting the signaling data defined above.
  • Another object of the present invention is to receive and process signaling data for the transmitted NRT service in a receiver so that the NRT service can be accessed.
  • non-real-time (NRT) service providing method according to the present invention
  • the file comprising the non-real-time service, the first signaling information and the second signaling information is IP packetized to be included in one ensemble and received; Constructing and displaying a service guide using first signaling information obtained from the ensemble; Acquiring first content identification information for the content selected from the displayed service guide; Accessing a flute session using second signaling information obtained from the ensemble, and obtaining second content identification information matching the first content identification information from the connected flute session; And receiving and storing at least one file constituting the corresponding content based on the obtained second content identification information.
  • FIC fast information channel
  • the FIC data may include the ensemble identifier and the transport stream identifier.
  • the transport stream identifier in the received FIC and the service identifier information in the received second signaling information may be combined into a specific type and mapped based on the service identifier information in the first signaling information.
  • the second signaling information may be received by being encapsulated in a UDP / IP header having a preset IP address and a UDP port number.
  • the slot corresponding to the ensemble may be received by a time slicing method.
  • the first signaling information may be an OMA-BCAST service guide
  • the second signaling information may be a service map table (SMT).
  • the obtained first content identification information may be a globalContentID for the corresponding content or may include content identification information defined separately with respect to the NRT service.
  • the acquired first content identification information may be mapped based on the acquired second content identification information, and the second content identification information may be 16 bits of binary type.
  • One example of a mobile broadcast receiver includes: a baseband processor unit configured to receive a file constituting a non-real-time service, and an ensemble in which an IP packet includes first signaling information and second signaling information; A first handler obtaining first signaling information from the received ensemble, and constructing and displaying a service guide using the obtained first signaling information; A second handler for obtaining first content identification information for the content selected in the displayed service guide; Acquire second signaling information from the ensemble, access a flute session using the acquired second signaling information, and obtain second content identification information matching the first content identification information from the connected flute session. A third handler; A control unit controlling to receive at least one or more files constituting the corresponding content based on the obtained second content identification information; And a storage unit for storing the received one or more files.
  • FIC fast information channel
  • the FIC data may include the ensemble identifier and the transport stream identifier.
  • the transport stream identifier in the received FIC and the service identifier information in the received second signaling information may be combined into a specific type and mapped based on the service identifier information in the first signaling information.
  • the second signaling information may be received by being encapsulated in a UDP / IP header having a preset IP address and a UDP port number.
  • the slot corresponding to the ensemble may be received by a time slicing method.
  • the first signaling information may be an OMA-BCAST service guide
  • the second signaling information may be a service map table (SMT).
  • the obtained first content identification information may be a globalContentID for the corresponding content or may include content identification information defined separately with respect to the NRT service.
  • the acquired first content identification information may be mapped based on the acquired second content identification information, and the second content identification information may be 16 bits of binary type.
  • the transmitting end may include signaling data to properly recognize, receive, and process an NRT service provided by a receiver.
  • the receiver can properly receive and process an NRT service received using the transmitted signaling data and provide the same to a user.
  • the receiver can configure and provide a service guide to a user by using the transmitted signaling data.
  • the receiver can effectively receive and process the content selected from the configured service guide using signaling information.
  • FIG. 2 is a block diagram illustrating a configuration of a receiving system according to an embodiment of the present invention
  • FIG. 3 is a diagram illustrating a relationship between an NRT service, a content item, and a file
  • FIG. 4 illustrates a protocol stack for a mobile NRT service configured according to an embodiment of the present invention.
  • FIG. 5 is a diagram illustrating an embodiment of a structure of a data group according to the present invention.
  • FIG. 6 illustrates a structure of an RS frame including a mobile NRT service configured according to an embodiment of the present invention.
  • FIG. 7 is a diagram illustrating an example of an M / H frame structure for transmitting / receiving mobile service data according to the present invention
  • FIG 9 illustrates a data transmission structure in a physical layer according to an embodiment of the present invention.
  • FIG. 10 illustrates a hierarchical signaling structure according to an embodiment of the present invention.
  • 11 and 12 illustrate bitstream syntax of an SMT configured according to an embodiment of the present invention.
  • FIG. 13 is a diagram illustrating a structure of a service guide SG according to an embodiment of the present invention.
  • FIG. 14 is a diagram illustrating bit stream syntax of an NRT component descriptor configured according to an embodiment of the present invention.
  • FIG. 15 illustrates the bitstream syntax of NRT_component_data when the component type value is 38 in the NRT component descriptor of FIG. 14.
  • FIG. 16 illustrates the relationship between an M / H service, a FLUTE session, and an NRT service according to the present invention
  • FIG. 17 illustrates an FDT schema for mapping a file and a content_id according to an embodiment of the present invention.
  • FIG. 18 illustrates an FDT schema for mapping a file and content_id according to another embodiment of the present invention.
  • FIG. 19 illustrates an example of a configuration block diagram of a receiver used for mapping signaling information configured according to an embodiment of the present invention.
  • FIG. 20 is a diagram to describe a process of connecting and converting SMT data and OMA-BCAST SG data according to an embodiment of the present invention.
  • FIG. 21 illustrates an 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.
  • FIG. 22 illustrates a method of converting service_id.
  • FIG. 23 is a flowchart illustrating a method of providing an NRT service according to an embodiment of the present invention.
  • FIG. 24 is a flowchart illustrating a method of providing an NRT service according to another embodiment of the present invention.
  • the main service data is data that can be received by the fixed receiving system and may include audio / video (A / V) data. That is, the main service data may include A / V data of a high definition (HD) or standard definition (SD) level, and may include various data for data broadcasting.
  • Known data is data known in advance by an appointment of a transmitting / receiving side.
  • M / H (or MH) is the first letter of each of a mobile and a handheld, and is a concept opposite to a fixed form.
  • the M / H service data includes at least one of mobile service data and handheld service data, and for convenience of description, the M / H service data may be referred to as mobile service data in the present invention. That is, in the present invention, MH, M / H, and mobile are all used in the same meaning.
  • the mobile service data may include not only M / H service data but also service data indicating movement or portability, and thus the mobile service data will not be limited to the M / H service data.
  • the mobile service data defined as described above may be data having information such as a program execution file, stock information, or the like, or may be A / V data.
  • the mobile service data may be A / V data having a smaller resolution and a smaller data rate than the main service data as service data for a portable or mobile terminal (or broadcast receiver).
  • the A / V codec used for the existing main service is an MPEG-2 codec
  • the MPEG-4 AVC Advanced Video Coding
  • SVC Scalable Video Coding
  • any kind of data may be transmitted as the mobile service data.
  • Transport Protocol Expert Group (TPEG) data for broadcasting traffic information in real time may be transmitted as mobile service data, and in connection with the present invention, an NRT service may be transmitted as mobile service data.
  • TPEG Transport Protocol Expert Group
  • the transmitting system of the present invention is capable of multiplexing and transmitting mobile service data including main service data and NRT service on the same or different physical channel without any influence on receiving main service data from an existing receiving system. do.
  • the transmission system of the present invention performs additional encoding on mobile service data, and inserts and transmits data that is known to both transmitting and receiving parties in advance, that is, known data.
  • the reception system enables mobile reception of mobile service data including an NRT service, and stable reception of mobile service data is possible even with various distortions and noises generated in a channel. It is possible.
  • FIG. 1 illustrates a conceptual diagram of an NRT service.
  • the broadcasting station transmits a Real Time (RT) service according to the existing scheme.
  • the broadcast station may provide an NRT (Non Real Time) service by transmitting an RT service and using bandwidth remaining in the process or using a dedicated bandwidth.
  • the NRT service may include news clips, weather information, advertisements, content for Push Video On Demand (VOD), and the like.
  • the conventional DTV receiver that is, the legacy device (legacy device), in principle, the operation is not affected by the NRT stream included in the channel. Therefore, the conventional DTV receiver has a problem in receiving and properly processing an NRT service provided by a broadcasting station.
  • the broadcast receiver that is, the NRT device according to the present invention can receive and appropriately process an NRT service combined with an RT service, thereby providing a viewer with various functions as compared to a conventional DTV receiver.
  • the RT service and the NRT service are transmitted through the same or different DTV channels, and are transmitted through an IP datagram. Therefore, the receiver needs to distinguish between two services transmitted through the same channel.
  • the present specification describes the definition and provision of signaling information so that a receiver can properly receive and process an NRT service.
  • FIG. 2 is a block diagram illustrating a configuration of a receiving system according to an embodiment of the present invention.
  • the reception system of FIG. 2 includes an operation controller 100, a tuner 111, a demodulator 112, an equalizer 113, a known data detector 114, a block decoder 115, and a primary RS that control the entire system.
  • the receiving system 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 may further include a primary RS frame buffer 131, a secondary RS frame buffer 132, and a transport packet (TP) handler 133.
  • TP transport packet
  • the receiving system includes an Internet Protocol (IP) datagram handler 141, a descrambler 142, a User Datagram Protocol (UDP) datagram handler 143, and a Real-time Transport Protocol / Real-RTP / RTCP.
  • IP Internet Protocol
  • UDP User Datagram Protocol
  • Real-time Transport Protocol / Real-RTP / RTCP time transport control protocol datagram handler 144, NTP datagram handler 145, service protection stream handler 146, second storage 147, ALC / LCT (Asynchronous)
  • the apparatus may further include a Layered Coding / Layered Coding Transport stream handler 148, a decompressor 149, an Extensible Mark-up Language (XML) parser 150, and an FDT handler 151.
  • the receiving system may further include an A / V decoder 161, a file decoder 162, a third storage unit 163, a middleware engine 164, and an SG handler 165.
  • the reception system may further include an EPG manager 171, an application manager 172, and a user interface (UI) manager 173.
  • IP adaptation module 130 IP datagram handler 141, descrambler ( 142, UDP datagram handler 143, RTP / RTCP datagram handler 144, NTP datagram handler 145, service protection stream handler 146, second storage 147, ALC It is referred to as common IP module 140, including / LCT stream handler 148, decompressor 149, and FDT handler 151.
  • a / V decoder 161, the file decoder 162, the third storage unit 163, the middleware engine 164, and the SG handler 165 may be referred to as an application module 160.
  • the operation controller 100 controls the operation of each block of the baseband processor 110.
  • the tuner 111 tunes the reception system to a frequency of a specific physical channel (or physical transmission channel, PTC) so that the main service data which is a broadcast signal for the fixed broadcast receiver and the broadcast signal for the mobile broadcast receiver are tuned. Receive mobile service data.
  • the tuner 111 down-converts the frequency of the tuned specific channel into an intermediate frequency (IF) signal and outputs the demodulator 112 and the known data detector 114.
  • the passband digital IF signal output from the tuner 111 may include only main service data, only mobile service data, or may include both main service data and mobile service data.
  • the demodulator 112 performs automatic gain control, carrier recovery, and timing recovery on the digital IF signal of the pass band input from the tuner 111 to form the baseband signal, and then the equalizer 113 and the known data detector 114. ) The demodulator 112 may improve demodulation performance by using a known data symbol string received from the known data detector 114 during timing restoration or carrier recovery.
  • the equalizer 113 compensates for the distortion on the channel included in the demodulated signal in the demodulator 112 and outputs the same to the block decoder 115.
  • the equalizer 113 may improve equalization performance by using a known data symbol string received from the known data detector 114.
  • the equalizer 113 may improve the equalization performance by receiving feedback of the decoding result of the block decoder 115.
  • the known data detector 114 detects a known data position inserted by the transmitting side from the input / output data of the demodulator 112, that is, data before demodulation or partial demodulation data is generated and is generated at the position along with the position information.
  • the sequence of known data is output to the demodulator 112, the equalizer 113, and the operation controller 100.
  • the known data detector 114 outputs the information to the block decoder 115 so that the block decoder 115 can distinguish the mobile service data that has been further encoded from the transmitting side and the main service data that have not been further encoded. do.
  • the block decoder 115 is configured to perform data equalization after channel equalization in the equalizer 113, and to perform both block encoding and trellis encoding of a serial concatenated convolution code (SCCC) scheme at a transmitting side (that is, in an RS frame). Data and signaling data), the trellis decoding and block decoding are performed in the reverse side of the transmitting side. If the trellis encoding is performed only without the block encoding (that is, main service data), only the trellis decoding is performed. do.
  • SCCC serial concatenated convolution code
  • the signaling decoder 118 decodes the signaling data input after channel equalization in the equalizer 113. It is assumed that signaling data (or signaling information) input to the signaling decoder 118 is data in which both block encoding and trellis encoding are performed in the transmission system. Such signaling data may be, for example, Transmission Parameter Channel (TPC) data and Fast Information Channel (FIC) data.
  • TPC Transmission Parameter Channel
  • FIC Fast Information Channel
  • the signaling decoder 118 performs recursive turbo decoding of parallel concatenated convolution code (PCCC) scheme on the data of the signaling information region among the input data, and then the FIC data and the TPC from the turbo decoded signaling data. Separate data.
  • PCCC parallel concatenated convolution code
  • the signaling decoder 118 performs RS decoding on the separated TPC data in reverse to the transmitting side and outputs the RS to the operation controller 100.
  • the signaling decoder 118 performs deinterleaving on the separated FIC data in sub-frame units, performs RS decoding on the reverse side of the transmitter, and outputs the decoded data to the FIC handler 121.
  • the transmission unit of FIC data deinterleaved and RS decoded by the signaling decoder 118 and output to the FIC handler 121 is an FIC segment.
  • the FIC handler 121 receives FIC data from the signaling decoder 118 and extracts signaling information for service acquisition, that is, mapping information between the ensemble and the mobile service.
  • the FIC handler 121 may include an FIC segment buffer, an FIC segment parser, and an FIC chunk parser.
  • the FIC segment buffer buffers the FIC segment group in M / H frame units input from the signaling decoder 118 and outputs the buffer to the FIC segment parser.
  • the FIC segment parser extracts and analyzes the header of each FIC segment stored in the FIC segment buffer, and outputs the payload of the corresponding FIC segment to the FIC chunk parser according to the analysis result.
  • the FIC chunk parser extracts signaling information for service acquisition by restoring and analyzing the FIC chunk data structure from the FIC segment payloads using the result analyzed by the FIC segment parser.
  • the signaling information obtained by the FIC chunk parser is output to the service manager 122.
  • the service signaling handler 123 includes a service signaling buffer and a service signaling parser, and buffers table sections, eg, SMT sections, of the service signaling channel transmitted from the UDP datagram handler 143. Analyze and process.
  • the SMT information processed by the service signaling handler 123 is also output to the service manager 122.
  • the SMT section or the service signaling channel for transmitting the SMT section may be received in a corresponding RS frame in the form of a UDP / IP packet having a well-known IP destination address and a well-known destination UDP port number. . Therefore, the receiving system can process the SMT section and the descriptors of each SMT section without requiring additional information.
  • the SMT section provides signaling information (including IP access information) for all services in the ensemble including the SMT section. Therefore, by using the information processed from the SMT, it is possible to access the IP stream component belonging to the service to be received, and provide the corresponding service to the user.
  • signaling information including IP access information
  • the information processed from the SMT is collected by the service manager 122 and stored in the first storage unit 124.
  • the service manager 122 stores the information extracted from the SMT in the first storage unit 124 in the form of a service map.
  • the service manager 122 constructs a service map using the signaling information collected from the FIC handler 121 and the service signaling handler 123, and configures the service guide (SG) collected from the service guide (SG) handler 165.
  • the program guide may be controlled to receive a desired mobile service by the user with reference to the configured service map and the created service guide, and the program guide may be displayed on at least a part of the screen according to the user's input. To control.
  • the operation controller 100 stores a service map and a service guide created by the service manager 122. In addition, the operation controller 100 extracts necessary data according to the request of the service manager 122 and the EPG manager 171 and transfers the necessary data to the service manager 122 and / or the EPG manager 171.
  • the operation controller 100 receives the base data location information and the TPC data, and basebands the M / H frame time information, the presence or absence of a data group of the selected parade, the location information of the known data in the data group, and the power control information. Transfers to each block of the processor 110. A detailed description of the TPC data will be given later.
  • the transmission system uses the RS frame concept as an encoding unit.
  • the RS frame is divided into a primary RS frame and a secondary RS frame.
  • the division of the primary RS frame and the secondary RS frame depends on the importance of data according to one embodiment.
  • the primary RS frame decoder 116 receives the output of the block decoder 115 as an input.
  • the primary RS frame decoder 116 receives mobile service data or NRT service data encoded with Reed Solomon (RS) encoding and / or cyclic redundancy check (CRC) encoding from the block decoder 115. do.
  • the primary RS frame decoder 116 may receive Reed Solomon (RS) encoding and / or Cyclic Redundancy Check (CRC) encoded SMT section data or OMA BCAST SG data from the block decoder 115.
  • RS Reed Solomon
  • CRC Cyclic Redundancy Check
  • the primary RS frame decoder 116 receives data other than main service data, for example, at least one of mobile service data, NRT service data, SMT section data, and OMA BCAST SG data.
  • the primary RS frame decoder 116 performs the reverse process of the RS frame encoder (not shown) of the transmission system to correct errors in the primary RS frame. That is, the primary RS frame decoder 116 collects a plurality of data groups to form a primary RS frame and then performs error correction on a primary RS frame basis. In other words, the primary RS frame decoder 116 decodes the primary RS frame transmitted for the actual broadcast service.
  • the primary RS frame decoded by the primary RS frame decoder 116 is output to the primary RS frame buffer 131.
  • the primary RS frame buffer 131 configures an M / H TP in units of rows and outputs the M / H TP to the TP handler 133.
  • the secondary RS frame decoder 117 receives the output of the block decoder 115 as an input.
  • the secondary RS frame decoder 117 also receives mobile service data or NRT service data encoded with Reed Solomon (RS) encoding and / or cyclic redundancy check (CRC) encoding from the block decoder 115.
  • the secondary RS frame decoder 117 may receive SMT section data or OMA BCAST SG data encoded with Reed Solomon (RS) encoding and / or cyclic redundancy check (CRC) encoding from the block decoder 115.
  • the secondary RS frame decoder 117 receives data other than main service data, for example, at least one of mobile service data, NRT service data, SMT section data, and OMA BCAST SG data.
  • the secondary RS frame decoder 117 performs an inverse process of an RS frame encoder (not shown) of the transmission system to correct errors in the secondary RS frame. That is, the secondary RS frame decoder 117 collects a plurality of data groups to form a secondary RS frame and then performs error correction on a secondary RS frame basis. In other words, the secondary RS frame decoder 117 decodes the secondary RS frame transmitted for mobile audio service data, mobile video service data, guide data, and the like.
  • the data of the secondary RS frame decoded by the secondary RS frame decoder 117 is output to the secondary RS frame buffer 132.
  • the secondary RS frame buffer 132 configures an M / H TP in units of rows after buffering the secondary RS frame and outputs the M / H TP to the TP handler 133.
  • the TP handler 133 is composed of a TP buffer and a TP parser. After buffering the M / H TP received from the primary and secondary RS frame buffers 131 and 132, each header of the buffered M / H TP is extracted. Analyze and restore the IP datagram from the payload of the M / H TP. The restored IP datagram is output to the IP datagram handler 141.
  • the IP datagram handler 141 is composed of an IP datagram buffer and an IP datagram parser. After buffering the IP datagram received from the TP handler 133, the IP datagram handler 141 extracts and analyzes a header of the buffered IP datagram. Restore the UDP datagram from the payload of the IP datagram. The restored UDP datagram is output to the UDP datagram handler 143.
  • the scrambled IP datagram is descrambled by the descrambler 142 and then output to the UDP datagram handler 143.
  • the descrambler 142 receives an encryption key or the like from the service protection stream handler 146 and decodes the UDP datagram. After scrambled, the data is output to the UDP datagram handler 143.
  • the UDP datagram handler 143 is composed of a UDP datagram buffer and a UDP datagram parser, and buffers UDP datagrams input from the IP datagram handler 141 or the descrambler 142 and then buffers the UDP.
  • the header of the datagram is extracted and analyzed to restore the data transmitted to the payload of the corresponding UDP datagram.
  • the restored data is an RTP / RTCP datagram, it is output to the RTP / RTCP datagram handler 144, and if it is an NTP datagram, it is output to the NTP handler 145.
  • the recovered data is a service protection stream
  • the recovered data is output to the service protection stream handler 146
  • the recovered data is an ALC / LCT stream
  • the output is output to the ALC / LCT stream handler 148.
  • the recovered data is SMT section data
  • the recovered data is output to the service signaling section handler 123.
  • the IP datagram handler 141 and the UDP datagram handler 143 are provided. ) May output data including the SMT section to the service signaling section handler 123 without requiring additional information.
  • the RTP / RTCP datagram handler 144 is composed of an RTP / RTCP datagram buffer and an RTP / RTCP datagram parser, and after buffering the data of the RTP / RTCP structure output from the UDP datagram handler 143, Extract the audio / video stream from the buffered data.
  • the extracted audio / video stream is output to the audio / video (A / V) decoder 161.
  • the A / V decoder 161 decodes the audio stream and the video stream output from the RTP / RTCP datagram handler 144 using respective decoding algorithms, and outputs the decoded audio stream to the presentation manager 170.
  • the audio decoding algorithm may be an AC-3 decoding 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, or a BSAC decoding.
  • At least one of the algorithm may be applied, and the video decoding algorithm may apply 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.
  • the NTP datagram handler 145 is composed of an NTP datagram buffer and an NTP datagram parser. After buffering the data of the NTP structure output from the UDP datagram handler 143, the NTP datagram handler 145 extracts an NTP stream from the buffered data. do. The extracted NTP stream is output to the A / V decoder 161 and decoded.
  • the service protection stream handler 146 may further include a service protection stream buffer, and after buffering data for service protection output from the UDP datagram handler 143, information for descramble from the buffered data. Extract The information for descrambling includes a key value for descrambling such as SKTM, LKTM, and the like. Information for the descramble is stored in the second storage unit 147, and is output to the descrambler 142 if necessary.
  • the ALC / LCT stream handler 148 is composed of an ALC / LCT stream buffer and an ALC / LCT stream parser. After buffering the data of the ALC / LCT structure output from the UDP datagram handler 143, the buffered data Analyze the header and header extension of the ALC / LCT session. As a result of analyzing the header and header extension of the ALC / LCT session, the ALC / LCT session may be output to the FDT handler 151, the SG handler 165, or the file decoder 162 according to the type of data transmitted to the ALC / LCT session. .
  • the compressed data is released by the decompressor 149 and then output to the file decoder 162.
  • the FDT handler 151 analyzes and processes a file description table of the FLUTE protocol transmitted in an XML structure through an ALC / LCT session.
  • the SG handler 165 collects and analyzes data for a service guide transmitted in an XML structure and outputs the data to the service manager 122.
  • the file decoder 162 decodes the data of the file structure transmitted through the ALC / LCT session and outputs the data to the middleware engine 164 or stores the data in the third storage unit 163.
  • the middleware engine 164 analyzes and executes data of a file structure, that is, an application.
  • the application may be output to an output device such as a screen or a speaker through the presentation manager 170.
  • the middleware engine 164 is an example of a Java-based middleware engine.
  • the middleware engine 164 controls a process of receiving an NRT content item and files related thereto.
  • the middleware engine 164 may control the FDT handler 151, the SG handler 165, and the EPG manager 171.
  • the EPG manager 171 receives the EPG data from the service manager 122 or the SG handler 165 according to the user's input, converts the EPG data into a display format, and outputs the EPG data to the presentation manager 170.
  • the application manager 172 performs overall management regarding the processing of application data transmitted in the form of an object, a file, and the like.
  • 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 according to a user's command input through the UI manager 173. By controlling, the function according to the user's command is performed.
  • the UI manager 173 transmits a user's input to the operation controller 100 through the UI.
  • the presentation manager 170 may include at least one of audio and video data output from the A / V decoder 161, file data output from the middleware engine 164, and EPG data output from the EPG manager 171. Provide it to the user via the screen.
  • an NRT service may be included in a mobile broadcast service, and an SMT section for signaling an NRT service included in the mobile broadcast service is extracted, for example, in the primary RS frame decoder 116.
  • the SMT section may be extracted by the secondary RS frame decoder 117.
  • the extracted IP adaptation module is processed by the IP module. That is, the IP datagram handler 141 processes the IP datagram including the SMT section and processes the UDP datagram, and then the extracted SMT section is processed by the service signaling section handler 123.
  • the FDT data and the NRT service data except for the SMT section data may be processed by the mobile broadcast receiver through an ALC / LCT processing unit to provide an NRT service.
  • FIG. 3 is a diagram illustrating a relationship between an NRT service, a content item, and a file.
  • one NRT service may include one or more content items, and each content item may include at least one or more file (s).
  • the content item may correspond to a program or event in a real-time broadcast as one independently playable entity. Accordingly, the NRT service refers to a group that can be serviced by a combination of the above content items, and corresponds to a channel concept in real time.
  • the receiver has a problem that it is difficult to properly process the mobile NRT service even when receiving the mobile NRT service because the signaling information for the received mobile NRT service data is not sufficient.
  • an aspect of the present invention is to solve the above problems, and to provide a processing method by defining signaling information so as to appropriately process mobile NRT service data received from a receiver.
  • signaling information so as to appropriately process mobile NRT service data received from a receiver.
  • SMT Service Map Table
  • SG OMA BCAST Service Guide
  • the receiver may identify whether the corresponding mobile service is a mobile NRT service by referring to the service_category field in the SMT, for example.
  • One or more content item (s) in the mobile NRT service may be identified using content identifier information in OMA BCAST SG and content_id field in FDT.
  • the mobile NRT service may be identified using, for example, NRT_service_id in the SMT and service identifier information in the OMA BCAST SG.
  • the present specification also provides a mapping method for identifier information of different formats for processing by the receiver.
  • the receiver can properly handle the received NRT service.
  • a mobile NRT service is transmitted over a FLUTE session and extracts FDT information from the FLUTE session.
  • the content_id in the extracted FDT information may be mapped to the content identifier of the OMA-BCAST SG to identify and receive the NRT service content selected by the user.
  • each file constituting the content item is identified using the TOI and Content-Location fields specified in the FDT within the FLUTE session, and the respective TOI or Content-Location and content are identified. Concatenation of items may be achieved by mapping the content_ID field in the FDT with the content identifier field of the OMA BCAST SG.
  • the NRT service can be largely classified into a fixed NRT service and a mobile NRT service.
  • a mobile NRT service will be described as an example.
  • FIG. 4 illustrates a protocol stack for a mobile NRT service configured according to an embodiment of the present invention.
  • FIG. 4 includes an adaptation layer between the IP layer and the physical layer to transmit an IP datagram including signaling information without using the MPEG-2 TS format.
  • an NRT service for a mobile service is packetized according to a user datagram protocol (UDP) scheme in an IP layer, and the UDP packet is packetized according to an IP scheme and becomes UDP / IP packet data.
  • the packetized UDP / IP packet data is referred to herein as an IP datagram for convenience of description.
  • the signaling information channel including the SMT is also packetized according to the User Datagram Protocol (UDP) scheme, and the UDP packet is again packetized according to the IP scheme to become UDP / IP packet data.
  • UDP User Datagram Protocol
  • the OMA-BCAST Service Guide (SG) and NRT content items / files are packetized according to the FLUTE scheme, and then packetized according to the ALC / LCT (Asynchronous Layered Coding / Layered Coding Transport) scheme. do.
  • the ALC / LCT packet is again packetized according to the UDP scheme, and the ALC / LCT / UDP packet is again packetized according to the IP scheme to form ALC / LCT / UDP / IP packet data.
  • the adaptation layer generates an RS frame including signaling information, an IP datagram, and identification information for distinguishing the signaling information from the IP datagram. That is, the adaptation layer is a data link layer that distinguishes the IP datagram of the mobile service data and the IP datagram of the signaling information table and connects the separated datagram to be processed in a higher layer.
  • the RS frame is modulated by a predetermined transmission scheme, for example, a VSB transmission scheme, in a mobile physical layer and transmitted to a receiving system.
  • data structures used in the mobile broadcasting technology according to the present invention include a data group structure and an RS frame structure. This will be described below.
  • FIG. 5 is a diagram illustrating an embodiment of a structure of a data group according to the present invention.
  • M / H blocks B1 to B10 show an example of dividing a data group into ten M / H blocks (M / H blocks B1 to B10). Each M / H block has a length of 16 segments.
  • the first five segments of the M / H block B1 and the five segments after the M / H block B10 allocate only RS parity data to a portion of the data segment, and exclude the data from the A region and the D region of the data group.
  • each M / H block is allocated to one of areas A to D according to the characteristics of each M / H block in the data group. Can be included.
  • each M / H block is included in any one of the A region and the D region according to the interference level of the main service data.
  • the reason why the data group is divided into a plurality of areas is used for different purposes. That is, an area where there is no or little interference of the main service data may exhibit stronger reception performance than an area that is not.
  • the main service It is possible to periodically insert known data of a certain length into an area where data does not interfere (that is, an area where main service data is not mixed). However, it is difficult to periodically insert known data into the area where the main service data interferes with the interference of the main service data, and also to insert long known data continuously.
  • the M / H blocks B4 to M / H block B7 in the data group of FIG. 5 show an example in which long known data strings are inserted before and after each M / H block as an area without interference of main service data.
  • the receiving system can perform the equalization using the channel information obtained from the known data. You can get performance.
  • the M / H block B3 and the M / H block B8 in the data group of FIG. 5 are regions in which main service data has little interference, and a long known data string is inserted into only one side of both M / H blocks. That is, due to the interference of the main service data, M / H block B3 is inserted with a long known data column only after the M / H block, and M / H block B8 is inserted with a long known data column only before the corresponding M / H block. Can be.
  • the receiving system can perform equalization using channel information obtained from the known data, which is more robust than the C / D area. Equalization performance can be obtained.
  • the M / H block B2 and the M / H block B9 in the data group of FIG. 5 have more interference of the main service data than the B area, and both M / H blocks cannot insert a long known data string back and forth.
  • the M / H block B1 and the M / H block B10 in the data group of FIG. 5 have more interference of the main service data than the C region, and likewise, both M / H blocks cannot insert a long known data string back and forth.
  • the data group also includes a signaling information region to which signaling data (or signaling information) is allocated.
  • a part of the first to second segments of the M / H block B4 in the data group may be used as the signaling information region.
  • the signaling information area consists of 207 bytes which is the first segment of the M / H block B4 and the first 69 bytes of the second segment.
  • the first segment of the M / H block B4 corresponds to the 17th or 173th segment of the VSB field.
  • Signaling data transmitted to the signaling information region can be largely divided into two types of signaling channel data.
  • One is Transmission Parameter Channel (TPC) data and the other is Fast Information Channel (FIC) data.
  • TPC Transmission Parameter Channel
  • FIC Fast Information Channel
  • the TPC data mainly includes parameters used in a physical layer module and is transmitted without being interleaved, so that the TPC data can be accessed for each slot in the receiving system.
  • the FIC data is provided to enable fast service acquisition at the receiver and includes cross layer information between the physical layer and the upper layer.
  • the FIC data is interleaved in subframe units and transmitted.
  • the signaling information area is located between the first known data row and the second known data row. That is, the first known data string is inserted into the last two segments of the M / H block B3 in the data group, and the second known data string is inserted into the second and third segments of the M / H block B4.
  • the third to sixth known data columns are inserted into the last two segments of the M / H blocks B4, B5, B6, and B7, respectively.
  • the first, third to sixth known data columns are spaced 16 segments apart.
  • FIG. 6 illustrates a structure of an RS frame including a mobile NRT service configured according to an embodiment of the present invention.
  • the RS frame is received for each M / H frame while being switched to the time slicing mode.
  • One RS frame includes IP streams of each mobile service data or signaling data, and service map table (SMT) section data may be present in all RS frames.
  • the SMT section data may be in the form of an IP stream or may be in another form.
  • Data of the RS frame is allocated to the corresponding areas of the plurality of data groups and transmitted.
  • RS frame consists of at least one M / H TP (Transport Packet).
  • This M / H TP consists of an M / H header and an M / H payload.
  • the M / H payload may include signaling data as well as mobile service data. That is, one M / H payload may include only mobile service data, may include only signaling data, or may include both service data and signaling data.
  • the NRT service according to the present invention may be included in the mobile service data.
  • IP Datagram 1 IP Datagram 1
  • IP Datagram 2 IP Datagram 3
  • IP Datagram 3 IP Datagram 3
  • FIG. 7 is a diagram illustrating an example of an M / H frame structure for transmitting / receiving mobile service data according to the present invention.
  • one M / H frame includes five subframes and one subframe consists of sixteen slots.
  • one M / H frame means five subframes and 80 slots.
  • One slot consists of 156 data packets (ie, transport stream packets) at the packet level and 156 data segments at the symbol level. Or half of the VSB field. That is, since one data packet of 207 bytes has the same amount of data as one data segment, the data packet before data interleaving can be used as the concept of the data segment. At this time, two VSB fields are combined to form one VSB frame.
  • FIG. 8 illustrates an example of a VSB frame structure, in which one VSB frame includes two VSB fields (ie, odd field and even field). Each VSB field consists of one field sync segment and 312 data segments.
  • the slot is a basic time unit for multiplexing the mobile service data and the main service data.
  • One slot may include mobile service data or may consist only of main service data.
  • the slot consists of 156 main service data packets.
  • mobile service data in one RS frame may be allocated to all of the A / B / C / D areas in the data group or may be allocated to at least one of the A / B / C / D areas.
  • mobile service data in one RS frame is allocated to all of the A / B / C / D areas or only to one of the A / B areas and the C / D areas. That is, in the latter case, the RS frame allocated to the A / B area in the data group and the RS frame allocated to the C / D area are different.
  • the RS frame allocated to the A / B region in the data group is called a primary RS frame, and the RS frame allocated to the C / D region is a secondary RS frame. frame).
  • the primary RS frame and the secondary RS frame form one parade. That is, if the mobile service data in one RS frame are all allocated to the A / B / C / D areas in the data group, one parade transmits one RS frame. In contrast, if the mobile service data in one RS frame is allocated to the A / B area in the data group and the mobile service data in the other RS frame is allocated to the C / D area in the data group, Up to RS frames can be transmitted.
  • the RS frame mode indicates whether one parade transmits one RS frame or two RS frames.
  • This RS frame mode is transmitted as TPC data.
  • Table 1 below shows an example of an RS frame mode.
  • Table 1 Value Application Identifier Format 0x0000 DASE application 0x0001 ATSC reserved 0x0002 ATSC A / 92 Application 0x0003 NRT Application 0x0004-0x7FFF ATSC reserved 0x8000-0xFFFF User private
  • RS frame mode value 00
  • one parade transmits one RS frame.
  • the RS frame mode value 01
  • one parade is two RS frames, that is, primary RS.
  • the data of the secondary RS frame for region C / D for the region indicates that the data is allocated to the C / D region of the corresponding data group and transmitted.
  • the parades may be allocated as far apart from each other as possible in the subframe. This makes it possible to respond strongly to burst errors that can occur within one subframe.
  • the method of allocating parades may be differently applied to every M / H frame and may be equally applied to all M / H frames.
  • the same may be applied to all subframes in one M / H frame or may be differently applied to each subframe.
  • the present invention may vary for each M / H frame, and the same applies to all subframes in one M / H frame. That is, the M / H frame structure may vary in units of M / H frames, which makes it possible to flexibly adjust the ensemble data rate.
  • the ensemble concept is introduced to define a set of services.
  • One M / H ensemble has the same QoS and is coded with the same FEC code.
  • one ensemble has the same unique identifier (ie, ensemble id) and corresponds to consecutive RS frames.
  • FIG. 9 is a diagram illustrating a data transmission structure in a physical layer according to one embodiment of the present invention, and shows an example in which FIC data is included and transmitted in each data group.
  • the M / H frame for about 0.968 seconds is divided into five subframes, and data groups corresponding to several ensembles are present in each subframe, and data groups corresponding to each ensemble are present. These are interleaved in M / H frame units to form an RS frame belonging to one ensemble.
  • a portion of each data group e.g. 37 bytes / data group
  • the FIC region allocated to each data group constitutes one FIC segment, which is interleaved in units of subframes.
  • RS encoding and serial concatenated convolution code (SCCC) encoding are applied to data of the RS frame
  • RS encoding and parallel concatenated convolution code (PCCC) encoding are applied to the FIC data.
  • TPC data is applied to RS encoding and parallel concatenated convolution code (PCCC) encoding similarly to the FIC data.
  • (187 + P, 187) -RS encoding is applied to the data of the RS frame
  • (51,37) -RS encoding is applied to the FIC data
  • the (18,10) -RS encoding is applied to the TPC data. In one embodiment it is applied.
  • P is the number of parity bytes.
  • FIG. 10 illustrates a hierarchical signaling structure according to an embodiment of the present invention.
  • the mobile broadcast technology according to the present embodiment employs a signaling method using FIC and SMT. This is called hierarchical signaling structure in the present invention.
  • FIG. 10 illustrates a hierarchical signaling structure for providing data required for service acquisition through a service map table (SMT) among FIC chunks and IP level mobile service signaling channels.
  • SMT service map table
  • the FIC chunk uses its fast characteristics to convey the mapping relationship between the mobile service and the ensemble to the receiving system. That is, the FIC chunk provides signaling system for quickly finding an ensemble delivering a desired service in the receiving system and quickly receiving RS frames of the ensemble.
  • 11 and 12 illustrate bitstream syntax of an SMT configured according to an embodiment of the present invention.
  • the SMT describes service information and IP access information in an ensemble in which the SMT is transmitted.
  • the SMT also provides broadcast stream information of a corresponding service using Transport_Stream_ID, which is an identifier of a broadcast stream to which each service belongs.
  • Transport_Stream_ID is an identifier of a broadcast stream to which each service belongs.
  • the SMT according to the present embodiment may include description information of each mobile service in one MH ensemble, and other additional information may be included in a descriptor area.
  • the SMT section may be included and transmitted in the form of an IP stream in an RS frame.
  • RS frame decoders of a receiver to be described later decode an input RS frame and output the decoded RS frame to a corresponding RS frame handler.
  • Each RS frame handler divides the input RS frame into row units to form an MH TP and outputs it to the MH TP handler.
  • a table_id field (8 bits) is a field for distinguishing a type of table, and this shows that the table section is a table section in SMT (table_id: An 8-bit unsigned integer number that indicates the type of table section being defined in Service Map Table (SMT).
  • SMT Service Map Table
  • a section_syntax_indicator field (1 bit) is an indicator defining a section format of an SMT.
  • the section format may be, for example, a short-form syntax (0) of MPEG (section_syntax_indicator: This 1-bit field shall be set to 0 to always indicate that this table is derived from the short form of the MPEG-2 private section table).
  • the private_indicator field (1 bit) indicates whether the SMT follows the private section (private_indicator: This 1-bit field shall be set to 1).
  • section_length A 12-bit field.It specifies the number of remaining bytes this table section immediately following this field.The value in this field shall not exceed 4093 (0xFFD)).
  • table_id_extension This is a 16-bit field and is table-dependent.It shall be considered to be logically part of the table_id field providing the scope for the remaining fields).
  • the table_id_extension field includes an SMT_protocol_version field.
  • the SMT_protocol_version field (8 bits) indicates the protocol version to allow NRT SMT to transmit parameters whose parameters differ from those defined in the current protocol (SMT_protocol_version: 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).
  • An ensemble_id field (8 bits) is an ID value associated with a corresponding MH ensemble and may be assigned values of 0x00 to 0x3F. The value of this field is preferably derived from parade_id of TPC data. If the MH ensemble is transmitted through the primary RS frame, the most significant bit (MSB) is set to 0, and the remaining 7 bits are used as the parade_id value of the corresponding MH parade. Meanwhile, if the MH ensemble is transmitted through the secondary RS frame, the most significant bit (MSB) is set to 1, and the remaining 7 bits are used as the parade_id value of the corresponding MH parade (ensemble_id: This 8-bit unsigned integer).
  • this field in the range 0x00 to 0x3F 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 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).
  • a version_number field (5 bits) represents the version number of the SMT.
  • current_next_indicator 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).
  • section_number This 8-bit field 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).
  • last_section_number This 8-bit field shall give the number of the last section (ie, the section with the highest section_number) of the Service Signaling table of which this section is a part).
  • a num_services field (8 bits) indicates the number of services in the SMT section.
  • the service is an NRT service, it may indicate the number of corresponding NRT services (num_services: This 8 bit field specifies the number of services in this SMT section).
  • the SMT provides information about a plurality of mobile services (or NRT services) using a for loop.
  • the following field information may be provided for each service.
  • the service_id field (16 bits) is an indicator for uniquely identifying the mobile service within the range of the MH broadcast.
  • the service_id does not change throughout the service.
  • the ervice_id will identify each NRT service (service_id: 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.
  • Annex A for a description of an allocation scheme for MH_service_id values).
  • the Multi_ensemble_service field (2 bits) identifies whether the mobile service is sent over one or more ensemble. In addition, this field only identifies whether the mobile service is represented as part of the mobile service transmitted via the ensemble. That is, multi_ensemble_service: 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.The value of this field is defined in Table 6.8).
  • An MH_service_status field (2 bits) identifies the status of the mobile service.
  • the MSB indicates whether the corresponding mobile service is active (1) or inactive (0), and the LSB indicates whether the corresponding mobile service is hidden (1) or not (0).
  • MH_service_status 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 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).
  • the SP_indicator field (1 bit) is used to indicate if a service protection is applied to at least one of the components required to provide a meaningful presentation of the mobile service (SP_indicator: A 1-bit field that shall 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).
  • short_service_name_length 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).
  • the short_service_name field indicates the short name of the mobile service (short_service_name: The short name of the M / H Service, each character of which shall be encoded per UTF-8 [29] .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 0x00).
  • An MH_service_category field (6 bits) identifies the type category of the service transmitted in the mobile service, as defined in Table 2 below. If the value of this field is set to a value indicating Informative only, the value of this field is treated as an informative description of the category of the service. And the receiver is required to check the component_level_descriptors () field of the SMT to identify the actual category of the service transmitted through the MH service. For services with video and / or audio components they have an NTP timebase component (MH_service_category: A 6-bit enumerated type field that shall identify the type category of service carried in this M / H Service as defined in Table 7.3.
  • the value of this field When the value of this field is set to the value which is indicated Informative only, the value of this field shall be 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).
  • the receiver when the value of the MH_service_category field in the received SMT section is, for example, a value of 0x0E, the receiver may know that the mobile service is a mobile NRT service. Accordingly, when the value of the MH_service_category field is 0x0E, the receiver identifies that the corresponding mobile service is an NRT service, and as a result, a diagram of a component level including information on a FLUTE session in which the identified NRT service is transmitted. Check component_descriptor of 14. Here, in checking the component_descriptor, if the component_type field value in the corresponding descriptor is 38, information on the FLUTE session received as component data of FIG. 15 to be described later is extracted.
  • a num_components field (5 bits) describes the number of IP stream components in the mobile service (num_components: This 5-bit field specifies the number of IP stream components in this M / H Service).
  • the IP_version_flag field (1 bit) indicates that the source_IP_address field, the MH_service_destination_IP_address field, and the component_destination_IP_address field are IPv6 addresses when set to 1; 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. of IPv6 addressing is not currently defined).
  • source_IP_address_flag 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.
  • MH_service_destination_IP_address_flag A 1-bit Boolean flag that indicates, when set to 1, that a MH_service_destination_IP_address value is present, to serve as the default IP address for the components of this M / H Service).
  • the source_IP_address field (32 or 128 bits) needs to be interpreted when source_IP_address_flag is set to 1, but does not need to be interpreted when source_IP_address_flag is not set to zero. If source_IP_address_flag is set to 1 and the IP_version_flag field is set to 0, this field indicates a 32-bit IPv4 address indicating the source of the corresponding virtual channel.
  • IP_version_flag indicates a 32-bit IPv6 address indicating the source of the virtual channel (source_IP_address: This 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).
  • the MH_service_destination_IP_address field (32 or 128 bits) needs to be interpreted when MH_service_destination_IP_address_flag is set to 1, but does not need to be interpreted when MH_service_destination_IP_address_flag is set to 0. If MH_service_destination_IP_address_flag is set to 1 and the IP_version_flag field is set to 0, this field indicates a 32-bit target IPv4 address for the corresponding virtual channel. If MH_service_destination_IP_address_flag is set to 1 and the IP_version_flag field is set to 1, this field indicates a 64-bit target IPv6 address for the corresponding virtual channel.
  • MH_service_destination_IP_address This field shall be present if the MH_service_destflag shall not be present if the MH_service_destination_IP_address_flag is set to 0. If this MH_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).
  • the SMT according to the present embodiment provides information on a plurality of components using a for loop.
  • the essential_component_indicator field (1 bit), if set to 1, indicates that the corresponding component is an essential component for mobile service. Otherwise_component_indicator: 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).
  • component_destination_IP_address_flag A 1-bit Boolean flag that shall indicate, when set to 1, that the component_destination_IP_address is present for the component_destination_IP_address_flag field (1 bit) is set to 1 if the component_destination_IP_address field exists for the component. this component).
  • a port_num_count field (6 bits) indicates the number of UDP ports associated with the corresponding UDP / IP stream component.
  • the target UDP port number value is increased by 1 starting from the value of the destination_UDP_port_num field.
  • the target UDP port number is increased by 2 starting from the value of the destination_UDP_port_num field, because this 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).
  • a destination_UDP_port_num field (16 bits) indicates a target UDP port number for the corresponding IP stream component.
  • the value of destination_UDP_port_num is an even number, and the next higher value indicates the target UDP port number of the associated RTCP stream (component_destination_UDP_port_num: A 16-bit unsigned integer field, that represents the destination UDP port number for this UDP / IP stream component
  • 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).
  • the component_destination_IP_address field (32 or 128 bits) is set to 0 in the IP_version_flag field, this field indicates a 32-bit target IPv4 address for the corresponding IP stream component. If the IP_version_flag field is set to 1, this field indicates a 128-bit target IPv6 address for the corresponding IP stream component (component_destination_IP_address: This 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 MH 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 MH_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
  • a num_component_level_descriptors field (4 bits) describes the number of component level descriptors for the corresponding component (num_component_level_descriptors: This 4 bit field specifies the number of component level descriptors for this component).
  • component_level_descriptor represents one or more descriptors providing additional information for this IP stream component, may be included.
  • the num_MH_service_level_descriptors field (4 bits) describes the number of NRT service level descriptors for the corresponding service (num_MH_service_level_descriptors: This 4 bit field specifies the number of service level descriptors for this service).
  • MH_service_level_descriptor represents a descriptor that provides additional information about the service.
  • the mobile service may include an NRT service and may inform a specific service type for the corresponding NRT service.
  • the specific service type may include, for example, a portal service for providing web content, a push VOD, an A / V download, etc.
  • the num_ensemble_level_descriptors field (4 bits) describes the number of ensemble level descriptors for the ensemble (num_ensemble_level_descriptors: This 4 bit field specifies the number of ensemble level descriptors for this ensemble).
  • ensemble_level_descriptor Zero or more descriptors providing additional information for the M / H Ensemble which this SMT-MH describes, may be included) .
  • Source_IP_address is a source IP address of the same server that transmits all channels of the FLUTE session when the service is an NRT service.
  • MH_service_destination_IP_Address is signaled if there is a destination IP address of the session level of this FLUTE session.
  • a component may be mapped to a channel in a FLUTE session, and a separate destination IP address (different from the IP address signaled on a session basis) for each channel may be signaled through component_destination_IP_address.
  • a destination port number may be signaled through component_destination_UDP_port_num, and the number of destination port numbers starting from component_destination_UDP_port_num may be additionally specified through port_num_count.
  • FIG. 13 is a diagram illustrating a structure of a service guide SG according to an embodiment of the present invention.
  • the receiving system receives a service guide delivery descriptor (ServiceGuideDeliveryDescriptor), which is information describing the service guide, using the entry point information.
  • ServiceGuideDeliveryDescriptor Information on the structure and acquisition of the service guide can be obtained from the service guide delivery descriptor, which can be used to receive service guide information.
  • the SG can provide signaling information (also referred to as announcement information) in subdivided sub-units, and the sub-divided sub-units are called fragments.
  • the fragment used in the SG may include a service fragment, a schedule fragment, a content fragment, a purge item fragment, a purge data fragment, and a purse channel.
  • Fragments, and access fragments, session description fragments, previewData fragments, and interactive data fragments may refer to the service fragment.
  • the schedule fragment may refer to a service fragment and a content fragment.
  • the number illustrated above each arrow in FIG. 12 represents the possible number of each sub unit information. And the number represents the possible number of each fragment.
  • the service fragment contains information about a service provided to the user, for example a service such as one conventional television channel.
  • the content fragment includes metadata about content. For example, types of A / V, text, images, and the like for the content are included in the content fragment.
  • the NRT service guide data may be obtained by acquiring a service fragment, a schedule fragment, and a content fragment.
  • the NRT service guide data may include information about content version, content_id, content available time, and the like.
  • the schedule fragment includes schedule information for one piece of content of a service.
  • the broadcast time of the content may correspond to this.
  • the aperture item fragment includes item information related to a purchase.
  • the aperture data fragment includes information related to the purchase of a service that a user can purchase.
  • the aperture channel fragment refers to an interface through which a terminal or a user communicates with a purchase system.
  • the aperture channel fragment includes parameters related to a purchase system or information on management of a purchase channel.
  • the access fragment includes information related to access of a service or content.
  • NRT services are signaled in M / H broadcasting.
  • Signaling of information on individual MH NRT content items consists of the following two steps.
  • 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.
  • Content through the NRT service is transmitted through FLUTE, and access information on the SMT table signals FLUTE session information as follows.
  • FIG. 14 illustrates a bit stream syntax of an NRT component descriptor configured according to an embodiment of the present invention.
  • NRT_component_descriptor () will appear in the component descriptor loop of each component of each NRT service in the SMT. And all parameters in the descriptor correspond to the parameters used for components of the NRT service (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).
  • descriptor_tag field (8 bits) identifies a descriptor (0x8D) (descriptor_tag: This 8-bit unsigned integer shall have the value, identifying this descriptor as the NRT_component_descriptor).
  • descriptor_length This 8-bit unsigned integer shall specify the length (in bytes) immediately following this field up to the end of this descriptor).
  • a component_type field (7 bits) identifies an encoding format of a component.
  • the identification value may be one of values assigned for payload_type of the RTP / AVP stream. Or one of the values shown in Table 3 assigned by this specification. Or dynamic value.
  • the values in this field shall correspond to the values in payload_type in the RTP header of the IP stream carrying the component (component_type: This 7-bit field 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 in the range 96-127.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.Note that additional values of the component_type field in the range of 43-71 can be defined in future versions of this standard).
  • the component_type 38 defined for the FLUTE component in ATSC-M / H may be used to additionally signal the parameters described below required for the FLUTE session. 43 may be newly defined and used as a component_type for NRT transmission.
  • a num_STKM_streams field (8 bits) identifies a number of STKM streams associated with this component. (num_STKM_streams: An 8-bit unsigned integer field that shall identify the number of STKM streams associated with this component).
  • the STKM_stream_id field (8 bits) identifies the STKM stream with the keys to decrypt the corresponding protected component obtained.
  • STKM_stream_id An 8-bit unsigned integer field that 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).
  • the NRT_component_data (component_type) field provides encoding parameters and / or other parameters necessary for representing the corresponding component.
  • the NRT_component_data (component_type) The NRT_component_data () element 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).
  • the File Delivery Table (FDT) of FLUTE sessions is used to deliver item lists of all content items and provides the size, data type and information of the items related to obtaining the items (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).
  • the receiver may configure and display a service guide using OMA BCAST SG.
  • the receiver obtains information for accessing the FLUTE session through which the content selected in the indicated service guide is transmitted from the SMT.
  • a file is received by mapping information on a file transmitted through a file information (FDT) in a connected FLUTE session.
  • the content identifier information of the OMA-BCAST SG is a globalContentID which can uniquely identify a corresponding content item in an XML format, or includes a NRT_content_id defined separately in relation to an NRT service. Conversion is required when mapping the file information in the FLUTE session. However, the conversion process will be described in detail in the corresponding part and will be omitted here.
  • parameters are required to signal a FLUTE session, and these parameters include mandatory parameters that are absolutely necessary and parameters that are optionally required in connection with the FLUTE session.
  • the mandatory parameters include the source IP address, the number of channels in the session, the destination IP address and port number for each channel in the session. for each channel in the session, the Transport Session Identifier (TSI) of the session, and the start time and end time of the session parameters.
  • Optionally related parameters include: FEC Object Transmission Information, Some information that tells receiver in the first place, that the session contains files that are of interest And Bandwidth specification parameters.
  • the number parameter of channels in the session may be explicitly provided or may be obtained by summing the number of streams constituting the session.
  • a start time and end time of the session parameter may be signaled through the SMT proposed by the present invention, and a source IP address and a destination IP for each channel in the session through the session_description_descriptor. Parameters for the address and port number and the number of channels in the session can be signaled.
  • FIG. 15 illustrates the bitstream syntax of NRT_component_data when the component type value is 38 in the NRT component descriptor of FIG. 14.
  • One NRT service may be included in 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 (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).
  • a TSI field (16 bits) indicates a TSI of a FLUTE session (TSI: A 16-bit unsigned integer field, which shall be the Transport Session Identifier (TSI) of the FLUTE session).
  • TSI Transport Session Identifier
  • the session_start_time field indicates the time at which the FLUTE session starts.
  • Session_start_time 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).
  • the session_end_time field indicates the time when the FLUTE session ends.
  • Session_end_time 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).
  • a tias_bandwidth_indicator field (1 bit) indicates flags including transport independent application specific (TIAS) bandwidth information. If the TIAS Bandwidth field indicates that the bit is present, the bit shall be set to 1, and if the TIAS Bandwidth field indicates that the TIAS bandwidth field does not exist, the bit shall be set to 0 (tias_bandwidth_indicator: 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).
  • TIAS transport independent application specific
  • the as_bandwidth_indicator field (1 bit) is flags including application specific (AS) bandwidth information. If the AS bandwidth field is present, the bit should be set to 1, and if the AS bandwidth field is not present, the bit should be set to 0 (as_bandwidth_indicator: A 1-bit field that flags the inclusion of bit 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).
  • An FEC_OTI_indicator field (1 bit) indicates whether FEC Object Transmission Information (OTI) information is provided (FEC_OTI_indicator: A 1-bit indicator that indicates whether FEC Object Transmission Information is provided).
  • tias_bandwidth indicates the TIAS maximum bandwidth (tias_bandwidth: This value shall be one one-thousandth of the Transport Independent Application Specific maximum bandwidth as defined in RFC 3890 [16], rounded up to the next highest integer if necessary. (Note: this gives the TIAS bandwidth in kilobits per second)).
  • the as_bandwidth field shall have the value of the AS maximum bandwidth (as_bandwidth: This value shall be the Application Specific maximum bandwidth as defined in RFC 4566 [17]. (Note: this gives the AS bandwidth in kilobits per second)).
  • the FEC_encoding_id field indicates FEC encoding ID used in this FLUTE session (FEC_encoding_id: FEC encoding ID used in this FLUTE session, as defined in RFC 3926 [18]).
  • the FEC_instance_id field indicates the FEC instance ID used in the FLUTE session (FEC_instance_id: FEC instance ID used in this FLUTE session, as defined in RFC 3926 [18]).
  • the NRT component descriptor may be delivered through a Component_level_descriptor loop of SMT. Therefore, even when there are a plurality of FLUTE channels, since TSI, session_start_time, session_end_Time, etc., which are session level parameters, need to be signaled only once, the NRT component descriptor can be transmitted only through one component among the components of the multiple channels through the Component_level_descriptor loop.
  • FIG. 16 illustrates the relationship between an M / H service, a FLUTE session, and an NRT service according to the present invention.
  • M / H services include one or more M / H component (s), each M / H component being transmitted on a FLUTE channel.
  • the FLUTE channel corresponds to the MH service component.
  • one M / H NRT service includes multiple FLUTE sessions, and each FLUTE session includes multiple FLUTE channels.
  • the MH component is defined by one destination IP address and one UDP port number.
  • MH NRT service A includes FLUTE session 1, which is indicated by TSI 1 information of MH component 1 and MH component 2 among MH services.
  • MH NRT service B includes FLUTE sessions 2 and 3, the FLUTE session 2 is indicated by the TSI 2 information of MH component 3 and MH component 4 of the MH services, FLUTE session 3 is TSI of MH component 5 3 is indicated by information.
  • FIG. 17 illustrates an FDT schema for mapping a file and content_id according to an embodiment of the present invention
  • FIG. 18 illustrates an FDT schema for mapping a file and content_id according to another embodiment of the present invention. As illustrated, the FDT instant level entry file designation method is represented.
  • the FDT instance level means a level including a definition part of the common attributes of all files declared in the FDT, and the FDT file level includes definitions of individual attributes in each file. It is used to mean a level.
  • the part indicated by 1 denotes a content identifier at the FDT-Instance level, where the content identifier declared is all files declared in the FDT-Instance. Is given to.
  • this information may be overridden by assigning a new content identifier at the file level.
  • the file may be notified by assigning a file level content identifier to be described below.
  • the content identifier is represented using 16 bits.
  • the part marked 2 indicates a content identifier at the file level. If a file included in an FDT instance belongs to a different content item, this method signals to which content item each file belongs.
  • Number 3 is a method for notifying whether each file is an entry file for each file.
  • the file that corresponds to the root file that must be played first among the files that make up the content item or must be accessed first to access the content item is called an entry file.
  • the entry attribute can be omitted. If the default value is omitted, it means that the file is not an entry file.
  • a specific file may act as an entry in a specific group and not in another group.
  • index.htm when the content item is configured in the form of a web page, and index.htm and several other related picture and text files exist. Becomes
  • the following two methods can be considered to indicate whether an entry file is provided when a content identifier is assigned at the FDT-instance level.
  • the content identifier overlaps at the FDT-Instance level and the file level. It may have a structure.
  • FDT-Content-ID-Type is separately defined for the FDT-instance level content identifier and extended to include the content location of the entry file as indicated by 2. .
  • a part of overlapping signaling of the content location may be a disadvantage, but an advantage may be obtained that the entry file configuration information may be directly obtained for each content item.
  • FIG. 19 illustrates an example of a configuration block diagram of a receiver used for mapping signaling information configured according to an embodiment of the present invention.
  • the mobile broadcast receiver is tuned to a desired ensemble, and then extracts and processes an SMT from RS frame data of the ensemble.
  • the extracted / processed SMT includes information necessary for mapping of mobile service (or NRT service) and IP access information and acquisition of IP stream component of each mobile service (or NRT service) in the form of a table and a descriptor.
  • the SMT is divided into sections and transmitted, and each section can be processed by itself.
  • One SMT section includes virtual channel information of an ensemble in which the SMT section is transmitted.
  • Each SMT section is divided into ensemble_id and section_number.
  • Each SMT section is encapsulated in UDP / IP.
  • the IP address and UDP port number use well-known values so that the mobile broadcast receiver can receive the SMT section without additional IP access information.
  • Each SMT section is transmitted in binary form, and the mobile broadcast receiver processes the corresponding SMT section in binary form.
  • the data of the SMT section is in binary format
  • the data of the OMA-BCAST SG is in XML format. Therefore, the two data can be used for later mapping only after conversion. That is, the mobile broadcast receiver converts binary data elements of each received SMT section into XML to maintain consistency with the OMA-BCAST SG.
  • the SMT in binary form is processed by the SMT binary parser in the handler and stored in the storage unit 124, and then extracted from the storage unit 124 for mapping to be converted into an XML form by the SMT converter and converted into an SG handler ( 165), and when the OMA-BCAST SG in XML format is input to the SG handler 165, mapping is performed using both data.
  • FIG. 20 is a diagram to explain a process of connecting and converting SMT data and OMA-BCAST SG data according to one embodiment of the present invention
  • FIG. 22 is a diagram to describe a method of converting service_id. will be.
  • the mobile broadcast receiver converts an SMT section in binary format into an XML form for mapping.
  • transport_stream_id in FIC and 16-bit binary type service_id in SMT are combined and converted into anyURI type and mapped to service identifier information (eg, globalServiceID) on OMA-BCAST SG.
  • the converted anyURI type may be, for example, a format such as urI :: // atsc. ⁇ Transport_stream_id> ⁇ service_id>.
  • the receiver may find a service fragment using service identifier information (eg, globalServiceID) on the OMA-BCAST SG.
  • the content identifier information (eg, globalContentID or NRT_content_id) on the OMA-BCAST SG is mapped based on the content_id in the FDT. Accordingly, the receiver may find a corresponding content fragment in the OMA-BCAST SG and a schedule fragment referencing the same using the mapping.
  • the content_id in the FDT may be, for example, 16 bits of binary type.
  • the MH receiving system converts the SMT and FDT in binary form transmitted through a well-known IP address and a UDP port number into an XML form, and transmits the OMA-BCAST SG transmitted in the original XML form. You can map your corresponding information to maintain consistency.
  • FIG. 21 illustrates an 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.
  • the following method may be used to signal access information on a service transmitted through an NRT service in an access fragment of BCAST SG.
  • Access information for service delivery through broadcast is provided through a broadcast service delivery structure. As shown in FIG. 21, access information of a service delivered through an NRT service may be provided. If the NRTServiceRef element is added as a method for session description to provide access information for the NRT service, this is to refer to the NRT service and use the NRT service access information on the SMT table.
  • the NRT-Broadcast-Locator is used as a URI (Uivesial Resource Identifier) uniquely identifying the ensemble in which the NRT service is loaded, and the NRT service ID is provided by providing an NRT service ID through the NRT-Service-Reference. Identification is possible.
  • URI User Resource Identifier
  • NRT-Broadcast-Locator it would be possible to extend the NRT-Broadcast-Locator as follows to identify the NRT service with a single URI.
  • the NRT service ID may be included in the URI to uniquely identify the NRT service with one URI.
  • FIG. 23 is a flowchart illustrating a method of providing an NRT service according to an embodiment of the present invention.
  • the receiver receives the OMA BCAST SG and processes the received OMA BCAST SG to configure and display a service guide (S2301).
  • a content identifier associated with the selected specific content item is obtained (S2302).
  • the receiver processes and reads an SMT of signaling information in order to receive the selected specific content item (S2303).
  • the MH_service_category field is found to identify the NRT service (S2304).
  • the receiver may identify a desired NRT service using the MH_service_id field.
  • the receiver reads and stores session information such as an IP address and a UDP port number for each component corresponding to the NRT service in the SMT (S2305).
  • the receiver processes component_descriptor () for the NRT service and reads information on the FLUTE session (S2306).
  • the receiver may determine a TSI value for each component by processing component_descriptor for each component (M / H component data with type 38).
  • the receiver joins to a FLUTE file delivery session using the obtained information to read an FDT to obtain a content_id for the selected content item (S2307).
  • the content_id acquired in step S2307 and the content identifier obtained in step S2302 are mapped (S2308).
  • the mapping is because the content_id acquired in the step S2307 and the content identifier obtained in the step S2302 are defined in different formats.
  • the mapping process may refer to, for example, FIGS. 20 to 22 described above.
  • step S2309 If the content_id acquired in step S2307 and the content identifier obtained in step S2302 match as a result of the mapping, a file in the selected content item is downloaded (S2309).
  • FIG. 24 is a flowchart illustrating a method of providing an NRT service according to another embodiment of the present invention.
  • the receiver processes and reads an SMT of signaling information in order to receive a content item in an NRT service (S2401).
  • the MH_service_category field is found to identify the NRT service (S2402).
  • the receiver may identify a desired NRT service using the MH_service_id field.
  • the receiver reads and stores session information such as an IP address and a UDP port number for each component corresponding to the NRT service in the SMT (S2403).
  • the receiver processes component_descriptor () for the NRT service and reads information on the FLUTE session (S2404).
  • the receiver may determine a TSI value for each component by processing component_descriptor for each component (M / H component data with type 38).
  • the receiver joins to a FLUTE file delivery session using the obtained information to read an FDT to obtain a content_id for a content item in an NRT service.
  • the obtained content_id and the files transmitted through the corresponding FLUTE session are stored (S2405).
  • the receiver receives the OMA BCAST SG and processes the received OMA BCAST SG to construct and display a service guide (S2406).
  • a content identifier associated with the selected specific content item is obtained (S2407).
  • the content_id acquired in step S2405 and the content identifier obtained in step S2407 are mapped (S2408).
  • the mapping is because the content_id acquired in the step S2405 and the content identifier obtained in the step S2407 are defined in different formats. The mapping process is described above with reference to FIGS. 20 to 22.
  • step S2405 If the content_id acquired in step S2405 and the content identifier obtained in step S2407 match as a result of the mapping, a file in the selected content item is played (S2409).
  • the SMT is processed first to access a FLUTE session provided with an NRT service to receive and store content items in a corresponding service, and then store the stored content item using OMA-BCAST SG. This is a flow of playing a desired content item by a user or the like.
  • the OMA-BCAST SG is processed first to provide a service guide, and when a user selects a specific content item, the SMT is processed to access a FLUTE session in which the selected content item is transmitted. To receive, store, and then play back the corresponding content.
  • the service method of FIG. 23 differs from the service method of FIG. 24.
  • the user's selection is expanded by receiving and storing all related content items, and the desired content is already stored.
  • the efficiency of the system may be reduced by receiving all content items in the service and receiving unnecessary content items.
  • the efficiency of the system can be improved by receiving only the desired content item, but if the user wants another content item, the time required for the playback may be longer because the user must provide the service guide again and receive the selected content item. have.
  • the present invention has industrial applicability in the field of broadcasting and communication.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Circuits Of Receivers In General (AREA)

Abstract

본 발명은 서비스를 제공하는 방법 및 모바일 방송 수신기에 관한 것으로, 본 발명에 따른 서비스 제공 방법의 일 예는, 비실시간 서비스를 구성하는 파일과 제1 시그널링 정보와 제2 시그널링 정보가 IP 패킷화되어 하나의 앙상블에 포함되어 수신되는 단계; 상기 앙상블로부터 획득한 제1 시그널링 정보를 이용하여 서비스 가이드를 구성하고 표시하는 단계; 상기 표시된 서비스 가이드에서 선택된 컨텐트에 대한 제1 컨텐트 식별 정보를 획득하는 단계; 상기 앙상블로부터 획득한 제2 시그널링 정보를 이용하여 플루트(FLUTE) 세션에 접속하고, 접속된 플루트 세션으로부터 상기 제1 컨텐트 식별 정보와 매칭되는 제2 컨텐트 식별 정보를 획득하는 단계; 및 상기 획득한 제2 컨텐트 식별 정보에 근거하여 해당 컨텐트를 구성하는 적어도 하나 이상의 파일들을 수신하여 저장하는 단계;를 포함한다.

Description

서비스 제공 방법 및 모바일 방송 수신기
본 발명은 지상파 방송망을 통해 논-리얼 타임(Non Real Time; 이하 'NRT'라 한다) 방식으로 전송되는 서비스에 대한 서비스 타입 및 서비스에 대한 상세 정보에 대한 시그널링(signaling) 방법 및 해당 정보를 수신하여 처리하기 위한 NRT 수신기의 동작에 관한 것으로, 더욱 상세하게는 수신기는 이러한 서비스 관련 시그널링 정보를 이용하여 해당 NRT 서비스에 대한 추가적인 정보를 획득하며 해당 서비스를 어떻게 처리하여 사용자에게 출력할지 그리고 관련된 어플리케이션 모듈(application module)의 동작을 결정할 수 있다. 본 발명은 NRT 서비스를 위한 시그널링 정보와 어나운스먼트(announcement) 정보 간 매핑(mapping) 방법 및 방송 수신기에 관한 것이다.
향후 DTV 서비스에서 활용될 유력한 어플리케이션(application) 중의 하나로 NRT 서비스(Non Real Time service)를 들 수 있다. NRT는 말 그대로 실시간 스트리밍이 아닌 비실시간 전송, 저장 및 시청 동작을 수반하며 지상파 등의 방송 매체를 통해 여분의 대역폭(bandwidth)을 통해 파일(file) 형태의 컨텐트를 전송하는 것으로 push VOD, targeted advertising 등의 다양한 서비스 기능의 구현이 예상되는 기술이다.
본 발명의 목적은 NRT 서비스에 대한 시그널링 데이터를 정의하는데 있다.
본 발명의 다른 목적은 상기 정의된 시그널링 데이터를 전송하는 방식을 정의하는데 있다.
본 발명의 또 다른 목적은 수신기에서 상기 전송되는 NRT 서비스에 대한 시그널링 데이터를 수신 처리하여 NRT 서비스를 접근할 수 있도록 하는데 있다.
본 발명의 또 다른 목적은 수신기에서 상기 시그널링 데이터의 컨텐트 식별자와 선택된 컨텐트가 전송되는 컨텐트의 식별자를 매핑하는 방법을 제공하는데 있다.
본 발명의 또 다른 목적은 수신기에서 시그널링 데이터를 이용하여 구성한 서비스 가이드로부터 선택된 컨텐트를 수신 처리하여 사용자에게 제공할 수 있는 방법을 제공함에 있다.
본 발명에 따른 비실시간(NRT) 서비스 제공 방법의 일 예는, 비실시간 서비스를 구성하는 파일과 제1 시그널링 정보와 제2 시그널링 정보가 IP 패킷화되어 하나의 앙상블에 포함되어 수신되는 단계; 상기 앙상블로부터 획득한 제1 시그널링 정보를 이용하여 서비스 가이드를 구성하고 표시하는 단계; 상기 표시된 서비스 가이드에서 선택된 컨텐트에 대한 제1 컨텐트 식별 정보를 획득하는 단계; 상기 앙상블로부터 획득한 제2 시그널링 정보를 이용하여 플루트(FLUTE) 세션에 접속하고, 접속된 플루트 세션으로부터 상기 제1 컨텐트 식별 정보와 매칭되는 제2 컨텐트 식별 정보를 획득하는 단계; 및 상기 획득한 제2 컨텐트 식별 정보에 근거하여 해당 컨텐트를 구성하는 적어도 하나 이상의 파일들을 수신하여 저장하는 단계;를 포함한다.
이때, 상기 NRT 서비스 획득을 위한 크로스 계층 정보를 포함하는 고속 정보 채널(FIC) 데이터와 상기 FIC의 업데이트를 식별할 수 있는 FIC 버전 정보를 포함하는 전송 파라미터 채널(TPC) 데이터를 수신하는 단계;를 더 포함할 수 있다.
그리고 상기 FIC 데이터는 상기 앙상블 식별자와 트랜스포트 스트림 식별자를 포함할 수 있다.
또한, 상기 수신되는 FIC 내 트랜스포트 스트림 식별자와 상기 수신되는 제2 시그널링 정보 내 서비스 식별자 정보를 하나로 묶어 특정 타입으로 변환하여 상기 제1 시그널링 정보 내 서비스 식별자 정보를 기준으로 매핑할 수 있다.
그리고 상기 제2 시그널링 정보는, 미리 설정된 IP 어드레스와 UDP 포트 넘버를 갖는 UDP/IP 헤더로 인캡슐레이션되어 수신될 수 있다.
또한, 상기 앙상블에 대응하는 슬롯을 타임 슬라이싱 방식으로 수신할 수 있다.
그리고 상기 제1 시그널링 정보는 OMA-BCAST 서비스 가이드이고, 상기 제2 시그널링 정보는 서비스 맵 테이블(SMT)일 수 있다.
또한, 상기 획득한 제1 컨텐트 식별 정보는, 해당 컨텐트에 대한 globalContentID이거나 또는 상기 비실시간 서비스와 관련하여 별도로 정의된 컨텐트 식별 정보를 포함할 수 있다.
그리고 상기 획득한 제1 컨텐트 식별 정보는, 상기 획득한 제2 컨텐트 식별 정보를 기준으로 매핑하되, 상기 제2 컨텐트 식별 정보는 바이너리 타입의 16비트일 수 있다.
본 발명에 따른 모바일 방송 수신기의 일 예는, 비실시간 서비스를 구성하는 파일과 제1 시그널링 정보와 제2 시그널링 정보가 IP 패킷화되어 포함된 하나의 앙상블을 수신하는 베이스밴드 프로세서부; 상기 수신되는 앙상블로부터 제1 시그널링 정보를 획득하고, 획득한 제1 시그널링 정보를 이용하여 서비스 가이드를 구성하고 표시하는 제1 핸들러; 상기 표시된 서비스 가이드에서 선택된 컨텐트에 대한 제1 컨텐트 식별 정보를 획득하는 제2 핸들러; 상기 앙상블로부터 제2 시그널링 정보를 획득하고, 획득한 제2 시그널링 정보를 이용하여 플루트(FLUTE) 세션에 접속하고, 접속된 플루트 세션으로부터 상기 제1 컨텐트 식별 정보와 매칭되는 제2 컨텐트 식별 정보를 획득하는 제3 핸들러; 상기 획득한 제2 컨텐트 식별 정보에 근거하여 해당 컨텐트를 구성하는 적어도 하나 이상의 파일들을 수신하도록 제어하는 제어부; 및 수신되는 적어도 하나 이상의 파일들을 저장하는 저장부;를 포함한다.
이때, 상기 NRT 서비스 획득을 위한 크로스 계층 정보를 포함하는 고속 정보 채널(FIC) 데이터와 상기 FIC의 업데이트를 식별할 수 있는 FIC 버전 정보를 포함하는 전송 파라미터 채널(TPC) 데이터를 수신하는 단계;를 더 포함할 수 있다.
그리고 상기 FIC 데이터는 상기 앙상블 식별자와 트랜스포트 스트림 식별자를 포함할 수 있다.
또한, 상기 수신되는 FIC 내 트랜스포트 스트림 식별자와 상기 수신되는 제2 시그널링 정보 내 서비스 식별자 정보를 하나로 묶어 특정 타입으로 변환하여 상기 제1 시그널링 정보 내 서비스 식별자 정보를 기준으로 매핑할 수 있다.
그리고 상기 제2 시그널링 정보는, 미리 설정된 IP 어드레스와 UDP 포트 넘버를 갖는 UDP/IP 헤더로 인캡슐레이션되어 수신될 수 있다.
또한, 상기 앙상블에 대응하는 슬롯을 타임 슬라이싱 방식으로 수신할 수 있다.
그리고 상기 제1 시그널링 정보는 OMA-BCAST 서비스 가이드이고, 상기 제2 시그널링 정보는 서비스 맵 테이블(SMT)일 수 있다.
또한, 상기 획득한 제1 컨텐트 식별 정보는, 해당 컨텐트에 대한 globalContentID이거나 또는 상기 비실시간 서비스와 관련하여 별도로 정의된 컨텐트 식별 정보를 포함할 수 있다.
그리고 상기 획득한 제1 컨텐트 식별 정보는, 상기 획득한 제2 컨텐트 식별 정보를 기준으로 매핑하되, 상기 제2 컨텐트 식별 정보는 바이너리 타입의 16비트일 수 있다.
본 발명에 따르면,
첫째, 전송단은 수신기에서 제공되는 NRT 서비스를 적절하게 인식하고 수신하여 처리할 수 있도록 시그널링 데이터를 포함할 수 있는 효과가 있다.
둘째, 수신기는 상기 전송되는 시그널링 데이터를 이용하여 수신되는 NRT 서비스를 적절하게 수신 처리하여 사용자에게 제공할 수 있는 효과가 있다.
셋째, 수신기는 상기 전송되는 시그널링 데이터를 이용하여 사용자에게 서비스 가이드를 구성하여 제공할 수 있는 효과가 있다.
넷째, 수신기는 상기 구성된 서비스 가이드로부터 선택된 컨텐트를 시그널링 정보를 이용하여 정확하게 수신하여 처리할 수 있는 효과가 있다.
도 1은 NRT 서비스에 대한 개념도를 도시한 것이고,
도 2는 본 발명의 일 실시 예에 따른 수신 시스템의 구성 블록도를 도시한 도면이고,
도 3은 NRT 서비스, 컨텐트 아이템 및 파일에 대한 관계를 설명하기 위해 도시한 것이고,
도 4는 본 발명의 일 실시 예에 따라 구성한 모바일 NRT 서비스에 대한 프로토콜 스택(protocol stack)을 도시한 것이고,
도 5는 본 발명에 따른 데이터 그룹의 구조에 대한 일 실시 예를 보인 도면이고,
도 6은 본 발명의 일 실시 예에 따라 구성한 모바일 NRT 서비스를 포함한 RS 프레임의 구조를 도시한 것이고,
도 7은 본 발명에 따른 모바일 서비스 데이터의 송/수신을 위한 M/H 프레임 구조의 일 예를 보인 도면이고,
도 8은 VSB 프레임 구조의 일 예를 보인 것이고,
도 9는 본 발명의 일 실시예에 따른 물리적 계층에서의 데이터 전송 구조를 도시한 도면이고,
도 10은 본 발명의 일 실시 예에 따른 계층적인 시그널링 구조를 도시한 도면이고,
도 11과 12는 본 발명의 일 실시 예에 따라 구성한 SMT의 비트스트림 신택스을 도시한 것이고,
도 13은 본 발명의 일 실시예에 따른 서비스 가이드(SG)의 구조를 예시한 도면이고,
도 14는 본 발명의 일 실시 예에 따라 구성한 NRT 컴포넌트 디스크립터의 비트 스트림 신택스를 설명하기 위해 도시한 것이고,
도 15는 도 14의 NRT 컴포넌트 디스크립터에서 component type 값이 38일 때의 NRT_component_data의 비트스트림 신택스를 설명하기 위해 도시한 것이고,
도 16은 본 발명에 따라 M/H 서비스, FLUTE 세션 및 NRT 서비스의 관계를 설명하기 위해 도시한 것이고,
도 17은 본 발명의 일 실시 예에 따른 파일과 content_id의 매핑을 위한 FDT 스키마를 설명하기 위해 도시한 것이고,
도 18은 본 발명의 다른 실시 예에 따른 파일과 content_id의 매핑을 위한 FDT 스키마를 설명하기 위해 도시한 것이고,
도 19는 본 발명의 일 실시 예에 따라 구성한 시그널링 정보들의 매핑에 이용되는 수신기의 구성 블록도의 일 예를 도시한 것이고,
도 20은 본 발명의 일 실시 예에 따라 SMT 데이터와 OMA-BCAST SG 데이터를 변환하여 매핑하기 위해 연결하는 과정을 설명하기 위해 도시한 것이고,
도 21은 본 발명의 일 실시 예에 따라 NRT 서비스를 통하여 접속 정보를 제공하기 위한 OMA BCAST SG Broadcast service delivery 의 XML 스키마를 설명하기 위해 도시한 것이고,
도 22는 service_id를 변환하는 방법을 설명하기 위해 도시한 것이고,
도 23은 본 발명의 일 실시 예에 따라 NRT 서비스를 제공하는 방법을 설명하기 위해 도시한 순서도이고, 및
도 24는 본 발명의 다른 실시 예에 따라 NRT 서비스를 제공하는 방법을 설명하기 위해 도시한 순서도이다.
이하 상기의 목적을 구체적으로 실현할 수 있는 본 발명의 바람직한 실시 예를 첨부한 도면을 참조하여 설명한다. 이때, 도면에 도시되고 또 이것에 의해서 설명되는 본 발명의 구성과 작용은 적어도 하나의 실시 예로서 설명되는 것이며, 이것에 의해서 본 발명의 기술적 사상과 그 핵심 구성 및 작용이 제한되지는 않는다.
본 발명에서 사용되는 용어의 정의
본 발명에서 사용되는 용어는 본 발명에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 발명의 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서, 본 발명에서 사용되는 용어는 단순한 용어의 명칭이 아닌 그 용어가 가지는 의미와 본 발명의 전반에 걸친 내용을 토대로 정의되어야 함을 밝혀두고자 한다.
본 발명에서 사용되는 용어 중 메인 서비스 데이터는 고정형 수신 시스템에서 수신할 수 있는 데이터로서, 오디오/비디오(A/V) 데이터를 포함할 수 있다. 즉, 상기 메인 서비스 데이터에는 HD(High Definition) 또는 SD(Standard Definition)급의 A/V 데이터가 포함될 수 있으며, 데이터 방송을 위한 각종 데이터가 포함될 수도 있다. 그리고 기지(Known) 데이터는 송/수신 측의 약속에 의해 미리 알고 있는 데이터이다.
본 발명에서 사용되는 용어 중 M/H(또는 MH)는 모바일(Mobile), 핸드헬드(Handheld) 각각의 첫 글자이며, 고정형에 반대되는 개념이다. 그리고 M/H 서비스 데이터는 모바일 서비스 데이터, 핸드헬드 서비스 데이터 중 적어도 하나를 포함하며, 설명의 편의를 위해 본 발명에서는 M/H 서비스 데이터를 모바일 서비스 데이터라 하기도 한다. 즉, 본 발명에서 MH, M/H, 모바일은 모두 동일한 의미로 사용된다. 이때, 상기 모바일 서비스 데이터에는 M/H 서비스 데이터뿐만 아니라, 이동이나 휴대를 의미하는 서비스 데이터는 어느 것이나 포함될 수 있으며, 따라서 상기 모바일 서비스 데이터는 상기 M/H 서비스 데이터로 제한되지 않을 것이다.
상기와 같이 정의된 모바일 서비스 데이터는 프로그램 실행 파일, 주식 정보 등과 같이 정보를 갖는 데이터일 수도 있고, A/V 데이터일 수도 있다. 특히, 상기 모바일 서비스 데이터는 휴대용이나 이동형 단말기(또는 방송 수신기)를 위한 서비스 데이터로서 메인 서비스 데이터에 비해서 작은 해상도와 작은 데이터 율을 가지는 A/V 데이터가 될 수도 있다. 예를 들어, 기존 메인 서비스를 위해 사용하는 A/V 코덱(Codec)이 MPEG-2 코덱이라면, 모바일 서비스를 위한 A/V 코덱으로는 보다 영상 압축 효율이 좋은 MPEG-4 AVC(Advanced Video Coding), SVC(Scalable Video Coding) 등의 방식이 사용될 수도 있다. 또한, 상기 모바일 서비스 데이터로 어떠한 종류의 데이터라도 전송될 수 있다. 일례로, 실시간으로 교통 정보를 방송하기 위한 TPEG(Transport Protocol Expert Group) 데이터가 모바일 서비스 데이터로 전송될 수 있으며, 본 발명과 관련하여, NRT 서비스가 모바일 서비스 데이터로 전송될 수 있다.
또한, 상기 모바일 서비스 데이터를 이용한 데이터 서비스로는 날씨 서비스, 교통 서비스, 증권 서비스, 시청자 참여 퀴즈 프로그램, 실시간 여론 조사, 대화형 교육 방송, 게임 서비스, 드라마의 줄거리, 등장인물, 배경음악, 촬영장소 등에 대한 정보 제공 서비스, 스포츠의 과거 경기 전적, 선수의 프로필 및 성적에 대한 정보 제공 서비스, 상품 정보 및 이에 대한 주문 등이 가능하도록 하는 서비스별, 매체별, 시간별, 또는 주제별로 프로그램에 대한 정보 제공 서비스 등이 될 수 있으며, 본 발명은 이에 한정하지는 않는다.
본 발명의 송신 시스템은 기존 수신 시스템에서 메인 서비스 데이터를 수신하는데 전혀 영향을 주지 않으면서(backward compatible), 동일 또는 다른 물리적 채널에 메인 서비스 데이터와 NRT 서비스를 포함한 모바일 서비스 데이터를 다중화하여 전송할 수 있도록 한다.
본 발명의 송신 시스템은 모바일 서비스 데이터에 대해 추가적인 부호화를 수행하고, 송/수신 측 모두가 미리 알고 있는 데이터 즉, 기지(known) 데이터를 삽입하여 전송할 수 있도록 한다.
이러한 본 발명에 따른 송신 시스템을 사용하면 수신 시스템에서는 NRT 서비스를 포함한 모바일 서비스 데이터의 이동 수신이 가능하며, 또한 채널에서 발생하는 각종 왜곡(distortion)과 노이즈(noise)에도 모바일 서비스 데이터의 안정적인 수신이 가능하다.
NRT 서비스 개념도
도 1은 NRT 서비스에 대한 개념도를 도시한 것이다.
방송국은 기존 방식에 따라 RT(Real Time) 서비스를 송신한다. 이때, 방송국은 RT 서비스를 송신하고 그 과정에서 남는 대역폭(Bandwidth)을 이용하거나 또는 전용 대역폭을 이용하여 NRT(Non Real Time) 서비스를 제공할 수 있다. 여기서, 상기 NRT 서비스에는 뉴스 클립(News Clip), 날씨 정보, 광고, Push VOD(Video On Demand)를 위한 컨텐트 등이 포함될 수 있다.
다만, 종래 DTV 수신기 즉, 레거시 디바이스(legacy device)는, 채널 내 포함된 NRT 스트림에 의해 그 동작이 영향을 받지 않는 것이 원칙이다. 따라서, 종래 DTV 수신기는 방송국에 의해 제공되는 NRT 서비스를 수신하여 적절하게 처리함에 있어서 문제점이 있다.
반면, 본 발명에 따른 방송 수신기 즉, NRT 디바이스는, RT 서비스와 결합된 NRT 서비스를 수신하여 적절하게 처리할 수 있어 시청자에게 종래 DTV 수신기에 비해 다양한 기능을 제공할 수 있다.
여기서, RT 서비스와 NRT 서비스는 동일 또는 다른 DTV 채널을 통해 전송되며, IP 데이터그램을 통해 전송된다. 그러므로, 수신기는 동일한 채널을 통해 전송되는 두 서비스를 구분하여야 할 필요가 있다. 이를 위해 본 명세서에서는 수신기에서 NRT 서비스를 수신하여 적절히 처리할 수 있도록 시그널링 정보를 정의하고 제공하는 것에 대해 설명한다.
수신 시스템
도 2는 본 발명의 일 실시 예에 따른 수신 시스템의 구성 블록도를 도시한 도면이다.
도 2의 수신 시스템은, 시스템 전체를 제어하는 오퍼레이션 컨트롤러(100), 튜너(111), 복조기(112), 등화기(113), 기지 데이터 검출기(114), 블록 디코더(115), 프라이머리 RS 프레임 디코더(116), 세컨더리 RS 프레임 디코더(117), 시그널링 디코더(118) 및 베이스밴드 제어기(119)를 포함한다. 여기서, 상기 수신 시스템은 FIC 핸들러(121), 서비스 매니저(122), 서비스 시그널링 핸들러(123) 및 제1 저장부(124)를 더 포함할 수 있다. 그리고 상기 수신 시스템은, 프라이머리 RS 프레임 버퍼(131), 세컨더리 RS 프레임 버퍼(132), 및 트랜스포트 패킷(TP) 핸들러(133)를 더 포함할 수 있다. 또한, 상기 수신 시스템은, IP(Internet Protocol) 데이터그램 핸들러(141), 디스크램블러(142), UDP(User Datagram Protocol) 데이터그램 핸들러(143), RTP/RTCP(Real-time Transport Protocol/Real-time Transport Control Protocol) 데이터그램 핸들러(144), NTP(Network Time Protocol) 데이터그램 핸들러(145), 서비스 보호(service protection) 스트림 핸들러(146), 제2 저장부(147), ALC/LCT(Asynchronous Layered Coding/Layered Coding Transport) 스트림 핸들러(148), 디콤프레서(decompressor)(149), XML(Extensible Mark-up Language) 파서(150) 및 FDT 핸들러(151)를 더 포함할 수 있다. 그리고 상기 수신 시스템은, A/V 디코더(161), 파일 디코더(162), 제3 저장부(163), 미들웨어 엔진(164) 및 SG 핸들러(165)를 더 포함할 수 있다. 또한, 상기 수신 시스템은, EPG 매니저(171), 어플리케이션 매니저(172) 및 UI(User Interface) 매니저(173)를 더 포함할 수 있다.
이하 본 명세서에서는 설명의 편의를 위해, 튜너(111), 복조기(112), 등화기(113), 기지 데이터 검출기(114), 블록 디코더(115), 프라이머리 RS 프레임 디코더(116), 세컨더리 RS 프레임 디코더(117), 시그널링 디코더(118) 및 베이스밴드 제어기(119)를 포함하여 베이스밴드 프로세서(110)라 칭하고, FIC 핸들러(121), 서비스 매니저(122), 서비스 시그널링 핸들러(123) 및 제1 저장부(124)를 포함하여 서비스 디멀티플렉서(120)라 칭한다. 또한, 프라이머리 RS 프레임 버퍼(131), 세컨더리 RS 프레임 버퍼(132) 및 트랜스포트 패킷 핸들러(133)를 포함하여 IP 어뎁테이션 모듈(130)이라 칭하고, IP 데이터그램 핸들러(141), 디스크램블러(142), UDP 데이터그램 핸들러(143), RTP/RTCP 데이터그램 핸들러(144), NTP 데이터그램 핸들러(145), 서비스 보호(service protection) 스트림 핸들러(146), 제2 저장부(147), ALC/LCT 스트림 핸들러(148), 디콤프레서(decompressor)(149) 및 FDT 핸들러(151)를 포함하여 커먼 IP 모듈(140)이라 칭한다. 또한, 상기 A/V 디코더(161), 파일 디코더(162), 제3 저장부(163), 미들웨어 엔진(164) 및 SG 핸들러(165)를 포함하여 어플리케이션 모듈(160)이라 칭한다.
도 2에서 사용되는 용어는 현재 널리 사용되는 일반적인 용어를 선택하였으나, 새로운 기술의 출현에 따라 본 발명에서 출원인이 가장 적합하다고 판단한 용어도 임의로 사용하였으며, 이에 대해서는 해당 설명부분에서 용어의 의미를 명확히 설명하기로 한다. 따라서, 본 발명을 이해함에 있어 단순한 용어의 명칭이 아닌 용어가 가지는 의미로서 본 발명을 파악하여야 됨을 밝혀 두고자 한다.
이와 같이 구성된 도 2에서 오퍼레이션 컨트롤러(100)는 상기 베이스밴드 프로세서(110)의 각 블록의 동작을 제어한다.
튜너(111)는 특정 물리 채널(또는 물리 전송 채널, physical transmission channel, PTC)의 주파수로 수신 시스템을 튜닝하여 고정형 방송 수신장치를 위한 방송 신호인 메인 서비스 데이터와 이동형 방송 수신장치를 위한 방송 신호인 모바일 서비스 데이터를 수신한다. 상기 튜너(111)는 튜닝된 특정 채널의 주파수를 중간주파수(IF: Intermediate Frequency) 신호로 다운 컨버전하여 복조기(112)와 기지 데이터 검출기(114)로 출력한다. 상기 튜너(111)로부터 출력되는 통과대역 디지털 IF 신호는 메인 서비스 데이터만 포함할 수도 있고, 모바일 서비스 데이터만 포함할 수도 있으며, 메인 서비스 데이터와 모바일 서비스 데이터를 함께 포함할 수도 있다.
복조기(112)는 튜너(111)로부터 입력되는 통과 대역의 디지털 IF 신호에 대해 자동 이득 제어, 반송파 복구 및 타이밍 복구 등을 수행하여 기저대역 신호로 만든 후 등화기(113)와 기지 데이터 검출기(114)로 출력한다. 상기 복조기(112)는 타이밍 복원이나 반송파 복구 시에 상기 기지 데이터 검출기(114)로부터 입력받는 기지 데이터 심볼 열을 이용하여 복조 성능을 향상시킬 수 있다.
등화기(113)는 복조기(112)에서 복조된 신호에 포함된 채널 상의 왜곡을 보상한 후 블록 디코더(115)로 출력한다. 상기 등화기(113)는 기지 데이터 검출기(114)로부터 입력받는 기지 데이터 심볼 열을 이용함으로써, 등화 성능을 향상시킬 수 있다. 또한, 상기 등화기(113)는 상기 블록 디코더(115)의 디코딩 결과를 피드백 받아 등화 성능을 향상시킬 수도 있다.
기지 데이터 검출기(114)는 복조기(112)의 입/출력 데이터 즉, 복조가 이루어지기 전의 데이터 또는 복조가 일부 이루어진 데이터로부터 송신 측에서 삽입한 기지 데이터 위치를 검출하고 위치 정보와 함께 그 위치에서 발생시킨 기지 데이터의 시퀀스(Sequence)를 복조기(112), 등화기(113) 및 오퍼레이션 컨트롤러(100)로 출력한다. 또한, 상기 기지데이터 검출기(114)는 송신 측에서 추가적인 부호화를 거친 모바일 서비스 데이터와 추가적인 부호화를 거치지 않은 메인 서비스 데이터를 블록 디코더(115)에서 구분할 수 있도록 하기 위한 정보를 블록 디코더(115)로 출력한다.
블록 디코더(115)는 등화기(113)에서 채널 등화된 후 입력되는 데이터가 송신 측에서 serial concatenated convolution code (SCCC) 방식의 블록 인코딩과 트렐리스 인코딩이 모두 수행된 데이터(즉, RS 프레임 내 데이터, 시그널링 데이터)이면 송신 측의 역으로 트렐리스 디코딩 및 블록 디코딩을 수행하고, 블록 인코딩은 수행되지 않고 트렐리스 인코딩만 수행된 데이터(즉, 메인 서비스 데이터)이면 트렐리스 디코딩만을 수행한다.
시그널링 디코더(118)는 등화기(113)에서 채널 등화된 후 입력되는 시그널링 데이터의 디코딩을 수행한다. 상기 시그널링 디코더(118)로 입력되는 시그널링 데이터(또는 시그널링 정보)는 송신 시스템에서 블록 인코딩과 트렐리스 인코딩이 모두 수행된 데이터라고 가정한다. 이러한 시그널링 데이터로는 TPC(Transmission Parameter Channel) 데이터와 FIC(Fast Information Channel) 데이터를 일 예로 들 수 있다. 예를 들면, 상기 시그널링 디코더(118)는 입력되는 데이터 중 시그널링 정보 영역의 데이터에 대해 parallel concatenated convolution code (PCCC) 방식의 회귀적 터보 디코딩을 수행한 후, 터보 디코딩된 시그널링 데이터로부터 FIC 데이터와 TPC 데이터를 분리한다. 또한, 상기 시그널링 디코더(118)는 상기 분리된 TPC 데이터에 대해 송신 측의 역으로 RS 디코딩을 수행하여 오퍼레이션 컨트롤러(100)로 출력한다. 그리고 상기 시그널링 디코더(118)는 상기 분리된 FIC 데이터에 대해 서브 프레임 단위로 디인터리빙을 수행하고, 송신 측의 역으로 RS 디코딩을 수행한 후 FIC 핸들러(121)로 출력한다. 상기 시그널링 디코더(118)에서 디인터리빙 및 RS 디코딩되어 FIC 핸들러(121)로 출력되는 FIC 데이터의 전송 단위는 FIC 세그먼트이다.
FIC 핸들러(121)는 시그널링 디코더(118)로부터 FIC 데이터를 입력 받아 서비스 획득을 위한 시그널링 정보 즉, 앙상블과 모바일 서비스 간의 매핑 정보를 추출한다. 이를 위해 상기 FIC 핸들러(121)는 FIC 세그먼트 버퍼, FIC 세그먼트 파서 및 FIC 청크 파서를 포함할 수 있다.
FIC 세그먼트 버퍼는 시그널링 디코더(118)로부터 입력되는 M/H 프레임 단위의 FIC 세그먼트 그룹을 버퍼링한 후 FIC 세그먼트 파서로 출력한다. 상기 FIC 세그먼트 파서는 상기 FIC 세그먼트 버퍼에 저장된 각 FIC 세그먼트의 헤더를 추출하여 분석하고, 분석 결과에 따라 해당 FIC 세그먼트의 페이로드를 FIC 청크 파서로 출력한다. 상기 FIC 청크 파서는 상기 FIC 세그먼트 파서에서 분석된 결과를 이용하여 FIC 세그먼트 페이로드들로부터 FIC 청크 데이터 구조를 복원하고 분석하여 서비스 획득을 위한 시그널링 정보를 추출한다. 상기 FIC 청크 파서에서 획득된 시그널링 정보는 서비스 매니저(122)로 출력된다.
한편, 서비스 시그널링 핸들러(123)는 서비스 시그널링 버퍼와 서비스 시그널링 파서를 포함하여 구성하고, 상기 UDP 데이터그램 핸들러(143)로부터 전송되는 서비스 시그널링 채널의 테이블 섹션들 예를 들어, SMT 섹션들을 버퍼링한 후 분석하고 처리한다. 상기 서비스 시그널링 핸들러(123)에서 처리된 SMT 정보도 서비스 매니저(122)로 출력된다.
상기 SMT 섹션 또는 상기 SMT 섹션을 전송하는 서비스 시그널링 채널은 Well-known IP desination address와 well-known destination UDP port number를 가지는 UDP/IP 패킷 형태로 해당 RS 프레임에 포함되어 수신되는 것을 일 실시예로 한다. 따라서, 수신 시스템에서 별도의 정보를 요구하지 않고 상기 SMT 섹션 및 각 SMT 섹션의 디스크립터들을 처리할 수 있다.
또한 상기 SMT 섹션은 상기 SMT 섹션이 포함된 앙상블 내 모든 서비스에 대한 시그널링 정보(IP 접속 정보 포함)를 제공한다. 그러므로, 상기 SMT로부터 처리된 정보를 이용하여 수신을 원하는 서비스에 속한 IP 스트림 콤포넌트를 억세스하여, 사용자에게 해당 서비스를 제공할 수 있다.
상기 SMT로부터 처리된 정보는 서비스 매니저(122)에 의해 수집되어 제1 저장부(124)에 저장된다. 상기 서비스 매니저(122)는 상기 SMT에서 추출된 정보를 서비스 맵 형태로 상기 제1 저장부(124)에 저장한다.
서비스 매니저(122)는 FIC 핸들러(121)와 서비스 시그널링 핸들러(123)로부터 수집한 시그널링 정보를 이용하여 서비스 맵을 구성하고, 서비스 가이드(SG) 핸들러(165)로부터 수집한 서비스 가이드(SG)를 이용하여 프로그램 가이드를 작성한다. 그리고 상기 구성된 서비스 맵과 작성된 서비스 가이드를 참조하여 유저(User)가 원하는 모바일 서비스를 수신할 수 있도록 오퍼레이션 컨트롤러(100)를 제어하고 또한, 유저의 입력에 따라 프로그램 가이드가 화면의 적어도 일부에 디스플레이 될 수 있도록 제어한다.
오퍼레이션 컨트롤러(100)는 서비스 매니저(122)에서 작성된 서비스 맵 및 서비스 가이드를 저장한다. 또한, 상기 오퍼레이션 컨트롤러(100)는 상기 서비스 매니저(122) 및 EPG 매니저(171)의 요청에 따라 필요한 데이터를 추출하여 서비스 매니저(122) 및/또는 EPG 매니저(171)로 전달한다.
오퍼레이션 컨트롤러(100)는 기지 데이터 위치 정보 및 TPC 데이터를 입력 받아 M/H 프레임 시간 정보, 선택된 퍼레이드(Parade)의 데이터 그룹 존재 유무, 데이터 그룹 내의 기지 데이터의 위치 정보, 전력 제어 정보 등을 베이스밴드 프로세서(110)의 각 블록에 전달한다. 상기 TPC 데이터의 상세한 설명은 뒤에서 하기로 한다.
한편, 본 발명에 따르면, 송신 시스템에서는 인코딩 단위로 RS 프레임 개념을 사용하고 있다. 상기 RS 프레임은 프라이머리 RS 프레임(Primary RS Frame)과 세컨더리 RS 프레임(Secondary RS Frame)으로 구분한다. 본 발명에서 프라이머리 RS 프레임과 세컨더리 RS 프레임의 구분은 데이터의 중요도에 따르는 것을 일 실시 예로 한다.
프라이머리 RS 프레임 디코더(116)는 블록 디코더(115)의 출력을 입력으로 받는다. 이때, 상기 프라이머리 RS 프레임 디코더(116)는 RS(Reed Solomon) 인코딩 및/또는 CRC(Cyclic Redundancy Check) 인코딩된 모바일 서비스 데이터 또는 NRT 서비스 데이터를 상기 블록 디코더(115)로부터 입력 받는 것을 일 실시 예로 한다. 상기 프라이머리 RS 프레임 디코더(116)는 RS(Reed Solomon) 인코딩 및/또는 CRC(Cyclic Redundancy Check) 인코딩된 SMT 섹션 데이터 또는 OMA BCAST SG 데이터를 상기 블록 디코더(115)로부터 입력 받을 수 있다.
즉, 프라이머리 RS 프레임 디코더(116)는 메인 서비스 데이터가 아닌 데이터 예를 들어, 모바일 서비스 데이터, NRT 서비스 데이터, SMT 섹션 데이터, OMA BCAST SG 데이터 중 적어도 하나를 수신한다. 상기 프라이머리 RS 프레임 디코더(116)는 송신 시스템의 RS 프레임 인코더(미도시)의 역과정을 수행하여, 프라이머리 RS 프레임 내의 에러들을 정정한다. 즉, 상기 프라이머리 RS 프레임 디코더(116)는 다수의 데이터 그룹을 모아 프라이머리 RS 프레임을 형성한 후, 프라이머리 RS 프레임 단위로 에러 정정을 수행한다. 다시 말해, 상기 프라이머리 RS 프레임 디코더(116)는 실제 방송 서비스 등을 위하여 전송되는 프라이머리 RS 프레임을 디코딩한다. 상기 프라이머리 RS 프레임 디코더(116)에서 디코딩된 프라이머리 RS 프레임은 프라이머리 RS 프레임 버퍼(131)로 출력된다. 상기 프라이머리 RS 프레임 버퍼(131)는 상기 프라이머리 RS 프레임을 버퍼링한 후 각 로우(row) 단위로 M/H TP를 구성하여 TP 핸들러(133)로 출력한다.
세컨더리 RS 프레임 디코더(117)는 블록 디코더(115)의 출력을 입력으로 받는다. 이때 상기 세컨더리 RS 프레임 디코더(117)도 RS(Reed Solomon) 인코딩 및/또는 CRC(Cyclic Redundancy Check) 인코딩된 모바일 서비스 데이터 또는 NRT 서비스 데이터를 상기 블록 디코더(115)로부터 입력 받는 것을 일 실시 예로 한다. 상기 세컨더리 RS 프레임 디코더(117)는 RS(Reed Solomon) 인코딩 및/또는 CRC(Cyclic Redundancy Check) 인코딩된 SMT 섹션 데이터 또는 OMA BCAST SG 데이터를 상기 블록 디코더(115)로부터 입력 받을 수 있다.
즉, 상기 세컨더리 RS 프레임 디코더(117)는 메인 서비스 데이터가 아닌 데이터 예를 들어, 모바일 서비스 데이터, NRT 서비스 데이터, SMT 섹션 데이터, OMA BCAST SG 데이터 중 적어도 하나를 수신한다. 상기 세컨더리 RS 프레임 디코더(117)는 송신 시스템의 RS 프레임 인코더(미도시)의 역과정을 수행하여, 세컨더리 RS 프레임 내의 에러들을 정정한다. 즉, 상기 세컨더리 RS 프레임 디코더(117)는 다수의 데이터 그룹을 모아 세컨더리 RS 프레임을 형성한 후, 세컨더리 RS 프레임 단위로 에러 정정을 수행한다. 다시 말해, 상기 세컨더리 RS 프레임 디코더(117)는 모바일 오디오 서비스 데이터, 모바일 비디오 서비스 데이터, 가이드 데이터 등을 위하여 전송되는 세컨더리 RS 프레임을 디코딩한다. 상기 세컨더리 RS 프레임 디코더(117)에서 디코딩된 세컨더리 RS 프레임의 데이터는 세컨더리 RS 프레임 버퍼(132)로 출력된다. 상기 세컨더리 RS 프레임 버퍼(132)는 상기 세컨더리 RS 프레임을 버퍼링한 1후 각 로우(row) 단위로 M/H TP를 구성하여 TP 핸들러(133)로 출력한다.
TP 핸들러(133)는 TP 버퍼와 TP 파서로 구성되며, 상기 프라이머리 및 세컨더리 RS 프레임 버퍼(131,132)로부터 전달받은 M/H TP를 버퍼링한 후, 버퍼링된 M/H TP의 각 헤더를 추출하고 분석하여 해당 M/H TP의 페이로드로부터 IP 데이터그램을 복원한다. 그리고 복원된 IP 데이터그램은 IP 데이터그램 핸들러(141)로 출력한다.
IP 데이터그램 핸들러(141)는 IP 데이터그램 버퍼와 IP 데이터그램 파서로 구성되며, 상기 TP 핸들러(133)로부터 전달받은 IP 데이터그램을 버퍼링한 후, 버퍼링된 IP 데이터그램의 헤더를 추출하고 분석하여 해당 IP 데이터그램의 페이로드로부터 UDP 데이터그램을 복원한다. 그리고 복원된 UDP 데이터그램은 UDP 데이터그램 핸들러(143)로 출력한다.
이때 상기 UDP 데이터그램이 스크램블되어 있다면, 상기 스크램블된 IP 데이터그램은 디스크램블러(142)에서 디스크램블된 후 UDP 데이터그램 핸들러(143)로 출력된다. 일 예로, 상기 디스크램블러(142)는 수신된 IP 데이터그램 중 UDP 데이터그램에 스크램블이 적용된 경우, 상기 서비스 보호 스트림 핸들러(146)로부터 인크립션 키(Encryption key) 등을 입력받아 상기 UDP 데이터그램을 디스크램블한 후 UDP 데이터그램 핸들러(143)로 출력한다.
상기 UDP 데이터그램 핸들러(143)는 UDP 데이터그램 버퍼와 UDP 데이터그램 파서로 구성되며, 상기 IP 데이터그램 핸들러(141) 또는 디스크램블러(142)로부터 입력되는 UDP 데이터그램을 버퍼링한 후, 버퍼링된 UDP 데이터그램의 헤더를 추출하고 분석하여 해당 UDP 데이터그램의 페이로드로 전송되는 데이터를 복원한다. 이때 복원된 데이터가 RTP/RTCP 데이터그램이면 RTP/RTCP 데이터그램 핸들러(144)로 출력하고, NTP 데이터그램이면 NTP 핸들러(145)로 출력된다. 또는 복원된 데이터가 서비스 보호 스트림이면 서비스 보호 스트림 핸들러(146)로 출력하고, ALC/LCT 스트림이면 ALC/LCT 스트림 핸들러(148)로 출력한다. 또한 복원된 데이타가 SMT 섹션 데이터이면 서비스 시그널링 섹션 핸들러(123)로 출력한다.
상기 SMT 섹션 또는 상기 SMT 섹션을 전송하는 서비스 시그널링 채널은 Well-known IP desination address와 well-known desination UDP port number를 가지는 IP 데이터그램이므로, 상기 IP 데이터그램 핸들러(141)와 UDP 데이터그램 핸들러(143)는 별도의 정보를 요구하지 않고 상기 SMT 섹션이 포함된 데이터를 상기 서비스 시그널링 섹션 핸들러(123)로 출력할 수 있다.
상기 RTP/RTCP 데이터그램 핸들러(144)는 RTP/RTCP 데이터그램 버퍼와 RTP/RTCP 데이터그램 파서로 구성되며, 상기 UDP 데이터그램 핸들러(143)로부터 출력되는 RTP/RTCP 구조의 데이터를 버퍼링한 후, 버퍼링된 데이터로부터 오디오/비디오 스트림을 추출한다. 그리고 추출된 오디오/비디오 스트림은 오디오/비디오(A/V) 디코더(161)로 출력한다. 상기 A/V 디코더(161)는 상기 RTP/RTCP 데이터그램 핸들러(144)로부터 출력되는 오디오 스트림과 비디오 스트림을 각각의 디코딩 알고리즘으로 디코딩한 후 프리젠테이션 매니저(170)로 출력한다. 일 예로, 오디오 디코딩 알고리즘은 AC-3 디코딩 알고리즘, MPEG 2 audio 디코딩 알고리즘, MPEG 4 audio 디코딩 알고리즘, AAC 디코딩 알고리즘, AAC+ 디코딩 알고리즘, HE AAC 디코딩 알고리즘, AAC SBR 디코딩 알고리즘, MPEG surround 디코딩 알고리즘, BSAC 디코딩 알고리즘 중 적어도 하나를 적용하고, 비디오 디코딩 알고리즘은 MPEG 2 video 디코딩 알고리즘, MPEG 4 video 디코딩 알고리즘, H.264 디코딩 알고리즘, SVC 디코딩 알고리즘, VC-1 디코딩 알고리즘 중 적어도 하나를 적용할 수 있다.
상기 NTP 데이터그램 핸들러(145)는 NTP 데이터그램 버퍼와 NTP 데이터그램 파서로 구성되며, 상기 UDP 데이터그램 핸들러(143)로부터 출력되는 NTP 구조의 데이터를 버퍼링한 후, 버퍼링된 데이터로부터 NTP 스트림을 추출한다. 그리고 상기 추출된 NTP 스트림은 상기 A/V 디코더(161)로 출력되어 디코딩된다.
상기 서비스 보호 스트림 핸들러(146)는 서비스 보호 스트림 버퍼를 더 포함할 수 있으며, 상기 UDP 데이터그램 핸들러(143)로부터 출력되는 서비스 보호를 위한 데이터를 버퍼링한 후, 버퍼링된 데이터로부터 디스크램블을 위한 정보를 추출한다. 상기 디스크램블을 위한 정보는 SKTM, LKTM 등과 같은 디스크램블링을 위한 키 값을 포함한다. 상기 디스크램블을 위한 정보는 제2 저장부(147)에 저장되며, 필요한 경우 상기 디스크램블러(142)로 출력된다.
상기 ALC/LCT 스트림 핸들러(148)는 ALC/LCT 스트림 버퍼와 ALC/LCT 스트림 파서로 구성되며, 상기 UDP 데이터그램 핸들러(143)로부터 출력되는 ALC/LCT 구조의 데이터를 버퍼링한 후, 버퍼링된 데이터로부터 ALC/LCT 세션의 헤더 및 헤더 확장(header extension)을 분석한다. 상기 ALC/LCT 세션의 헤더 및 헤더 확장을 분석한 결과, 상기 ALC/LCT 세션으로 전송되는 데이터의 종류에 따라 FDT 핸들러(151), SG 핸들러(165) 또는 파일 디코더(162)로 출력할 수 있다.
이때, 상기 ALC/LCT 세션으로 전송되는 데이터가 압축되어 있으면, 상기 압축된 데이터는 디콤프레서(149)에서 해제된 후 파일 디코더(162)로 출력된다.
상기 FDT 핸들러(151)는 ALC/LCT session을 통하여 XML 구조로 전송되는 FLUTE 프로토콜의 파일 디스크립션 테이블(File Description Table)을 분석하고 처리한다.
상기 SG 핸들러(165)는 XML 구조로 전송되는 서비스 가이드를 위한 데이터를 수집하고 분석하여 서비스 매니저(122)로 출력한다.
상기 파일 디코더(162)는 ALC/LCT session을 통하여 전송되는 파일 구조의 데이터를 디코딩하여 미들웨어 엔진(164)으로 출력하거나, 제3 저장부(163)에 저장한다.
상기 미들웨어 엔진(164)은 파일 구조의 데이터 즉, 어플리케이션을 해석하여 실행시킨다. 그리고 상기 어플리케이션을 프리젠테이션 매니저(170)를 통해 화면이나 스피커와 같은 출력 장치로 출력할 수도 있다. 상기 미들웨어 엔진(164)은 자바(JAVA) 기반의 미들웨어 엔진인 것을 일 실시 예로 한다. 여기서, 상기 미들웨어 엔진(164)은, NRT 컨텐트 아이템 및 그와 관련된 파일들을 수신하는 과정을 제어한다. 예를 들어, 상기 미들웨어 엔진(164)은, FDT 핸들러(151), SG 핸들러(165)와 EPG 매니저(171)를 제어할 수 있다.
상기 EPG 매니저(171)는 유저의 입력에 따라 상기 서비스 매니저(122) 또는 SG 핸들러(165)로부터 EPG 데이터를 입력받아 디스플레이 포맷으로 변환한 후 프리젠테이션 매니저(170)로 출력한다.
상기 어플리케이션 매니저(172)는 오브젝트, 파일 등의 형태로 전송되는 어플리케이션 데이터의 처리에 관한 전반적인 관리를 수행한다.
상기 오퍼레이션 컨트롤러(100)는 UI 매니저(173)를 통해 입력되는 유저의 명령에 따라 상기 서비스 매니저(122), EPG 매니저(171), 어플리케이션 매니저(172), 프리젠테이션 매니저(170) 중 적어도 하나를 제어하여, 상기 유저의 명령에 따른 기능이 수행되도록 한다.
상기 UI 매니저(173)는 UI를 통해 유저의 입력을 오퍼레이션 컨트롤러(100)로 전달한다.
상기 프리젠테이션 매니저(170)는 A/V 디코더(161)에서 출력되는 오디오 및 비디오 데이터, 미들웨어 엔진(164)에서 출력되는 파일 데이터, EPG 매니저(171)에서 출력되는 EPG 데이터 중 적어도 하나를 스피커 및/또는 화면을 통해 유저에게 제공한다.
본 발명과 관련하여, 모바일 방송 서비스에 NRT 서비스가 포함될 수 있고, 상기 모바일 방송 서비스에 포함된 NRT 서비스를 시그널링하기 위한 SMT 섹션은 예를 들어, 프라이머리 RS 프레임 디코더(116)에서 추출된다. 여기서, SMT 섹션은 세컨더리 RS 프레임 디코더(117)에서 추출될 수도 있다. 이후 상기 추출된 IP 어댑테이션 모듈을 거쳐 IP 모듈에서 처리된다. 즉, IP 데이터그램 핸들러(141)에서 SMT 섹션이 포함된 IP 데이터그램을 처리하고, UDP 데이터그램까지 처리한 후에 추출된 SMT 섹션은 서비스 시그널링 섹션 핸들러(123)에서 처리된다. 또한, SMT 섹션 데이터를 제외한 FDT 데이터와 NRT 서비스 데이터들은 ALC/LCT 처리부를 거쳐 모바일 방송 수신기에서 처리되어 NRT 서비스를 제공할 수 있다.
NRT 서비스, 컨텐트 아이템, 파일의 관계 설명
도 3은 NRT 서비스, 컨텐트 아이템 및 파일에 대한 관계를 설명하기 위해 도시한 것이다.
도 3을 참조하면, 하나의 NRT 서비스는 하나 또는 그 이상의 컨텐트 아이템(content item)을 포함할 수 있고, 각 컨텐트 아이템은 적어도 하나 또는 그 이상의 파일(들)로 구성할 수 있다. 또한, 컨텐트 아이템은 하나의 독립적으로 재생 가능한 개체(entity)로서 리얼타임 방송에서의 프로그램(program) 또는 이벤트(event)에 해당할 수 있다. 따라서, NRT 서비스는 상기와 같은 컨텐트 아이템들의 조합으로 서비스 가능한 그룹을 말하며, 리얼 타임에서의 채널 개념에 해당한다.
관련하여, 모바일 서비스 환경에서 수신기는 수신되는 모바일 NRT 서비스 데이터에 대한 시그널링 정보가 충분치 않아 해당 모바일 NRT 서비스를 수신하여도 이를 적절하게 처리하기 어려운 문제가 있었다.
이에 본 발명은 상기와 같은 문제점을 해결하기 위한 것으로, 수신기에서 수신되는 모바일 NRT 서비스 데이터를 적절하게 처리할 수 있도록 시그널링 정보를 정의하고 그를 이용한 처리방법을 제공하고자 한다. 다만, 이에 대한 보다 상세한 설명은 해당 부분에서 후술하고 여기서는 간략하게 살펴본다.
이하 본 명세서에서는 모바일 NRT 서비스에 대한 시그널링을 위해 SMT(Service Map Table)와 OMA BCAST SG(Service Guide)를 이용하는 것을 예로 하여 설명한다.
우선, 수신기는 예를 들어, SMT 내 service_category 필드를 참조하여 해당 모바일 서비스가 모바일 NRT 서비스인지 여부를 식별할 수 있다. 그리고 모바일 NRT 서비스 내 하나 또는 그 이상의 컨텐트 아이템(들)은, OMA BCAST SG 내 컨텐트 식별자 정보와 FDT 내 content_id 필드를 이용하여 식별할 수 있다. 또한, 모바일 NRT 서비스는 예를 들어, SMT 내 NRT_service_id와 OMA BCAST SG 내의 서비스 식별자 정보를 이용하여 식별할 수 있다.
다만, 상기 시그널링 정보들은 서로 다른 포맷으로 정의되어 있는바, 본 명세서에서는 수신기에서 이를 처리하기 위한 서로 다른 포맷의 식별자 정보에 대한 매핑 방법도 제공하고자 한다. 따라서, 수신기는 수신되는 NRT 서비스를 적절하게 처리할 수 있게 된다.
관련하여, 모바일 NRT 서비스는 FLUTE 세션을 통해 전송되고 상기 FLUTE 세션으로부터 FDT 정보를 추출한다. 그리고 상기 추출된 FDT 정보 내 content_id는 OMA-BCAST SG의 컨텐트 식별자와 매핑하여 사용자 등에 의해 선택된 NRT 서비스 컨텐트를 확인하여 수신할 수 있다. 상기 매핑 방법에 대해 간략하게 설명하면 예를 들어, 컨텐트 아이템을 구성하는 각 파일은 FLUTE 세션 내에서의 FDT 내에 명시된 TOI 및 Content-Location 필드를 이용하여 식별하며, 상기 각 TOI 또는 Content-Location과 컨텐트 아이템의 연결은 FDT에서의 content_ID 필드를 OMA BCAST SG의 컨텐트 식별자 필드와 매핑하여 이룰 수 있다. 다만, 여기서는 본 발명에 대한 개념만을 설명하였고, 해당 부분에서 보다 상세하게 설명한다.
Mobil NRT 서비스에 대한 프로토콜
NRT 서비스는 크게 고정 NRT 서비스(Fixed NRT Service)와 모바일 NRT 서비스(Mobile NRT Service)로 구분할 수 있다. 이하 본 명세서에서는 설명의 편의를 위해 모바일 NRT 서비스를 예로 하여 설명한다.
도 4는 본 발명의 일 실시 예에 따라 구성한 모바일 NRT 서비스에 대한 프로토콜 스택(protocol stack)을 도시한 것이다.
도 4는 IP 계층과 물리 계층 사이에 적응 계층(Adaption Layer)을 포함시켜, MPEG-2 TS 포맷을 사용하지 않으면서 시그널링 정보가 포함된 IP 데이터그램을 전송할 수 있다.
도 4에서 모바일 서비스를 위한 NRT 서비스는 IP 계층에서 UDP(User Datagram protocol) 방식에 따라 패킷화되며, UDP 패킷은 다시 IP 방식에 따라 패킷화되어 UDP/IP 패킷 데이터가 된다. 상기 패킷화된 UDP/IP 패킷 데이터를 본 명세서에서는 설명의 편의를 위해 IP 데이터그램이라 한다. 또한, SMT를 포함하는 시그널링 정보 채널도 UDP(User Datagram protocol) 방식에 따라 패킷화되고, UDP 패킷은 다시 IP 방식에 따라 패킷화되어 UDP/IP 패킷 데이터가 된다.
그리고 도 4에서 OMA-BCAST 서비스 가이드(Service Guide: SG)와 NRT 컨텐트 아이템들/파일들은 FLUTE 방식에 따라 패킷화하고, 이를 다시 ALC/LCT(Asynchronous Layered Coding/Layered Coding Transport) 방식에 따라 패킷화한다. 상기 ALC/LCT 패킷은 다시 UDP 방식에 따라 패킷화되며, ALC/LCT/UDP 패킷은 다시 IP 방식에 따라 패킷화되어 ALC/LCT/UDP/IP 패킷 데이터가 된다.
또한, 적응 계층에서는, 시그널링 정보, IP 데이터그램 그리고 상기 시그널링 정보와 IP 데이터그램을 구분할 수 있는 식별 정보를 포함하는 RS 프레임을 생성한다. 즉, 상기 적응 계층은 모바일 서비스 데이터의 IP 데이터그램과 시그널링 정보 테이블의 IP 데이터그램을 구분하고, 구분된 데이터그램을 상위 계층에서 처리할 수 있도록 연결하는 데이터 링크 계층이다. 상기 RS 프레임은 모바일 물리 계층(mobile physical layer)에서 기 정해진 전송 방식 예를 들면, VSB 전송 방식으로 변조되어 수신 시스템으로 전송된다.
데이터 포맷 구조
한편, 본 발명의 실시 예에 따른 모바일 방송 기술에서 사용하고 있는 데이터 구조는 데이터 그룹 구조와 RS 프레임 구조가 있다. 이를 상술하면 다음과 같다.
도 5는 본 발명에 따른 데이터 그룹의 구조에 대한 일 실시 예를 보인 도면이다.
도 5에 따른 데이터 구성에서 데이터 그룹을 10개의 M/H 블록(M/H block B1~B10)으로 구분하는 예를 보이고 있다. 그리고 각 M/H 블록은 16 세그먼트의 길이를 갖는 것을 일 실시 예로 한다. 도 5에서 M/H 블록 B1의 앞 5 세그먼트와 M/H 블록 B10 뒤의 5 세그먼트는 일부에 RS 패리티 데이터만 할당하며, 데이터 그룹의 A 영역 내지 D 영역에서 제외하는 것을 일 실시 예로 한다.
즉, 하나의 데이터 그룹을 A, B, C, D 영역으로 구분한다고 가정하면, 데이터 그룹 내 각 M/H 블록의 특성에 따라 각 M/H 블록을 A 영역 내지 D 영역 중 어느 하나의 영역에 포함시킬 수 있다. 이때 메인 서비스 데이터의 간섭 정도에 따라 각 M/H 블록을 A 영역 내지 D 영역 중 어느 하나의 영역에 포함시키는 것을 일 실시 예로 한다.
여기서, 상기 데이터 그룹을 다수개의 영역으로 구분하여 사용하는 이유는 각각의 용도를 달리하기 위해서이다. 즉, 메인 서비스 데이터의 간섭이 없거나 적은 영역은 그렇지 않은 영역보다 강인한 수신 성능을 보일 수 있기 때문이다. 또한, 송/수신 측의 약속에 의해 알고 있는 기지(known) 데이터를 데이터 그룹에 삽입하여 전송하는 시스템을 적용하는 경우, 모바일 서비스 데이터에 연속적으로 긴 기지 데이터를 주기적으로 삽입하고자 할 때, 메인 서비스 데이터의 간섭이 없는 영역(즉, 메인 서비스 데이터가 섞이지 않는 영역)에는 일정 길이의 기지 데이터를 주기적으로 삽입하는 것이 가능하다. 그러나 메인 서비스 데이터의 간섭이 있는 영역에는 메인 서비스 데이터의 간섭으로 기지 데이터를 주기적으로 삽입하는 것이 곤란하고 연속적으로 긴 기지 데이터를 삽입하는 것도 곤란하다.
도 5의 데이터 그룹 내 M/H 블록 B4 내지 M/H 블록 B7은 메인 서비스 데이터의 간섭이 없는 영역으로서 각 M/H 블록의 앞뒤에 긴 기지 데이터 열이 삽입된 예를 보이고 있다. 본 발명에서는 상기 M/H 블록 B4 내지 M/H 블록 B7을 포함하여 A 영역(=B4+B5+B6+B7)이라 하기로 한다. 상기와 같이 각 M/H 블록마다 앞뒤로 기지 데이터 열을 갖는 A 영역의 경우, 수신 시스템에서는 기지 데이터로부터 얻을 수 있는 채널 정보를 이용하여 등화를 수행할 수 있으므로, A 영역 내지 D 영역 중 가장 강인한 등화 성능을 얻을 수가 있다.
도 5의 데이터 그룹 내 M/H 블록 B3과 M/H 블록 B8은 메인 서비스 데이터의 간섭이 적은 영역으로서, 두 M/H 블록 모두 한쪽에만 긴 기지 데이터 열이 삽입된 예를 보이고 있다. 즉, 메인 서비스 데이터의 간섭으로 인해 M/H 블록 B3은 해당 M/H 블록의 뒤에만 긴 기지 데이터 열이 삽입되고, M/H 블록 B8은 해당 M/H 블록의 앞에만 긴 기지 데이터 열이 삽입될 수 있다. 본 발명에서는 상기 M/H 블록 B3과 M/H 블록 B8을 포함하여 B 영역(=B3+B8)이라 하기로 한다. 상기와 같이 각 M/H 블록마다 어느 한쪽에만 기지 데이터 열을 갖는 B 영역의 경우, 수신 시스템에서는 기지 데이터로부터 얻을 수 있는 채널 정보를 이용하여 등화를 수행할 수 있으므로, C/D 영역보다 더 강인한 등화 성능을 얻을 수가 있다.
도 5의 데이터 그룹 내 M/H 블록 B2와 M/H 블록 B9는 메인 서비스 데이터의 간섭이 B 영역보다 더 많으며, 두 M/H 블록 모두 앞뒤로 긴 기지 데이터 열을 삽입할 수 없다. 본 발명에서는 상기 M/H 블록 B2와 M/H 블록 B9를 포함하여 C 영역(=B2+B9)이라 하기로 한다.
도 5의 데이터 그룹 내 M/H 블록 B1과 M/H 블록 B10은 메인 서비스 데이터의 간섭이 C 영역보다 더 많으며, 마찬가지로 두 M/H 블록 모두 앞뒤로 긴 기지 데이터 열을 삽입할 수 없다. 본 발명에서는 상기 M/H 블록 B1과 M/H 블록 B10을 포함하여 D 영역(=B1+B10)이라 하기로 한다. 상기 C/D 영역은 기지 데이터 열로부터 많이 떨어져 있기 때문에 채널이 빠르게 변하는 경우에는 수신 성능이 안 좋을 수가 있다.
또한, 상기 데이터 그룹은 시그널링 데이터(또는 시그널링 정보)가 할당되는 시그널링 정보 영역을 포함한다.
본 발명은 데이터 그룹 내 M/H 블록 B4의 첫 번째 세그먼트부터 두 번째 세그먼트의 일부를 시그널링 정보 영역으로 이용할 수 있다.
본 발명은 각 데이터 그룹의 M/H 블록 B4의 276(=207+69) 바이트를 시그널링 정보 영역으로 이용하는 것을 일 실시 예로 한다. 즉, 시그널링 정보 영역은 M/H 블록 B4의 첫 번째 세그먼트인 207 바이트와 두 번째 세그먼트의 처음 69 바이트로 구성된다. 상기 M/H 블록 B4의 첫 번째 세그먼트는 VSB 필드의 17번째 또는 173번째 세그먼트에 해당한다.
상기 시그널링 정보 영역으로 전송되는 시그널링 데이터는 크게 두 종류의 시그널링 채널 데이터로 구분할 수 있다. 하나는 전송 파라미터 채널(Transmission Parameter Channel; TPC) 데이터이고, 다른 하나는 고속 정보 채널(Fast Information Channel; FIC) 데이터이다.
그리고 상기 TPC 데이터는 주로 물리적 계층(Physical layer) 모듈에서 사용되는 파라미터들을 포함하며, 인터리빙이 되지 않고 전송되므로, 수신 시스템에서는 슬롯별로 억세스가 가능하다.
상기 FIC 데이터는 수신기에서 빠른 서비스 획득(fast service acquisition)이 가능하도록 하기 위해 제공되며, 물리 계층과 상위 계층 사이의 크로스 계층 정보를 포함한다. 상기 FIC 데이터는 서브 프레임 단위로 인터리빙되어 전송된다.
예를 들어, 상기 데이터 그룹이 도 5에서와 같이 6개의 기지 데이터 열을 포함하는 경우, 상기 시그널링 정보 영역은 제 1 기지 데이터 열과 제2 기지 데이터 열 사이에 위치한다. 즉, 제1 기지 데이터 열은 데이터 그룹 내 M/H 블록 B3의 마지막 2 세그먼트에 삽입되고, 제2 기지 데이터 열은 M/H 블록 B4의 두 번째와 세 번째 세그먼트에 삽입된다. 그리고 제3 내지 제6 기지 데이터 열은 M/H 블록 B4, B5, B6, B7의 마지막 2 세그먼트에 각각 삽입된다. 상기 제1, 제3 내지 제 6 기지 데이터 열은 16 세그먼트만큼 떨어져 있다.
RS 프레임 (RS Frame)
도 6은 본 발명의 일 실시 예에 따라 구성한 모바일 NRT 서비스를 포함한 RS 프레임의 구조를 도시한 것이다.
상기 RS 프레임은 타임 슬라이싱 모드로 전환된 상태에서 각 M/H 프레임마다 수신하게 된다. 하나의 RS 프레임에는 각 모바일 서비스 데이터 또는 시그널링 데이터의 IP 스트림들이 포함되며, 또한 모든 RS 프레임에는 SMT(service map table) 섹션 데이터가 존재할 수 있다. 상기 SMT 섹션 데이터는 IP 스트림 형태일 수도 있고, 다른 형태일 수도 있다. 상기 RS 프레임의 데이터는 복수 개의 데이터 그룹의 해당 영역에 할당되어 전송된다.
본 발명의 일 실시 예에 따른 RS 프레임은 적어도 하나의 M/H TP(Transport Packet)으로 이루어져 있다. 이러한 M/H TP는 M/H 헤더와 M/H 페이로드로 이루어져 있다.
상기 M/H 페이로드에는 모바일 서비스 데이터뿐만 아니라 시그널링 데이터를 포함할 수 있다. 즉, 하나의 M/H 페이로드는 모바일 서비스 데이터만을 포함할 수 있거나, 시그널링 데이터만을 포함할 수 있거나, 혹은 서비스 데이터 및 시그널링 데이터를 모두 포함할 수 있다. 여기서, 상기 모바일 서비스 데이터에는, 본 발명에 따른 NRT 서비스가 포함될 수 있다.
상기 도 6의 RS 프레임은, SMT를 위한 IP 데이터그램(IP Datagram 1), 두 종류의 모바일 서비스를 위한 IP 데이터그램(즉, IP Datagram 2, IP Datagram 3)이 할당된 예를 보이고 있다.
데이터 전송 구조
도 7은 본 발명에 따른 모바일 서비스 데이터의 송/수신을 위한 M/H 프레임 구조의 일 예를 보인 도면이다.
도 7은 하나의 M/H 프레임이 5개의 서브 프레임으로 구성되고, 하나의 서브 프레임이 16개의 슬롯으로 구성되는 예를 보이고 있다. 이 경우 하나의 M/H 프레임은 5개의 서브 프레임, 80개의 슬롯을 포함함을 의미한다.
그리고 하나의 슬롯은 패킷 레벨에서는 156개의 데이터 패킷(즉, 트랜스포트 스트림 패킷)으로, 심볼 레벨에서는 156개의 데이터 세그먼트로 구성된다. 또는 VSB 필드의 반에 해당되는 크기를 갖는다. 즉, 207 바이트의 한 데이터 패킷이 한 개의 데이터 세그먼트와 동일한 데이터 양을 가지므로 데이터 인터리빙되기 전의 데이터 패킷이 데이터 세그먼트의 개념으로 사용될 수 있다. 이때 두 개의 VSB 필드가 모여 하나의 VSB 프레임을 구성한다.
도 8은 VSB 프레임 구조의 일 예를 보인 것으로서, 하나의 VSB 프레임은 두 개의 VSB 필드(즉, odd 필드, even 필드)로 구성된다. 그리고 각 VSB 필드는 하나의 필드 동기 세그먼트와 312개의 데이터 세그먼트로 구성된다.
상기 슬롯은 모바일 서비스 데이터와 메인 서비스 데이터의 다중화를 위한 기본 시간 단위이다. 하나의 슬롯은 모바일 서비스 데이터를 포함할 수도 있고, 메인 서비스 데이터로만 구성될 수도 있다.
만일 슬롯 내 처음 118 데이터 패킷들이 하나의 데이터 그룹에 해당되면, 나머지 38 패킷들은 메인 서비스 데이터 패킷이 된다. 또 다른 예로, 하나의 슬롯에 데이터 그룹이 없다면, 해당 슬롯은 156개의 메인 서비스 데이터 패킷들로 구성된다.
한편, 하나의 RS 프레임 내 모바일 서비스 데이터는 데이터 그룹 내 A/B/C/D 영역에 모두 할당될 수도 있고, A/B/C/D 영역 중 적어도 하나의 영역에 할당될 수도 있다. 본 발명은 하나의 RS 프레임 내 모바일 서비스 데이터를 A/B/C/D 영역에 모두 할당하거나, A/B 영역과 C/D 영역 중 어느 하나에만 할당하는 것을 일 실시예로 한다. 즉, 후자의 경우, 데이터 그룹 내 A/B 영역에 할당되는 RS 프레임과 C/D 영역에 할당되는 RS 프레임이 다르다. 본 발명의 일실시예에 따르면, 데이터 그룹 내 A/B 영역에 할당되는 RS 프레임을 프라이머리 RS 프레임(Primary RS frame)이라 하고, C/D 영역에 할당되는 RS 프레임을 세컨더리 RS 프레임(Secondary RS frame)이라 하기로 한다. 그리고 프라이머리 RS 프레임과 세컨더리 RS 프레임이 하나의 퍼레이드(parade)를 구성한다. 즉, 하나의 RS 프레임 내 모바일 서비스 데이터가 데이터 그룹 내 A/B/C/D 영역에 모두 할당된다면, 하나의 퍼레이드는 하나의 RS 프레임을 전송한다. 이에 반해, 하나의 RS 프레임 내 모바일 서비스 데이터가 데이터 그룹 내 A/B 영역에 할당되고, 다른 하나의 RS 프레임 내 모바일 서비스 데이터가 해당 데이터 그룹 내 C/D 영역에 할당된다면, 하나의 퍼레이드는 두 개의 RS 프레임까지 전송할 수 있다.
즉, RS 프레임 모드(mode)는 하나의 퍼레이드가 하나의 RS 프레임을 전송하는지, 두 개의 RS 프레임을 전송하는지를 지시한다. 이러한 RS 프레임 모드는 TPC 데이터로서 전송된다.
다음의 표 1은 RS 프레임 모드의 일 예를 보인다.
표 1
Value Application Identifier Format
0x0000 DASE application
0x0001 ATSC reserved
0x0002 ATSC A/92 Application
0x0003 NRT Application
0x0004-0x7FFF ATSC reserved
0x8000-0xFFFF User private
상기 표 1은 RS 프레임 모드를 표시하기 위해 2비트가 할당되는 것을 일 실시 예로 하고 있다. 상기 표 1을 보면, RS 프레임 모드 값이 00이면, 하나의 퍼레이드가 하나의 RS 프레임을 전송함을 지시하고, RS 프레임 모드 값이 01이면, 하나의 퍼레이드가 두 개의 RS 프레임 즉, 프라이머리 RS 프레임과 세컨더리 RS 프레임을 전송함을 지시한다. 즉, 상기 RS 프레임 모드 값이 01이면, A/B 영역을 위한 프라이머리 RS 프레임(Primary RS frame for region A/B)의 데이터는 데이터 그룹의 A/B 영역에 할당되어 전송되고, C/D 영역을 위한 세컨더리 RS 프레임(Secondary RS frame for region C/D)의 데이터는 해당 데이터 그룹의 C/D 영역에 할당되어 전송됨을 지시한다.
상기 데이터 그룹의 할당과 마찬가지로, 퍼레이드들도 서브 프레임 내에서 가능한 서로 멀리 떨어져 할당하는 것을 일 실시 예로 한다. 이렇게 함으로써 하나의 서브 프레임 내에서 발생할 수 있는 버스트 에러에 대해 강력하게 대응할 수 있게 된다.
그리고 퍼레이드들의 할당 방법은 M/H 프레임마다 다르게 적용할 수 있고, 모든 M/H 프레임에 동일하게 적용할 수도 있다. 또한 하나의 M/H 프레임 내 모든 서브 프레임에 동일하게 적용할 수도 있고, 각 서브 프레임마다 다르게 적용할 수도 있다. 본 발명은 M/H 프레임마다 달라질 수 있으며, 하나의 M/H 프레임 내 모든 서브 프레임에는 동일하게 적용하는 것을 일 실시 예로 한다. 즉, M/H 프레임 구조는 M/H 프레임 단위로 달라질 수 있으며, 이것은 앙상블 데이터 율을 탄력적으로 조정할 수 있게 한다.
즉, 본 발명의 실시 예에서는 앙상블(Ensemble) 개념을 도입하여, 서비스의 집합을 정의한다. 하나의 M/H 앙상블은 동일한 QoS를 가지며, 동일한 FEC 코드로 코딩된다. 또한 하나의 앙상블은 같은 고유 식별자(즉, ensemble id)를 가지며 연속하는 RS 프레임에 대응된다.
도 9는 본 발명의 일 실시예에 따른 물리적 계층에서의 데이터 전송 구조를 도시한 도면으로, 각 데이터 그룹 내에 FIC 데이터가 포함되어 전송되는 예를 보이고 있다.
상기에서 설명한 바와 같이, 약 0.968 초 동안의 M/H 프레임은 5개의 서브 프레임으로 분할되고, 각각의 서브 프레임 내에 여러 개의 앙상블에 해당하는 데이터 그룹들이 섞여 존재하며, 각각의 앙상블에 해당하는 데이터 그룹들이 M/H 프레임 단위로 인터리빙되어 하나의 앙상블에 속하는 RS 프레임을 구성하게 된다. 도 7에서는 2개의 앙상블(NoG=4, NoG=3)이 존재한다. 또한 각각의 데이터 그룹의 일정 부분(e.g. 37 bytes/데이터 그룹)은 RS 프레임 데이터 채널과는 별도로 인코딩이 적용된 FIC 데이터를 전달하는 용도로 사용된다. 각각의 데이터 그룹에 할당되는 FIC 영역은 하나의 FIC 세그먼트를 이루며, 이 FIC 세그먼트들은 서브 프레임 단위로 인터리빙된다. 예를 들어, 상기 RS 프레임의 데이터에 RS 인코딩과 serial concatenated convolution code (SCCC) 인코딩이 적용되고, 상기 FIC 데이터에 대해 RS 인코딩과 parallel concatenated convolution code (PCCC) 인코딩이 적용되는 것을 일 실시예로 한다. 한편 TPC 데이터도 상기 FIC 데이터와 마찬가지로 RS 인코딩과 parallel concatenated convolution code (PCCC) 인코딩이 적용된다. 이때 상기 RS 프레임의 데이터는 (187+P,187)-RS 인코딩이 적용되고, 상기 FIC 데이터는 (51,37)-RS 인코딩이 적용되며, 상기 TPC 데이터는 (18,10)-RS 인코딩이 적용되는 것을 일 실시예로 한다. 여기서, P는 패리티 바이트의 개수이다.
계층적 시그널링 구조
도 10은 본 발명의 일 실시 예에 따른 계층적인 시그널링 구조를 도시한 도면이다. 본 실시 예에 따른 모바일 방송 기술은 도 10에 도시된 바와 같이, FIC와 SMT를 이용한 시그널링 방법을 채용하고 있다. 이를 본 발명에서는 계층적 시그널링 구조라 명명한다.
즉, 도 10은 FIC 청크와 IP 레벨의 모바일 서비스 시그널링 채널 중, 서비스 맵 테이블(SMT)을 통하여 서비스 획득(Service Acquisition)에 필요한 데이터를 제공하는 계층적 시그널링 구조를 나타낸다.
도 10에서 알 수 있듯이, FIC 청크는 그 빠른 특성을 이용하여, 모바일 서비스와 앙상블 간의 매핑 관계를 수신 시스템으로 전달한다. 즉, 상기 FIC 청크는 수신 시스템에서 원하는 서비스를 전달하는 앙상블을 빠르게 찾아서 해당 앙상블의 RS 프레임들을 빨리 수신할 수 있도록 하기 위한 시그널링 데이터를 수신 시스템에 제공한다.
SMT (Service Map Table)
다음으로 도 6의 RS 프레임 내 IP 데이터그램을 통해 전송되는 NRT 서비스들에 대한 시그널링 정보에 대해 설명한다. 이하에서는 상기 시그널링 정보의 하나인 SMT에 대해 설명한다.
도 11과 12는 본 발명의 일 실시 예에 따라 구성한 SMT의 비트스트림 신택스을 도시한 것이다.
여기서, 해당 신택스는 이해를 돕기 위하여 MPEG-2 프라이빗 섹션(Private section) 형태로 작성되었으나, 해당 데이터의 포맷은 어떠한 형태가 되어도 무방하다. SMT는 SMT가 전송되는 앙상블(Ensemble) 내의 서비스 정보 및 IP 접속 정보를 기술하며, 각 서비스가 속하는 브로드캐스트 스트림(Broadcast stream)의 인식자인 Transport_Stream_ID를 이용, 해당 서비스의 브로드캐스트 스트림 정보 또한 제공한다. 그리고 본 실시 예에 따른 SMT는 하나의 MH 앙상블 내의 각 모바일 서비스의 서술(Description) 정보를 포함하며, 서술자(Descriptor) 영역에 기타 부가 정보들이 포함될 수 있다.
도 11과 12를 참조할 때, SMT 섹션은 상술한 바와 같이, RS 프레임 내의 IP 스트림 형태로 포함되어 전송될 수 있다. 이 경우, 후술할 수신기의 RS 프레임 디코더들은 입력된 RS 프레임을 디코딩하고, 디코딩된 RS 프레임은 해당 RS 프레임 핸들러로 출력한다. 그리고 각 RS 프레임 핸들러는 입력된 RS 프레임을 로우(row) 단위로 구분하여 MH TP를 구성하여 MH TP 핸들러로 출력한다.
한편, SMT를 통해 전송될 수 있는 필드들의 예를 들면 다음과 같다.
table_id 필드(8비트)는 테이블의 타입을 구분시키기 위한 필드로서, 이를 통해 본 테이블 섹션이 SMT 내 테이블 섹션임을 알 수 있다(table_id: An 8-bit unsigned integer number that indicates the type of table section being defined in Service Map Table (SMT)).
section_syntax_indicator 필드(1비트)는 SMT의 섹션 형식을 정의하는 지시자로서, 섹션 형식은 예를 들어, MPEG의 short-form 신택스(0) 등이 될 수 있다(section_syntax_indicator: This 1-bit field shall be set to 0 to always indicate that this table is derived from the short form of the MPEG-2 private section table).
private_indicator 필드(1비트)는 SMT가 프라이빗 섹션을 따르는지 여부를 나타낸다(private_indicator: This 1-bit field shall be set to 1).
section_length 필드(12비트)는 해당 필드 이후의 나머지 SMT의 섹션 길이를 나타낸다(section_length: A 12-bit field. It specifies the number of remaining bytes this table section immediately following this field. The value in this field shall not exceed 4093 (0xFFD)).
table_id_extension 필드(16비트)는 테이블 종속적이고, 남은 필드들의 범위를 제공하는 table_id 필드의 논리적인 부분이 된다(table_id_extension: This is a 16-bit field and is table-dependent. It shall be considered to be logically part of the table_id field providing the scope for the remaining fields). 여기서, table_id_extension 필드는 SMT_protocol_version 필드를 포함한다.
SMT_protocol_version 필드(8비트)는 현재 프로토콜 내에서 정의된 것들과 다른 구조를 가지는 파라미터들이 전송하는 NRT SMT를 허락하기 위한 프로토콜 버전을 알려준다(SMT_protocol_version: 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).
ensemble_id 필드(8비트)는 해당 MH 앙상블과 관련된 ID값으로, 0x00에서 0x3F의 값들이 할당될 수 있다. 본 필드의 값은 TPC 데이터의 parade_id로부터 도출되는 것이 바람직하다. 만약 해당 MH 앙상블이 프라이머리 RS 프레임을 통해 전송될 경우에는 가장 상위 비트(MSB)는 0으로 설정되며, 나머지 7비트는 해당 MH 퍼레이드의 parade_id의 값으로 이용한다. 한편, 만약 해당 MH 앙상블이 세컨더리 RS 프레임을 통해 전송될 경우에는 가장 상위 비트(MSB)는 1로 설정되며, 나머지 7비트는 해당 MH 퍼레이드의 parade_id의 값으로 이용한다(ensemble_id: This 8-bit unsigned integer field in the range 0x00 to 0x3F 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 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).
version_number 필드(5비트)는 SMT의 버전 번호를 나타낸다.
current_next_indicator 필드(1비트)는 전송된 SMT 테이블 섹션이 현재 적용 가능한지 여부를 지시한다(current_next_indicator: 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).
section_number 필드(8비트)는 현재 테이블 섹션이 SMT 테이블을 구성하는 섹션들 내 섹션 넘버를 표현한다(section_number: This 8-bit field 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).
last_section_number 필드(8비트)는 SMT 테이블을 구성하는 마지막 섹션 번호를 나타낸다(last_section_number: This 8-bit field 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).
num_services 필드(8비트)는 SMT 섹션 내의 서비스의 수를 지시한다. 여기서, 만약 상기 서비스가 NRT 서비스라면, 해당 NRT 서비스의 수를 지시할 수 있다(num_services: This 8 bit field specifies the number of services in this SMT section).
한편, 본 실시 예에 따른 SMT는, for loop를 사용하여 복수의 모바일 서비스(또는 NRT 서비스)에 대한 정보를 제공한다. 이하 각 서비스에 대해 다음과 같은 필드 정보를 제공할 수 있다.
service_id 필드(16비트)는, 해당 MH 방송의 범위 내의 모바일 서비스를 유일하게 식별하기 위한 지시자이다. 상기 service_id는 해당 서비스를 통틀어 변하지 않는다. 여기서, 상기 모바일 서비스가 NRT 서비스라면, 상기 ervice_id는 각 NRT 서비스를 식별할 것이다(service_id: 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. See Annex A for a description of an allocation scheme for MH_service_id values).
Multi_ensemble_service 필드(2비트)는, 모바일 서비스가 하나 이상의 앙상블을 통해 전송되는지 여부를 식별한다. 또한, 해당 필드는 단지 모바일 서비스가 해당 앙상블을 통해 전송되는 모바일 서비스의 부분으로서 표현되는지 여부를 식별한다. 즉, NRT 서비스가 하나 이상의 앙상블을 통해 전송되는지 여부를 식별한다(multi_ensemble_service: 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. The value of this field is defined in Table 6.8).
MH_service_status 필드(2비트)는 해당 모바일 서비스의 상태를 식별한다. 여기서, MSB는 해당 모바일 서비스가 액티브(1)인지 아니면 인액티브(0)인지 지시하고, LSB는 해당 모바일 서비스가 히든(1)인지 아닌지(0)를 지시한다. 여기서, 상기 모바일 서비스가 NRT 서비스라면, 해당 NRT 서비스의 상태를 식별할 것이다(MH_service_status: 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 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).
SP_indicator 필드(1비트)는, 해당 모바일 서비스의 의미 있는 프리젠테이션을 제공하기 위해 필요한 컴포넌트들 중 적어도 하나에 적용되는 서비스 프로텍션이 설정되었으면 이를 지시하기 위함이다(SP_indicator: A 1-bit field that shall 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).
short_service_name_length 필드 (3비트)는, short_service_name 필드 내 바이트 쌍들의 넘버를 지시한다(short_service_name_length: 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).
short_service_name 필드는, 모바일 서비스의 숏 네임을 나타낸다(short_service_name: The short name of the M/H Service, each character of which shall be encoded per UTF-8 [29]. 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 0x00).
MH_service_category 필드(6비트)는, 하기의 표 2에서 규정된 바와 같이, 모바일 서비스 내에 전송되는 서비스의 타입 카테고리를 식별한다. 해당 필드의 값이 Informative only를 지시하는 값으로 설정되면, 해당 필드의 값은 서비스의 카테고리에 대한 인포머티브 디스크립션으로 다루어진다. 그리고 수신기는 MH 서비스를 통해 전송되는 서비스의 실제 카테고리를 식별하기 위해 SMT의 component_level_descriptors() 필드를 검사하는 것이 요구된다. 비디오 및/또는 오디오 컴포넌트를 가진 서비스들을 위해 그것들은 NTP 타임베이스 컴포넌트를 가진다(MH_service_category: A 6-bit enumerated type field that shall identify the type category of service carried in this M/H Service as defined in Table 7.3. When the value of this field is set to the value which is indicated Informative only, the value of this field shall be 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).
표 2
Value Encapsulated Protocol
0x00 Not in a MPEG-2 Transport Stream
0x01 Asynchronous non-flow controlled scenario of the DSM-CC Download protocol encapsulated in DSM-CC sections
0x02 Non-streaming Synchronized Download protocol 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
0x07 Synchronized streaming multiprotocol datagrams in PES using LLC/SNAP header
0x08 Synchronous streaming multiprotocol datagrams in PES using LLC/SNAP header
0x09 Synchronized streaming IP datagrams in PES
0x0A Synchronous streaming IP datagrams in PES
0x0B Proprietary Data Piping
0x0C SCTE DVS 051 asynchronous protocol [19]
0x0D Asynchronous carousel scenario of the DSM-CC Download protocol encapsulated in DSM-CC sections
0x0E Reserved for harmonization with another standard body
0x0F-0x7F ATSC reserved
0x80-0Xff User defined
특히, 본 발명과 관련하여, 수신기는 수신된 SMT 섹션 내 MH_service_category 필드의 값이 예를 들어, 0x0E의 값인 경우, 해당 모바일 서비스는 모바일 NRT 서비스임을 알 수 있다. 따라서, 수신기는 상기 MH_service_category 필드의 값이 0x0E 인 경우에는 해당 모바일 서비스가 NRT 서비스임을 식별하고, 그 결과 상기 식별된 NRT 서비스가 전송되는 FLUTE 세션에 대한 정보가 포함된 컴포넌트 레벨(component level)의 도 14의 component_descriptor를 체크하여야 한다. 여기서, 상기 component_descriptor를 체크함에 있어서, 해당 디스크립터 내 component_type 필드 값이 38이면 후술하는 도 15의 component data로 수신되는 FLUTE 세션에 대한 정보를 추출한다.
num_components 필드(5비트)는 해당 모바일 서비스 내 IP 스트림 컴포넌트의 넘버를 설명한다(num_components: This 5-bit field specifies the number of IP stream components in this M/H Service).
IP_version_flag 필드(1비트)는 1로 설정된 경우에는 source_IP_address 필드, MH_service_destination_IP_address 필드 및 component_destination_IP_address 필드가 IPv6 어드레스임을 지시하고, 0으로 설정된 경우에는 source_IP_address 필드, MH_service_destination_IP_address 필드, component_destination_IP_address 필드가 IPv4 어드레스임을 지시한다(IP_version_flag: 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).
source_IP_address_flag 필드(1비트)가 설정된 경우에는 해당 모바일 서비스를 위한 소스 IP 어드레스 값이 소스 특정 멀티캐스트를 지시하기 위해 존재함을 지시하는 플래그이다(source_IP_address_flag: 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).
MH_service_destination_IP_address_flag 필드(1비트)가 설정된 경우에는 해당 IP 스트림 컴포넌트가 MH_service_destination_IP_address와는 다른 target IP 어드레스를 갖는 IP 데이터그램을 통해 전송됨을 지시한다. 따라서 본 플래그가 설정된 경우에는 수신 시스템은 해당 IP 스트림 컴포넌트에 접근하기 위해서 component_destination_IP_address을 destination_IP_address로 사용하고, num_channels 루프 내의 MH_service_destination_IP_address 필드를 무시한다(MH_service_destination_IP_address_flag: A 1-bit Boolean flag that indicates, when set to 1, that a MH_service_destination_IP_address value is present, to serve as the default IP address for the components of this M/H Service).
source_IP_address 필드(32 또는 128비트)는 source_IP_address_flag가 1로 설정된 경우에는 해석될 필요가 있지만, source_IP_address_flag가 0로 설정되지 않은 경우에는 해석될 필요가 없다. source_IP_address_flag가 1로 설정되고 IP_version_flag 필드가 0으로 설정된 경우, 본 필드는 해당 가상 채널의 소스를 나타내는 32비트 IPv4 어드레스를 지시한다. 만약 IP_version_flag 필드가 1로 설정된 경우에는 본 필드는 해당 가상 채널의 소스를 나타내는 32비트 IPv6 어드레스를 지시한다(source_IP_address: This 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).
MH_service_destination_IP_address 필드(32 또는 128비트)는 MH_service_destination_IP_address_flag 가 1로 설정된 경우에는 해석될 필요가 있지만, MH_service_destination_IP_address_flag 가 0으로 설정된 경우에는 해석될 필요가 없다. MH_service_destination_IP_address_flag 가 1로 설정되고, IP_version_flag 필드가 0으로 설정된 경우, 본 필드는 해당 가상 채널에 대한 32비트 타겟 IPv4 어드레스를 나타낸다. MH_service_destination_IP_address_flag 가 1로 설정되고, IP_version_flag 필드가 1로 설정된 경우, 본 필드는 해당 가상 채널에 대한 64비트 타겟 IPv6 어드레스를 나타낸다. 만약 해당 MH_service_destination_IP_address를 해석할 수 없다면, num_components 루프 내의 component_destination_IP_address 필드가 해석되어야 하고, 수신 시스템은 IP 스트림 컴포넌트에 접근하기 위해서, component_destination_IP_address를 사용해야 한다(MH_service_destination_IP_address: This field shall be present if the MH_service_destination_IP_address_flag is set to 1 and shall not be present if the MH_service_destination_IP_address_flag is set to 0. If this MH_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).
한편, 본 실시 예에 따른 SMT는, for loop를 사용하여 복수의 컴포넌트에 대한 정보를 제공한다.
essential_component_indicator 필드(1비트)는, 1로 설정되어 있으면 해당 컴포넌트는 모바일 서비스를 위한 필수 컴포넌트 임을 지시한다. 그렇지 않으면, 해당 컴포넌트는 선택적인 컴포넌트임을 지시한다(essential_component_indicator: 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).
component_destination_IP_address_flag 필드(1비트)는 1로 설정되어 있으면 해당 컴포넌트를 위해 component_destination_IP_address 필드가 존재함을 지시하는 플래그이다(component_destination_IP_address_flag: A 1-bit Boolean flag that shall indicate, when set to 1, that the component_destination_IP_address is present for this component).
port_num_count 필드(6비트)는 해당 UDP/IP 스트림 컴포넌트와 관련된 UDP 포트의 넘버를 지시한다. 타겟 UDP 포트 넘버 값은 destination_UDP_port_num 필드 값으로부터 시작해서 1씩 증가한다. RTP 스트림을 위해서는, 타겟 UDP 포트 넘버는 destination_UDP_port_num 필드 값으로부터 시작해서 2씩 증가하며, 이는 RTP 스트림과 관련된 RTCP 스트림을 포함하기 위해서이다(port_num_count: This 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).
destination_UDP_port_num 필드(16비트)는 해당 IP 스트림 컴포넌트를 위한 타겟 UDP 포트 넘버를 나타낸다. RTP 스트림을 위해서는 destination_UDP_port_num의 값은 짝수이고, 다음 높은 값은 관련된 RTCP 스트림의 타겟 UDP 포트 넘버를 나타낸다(component_destination_UDP_port_num: A 16-bit unsigned integer field, that 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).
component_destination_IP_address 필드(32 또는 128비트)는 IP_version_flag 필드가 0으로 설정된 경우에는 본 필드는 해당 IP 스트림 컴포넌트를 위한 32비트 타겟 IPv4 어드레스를 지시한다. 그리고 IP_version_flag 필드가 1로 설정된 경우에는 본 필드는 해당 IP 스트림 컴포넌트를 위한 128비트 타겟 IPv6 어드레스를 지시한다(component_destination_IP_address: This 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 MH 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 MH_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).
num_component_level_descriptors 필드(4비트)는, 해당 컴포넌트를 위한 컴포넌트 레벨 디스크립터들의 수를 설명한다(num_component_level_descriptors: This 4 bit field specifies the number of component level descriptors for this component).
component_level_descriptor()은 해당 IP 컴포넌트에 대한 추가 정보를 제공하는 서술자를 나타낸다(component_level_descriptor(): One or more descriptors providing additional information for this IP stream component, may be included).
num_MH_service_level_descriptors 필드(4비트)는 해당 서비스를 위한 NRT 서비스 레벨 디스크립터들의 수를 설명한다(num_MH_service_level_descriptors: This 4 bit field specifies the number of service level descriptors for this service).
MH_service_level_descriptor()은 해당 서비스에 대한 추가 정보를 제공하는 서술자를 나타낸다. 여기에서, 모바일 서비스는 NRT 서비스를 포함할 수 있고, 해당 NRT 서비스에 대한 구체적인 서비스 타입을 알려줄 수 있다. 상기 구체적인 서비스 타입에는 예를 들어, 웹 컨텐츠를 제공하기 위한 포털 서비스, 푸쉬 VOD, A/V 다운로드 등이 있을 수 있다(MH_service_level_descriptor(): Zero or more descriptors providing additional information for this M/H Service, may be included).
num_ensemble_level_descriptors 필드(4비트)는 해당 앙상블을 위한 앙상블 레벨 디스크립터들의 수를 설명한다(num_ensemble_level_descriptors: This 4 bit field specifies the number of ensemble level descriptors for this ensemble).
ensemble_level_descriptor()은 해당 SMT가 서술하는 모바일 앙상블에 대한 추가 정보를 제공하는 서술자를 나타낸다(ensemble_level_descriptor(): Zero or more descriptors providing additional information for the M/H Ensemble which this SMT-MH describes, may be included).
Source_IP_address는 상기 서비스가 NRT 서비스인 경우, FLUTE 세션의 모든 채널을 전송하는 동일한 서버의 소스 IP 어드레스(source IP address)가 된다.
MH_service_destination_IP_Address는 이 FLUTE 세션의 세션 레벨의 목적 IP 어드레스(destination IP address)가 있으면 시그널링 된다.
Component는 FLUTE 세션 내의 채널에 매핑될 수 있으며, 각 채널 별로(세션 단위로 시그널링된 IP 어드레스와 다른) 별도의 목적 IP 어드레스(destination IP address)를 component_destination_IP_address를 통해 시그널링 할 수 있다. 또한, component_destination_UDP_port_num을 통해 목적 포트 넘버(destination port number)를 시그널링하고, port_num_count를 통해 component_destination_UDP_port_num으로부터 시작하는 목적 포트 넘버의 개수를 추가로 지정할 수 있다.
OMA-BCAST Service Guide
도 13은 본 발명의 일 실시예에 따른 서비스 가이드(SG)의 구조를 예시한 도면이다.
서비스 가이드의 엔트리 포인트 정보가 앙상블에 포함되어 전송될 경우, 수신 시스템에서는 해당 엔트리 포인트 정보를 이용하여 서비스 가이드를 기술하는 정보인 서비스 가이드 딜리버리 디스크립터(ServiceGuideDeliveryDescriptor)를 수신한다. 서비스 가이드 딜리버리 디스크립터로부터 서비스 가이드의 구조와 획득에 대한 정보를 얻을 수 있는데, 이를 이용하여 서비스 가이드 정보를 수신할 수 있다. 상기 SG는 세분화된 하위 단위로 시그널링 정보(또는 announcement 정보라 하기도 함)를 제공할 수 있으며, 세분화된 하위 단위를 프래그먼트(fragment)라고 호칭한다. 상기 SG에서 사용되는 프래그먼트로는 서비스(Service) 프래그먼트, 스케줄(Schedule) 프래그먼트, 컨텐트(Content) 프래그먼트, 퍼처스 아이템(Purchase Item) 프래그먼트, 퍼처스 데이터(Purchase Data) 프래그먼트, 퍼처스채널(Purchase Channel) 프래그먼트, 및 억세스(Access) 프래그먼트, 세션 디스크립션(session description) 프래그먼트, 프리뷰데이터(previewData) 프래그먼트, 및 인터액티브데이터(interactiveData) 프래그먼트 등이 있다. 도 13에서 화살표는 참조 관계를 나타낸다. 이 예를 따르면 퍼처스 아이템 프래그먼트, 컨텐트 프래그먼트, 스케쥴 프래그먼트, 억세스 프래그먼트는 서비스 프래그먼트를 참조할 수 있다. 스케쥴 프래그먼트는 서비스 프래그먼트와 컨텐트 프래그먼트를 참조할 수 있다. 도 12의 각 화살표 위에 예시된 수는 각 하위 단위 정보의 가능한 개수를 나타낸다. 그리고 숫자는 각 프래그먼트의 가능한 수를 나타낸다.
예시한 프래그먼트들 중 주요 프래그먼트들을 설명하면 다음과 같다.
상기 서비스 프래그먼트는 사용자에게 제공되는 서비스, 예를 들면 종래의 하나의 텔레비전 채널과 같은 서비스에 대한 정보를 포함한다.
상기 컨텐트 프래그먼트는 콘텐츠에 대한 메타데이터(metadata)를 포함한다. 예를 들어, 콘텐츠에 대한 A/V, 텍스트, 이미지 등의 타입이 컨텐트 프래그먼트에 포함된다.
또한, NRT 서비스 가이드 데이터는 서비스 프래그먼트, 스케쥴 프래그먼트 및 컨텐트 프래그먼트를 획득하여 얻을 수 있다. 여기서, 상기 NRT 서비스 가이드 데이터는 컨텐트 버전, content_id, 컨텐트 이용 가능 시간 등에 대한 정보를 포함할 수 있다.
상기 스케줄 프래그먼트는 서비스의 하나의 콘텐츠에 대한 스케줄 정보를 포함한다. 예를 들면 그 콘텐츠의 방송 시간이 이에 해당할 수 있다.
상기 퍼처스 아이템 프래그먼트는 구매에 관련된 아이템 정보를 포함한다.
상기 퍼처스 데이터 프래그먼트는 사용자가 구매할 수 있는 서비스의 구매에 관련된 정보를 포함한다. 상기 퍼처스 채널 프래그먼트는 단말기나 사용자가 구매 시스템과 소통하는 인터페이스를 의미한다. 상기 퍼처스 채널 프래그먼트는 구매 시스템에 관련된 파라미터나 구매 채널의 관리에 대한 정보를 포함한다.
상기 억세스 프래그먼트는 서비스나 컨텐트의 억세스에 관련된 정보를 포함한다.
모바일 NRT 서비스 시그널링 아키텍쳐
M/H 방송에서 NRT 서비스들의 특성을 어떻게 시그널링 되는지를 설명한다. 개별 MH NRT 컨텐트 아이템들에 대한 정보의 시그널링은 아래의 두 단계로 이루어진다. 첫째, 모든 컨텐트 아이템들의 아이템들의 리스트들, 그들의 사이즈들, 데이터 타입들과 상기 아이템들을 획득하는 것과 관련된 정보를 전달하기 위해 FLUTE 세션들의 FDT가 사용된다. 둘째, OMA-BCAST SG는 상기 아이템들에 대한 더욱 상세한 설명 정보와 그들의 전달 스케줄들을 제공한다(The signaling of information about individual M/H NRT content items is done at two levels:
1. 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.
2. The OMA BCAST Service Guide (SG) gives more detailed descriptive information about the items and their delivery schedules).
NRT_component_descriptor()
NRT 서비스를 통한 컨텐츠는 FLUTE를 통해 전송되며 SMT 테이블 상의 접속 정보는 다음과 같이 FLUTE 세션 정보를 시그널링 한다.
도 14는 본 발명의 일 실시 예에 따라 구성한 NRT 컴포넌트 디스크립터의 비트 스트림 신택스를 설명하기 위해 도시한 것이다.
NRT_component_descriptor()는 SMT 내 각 NRT 서비스의 각 컴포넌트의 컴포넌트 디스크립터 루프 내에 나타날 것이다. 그리고 해당 디스크립터 내 모든 파라미터들은 NRT 서비스의 컴포넌트들을 위해 사용되는 파라미터들에 상응한다(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).
이하 NRT_component_descriptor를 통해 전송되는 각 필드 정보에 대해 기술하면, 다음과 같다.
descriptor_tag 필드(8비트)는 해당 디스크립터(0x8D)를 식별한다(descriptor_tag: This 8-bit unsigned integer shall have the value, identifying this descriptor as the NRT_component_descriptor).
descriptor_length 필드(8비트)는 바로 다음 필드부터 해당 디스크립터의 끝까지 길이(바이트 단위)를 설명한다(descriptor_length: This 8-bit unsigned integer shall specify the length (in bytes) immediately following this field up to the end of this descriptor).
component_type 필드(7비트)는 컴포넌트의 인코딩 포맷을 식별한다. 상기 식별 값은 RTP/AVP 스트림의 payload_type을 위해 할당된 값들 중의 하나일 수 있다. 또는 본 명세서에 의해 할당된 표 3에 도시된 값들 중 하나일 수 있다. 또는 다이내믹 밸류(dynamic value)일 수 있다. RTP를 거쳐 전송되는 미디어를 구성하는 컴포넌트들을 위해 본 필드의 값들은 해당 컴포넌트를 전송하는 IP 스트림의 RTP 헤더 내 payload_type 내 값들과 일치할 것이다(component_type: This 7-bit field 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 in the range 96-127. 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. Note that additional values of the component_type field in the range of 43-71 can be defined in future versions of this standard).
NRT 서비스 스트림을 FLUTE 기반으로 전송할 경우에 FLUTE 세션에 대해 필요한 아래에 기술할 파라미터들을 추가로 시그널링하기 위하여 ATSC-M/H에서 FLUTE 컴포넌트를 위해 정의한 component_type인 38을 사용할 수도 있고, 아직 할당되지 않은 값인 43을 새로이 NRT 전송을 위한 component_type으로 정의하여 쓸 수도 있다.
표 3
component_type Meaning
0-34 Assigned or reserved by IANA, except that 20 24, 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)
37 HE AAC v2 audio stream component (assigned by 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
num_STKM_streams 필드(8비트)는, 해당 컴포넌트와 관련된 STKM 스트림들의 넘버를 식별한다(num_STKM_streams: An 8-bit unsigned integer field that shall identify the number of STKM streams associated with this component).
STKM_stream_id 필드(8비트)는, 얻어진 해당 보호된 컴포넌트를 디크립트하기 위해 키들을 있는 STKM 스트림을 식별한다. 여기서, 상기 STKM 스트림을 위한 상기 컴포넌트 디스크립터 내에 STKM_stream_id 필드를 참조한다(STKM_stream_id: An 8-bit unsigned integer field that 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).
NRT_component_data(component_type) 필드는, 해당 컴포넌트를 표현하기 위해 필요한 인코딩 파라미터들 및/또는 다른 파라미터들을 제공한다. 여기서, NRT_component_data 엘리먼트의 구조는 component_type 필드의 값에 의해 결정된다(NRT_component_data(component_type): The NRT_component_data() element 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).
FLUTE 세션들의 FDT(File Delivery Table)는 모든 컨텐트 아이템들의 아이템 리스트들을 전달하는데 사용되고, 상기 아이템들을 획득하는데 관련된 아이템들의 사이즈, 데이터 타입과 정보들을 제공한다(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).
예를 들어, 수신기는 OMA BCAST SG를 이용하여 서비스 가이드를 구성하고 표시할 수 있다. 그리고 수신기는 SMT로부터 상기 표시된 서비스 가이드에서 선택된 컨텐트가 전송되는 FLUTE 세션을 접속하기 위한 정보를 획득한다. 또한, OMA BCAST SG의 컨텐트 식별자 정보와 상기 SMT로부터 획득한 접속 정보에 근거하여 접속한 FLUTE 세션 내 파일 정보(FDT)을 통해 전송되는 파일에 대한 정보를 매핑하여 파일을 수신한다. 여기서, 상기 OMA-BCAST SG의 컨텐트 식별자 정보는 XML 포맷으로 해당 컨텐트 아이템을 글로벌리하게 유일하게 식별할 수 있는 globalContentID이거나 또는 NRT 서비스와 관련하여 별도로 정의된 NRT_content_id를 포함하는 개념으로, 바이너리 포맷의 값인 FLUTE 세션 내 파일 정보와 매핑 시에 변환이 필요하다. 다만, 상기 변환 과정은 해당 부분에서 상세하게 설명하고 여기서는 생략한다.
관련하여, FLUTE 세션을 시그널링하기 위해서는 파라미터들이 필요하고, 이러한 파라미터들에는 반드시 필요한 필수 파라미터들과 해당 FLUTE 세션과 관련되어 선택적으로 필요한 파라미터들이 있다. 우선, 필수 파라미터들에는 소스 IP 어드레스(source IP address), 세션 내 채널의 수(The number of channels in the session), 세션 내 각 채널을 위한 목적 IP 어드레스와 포트 넘버(The destination IP address and port number for each channel in the session), 세션의 TSI(The Transport Session Identifier (TSI) of the session) 및 세션의 시작시간과 종료시간(The start time and end time of the session) 파라미터가 포함되고, 해당 세션과 관련하여 선택적으로 필요한 파라미터에는, FEC 오브젝트 트랜스미션 정보(FEC Object Transmission Information), 관심 있는 파일들을 포함한 세션의 첫번째 수신 정보(Some information that tells receiver in the first place, that the session contains files that are of interest) 및 대역폭 상세(Bandwidth specification) 파라미터가 포함된다.
여기서, 상기 세션 내 채널의 개수 파라미터는 명시적으로 제공될 수도 있고, 세션을 구성하는 스트림의 개수를 합산하여 구할 수도 있다. 상기 파라미터들 중에서 본 발명에서 제안한 SMT를 통해 세션의 시작시간과 종료시간(start time and end time of the session) 파라미터가 시그널링 될 수 있고, session_description_descriptor를 통해 소스 IP 어드레스, 세션 내 각 채널을 위한 목적 IP 어드레스와 포트 넘버, 세션 내 채널의 수에 대한 파라미터가 시그널링 될 수 있다.
NRT_component_data
도 15는 도 14의 NRT 컴포넌트 디스크립터에서 component type 값이 38일 때의 NRT_component_data의 비트스트림 신택스를 설명하기 위해 도시한 것이다.
하나의 NRT 서비스는 멀티플 FLUTE 세션들에 포함될 수 있다. 각 세션은 세션들을 위해 사용되는 IP 어드레스들과 포트들에 의존하는 하나 또는 그 이상의 FLUTE 컴포넌트 디스크립터들을 이용하여 시그널링 될 수 있다(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).
이하 NRT_component_data의 각 필드에 대해 상세하게 설명하면, 다음과 같다.
TSI 필드(16비트)는 FLUTE 세션의 TSI를 지시한다(TSI: A 16-bit unsigned integer field, which shall be the Transport Session Identifier (TSI) of the FLUTE session).
session_start_time 필드는 FLUTE 세션이 시작하는 시각을 지시한다. 만약 해당 필드의 값이 모두 0이면, 세션은 이미 시작된 것으로 해석될 수 있다(session_start_time: 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).
session_end_time 필드는 FLUTE 세션이 종료되는 시각을 지시한다. 만약 해당 필드의 값이 모두 0이면, 세션은 무한정 계속되는 것으로 해석될 수 있다(session_end_time: 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).
tias_bandwidth_indicator 필드(1비트)는 TIAS(Transport Independent Application Specific) 대역폭 정보를 포함하는 플래그들을 지시한다. 만약 TIAS 대역폭 필드가 존재하는 것으로 지시하려면 해당 비트는 1로 설정되고, TIAS 대역폭 필드가 존재하지 않는 것으로 지시하려면 해당 비트는 0으로 설정되어야 할 것이다(tias_bandwidth_indicator: 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).
as_bandwidth_indicator 필드(1비트)는 AS(Application Specific) 대역폭 정보를 포함하는 플래그들이다. 만약 AS 대역폭 필드가 존재하는 것으로 지시하려면 해당 비트는 1로 설정되어야 하고, AS 대역폭 필드가 존재하지 않는 것으로 지시하려면 해당 비트는 0으로 설정되어야 할 것이다(as_bandwidth_indicator: 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).
FEC_OTI_indicator 필드(1비트)는 FEC 오브젝트 트랜스미션 정보(OTI) 정보가 제공되는지 여부를 지시한다(FEC_OTI_indicator: A 1-bit indicator that indicates whether FEC Object Transmission Information is provided).
tias_bandwidth 필드는 TIAS 최대 대역폭을 지시한다(tias_bandwidth: This value shall be one one-thousandth of the Transport Independent Application Specific maximum bandwidth as defined in RFC 3890 [16], rounded up to the next highest integer if necessary. (Note: this gives the TIAS bandwidth in kilobits per second)).
as_bandwidth 필드는 AS 최대 대역폭의 값을 가질 것이다(as_bandwidth: This value shall be the Application Specific maximum bandwidth as defined in RFC 4566 [17]. (Note: this gives the AS bandwidth in kilobits per second)).
FEC_encoding_id 필드는 해당 FLUTE 세션 내에서 사용된 FEC 인코딩 ID를 지시한다(FEC_encoding_id: FEC encoding ID used in this FLUTE session, as defined in RFC 3926 [18]).
FEC_instance_id 필드는 해당 FLUTE 세션 내에서 사용된 FEC 인스턴스 ID를 지시한다(FEC_instance_id: FEC instance ID used in this FLUTE session, as defined in RFC 3926 [18]).
상기와 같은 파라미터들을 FLUTE 컴포넌트 데이터 바이트들(FLUTE component data bytes)을 통해 시그널링함으로써 FULTE 세션을 수신하기 위해 꼭 필요한 정보들은 모두 제공할 수 있으며, 이 세션을 통해 FDT를 수신하여 이를 통해 FLUTE 세션을 통해 전달되는 모든 파일들에 대한 정보를 획득하여 이 파일들을 수신하는 방법이 사용될 수 있다.
여기서, 상기 NRT 컴포넌트 디스크립터(NRT component descriptor)는 SMT의 Component_level_descriptor 루프를 통해 전달될 수 있다. 따라서, FLUTE 채널이 복수 개일 경우에도 세션 레벨의 파라미터들인 TSI, session_start_time, session_end_Time 등은 한 번만 시그널링되면 되므로, 여러 개의 채널의 컴포넌트 중에서 하나의 컴포넌트에서만 NRT 컴포넌트 디스크립터를 Component_level_descriptor 루프를 통해 전송할 수 있다.
M/H 서비스, FLUTE 세션 및 NRT 서비스의 관계
도 16은 본 발명에 따라 M/H 서비스, FLUTE 세션 및 NRT 서비스의 관계를 설명하기 위해 도시한 것이다.
M/H 서비스들은 하나 또는 그 이상의 M/H 컴포넌트(들)을 포함하고, 각 M/H 컴포넌트는 FLUTE 채널을 통해 전송된다. FLUTE 채널은 MH 서비스 컴포넌트와 대응된다. 또한, 하나의 M/H NRT 서비스는 멀티플 FLUTE 세션들을 포함하고, 각 FLUTE 세션은 멀티플 FLUTE 채널을 포함한다. 여기서, MH 컴포넌트는, 하나의 목적 IP 어드레스와 하나의 UDP 포트 넘버로 정의된다.
예를 들어, MH NRT 서비스 A는 FLUTE 세션 1을 포함하고, 상기 FLUTE 세션 1은 MH 서비스들 중 MH 컴포넌트 1과 MH 컴포넌트 2의 TSI 1 정보에 의해 지시된다. 또한, MH NRT 서비스 B는 FLUTE 세션 2와 3을 포함하고, 상기 FLUTE 세션 2은 MH 서비스들 중 MH 컴포넌트 3과 MH 컴포넌트 4의 TSI 2 정보에 의해 지시되고, FLUTE 세션 3은 MH 컴포넌트 5의 TSI 3 정보에 의해 지시된다.
FDT 스키마(schema)에 대한 설명
도 17은 본 발명의 일 실시 예에 따른 파일과 content_id의 매핑을 위한 FDT 스키마를 설명하기 위해 도시한 것이고, 도 18은 본 발명의 다른 실시 예에 따른 파일과 content_id의 매핑을 위한 FDT 스키마를 설명하기 위해 도시한 것으로, FDT 인스턴트 레벨 엔트리 파일 지정 방식을 표현한다.
이하에서 FDT 인스턴스 레벨은, FDT에서 선언된 모든 파일의 공통 속성을 정의할 필요가 있는 경우 그에 대한 정의 부분을 포함하는 레벨을 의미하고, FDT 파일 레벨은, 각 파일에 개별적인 속성에 대한 정의를 포함하는 레벨을 의미하는 것으로 사용된다.
도 17 내지 18을 참조할 때, 1번으로 표시된 부분은 FDT-Instance 레벨(level)에서 컨텐트 식별자를 선언하는 것으로, 여기에서 선언된 컨텐트 식별자는 해당 FDT-Instance 내에서 선언된 모든 파일(file)에 부여된다. 물론 파일 레벨(File level)에서 컨텐트 식별자를 새롭게 부여함으로써 이 정보를 오버라이드(override) 할 수도 있다. 혹은 특정 파일이 FDT-Instance 레벨에 정의된 컨텐트 아이템(content item)이 아닌 다른 컨텐트 아이템에도 속한다면 하기에 설명할 파일 레벨 컨텐트 식별자를 부여하는 것을 통해 이를 알려줄 수도 있다. 본 실시 예에서는 컨텐트 식별자를 16 비트를 사용해 표현한다.
2번으로 표시된 부분은 파일 레벨에서 컨텐트 식별자를 선언하는 것으로 FDT Instance 내에 포함된 파일이 서로 다른 컨텐트 아이템에 속할 경우 이 방법을 이용해 각 파일이 어느 컨텐트 아이템에 속하는 지를 시그널링 한다.
3번은 각 파일에 대해 해당 파일이 엔트리 파일(entry file)인지 여부를 알려주기 위한 방법이다. 즉, 컨텐트 아이템을 구성하는 여러 개의 파일들 중에서 가장 먼저 재생하거나 컨텐트 아이템을 접근하기 위해 반드시 먼저 실행해야 하는 루트 파일(root file)에 해당하는 파일을 엔트리 파일이라고 하며 이러한 정보를 알려주기 위한 방법을 나타낸다. entry 속성(attribute)은 생략이 가능하며 기본 값은 false로 생략되어 있는 경우 해당 파일은 엔트리 파일이 아님을 의미한다.
이렇게 파일 레벨에서 속하는 그룹에 따른 엔트리 여부를 각각 시그널링 해줌으로써 특정 파일이 특정 그룹에서는 엔트리 역할을 수행하고 또 다른 그룹에서는 그렇지 않을 수 있다.
엔트리 파일의 실시 예로는 컨텐트 아이템이 웹 페이지(web page) 형태로 구성되었을 때, index.htm 및 기타 여러 개의 관련된 그림 및 텍스트 파일(text file)이 존재한다고 했을 때, index.htm이 바로 엔트리 파일이 된다.
FDT-instance 레벨에서 컨텐트 식별자를 부여할 경우의 엔트리 파일 여부를 알려주는 방법은 아래와 같은 두 가지 방법을 생각해 볼 수 있다.
1) 엔트리 파일에 해당되는 파일에 대하여 파일 레벨 컨텐트 식별자를 추가로 부여하고 이의 엔트리 속성을 true로 설정하는 방법: 이 경우 컨텐트 식별자가 FDT-Instance 레벨과 파일 레벨에 중복되는 단점이 있으나 가장 융통성 있는 구조를 가질 수 있다.
2) 도 18에 도시한 FDT 스키마(schema)의 또 다른 실시 예와 같이 FDT-instance 레벨의 컨텐트 식별자 정의에서 엔트리 파일의 역할을 수행하는 파일들을 직접 레퍼런스(reference) 해주는 방식을 생각할 수 있다. 이를 위해 도 18의 실시 예에서는 FDT-instance 레벨 컨텐트 식별자를 위해 FDT-Content-ID-Type을 별도로 정의하고 이를 2번으로 표시된 바와 같이 엔트리 파일의 컨텐트 로케이션(content location)을 포함할 수 있도록 확장하였다.
이 방법의 경우 컨텐트 로케이션을 중복해서 시그널링 하는 부분이 단점이 될 수 있으나 각 컨텐트 아이템별로 엔트리 파일 구성 정보를 바로 획득할 수 있다는 점이 장점이 될 수 있다.
SMT 및 FDT와 OMA-BCAST SG와의 매핑
도 19는 본 발명의 일 실시 예에 따라 구성한 시그널링 정보들의 매핑에 이용되는 수신기의 구성 블록도의 일 예를 도시한 것이다.
본 발명에 따르면, 모바일 방송 수신기는 원하는 앙상블(Ensemble)에 튜닝된 후, 해당 앙상블의 RS 프레임 데이터 중 SMT를 추출 및 처리한다. 여기서, 상기 추출/처리되는 SMT는 모바일 서비스(또는 NRT 서비스)와 IP 접속 정보의 매핑 및 각 모바일 서비스(또는 NRT 서비스)의 IP 스트림 컴포넌트의 어퀴지션에 필요한 정보를 테이블 및 디스크립터 형태로 포함한다. 또한, SMT는 섹션 단위로 분할되어 전송되며 각 섹션은 그 자체로 처리가 가능하다. 하나의 SMT 섹션은 그 SMT 섹션이 전송되는 앙상블의 가상 채널 정보를 포함한다. 각 SMT 섹션은 ensemble_id 및 section_number로 구분된다. 각 SMT 섹션은 UDP/IP로 인캡슐레이션되는데, IP 어드레스와 UDP 포트 넘버는 Well-known 값을 사용하여, 모바일 방송 수신기가 별도의 IP 접속 정보 없이도 SMT 섹션을 수신할 수 있도록 한다. 각 SMT 섹션은 바이너리 형태로 전송되며, 모바일 방송 수신기는 해당 바이너리 형태의 SMT 섹션을 처리한다.
여기서, 기본적으로 SMT 섹션의 데이터는 바이너리 형태이고, OMA-BCAST SG의 데이터는 XML 형태이다. 따라서, 상기 두 데이터는 변환을 하여야만 이후 매핑에 이용될 수 있다. 즉, 모바일 방송 수신기는 수신된 각 SMT 섹션의 바이너리 형태의 데이터 엘리먼트들을 XML 형태로 변환(conversion)하여 OMA-BCAST SG와 일관성(Consistency)을 유지한다. 여기서, 바이너리 형태의 SMT는 핸들러 내 SMT 바이너리 파서에 의해 처리되어 저장부(124)에 저장되고, 이후 매핑을 위해서 상기 저장부(124)로부터 추출되어 SMT 컨버터에 의해 XML 형태로 변환되어 SG 핸들러(165) 로 입력되고, XML 형태의 OMA-BCAST SG가 SG 핸들러(165)로 입력되면 양 데이터를 이용하여 매핑을 한다.
양 데이터의 매핑을 위한 변환 과정을 보다 상세하게 설명하면, 다음과 같다.
도 20은 본 발명의 일 실시 예에 따라 SMT 데이터와 OMA-BCAST SG 데이터를 변환하여 매핑하기 위해 연결하는 과정을 설명하기 위해 도시한 것이고, 도 22는 service_id를 변환하는 방법을 설명하기 위해 도시한 것이다.
도 20과 22를 참조하면, 모바일 방송 수신기는 매핑을 위해 바이너리 포맷의 SMT 섹션을 XML 형태로 변환한다.
예를 들어, FIC 내 transport_stream_id와 SMT 내 16비트 바이너리 타입의 service_id를 하나로 묶어 anyURI 타입으로 변환하여 OMA-BCAST SG 상의 서비스 식별자 정보(예를 들어, globalServiceID)와 매핑한다. 여기서, 상기 변환된 anyURI 타입은 예를 들어, urI:://atsc.<transport_stream_id><service_id>와 같은 포맷일 수 있다. 따라서, 수신기는, 상기 OMA-BCAST SG 상의 서비스 식별자 정보(예를 들어, globalServiceID)를 이용하여 서비스 프래그먼트를 찾을 수 있다.
또한, FDT 내 content_id를 기준으로 OMA-BCAST SG 상의 컨텐트 식별자 정보(예를 들어, globalContentID 또는 NRT_content_id)를 매핑한다. 따라서, 수신기는, 상기 매핑을 이용하여 OMA-BCAST SG 내 해당 컨텐트 프래그먼트(Content Fragment) 및 이를 참조하는 스케쥴 프래그먼트를 찾을 수 있다. 또한, 상기 FDT 내 content_id는 예를 들어, 바이너리 타입의 16비트일 수 있다.
그러므로, 본 발명에 따르면, 모바일 방송 시스템인 MH 수신 시스템은 Well-known IP 어드레스와 UDP 포트 넘버를 통하여 전송되는 바이너리 형태의 SMT와 FDT를 XML 형태로 변환, 원래 XML 형태로 전송되는 OMA-BCAST SG 내 대응되는 정보를 매핑하여 일관성을 유지할 수 있다.
NRT 시그널링 아키텍쳐 디스크립션(NRT Signaling Architechture description)
도 21은 본 발명의 일 실시 예에 따라 NRT 서비스를 통하여 접속 정보를 제공하기 위한 OMA BCAST SG Broadcast service delivery 의 XML 스키마를 설명하기 위해 도시한 것이다.
상기 과정 중에서 BCAST SG의 액세스 프래그먼트(Access Fragment)에서 NRT 서비스를 통해 전송되는 서비스에 대한 접속 정보를 시그널링하기 위하여 다음과 같은 방법을 사용할 수 있다.
브로드캐스트(Broadcast)를 통한 서비스 전달에 대한 접속 정보는 Broadcast service delivery 구조를 통해 제공된다. 도 21에 도시된 바와 같이, NRT 서비스를 통해 전달되는 서비스의 접속 정보를 제공할 수 있다. Session Description을 위한 방법으로 NRTServiceRef 엘리먼트를 추가하여 NRT 서비스에 대한 접속 정보를 제공하고자 하면 이는 NRT 서비스를 레퍼런스함으로써 SMT 테이블 상의 NRT 서비스 접속 정보를 레퍼런스하여 이를 이용하고자 하는 것이다.
이를 위해 도 21과 같이, NRT-Broadcast-Locator를 NRT 서비스가 실려오는 앙상블을 유일하게 식별하는 URI(Uivesial Resource Identifier)로 사용하고 NRT-Service-Reference를 통해 NRT 서비스 ID를 제공하여 NRT 서비스를 유일하게 식별하는 방법이 가능하다.
이와 함께 NRT-Broadcast-Locator를 다음과 같이 확장하여 하나의 URI로 NRT 서비스까지 식별할 수 있도록 하는 것도 가능할 것이다.
atsc://f=<frequency>.<program_number>[.m=<modulation_format>][/<NRT_service_ID>]
상기와 같이 NRT Service ID를 URI에 포함하여 하나의 URI로 NRT 서비스를 유일하게 식별할 수 있다.
NRT 서비스 제공 방법
도 23은 본 발명의 일 실시 예에 따라 NRT 서비스를 제공하는 방법을 설명하기 위해 도시한 순서도이다.
수신기는 OMA BCAST SG를 수신하고, 수신된 OMA BCAST SG를 처리하여 서비스 가이드를 구성하고 표시한다(S2301).
상기 표시된 서비스 가이드로부터 사용자 등에 의해 적어도 하나의 모바일 NRT 서비스 내 특정 컨텐트 아이템이 선택되면, 선택된 특정 컨텐트 아이템과 관련된 컨텐트 식별자를 획득한다(S2302).
수신기는 상기 선택된 특정 컨텐트 아이템을 수신하기 위해 시그널링 정보 중 SMT를 처리하고 읽는다(S2303).
M/H 서비스가 싱글 또는 멀티플 M/H NRT 서비스(들)을 포함하면, MH_service_category 필드를 찾아 NRT 서비스임을 식별한다(S2304). 여기서, 수신기는 MH_service_id 필드를 이용하여 원하는 NRT 서비스를 식별할 수 있다.
수신기는 SMT 내 NRT 서비스에 해당하는 각 컴포넌트를 위한 IP 어드레스와 UDP 포트 넘버 등의 세션 정보를 읽고 저장한다(S2305).
수신기는 NRT 서비스에 대한 component_descriptor()을 처리하여 FLUTE 세션에 대한 정보를 읽는다(S2306).
수신기는 각 컴포넌트에 대해 component_descriptor를 처리하여(M/H component data with type 38) 각 컴포넌트에 대한 TSI 값을 파악할 수 있다. 수신기는 상기 획득한 정보를 이용해 FLUTE 파일 딜리버리 세션에 조인(join) 하여 FDT를 읽어 상기 선택된 컨텐트 아이템에 대한 content_id를 획득한다(S2307).
상기 S2307 단계에서 획득한 content_id와 상기 S2302 단계에서 획득한 컨텐트 식별자를 매핑한다(S2308). 여기서, 상기 매핑은, 상기 S2307 단계에서 획득한 content_id와 상기 S2302 단계에서 획득한 컨텐트 식별자가 서로 다른 포맷으로 정의되기 때문이다. 상기 매핑 과정은 예를 들어, 상술한 도 20 내지 22를 참조할 수 있다.
상기 매핑 결과 상기 S2307 단계에서 획득한 content_id와 상기 S2302 단계에서 획득한 컨텐트 식별자가 일치하면, 상기 선택된 컨텐트 아이템 내의 파일을 다운로드 한다(S2309).
도 24는 본 발명의 다른 실시 예에 따라 NRT 서비스를 제공하는 방법을 설명하기 위해 도시한 순서도이다.
수신기는 NRT 서비스 내 컨텐트 아이템을 수신하기 위해 시그널링 정보 중 SMT를 처리하고 읽는다(S2401).
M/H 서비스가 싱글 또는 멀티플 M/H NRT 서비스(들)을 포함하면, MH_service_category 필드를 찾아 NRT 서비스임을 식별한다(S2402). 여기서, 수신기는 MH_service_id 필드를 이용하여 원하는 NRT 서비스를 식별할 수 있다.
수신기는 SMT 내 NRT 서비스에 해당하는 각 컴포넌트를 위한 IP 어드레스와 UDP 포트 넘버 등의 세션 정보를 읽고 저장한다(S2403).
수신기는 NRT 서비스에 대한 component_descriptor()을 처리하여 FLUTE 세션에 대한 정보를 읽는다(S2404).
수신기는 각 컴포넌트에 대해 component_descriptor를 처리하여(M/H component data with type 38) 각 컴포넌트에 대한 TSI 값을 파악할 수 있다. 수신기는 상기 획득한 정보를 이용해 FLUTE 파일 딜리버리 세션에 조인(join) 하여 FDT를 읽어 NRT 서비스 내 컨텐트 아이템에 대한 content_id를 획득한다. 상기 획득한 content_id와 해당 FLUTE 세션을 통해 전송되는 파일들을 저장한다(S2405).
수신기는 OMA BCAST SG를 수신하고, 수신된 OMA BCAST SG를 처리하여 서비스 가이드를 구성하고 표시한다(S2406).
상기 표시된 서비스 가이드로부터 사용자 등에 의해 적어도 하나의 모바일 NRT 서비스 내 특정 컨텐트 아이템이 선택되면, 선택된 특정 컨텐트 아이템과 관련된 컨텐트 식별자를 획득한다(S2407).
상기 S2405 단계에서 획득한 content_id와 상기 S2407 단계에서 획득한 컨텐트 식별자를 매핑한다(S2408). 여기서, 상기 매핑은, 상기 S2405 단계에서 획득한 content_id와 상기 S2407 단계에서 획득한 컨텐트 식별자가 서로 다른 포맷으로 정의되기 때문이다. 상기 매핑 과정은 상술한 도 20 내지 22를 참조한다.
상기 매핑 결과 상기 S2405 단계에서 획득한 content_id와 상기 S2407 단계에서 획득한 컨텐트 식별자가 일치하면, 상기 선택한 컨텐트 아이템 내의 파일을 재생한다(S2409).
상술한 도 23의 서비스 방법의 일 실시 예의 경우에는 SMT를 먼저 처리함으로써 NRT 서비스가 제공되는 FLUTE 세션에 접속하여 해당 서비스 내 컨텐트 아이템들을 수신하여 저장하고, 이후 OMA-BCAST SG를 이용해 상기 저장된 컨텐트 아이템 중 사용자 등이 원하는 컨텐트 아이템을 재생하는 플로우이다.
이에 반해 도 24의 서비스 방법의 다른 실시 예의 경우에는 OMA-BCAST SG를 먼저 처리하여 서비스 가이드를 제공하고 사용자 등이 특정 컨텐트 아이템을 선택하면, SMT를 처리하여 선택된 컨텐트 아이템이 전송되는 FLUTE 세션에 접속하여 해당 컨텐트를 수신하여 저장하고 이후 재생하는 플로우이다.
도 23의 서비스 방법과 도 24의 서비스 방법은 상술한 차이가 있으며, 도 24의 경우에는 관련 컨텐트 아이템들을 모두 수신하여 저장함으로써 사용자의 선택의 폭을 넓히고 원하는 컨텐트가 이미 저장되어 있으므로 빠른 시간 내에 재생가능하나 저장 공간의 한계가 있고 서비스 내 모든 컨텐트 아이템을 수신하여 불필요한 컨텐트 아이템도 수신함으로써 시스템의 효율성이 떨어질 수 있다. 또한, 도 24의 경우에는 원하는 컨텐트 아이템만을 수신함으로써 시스템의 효율성을 높일 수는 있으나 사용자가 다른 컨텐트 아이템을 원하는 경우 다시 서비스 가이드를 제공하고 선택되는 컨텐트 아이템을 수신하여야 하므로 재생까지 걸리는 시간이 길어질 수 있다.
지금까지 설명한 본 발명은 상술한 실시 예에 한정되지 않으며, 첨부된 청구범위에서 알 수 있는 바와 같이 본 발명이 속한 분야의 통상의 지식을 가지 자에 의해 변형이 가능하고 이러한 변형은 본 발명의 범위에 속한다.
발명의 실시를 위한 형태는 발명의 실시를 위한 최선의 형태에서 함께 기술되었다.
본원발명은 방송 및 통신 분야에서 산업상 이용가능성이 있다.

Claims (18)

  1. 비실시간 서비스를 구성하는 파일과 제1 시그널링 정보와 제2 시그널링 정보가 IP 패킷화되어 하나의 앙상블에 포함되어 수신되는 단계;
    상기 앙상블로부터 획득한 제1 시그널링 정보를 이용하여 서비스 가이드를 구성하고 표시하는 단계;
    상기 표시된 서비스 가이드에서 선택된 컨텐트에 대한 제1 컨텐트 식별 정보를 획득하는 단계;
    상기 앙상블로부터 획득한 제2 시그널링 정보를 이용하여 플루트(FLUTE) 세션에 접속하고, 접속된 플루트 세션으로부터 상기 제1 컨텐트 식별 정보와 매칭되는 제2 컨텐트 식별 정보를 획득하는 단계; 및
    상기 획득한 제2 컨텐트 식별 정보에 근거하여 해당 컨텐트를 구성하는 적어도 하나 이상의 파일들을 수신하여 저장하는 단계;를 포함하는 비실시간(NRT) 서비스 제공 방법.
  2. 제 1 항에 있어서,
    상기 NRT 서비스 획득을 위한 크로스 계층 정보를 포함하는 고속 정보 채널(FIC) 데이터와 상기 FIC의 업데이트를 식별할 수 있는 FIC 버전 정보를 포함하는 전송 파라미터 채널(TPC) 데이터를 수신하는 단계;를 더 포함하는 비실시간(NRT) 서비스 제공 방법.
  3. 제2항에 있어서,
    상기 FIC 데이터는 상기 앙상블 식별자와 트랜스포트 스트림 식별자를 포함하는 비실시간(NRT) 서비스 제공 방법.
  4. 제3항에 있어서,
    상기 수신되는 FIC 내 트랜스포트 스트림 식별자와 상기 수신되는 제2 시그널링 정보 내 서비스 식별자 정보를 하나로 묶어 특정 타입으로 변환하여 상기 제1 시그널링 정보 내 서비스 식별자 정보를 기준으로 매핑하는 비실시간 서비스 제공 방법.
  5. 제1항에 있어서,
    상기 제2 시그널링 정보는,
    미리 설정된 IP 어드레스와 UDP 포트 넘버를 갖는 UDP/IP 헤더로 인캡슐레이션되어 수신되는 비실시간(NRT) 서비스 제공 방법.
  6. 제1항에 있어서,
    상기 앙상블에 대응하는 슬롯을 타임 슬라이싱 방식으로 수신하는 비실시간 (NRT) 서비스 제공 방법.
  7. 제1항에 있어서,
    상기 제1 시그널링 정보는 OMA-BCAST 서비스 가이드이고, 상기 제2 시그널링 정보는 서비스 맵 테이블(SMT)인 비실시간 서비스 제공 방법.
  8. 제1항에 있어서,
    상기 획득한 제1 컨텐트 식별 정보는,
    해당 컨텐트에 대한 globalContentID이거나 또는 상기 비실시간 서비스와 관련하여 별도로 정의된 컨텐트 식별 정보를 포함하는 비실시간 서비스 제공 방법.
  9. 제8항에 있어서,
    상기 획득한 제1 컨텐트 식별 정보는,
    상기 획득한 제2 컨텐트 식별 정보를 기준으로 매핑하되, 상기 제2 컨텐트 식별 정보는 바이너리 타입의 16비트인 비실시간 서비스 제공 방법.
  10. 비실시간 서비스를 구성하는 파일과 제1 시그널링 정보와 제2 시그널링 정보가 IP 패킷화되어 포함된 하나의 앙상블을 수신하는 베이스밴드 프로세서부;
    상기 수신되는 앙상블로부터 제1 시그널링 정보를 획득하고, 획득한 제1 시그널링 정보를 이용하여 서비스 가이드를 구성하고 표시하는 제1 핸들러;
    상기 표시된 서비스 가이드에서 선택된 컨텐트에 대한 제1 컨텐트 식별 정보를 획득하는 제2 핸들러;
    상기 앙상블로부터 제2 시그널링 정보를 획득하고, 획득한 제2 시그널링 정보를 이용하여 플루트(FLUTE) 세션에 접속하고, 접속된 플루트 세션으로부터 상기 제1 컨텐트 식별 정보와 매칭되는 제2 컨텐트 식별 정보를 획득하는 제3 핸들러;
    상기 획득한 제2 컨텐트 식별 정보에 근거하여 해당 컨텐트를 구성하는 적어도 하나 이상의 파일들을 수신하도록 제어하는 제어부; 및
    수신되는 적어도 하나 이상의 파일들을 저장하는 저장부;를 포함하는 모바일 방송 수신기.
  11. 제 10 항에 있어서,
    상기 NRT 서비스 획득을 위한 크로스 계층 정보를 포함하는 고속 정보 채널(FIC) 데이터와 상기 FIC의 업데이트를 식별할 수 있는 FIC 버전 정보를 포함하는 전송 파라미터 채널(TPC) 데이터를 수신하는 단계;를 더 포함하는 비실시간(NRT) 서비스 제공 방법.
  12. 제11항에 있어서,
    상기 FIC 데이터는 상기 앙상블 식별자와 트랜스포트 스트림 식별자를 포함하는 비실시간(NRT) 서비스 제공 방법.
  13. 제12항에 있어서,
    상기 수신되는 FIC 내 트랜스포트 스트림 식별자와 상기 수신되는 제2 시그널링 정보 내 서비스 식별자 정보를 하나로 묶어 특정 타입으로 변환하여 상기 제1 시그널링 정보 내 서비스 식별자 정보를 기준으로 매핑하는 비실시간 서비스 제공 방법.
  14. 제10항에 있어서,
    상기 제2 시그널링 정보는,
    미리 설정된 IP 어드레스와 UDP 포트 넘버를 갖는 UDP/IP 헤더로 인캡슐레이션되어 수신되는 비실시간(NRT) 서비스 제공 방법.
  15. 제10항에 있어서,
    상기 앙상블에 대응하는 슬롯을 타임 슬라이싱 방식으로 수신하는 비실시간 (NRT) 서비스 제공 방법.
  16. 제10항에 있어서,
    상기 제1 시그널링 정보는 OMA-BCAST 서비스 가이드이고, 상기 제2 시그널링 정보는 서비스 맵 테이블(SMT)인 비실시간 서비스 제공 방법.
  17. 제10항에 있어서,
    상기 획득한 제1 컨텐트 식별 정보는,
    해당 컨텐트에 대한 globalContentID이거나 또는 상기 비실시간 서비스와 관련하여 별도로 정의된 컨텐트 식별 정보를 포함하는 비실시간 서비스 제공 방법.
  18. 제17항에 있어서,
    상기 획득한 제1 컨텐트 식별 정보는,
    상기 획득한 제2 컨텐트 식별 정보를 기준으로 매핑하되, 상기 제2 컨텐트 식별 정보는 바이너리 타입의 16비트인 비실시간 서비스 제공 방법.
PCT/KR2009/003097 2008-06-09 2009-06-09 서비스 제공 방법 및 모바일 방송 수신기 WO2009151266A2 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA2726831A CA2726831C (en) 2008-06-09 2009-06-09 Method for mapping signaling information to announcement information and broadcast receiver

Applications Claiming Priority (20)

Application Number Priority Date Filing Date Title
US5981108P 2008-06-09 2008-06-09
US61/059,811 2008-06-09
US7912108P 2008-07-08 2008-07-08
US61/079,121 2008-07-08
US11588808P 2008-11-18 2008-11-18
US61/115,888 2008-11-18
US12117808P 2008-12-09 2008-12-09
US61/121,178 2008-12-09
US13849408P 2008-12-17 2008-12-17
US61/138,494 2008-12-17
US15397309P 2009-02-20 2009-02-20
US15398509P 2009-02-20 2009-02-20
US61/153,985 2009-02-20
US61/153,973 2009-02-20
US16971109P 2009-04-15 2009-04-15
US61/169,711 2009-04-15
US17900509P 2009-05-17 2009-05-17
US61/179,005 2009-05-17
KR1020090051202A KR101598518B1 (ko) 2008-06-09 2009-06-09 서비스 제공 방법 및 모바일 방송 수신기
KR10-2009-0051202 2009-06-09

Publications (2)

Publication Number Publication Date
WO2009151266A2 true WO2009151266A2 (ko) 2009-12-17
WO2009151266A3 WO2009151266A3 (ko) 2010-04-01

Family

ID=41417241

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2009/003097 WO2009151266A2 (ko) 2008-06-09 2009-06-09 서비스 제공 방법 및 모바일 방송 수신기

Country Status (2)

Country Link
US (5) US8537746B2 (ko)
WO (1) WO2009151266A2 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105814897A (zh) * 2013-12-09 2016-07-27 Lg电子株式会社 处理包括广播内容和与广播内容有关的应用的广播信号的接收机和方法
CN113050980A (zh) * 2019-12-27 2021-06-29 西安诺瓦星云科技股份有限公司 一种功能配置信息获取方法、装置及计算机可读存储介质

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2890274A1 (fr) * 2005-08-30 2007-03-02 France Telecom Procede d'adressage pour le transport de donnees sur un reseau de telecommunication,signal de structure d'adresse, passerelle et programme d'ordinateur correspondants
WO2009151266A2 (ko) 2008-06-09 2009-12-17 엘지전자(주) 서비스 제공 방법 및 모바일 방송 수신기
US8189689B2 (en) * 2008-08-12 2012-05-29 Himax Technologies Limited Receiver for reducing PCR jitter
US8503335B2 (en) * 2008-08-20 2013-08-06 Samsung Electronics Co., Ltd. Method and apparatus for transmitting broadcast data, and method and apparatus for receiving broadcast data
WO2010021526A2 (en) 2008-08-22 2010-02-25 Lg Electronics Inc. A method for processing additional information related to an announced service or content in an nrt service and a broadcast receiver
US8102922B2 (en) * 2008-09-30 2012-01-24 Himax Technologies Limited Demodulator device and demodulation method for reducing PCR jitter
KR20100050426A (ko) * 2008-11-04 2010-05-13 한국전자통신연구원 3차원 방송 서비스 송수신 방법 및 시스템
WO2010068033A2 (ko) * 2008-12-09 2010-06-17 엘지전자 주식회사 비실시간 서비스 처리 방법 및 방송 수신기
US8549566B2 (en) * 2008-12-09 2013-10-01 Lg Electronics Inc. Method of processing non-real time service and broadcast receiver
US8782725B2 (en) * 2009-01-15 2014-07-15 Lg Electronics Inc. Method of processing non-real time service and broadcast receiver
US8594261B2 (en) * 2009-04-17 2013-11-26 Lg Electronics Inc. Transmitting/receiving system and broadcast signal processing method
US20100315486A1 (en) * 2009-06-15 2010-12-16 Electronics And Telecommunication Research Institute Stereoscopic video service providing/receiving method and apparatus in digital broadcasting system
CA2851888C (en) * 2010-03-29 2020-03-31 Lg Electronics Inc. Method of processing non-real time service and broadcast receiver
US8953478B2 (en) * 2012-01-27 2015-02-10 Intel Corporation Evolved node B and method for coherent coordinated multipoint transmission with per CSI-RS feedback
US9596116B2 (en) 2014-02-20 2017-03-14 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
KR102130191B1 (ko) * 2014-03-14 2020-07-03 소니 주식회사 수신 장치, 수신 방법, 송신 장치, 및 송신 방법
KR101752434B1 (ko) * 2014-08-22 2017-07-03 엘지전자 주식회사 방송 전송 장치, 방송 전송 장치의 동작 방법. 방송 수신 장치 및 방송 수신 장치의 동작 방법
KR101853669B1 (ko) * 2014-09-25 2018-05-02 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
KR101760445B1 (ko) * 2014-11-13 2017-07-21 소니 주식회사 수신 장치, 수신 방법, 송신 장치 및 송신 방법
WO2016114510A1 (ko) * 2015-01-18 2016-07-21 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
JPWO2021065915A1 (ko) * 2019-09-30 2021-04-08

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7231404B2 (en) * 2003-01-31 2007-06-12 Nokia Corporation Datacast file transmission with meta-data retention
US7376150B2 (en) * 2004-07-30 2008-05-20 Nokia Corporation Point-to-point repair response mechanism for point-to-multipoint transmission systems
US20060059267A1 (en) * 2004-09-13 2006-03-16 Nokia Corporation System, method, and device for downloading content using a second transport protocol within a generic content download protocol
US8320819B2 (en) * 2005-11-01 2012-11-27 Nokia Corporation Mobile TV channel and service access filtering
US7702337B2 (en) * 2006-05-16 2010-04-20 Nokia Corporation Method and system for providing quick service access
US20080010578A1 (en) * 2006-06-22 2008-01-10 Innovative Sonic Limited Method and apparatus for detection of local NACK in a wireless communications system
KR100800737B1 (ko) 2006-06-23 2008-02-01 삼성전자주식회사 Ｄｖｂ-ｈ 시스템에서 유사 방송 서비스 제공 방법 및시스템
KR101419287B1 (ko) 2006-07-07 2014-07-14 삼성전자주식회사 Ｉｐｄｃ 서비스를 제공하는 장치 및 방법 및 ｉｐｄｃ서비스를 처리하는 장치 및 방법
US8169957B2 (en) * 2007-02-05 2012-05-01 Qualcomm Incorporated Flexible DTX and DRX in a wireless communication system
US20130258919A1 (en) * 2007-02-05 2013-10-03 Qualcomm Incorporated Flexible dtx and drx in a wireless communication system
MX2010004147A (es) * 2007-10-15 2010-08-09 Thomson Licensing Transmision de television de alta definicion con capacidad movil.
EP2073491A1 (en) * 2007-12-21 2009-06-24 Thomson Licensing Method of management of metadata size of a service guide
WO2009151266A2 (ko) 2008-06-09 2009-12-17 엘지전자(주) 서비스 제공 방법 및 모바일 방송 수신기
CN102187611B (zh) * 2008-10-17 2014-04-02 爱立信电话股份有限公司 改进无线通信系统中harq重传和电池寿命的方法
US9363059B2 (en) * 2010-04-02 2016-06-07 Acer Incorporated Method of handling component carrier activation and deactivation and communication device thereof

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ADVANCED TELEVISION SYSTEMS COMMITTEE: 'ATSC Standard: Delivery of IP Multicast Sessions over ATSC Data Broadcast' DOC . A/92 31 January 2002, XP002208293 *
DAVID GOMEZ-BARQUERO ET AL: 'IEEE' FILECASTING FOR STREAMING CONTENT DELIVERY IN IP DATACAST OVER DVB-H SYSTEMS 31 March 2008, page 02, XP031268579 *
'DVB - IP Datacast over DVB-H Architecture' ETSI TR 102 469 V1. 1. 1 May 2006, XP014034109 *
SAMRAT GANGULY ET AL: 'NON-REAL-TIME CONTENT SCHEDULING ALGORITHMS FOR WIRELESS DATA NETWORKS' IEEE July 2006, pages 1375 - 1379, XP010754052 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105814897A (zh) * 2013-12-09 2016-07-27 Lg电子株式会社 处理包括广播内容和与广播内容有关的应用的广播信号的接收机和方法
CN113050980A (zh) * 2019-12-27 2021-06-29 西安诺瓦星云科技股份有限公司 一种功能配置信息获取方法、装置及计算机可读存储介质
CN113050980B (zh) * 2019-12-27 2024-04-09 西安诺瓦星云科技股份有限公司 一种功能配置信息获取方法、装置及计算机可读存储介质

Also Published As

Publication number Publication date
US9736547B2 (en) 2017-08-15
US20170289640A1 (en) 2017-10-05
US10244289B2 (en) 2019-03-26
US20160142790A1 (en) 2016-05-19
US9118975B2 (en) 2015-08-25
US20130332975A1 (en) 2013-12-12
US9294811B2 (en) 2016-03-22
US20100034140A1 (en) 2010-02-11
US8537746B2 (en) 2013-09-17
WO2009151266A3 (ko) 2010-04-01
US20150319482A1 (en) 2015-11-05

Similar Documents

Publication Publication Date Title
WO2009151266A2 (ko) 서비스 제공 방법 및 모바일 방송 수신기
WO2010021525A2 (en) A method for processing a web service in an nrt service and a broadcast receiver
WO2009151265A2 (ko) 방송 신호 수신 방법 및 수신 시스템
WO2009151267A2 (ko) 서비스 제공 방법 및 방송 수신기
WO2010068033A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2010058958A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2010068040A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2015008986A1 (ko) 하이브리드 방송 시스템의 방송 신호를 송신/수신하는 방법 및 장치
WO2010082783A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2014209057A1 (ko) 지상파 방송망과 인터넷 프로토콜망 연동 기반의 하이브리드 방송 시스템에서 방송 서비스의 송수신 방법 및 장치
WO2010068043A2 (en) Method for processing targeting descriptor in non-real-time receiver
WO2011049278A1 (en) Method for processing broadcast program information and broadcast receiver
WO2012091371A1 (en) Method for transmitting broadcast service, method for receiving the broadcasting service, and apparatus for receiving the broadcasting service
WO2014025207A1 (en) A method and an apparatus for processing a broadcast signal including an interactive broadcast service
WO2011122838A2 (en) Method of processing non-real time service and broadcast receiver
WO2017204546A1 (ko) 방송 신호 송수신 장치 및 방법
WO2010107167A1 (en) Transmitting/receiving system and method of processing data in the transmitting/receiving system
WO2011112053A2 (ko) 비실시간 방송 서비스 처리 시스템 및 그 처리방법
WO2017014586A1 (ko) 방송 신호 송수신 장치 및 방법
WO2010068034A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2011074844A2 (en) Method of processing non-real time service and broadcast receiver
WO2016108606A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016064150A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017209514A1 (ko) 방송 신호 송수신 장치 및 방법
WO2017135673A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09762653

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2726831

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09762653

Country of ref document: EP

Kind code of ref document: A2