KR100914710B1 - IPTV receiver and method for acquisition resource for IPTV service - Google Patents

Abstract

Disclosed are a resource acquisition method for an IPTV receiver and an IPTV service. The network interface unit transmits and receives an IP packet through a network. The IP network stack identifies the destination of the received IP packet and classifies the IP packet according to the protocol. The SI decoder parses an IPTV service record including a resource locator element indicating a location of a resource included in the received IP packet to calculate a differential element included in the resource locator element. The IPTV Terminal Function (ITF) operation controller controls the acquisition of resources according to the information contained in the differential element.

Broadcast, IP, Service, ITF, Resources

Description

IPTV receiver and method for acquisition resource for IPTV service}

The present invention relates to an IPTV receiver and a resource acquisition method for an IPTV service, and more particularly, to an IPTV receiver and a resource acquisition method for an IPTV service using an Internet protocol.

Existing TVs transmit contents produced by broadcasting companies through cable, terrestrial, or satellite broadcasting providers through radio transmission media such as broadcasting networks, and viewers receive a TV receiver capable of receiving the respective transmission media. Was serviced by viewing.

However, as digital-based digital TV technology has been developed and commercialized in existing analog broadcasting, various contents such as real-time broadcasting, contents on demand, games, news, etc., using the internet network connected to each household in addition to the existing radio media. Can be provided to viewers.

An example of providing content using the Internet network may be an Internet Protocol TV (IPTV). The IPTV refers to a service that provides an information service, video content, and broadcasting to a television using a high speed internet network.

IPTV is the same as general cable broadcasting or satellite broadcasting in that it provides broadcasting contents including video, but it is characterized in that bidirectionality is added. And unlike general public broadcasting, cable broadcasting or satellite broadcasting, viewers can watch programs they want to watch at their convenient time.

An object of the present invention is to provide an IPTV receiver capable of efficiently searching for and obtaining an IPTV service and a resource obtaining method for an IPTV service.

Another object of the present invention is to provide an IPTV receiver and a resource acquisition method for an IPTV service that can efficiently manage information on an IPTV service.

In order to achieve the above technical problem, a method for obtaining a resource for an IPTV service according to the present invention includes connecting to a service provider through a network, one of an inline encoded resource, an HTTP server, and a streaming server. Receiving an IPTV Service Record (Channel Map Record) comprising a resource locator element indicative of the location of a resource which is either a file transmitted by a file or a file transmitted via a FLUTE protocol, parsing the received IPTV service record An element including inline media information for obtaining the inline encoded resource from the resource locator element, and an element including media URL information for obtaining a file transmitted by any one of the HTTP server and the streaming server. And through the FLUTE protocol. Extracting a child element, which is one of the elements including the flute file information for obtaining the transmitted file, and acquiring the resource according to the information included in the difference element. Can be.
Preferably, the IPTV service record includes a service provider discovery record and a service discovery procedure including service provider information for recognizing the service provider and access method information for accessing the service provider. A master SI table record including channel map indication information for starting a service discovery process and version information for detecting a change of a service, and a master for receiving the master SI table An ITF Registration Output Record including SI table indication information, a Channel Map Record including information about a virtual channel provided by the service provider, and channel detail information of the virtual channel. Including channel detail records ( At least one of an EPG discovery record including channel details record and EPG discovery information for receiving EPG data. In this case, when the IPTV service record is the service provider discovery record, the obtained resource may be the ITF registration output record.
In addition, when the IPTV service record is the ITF registration output record, the obtained resource may be the master SI table record.
In addition, when the IPTV service record is the master SI table record, the obtained resource may be the channel map record.
In addition, when the IPTV service record is the channel map record, the obtained resource may be the channel detail record.
Preferably, the file transmitted by the HTTP server may be the IPTV service record.
Preferably, the file transmitted through the flute protocol may be the IPTV service record.
Preferably, the media URL information may include at least one of streaming media information and HTTP resource information. Here, the streaming media information may include information for receiving a media stream transmitted to MPEG-2 TS through a Real-time Transport Protocol (RTP) using or not using a Real-Time Streaming Protocol (RTSP).
Preferably, the flute file information may include file name information and flute file transfer information.
Preferably, the flute file transmission information includes at least one of transport session identifier information, flute session start time information, flute session end time information, TIAS band information, AS band information, host address information, flute session channel information, and FEC information. It may include one. The flute session channel information may include at least one of port information, TIAS band information, AS band information, and multicast address information. In addition, the FEC information may include at least one of FEC encoding identifier information and FEC instance identifier information.
An IPTV receiver according to the present invention for solving the above technical problem is a file transmitted by any one of an inline encoded resource (Inline encoded), HTTP server and streaming server through a network and a file transmitted through the FLUTE protocol A network interface unit for receiving an IP packet carrying an IPTV service record including a resource locator element indicating a location of a resource, and parsing the IPTV service record to obtain the inline encoded resource from the resource locator element. An element containing inline media information for obtaining, an element containing media URL information for obtaining a file transmitted by either the HTTP server or a streaming server, and a flute for obtaining a file transmitted via the FLUTE protocol SI decoder for extracting a child element, which is one of the elements including one information, and an ITF operation controller for controlling the acquisition of the resource according to the information included in the difference element. can do.
Preferably, the IPTV service record includes a service provider discovery record and a service discovery procedure including service provider information for recognizing a service provider and connection method information for accessing the service provider. a master SI table record including channel map indication information for starting a discovery process and version information for detecting a change of a service, and a master SI for receiving the master SI table ITF Registration Output Record including table indication information, Channel Map Record including information about the virtual channel provided by the service provider, Channel Map Record including channel detail information of the virtual channel. Channel Details Record It may include at least one of an EPG Discovery Record including a Details Record and EPG discovery information for receiving the EPG data.
Preferably, the file transmitted by the HTTP server may be the IPTV service record.
Preferably, the file transmitted through the flute protocol may be the IPTV service record.
Preferably, the media URL information may include at least one of streaming media information and HTTP resource information.
Preferably, the streaming media information may include information for receiving a media stream transmitted to MPEG-2 TS through a Real-time Transport Protocol (RTP) using or not using a Real-Time Streaming Protocol (RTSP). .
Preferably, the flute file information may include file name information and flute file transfer information.
Preferably, the flute file transmission information includes at least one of transport session identifier information, flute session start time information, flute session end time information, TIAS band information, AS band information, host address information, flute session channel information, and FEC information. It may include one. The flute session channel information may include at least one of port information, TIAS band information, AS band information, and multicast address information. In addition, the FEC information may include at least one of FEC encoding identifier information and FEC instance identifier information.

delete

delete

delete

delete

delete

delete

delete

According to the present invention, an IPTV receiver and a resource acquisition method for an IPTV service can efficiently search for and acquire an IPTV service, and update information on an IPTV service quickly and accurately, thereby efficiently obtaining information on an IPTV service. Can manage.

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention that can specifically realize the above object will be described. At this time, the configuration and operation of the present invention shown in the drawings and described by it will be described as at least one embodiment, by which the technical spirit of the present invention and its core configuration and operation is not limited.

The terms used in the present invention have been selected as general terms widely used as possible in consideration of the functions in the present invention, but may vary according to the intention or custom of a person skilled in the art or the emergence of a new technology. In addition, in certain cases, there is also a term arbitrarily selected by the applicant, in which case the meaning will be described in detail in the description of the invention. Therefore, it is intended that the terms used in the present invention should be defined based on the meanings of the terms and the general contents of the present invention rather than the names of the simple terms.

1 is a system configuration diagram illustrating the concept of an IPTV service.

Referring to FIG. 1, an IPTV system includes a service provider domain, a network provider domain, and a customer domain.

The service provider area may include content providers and service providers. The content provider serves to provide content to a service provider. The service provider serves to provide a service to subscribers, collects various contents, and modifies a signal according to an IP environment and delivers it to a user. In addition, the service provider transmits multimedia data, and maintains the transmission network for stable reception of content to the customer, and an infrastructure for network transmission to the content provider. And provide functionality. Here, the service provider may be a virtual entity, and the content provider may be a service provider.

The network provider area connects users and service providers through an IP network. The transmission system may use various network networks, such as an access network, a backbone network, or a wireless wide area network (WAN).

The customer area is an area consuming an IPTV service. The customer domain is responsible for replaying incoming data using infrastructure such as xDSL and cable, and responding to user needs immediately. Most of them are made up of companies that produce IPTV, and the types can be divided into IPTV, IP STB, and IP Phone. The customer area device may be used to receive content from the customer area and receive a broadcast. The customer area device may include a set top box, a PC, a mobile terminal, an IPTV terminal function (ITF) device, or a delivery network gateway (DNG) device.

Learn more about each area.

First, content providers may include a TV station and a radio station that make a broadcast program. TV Station refers to existing terrestrial or cable stations, which can create and store programs that users can watch and transmit them digitally. In general, it is to be able to transmit in various broadcast forms.

Radio Station means a general radio station, and although there may be a video channel at any time, it can be said that it operates without a video channel in most cases. Video on Demand (VoD) and Audio on Demand (AoD) services have different characteristics from TV Station or Radio Station. Content providers will also store and store programs for broadcast, but this is a live broadcast with continuity, which can't be rewound or stopped unless recorded. However, in the case of VoD or AoD, I store the broadcasting program, movie, music, etc. that I want and then play it for viewing. For example, if there is a broadcast program that was not properly watched because there is no current time, it is possible to access a site that provides such a broadcast service and download the file or play the file immediately. AoD also offers the ability to record audio programs in real time or make it difficult to record audio programs. Music on Demand (MoD) service can download and listen to the music I want. MoD's services can be performed by record labels or record distributors by extending existing web services.

Hereinafter, an embodiment of a service provided by a content provider will be described.

The PF server can be serviced by a company that manages all broadcasting information and location information provided by a content provider. This service mainly contains broadcasting time or location information necessary for broadcasting and information that a user can access. The customer can obtain this information and display it on the screen. The PF server is one of the services to be provided for each broadcasting station. In the IPTV environment, the PF server can provide the service so that the user can access the broadcasting station.

The EPG service is one of convenient services that allows a user to search a broadcast program by time zone and to grasp by channel. The EPG service is already installed on the customer side and can be executed. The user can obtain only the information on the corresponding broadcasting station from the PF server, but the EPG service can obtain the information on the real time broadcasting channels of all broadcasting stations at once and can be used very conveniently. For example, it has a powerful built-in function to schedule recording of CNN news or to schedule watching a Disney broadcast. Therefore, the EPG service must provide detailed information of the broadcasting program of the corresponding region in each time zone. In particular, in some dramas, the contents of a drama can be searched or divided into categories to distinguish SF, Drama, Animation, etc., and detailed information about the plot or characters of a movie or drama in a simple broadcast program is also included. can do. The big problem of EPG service is that there are many kinds of licenses of customers who watch IPTV, so how to transmit EPG data that is suitable for users can be a problem. To access the EPG service, Costumer simply finds and presses an input key on the remote.

ECG service has all functions that user can conveniently use contents information of content provider and location and access authority of access server. In short, it is an electronic content guide (EPG) that provides easy access to servers with content and detailed information about the content. In other words, instead of real-time broadcasting, services such as AoD, MoD, and VoD are bundled together like EPG to reduce the burden of users accessing individual content services to download or view content. Similar to the EPG service, this service does not inform the real-time broadcast channel information but is already stored in the server so that it can be watched at any time and downloaded and stored. To access the server with each content, the user will have to obtain a very difficult address or PF server. This is a very complicated process and time consuming. Companies that provide ECG allow ECG programs to be automatically installed on customers, collect information on all contents, and provide data. To access the ECG service, the customer can also click the Enter key button on the remote control.

Portal Server is a web service provided by each broadcasting station. The portal server is connected to a web server of a broadcasting company or a service provider. The role of Portal Server is to search or view the list of programs provided by each broadcaster or content providers that provide content services. It can be thought of as a function like ECG or EPG. However, Portal service also has functions such as user authentication and license agreement, so I need to connect to watch the program I want. In addition, the ECG or EPG provides an integrated broadcast or content list, but the Portal service may provide detailed search by providing broadcast or content list information for a corresponding program provider. To access the Portal service, the customer simply clicks the Portal input button on the remote.

In this way, the content provider side should include functions for providing such services, and in order for these functions to operate normally, the server 130 of each service provider may transmit the corresponding program or broadcast information in real time. Must be connected to the IP network. In addition, each broadcasting station or service provider must be connected to the service provider's network to be transmitted without delay and error. Therefore, the system can transmit multimedia data using internet real-time protocol such as RTP, RTSP, RSVP and MPLS. This must be equipped. For example, if you are trying to deliver multimedia in real time from the current TV studio, you will need to transcode the MPEG-2 and AC-3 audio specifications to match the format of the IPTV. When passing through the server doing this work, the system is configured to pass through the IP network provided by the service provider by attaching the RTP / UDP protocol containing the time information to match the caption or lipync.

The service provider provides network stability and bandwidth to transmit multimedia data and broadcast data transmitted from a content provider. Service providers can also provide IPTV services using existing cable networks. In this case, the equipment of the delivery network needs to be changed. In other words, network equipment that can transmit data in real time should be configured, and network should be configured in consideration of bandwidth to customer. These devices need to reduce bandwidth by processing large amounts of multimedia data using Multicast service, which is the basic network service of IPTV. If the bandwidth is not secured, the service provider may transcode multimedia broadcasting data from the optical fiber network configuration or contents provider and transform it into a format such as MPEG-4 or MPEG-7 in an effort to secure the bandwidth. have. The Service Provider has to provide several services for this purpose. It is designed to provide size Network Management System (NMS), Dynamic Host Control Protocol (DHCP) and CDN services.

NMS service manages Delivery Network that Service Provider can send to each customer and performs RCMS (Remote Configuration and Management Server) function. That is, if a problem occurs in the transmission network and the customer cannot receive the broadcast, it must have a means for emergency treatment. NMS is widely used as a standardized means to smoothly control and manage machines in remote transport layers. Using this service, you can see how much traffic is being generated for which broadcasts and where the bandwidth is scarce. In addition, the content providers should be provided to the content providers to create and manage groups in the multicast. Sometimes you need to be able to create more Multicast groups.

DHCP service is used to automatically assign IP to customer's IPTV receiver and to inform the address of CDN server. DHCP services are also a good way to assign IP to PCs in the general network. The IPTV receiver should be sent an address that allows access to the licensed IPTV receiver so that the user can register during the initial connection. In general, IPv4 will be provided by IPTV receivers, but IPv6 is also available. Thus, IPTV receivers that provide IPv4 do not mean they cannot be used.

CDN service is data provided by the Service Provider. When the IPTV receiver is powered on and operated for the first time, the CDN information is received from the Service Provider while receiving IP by the DHCP service. This information contains the registration or authentication of the user of the IPTV provider and the aforementioned PF information. The IPTV receiver may receive the IP broadcast signal by obtaining CDN information from the service provider.

A customer can have several types of IPTV receivers. If you have a regular TV, you can enjoy IPTV by renting an IPTV STB, and a service provider can pay additional service costs at a low price and apply for an IP phone. IPTV receiver basically has network interface to connect to network, and has internet protocol to receive and process data packet from network and play it on the screen in case of multimedia data. It needs to be sent quickly to the server and get the information from the server to respond. That is, the IPTV receiver may operate to transmit the user's requirements in both directions while processing the multimedia data. You can also provide buttons for IPTV on the remote control to use the service well. In the provided IPTV receiver, the user can save and view the wonderful scenes in the drama and enjoy additional services such as location information and hotel reservation.

Meanwhile, the aforementioned NMS performs a RCMS function as well as a function of managing a network by a service provider. RCMS helps users to control and manage their own IPTV receivers. As the number of IPTV receivers increases and additional services increase, the role of RCMS becomes more important. For this reason, the SNMP protocol is mandatory for IPTV broadcast receivers. This is intended to enable Service Provider to manage and control IPTV broadcast receivers. IPTV broadcast receivers can then learn in detail the statistics of the protocol they are currently communicating with, information about the processor they are using, and what TV manufacturer they are using.

In order to receive the IPTV service in the customer area, the ITF 120 may transmit a server address resolution request to the DNS server 110. DNS server 110 then transmits the server address to ITF 120. The ITF 120 can then connect to the server 130 with the received server address and receive the IPTV service. Here, the ITF 120 may be connected to the server 130 in at least one of a multicast method and a unicast method.

2 is a diagram schematically illustrating a multicast scheme.

Referring to FIG. 2, the multicast method is a method of transmitting data to a plurality of recipients of a specific group. For example, a service provider can send data to multiple pre-registered ITFs at once. The Internet Group Management Protocol (IGMP) protocol may be used for the multicast registration.

3 is a diagram schematically illustrating a unicast scheme.

Referring to FIG. 3, the unicast method is a method of transmitting data 1: 1 between one sender and one receiver. For example, in the unicast scheme, when an ITF requests a service from a service provider, the service provider transmits the service to the ITF according to the request.

4 is a flowchart illustrating a preferred embodiment of the method for searching for an IPTV service according to the present invention.

Referring to FIG. 4, in order to receive an IPTV service, the ITF performs a service provider discovery to find a list of addresses of a service discovery server. In this case, the service provider discovery refers to a process in which the ITF finds information about the IPTV service provider and information for accessing the service provider through a security managed network. The ITF can find the address list of the SD server (Service Discovery Server) in the following way.

Address list search method of SD server (Service Discovery Server)

1. Preset or manual setting: Follow the preset address in ITF or set the user manually

2. DHCP based SP Discovery: Get the address list of SD server using DHCP option

3. DNS SRV-based SP Discovery: Get the SD server speed list by using DNS SRV mechanism.

The ITF 420 may find a specific SD server through the SD server address list obtained by the above methods 1 to 3 and may receive a service provider discovery record from the specific SD server.

The service provider 410 transmits a service provider discovery record to the ITF 420 (S400). The service provider discovery record here includes information about a useful IPTV service provider and information for accessing the service provider through a secure managed network. The service provider discovery record may be transmitted in a push mode or a pull mode. When transmitted in the pull mode, the service provider 410 transmits the service provider discovery record when the ITF 420 has a request for the transmission of the service provider discovery record. However, when sent in push mode, the service provider 410 sends the service provider discovery record regardless of the ITF 420 sending request for the service provider discovery record.

The ITF 420 accesses the Registration Server designated by the address information of the Registration Server included in the service provider discovery record and performs the ITF registration procedure (S405). In this case, the information delivered from the ITF 420 to the service provider 410 may be delivered in the form of an ITFRegistrationInputType record and may include subscriber identifier information and subscriber location information. And here, the ITF registration may be referred to as a SP (Service Provider Attachment), which may vary according to the intention or custom of a person skilled in the art or the appearance of a new technology.

After successful authentication, the service provider 410 transmits a provision information record to the ITF 420 (S410). Here, a provision information record is a record providing provisioning information and authentication information obtained by the ITF during the SP access procedure. A provision information record has a form of an ITFRegistrationOutputType record, and may be data customized to a service subscribed to based on information included in the ITFRegistrationInputType record. Herein, the ITFRegistrationInputType record may include at least one of subscriber identifier information and subscriber location information. The subscriber location information may be an address where the subscriber's ITF is located. In addition, when the ITFRegistrationInputType record includes only subscriber identifier information, the registration server may obtain previously stored subscriber location information and subscription status information based on the subscriber identifier information.

For example, a provision information record may be customized to the subscriber's subscription status and ITF location. The ITF 420 may provide its ID and location information through the ITFRegistrationInputType record, and the registration server may specify the service subscribed to by the ITF based on this. In addition, the registration server provides an address, in the form of an ITFRegistrationOutputType record, from which an ITF 420 may obtain service information based on a specified service.

Service Information includes a Master SI Table Record that manages the version of Channel Map and Channel Details, a Channel Map Record that provides a list of channels in package form, and a Channel Map Record of each channel. It is divided into Channel Details Records containing detailed information. In this case, the service information may be transmitted in a push mode or a pull mode.

The service provider 410 transmits a master SI table record to the ITF 420 (S415). Here, the ITF 420 may receive the corresponding master SI table record or request the service provider 410 based on the location information of the master SI table included in the provision information record.

In addition, the service provider 410 transmits a channel map record to the ITF 420 (S420). Here, the ITF 420 may receive the corresponding channel map record or request the service provider 410 based on the channel information included in the master SI table record.

The service provider 410 transmits a channel details record to the ITF 420 (S425). Here, the ITF 420 may receive the channel detail record or request the service provider 410 based on the virtual channel information included in the master SI table record or the channel detail location information included in the channel map record.

5 is a diagram illustrating a schema of a preferred embodiment of a service provider discovery type according to the present invention.

Referring to FIG. 5, the service provider discovery record includes a ServiceProviderID attribute, a Version attribute, a LogoURI attribute, a Name element, a Description element, and an SProviderRegistrationServer element.

The ServiceProviderID property includes unique identifier information for identifying a service provider, and the uniqueness of the identifier can be guaranteed by using a domain name registered as an identifier.

The Version attribute contains the version information for this record.

The LogoURI attribute includes logo image information that specifies the URI of the logo image of the service provider and may be optionally used.

The Name element contains information about the name of the service provider. The service provider may have one name for each language. To this end, the Name element includes a Language attribute, and the Language attribute includes information about a name defined for each language. Here, the Name element must contain at least one Language attribute.

The Description element includes detailed text description information about the service provider, and the text description information may be one for each language similarly to the information about the name of the service provider. To this end, the Description element includes a Language attribute and may include a plurality of Language attributes. The Language property contains textual description information. The text description information may be optionally provided and may not be provided.

The SProviderRegistrationServer element contains the address information of the registration server of the service provider. For this purpose, the SProviderRegistrationServer element may include a Location URL attribute, and the Location URL attribute includes address information of the Registration Server. In this case, the address information of the registration server may be in the form of a URL.

Figure 6 illustrates a schema of one preferred embodiment for an ITF Registration Input Type in accordance with the present invention.

Referring to FIG. 6, an ITF registration input record includes a ConsumerID attribute and a ConsumerLocation attribute, and information transmitted from the ITF to the registration server for registration may be transmitted in the structure of the ITF registration input type.

The ConsumerID attribute includes subscriber identifier information for uniquely identifying the subscriber, and the MAC address of the ITF may be used as the subscriber identifier.

The ConsumerLocation attribute contains subscriber location information indicating the location of the subscriber. Based on the information contained in the ConsumerLocation, the registration server can recognize the location of the subscriber to determine the corresponding area, and can select and send flows suitable for the ITF according to the determined area. The subscriber location information may be obtained through the DHCP option in the network attachment step.

FIG. 7 illustrates a schema of a preferred embodiment of an ITF Registration Output Type according to the present invention.

Referring to FIG. 7, the ITF registration output record includes a MasterSITableLocation element, a SubscribedChannelMap element, an UnsubscribedChannelMap element, an EPGDiscoveryLocation element, and a SPRemoteConfigurationServerLocation element. When the registration is successful, the information transmitted from the Registartion Server to the ITF is an ITF registration output type (ITF). Regitstration Output Type) structure.

The MasterSITableLocation element contains location information of the Master SI Table.

The SubscribedChannelMap element contains information about the channel map to which the user subscribed. Service providers can provide their channels in the form of multiple channel maps so that users can select one or more of them to subscribe. In addition, it is also possible to provide a list of channels subscribed to by the user by combining the channel map by configuring the channel map in the form of a channel map internally without being directly visible to the user.

The UnsubscribedChannelMap element contains information about channel maps to which the user has not subscribed. The service provider may need to provide such a list of channels for promotion, although the user is not currently subscribed and can not watch. The service provider may optionally provide such channel maps.

The EPGDiscoveryLocation element contains EPG data provider information for discovering EPG data. The EPG data provider information includes address information for receiving EPG data. EPGs may optionally be provided and one or more EPGs may be provided. Here, the EPGDiscoveryLocation element may be defined as an EPG Discovery Record Type as an example.

The SPRemoteConfigurationServerLocation element contains address information of the Remote Configuration Server provided by the SP. If the address information of the Remote Configuration Server exists, the ITF must connect to the Remote Configuration Server and perform the Remote Configuration procedure. Here, the Remote Configuration Server performs the above-described RCMS function.

FIG. 8 is a diagram illustrating a relationship between tables configuring service information (SI).

Referring to FIG. 8, a Master SI Table Record provides pointers to Virtual Channel Maps. Here, the pointers are information necessary to start the virtual channel discovery process. The Master SI Table Record also allows ITF to detect changes in some versions of the SI. Master SI Table Record is a version of Channel Map Master that contains version information of each channel map and Channel Detail that contains channel details. It may be composed of virtual channel masters containing information. In this case, the master SI table record may optionally include a virtual channel master.

Each Channel Map is uniquely identified by VCListID and has two version information of VCListVerion and ChannelDetailsVersion. VCListVersion is a version of the channel list of the Channel Map. The version is changed only when a channel is added or deleted. ChannelDetailsVersion is version information for managing whether the detailed information of a channel included in the channel map is changed. The version is changed only when the detailed information of the channel is changed.

There can only be one master SI table record in the service provider. However, if the service configuration differs by region, it would be more efficient to configure one master SI table record for each region. In this case, the Registration step makes it possible to provide a master SI table record for the ITF region.

In FIG. 8, two channel maps are illustrated in the master SI table record, which can be uniquely identified by the VCListID. Each channel map may have one or more channels, and does not include detailed information of the channel on the channel map, but designates a location from which the information can be obtained. In other words, Channel Details Location plays a role in designating the location of channel details.

The Channel Details Record contains the detailed information of the channel and can be found by the Channel Details Location on the Channel Map. In addition to the method described above, the method of delivering a channel details location may have various methods as follows.

Channel Details Record Delivery Method

1. How to provide a single multicast stream globally

This is a method of distributing channel details records of all channels provided by a service provider as one global multicast stream. In this case, as described above, the address of this global multicast stream can be provided in ITFRegistrationOutputType without providing the address of detailed information for each channel on the channel map.

2. How to provide one multicast stream per region

In the first method, channel detail information is provided in one stream globally. In this case, channel detail information may be provided through a separate multicast stream for each region. In this case, the region that belongs to the ITF can be specified through the registration process, so the address of the unique multicast stream for each region can be specified through the ITFRegistrationOutputType.

3. How to specify Default Channel details location in Channel Map

  If some or all of the details of a channel belonging to a channel map can be obtained from the same address, it is sufficient to specify it once in the Channel Map rather than in each Channel Details Location. In this case, if there is a channel that needs to obtain detailed information from another address, the address specified in the channel map can be overridden by specifying it again or additionally in the channel details location. Will be.

4. A method of designating the location of detailed information for each channel through Channel Details Location as shown in FIG.

This is a method of specifying detailed information of channels belonging to each channel map by each Channel Details Location. For example, for a channel having a ServiceID of "WNBC.COM/ch9" and "WNBC.COM/ch11", respectively, if "WNBC.COM/ch9", the LocationURL of the Channel Details Location of the channel is "ipm: //sd.verizon.com ", for the channel" WNBC.COM/ch11 ", specify the LocationURL of the Channel Details Location for the channel details as" ipm: //sd.verizon.com ", respectively. do.

To find the details of each channel in the transmitted Channel Details Records, the ServiceID of the Channel Details Location can serve as a unique identifier that distinguishes the details of each channel. In addition, the Channel Details Record of a channel can be found through the ServiceID of the Channel Details Record Location.

If the channel details record is received in a multicast manner, the channel details record corresponding to the ServiceID can be found while joining the corresponding stream and continuously receiving the records.

If the Channel Details Record is received in a unicast manner, the ServiceID is passed to the server as a parameter so that only the desired Channel Details Record is transmitted so that the corresponding Channel Details Record is received. Record only).

Master SI Table Records, Channel Map Records, and Channel Details Records are logically delivered in three separate flows. Either way, it can be delivered anyway.

Pass through Master SI Table Record ITF can manage update of Channel Map and Channel Details. ITF monitors the master SI table to determine whether the version of Channel Map and Channel Details has changed, and, if the version has changed, Channel Map and Channel Details. It may be recognized that has been updated to update the channel map and the channel details.

In this case, the channel details can be checked in two ways. The first can be checked through the Channel Details Version of the Channel Map Master in the Master SI Table Record. When the Channel Details Version of the Channel Map Master is changed, the Channel Details may be recognized as updated. The second can be checked through the Channel Details Version of the Channel Map Record. That is, it is possible to find a channel map record indicated by the channel map master and determine whether the channel details version of the corresponding channel map record is changed by checking whether there is an update. In the second method, the Master SI Table Record does not need to include the Virtual Channel Master and the Channel Map Master does not need to include the Channel Details Version.

FIG. 9 illustrates a schema of a preferred embodiment of a Master SI Table Record Type. FIG.

Referring to FIG. 9, a Master SI Table Record includes channel map management information. To this end, the Master SI Table Record may include a ServiceProviderID attribute, a Version attribute, a ChannelMapMaster element, and a VirtualChannelMaster element. Here, the VirtualChannelMaster element may optionally be included.

The ServiceProviderID property may include service provider identifier information for uniquely identifying a service provider, and may use a domain name registered as a service provider identifier.

The Version attribute contains version information of the master SI table record. Version information included in the Version property can determine whether to update the master SI table record.

The ChannelMapMaster element contains information for receiving a Channel Map. In other words, the ChannelMapMaster element includes a pointer to a channel map instance. In addition, the Master SI Table Record may include one or more pointers for indicating one or more channel map records, respectively. A channel map record can be received based on the information included in the ChannelMapMaster element, and it can be determined whether the channel map is updated. To this end, the ChannelMapMaster element may include a VCListID attribute, a VCListVersion attribute, and a ChannelDetailsVersion attribute. The VCListID attribute contains identifier information that uniquely identifies the channel map instance. The VCListVersion attribute includes version information that determines whether or not the channel lists constituting the channel map are changed. Here, the version information included in the VCListVersion attribute is changed when a channel is added or deleted. The ChannelDetailsVersion attribute includes version information indicating whether detailed information of channels constituting the channel map has changed. Here, the version information included in the ChannelDetailsVersion property changes when the channel details change.

The VirtualChannelMaster element includes a ServiceID attribute and a VCVersion attribute. The ServiceID attribute contains identifier information for uniquely identifying a service. The desired Channel Details Record can be found based on the information included in the ServiceID property. The VCVersion attribute includes version information of channel details.

FIG. 10 illustrates a schema of a preferred embodiment of a channel map type.

Referring to FIG. 10, a channel map is a structure that contains channel map information and does not include detailed information of a channel, and serves as a package of channels. Here, the channel map of FIG. 10 represents a method of specifying a separate address for each channel detail, which is the fourth method of the channel details delivery method described above with reference to FIG. 8. In this case, the channel map information may be, for example, a channel map instance.

The channel map record includes a channel map instance. To this end, a channel map record includes a ServiceProviderID attribute, a VCListID attribute, a VCListVersion attribute, a ChannelDetailsVersion attribute, and a ChannelDetailsLocation element.

The ServiceProviderID property may include service provider identifier information for uniquely identifying a service provider, and may use a domain name registered as a service provider identifier.

The VCListID includes identifier information uniquely identifying the ChannelMap.

The VCListVersion attribute includes version information that determines whether or not the channel lists constituting the channel map are changed. Here, the version information included in the VCListVersion attribute is changed when a channel is added or deleted.

The ChannelDetailsVersion attribute includes version information indicating whether the detailed information of a channel constituting the channel map is changed. Here, the version information included in the ChannelDetailsVersion property changes when the channel details change.

The ChannelDetailsLocation element includes location information of detailed information of each channel. For this purpose, the ChannelDetailsLocation element includes a ServiceID attribute, a LocationURL attribute, and a VCVersion attribute. The ServiceID attribute contains identifier information for uniquely identifying a service. The desired Channel Details Record can be found based on the information included in the ServiceID property. The LocationURL attribute contains address information from which you can get detailed information about this service. The VCVersion attribute includes version information of channel details.

FIG. 11 illustrates a schema of another preferred embodiment of a channel map type. FIG.

Referring to FIG. 11, a channel map is a structure containing channel map information, and serves as a package of channels, and does not include detailed information of channels, but instead debits the detailed information of channels. Contains information about the location. Here, the channel Ma of FIG. 11 is a method of designating a default channel details location in a channel map, which is the third method of the channel details delivery method described above with reference to FIG. 8. Indicates. In this case, the channel map information may be, for example, a channel map instance.

The channel map record includes a channel map instance. To this end, a channel map record includes a ServiceProviderID attribute, a VCListID attribute, a VCListVersion attribute, a ChannelDetailsVersion attribute, a ChannelDetailsDefaultLocation element, and a ChannelDetailsLocation element.

The ServiceProviderID property may include service provider identifier information for uniquely identifying a service provider, and may use a domain name registered as a service provider identifier.

The VCListID includes identifier information uniquely identifying the ChannelMap.

The VCListVersion attribute includes version information that determines whether or not the channel lists constituting the channel map are changed. Here, the version information included in the VCListVersion attribute is changed when a channel is added or deleted.

The ChannelDetailsVersion attribute includes version information indicating whether the detailed information of a channel constituting the channel map is changed. Here, the version information included in the ChannelDetailsVersion property changes when the channel details change.

The ChannelDetailsDefaultLocation element contains the default location information of the detailed information of the channel belonging to the channel map. To do this, the ChannelDetailsDefaultLocation element contains a LocationURL attribute. The LocationURL attribute contains the default location information. Here, the default location information is an address capable of receiving all or part of detailed information of a channel belonging to one channel map. If there is a channel for which detailed information is to be obtained from another address, the location information of the detailed information of the corresponding channel may be overridden in the ChannelDetailsLocation element.

The ChannelDetailsLocation element includes location information of detailed information of each channel. That is, when there is detailed information of a channel that cannot be obtained from the default position information included in the ChannelDetailsDefaultLocation element, the ChannelDetailsLocation element includes the location information of the detailed information of the channel. For this purpose, the ChannelDetailsLocation element includes a ServiceID attribute, a LocationURL attribute, and a VCVersion attribute. The ServiceID attribute contains identifier information for uniquely identifying a service. The desired Channel Details Record can be found based on the information included in the ServiceID property. The LocationURL attribute contains address information from which you can get detailed information about this service. The VCVersion attribute includes version information of channel details.

12A and 12B illustrate a schema of a preferred embodiment of a Channel Details Type.

12A and 12B, a channel details record includes detailed information of a channel included in a channel map. The channel details record for this includes a ServiceProviderID attribute and a VirtualChannelDetails element.

The ServiceProviderID property contains service provider identifier information that can uniquely identify the service provider.

The VirtualChannelDetails element contains detailed information of each channel. To this end, the VirtualChannelDetails element includes a ChannelType attribute, a ServiceID attribute, a VCVersion attribute, a ShortChannelName element, a ChannelNumber element, and a ChannelSource element. Here, the ChannelSource element may be optionally included. If the VirtualChannelDetails element does not include the ChannelSource element, the ChannelSource element may be independently transmitted as a separate ChannelSource record, and the VirtualChannelDetails element may include location information and identification information capable of receiving the ChannelSource record.

The ChannelType attribute includes service type information indicating a service type of a channel, and the service type information indicates whether the corresponding channel is a video channel, an audio channel, or a data broadcasting channel.

The ServiceID attribute contains identifier information for uniquely identifying a service. The desired Channel Details Record can be found based on the information included in the ServiceID property.

The VCVersion attribute includes version information of channel details.

The ShortChannelName element contains the name of the channel as a short text value of 7 characters or less. For example, it could be a value like "WABC".

The ChannelNumber element contains the channel number. In the present invention, both the one part channel number and the two part channel number can be supported, and the corresponding channel number can be any one of the one part channel number and the two part channel number. To this end, the ChannelNumber element may include a MajorChannelNumber element including physical channel information and a MinorChannelNumber including logical channel information.

The ChannelSource element contains information that specifies the actual source of the channel. To this end, the ChannelSource element includes a VirtualChannelLocation element, a ChannelSourcePurpose element, a VideoAttribute element, an AudioAttributes element, and an ECMLocation element.

The VirtualChannelLocation element contains the IP address and transport protocol information that can receive the source of the channel. For this purpose, the VirtualChannelLocation element includes a ProgramNumber attribute and an IPLocation element. By selectively supporting the ProgramNumber attribute, it guarantees scalability to MPTS and also provides an opportunity to check whether the received stream is a desired stream even in the case of SPTS. The IPLocation element contains a Location URL attribute that contains URL information that can receive the source of the channel.

The ChannelSourcePurpose element may include source type information, which is a value indicating the characteristics of a channel, and may include a plurality of source type information. The source type information may be any one of HD, SD, PIP, and Barker. Barker channel is a channel for advertising or promotion. When the channel is not available due to the authority of the channel, it is automatically selected and serves as a guide for promoting and subscribing to the channel, and Barker is at least one of HD Barker, SD Barker, and PIP Barker. Contains a single value.

One channel can have one source for each value specified by ChannelSourcePurpose. That is, when the ChannelSourcePurpose element includes one HD and one SD at the same time, one channel may have one HD source and one SD source. However, one channel does not need to have two HD sources simultaneously, so the ChannelSourcePurpose element does not contain two HDs at the same time.

The VideoAttributes element contains video attribute information of the source. To this end, the VideoAttributes element includes a Codec attribute including video codec information, a Profile attribute including video profile information, and a Level attribute including video level information.

The AudioAttributes element contains audio attribute information of the source. To this end, the AudioAttributes element includes a Codec including audio codec information, a Profile attribute including video profile information, a Level attribute including audio level information, a Bitrate attribute including audio bitrate information, and SamplingFrequency information including audio sampling frequency information. Include.

The video attribute information included in the VideoAttribute element and the audio attribute information included in the AudioAttributes element allow the user to select and watch the optimal source according to the function of the ITF.

The ECMLocation element contains ECMLocation address information that can receive ECM information.

FIG. 13 is a flowchart illustrating an exemplary embodiment of a service provider discovery according to the present invention. Referring to FIG.

Referring to FIG. 13, the ITF searches for an SD server (S1300). Here, the ITF can find the SD server according to the address list search method of the SD server (Service Discovery Server) described above with reference to FIG. 4.

The ITF accesses the SD server based on the main list of the SD servers, and obtains a service provider discovery record from the SD server (S1310). The service provider discovery record may be a service provider discovery record described above with reference to FIG. 5. In addition, the ITF may receive a Service Provider Discovery Record from the SD server in PUSH mode or PULL mode.

The ITF parses the ServiceProviderID attribute of the received Service Provider Discovery Record to calculate service provider identifier information included in the ServiceProviderID attribute (S1320).

The ITF checks whether the calculated service provider identifier information is a service provider who wants to receive a service (S1330). If the service provider does not want to be provided with the service, the ITF performs step S1300 to find another SD server in the main list of SD servers.

If the service provider wants to receive the service, the ITF parses the Name and Description attributes of the Service Provider Discovery Record to provide information and a description of the name of the service provider included in the Name attribute. Detailed text description information on the service provider included in the attribute is calculated (S1340).

The ITF parses the SProviderRegistrationServer element of the provider discovery record to calculate address information of the registration server of the service provider included in the SProviderRegistrationServer element (S1350). The ITF may access the Registration Server based on the calculated address information of the Registration Server and perform the ITF registration procedure.

FIG. 14 is a flowchart illustrating a preferred embodiment of a service provider registration and service discovery according to the present invention.

Referring to FIG. 14, the ITF transmits a registration request to a registration server designated by address information of a registration server included in a service provider discovery record (S1400). Here, the ITF may transmit the ITFRegistrationInputType record described above with reference to FIG. 6 as a registration request.

The Registration Server receives the registration request and determines whether to register the ITF (S1410). Here, the Registration Server may receive an ITFRegistrationInputType record as a registration request, and determine whether to register based on subscriber identifier information and subscriber location information included in the ITFRegistrationInputType record.

If the registration is approved, the ITF receives the ITFRegistrationOutputType record (S1420). Here, the ITFRegistrationOutputType record may be the ITFRegistrationOutputType record described above with reference to FIG. 7, and the information included in the TFRegistrationOutputType record may be information customized by the information included in the ITFRegistrationInputType record.

The ITF parses the MasterSITableLocation element of the received ITFRegistrationOutputType record and calculates position information of the Master SI Table included in the MasterSITableLocation element (S1430).

The ITF receives a Master SI Table Record based on the calculated position information of the Master SI Table (S1440). The received master SI table record may be a master SI table record described above with reference to FIG. 9.

The ITF parses the SubscribedChannelMap element of the received ITFRegistrationOutputType record, and calculates information about the channel map subscribed to by the user included in the SubscribedChannelMap element (S1450). Here, the ITF may calculate channel map location information for receiving a channel map subscribed to by a user from ChannelMapMaster of a Master SI Table Record.

The ITF receives a channel map record based on the calculated channel map position information in operation S1460. The received channel map record may be at least one of the channel map record described above with reference to FIG. 10 and the channel map record described above with reference to FIG. 11.

The ITF parses the ChannelDetailsLocation element of the received Channel Map Record, and calculates location information of the detailed information of the channel included in the ChannelDetailsLocation element (S1470).

The ITF receives a Channel Details Record based on the calculated position information of the detailed information of the channel (S1480). The received Channel Details Record may be a Channel Details Record shown in FIGS. 12A and 12B.

The ITF starts the received service service (S1490).

FIG. 15 is a flowchart illustrating an exemplary embodiment of a method of processing an update of a master SI table.

Referring to FIG. 15, the ITF updates a master SI table (S1500). The ITF monitors the Master SI Table in real time and can check whether the version of the received Master SI Table Record is changed. If the version of the received Master SI Table Record is changed, the ITF updates the Master SI Table with information contained in the received Master SI Table Record. .

The ITF selects a ChannelMapMaster element for updating among ChannelMapMaster elements included in the Master SI table (S1510).

The ITF checks whether the selected ChannelMapMaster element includes information for receiving a channel map subscribed to by the user (S1520). To do this, the ITF can use information about the channel maps subscribed to by the user included in the SubscribedChannelMap in the ITFRegistrationOutputType record.

If the user includes information for receiving the subscribed channel map, the ITF checks whether the version information included in the VCListVersion attribute of the selected ChannelMapMaster element has been changed (S1530). When the version information included in the VCListVersion attribute is changed, the ITF receives the updated channel map record and converts the channel map with the information included in the received channel map record. Update (S1540).

Check whether there is a ChannelMapMaster element that is not selected in the master SI table (S1550). If there is a ChannelMapMaster element that is not selected, the ITF performs step S1510.

FIG. 16 is a flowchart illustrating another exemplary embodiment of a method of processing an update of a master SI table. Referring to FIG.

Referring to FIG. 16, the ITF updates a master SI table (S1600). The ITF monitors the Master SI Table in real time and can check whether the version of the received Master SI Table Record is changed. If the version of the received Master SI Table Record is changed, the ITF updates the Master SI Table with information contained in the received Master SI Table Record. .

The ITF selects a ChannelMapMaster element for updating among ChannelMapMaster elements included in the Master SI table (S1610).

The ITF checks whether the selected ChannelMapMaster element includes information for receiving a channel map subscribed to by the user (S1620). To do this, the ITF can use information about the channel maps subscribed to by the user included in the SubscribedChannelMap in the ITFRegistrationOutputType record.

If the user includes information for receiving the subscribed channel map, the ITF checks whether the version information included in the VCListVersion attribute of the selected ChannelMapMaster element is changed (S1630). When the version information included in the VCListVersion attribute is changed, the ITF receives the updated channel map record and converts the channel map with the information included in the received channel map record. Update (S1640).

The ITF checks whether the version information included in the ChannelDetailsVersion attribute of the selected ChannelMapMaster element has changed (S1650). If the version information included in the ChannelDetailsVersion attribute is changed, channel details are updated (S1650).

Check whether there is a ChannelMapMaster element that is not selected in the master SI table (S1670). If there is a ChannelMapMaster element that is not selected, the ITF performs step S1610.

FIG. 17 is a flowchart illustrating an exemplary embodiment of a method of processing an update of a Channel Details Version.

Referring to FIG. 17, the ITF updates a channel map (S1700).

The ITF selects a channel from the channel map (S1710). In this case, the ITF may also select a ChannelDetailsLocation element including location information of detailed information of the channel selected in the channel map.

The ITF checks whether the version information included in the VCVersion attribute of the selected ChannelDetailsLocation element has changed (S1720). If the version information has changed, the ITF receives the updated Channel Details Record, and the Channel Details of the selected channel based on the information contained in the received Channel Details Record. Details) is updated (S1730).

The ITF checks whether there is a channel that is not selected in the channel map (S1740). If there is a channel that is not selected, the ITF performs step S1710.

FIG. 18 is a flowchart illustrating another exemplary embodiment of a method of processing an update of a channel details version.

Referring to FIG. 18, the ITF selects a channel from a channel map (S1800). In this case, the ITF may also select a ChannelDetailsLocation element including location information of detailed information of the channel selected in the channel map.

The ITF searches for a Virtual Channel Master element including a ServiceID attribute including identifier information such as identifier information included in the ServiceID attribute of the ChannelDetailsLocation element selected from the Master SI Table (S1810).

The ITF determines whether the version information included in the VCVersion attribute of the found Virtual Channel Master element is the same as the version information included in the VCVersion attribute of the selected ChannelDetailsLocation element (S1820). If different from the version information, the ITF receives the updated Channel Details Record and, based on the information contained in the received Channel Details Record, the Channel Details of the selected channel. Details) is updated (S1830).

The ITF checks whether there is a channel that is not selected in the channel map (S1840). If there is a channel that is not selected, the ITF performs step S1800.

19 is a diagram illustrating a schema of a preferred embodiment of an EPG Discovery Record Type according to the present invention.

Referring to FIG. 19, an EPG Discovery Record includes EPG discovery information for discovering EPG data. To this end, the EPG Discovery Record includes an EPGProviderID attribute, a Version attribute, a Name element, a Description element, an EPG ServerLocation element, a TargetServiceProviderID element, and a Logo element.

EPGProviderID includes identifier information that can uniquely identify a provider that provides EPG data. Here, a domain name registered as identifier information may be used.

The Version attribute includes version information of the EPG Discovery Record.

The Name element includes information about the text name of the EPG data provider, and the EPG data provider may have one name for each language. For this purpose, the Name element contains a Language attribute. In addition, the Name element may include a plurality of Language attributes, and each of the plurality of Language attributes includes information on the text name of the EPG data provider defined for each language.

The Description element includes detailed text description information about the EPG data provider, and the text description information may be one for each language similarly to the information against the name of the EPG data provider. For this purpose, the Description element includes a Language attribute. In addition, the Description element may include a plurality of Language attributes, and each of the plurality of Language attributes includes text description information defined for each language.

The EPG ServerLocation element includes IP address information capable of receiving EPG data and protocol information used for receiving EPG data.

The TargetServiceProviderID element contains ID information of service providers supported by the EPG data provider.

Logo contains location information of the logo of this EPG data provider. The location information of the logo may be in the form of a URI.

20 is a block diagram showing the configuration of a preferred embodiment of the ITF (IPTV Terminal Function) according to the present invention.

Referring to FIG. 20, the ITF includes a network interface unit, an IP network stack 2015, a file handler 2020, an SI handler 2025, and an EPG handler. 2030, Storage 2035, SI Decoder 2040, EPG Decoder 2045, ITF Operation Controller 2050, Channel Service Manager Channel Service Manager (2055), Application Manager (2060), Demultiplexer (2065), PSI / PSIP Parser (2070), A / V Decoder (A / V Decoder) (2075) And a display module 2080. The network interface unit may include a modem 2005 and an Ethernet NIC 2010.

The modem 2005 serves as an interface through which the ITF is connected to the IP network at the physical level. Modem 2005 demodulates a signal transmitted through a physical medium, restores it to a digital signal, and modulates a digital signal transmitted by the ITF to a service provider. To the IP network. The modem 2005 may be implemented as a cable modem, a DSL modem, or the like.

The Ethernet NIC 2010 restores an IP packet and outputs the digital signal received through the modem 2005 to the IP network stack 2015. In addition, the Ethernet network interface (Ethernet NIC) (2010) encapsulates the IP packet output from the IP network stack (2015) into an Ethernet datagram and outputs it to the modem (2005).

The IP Network Stack (2015) processes the processing modules of each layer according to the IP Protocol stack. The IP Network Stack (2015) is involved in packet delivery from source to destination for packets received at the ITF and packets transmitted by the ITF. The IP network stack 2015 classifies the received packets so as to correspond to an appropriate protocol, and outputs packets classified into a file handler 2020 and a demultiplexer 2065. For example, the IP Network Stack (2015) includes a Service Provider Discovery Record, an ITF Registration Output Record, a Master SI Table Record, and a Channel Map Record. When a packet including any one of a Channel Map Record, a Channel Details Record, and an EPG Discovery Record is received, the data included in the packet is a file handler. Output to (2020). The IP stack 2015 also outputs an IPF Registration Input Record (IPF) to an Ethernet network interface (Ethernet NIC) 2010 for IP packetization and delivery to a service provider.

The file handler 2020 collects the data output by the IP network stack 2015 and restores the data in a file form. Here, the file handler 2020 may restore data output from the IP network stack 2015 by using FLUTE in a file form. That is, the service provider may transmit a file using FLUTE, and the file handler 2020 may receive a file transmitted by the service provider using FLUTE. The file handler 2020 classifies the converted file and outputs the converted file to any one of the SI handler 2025 and the EPG handler 2030.

The SI handler 2025 processes a portion corresponding to the IPTV SI data among the file type data received from the file handler 2020 and stores the portion corresponding to the IPTV SI data in the storage 2035. Here, the IPTV SI data includes Service Provider Discovery Record, ITF Regitstration Output Record, Master SI Table Record, Channel Map Record, Channel Detail. It may be at least one of a Channel Details Record and an EPG Discovery Record.

The EPG handler 2030 may process a portion corresponding to the IPTV EPG data among the file type data received from the file handler 2020 and store it in the storage 2035. . Here, the IPTV EPG data may be received from the service provider by using information included in the EPG discovery record.

The storage 2035 is provided by the SI provided by the SI Handler 2025 and the EPG and the ITF Operation Controller 2050 provided by the EPG Handler 2030. Data to be stored.

The SI decoder 2040 decodes SI data stored in the storage 2035, restores necessary information, and provides the same to an ITF operation controller 2050. The SI decoder 2040 calculates information about a useful IPTV service provider from a service provider discovery record and information for accessing the service provider through a secure managed network. For example, the SI decoder 2040 may parse a service provider discovery record to calculate registration server address information included in the service provider discovery record.

In addition, the SI decoder 2040 may parse the ITF Registration Output Record to calculate information included in the ITF Registration Output Record. For example, the SI decoder 2040 may calculate EPG discovery information for discovering EPG data included in an ITF Regitstration Output Record and address information for receiving a master SI table record. Can be.

In addition, the SI decoder 2040 parses a master SI table record to receive a channel map record and a channel details record included in the master SI table record. Information, version information of the channel map record, and version information of the channel details record can be calculated.

The SI decoder 2040 may calculate channel map information from a channel map record, and calculate channel detail information of a corresponding channel from a channel details record. .

When EPG information is needed, the EPG decoder 2045 restores EPG data by importing and analyzing EPG data stored in storage 2035. The EPG decoder 2045 provides the restored EPG data to the ITF Operation Controller 2050.

The ITF Operation Controller 2050 controls the operation of the ITF. The ITF Operation Controller 2050 controls the SI Decoder 2040, the EPG Decoder 2045, and the Display Module 2080, and controls the ITF Operation Controller (ITF). The operation controller 2050 processes a request input from the channel service manager 2055 and the application manager 2060.

The ITF Operation Controller 2050 controls the SI Decoder 2040 to create a Channel Map and according to the key input received from the Channel Service Manager 2055. The channel is selected using the channel map. The ITF Operation Controller 2050 controls the SI Decoder 2015 so that the selected channel is received. The ITF Operation Controller 2050 may control the IP Network Stack 2015 so that the selected channel is received. The ITF Operation Controller 2050 may control the PSI / PSIP Parser 2070 such that the selected channel is received.

The channel service manager 2055 receives a channel request signal from a user and provides an input channel request signal to the ITF operation controller 2050 to change the channel to the requested channel. do.

Application Manager 2060 manages the overall state and provides a user interface. When the application manager 2060 receives the EPG display request from the user through the user interface, the application manager 2060 provides the display module (Display Modul) 2080 by providing the EPG display request to the ITF Operation Controller 2050. ) To display the EPG.

The demultiplexer 2060 demultiplexes the received packet into audio data, video data, program specific information (PSI) data, and the like, to respectively decode the A / V decoder 2075 and the PSI / PSIP parser (PSI / PSIP). Parser 2070). That is, the demultiplexer 2065 extracts MPEG-2 Transport Stream data from an IP packet received from an IP network stack 2015 and, according to each PID, a PSI / PSIP Parser 2070 or A / V decoder (A / V Decoder) (2075).

The PSI / PSIP Parser 2070 is a program element such as PID information of each data (A / V, etc.) of the MPEG-2 Transport Stream in the IP Datagram received from the demultiplexer 2060. Extract and parse PSI / PSIP data containing information that can be accessed. In addition, the PSI / PSIP Parser 2070 may control the demultiplexing process of the demultiplexer 2060 based on the extracted PSI / PSIP data.

An A / V decoder 2075 decodes the video data and the audio data received by the demultiplexer 2010. To this end, the decoder 2014 may include an audio decoder and a video decoder. The audio data decoded by the audio decoder is provided to a user through a display module 2080, and the video data decoded by the video decoder is displayed through a display module 2080.

The display module 2080 displays video data and audio data decoded by the A / V decoder 2075 according to the control of the ITF operation controller 2050. In addition, the display module 2080 receives the EPG data from the ITF Operation Controller 2050 and displays the received EPG data according to the ITF Operation Controller 2050.

21 is a flowchart illustrating a process of performing a preferred embodiment of the method for establishing a virtual channel according to the present invention.

Referring to FIG. 21, the ITF performs a network attachment (S2100). The network attachment is a procedure in which the ITF establishes a connection between the IP network and the layer 3 layer and acquires network configuration data.

The ITF performs a service provider discovery to obtain a service provider discovery record (S2105). In this case, the ITF may perform service provider discovery described above with reference to FIG. 13.

The ITF acquires SI and EPG data using the information included in the obtained Service Provider Discovery Record (S2110). Here, the ITF may perform service provider registration and service discovery described above with reference to FIG. 14 to obtain SI metadata. The ITF performs a Service Provider Registration, which allows the ITF to obtain a Registration Output Record (ITF), and based on the information contained in the obtained Registration Output Record (ITF). Service discovery may be performed. The ITF may perform a service discovery to obtain a master SI table record, a channel map record, and a channel details record. The SI metadata may be calculated from information included in a channel map record and a channel details record.

In addition, the ITF may acquire EPG data based on the information included in the EPGDiscoveryLocation included in the ITF Regitstration Output Record.

The ITF generates a channel map using the obtained SI metadata and stores the generated channel map (S1215). The ITF receives a user's virtual channel request signal (S1220). Here you can select a virtual channel to watch by up / down the channel.

In addition, the ITF generates an EPG using the obtained EPG data and stores the generated EPG (S1225). The ITF displays the stored EPG (S1230). The ITF receives the selected virtual channel request signal from the displayed EPG (S1235). Here, the user can select a specific virtual channel to watch in the EPG displayed on the screen.

The ITF searches for information about the requested virtual channel in the stored channel map according to the virtual channel request signal (S1240). Here, the ITF can detect the location information that can receive the virtual channel included in the LocationURL of the Channel Details Location by searching the channel map for the Channel Details Location including the SeviceID that matches the SeviceID of the requested virtual channel. In addition, the ITF may detect channel details including the SeviceID that matches the SeviceID of the requested virtual channel, and detect detailed information of the requested virtual channel.

The ITF tunes to the requested virtual channel based on the information on the retrieved virtual channel (S1245). Here, the ITF may receive an IPTV service for the requested virtual channel by accessing an address indicated by location information capable of receiving the detected virtual channel. The ITF provides the received IPTV service to the user (S1250).

FIG. 22 illustrates a schema of a preferred embodiment of a resource locator type, and FIG. 23 illustrates XML code of a preferred embodiment of a resource locator type of FIG. 22. All.

Referring to FIGS. 22 and 23, an element defined as a resource locator type may be a protocol such as inline media information, HTTP, etc., which is information on "Inline Media" encoded inline in an XML document in which the element exists. It may include at least one of media URL information, which is information on "MediaURL", which is a URL for a Resource that can be acquired through, and flute file information, which is information on a file transmitted to Multicast through FLUTE. For this purpose, the resource locator type may include at least one of an InlineMedia element, a MediaURL element, and a FluteFileLocator element.

The InlineMedia element contains media URL information. Inline media indicated by the media URL information may be hexadecimal or base64 encoded.

The MediaURL element contains media URL information. In this case, when the MediaURL element is a MediaURL type, the media URL information includes information for receiving streaming media through the RTP / RTSP protocol. If the MediaURL element is an HTTP resource type, the media URL information includes information for receiving a resource through the HTTP protocol. In addition, the media URL information may include information for receiving a resource through the mcast protocol.

The FluteFileLocator element contains the flute file information.

In the present invention, an element including information for receiving a resource may be defined as a resource locator type. In the present invention, an element including a LocationURL attribute may be defined as a resource locator type. The record provided by the service provider may be included in an element defined as a resource locator type, and the element defined as the resource locator type included in the record provided by the service provider may be an IPTV. It may include information for receiving a resource required to provide a service.

FIG. 24 illustrates a schema of a preferred embodiment of the flute file locator type, and FIG. 25 illustrates XML code of a preferred embodiment of the flute file locator type of FIG. Figure is a diagram.

24 and 25, the FluteFileLocator element includes a FileName element and a FluteSDP element. Here, the FileName element includes name information of a file to be received through the Flute protocol, and the FluteSDP element includes flute file transfer information including parameter information for receiving a file.

FIG. 26 illustrates a schema of a preferred embodiment of the flute SDP type, and FIG. 27 illustrates XML code of a preferred embodiment of the flute SDP type of FIG. 26. .

26 and 27, the FlutSDP element includes flute file transfer information. For this purpose, the FlutSDP element may include a TSI attribute, a startTime attribute, an endTime attribute, a tiasBandwidth attribute, an asBandwith attribute, an IPv4SourceAddr element, an IPv6SourceAddr element, an FluteChannel element, and an FecOtiType element.

The TSI attribute contains transport session identifier information for the flute session.

The startTime attribute contains the start time information at which the flute session begins.

The endTime attribute contains end time information at which the flute session ends.

The tiasBandwidth attribute contains TIAS bandwidth information of the flute session.

The asBandwith attribute contains the AS bandwidth information of the flute session.

The IPv4SourceAddr element contains address information defined in IPv4 of the host providing the file.

The IPv6SourceAddr element contains the IPv6 defined address information of the host providing the file.

The FluteChannel element contains channel information for the flute session.

FecOtiType element Contains FEC information.

FIG. 28 illustrates a schema of a preferred embodiment of the FEC Oti Type, and FIG. 29 illustrates an XML code of a preferred embodiment of the FEC Oti Type of FIG. 28. .

28 and 29, the FecOtiType element includes FEC information. To this end, the FecOtiType element may include a fecEncodingID element and a fecInstanceID element. Here, the fecEncodingID element includes FEC encoding identifier information used in a flute session, and the fecInstanceID element includes corresponding FEC instance identifier information.

30 is a diagram showing a schema of a preferred embodiment of the flute channel type, and FIG. 31 is a diagram showing an XML code of a preferred embodiment of the flute channel type of FIG. to be.

30 and 31, the FluteChannel element includes channel information for a flute session. To this end, the FluteChannel element may include a DestPort attribute, a tiasBandwith attribute, an asBandwidth attribute, an IPv4DestAddr element, and an IPv6DestAddr element. Here, the FluteChannel element may include at least one of an IPv4DestAddr element and an IPv6DestAddr element.

The DestPort attribute contains port information for receiving a channel.

The tiasBandwith attribute contains the TIAS bandwidth information of the channel.

The asBandwidth attribute contains the AS bandwidth information of the channel.

The IPv4DestAddr element contains multicast address information defined in IPv4 of a flute session or channel.

The IPv6DestAddr element contains multicast address information defined in IPv6 of a flute session or channel.

32 is a flowchart illustrating a process of performing an embodiment of a method for acquiring a resource for an IPTV service according to the present invention.

Referring to FIG. 32, the ITF performs a network attachment (S3200). The network attachment is a procedure in which the ITF establishes a connection between the IP network and the layer 3 layer and acquires network configuration data.

The ITF obtains an IPTV service record from the service provider through the network (S3205). Here, the IPTV service record is a Service Provider Discovery Record, an ITF Regitstration Output Record, a Master SI Table Record, a Channel Map Record, and Channel Details. It may be at least one of a Channel Details Record and an EPG Discovery Record. The IPTV service record may also be an XML document.

The ITF parses the IPTV service record to check whether there is a resource required from the IPTV service record (S3210). Here, the resource may be broadcast content or an IPTV service record. In addition, it is possible to check whether there is a required resource according to whether the IPTV service record includes an element defined as a resource locator type.

The ITF parses the IPTV service record to calculate an element defined as a resource locator type from the IPTV service record (S3215).

It is checked whether the calculated element includes any of InlineMedia element, MediaURL element, and FluteFile element (S3220).

If the calculated element includes the InlineMedia element, the ITF parses the InlineMedia element included in the IPTV service record to calculate inline media information included in the InlineMedia element (S3225). The ITF can find "Inline Media" based on the calculated inline media information.

If the calculated element includes the FluteFile element, the ITF parses the FluteFile element included in the IPTV service record to calculate the FluteSDP element included in the FluteFile element (S3230). The ITF parses the calculated FluteSDP element to calculate flute file transfer information included in the FluteSDP element (S3235). The ITF accesses the file indicated by the flute file transfer information through the flute protocol based on the calculated file transfer information, and acquires the corresponding file (S3240).

If the calculated element includes the MediaURL element, the ITF parses the IPTV service record to calculate type information of the MediaURL element (S3245). The ITF checks whether the calculated type information of the MediaURL element is one of streaming media and HTTP resource (S3250). If the calculated type information of the MediaURL element is Streaming Media, the ITF obtains Streaming Media through the RTP / RTSP protocol based on the media URL information included in the MediaURL element (S3255). If the calculated type information of the MediaURL element is an HTTP resource, the ITF obtains an HTTP resource through the HTTP protocol based on the media URL information included in the MediaURL element (S3260).

The present invention is not limited to the above-described embodiments, and can be modified by those skilled in the art as can be seen from the appended claims, and such modifications are within the scope of the present invention. .

1 is a system configuration diagram showing the concept of an IPTV service;

2 schematically illustrates a multicast scheme,

3 is a diagram schematically illustrating a unicast scheme;

4 is a flowchart illustrating a preferred embodiment of a method for searching for an IPTV service according to the present invention;

5 illustrates a schema of a preferred embodiment of a Service Provider Discovery Type according to the present invention;

6 illustrates a schema of a preferred embodiment of an ITF Registration Input Type according to the present invention;

7 illustrates a schema of a preferred embodiment of an ITF Registration Output Type according to the present invention;

8 is a diagram illustrating a relationship between tables configuring service information (SI);

9 illustrates a schema of a preferred embodiment of a Master SI Table Record Type;

FIG. 10 illustrates a schema of a preferred embodiment of a channel map type. FIG.

FIG. 11 illustrates a schema of another preferred embodiment for a Channel Map Type. FIG.

12A and 12B illustrate a schema of one preferred embodiment of a Channel Details Type;

FIG. 13 is a flowchart illustrating a preferred embodiment of a service provider discovery according to the present invention; FIG.

FIG. 14 is a flowchart illustrating a preferred embodiment of a service provider registration and service discovery according to the present invention; FIG.

FIG. 15 is a flowchart illustrating an exemplary embodiment of a method of processing an update of a master SI table; FIG.

FIG. 16 is a flow chart showing the implementation of another preferred embodiment of a method for processing an update of a Master SI table.

FIG. 17 is a flow chart showing the implementation of one preferred embodiment of a method for handling update of Channel Details Version. FIG.

FIG. 18 is a flow chart showing the implementation of another preferred embodiment of a method for handling update of Channel Details Version. FIG.

19 illustrates a schema of a preferred embodiment of an EPG Discovery Record Type according to the present invention;

20 is a block diagram showing the configuration of a preferred embodiment of the ITF (IPTV Terminal Function) according to the present invention;

21 is a flowchart illustrating a process of performing an embodiment of a method for establishing a virtual channel according to the present invention;

FIG. 22 illustrates a schema of a preferred embodiment of a Resource Locator Type. FIG.

FIG. 23 illustrates an XML code of a preferred embodiment of the Resource Locator Type of FIG. 22;

FIG. 24 illustrates a schema of one preferred embodiment for the Flute File Locator Type. FIG.

FIG. 25 illustrates XML code of a preferred embodiment for the Flute File Locator Type of FIG. 24;

FIG. 26 illustrates a schema of a preferred embodiment of the Flute SDP Type. FIG.

27 is a diagram showing an XML code of a preferred embodiment of the flute SDP type of FIG. 26;

FIG. 28 illustrates a schema of a preferred embodiment for an FEC Oti Type; FIG.

FIG. 29 illustrates XML code of a preferred embodiment for the FEC Oti Type of FIG. 28;

FIG. 30 illustrates a schema of a preferred embodiment for a Flute Channel Type. FIG.

FIG. 31 illustrates an XML code of a preferred embodiment of the Flute Channel Type of FIG. 30, and

32 is a flowchart illustrating a process of performing an embodiment of a method for acquiring a resource for an IPTV service according to the present invention.

Claims (24)

Connecting to a service provider via a network; An IPTV service record that includes a resource locator element that indicates the location of a resource, which is one of an inline encoded resource, a file transmitted by one of an HTTP server or a streaming server, and a file transmitted via the FLUTE protocol. Receiving a channel map record; Parse the received IPTV service record to obtain an element containing inline media information for obtaining the inline encoded resource from the resource locator element, a file transmitted by either the HTTP server or the streaming server. Extracting a child element, which is one of an element including media URL information for the element and an element including flute file information for obtaining a file transmitted through the FLUTE protocol; And Acquiring the resource according to the information included in the differential element. The method of claim 1, The IPTV service record includes a service provider discovery record including service provider information for recognizing the service provider and a connection method information for accessing the service provider, and a service discovery procedure. a master SI table record including channel map indication information for starting a process and version information for detecting a change of a service, and a master SI table for receiving the master SI table An ITF registration output record including indication information, a channel map record including information about a virtual channel provided by the service provider, and a channel map information of the virtual channel. Channel Details Record And an EPG discovery record including an EPG discovery information for receiving the EPG data. The method of claim 2, And when the IPTV service record is the service provider discovery record, the obtained resource is the ITF registration output record. The method of claim 2, And when the IPTV service record is the ITF registration output record, the obtained resource is the master SI table record. The method of claim 2, And when the IPTV service record is the master SI table record, the obtained resource is the channel map record. The method of claim 2, And when the IPTV service record is the channel map record, the obtained resource is the channel detail record. The method of claim 1, The file transmitted by the HTTP server is a resource acquisition method for an IPTV service, characterized in that the IPTV service record. The method of claim 1, The file transmitted through the flute protocol is the IPTV service record, characterized in that the resource acquisition method for the IPTV service. The method of claim 1, The media URL information includes at least one of streaming media information and HTTP resource information. The method of claim 9, The streaming media information may include information for receiving a media stream transmitted to MPEG-2 TS through a Real-time Transport Protocol (RTP) using or not using a Real-Time Streaming Protocol (RTSP). Resource Acquisition Method for IPTV Service. The method of claim 1, The flute file information includes file name information and flute file transfer information. The method of claim 11, The flute file transmission information includes at least one of transport session identifier information, flute session start time information, flute session end time information, TIAS band information, AS band information, host address information, flute session channel information, and FEC information. Resource acquisition method for an IPTV service comprising a. The method of claim 12, The flute session channel information includes at least one of port information, TIAS bandwidth information, AS band information, and multicast address information. The method of claim 12, The FEC information includes at least one of FEC encoding identifier information and FEC instance identifier information. A resource locator element that indicates the location of the resource, which is one of an inline encoded resource over the network, a file transmitted by one of the HTTP server and the streaming server, and a file transmitted via the FLUTE protocol. A network interface unit for receiving an IP packet carrying an IPTV service record; An element containing inline media information for parsing the IPTV service record to obtain the inline encoded resource from the resource locator element, a media URL for obtaining a file transmitted by any one of the HTTP server and the streaming server An SI decoder for extracting a child element, which is one of an element including information and an element including flute file information for obtaining a file transmitted through the FLUTE protocol; And  And an ITF operation controller (ITF Operation Controller) for controlling to acquire the resource according to the information included in the differential element. The method of claim 15, The IPTV service record includes a service provider discovery record including a service provider information for recognizing a service provider and a connection method information for accessing the service provider, and a service discovery process. Master SI table record including channel map indication information for starting a) and version information for detecting a change of a service, and a master SI table indication for receiving the master SI table. ITF Registration Output Record including information, Channel Map Record including information about the virtual channel provided by the service provider (Channel Map Record), Channel including channel details of the virtual channel Channel Details Record And an EPG discovery record including EPG discovery information for receiving EPG data. The method of claim 15, And the file transmitted by the HTTP server is the IPTV service record. The method of claim 15, And the file transmitted through the flute protocol is the IPTV service record. The method of claim 15, The media URL information includes at least one of streaming media information and HTTP resource information. The method of claim 19, The streaming media information may include information for receiving a media stream transmitted to MPEG-2 TS through a Real-time Transport Protocol (RTP) using or not using Real-Time Streaming Protocol (RTSP). IPTV receiver. The method of claim 15, And the flute file information includes file name information and flute file transfer information. The method of claim 21, The flute file transmission information includes at least one of transport session identifier information, flute session start time information, flute session end time information, TIAS band information, AS band information, host address information, flute session channel information, and FEC information. IPTV receiver comprising a. The method of claim 22, The flute session channel information includes at least one of port information, TIAS band information, AS band information, and multicast address information. The method of claim 22, The FEC information includes at least one of FEC encoding identifier information and FEC instance identifier information.

Images