KR20090059088A - Method for controlling a channel for building a channel map in an iptv receiver and apparatus thereof - Google Patents

Abstract

A channel controlling method for forming a channel map in an IPTV receiver and a device therefor are provided to enable an ITF(IPTV Terminal Function) to previously perceive an attribute related to service provision of each virtual channel, thereby more efficiently operating SI(Service Information) data for service acquisition. An IP network stack(2015) receives an IP stream including program guide data and SI data. A file handler(2020) demultiplexes the program guide data and the SI data of the received IP stream. An SI handler(2025) demultiplexes a channel technology table, a master SI table, and a virtual channel technology table that includes elements for determining times. An SI decoder(2040) parses the elements from the demultiplexed virtual channel technology table. A controller controls so that a virtual channel is displayed according to the parsed elements.

Description

Method for controlling a channel for building a channel map in an IP receiver and apparatus

The present invention relates to a channel control method and apparatus for forming a channel map in an IPTV receiver, and more particularly, to adaptively cope with a channel environment that is changed from time to time using information previously promised between a transmitting and receiving end in an IPTV environment. It's about what you want to do.

The broadcasting environment was separated from each other using the conventional terrestrial, cable, and satellite media, but it is becoming more and more integrated. In this process, an IPTV environment for providing services based on IP has recently been created and related standards have been made.

However, even if the IPTV environment is established, the service will still need to be serviced based on the channel. In other words, a channel operating method for providing a service even in an IPTV environment has an important meaning.

However, since the channel operation method is not complete in related standards currently being made, there is a problem that may confuse users and receiver terminal manufacturers.

The present invention has been made to solve the above problems, and an object of the present invention is to enable an IPTV receiver, that is, an ITF (IPTV Terminal Function) to efficiently set up a channel.

Another object of the present invention is to enable the ITF to efficiently operate a channel map.

Another object of the present invention is to enable ITF to efficiently operate an Inactive Channel.

It is another object of the present invention to enable ITF to provide Programming Guide Information for inactive channels.

Hereinafter, to achieve the above object, an example of a channel control method for forming a channel map in an IPTV receiver according to the present invention includes master service information including a first element defining a position of a virtual channel map table. information) receiving a table; Parsing the first element in the received master service information table; Receiving the virtual channel table including a second element defining a position of a virtual channel description table based on the position of the parsed element; If the virtual channel service is active, receiving the virtual channel description table including a third element indicating a time specification based on the parsed second element; Parsing a third element within the received virtual channel description table; And controlling the virtual channel to be displayed according to the parsed third element.

The third element may be a virtual channel active time element.

In addition, in the absence of the third element, the virtual channel service may always be active.

The mast service information table may include version information of the virtual channel map table.

An example of an IPTV receiver according to the present invention includes an IP network stack for receiving an IP stream including program guide data and service information (SI) data; A file handler for demultiplexing service information data and program guide data of the received IP stream; A virtual channel description table, an element for determining times when a virtual channel is active, a master service information (SI) table, and a service information (SI) handler for demultiplexing the channel description table; An SI decoder for parsing the element from the demultiplexed virtual channel description table; And a controller for controlling to display the virtual channel according to the parsed element.

The IPTV receiver may further include a storage configured to store the demultiplexed master service information (SI) table, a virtual channel map table, and a virtual channel description table.

The IPTV receiver may further include a display unit for displaying the virtual channel service.

The controller may determine whether the element exists.

In addition, the virtual channel service may be in an active state when there is no element.

The controller may control a display unit to display the virtual channel.

Therefore, according to the channel operating method and apparatus according to the present invention,

First, the ITF has the effect of identifying in advance the attributes related to the service provision of each virtual channel.

Second, the SI data for each channel map and service acquisition can be more efficiently used.

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 widely used general terms as possible in consideration of the functions in the present invention, but may vary according to the intention or custom of the person skilled in the art or the emergence of new technologies. 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, maintains the transmission network so that the user can receive the content stably, and provides the infrastructure for the network provider to the content provider. Provide the function. 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 and executed automatically on the customer side. 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, the Portal service also has features such as user authentication and license agreements, 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 a function for providing such services, and in order for these functions to operate normally, the server 130 of each service provider may transmit a 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 form such as MPEG-4 or MPEG-7 in order 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. Therefore, IPTV receivers that provide IPv4 are not unusable.

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 coming from network and play it on screen in case of multimedia data, and to control data packet when operating with remote controller It needs to be sent quickly to the server and get the information from the server and react. 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.

On the other hand, the NMS mentioned above performs the RCMS function as well as the function that the service provider manages the network. 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 transmitted in push mode, the service provider 410 transmits the service provider discovery record regardless of the request for the ITF 420 to transmit 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 emergence 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 contains detailed text description information about the service provider, and there may be one text description information for each language similar to the information about the service provider's name. 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. Through the information included in the ConsumerLocation, the registration server can recognize the location of the subscriber to determine the area and send the 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 be only 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 channels on the channel map, but specifies 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 indicating whether 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 a 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 specifying 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 property, it guarantees scalability to MPTS and also provides an opportunity to check whether the received stream is the one I want 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.

14 is a flowchart illustrating a preferred embodiment of a service provider registration and a 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). If the version information included in the VCListVersion property 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. ) 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 about a text name of an 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 Service Manager 2055, Application Manager 2060, Demultiplexer 2065, PSI / PSIP Parser 2070, A / V Decoder 2075 and And a display module 2080. The network interface unit may include a modem 2005 and an Ethernet NIC 2010.

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 forwarding 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 calculates 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 do.

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 retrieves and analyzes EPG data stored in the storage 2035 to restore the EPG data. 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 a channel service manager 2055 and an 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 at 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 under 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, the user 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 the information on 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).

Hereinafter, a method and apparatus for controlling a channel for building a channel map in an IPTV terminal function (ITF) according to the present invention will be described in detail with reference to the accompanying drawings. Therefore, according to the present invention, it is possible to seek convenience of the user in providing the IPTV service in the ITF.

In particular, the present disclosure describes a method and apparatus for controlling a channel in order to more efficiently build a channel map in the ITF using system information (SI) and electronic programming guide (EPG) data essential for IPTV service use.

In this regard, the term "channel" is used herein to mean both the concept of a channel used in an existing broadcasting environment and a channel related to the use of IPTV service and content.

In the present specification, the term "active channel" includes contents defined in a related standard, and when referring to SI information and EPG information necessary for IPTV service and content use, the current broadcast is not interrupted. Used to mean the channel being used.

In addition, in the present specification, the term "inactive channel" is used to mean a channel which is not currently being serviced because broadcast is interrupted unlike the active channel.

In an IPTV environment, the service of each virtual channel may not be continuous for 24 hours. For example, either virtual channel may be an active channel from 6:00 AM to 12:00 PM, but an inactive channel except for the above time. Therefore, in operating the channel, the ITF needs to be more aware of the channel status for each virtual channel. However, the current specification does not specifically define the contents thereof, that is, information about a change in channel state in relation to channel operation. Therefore, the ITF does not reflect such a channel state or the like, resulting in inefficient channel operation, which may cause inconvenience to a user.

Accordingly, in the present invention, the above-described problems are defined in SI data or EPG data by appointment between the transmitting and receiving terminals by defining information related to channel operation such as changing the state of each channel and the state thereof according to an embodiment of the present invention. To solve this problem. Therefore, according to the present invention, the ITF can operate the channel more efficiently, thereby eliminating user inconvenience.

FIG. 22 illustrates, in relation to the present invention, main components of SI data necessary for service acquisition of IPTV, their relations, and their relationships with EPGs.

Referring to FIG. 22, the SI data is the information that is necessary for the ITF to access and parse the content.The master SI table, It includes a virtual channel map (Virtual Channel Map), and a virtual channel description table (Virtual Channel Description table). In this case, the remaining tables other than the master SI table may be distinguished by being referred to as other SI tables, for example.

The master SI table is for controlling an issue such as a version of SI data, and includes a virtual location of the virtual channel map instance information element and each virtual that matches a version number in the virtual channel map instance itself. Version number of this instance of the Virtual Channel Map instance, which shall match the version number in the Virtual Channel Map instance itself. Here, the location information is represented, for example, a VirtualChannelUrl element. Therefore, the ITF may receive the individual virtual channel map instance using the VirtualChannelUrl element in the master SI table.

The virtual channel map provides information on the virtual channels of the service provider (SP) that provides the SI data and the IPTV service, and the default location information element of the file including the virtual channel description of the virtual channels in the virtual channel map. (Default location of the file containing the Virtual Channel Descriptions of the virtual channels in this VirtualChannelMap) and each virtual channel service element. Here, the default location information element may be represented by, for example, a VirutalChannelDescription element, and each of the virtual channel service elements may be represented by a VirtualChannelService element. The VirtualChannelService element may include an entry (Each Virtual Channel Service has an entry), and the entry may include, for example, a VirtualChannelDescriptionOverride element. Accordingly, the ITF may receive the virtual channel description table using the VirutalChannelDescription element in the virtual channel map.

The virtual channel description table provides resource information for accessing each virtual channel, and is specific for receiving a VirtualChannelServiceId element defining an identifier of the virtual channel service and an associated source table. Contains a number of ProgrammingSource elements defined by values. Therefore, the ITF may receive the relevant source table using the ProgrammingSource element.

Eventually, the ITF receives the virtual channel map using the received master SI table, receives the virtual channel description table using the received virtual channel map, and receives the associated source table using the received virtual channel map description table. do.

Referring to FIG. 22, the EPG data provides information about a virtual channel service and includes a VirtualChannelService element. Here, the VirtualChannelService element in the EPG data is associated with a VirtualChannelService element included in the virtual channel map in the SI data and a VirtualChannelServiceId element included in the virtual channel description table.

FIG. 23 illustrates a screen in which the ITF receives EPG data and outputs EPG information.

Referring to FIG. 23, 30-1 (ABC), 31-1 (NBC), 32-1 (FOX-1), and 32-2 (FOX-2) that exist between 12:00 and 15:00. Four channels are shown. And guide information for each channel is provided.

Here, the 32-2 (FOX-2) channel is in an invalid state in which service is not provided from 12:00 to 14:00, and a valid state in which service is provided from 14:00. Becomes At this time, the ITF requests the user to access the 32-2 (FOX-2) channel through Channel Up / down or EPG screen between 12:00 and 14:00. In this case, access should not be allowed because the channel is in balanced state.

To this end, the ITF needs to know whether the channel is in the balanced state at that time, that is, the ITF needs to know the state of the channel to properly respond to the channel access request. However, since information related to channel status and the like is not defined in the SI data or EPG data defined in the related standard, ITF is not aware of it, and it cannot operate properly in such a situation and has to operate inefficiently.

In the following description, a method of controlling a channel for building a channel map in an IPTV terminal function (ITF) according to the present invention as described above is divided into two methods. First, the method defines and uses each virtual channel property, that is, information about when the corresponding virtual channel is changed from an active channel to an inactive channel and vice versa. Second, whether the virtual channel is currently an active channel or an inactive channel. There is a way to tell them and define information about when the current property changes from one property to another. Hereinafter, the method will be described with reference to each embodiment.

First, an embodiment according to the first method will be described.

FIG. 24 illustrates a schema of a Virtual Channel Availability element constructed according to an embodiment of the present invention, and FIG. 25 illustrates the schema of FIG. 24 in XML format.

24 and 25, the virtual channel attribute element includes time information when the state of the virtual channel changes. Here, the time information when the corresponding virtual channel state changes is, for example, information about the time when the corresponding virtual channel is changed from the inactive channel to the active channel, and conversely, the time when the corresponding virtual channel is changed from the active channel to the inactive channel. It includes at least one of information about.

24 and 25, according to the present invention, the virtual channel attribute element may include at least one element of the VCValidateTime element and the VCInvalidateTime element. In this case, the virtual channel attribute element may include only one element corresponding to whether the corresponding virtual channel is an inactive channel or an active channel. Accordingly, the ITF may determine whether the virtual channel attribute element exists and the virtual channel is an active channel or an inactive channel from an element existing below it.

The VCValidateTime element is an element of a dateTime type and is valid when the corresponding virtual channel is an inactive channel (for example, when SI data is produced). The value of this element indicates the time when the corresponding virtual channel is switched to the active channel in the future, and if there is no plan to switch the virtual channel to the active channel at present, the element may be set to a specific value to indicate this. It indicates the time when the corresponding virtual channel service becomes active. (Designation of the times when this Virtual Channel Service is active (ie, “on the air”). If this element is omitted, it SHALL mean that this Virtual Channel Service is always active.)

The VCInvalidateTime element is a datetime type element and is valid when the corresponding virtual channel is active (for example, when SI data is produced). The value of this element indicates when the virtual channel will be converted to an inactive channel in the future. If there is currently no plan to convert the virtual channel to an inactive channel, this element is set to a specific value. It indicates the time when the corresponding virtual channel service becomes inactive.

FIG. 26 illustrates a schema structure of a virtual channel service type including the virtual channel attribute element schema of FIG. 24 according to an embodiment of the present invention. FIG. 27 expresses the schema of FIG. 26 in an XML form.

26 and 27, the position of the virtual channel attribute element according to an embodiment of the present invention is not limited. That is, the virtual channel attribute element is described as being included in a virtual channel map. For example, the virtual channel attribute element may be included in a virtual channel description table. However, in the present specification, for convenience of description, it is illustrated as a lower element of the virtual channel service element. Here, the virtual channel service element is one of a plurality of elements of a virtual channel map element that is a child element of the virtual channel map element. In addition, the virtual channel service element includes a virtual channel service element below, and the virtual channel service element includes a plurality of elements below the bar. The virtual channel attribute element according to an embodiment of the present invention also includes the virtual channel. It is an example of being included in a service element.

Therefore, when the content of the above-described virtual channel attribute element is updated, the virtual channel service version element of the virtual channel service element is also updated so that the ITF can know that there is a change in the corresponding virtual channel information. can do.

Next, another embodiment according to the second method will be described.

FIG. 28 illustrates a schema of a virtual channel attribute element constructed according to an embodiment of the present invention, and FIG. 29 illustrates the schema of FIG. 28 in an XML form.

Hereinafter, the description of the parts common to those described above with reference to FIGS. 24 to 25 will be used, and the description will be given based on different parts. In the present embodiment, unlike the above-described embodiment, both of the following elements may exist.

The VCAvailabilityFlag element is a flag of the boolean type. The flag indicates whether the virtual channel is currently an active channel or an inactive channel (for example, when SI data is produced). Only when this element indicates that the virtual channel is an inactive channel, the next Virtual Channel Validate Time element becomes valid.

The VCValidateTime element is identical to the definition of FIG. 24 described above, but is valid only when the VCAvailabilityFlag element indicates that the virtual channel is an inactive channel.

However, the technical idea of the present invention is not limited to the name or description of each element. For example, the flag element may indicate the state of the corresponding virtual channel, i.e., whether it is invalidated or valid, and thus the state in the time element is different from the current state, i.e. from inactive channel to active channel or in active channel. It can also be defined as giving information about the time to change to the active channel. It can be seen that it is naturally included in the technical idea of the present invention.

Therefore, the ITF determines whether the corresponding virtual channel is an active channel or an inactive channel from the VCAvailabilityFlag element, and if the determination result is an inactive channel, the ITF may know when the virtual channel is changed to the active channel from the VCValidateTime element and reflect the result. . In this case, if the VCAvailabilityFlag element does not exist and only the VCValidateTime element exists, the ITF may determine that the virtual channel is an inactive channel and process it.

FIG. 30 illustrates a schema structure of a virtual channel service type including the virtual channel attribute element schema of FIG. 28 according to an embodiment of the present invention. FIG. 31 illustrates the schema of FIG. 30 in an XML form.

30 and 31 are the same as the contents described above with reference to FIGS. 26 and 27, and use thereof. 28 and 29, the virtual channel attribute part is different.

32 is a flowchart illustrating a method of controlling a channel to build a channel map in an IPTV terminal function (ITF) using a virtual channel attribute element according to an embodiment of the present invention. to be.

FIG. 32 shows that when a user requests a channel change through, for example, a channel up / down using a remote controller or a selection in an EPG output on a screen, the ITF requests the request. In this case, when the virtual channel to be changed is an inactive channel, a structure of preventing tuning to the virtual channel using the attribute information of the virtual channel in the SI data will be described. Here, steps S3201 to S3209 of FIG. 32 are the same as those of FIG. 21, and will be described below from step S3210.

The ITF determines whether there is a virtual channel attribute element in the channel map information by using the search result in step S3209 (S3210).

As a result of the determination in step S3210, if there is no virtual channel attribute element in the channel map information, the corresponding virtual channel requested from the user is tuned in step S3205 or S3208 (S3214). In operation S3215, an IPTV service received through the tuned virtual channel is provided to the user.

However, as a result of the determination in step S3210, if there is a virtual channel attribute element in the channel map information, the virtual channel attribute element is parsed (S3211). In operation S3212, it is determined whether the corresponding virtual channel requested from the user is an inactive channel based on the parsed virtual channel attribute element. In operation S3212, whether the corresponding virtual channel is an inactive channel may be determined in two ways, for example, according to the present invention described above with reference to FIGS. 24 and 26.

That is, as described above with reference to FIG. 24, if the lower element of the parsed virtual channel attribute element is a VCValidateTime element, the virtual channel may be determined to be an inactive channel. However, if the lower element is a VCInvalidateTime element, the corresponding virtual channel may be determined as an active channel.

The other is to use the VCAvailabilityFlag element among sub-elements of the parsed virtual channel attribute element, as described above in FIG. 28. That is, since the VCAvailabilityFlag element indicates whether each virtual channel is currently an active channel or an inactive channel, it can be determined whether the corresponding virtual channel is an inactive channel requested from the user.

Accordingly, if the corresponding virtual channel is not an inactive channel as a result of the determination in step S3212, the ITF performs steps S3214 and S3215 as in the flow of the case in which the virtual channel attribute element in the channel map information does not exist in the determination result in step S3210. Provides IPTV service to users via

However, if it is determined in step S3212 that the virtual channel is an inactive channel, the ITF prevents the virtual channel from being tuned despite the user's request (S3213). However, since the ITF receives a request for channel change from the user in step S3205 or step S3208, a response may be required. In this case, the ITF may, for example, provide a user interface (UI) (eg, the EPG screen of FIG. 23) with the message “No Service” or “When this Channel will be available”. The flow returns to step S3204 to wait for the user's channel selection request.

According to the above-described preferred embodiment of the present invention, the ITF can grasp the attributes related to the service provision of each virtual channel in advance, and more efficiently manage the SI data for each channel map and the service acquisition. Can be.

On the other hand, the terms used in the present invention (terminology) are terms defined in consideration of functions in the present invention, which may vary according to the intention or custom of a person skilled in the art, the definition of which is used throughout the present invention. It should be based on what has been done.

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.

And, the above-mentioned numerical value is a preferred embodiment or merely an example, and the scope of the present invention is not limited to the numerical values, and as can be seen in the appended claims, the general scope of the present invention. Modifications are possible by those skilled in the art 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 process of searching for an IPTV service according to an embodiment of the present invention;

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

6 is a diagram illustrating a schema of an ITF Registration Input Type according to an embodiment of the present invention;

7 is a diagram illustrating a schema of an ITF registration output type according to an embodiment of the present invention;

8 is a view showing a relationship between each table constituting a service information (SI) in the context of the present invention,

9 illustrates a schema of a Master SI Table Record Type according to an embodiment of the present invention;

10 illustrates a schema of a channel map type according to an embodiment of the present invention.

11 is a diagram illustrating a schema of a channel map type according to another embodiment of the present invention;

12A and 12B illustrate a schema of a channel details type according to an embodiment of the present invention.

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

14 is a flowchart illustrating a process of performing service provider registration and service discovery according to an embodiment of the present invention.

15 is a flowchart illustrating a process of a method of processing an update of a master SI table according to an embodiment of the present invention;

16 is a flowchart illustrating a procedure of a method of processing an update of a master SI table according to another embodiment of the present invention;

17 is a flowchart illustrating a process of a method of processing an update of Channel Details Version according to an embodiment of the present invention;

18 is a flowchart illustrating a process of a method of processing an update of a channel detail version according to another embodiment of the present invention;

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

20 is a block diagram showing the configuration of an IPTV terminal function (ITF) according to an embodiment of the present invention;

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

FIG. 22 is a view showing a main component of SI data necessary for service acquisition of an IPTV, its relationship, and a relationship with an EPG in relation to the present invention;

FIG. 23 is a diagram illustrating a screen in which an ITF receives EPG data and outputs EPG information. FIG.

24 is a diagram illustrating a schema of a Virtual Channel Availability Element configured according to an embodiment of the present invention, FIG. 25 is a diagram illustrating the Virtual Channel Availability Element schema of FIG. 24 in an XML form.

FIG. 26 illustrates a schema structure of a "virtual channel service type" including the "virtual channel attribute" element schema of FIG. 24 according to an embodiment of the present invention; FIG.

FIG. 27 is a diagram illustrating the schema of FIG. 26 in XML form; FIG.

FIG. 28 is a diagram showing a schema of a "virtual channel attribute" element constructed according to an embodiment of the present invention; FIG.

FIG. 29 is a diagram showing the "virtual channel attribute" element schema of FIG. 28 in XML form;

30 is a diagram illustrating a schema structure of a "virtual channel service type" including the "virtual channel attribute" element schema of FIG. 24 according to one embodiment of the present invention;

FIG. 31 is a diagram illustrating the schema of FIG. 30 in XML form; FIG.

32 is a flowchart illustrating a method of setting a virtual channel of an ITF using a "virtual channel attribute" element according to an embodiment of the present invention.

Claims (10)

Receiving a master service information table including a first element defining a location of a virtual channel map table; Parsing the first element in the received master service information table; Receiving the virtual channel table including a second element defining a position of a virtual channel description table based on the position of the parsed element; If the virtual channel service is active, receiving the virtual channel description table including a third element indicating a time designation based on the parsed second element; Parsing a third element within the received virtual channel description table; And And controlling a virtual channel to be displayed according to the parsed third element. The method of claim 1, And the third element is a virtual channel active time element. The method of claim 1, And if the third element is absent, the virtual channel service is always active. The method of claim 1, The mast service information table includes version information of the virtual channel map table. An IP network stack for receiving an IP stream comprising program guide data and service information (SI) data; A file handler for demultiplexing service information data and program guide data of the received IP stream; A virtual channel description table, an element for determining times when a virtual channel is active, a master service information (SI) table, and a service information (SI) handler for demultiplexing the channel description table; An SI decoder for parsing the element from the demultiplexed virtual channel description table; And And a control unit for controlling to display a virtual channel according to the parsed element. The method of claim 5, The IPTV receiver, And a storage unit for storing the demultiplexed master service information (SI) table, a virtual channel map table, and a virtual channel description table. The method of claim 6, The IPTV receiver, The IPTV receiver further comprises a display unit for displaying the virtual channel service. The method of claim 7, wherein And the control unit determines whether the element exists. The method of claim 8, And the virtual channel service is active when the element is absent. The method of claim 9, The control unit is an IPTV receiver for controlling the display unit for displaying the virtual channel.

Images