KR20100081408A - Broadcasting receiver and method for monitoring a state of return channel - Google Patents

Abstract

PURPOSE: A broadcasting receiver and a method for monitoring a state of return channel are provided to monitor the channel state, thereby rapidly providing channel state information. CONSTITUTION: A communication control unit(388) generates return channel interface listener instance receiving return channel state information and registers the instance. The communication control unit monitors whether state of a return channel is changed. If the state of the return channel is changed, the communication unit generates event instance informing the return channel state information. The communication control unit transmits the generated event instance to the registered return channel listener instance.

Description

Broadcasting receiver and method for monitoring a state of return channel}

The present invention relates to a broadcast receiver and a return channel state monitoring method, and more particularly, to a broadcast receiver and a return channel state monitoring method capable of sensing a channel state and providing sensed information.

In general, digital broadcasting is multichannel / multimedia broadcasting, unlike conventional analog broadcasting, not only providing high-quality / high-quality service but also having versatility. Versatility is a new service that provides multimedia information through broadcast media. It refers to data broadcasting or interactive broadcasting. Data broadcasting is a broadcast that uses information to broadcast receiver by transmitting multimedia data such as text, still picture, moving picture, graphic, document, software, etc., and is the best service for the current trend of convergence of broadcasting and communication.

In order to provide such services, middleware platform providers need to access multimedia data distributed over a number of heterogeneous broadcast and web-enabled networks. These networks are generally used as examples, such as Digital Video Broadcasting (DVB) (including DVB-C (cable), DVB-T (terrestrial), and DVB-S (satellite)), OpenCable.TM. Application platform United States or Europe, including OpenCable.TM.Applications Platform (OCA), Next Generation Television System Committee (ATSC), National Television System Committee (NTSC), GI Motorola Network, Multimedia Home Platform (MHP) standards, and more Based on industry digital broadcasting standards. In particular, the MHP standard extends existing DVB standards for broadcast and interactive services in all transport networks, including satellite, cable, terrestrial and microwave. The DVB / MHP standard defines a hardware independent, interface between the terminals and interactive digital applications that they run. This allows digital content providers to handle all types of terminals, from low functionality to high performance set top boxes, integrated digital TV sets and multimedia PCs.

Version 1.0.3 of the MHP standard supports a freely downloadable application called 'Xlet'. That is, the MHP standard uses Xlet Application to handle various user requirements. At this time, Xlet Application receives system resources from middleware and handles these tasks. In other words, Xlet applications can be run on all types of terminals, from low-functioning to high-end set-top boxes, integrated digital TV sets, and multimedia PCs, by allocating them through middleware rather than directly allocating resources from broadcast receivers.

An object of the present invention is to provide a broadcast receiver and a return channel state monitoring method capable of quickly providing channel state information by monitoring channel state.

Another technical problem to be solved by the present invention is to provide a broadcast receiver and a return channel state monitoring method for immediately informing when a channel state changes dynamically.

In accordance with an aspect of the present invention, a method for monitoring a return channel state according to the present invention comprises: generating a return channel interface listener instance for receiving return channel state information that is information about a state of the return channel, and generating the returned return Registering a channel interface listener instance; Monitoring whether the return channel has changed state; And when the state of the return channel is changed, generating an event instance informing of the return channel state information, and delivering the generated event instance to the registered return channel interface listener instance. The return channel may include a digital CATV return channel, a digital enhanced cordless telecommunications (DECT) return channel, a public switched telephone network (PSTN) return channel, an integrated services digital network (ISDN) return channel, and a local multipoint distribution (LMDS). It may include at least one of a System (CH) return channel and a MA-TV Return channel. In addition, the return channel may be one of a normal operation state and an abnormal state.

Advantageously, the return channel state monitoring method may further comprise requesting the return channel state information.

Preferably, the return channel state bonnetizing method may further include acquiring a return channel interface implementation instance for managing an interface of the return channel. The return channel interface implementation instance may be implemented by adding a function of monitoring a state of the return channel to a class modeling a network interface of the return channel. The class may be org.dvb.net.rc.RCInterface.

Preferably, in the registering step, the return channel interface listener instance may be registered using a method provided by the return channel interface implementation instance.

In order to achieve the above another technical problem, a broadcast receiver according to the present invention comprises a network interface for providing a return channel; And generating and registering a return channel interface listener instance that receives return channel status information, which is information about the status of the return channel, and monitoring whether or not the status of the return channel changes. And a controller configured to generate an event instance for notifying return channel state information and to deliver the generated event instance to the registered return channel interface listener instance. The return channel may include a digital cable television (CATV) return channel, a digital enhanced cordless telecommunications (DECT) return channel, a public switched telephone network (PSTN) return channel, an integrated services digital network (ISDN) return channel, a local multipoint distribution system (LMDS). ) And at least one of a master-antenna television (MATV) return channel. In addition, the state of the return channel may be any one of a normal state and an abnormal state.

Preferably, the control unit may generate a return channel interface implementation instance managing the interface of the return channel. The return channel interface implementation instance may be implemented by adding a function of monitoring a state of the return channel to a class modeling a network interface of the return channel. The class may be org.dvb.net.rc.RCInterface.

Preferably, the control unit may register the return channel interface listener instance by using a method provided by the return channel interface implementation instance.

According to the broadcast receiver and the method for monitoring the return channel state according to the present invention, since the state of the return channel is monitored in real time, it is possible to provide return channel state information quickly and to change the state of the return channel dynamically. It can be detected immediately, providing a faster and more reliable service to the user.

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

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

1 is a structural diagram showing a configuration of a preferred embodiment of the hierarchical structure of a broadcast receiver.

Referring to FIG. 1, the broadcast receiver 100 according to the present invention includes an application 110, a middleware 120, and resources 130.

Application 110 is defined as a program executed to achieve various purposes in broadcast receiver 100. The application 110 may be executed by the plurality of applications 111, 112,..., 119 on the broadcast receiver 100.

 Applications 111, 112,... 119 are broadcast in a broadcast stream with digital television programs to a properly installed broadcast receiver 100. The applications 111, 112,..., 119 can be broadcast in a carousel format according to a protocol such as the DSM-CC protocol specified under ISO / IEC13818-6, where the applications 111, 112,. Are broadcast periodically. Properly installed broadcast receiver 100 receives these applications 111, 112,..., 119 and executes them locally. Example applications 111, 112,..., 119 include electronic program guides, play-along games, telebanking, menu navigation options, teleshopping, electronic newspapers, and similar information services.

The application 110 may be an Xlet application in a MHP-based standard. The basic hardware for running Xlets is a set top box or digital television receiver that supports the Java TV platform (eg, middleware 120 of FIG. 1). Xlets do not have a "main" way and Xlets implement the interface Xlet.

Xlets have a life cycle, and the life cycle method signature is defined by the interface Xlet. Interface Xlet provides lifecycle methods for reporting Xlet state changes such as creation, initialization, startup, and destruction. However, the interface Xlet does not provide execution for its lifecycle methods. All Java TV implementations have an application manager 127 that calls lifecycle methods to move one or more Xlets through various application states via an interface Xlet. Interface Xlet does not provide execution for its lifecycle methods. The developer provides application-specific executions for those methods by defining what happens at each point in the Xlet life cycle. For example, the iniXlet method for a game Xlet will create user interface components. The Xlet is designed to notify the application manager 127 of the state changes by initiating some state changes themselves and causing methods in the XletContext interface.

The interface Xlet is defined by the javax.tv.xlet package, one of the packages defined in the Java TVTM API. The Java TV API consists of interfaces and classes grouped into packages. These packages include interfaces and classes for processing video, audio, and data sent to a digital receiver via a broadcast stream sent by television networks.

The interface Xlet, defined in javax.tv.xlet, allows the application manager to create, initialize, start, stop, and destroy Xlets. The application manager 127 maintains the state of the Xlet and causes the methods on the Xlet through various lifecycle methods. The Xlet executes these methods to update its internal operations and resource usages as directed by the application manager 127.

2 is a conceptual diagram illustrating an example of a life cycle of an application.

Referring to FIG. 2, the method summary of the interface Xlet, as defined by javax.tv.xlet, is as follows. The Xlet is in a loaded state 210 in memory. initXlet initializes the Xlet itself in the loaded state (210) and signals the Xlet to enter the paused state (220). startXlet signals the Xlet to start providing services and to enter an active state (230). The PauseXlet signals the Xlet to stop providing service and enter the suspended state 220. destroyXlet signals the Xlet to terminate service provision and enter a destroyed state (240).

On the other hand, not only the first embodiment, but also other embodiments to be described below, in consideration of the convenience of explanation and understanding, the application 110 will be described by taking the case of an MHP application as an example. Therefore, the scope of the present invention is not limited to the MHP standard, but may be applied to other data broadcasting standards, and this point is apparent when considering the claims of the present specification.

For example, the present invention can be applied not only to cables but also to data broadcasting through terrestrial and satellite broadcasting. That is, the broadcast receiver 100 according to the present invention may operate a terrestrial broadcast mode (Antenna), a satellite broadcast mode, a cable broadcast mode (cable) by operating a remote control or a "TV / Video" button of a local key to a user. Allows input of Video 1, Video 2, and so on.

The middleware 120 plays a role of mediating between the application 110 and the resource 130. In addition, the middleware 120 receives the information or command of the application 110, executes the received command to calculate a result of the received command, and transmits the calculated result to the application 120. For this purpose, the middleware 120 includes an interface 121 and a system service 126.

The interface 121 performs a function of transmitting and receiving data, information, and commands between the application 110 and the system service 126. That is, the application 110 may use a service provided by the middleware 120 through the interface 121. In order for the producer of the application 110 to use the middleware 120, each broadcast standard defines a request form for requesting a specific service provided by the middleware 120. If the application 110 requests the middleware 120 to perform a specific service according to the request abbreviation defined in each broadcasting standard, the interface 121 receives a request to perform a specific service and the system service 126. The request for execution of the specific service is transmitted to the system service 126 so that the specific service can perform the specific service requested. Here, the request form for requesting a specific service provided by the middleware 120 defined in the broadcast standard may be an API (Application Programming Interface) defined by JAVA.

For example, the request form for requesting a specific service may be defined as an API of the MHP. As is well known, MHP 1.0.x is basic and specifies a wide range of application execution environments for digital interactive TVs, regardless of vendor specific hardware and software. This execution environment is based on the definition of generic APIs that provide the use of a Java ™ virtual machine and access to common resources and facilities of an interactive digital TV terminal. Java ™ applications that use these generic APIs are called DVB-J applications. In contrast, MHP 1.1 provides additional functionality for the MHP 1.0.x platform in a number of ways, including defining a new optional application type, DVB-HTML. For MHP 1.0.x, only DVB-J is required to be supported. Therefore, for DVB-J applications running under MHP 1.0.x, "javax.tv.xlet.Xlet" is a defined interface and an entity that can be executed and recognized under MHP 1.0.x.

The system service 126 performs the service according to the request transmitted by the interface 121 and provides the result to the interface 126. In addition, the system service 126 downloads the application 110 from the broadcasting station, manages the life cycle of the downloaded application 110, and allocates the resource 130 to the application 110 in an active state 230. And manages returns and manages information about allocated resources. To this end, the system service 126 includes an application manager 127. Here, the middleware 120 may be implemented according to the MHP standard, for example, to support the MHP API.

The application manager 127 is a module that manages life cycles of the applications 111, 112,..., 119. The application manager 127 manages the creation, execution, and termination of the applications 111, 112,..., 119.

The resource 130 refers to a hardware entity having various functions, and the resource 130 may be represented as a hardware resource and a software resource. Hardware resources refer to tuners, demodulators, CAs, demultiplexers, decoders, memory, hard disks, and network adapters. In addition, a software resource may represent a plurality of hardware entities grouped and may be a resource defined on an operating system such as a process or a thread. Here, a thread is a unit of flow that runs within a process. Generally, a program has one thread, but depending on the program environment, more than one thread can run at the same time. That is, the program can be executed in a multithreaded manner. This multithreaded approach is a method of execution in which each thread shares and uses memory within a process, unlike processes that run independently and occupy separate memory.

In addition, the resource 130 is provided transparently to the application 110 so that the application 110 can be used irrespective of the internal implementation, and as described above, the middleware 120 may use the application 110 for this purpose. And mediate the resource (130). In addition, the resource 130 may be divided into a shared resource and a non-shared resource. Shared resources refer to resources that applications 111, 112, ..., 119 can share with each other, such as resources such as memory, threads, and network sessions. Non-shared resources are used by applications 111 as resources such as tuners. Refers to a resource that cannot be used by other applications 112,..., 119.

In order to use the resource 130, the Xlet application autonomously uses VM memory and threads. The protocol or management of these resources is entirely done in the middleware 120, and the application 110 operates without great consideration for the usage of its resources.

3 is a block diagram showing the configuration of a preferred embodiment of a broadcast receiver according to the present invention.

Referring to FIG. 3, the broadcast receiver 300 according to the present invention includes a tuner 311, a demodulator 312, a CA 313, a demultiplexer 314, a media decoder 315, and a user interface 321. , A storage medium 322, a network interface unit 323, and a processor 350. The tuner 311, the demodulator 312, the CA 313, the demultiplexer 314, the media decoder 315, the user interface 321, the storage medium 322, the network interface 323 and the processor. 350 is a component corresponding to the resource 130 of the broadcast receiver 100.

The tuner 311 receives broadcast data from at least one of the terrestrial wave, satellite, and cable, and outputs the broadcast data to the demodulator 312. That is, the tuner 311 tunes the frequency of a specific channel among the broadcast signals 301 input through any one of an antenna, a cable, and a satellite and outputs the tuner 312 to the demodulator 312. The tuner 311 may be provided for each broadcast source, for example, terrestrial wave, cable, and satellite, or may be an integrated tuner. In addition, when the tuner 311 is assumed to be a terrestrial broadcasting tuner, the tuner 311 may include at least one digital tuner and an analog tuner, or may be a digital / analog integrated tuner. When the terrestrial wave is an example, the tuner 311 tunes a terrestrial broadcast content transmitted through an antenna, that is, a broadcast signal of a channel selected by a user from among broadcast signals, and outputs the tuned signal to the demodulator 312.

The broadcast data received by the tuner 311 includes at least one of A / V data, MPEG section data, and application data. A / V data means audio data or video data. In addition, the MPEG section data is data including SI (System Information), EAS, and Application Information Table (AIT). In particular, an application information table (AIT) refers to a table including information on an application running in a receiver for data services, and in some cases, is also called XAIT and AMT. These AITs provide information about the application, such as the name of the application, the version of the application, the priority of the application, the ID of the application, the state of the application (auto-start, user operable, kill, etc.), and the type of application. (Java or HTML), the location of the stream containing the classes and data files of the application, the base directory of the application, the location of the icon of the application, and the like.

Application data refers to data containing the program code of the application (110). The processor 350 may determine a transmission mode based on an application information table (AIT) and control to download application data in the determined transmission mode. Herein, the transmission mode refers to a transmission method and a type of transmission medium for receiving broadcast data. The transmission method refers to the type of protocol used for each network layer, and DSM-CC User-to-User, Data and Object Carousel protocols, HTTP, TCP, UDP, IP, MPEG-2 Transport Stream, Ethernet protocol, etc. Can be used. In addition, the transmission method may be Broadcast Channel Protocols and Interaction Channel Protocols defined in the MHP standard.

Types of transmission media may include terrestrial, satellite, cable and Internet networks.

In addition, the transmission mode may include a transmission mode in which a transmission method and a transmission path vary depending on the type of broadcast data. That is, the broadcast receiver 300 may support a transmission mode in which A / V data is received through a cable and application data is received through an internet network.

In addition, the processor 350 may detect application information using an application information table (AIT). As a method of detecting application information using AIT, component_tag, original_network_id, transport_stream_id, and service_id may be detected. The component_tag refers to an elementary stream carrying DSI of the corresponding object carousel, and the original_network_id indicates a transport connection. Refers to the DVB-SI original_network_id of the providing TS. In addition, the transport_stream_id refers to the MPEG TS of the TS providing the transport connection, and the service_id refers to the DVB-SI of the service providing the transport connection. The original_network_id, transport_stream_id, and service_id may be used to obtain information on a specific channel.

The network interface unit 323 provides a return channel. The return channel here is a communication mechanism that provides a connection between the broadcast receiver 300 and the remote server. The remote server may be, for example, a server installed by a service provider to provide a broadcast service. Return channels include digital cable television (CATV) return channels, digital enhanced cordless telecommunications (DECT) return channels, public switched telephone network (PSTN) return channels, integrated services digital network (ISDN) return channels, and local multipoint distribution system (LMDS) returns. It may include at least one of a channel and a master-antenna television (MATV) return channel.

The broadcast receiver 300 may connect with a remote server through a return channel and transmit data to the remote server. In order to provide a return channel, the network interface unit 323 receives broadcast data through the Internet network and outputs the received broadcast data to the CA 313 or the communication control unit 388.

The demodulator 312 demodulates the signal output from the tuner 311 and outputs the demodulated signal to the CA 313. The CA 313 descrambles the signal output from the demodulator 312 or the signal output from the network interface 323, and outputs the descrambled signal to the demultiplexer 314. The demultiplexer 314 is a digital data stream, which is a signal output from the CA 313, for an application in the form of a data stream (for example, MPEG-2 format) representing audio and video and repeatedly broadcasted DSM-CC object carousel type. Demultiplex into data Here in another embodiment of a broadcast receiver capable of interfacing with non-broadcast delivery channels, the tuner 311 may be replaced with a network interface suitable for a non-broadcast delivery channel. The non-broadcast delivery channel may be an Internet Protocol (IP) based delivery channel.

The media decoder 315 decodes the audio stream and the video stream demultiplexed by the demultiplexer 314 into audio 302 and video 303 which can be displayed, respectively. To this end, the media decoder 315 may include an audio decoder and a video decoder. The video 303 displayed here may include an image output from the user interface 321.

Process 350 executes application 370 and middleware 380. The application 370 and the middleware 380 are components corresponding to the application 110 and the middleware 120 of the broadcast receiver 100, respectively.

The middleware 380 includes a tuner 311, a demodulator 312, a CA 313, a demultiplexer 314, a media decoder 315, a user interface 321, a storage medium 322, and a network interface unit ( 323 is controlled or managed and assigned to the application 370. To this end, the middleware 380 includes a tuner controller 381, a CA controller 382, an MPEG-2 SECTION FILTER 383, a service information processor 384, a DSM-CC 385, a media controller 386, and a storage controller. 387 and a communication control unit 388 are provided.

The tuner controller 381 controls the tuner 811 to allocate the tuner 811 to the application 370 or to change the tuning frequency of the tuner 811 according to a command of the application 370. The CA controller 382 controls the CA 312 so that the CA 312 descrambles the signal output from the demodulator 312.

The MPEG-2 SECTION FILTER 383 extracts information for displaying a video by filtering a data stream related to the video demultiplexed by the demultiplexer 314, and the service information processor 384 demultiplexes 314. Service information is extracted and processed from the demultiplexed data. That is, the MPEG-2 SECTION FILTER 383 extracts MPEG section data from the received broadcast data. In particular, the MPEG-2 SECTION FILTER 383 may extract host access guide information, which is guide information on a transmission mode, from the received broadcast data. In this case, the host access guide information may be included in the AIT and transmitted. In such a case, the MPEG-2 SECTION FILTER 383 may extract host access guide information by extracting AIT from broadcast data.

The DSM-CC 385 parses application data demultiplexed by the demultiplexer 314 to extract application program and application information, and stores the extracted information in the storage medium 322. The application program stored in storage medium 322 is executed in process 350.

The media controller 386 controls the media decoder 315 to display the audio 302 and video 303. In addition, the media controller retrieves the host access guide information extracted by the MPEG-2 SECTION FILTER 383 associated with the data access information stored in the storage medium 322, and broadcasts the broadcast data in a transmission mode indicated by the retrieved host access guide information. The tuner 311 or the network interface unit 323 may be controlled to receive. Here, the media control unit 386 controls the network interface unit 323 to control the network interface unit 323 instead of directly controlling the network interface unit 323, so that the host access guide information retrieved by the network interface unit 323 is stored. The broadcast data may be received in the indicated transmission mode.

The storage control unit 387 stores the audio stream, the video stream, the application program, the application information, and the service information in the storage medium 322, and the audio stream, the video stream, the application program, the application information, and the service information stored in the storage medium 322. Control access to The storage medium 322 may be any one of a RAM memory, a FLASH memory, and an HDD, or may include a RAM memory, a FLASH memory, and an HDD. The HDD may be an internal HDD or an external HDD.

The communication control unit 388 supports the application 370 to enable network communication, and controls the network interface unit 323 for this purpose. In addition, the communication control unit 388 controls the network interface unit 323 to receive broadcast data. The communication control unit 388 may provide application to the storage control unit 387 to extract application data from the broadcast data received by the network interface unit 323 and store it in the storage medium. The broadcast data received by the network interface unit 323 may be provided. The A / V data may be controlled to be output to the CA 313.

The communication controller 388 manages a return channel provided by the network interface unit 370. When the application 370 requests the use of the return channel, the communication control unit 388 provides a return channel interface to the application 370. When the application 370 requests the return channel state information, the communication control unit 388 provides the return channel state information. Here, the return channel state information refers to information about the state of the return channel. The return channel may be one of a normal operation state in which a return channel is connected to allow normal communication, and an abnormal state in which normal communication is not possible because of the return channel not connected.

In addition, the communication controller 388 may monitor whether the return channel is changed or not and provide return channel state information to the application 370 when the return channel is changed. The application 370 may need to perform a separate request procedure to the communication controller 388 to receive the return channel state information when the return channel state changes. That is, the communication controller 388 may provide return channel state information when the state of the return channel is changed depending on whether the request procedure of the application 370 is performed.

The application 370 is an example for receiving return channel state information when a state of a return channel is changed, and generates a return channel interface listener instance that receives the return channel state information, and registers the generated return channel interface listener instance. Here, the return channel interface listener instance may be registered through a method provided by the return channel interface implementation instance. The application 370 needs to obtain a return channel interface implementation instance that manages the interface of the return channel in order to register the return channel interface listener instance.

The communication control unit 388 generates a return channel interface implementation instance, and when the application 370 requests the return channel interface implementation instance, it provides the corresponding return channel interface implementation instance to the application 370. In addition, when the state of the return channel is changed, the communication control unit 388 may generate an event instance indicating the return channel state information, and transfer the generated event instance to the return channel interface listener instance registered by the application 370.

The process 380 may be implemented as a single process or a multi-process, and may include a tuner control unit 381, a CA control unit 382, an MPEG-2 SECTION FILTER 383, a service information processing unit 384, and a DSM of the middleware 380. The CC 385, the media controller 386, the storage controller 387, and the communication controller 388 may be made of hardware or firmware, respectively. In this case, the middleware 380 is a tuner control unit 381, CA control unit 382, MPEG-2 SECTION FILTER 383, service information processing unit 384, DSM-CC 385, the media control unit 386, the storage control unit 387, and the communication control unit 388 are used to mediate.

4 is a diagram illustrating a return channel interface implementation class and a return channel interface listener class according to the present invention.

Referring to FIG. 4, the return channel interface implementation (RCInterfaceImpl) class may be implemented by adding a function of monitoring the status of the return channel to a class that models the network interface of the return channel. Here, the class modeling the network interface of the return channel may be RCInterface included in the org.dvb.net.rc package. The org.dvb.net.rc package contains Java API related to session management for bidirectional IP connection proposed in DVB specification. In addition, the interface for monitoring the status of the return channel may be referred to as a return channel status monitor (RCStatusMonitor). That is, RCInterfaceImpl may be implemented by adding an RCStatusMonitor implementation to the RCInterface implementation. The application can use the return channel using RCInterfaceImpl, and create a return channel interface listener (RCInterfaceListener) and register the created RCInterfaceListener using the method provided by RCInterfaceImpl.

5 is a diagram illustrating a preferred example of the API specification of the RCStatusMonitor and RCInterfaceListener according to the present invention.

Referring to FIG. 5, the RCStatusMonitor is defined as a public interface type, includes CONNECTED and DISCONNECTED attributes, and includes getStatus (), addRCInterfaceListener (RCInterfaceListener listener), and removeRCInterfaceListener (RCInterfaceListener listener).

The CONNECTED attribute indicates the normal operation state in which the return channel is connected and in a normal communication state. It is defined as a public static final int type and is assigned a value of '0'.

The DISCONNECTED attribute indicates an abnormal state in which normal communication is not possible because the return channel is not connected. It is defined as a public static final int type and is assigned a value of '1'.

The getStatus () method is an API that reports the current status of the return channel. It is defined as a public int type and returns one of the following values: CONNECTED or DISCONNECTED.

The addRCInterfaceListener (RCInterfaceListener listener) method is an API used to dynamically know that the return channel status changes. It is defined as a public void type and has an RCInterfaceListener object as a parameter. Here RCInterfaceListener can be implemented in the application. The addRCInterfaceListener (RCInterfaceListener listener) method registers an RCInterfaceListener instance passed as a parameter.

An application can create an RCInterfaceListener instance and register it with the addRCInterfaceListener (RCInterfaceListener listener) method. For example, an application can register RCInterfaceListener1 by creating an RCInterfaceListener instance RCInterfaceListener1 and running RCStatusMonitor.addRCInterfaceListener (addRCInterfaceListener1).

The removeRCInterfaceListener (RCInterfaceListener listener) method is an API used to remove a registered RCInterfaceListener. It is defined as a public void type and has an RCInterfaceListener object as a parameter. If the RCInterfaceListener instance passed as a parameter here is not registered or is invalid, it will be ignored.

An application can remove a registered RCInterfaceListener instance using the removeRCInterfaceListener (RCInterfaceListener listener) method. For example, an application can remove a registered RCInterfaceListener1 by executing RCStatusMonitor.removeRCInterfaceListener (addRCInterfaceListener1).

RCInterfaceListener is defined as a public interface type and contains the receiveRCEvent (RCEvent event) method. RCInterfaceListener is used to know the status of return channel dynamically. RCInterfaceListener must be implemented where you want to know the dynamic state of the return channel.

The receiveRCEvent (RCEvent event) method sends an event when the return channel status changes. It is defined as a public void type and has an RCEvent object as a parameter. Here, the RCEvent object may be one of RCConnectedEvent and RCDisconnectedEvent.

FIG. 6 is a diagram illustrating a preferred example of an API specification of RCEvent, RCConnectedEvent, and RCDisconnectedEvent according to the present invention.

Referring to FIG. 6, RCEvent indicates return channel state information and occurs when a return channel state is dynamically changed. RCEvent is defined as a public class type, inherits from java.util.EventObject, and contains the RCEvent (java.lang.Obeject source) constructor. RCEvent is used by RCInterfaceListener.

When the state of the return channel changes dynamically, middleware can create an RCEvent instance and pass the generated RCEvent to the application that registered the RCInterfaceListener instance using the RCInterfaceListener.receiveRCEvent (RCEvent event) method.

RCConnectedEvent is raised when the return channel changes from abnormal state to normal operation. RCConnectedEvent is defined as a public class type and inherits RCEvent and includes the RCConnectedEvent (java.lang.Obeject source) constructor.

The RCConnectedEvent (java.lang.Obeject source) constructor includes source as a parameter. Where source is the RCInterface object on which the event occurred.

RCDisconnectedEvent occurs when the return channel changes from normal operation to abnormal status. RCDisconnectedEvent is defined as a public class type and inherits RCEvent and includes the constructor RCDisconnectedEvent (java.lang.Obeject source).

The constructor RCDisconnectedEvent (java.lang.Obeject source) includes source as a parameter. Where source is the RCInterface object on which the event occurred.

If the RCConnectedEvent is delivered through the registered RCInterfaceListener, the application can see that the return channel has changed from an abnormal state to a normal operation state. In addition, when RCDisconnectedEvent is delivered through registered RCInterfaceListener, the application can know that the return channel has changed from the normal operation state to the abnormal state.

7 is a diagram showing another preferred embodiment of the API specification of RCEvent according to the present invention.

Referring to FIG. 7, RCEvent indicates return channel state information and occurs when a return channel state is dynamically changed. RCEvent is defined as a public class type, inherits from java.util.EventObject, and includes the RCEvent (java.lang.Obeject source, int status) constructor and the getStatus () method.

The constructor of RCEvent (java.lang.Obeject source, int status) includes source and status as parameters. source is the RCInterface object where the event occurred, and status is RCStatusMonitor.CONNECTED if the return channel is in normal operation, and RCStatusMonitor.DISCONNECTED if the return channel is abnormal.

The getStatus () method provides the status parameter of RCEvent (java.lang.Obeject source, int status) constructor.

When the status of the return channel changes dynamically, middleware can create an RCEvent instance and pass the created RCEvent to the application that registered the RCInterfaceListener instance using the RCInterfaceListener.receiveRCEvent (RCEvent event) method. Here, if the return channel status changes from abnormal status to normal operation status, middleware executes RCEvent (RCInterface, RCStatusMonitor.CONNECTED) to generate RCEvent, and if the return channel status changes from normal operation status to abnormal status The middleware can generate RCEvents by executing RCEvent (RCInterface, RCStatusMonitor.DISCONNECTED).

8 is a sequence diagram of a preferred embodiment of a channel state monitoring method according to the present invention.

Referring to FIG. 8, the application 810 executes getInterface () or getInterfaces () to obtain a reference of the RCInterfaceImpl instance 830 from the RCInterfaceManager 820 (S800). RCInterfaceManager 820 is a class defined in org.dvb.net.rc and is a manager for all return channels in the broadcast receiver. A reference of one RCInterfaceImpl instance 830 may be obtained through getInterface (), and references of a plurality of RCInterfaceImpl instance 830 may be obtained through getInterfaces (). In addition, the RCInterfaceManager 820 may be a component included in or correspond to the communication control unit 388 of FIG. 3.

The application 810 executes RCInterfaceImpl.getStatus () to obtain return channel status information of the corresponding return channel (S802).

The application 810 creates an RCInterfaceListenerImpl instance 850 (S804). The application 810 registers an RCInterfaceListenerImpl instance 850 generated by executing RCInterfaceImpl.addRCInterfaceListener (RCInterfaceListener) (S806).

If the network interface unit 840 is connected to detect that the return channel state is changed from an abnormal state to a normal operation state, the RCInterfaceImpl instance 830 generates an RCConnectedEvent as an event instance indicating the return channel state information. (S808). Here, the RCInterfaceImpl instance 830 may generate RCEvent (RCInterface, RCStatusMonitor.CONNECTED) instead of RCConnectedEvent.

The RCInterfaceImpl instance 830 executes RCInterfaceListenerImpl.receiveRCEvent (RCEvent) and delivers the generated event instance to the RCInterfaceListenerImpl instance 850 (S810).

If the network interface unit 840 is disconnected, and it is detected that the return channel state is changed from the normal operation state to the abnormal state, the RCInterfaceImpl instance 830 generates an RCDisconnectedEvent as an event instance indicating the return channel state information. (S812). Here, the RCInterfaceImpl instance 830 may generate RCEvent (RCInterface, RCStatusMonitor.DISCONNECTED) instead of RCConnectedEvent.

The RCInterfaceListenerImpl instance 850 delivers the generated event instance to the RCInterfaceListenerImpl instance 850 by executing RCInterfaceListenerImpl.receiveRCEvent (RCEvent) (S814).

The application 810 removes the registered RCInterfaceListenerImpl instance 850 by executing RCInterfaceImpl.RemoveRCInterfaceLinsener (RCInterfaceListener) (S816).

9 is a block diagram of a preferred embodiment of a channel state monitoring method according to the present invention.

Referring to FIG. 9, the application 910 includes an RCInterfaceListenerImpl instance 912. Here, the application 910 is a component corresponding to the application 370 of FIG. 3. The application 910 may generate and include the required RCInterfaceListenerImpl instance 912 according to the number of return channels.

The application 910 may execute getInterface () and getInterfaces () to obtain a reference of the RCInterfaceImpl instance 927 from the RCInterfaceManager 925. In addition, the application 910 may register the RCInterfaceListenerImpl instance 912 using RCInterfaceImpl.addRCInterfaceListener (RCInterfaceListener). The registered RCInterfaceListenerImpl instance 912 may receive an RCConnectedEvent instance and an RCDisconnectedEvent instance. If an RCConnectedEvent instance is dispatched, it can be seen that the status of the return channel has changed from an abnormal state to a normal operation state. If an RCDisconnectedEvent instance has been passed, it can be seen that the status of the return channel has changed from a normal operation state to an abnormal state. have.

The application 910 may remove the registered RCInterfaceListenerImpl instance using RCInterfaceImpl.RemoveRCInterfaceListener (RCInterfaceListener).

The middleware 920 also includes an RCInterfaceManager 925. RCInterfaceManager 925 also includes an RCInterfaceImpl instance 927. Here, the RCInterfaceManager 925 may generate and include an RCInterfaceImpl instance 927 according to the number of return channels.

The RCInterfaceImpl instance 927 monitors whether the state of the return channel changes, creates an RCConnectedEvent instance when the state of the return channel changes from an abnormal state to a normal state, and changes the state of the return channel from the normal state to an abnormal state. In this case, create an RCDisconnectedEvent instance.

The network interface unit 930 provides a return channel and provides the RCInterfaceImpl instance 927 with the connected and disconnected states of the network cable.

FIG. 10 is a flowchart illustrating a preferred embodiment of a channel state monitoring method according to the present invention.

Referring to FIG. 10, the application 370 obtains a return channel interface implementation instance (S1000). Here, the return interface implementation instance manages the interface of the return channel and may be implemented by adding a function for monitoring the status of the return channel to a class that models the network interface of the return channel. In addition, the return channel interface implementation instance may be generated by the middleware 380.

The application 370 requests return channel state information to obtain return channel state information (S1010). Here, the application 370 may acquire return channel state information by using the obtained method of the return channel interface implementation instance. For example, RCSstatusMonitor.getStatus () shown in FIG. 5 may be used to obtain return channel status information.

The application 370 generates a return channel interface listener instance for receiving the return channel state information, which is information about the return channel state (S1020).

The application 370 registers the generated return channel interface listener instance (S1030). Here, the application 370 may register a return channel interface listener instance using a method provided by the return channel interface implementation instance. For example, the RCStatusMonitor.addRCInterfaceListener (RCInterfaceListener listener) shown in FIG. 5 may be used to register a return channel interface listener instance.

The middleware 380 monitors whether the state of the return channel changes (S1040). The middleware 380 may monitor at least one return channel. The middleware 380 checks whether the state of the return channel has changed (S1050).

When the state of the return channel is changed, the middleware 380 generates an event instance indicating the return channel state information, and transfers the generated event instance to the return channel interface listener instance registered by the application 380 (S1060). Here, the event instance indicating the return channel state information may be either one of the RCConnectedEvent instance and the RCDisconnectedEvent shown in FIG. 6 or the RCEvent shown in FIG. 7.

If the network interface unit 323 is connected, and it is detected that the state of the return channel is changed from the abnormal state to the normal operation state, the middleware 380 generates an RCConnectedEvent as an event instance indicating the return channel state information. Here, the middleware 380 may generate RCEvent (RCInterface, RCStatusMonitor.CONNECTED) instead of RCConnectedEvent.

If the network interface unit 323 is disconnected and it is detected that the return channel state is changed from the normal operation state to the abnormal state, the middleware 380 generates an RCDisconnectedEvent as an event instance indicating the return channel state information. . Here, the middleware 380 may generate RCEvent (RCInterface, RCStatusMonitor.DISCONNECTED) instead of RCConnectedEvent.

The middleware 380 delivers the generated event instance to the registered return channel interface listener instance (S1070). Here, the middleware 380 may deliver the event instance to the corresponding return channel interface listener instance using the method of the return channel interface listener instance. For example, the event instance can be delivered to the corresponding return channel interface listener instance using the RCInterfaceListener.receiveRCEvent method shown in FIG. 5. The application 370 may determine the state of the corresponding return channel through the event instance delivered to the return channel interface listener instance.

The invention can also be embodied as computer readable code on a computer readable recording medium. The computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer device is stored. Examples of the computer-readable recording medium include a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like, and may be implemented in the form of a carrier wave (for example, transmission via the Internet) . The computer-readable recording medium may also be distributed to networked computer devices so that computer readable code can be stored and executed in a distributed manner.

Although the preferred embodiments of the present invention have been shown and described above, the present invention is not limited to the specific preferred embodiments described above, and the present invention belongs to the present invention without departing from the gist of the present invention as claimed in the claims. Various modifications can be made by those skilled in the art, and such changes are within the scope of the claims.

1 is a structural diagram showing a configuration of a preferred embodiment of a hierarchical structure of a broadcast receiver;

2 is a conceptual diagram illustrating an example of a life cycle of an application;

3 is a block diagram showing the configuration of a preferred embodiment of a broadcast receiver according to the present invention;

4 shows a diagram of a return channel interface implementation class and a return channel interface listener class in accordance with the present invention;

5 is a view showing a preferred embodiment of the API specification of RCStatusMonitor and RCInterfaceListener in accordance with the present invention,

6 is a diagram showing a preferred embodiment of the API specification of RCEvent, RCConnectedEvent and RCDisconnectedEvent according to the present invention,

7 is a view showing another preferred embodiment of the API specification of RCEvent according to the present invention;

8 is a sequence diagram of a preferred embodiment of a channel state monitoring method according to the present invention;

9 illustrates a block diagram of a preferred embodiment of a channel state monitoring method in accordance with the present invention; and

FIG. 10 is a flowchart illustrating a preferred embodiment of a channel state monitoring method according to the present invention.

Claims (15)

Generating a return channel interface listener instance for receiving return channel state information which is information on the state of the return channel, and registering the generated return channel interface listener instance; Monitoring whether the return channel has changed state; And When the state of the return channel is changed, generating an event instance informing of the return channel state information and transferring the generated event instance to the registered return channel interface listener instance; How to monitor return channel status. The method of claim 1, The return channel may be a digital cable television (CATV) return channel, a digital enhanced cordless telecommunications (DECT) return channel, a public switched telephone network (PSTN) return channel, an integrated services digital network (ISDN) return channel, a local multipoint distribution system (LMDS). And at least one of a return channel and a master-antenna television (MATV) return channel. The method of claim 1, And a state of the return channel is one of a normal operation state and an abnormal state. The method of claim 1, Requesting the return channel state information. The method of claim 1, Obtaining a return channel interface implementation instance managing the interface of the return channel. The method of claim 5, In the step of registering, And returning the return channel interface listener instance using a method provided by the return channel interface implementation instance. The method of claim 5, The return channel interface implementation instance is implemented by adding a function of monitoring the status of the return channel to a class modeling the network interface of the return channel. The method of claim 7, wherein And the class is org.dvb.net.rc.RCInterface. A network interface unit providing a return channel; And Create and register a return channel interface listener instance that receives return channel status information, which is information about the status of the return channel, monitor whether the return channel is changed, and if the return channel status is changed, return And a controller configured to generate an event instance informing channel state information, and to deliver the generated event instance to the registered return channel interface listener instance. The method of claim 9, The return channel may be a digital cable television (CATV) return channel, a digital enhanced cordless telecommunications (DECT) return channel, a public switched telephone network (PSTN) return channel, an integrated services digital network (ISDN) return channel, a local multipoint distribution system (LMDS). And at least one of a return channel and a master-antenna television (MATV) return channel. The method of claim 9, And a status of the return channel is one of a normal state and an abnormal state. The method of claim 9, The control unit, And a return channel interface implementation instance for managing the interface of the return channel. The method of claim 12, The control unit, And registering the return channel interface listener instance using a method provided by the return channel interface implementation instance. The method of claim 12, The return channel interface implementation instance is implemented by adding a function for monitoring the status of the return channel to a class modeling the network interface of the return channel. 15. The method of claim 14, And the class is org.dvb.net.rc.RCInterface.

Images