Abstract:
A method in a protocol adaptor system for enabling a newly connected device to communicate with a generic application in a communications network, where the generic application uses a generic protocol. The method includes detecting that the device is unsupported by a specific protocol and that the device uses a variant of the specific protocol in the system. The method further includes determining a new fragment required for communication adaptation of the specific protocol, and retrieving the new fragment needed for adaptation of the specific protocol to said variant. The method further includes installing the fragment in the specific protocol, to enable communication between the generic application and the newly connected device.

Description:
TECHNICAL FIELD 
       [0001]    The present disclosure relates generally to a method, system and a computer program for communication protocol adaptation and handling of devices connected to the system. 
       BACKGROUND 
       [0002]    The number of devices connected to various communications networks is increasing. In general, in homes or household environments, there are devices for media recording and media consumption, devices for controlling the home itself, like lights, temperature or surveillance, and a wide range of other types of devices. There are different user groups of specific devices such as: elderly people with needs for assistance alarms or hearing aids, remote located homes which are desired to be enabled for remote control of heating or door locks, to give a few examples. Another area of device usage is commercial buildings, where indoor as well as outdoor surveillance of environments may be desired, as well as automation and control of sensors and actuators. 
         [0003]    There are a number of different reasons for connection of electronic devices to networks, e.g. from a desire to connect electronic devices to communications networks for direct benefits like remote control of a media appliance, to, for example, energy saving by better control of energy usage or to use energy when it cheap. These growing trends of connection of devices to networks, are inviting an increasing number of suppliers of electronic devices. This leads to a variety for consumers and solution builders to choose from, but on the other hand it increases the technical complexity of systems. Each device supplier of each device may have its own version and unique benefit, which may attract the users of the devices. However, as of today it may require expert knowledge in networking to connect a new device for e.g. a home cinema or elderly emergency assistance. It may have serious consequences if a device is faulty connected. 
         [0004]    The variety of suppliers of different types of devices represents dimensions of complexity, seen from a technical aspect. Another dimension of complexity is the various protocols available for connection of devices. Some protocols are well established and have been used for some time, and some are new and maturing. Some of the protocols are rich and supports a broad range of applications like UPnP (Universal Plug and Play), where some protocols may just support basic on/off commands, like certain implementations of ZigBee (the wireless mesh network standard). Another issue is the underlying communication network and the protocols for that. Examples of today may be TCP/IP on Ethernet, TCP/IP on Wireless LAN, plain SMS (simple message service), as well as ZigBee or propriety protocols. Users of devices may not want to be locked into a specific supplier of devices, and neither be locked to specific technologies for connection of devices to communication networks. 
         [0005]    From a user perspective, the providers of devices may not be the most suitable provider of applications, the applications which are desired or necessary to operate or control the connected devices. Applications for operation of devices may well originate from a third party than a device manufacturer. An example is the home cinema, where the media player, is from one manufacturer, the display from another vendor, and the sound system from yet another vendor. Another example is a population of buildings, where the buildings may be built by different entrepreneurs, at different points in time, un-coordinated, all more or less automatized, and later in time connected to a common system for home automation. In the latter example, the common system would comprise a fragmented plethora of devices. 
         [0006]    There are a number of problems associated with connection of devices to networks. For example, how should a new device and a network recognize each other? How can an application developer detect and know which type of device that has been connected to a network, and adapt the application for that particular device? Application developers today need to create a specific communication protocol implementation for each specific device type and potentially version. Application development becomes complex, because it may be difficult for an application developer to keep track of all device manufacturers and their respective versions. Another aspect is that upgrades may need to be synchronized. And yet, may end users or consumers will be inclined to avoid the hassle of network configuration when connecting new devices? 
       SUMMARY 
       [0007]    It is an object of embodiments described herein to address at least some of the problems and issues outlined above. It is an object to address how to enable communication between generic applications and devices. Another object is to enable communication between a newly connected unknown device and a generic application. It is possible to achieve these objects and others by using a system, method and computer program as defined in the attached independent claims. 
         [0008]    According to one aspect, a method in a protocol adaptor system is provided for enabling a device to communicate with a generic application in a communications network where the generic application uses a generic protocol. The method comprises detecting that the device is unsupported by a specific protocol and that the device uses a variant of the specific protocol in the system. The method further comprises determining a new fragment required for communication adaptation of said specific protocol. The method further comprises retrieving the new fragment needed for adaptation of the specific protocol to said variant. The method further comprises installing the fragment in the specific protocol, thereby enabling said communication between the generic application and the newly connected device. 
         [0009]    An advantage with the method is that developers of generic applications are not required to adapt a generic application for a variety of devices, where each device may require its specific communication. 
         [0010]    According to another aspect, a protocol adaptor system is provided configured to enable a device to communicate with a generic application in a communications network where the generic application uses a generic protocol unit, wherein the generic protocol unit is arranged to detect that the new device is unsupported by a specific protocol unit and that that the device uses a variant of the specific protocol unit in the system. The system further comprises the generic protocol unit, arranged to determine a new fragment required for communication adaptation. The system further comprises the generic protocol unit arranged to retrieve the new fragment needed for adaptation of the specific protocol unit to said variant, from a protocol provider unit. The system further comprises the generic protocol unit, arranged to install the new fragment in the specific protocol unit ( 130 ), thereby enabling the communication between the generic application ( 150 ) and the newly connected device ( 140 ). 
         [0011]    An advantage with the protocol adaptor system is that when a new device is installed, the system may detect the new device and automatically retrieve and install a necessary fragment for enabling of communication with the newly installed device. Thereby users may avoid the hassle of and sometimes troublesome installation and configuration of technical equipment. 
         [0000]    According to another aspect, a computer program, comprising computer readable code means for enabling a device to communicate with a generic application in a communications network where the generic application uses a generic protocol, which when run by a protocol adaptor system causes the protocol adaptor system to perform detection that the device is unsupported by a specific protocol and that the device uses a variant of the specific protocol in the system. The computer program further comprises determining a new fragment required for communication adaptation of said specific protocol. The computer program further comprises retrieving the new fragment needed for adaptation of the specific protocol to said variant. Further comprising installing the fragment in the specific protocol, thereby enabling said communication between the generic application and the newly connected device. 
         [0012]    According to another aspect, a computer program product is provided. The computer program product comprising a computer readable medium and a computer program, wherein the computer program is stored on the computer readable medium. 
         [0013]    The above method, system and computer program may be configured and implemented according to different optional embodiments. In one possible embodiment the specific protocol unit is arranged to transmit a search request to, and receive a response from, the device. In another embodiment the generic protocol unit comprises a local schema unit which is arranged to determine, based on device information, the new fragment required to enable communication between the generic application and the device. In another embodiment the generic protocol unit is arranged to retrieve the determined fragment from the local schema unit to the specific protocol unit. In another embodiment the local schema unit at a failure of determination of a required new fragment is arranged to transmit a request to the protocol provider unit, wherein the request comprises device information. In another embodiment the protocol provider unit comprises a service schema unit which is arranged to receive a request comprising device information, and to determine which specific fragment that is required to enable communication between the generic application and the device, based on the device information. 
         [0014]    In another embodiment the service schema unit is arranged to retrieve the determined fragment from a fragment database. In another embodiment the protocol provider unit is arranged to deliver the requested new fragment to the local schema unit. In another embodiment a fragment generator unit is arranged to generate a fragment which associates the generated fragment with the device and stores the generated fragment in the fragment database. In another embodiment the local schema unit is arranged to pre-retrieve a fragment which is likely to be required for future new devices, wherein the protocol provider unit determines the fragments to pre-retrieve. 
         [0015]    Further possible features and benefits of this solution will become apparent from the detailed description below. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0016]    The solution will now be described in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which: 
           [0017]      FIG. 1  is a block diagram illustrating a protocol adaptor system, according to an exemplifying embodiment. 
           [0018]      FIG. 2   a  is a block diagram illustrating a protocol adaptor system, according to some possible embodiments. 
           [0019]      FIG. 2   b  is a block diagram illustrating an example of the generic protocol unit. 
           [0020]      FIG. 3  is a flow chart illustrating a procedure in a protocol adaptor system according to an exemplifying embodiment. 
           [0021]      FIG. 4  is a flow chart illustrating a procedure in a protocol adaptor system, according to further possible embodiments. 
           [0022]      FIG. 5  is block diagram illustrating a clustered protocol adaptor system. 
       
    
    
     DETAILED DESCRIPTION 
       [0023]    Briefly described, a system is provided for protocol adaptation. When a new device is connected to a network, it may require a specific protocol for communication. Typically a device may be intended for communication with, or controlled by an application. However, a specific application for each specific device is not desired. Hence should a generic application with certain benefits be able to communicate with devices comprising features supporting the benefits. A generic application may be a media player, a home automation application for controlling light heating/cooling etc, a surveillance application controlling motion detectors and cameras for alarm triggering etc, not limiting to other types of generic applications that may communicate with various devices. The herein described system adapts communication between a device with specific protocol requirements, and an application communicating via a generic protocol. A generic protocol enables a generic application to send an instruction in one standard format, for example “light=on”, or receive a sensor reading in one standard format, for example temperature=18 degrees Celsius, regardless of which specific protocol and message format a devices uses. The system further may look for, and install necessary components in specific protocols, to enable communication with new connected devices. Such new components may be preinstalled in a gateway unit, or provided by a protocol provider unit. 
         [0024]    An example of how a protocol adaptor system  100  may be arranged will now be described with reference to  FIG. 1 . The  FIG. 1  shows a protocol adaptor system  100  configured to handle devices  140  connected to the protocol adaptor system  100 . A generic protocol unit  110  arranged to interface with an application  150 , respective a specific protocol unit  130  is shown, and the specific protocol unit  130  handles communication with a device  140 . 
         [0025]    When a new device  140  is connected to the protocol adaptor system  100 , a specific protocol unit  130  recognizes that a new device  140  has been connected. If the specific protocol unit  130  has support for communication with the device  140 , communication may be instantly enabled between the device  140  and the generic protocol unit  110 , because the specific protocol unit  130  already has necessary support for communication with the new device. Thereby, the device  140  is able to communicate with the generic application  150 . The generic application  150  performs generic communication via the generic protocol unit  110 , and the communication is adapted by the specific protocol unit  130  for the device  140 , to meet the device  140  protocol requirements. The generic protocol unit  110  may have a generic device API, GDA, (API—Application Programming Interface). The GDA provides the generic application  150  one way of communication, e.g. only one set of commands to transmit and one set of readings to receive. An advantage with the GDA is that generic applications  150  may be programmed in a generic way for different types of devices  140 , or communicates generically with different devices  140 . Otherwise applications must have support for each specific protocol and how each type of device complies with that protocol. The devices  140  may however have identical or similar features or functions. Examples of devices  140  are: various media players; power switches; temperature and other climate type of meters and actuators; surveillance equipment like cameras, radars and motion detectors; sports and training equipment; healthcare monitoring devices; elderly people emergency devices, not limiting the description to other related devices or other types of devices. By mapping commands and events in the specific protocol unit to service schemas used in communication between the generic protocol unit and the generic application  150 , the generic application  150  does not have to care about how a specific device expect communication to be performed. 
         [0026]    When the specific protocol unit  130  detects a new unknown connected device  140 , the specific protocol unit  130  may report to the generic protocol unit  110  that the new unknown device  140  is unsupported by the specific protocol unit  130 , and that a new fragment is needed to enable communication with the newly connected device  140 . Examples of a fragment is a piece of computer program code in script or binary format, an extension to an already excising protocol, a service schema for mapping of service extensions, a table mapping different service features, or a text string, not limiting a fragment to be in other formats. One example embodiment of a fragment is OSGi bundle fragment used to dynamically extend an OSGi bundle. Once a fragment is attached to a host module, it works as if it has been a part of the module. Therefore, by dynamically loading a fragment for a specific protocol unit  130 , it is possible to add logic to map a service schema to a newly discovered device. A service schema may be a table for translation of commands, readings, settings, etc. A service schema may also be a simple text string, or a document describing structure of a service and its properties and actions. An example of such a document may be a document in XML-format (eXtensible markup Language). A service schema may also be computer program code in script format or binary, for conversion or translation of commands, readings, settings, etc. A service defined in a service schema may be implemented by different specific protocol units  130  with mapping protocol specific commands and parameters to the ones corresponding in the schema. By doing the mapping, applications are able to communicate with devices which use different protocols in a same manner as far as they implement a same service. If it is determined by the generic protocol unit  110  that a new fragment is required, a fragment is retrieved from a protocol provider unit  120 . The new fragment is further installed by the generic protocol unit  110  in the specific protocol unit  130  to enable communication between the new device  140  and the generic application  150 . 
         [0027]    Now looking at  FIG. 2   a , which shows embodiments of the protocol adaptor system  100 , with the generic protocol unit  110  comprising a local schema unit  200 , and the protocol provider unit  120  comprising a service schema unit  210 , a fragment database  220  and a fragment generator unit  230 . 
         [0028]    According to an embodiment, the specific protocol unit  130  may transmit a search request. If there is a new device  140  connected, the new device  140  may respond to the specific protocol unit  130 , and the specific protocol unit  130  receives the response from the new device  140 . A search request may be transmitted as a DHCP broadcast, or a request to a multicast group which devices  140  would be expected to be listening to. This is not limiting other types of requests to be used. New and/or known devices  140  may be responding to the request according to used protocol. According to an embodiment, the generic protocol unit  110  may be arranged to determine, if the newly connected device  140  is supported by the specific protocol unit  130 . The generic protocol unit  110  may also determine that a new fragment is required for the specific protocol unit  130 . If it is determined that a new fragment is required, the determination of which fragment that is required may be performed by the local schema unit  200 . The determination may be based upon information about the protocol, device vendor, device id, etc. When the local schema unit  200  has determined which fragment that is required to enable communication between the generic application  150  and the newly connected device  140 , the generic protocol unit  110  may retrieve the fragment from the local schema unit  200 , and install the fragment in the specific protocol unit  130 . According to an embodiment, a specific protocol unit  130  may for example support any of TCP/UDP IP (Transfer Control Protocol/User Datagram Protocol/Internet Protocol), UPnP (Universal Plug and Play), Bonjour, Z-wave, ZigBee, CoAP (Constrained Application Protocol), TR069 (Technical Report 069), plain text (e.g. txt files), XML (eXtensible markup Language), or JSON (JavaScript Object Notation), e-mail, http (Hypertext Transfer protocol), https (http secure), ftp (file transfer protocol), SIP (Session Initiation Protocol), Bluetooth, or proprietary protocols such as ANT+, not limiting other protocols to be used. 
         [0029]    The generic protocol unit  110  and the specific protocol units  130  may be implemented in a gateway unit  205 . Examples of a gateway unit  205  is: ADSL router, wireless LAN access device, fiber-to-the-home termination device, access points for wireless devices, mobile terminal, vehicle arranged terminal, home automation access units, TV set top boxes, pluggable PC&#39;s (miniaturized network connected PC), and similar network access points, not limiting to other units. As an example, the gateway unit  205  may be operated by computer program code according to the OSGi (Open Services Gateway initiative), as well as other unix-based systems, or other proprietary systems suitable for a gateway unit  205 . 
         [0030]    If the local schema unit  200  fails to determine which fragment that is needed for a new device, the local schema unit  200  may transmit a request to the protocol provider unit  120 . Such a request may comprise information about the newly connected device. Examples of information about a device may include: device id, device type, services supported by the device, hardware capabilities, MAC-address (Media Access Control address), vendor id, serial number, production date, protocol name, protocol version, supported features list, location. 
         [0031]    According to an embodiment, the protocol provider unit  120  comprises the service schema unit  210  and the service schema unit  210  receives the request from the local schema unit  200 , including device information. The service schema unit  210  may determine which specific fragment that is needed for enabling communication between the new device  140  and the generic application  150 . The determination may be based on the device information in the request. An example of such information included in a request is: Protocol: CoAP, Device ID: MAC address, Service IDs: &lt;/weatherResource&gt;;rt=“ZurichWeather”;title=“GET the current weather in zurich”, this should be seen as an illustrative example, and not limiting other formats or contents in requests. According to an embodiment, the service schema unit  210  retrieves the determined fragment from the fragment database  220 . A fragment may be stored in the fragment database  220  by suppliers of devices  140 , in conjunction with the release of a new device  140 . A fragment may also be stored in the fragment database  220  at a later point in time by the device  140  supplier. A fragment may also be stored in the fragment database  220  by another party than the device  140  supplier. Such a party may be a fragment developer, or similar. The weather example is good, but not obvious to be applied on a remote switch, or a volume control on speakers] 
         [0000]    An example of a service schema is:
 
-&lt;service name=“TemperatureSensor”&gt; &lt;description&gt;This service type enables reading of the current temperature of a temperature sensor &lt;/description&gt; &lt;category&gt;homeautomation.hvac&lt;/category&gt;-&lt;properties&gt;-&lt;parameter name=“currentTemperature” type=“Float”&gt; &lt;description&gt;The current temperature. Unit: degrees Celsius&lt;/description&gt; &lt;/parameter&gt; &lt;/properties&gt; &lt;/service&gt;
 
Another example is:
 
-&lt;service name=“HeartRateMonitor”&gt; &lt;description&gt;This service type enables reading the heart rate.&lt;/description&gt; &lt;category&gt;health&lt;/category&gt;-&lt;properties&gt;-&lt;parameter name=“HeartBeatCount” type=“Integer”&gt; &lt;description&gt;The measured number of beats. Unit: number of beats.&lt;/description&gt; &lt;/parameter&gt;-&lt;parameter name=“HeartBeatEventTime” type=“Integer”&gt; &lt;description&gt;Represents the time of the last valid heart beat event. Unit: milliseconds. &lt;/description&gt; &lt;/parameter&gt;-&lt;parameter name=“HeartRate” type=“Integer”&gt; &lt;description&gt;The measured heart rate. Unit: beats per minute.&lt;/description&gt; &lt;/parameter&gt; &lt;/properties&gt; &lt;/service&gt;
 
Another example is:
 
-&lt;service name=“Wakeup”&gt; &lt;description&gt;This service makes it possible to get/set wakeup interval and receive wakeup notifications. &lt;/description&gt; &lt;category&gt;zwave&lt;/category&gt;-&lt;properties&gt;-&lt;parameter name=“awakeNotificationCounter” type=“Integer&gt; &lt;description&gt;A counter that is incremented each time a wake-up notification has been received. Subscribe for changes in this property to be notified about wake-ups. &lt;/description&gt; &lt;/parameter&gt;-&lt;parameter name=“currentWakeupinterval” type=“Integer&gt; &lt;description&gt;Specifies how often the device wakes up. Unit: seconds&lt;/description&gt; &lt;min&gt;0&lt;/min&gt; &lt;max&gt;16777215&lt;/max&gt; &lt;/parameter&gt;-&lt;parameter name=”currentNodeId” type=“Integer”&gt; &lt;description&gt;Specifies the ID of the node receiving the wakeup command. 0 means broadcast. &lt;/description&gt; &lt;min&gt;0&lt;/min&gt; &lt;max&gt;255&lt;/max&gt; &lt;/parameter&gt; &lt;/properties&gt;-&lt;actions&gt;-&lt;action name=“setWakeupinterval”&gt; &lt;description&gt;Set the wakeup interval.&lt;/description&gt;-&lt;arguments&gt;-&lt;parameter name=“wakeupinterval” type=“Integer”&gt; &lt;description&gt;Specifies how often the device wakes up. Unit: seconds&lt;/description&gt; &lt;min&gt;0&lt;/min&gt; &lt;max&gt;16777215&lt;/max&gt; &lt;/parameter&gt;-&lt;parameter name=“nodeId” type=“Integer”&gt; &lt;description&gt;Specifies the ID of the node receiving the wakeup command. 255 means broadcast. &lt;/description&gt; &lt;min&gt;0&lt;/min&gt; &lt;max&gt;255&lt;/max&gt; &lt;/parameter&gt; &lt;/arguments&gt; &lt;/action&gt; &lt;/actions&gt; &lt;/service&gt;
 
         [0032]    The service schema unit  210  may be arranged to deliver the fragment, which is requested by the local schema unit  200 . This is in response to the local schema unit&#39;s  200  request for a new fragment, including device  140  information, such that a newly connected unknown device may be supported and enable communication between the device  140  and the generic application  150 . 
         [0033]      FIG. 2   a  further shows the fragment generator unit  230 . The fragment generator unit  230  may automatically generate fragments. Such generation may be triggered by a new specification available for a new device  140  provided by a device  140  supplier. The specification would be the basis for generation of the fragment. An alternative is a new service schema for a device  140 , provided for example by a device  140  supplier. A specification may be used for creation of a service schema. 
         [0034]    According to an exemplifying embodiment, the local schema unit  200  is arranged to pre-retrieve a fragment. Examples are when a fragment is generated by the fragment generator unit  230  and stored in the fragment database  220 , it is also triggered to be pre-retrieved by the local schema unit  200 . Another example of triggering of pre-retrieval of a fragment is that usage of a specific fragment has reached a certain threshold, determined e.g. by the service schema unit  210 . When the threshold is reached, the local schema unit  200  is triggered by the service schema unit  210 , to pre-retrieve a fragment, a fragment which is likely to be needed in a future. An advantage with a pre-retrieval arrangement is that deployment of a fragment in a specific protocol unit  130 , may be performed faster than it would be with retrieval from the fragment database  220  via the service schema unit  210 . 
         [0035]    The physical or logical interfaces of a gateway unit  205  may be basis for determination of fragments that should be pre-retrieved. For example, if the gateway unit  205  has a certain radio interface for connection of certain devices, that may be basis for determination of pre-retrieval of fragments for support of new devices connected to the particular interface, operating a specific protocol. Another basis for determination of which fragments that should be pre-retrieved is by a combination of generic applications  150  and specific protocol units  130 . The combination of applications potential feature utilization, and specific protocol units  130  capabilities to utilize service schemas, may form a common denominated feature set, or service schemas, which may be the basis for determination of which fragments that should be pre-retrieved. 
         [0036]    Generation of fragments may be carried out according to the following. The previously mentioned GDA, Generic Device API, may be arranged for specific use cases, e.g. controlling an on/off switch, controlling a media player, surveillance of a domain, etc. The GDA may have generic actions, commands, parameters, etc on a side facing the generic application  150 . Specific services provided by a specific device  140 , may be described according to a standardized schema. Examples of such schemas are: WSDL (Web Services Description Language), WADL (Web Application Description Language), or other types of XML-based schemas, not limiting other standard or propriety schemas to be used. By usage of a device specific standardized schema, it is possible for the fragment generator unit  230  to generate a fragment that may connect feature sets, or service schemas of a specific device with a generic application  150 , via a specific protocol unit  140  and the generic protocol unit  110 . 
         [0037]    In  FIG. 2   a , a remote management unit  260  and a gateway management unit  265  are shown. The remote management unit  260  may receive instructions from the service schema unit  210 , about which fragment that should be transmitted to the generic protocol unit  110 . The remote management unit  260  may transmit such instructions to the gateway management unit  265 . The gateway management unit  265  may, locally in the gateway unit  205 , install the fragment in the specific protocol unit  130 . An instruction from the remote management unit  260 , may include directions for the gateway management unit  265  to retrieve the fragment from the fragment database  220 , and install the fragment. Optionally the gateway management unit  265 , may receive the instructions, and further instruct the local schema unit  200 , to retrieve the fragment from the fragment database  220 , and install the fragment in the specific protocol unit  130 . 
         [0038]    According to an exemplifying embodiment the remote management unit  260  is operated according to TR069 ACS (Technical Report 069 Auto Configuration Servers) and the communication between the remote management unit  260  and the gateway management unit  265  is operated according to TR069. 
         [0039]    According to an exemplifying embodiment, the service schema unit  210  instructs the remote management unit  260  with a list of fragments. The listed fragments is not yet requested for enablement of communication between a new device and a generic application  150 , but has been determined by the local schema unit  200  or the service schema unit  210 , as subjects for pre-retrieval. The remote management unit  260  instructs the gateway management unit  265 , to download and store the fragments locally in the local schema unit. Thereby fragments may be locally available when needed for enablement of communication between a new device and a generic application  150 . 
         [0040]    It should be noted that  FIG. 2   a  illustrates various functional units in the protocol adaptor system  100  and relations to other systems, applications or devices that may interact with the protocol adaptor system  100  and the skilled person is able to implement these functional units in practice using suitable software and hardware means. Thus, this aspect of the solution is generally not limited to the shown structures of the protocol adaptor system  100 , and the functional units  110 ,  120 ,  130 ,  200 ,  210 ,  220 , and  230  may be configured to operate according to any of the features described in this disclosure, where appropriate. 
         [0041]    The functional units  110 ,  120 ,  130 ,  200 ,  210 ,  220 , and  230  described above may be implemented in the protocol adaptor system  100 , by means of program modules of a respective computer program comprising code means which, when run by processors “P”  250  causes the protocol adaptor system  100  to perform the above-described actions. The processors P  240  may comprise a single Central Processing Unit (CPU), or could comprise two or more processing units. For example, the processors P  240  may include general purpose microprocessors, instruction set processors and/or related chips sets and/or special purpose microprocessors such as Application Specific Integrated Circuits (ASICs). The processors P  240  may also comprise a storage for caching purposes. 
         [0042]    Each computer program may be carried by computer program products “M”  250  in the sensor data system  100 , shown in  FIG. 2   a , in the form of memories having a computer readable medium and being connected to the processors P. Each computer program product M  250  or memory thus comprises a computer readable medium on which the computer program is stored e.g. in the form of computer program modules “m”. For example, the memories M  250  may be a flash memory, a Random-Access Memory (RAM), a Read-Only Memory (ROM) or an Electrically Erasable Programmable ROM (EEPROM), and the program modules m could in alternative embodiments be distributed on different computer program products in the form of memories within the protocol adaptor system  100 . 
         [0043]    According to an embodiment the protocol provider unit  120  is located in a central node. Such a central node may be a node in an operator core network, or a node located at a service providers facility, co-located with other types of service nodes. The protocol provider unit  120  may also be implemented as a cloud service where. 
         [0044]      FIG. 2   b  shows an illustrative example of an embodiment of communication related to the generic protocol unit  110 . The figure shows the generic application  150  that communicates generically via the GDA, Generic Device API, with the generic protocol unit  110 . The generic protocol unit  110  adapts the communication for each respective specific protocol unit  130 , e.g. UPnP, CoAP, or Z-wave. According to the figure, the generic application  150  may transmit a signal “ON”, or “OFF” to the GDA with the generic protocol unit  110 . Further, the generic protocol unit  110  may receive a “READING” from the GDA. According to the example, the “ON”, “OFF” and “READING” are in a generic format between the generic protocol unit  110  and the generic device  110 . The communication is however adapted by each specific protocol unit  130 , to support specific devices  140 . An example is an application for light switching with “READING” detection if the switch is in mode “ON” or “OFF”. This is just an illustrative example, and not limiting other applications. 
         [0045]    A procedure in a protocol adaptor system  100  will now be described with reference to  FIG. 3 . In a first step S 100 , it is determined that a newly connected device  140  is unsupported by the specific protocol. An unsupported device  140  may include that a bit in a service schema is missing, all the way to no communication at all, with the new device  140 . The device  140  uses a variant of the specific protocol, which is unsupported. In a next step S 110  it is determined what fragment that is needed to adapt the specific protocol, in order for the specific protocol to support communication adaptation, for the unsupported device  140 . Hence, the variant of the specific protocol may be required to utilize a full feature set of a new device  140 . The term variant may include protocol version, protocol extension, protocol adaptation, protocol feature set, protocol schema, not limiting the term variant to other similar meanings. In S 120  a new fragment is retrieved from a protocol provider unit. The new fragment intended for enablement of communication with the new unknown device. In step S 130  the new fragment is installed in a specific protocol unit, i.e. the specific protocol unit that has been provided with a new fragment supporting the newly connected device. Thereby communication with the new device is enabled for generic applications  150 , via the protocol adaptor system  100 . 
         [0046]      FIG. 4  shows a more detailed example of a procedure performed by a protocol adaptor system  100 . In a first step S 90  a search request is transmitted by the specific protocol unit, and responses may be received from known and new devices. In a next step S 200  it may be determined, by the generic protocol unit, if it is a new unknown device that has responded to the search request, or an already known device. If it is determined that the device already is known, the procedure is ended in step S 205 . If it is determined that the device is new and unknown, the procedure may continue to step S 210 . In step S 210  it may be determined by the local schema unit which fragment that is needed for enablement of communication with the new unknown device. In a next step S 220  the generic protocol unit retrieves the determined fragment from the local schema unit. If the fragment is pre-retrieved and stored in the local schema unit, the procedure may proceed to step S 240 . If the fragment is not pre-retrieved, or if a needed fragment has not been determined by the local schema unit, the procedure may continue to step S 232 . 
         [0047]    In step S 232  the local schema unit transmits a fragment retrieval request to the protocol provider unit. The request may include information about the device. In step S 234  it is determined by the service schema unit, which fragment that is needed by a specific protocol unit for enablement of communication with a new unknown device. In step S 236  the determined fragment is retrieved from the fragment database and transferred to the local schema unit. In step S 240  the fragment is installed in the specific protocol unit. In step S 250  is communication with the new device enabled, and generic applications may communicate with the new connected device. 
         [0048]      FIG. 5  shows an illustrative embodiment of a clustered protocol adaptor system  100 . A system may be implemented in various ways. It may be implemented on a single unit/host like a PC or an application server host or similar electronic device, or in a large scale environment with requirements on many transactions and redundancy. This is generally valid for most systems. For the clustered protocol adaptor system  100 , a clustered or hierarchical structure may however serve different purposes. According to  FIG. 5 , the protocol adaptor system  100 , related generic applications  150 , and devices  140   160 , there may be a plurality of units, as well a plurality of protocol adaptor system  100  cooperating. 
         [0049]    The clustered protocol adaptor system  100  as shown in  FIG. 5 , may include a plurality of gateway units  205  per protocol provider unit  120 . Each gateway unit  205  may connect to a varied plurality of devices  140  and consumer applications  150 . Service schema units  210  may be distributed in a large network solution and different service schema units  210  may serve different types of gateway units  205 . Fragment databases  220  may be replicated between a plurality of central office nodes in a network. According to an embodiment a single fragment generator unit  230 , may serve a plurality of service schema units  210  and a plurality of fragment databases  220 . Not limiting other architectural solutions of how to set up or structure a protocol adaptor system  100 . 
         [0050]    While the solution has been described with reference to specific exemplary embodiments, the description is generally only intended to illustrate the inventive concept and should not be taken as limiting the scope of the solution. For example, the terms “generic protocol unit”, “protocol provider unit”, “generic application”, and “device” have been used throughout this description, although any other corresponding nodes, functions, and/or parameters could also be used having the features and characteristics described here. The solution is defined by the appended claims.