Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
  • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/465—Distributed object oriented systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/54—Interprogram communication
  • G06F9/546—Message passing systems or structures, e.g. queues
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/54—Interprogram communication
  • G06F9/547—Remote procedure calls [RPC]; Web services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
  • H04N21/23109—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion by placing content in organized collections, e.g. EPG data repository
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/241—Operating system [OS] processes, e.g. server setup
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2209/00—Indexing scheme relating to G06F9/00
  • G06F2209/46—Indexing scheme relating to G06F9/46
  • G06F2209/462—Lookup
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2209/00—Indexing scheme relating to G06F9/00
  • G06F2209/46—Indexing scheme relating to G06F9/46
  • G06F2209/463—Naming

Definitions

• the invention relates to administration of distributed data systems, specifically headend systems of a cable television network. Background of the invention
• Cable television networks may be implemented by various techniques and network topologies, currently mostly as so-called HFC networks (Hybrid Fiber Coax), i.e. as combinations of a fibre network and a coaxial cable network, but when considering future network solutions the cable television operators must also take into account the rapid development of IP-based (Internet Protocol) networks and services, for example the so-called IP television.
• HFC networks Hybrid Fiber Coax
• IP-based networks and services for example the so-called IP television.
• IP-based (Internet Protocol) networks and services for example the so-called IP television.
• IP-based Internet Protocol
• the function of the headend is to receive program services from different sources, if necessary to convert them into a format suitable for the distribution network, and to adapt them to be transmitted typically in multiplexed channel bundles.
• the headend of a digital cable television networks must advantageously be able to receive program services in a digital satellite (DVB-S), terrestrial (DVB-T), cable (DVB-C) and asynchronic (DVB-ASI) format. Further, it must be able to receive analog program services, which must be converted into digital form by means of a suitable encoder. Further, one or more Video-On-Demand servers (VOD) may operate as a program source. All these program sources must therefore be able to be adapted in the headend system to a format suitable for the distribution network, typically either the DVB-C or DVB-ASI format.
• VOD Video-On-Demand servers
• the headend systems are typically complex, large systems composed of several separate devices, and their administration and usage is laborious and requires versatile skills from those performing those tasks.
• the operating system software of some devices is updated often, while devices with older technology may not necessarily be updated at all any longer.
• middleware is to hide the different user interfaces and usages of the devices behind a common administration interface and to aim to provide the user with a view of the entire system level. Middleware are expensive investments because of large amounts of development work and costs for continuous maintenance.
• the invention is based on the idea that in a distributed data system, such as a headend system of a cable television network, which comprises several data processors connected to each other via a communication bus, which data processors comprise at least one application, which applications are arranged to communication with each other, the variables of said applications are defined as data elements, which data element is a key/value -pair, where the key defines the location of the data element in the communication system and the value defines the current value of the data element; a specific keyscope is registered for each said application, which defines the initial part of said key, and a channel address of the application, which defines the location of the application in the communication bus so that the channel address can be resolved on the basis of said keyscope; at least one data element in a second application is called from a first application on the basis of at least one key of the data element; and the call is directed in the communication bus to said second application on the basis of the key of the data element and the channel address of the application.
• a distributed data system such as a headend system of a cable
• the invention describes a uniform communication method between applications, where changes in the communication interface or message structure of an individual application do not cause a change in the communication mechanism itself and therefore do not automatically require changing and updating client applications.
• the applications communicate by sending and receiving data elements (key/value-pairs), which are relayed between the communicating applications without the applications in question knowing each other in depth.
• an address of an application is received as a response to the application initializing a communication channel in a communication bus; and a specific keyscope and application channel address in a keyscope register are registered for said application.
• a get operation is determined for said calls, with which the application making the call requests the receiving application to send as a response the current value of at least one data element defined in the call; and a set operation, with which the application making the call notifies the receiving application a new value for the at least one data element defined in the call.
• the key/value-pair of the data element is a character string of an unlimited length, and the value is one of the following allowed data types: signed/unsigned 32/64-bit integral number, floating point number, ASCIIZ character string, or a byte string without a data type.
• the services offered by said data processors is notified to a distributed administration server by means of service notification messages; the device keyscope and a corresponding channel address notified in the service notification message is stored in a device keyscope register covering the system; and the services provided by a specific data processor are notified by means of service notification messages to the other data processors of the system from the distributed administration server.
• the device keyscope and the corresponding channel address notified in the service notification message are stored for a predetermined time in the device keyscope register covering the system; and as a response the not receiving a new service notification message within said predetermined time, said device keyscope is removed from said device keyscope register.
• the call is directed to a device-specific relay mechanism; a search in a data specific table of the keyscope register is performed on the basis of said key of the data element; as a response to not finding said data element key from the device-specific table of the keyscope register, a search is performed in the device keyscope register covering the system on the basis of said data element key; as a response to finding said data element key in the device keyscope register covering the system, a device keyscope corresponding to said second application and the channel address of the device are sent to the device-specific relay mechanism; and the call is directed from the device-specific relay mechanism in the communication bus to said device comprising the second application on the basis of said device keyscope and the channel address of the device.
• Fig. 1 shows in a reduced block chart an example of an integrated headed device, where the communication procedure according to the invention can be applied;
• Fig. 2 shows in a reduced view the basic functionality of the communication mechanism according to the invention
• Fig. 3 shows in a reduced view the registration according to an embodiment of a keyscope of the application in a key register
• Fig. 4 shows in a reduced view the establishment according to an embodiment of a value of a data element published by the application on the basis of a key
• Fig. 5 shows in a reduced view a distributed system according to an embodiment, which system is composed of several devices connected to each other via a data communication network;
• Fig. 6 shows in a reduced view a procedure according to an embodiment for notifying the services provided by a device to other device of the system.
• Fig. 7 shows in a reduced view a procedure according to an embodiment for communication between applications, when the applications are located in different devices. Detailed description of the invention
• Figure 1 shows by a reduced block chart an example of an integrated headend apparatus, where the communication procedure according to the invention may advantageously be applied.
• the purpose of figure 1 is to illustrate the operation of a headend apparatus on a general level by using some most typical modules as examples, and therefore figure 1 does not show all the functional blocks that are adaptable to a headend apparatus.
• the headend apparatus according to an aspect of the invention is shown physically integrated to the same apparatus assembly, for example a case. Even though this kind of physical integration is an advantageous embodiment, which facilitates the concrete administration and maintenance of the apparatus, it is not essential to the functionality of the invention.
• the invention can similarly be implemented by using one or more modules outside the apparatus case, which modules are, however, functionally connected in a manner required by the invention.
• the headend apparatus according to figure 1 can on a general level be understood as a distributed system, whose separate modules are managed through a common communication mechanism.
• the integrated headend apparatus 100 according to figure 1 comprises a main module 102 and at least one, but advantageously several, for example 4 to 8, interface modules 104. Each of such modules can be interpreted to correspond to a separate device according to prior art, as a part of the headend system.
• the headend apparatus 100 according to figure 1 comprises a power source module 106 and at least one, typically several fan modules 108.
• the main module 102 is responsible for the administration and synchronization of the headend apparatus and all the modules connected to it.
• the main module 102 comprises a central processing unit (CPU), memory (MEM) and interfaces to other modules and the user interface (Ul) 110 of the apparatus.
• the main module administrates all the data transfer taking place in the headend apparatus, comprising both the administration of incoming/outgoing program service streams of interface modules 104 and the processing of the internal control data of the apparatus.
• the main module also controls the power input from the power source module 106 to other modules.
• the main module advantageously comprises an internal Ethernet switch 112, which enables the processing of program service streams on IP level and sending and receiving program service streams as IP-based, either as Single Program Transport Stream (SPTS) or as Multi Program Transport Stream (MPTS) in an Ethernet network, in which an Ethernet interface module 114 is used for sending and receiving program service streams.
• SPTS Single Program Transport Stream
• MPTS Multi Program Transport Stream
• the operating system controlling the main module and the operation of the entire apparatus is stored in the memory (MEM).
• the memory (MEM) comprises a read memory portion, which can be for example a ROM memory and a random access memory which can be composed of a RAM memory and/or a FLASH memory.
• the information obtained from the different modules of the apparatus is relayed via the memory to the central processing unit (CPU), which comprises one or more processors and which processes the obtained information in a manner controlled by the operating system.
• CPU central processing unit
• the interface modules 104 are connected to the main module 102 for the part of their program service stream on the IP interface of the link layer plane of the Ethernet, which IP interface has its own IP address and a network mask configured via the user interface.
• the IP packets can be relayed as such to other interface modules.
• the basic functionality comprises advantageously at least an operating system, common program functions for all modules, a uniform administration of data positions and a universal communication mechanism.
• FIG 2 the basic functionality is implemented as an integrated core program (CORE), which can be taken into use in products connected to the system.
• the core program is delivered in a separate software packet in binary form, which packet can be adapted to operate in different HW environments.
• Figure 2 shows, as an example, several applications (APPLICATION (1), (2), ..., (n); 202, 204, 206), which can be used in one or more separate devices or modules belonging to a headend apparatus. For each application has been adapted a separate core software unit (CORE (1), (2) (n);
• the core software packet CORE offers to the application software of the product several services of general use, which are characteristic to all the products of the system.
• the communication mechanism of general use which can also be called DXI (Data Exchange Interface) in short, is designed to avoid the drawbacks of conventional IPC- techniques (InterProcess Communication).
• IPC techniques can be divided into two basic types: 1) communication between two points (P2P, point-to-point) by using application-specific function interfaces that are determined separately for each functionality; and 2) bus-type message relay mechanism with application-specific message structures.
• P2P point-to-point
• bus-type message relay mechanism with application-specific message structures.
• the weakness of these techniques is the application-specific individuality of the function interfaces and message structures, as well as the loss of compatibility caused by even a small change, which leads to the mutual captivity and version dependence of communicating applications.
• each application must know specifically from which application each service can be obtained.
• DXI communication method
• a uniform communication between applications is provided, where changes in the communication interface or message structure of an individual application do not cause a change in the communication mechanism itself and therefore do not automatically require changing and updating client applications.
• the applications communicate by sending and receiving data elements (key/value-pairs), which are relayed between the communicating applications without the applications in question knowing each other in depth. This is described more in detail by examples later.
• the direct access of the application (APPLICATION) to the original data position of the data element (DATA) is enabled.
• This method enables a fast data transmission and the multiformity of the data type does not limit data transfer at all. This is also described more in detail by examples later.
• the communication method (DXI) it is possible to implement a distributed application environment, where information on the services provided by the device is communicated to the other devices of the network, and information on the services provided by the other devices of the networks is received.
• the received service information is provided to the communication mechanism (DXI), which, if necessary, directs traffic over the network without the communicating applications having to separately prepare for the situation.
• From object-oriented software architectures are known, inter alia, get and set operations, by means of which objects and their values are set to a variable.
• the communication mechanism defines the get and set operations so that the application sending with the get operation (making the call) requests the receiver to send as a response the current values of the data elements defined as parameters.
• the sending application the one making the call
• the sending application notifies the receiver of the new values for the defined data elements as parameters of the call.
• the receiving application performs the procedures needed for changing the values of the data elements in question.
• an unlimited number of data elements can be as parameters of both the get and set operations.
• a data element is a key/value pair, where the key is a character string of an unlimited length, and the value is one of the allowed data types: signed/unsigned 32/64-bit integral number, floating point number, ASCIIZ character string, or an unlimited byte string (without a data type) divided into dimensioned bytes.
• the receiving application can possibly be prepared, for example, for the application processing the data element in question being loaded and not necessarily reacting to calls as fast as when unloaded.
• the identifier of the operation, as well as its parameters are advantageously encoded into such form that may be transferred by using a DXIJransport transfer mechanism.
• the applications do not need to be aware of the location of the data elements; it is sufficient that they know the key of the data element in question.
• the initial part of the key indicates the keyscope.
• Each application has an individual keyscope, which they register to a keyscope registry. This embodiment is illustrated in the example according to figure 3.
• the application 300 whose keyscope is "sensors”, publishes two data elements, whose keys are "temp.mbi” and "fan.rpm.1".
• the application initializes (init(); 302) the DXI_transport communication channel 304, so that other applications will be able to communicate with it.
• the application 300 receives information on its key address (transport_addr), which it notifies (register_keyscope(); 308) to a keyscope register 310. At the same time the application registers its keyscope "sensors".
• the data element of the application can advantageously be manipulated from another application, if the other application only knows the key of the data element.
• the registration of data elements utilizes advantageously also other data on the "behaviour" of the data element.
• the previous example describes two sensors (“sensors”), the first of which measures temperature (“temp.mbi”) and the second the fan rotation speed (“fan.rpm.1”), which values therefore describe the values of corresponding data elements.
• the first sensor is registered in the key register expressly as a temperature sensor (temp) and the second sensor as the sensor for the speed of rotation of the fan (fan.rpm).
• the behaviour of this kind of values, such as temperature or the speed of rotation of a fan, in a known environment is very much predictable by a person skilled in the art, in which case it is possible to make strong assumptions on the current values of the data elements.
• the system most advantageously comprises the keyscope register 310 covering the entire system, which register is composed of several tables, to which at least the keyscopes, channel addresses and status data of the applications are stored.
• the tables of the keyscope register can advantageously be grouped device-specifically, in which case the data elements of the applications of one device are stored in the same table.
• searching for the value of a specific data element of some application if the application is known to be in a specific device, the search can be focused directly to the correct table.
• searching for an application which is by default located in a different device than the application performing the search, the search can be skipped in the table of the device in question.
• the keyscope register can also be implemented as several separate keyscope registers.
• Figure 4 illustrates an example of how another application can determine the value of a data element published by a first application on the basis of the key.
• the communication application clientApp; 400
• the communication application 400 does not know the application it needs to communicate with in order to receive the desired reply, and therefore it makes a call (get("sensors.temp.mb1"); 402) to the DXI relay mechanism 404 (DXI_broker).
• the DXI_broker 404 performs a search on the basis of the key (find_provider("sensors.temp.mb1"; 406) in the keyscope register 408, from where a keyscope "sensors" registered in the above- described manner is found.
• the keyscope register 408 returns as a reply to the query the correct keyscope and the channel address of the application (find_result("sensors", transport_addr; 410).
• the DXI_broker 404 may now perform the actual communication via the DXMransport channel to the application providing the data value in question.
• the DXI_broker 404 sends an operation call (op(get, transport_addr, "sensors.temp.mb1"); 412) to the DXMransport channel 414, which directs the call (getfsensors.temp.mbr); 416) on the basis of the channel address to the correct application 418, which also comprises the data element "temp.mbr.
• the DXI_broker 404 relays the correct keyscope ("sensors”) received from the keyscope register 408 and the channel address (transport_addr) of the application to the application (clientApp; 400) that made the call, which stores the location of the data element for example as a static variable, which after this always points directly to the data element in question.
• clientApp the application that made the call
• the keyscope and the channel address are not needed to be searched again, but the addressing takes place directly to the data element itself, which naturally optimizes the speed of the search.
• FIG. 1 shows an example of such a distributed system, which is composed of several devices connected to each other via a data communication network.
• the system of the example according to figure 5 is the administration application of some other system, where each device is responsible for a certain part of the operations of the system.
• the system comprises a monitoring device (monitor; 500), which monitors the state of the administrated system, a control device (control; 502), which controls the administrated system, a database (db; 504), to which the state history of the managed system is stored, and user interface devices (monitor_gui; 506; control_gui; 508), which offer user interfaces for monitoring and controlling the administrated system.
• the devices of the system are connected to each other by means of a communication channel (ethernet; 510).
• ethernet 510
• this kind of a system it is possible to advantageously apply the above-described communication mechanism (DXI) so that the parts of the system find each other in a self-educating manner. This is illustrated in a simplified manner by means of figure 6.
• the device keyscope of the device is "monitor_gui", which a distributed DXI server (Distributed DXI_server; 600) notifies to the network (announce("monitor_gui”); 602) for the information of other devices of the system.
• the DDXI_server 600 listens to the service notification messages of other devices, and when noticing one (listen("monitor”); 604) stores the service notification messages together with the channel address (register_global_keyscope("monitor", transport_addr; 606) required for DXI communication to the device keyscope register 608 covering the system.
• the procedure also comprises the expiry of the device keyscope, i.e. each service notification message is valid for only a specific time, and if no new service notification message is received within this time, the device keyscope in question is removed from the register.
• Figure 7 illustrates an example of how the communication between the applications takes place when the applications are located in different devices.
• Figure 7 shows two device assemblies, a user interface device (monitor_gui; 700) and a monitoring device (monitor; 702), as well as a communication channel (DXMransport; 704) as an interface between these.
• the application (“Ul_app”; 706) located in the user interface device 700 wants to know the value of the data element "monitor.sensors.temp.1", and therefore it makes a call (get("monitor.sensors.temp.1"); 708) to the DXI__broker mechanism 710.
• the DXI_broker 710 In order to determine the correct keyscope the DXI_broker 710 first performs a search on the basis of the key (find_provider("sensors.temp.mb1"; 712) to the device-specific table 714 of the keyscope register. Since no correspondence is found in the device-specific table 714 of the keyscope register, next a search (result(NO_MATCH); 716) in the device keyscope register 718 covering the entire system is made, where a device keyscope "monitor" registered in the above-described manner can be found. As a response to the query, the device keyscope register 718 returns the correct keyscope of the device and at least the channel address of the device (resultfmonitor", transport_addr; 720).
• the DXI_broker 710 sends an operation call (op(get, transport_addr, "sensors.temp.1”); 722) to the DXI transport channel 704, which directs the call (get("sensors.temp.mb1"); 724) on the basis of the channel address of the device first to the correct device ("monitor"; 702).
• the monitoring device 702 directs the call further to the application 726, whose keyscope is "sensors”, which also comprises the data element "temp.1".
• a requirement for the operation of the above-described mechanism is advantageously only that the service notification message sent by the monitoring device 702 must be registered in the device keyscope register of the user interface device 700. Therefore, the communicating applications do not advantageously need to be prepared for communication between devices in any way. Communication between applications is therefore performed in the same way irrespective of whether they are in the same device or in different devices.
• the entire system can be implemented by focusing expressly on the characteristics of the variables, because there is no need to pay attention to the data type itself, as the communication mechanism is designed to operate with any data type. This way it can further be ensured that the variable acts in the manner that is characteristic to it.
• the communication mechanism DXI itself can be implemented on the basis of IPC techniques known as such.
• the transfer of data elements can be implemented either as communication between two points (P2P) with its function call mechanisms or by using message relaying in bus-form.
• P2P points
• message relaying in bus-form the encoding/decoding of data elements is performed most advantageously in a manner characteristic to the selected IPC technique.
• P2P communication is a more natural selection for IPC technique.
• Some applicable communication mechanisms include CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) and Sun RPC (Remote Procedure Call), of which especially SunRPC is well suited to be used in Unix/Linux-based embedded systems.
• CORBA Common Object Request Broker Architecture
• DCOM Distributed Component Object Model
• Sun RPC Remote Procedure Call

Applications Claiming Priority (2)

Publications (2)

Family

ID=39149057

Family Applications (1)

Country Status (3)

Citations (1)

Family Cites Families (6)

• 2008
  • 2008-02-29 FI FI20085188A patent/FI20085188L/fi not_active Application Discontinuation
• 2009
  • 2009-02-13 WO PCT/FI2009/050117 patent/WO2009106681A1/en active Application Filing
  • 2009-02-13 EP EP09714746A patent/EP2250788A4/de not_active Withdrawn

Patent Citations (1)

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events