WO2014207305A1

WO2014207305A1 - Mobile device management using websocket

Info

Publication number: WO2014207305A1
Application number: PCT/FI2014/050501
Authority: WO
Inventors: Roman Pichna; Dmitry Kolesnikov
Original assignee: Cassidian Finland Oy
Priority date: 2013-06-24
Filing date: 2014-06-23
Publication date: 2014-12-31
Also published as: FI20135687A; FI125251B

Abstract

To facilitate device management, an apparatus is provided with a device management application and a WebSocket with a device management protocol for the device management application; and the apparatus is configured to establish a WebSocket connection for device management.

Description

MOBILE DEVICE MANAGEMENT USING WEBSOCKET

FIELD

The present invention relates to device management, and especially to device management via one or more proxies.

BACKGROUND ART

Device management is the generic term used for technology that allows third parties to carry out the procedures of configuring devices on behalf of the end user. Third parties are typically operators, service providers or corporate information management departments. Device management includes, but is not restricted to setting initial configuration information in devices, subsequent updates of persistent information in devices, retrieval of management information from devices, execute primitives on devices, and processing events and alarms generated by devices. In other words, through device management, an external party can remotely set parameters, conduct troubleshooting servicing of terminals, install or upgrade software.

Management of mobile devices has evolved over time. For example, OMA Device Management is a device management protocol specified by the Open Mobile Alliance (OMA) Device Management (DM) Working Group and the Data Synchronization (DS) Working Group. OMA DM specification is designed for management of small mobile devices such as mobile phones, PDAs and palm top computers. The communication protocol is a request- response protocol. Authentication and challenge of authentication are built-in to ensure that a server that sends out the management commands to a client component, which runs on a mobile device and receives and implements the management commands, are communicating only after proper validation. The communication is initiated by the OMA device management server, asynchronously, using any of the methods available such as a WAP (Wireless Application Protocol) Push or SMS (Short Message Service) that triggers a pull mechanism during which a sequence of messages might be exchanged to complete a given device management task.

SUMMARY

An object of the invention is to provide an alternative device management mechanism that is able to traverse one or more firewalls and/or one or more proxies. The object of the invention is achieved by a method, an apparatus, a computer program product and a system which are characterized by what is stated in the independent claims. The preferred embodiments of the invention are disclosed in the dependent claims.

An aspect of the invention provides a WebSocket protocol -based device management. Advantages provided by the WebSocket protocol -based device management include support for device management push and the ability to traverse firewalls and proxies.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, exemplary embodiments will be described in greater detail with reference to accompanying drawings, in which

Figure 1 shows simplified architecture of a system and block diagrams of some apparatuses according to an exemplary embodiment;

Figures 2 to 5 are signaling charts illustrating different exemplary functionalities; and

Figures 6 and 7 are block diagrams of exemplary apparatuses.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

The following embodiments are exemplary. Although the specification may refer to "an", "one", or "some" embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.

The present invention is applicable to any wideband, broadband and narrowband access based network or system that is configured to support a WebSocket protocol, or a corresponding protocol providing communication channels over a single transport connection, and a handshake protocol for the WebSocket protocol, such as a hypertext transfer protocol (HTTP), and for any user apparatus or server apparatus configured to operate at least in one of the networks/systems and support the same protocols. Such a network/system may be based on a wireless communication system or a communication system utilizing both fixed networks and wireless networks. Examples of such access networks/systems include Terrestrial Trunked Radio Access (TETRA), TETRAPOL, DMR (digital mobile radio) systems, a PAMR network (Public Access Mobile Radio), and a 3rd or 4th, or beyond, generation mobile network, like LTE (Long Term Evolution), WiMAX (Worldwide Interoperability for Microwave Access), WLAN (Wireless Local Area Net-work), like WiFi, GoTa (Global Open Trunking Architecture) and systems providing delivery of data over Internet Protocol (IP) networks, such as the Internet.

The WebSocket is protocol is a non-HTTP network protocol for providing bi-directional, full-duplex communications channels over a single Transmission Control Protocol (TCP) socket. A WebSocket connection between a client device and a server typically disconnects only after the session between the server and the client device is completed, not after the server has sent a response to a request received from the client device. Further, an existing WebSocket connection allows the server to "push" data to the client device, whereby data is sent to the client device without requiring the client device to request the data.

Below different examples are described using the HTTP protocol as an example of the handshaking protocol for the WebSocket protocol described in more detail in Internet Engineering Task Force (IETF) standard (Request for comments) RFC 6455: The WebSocket protocol, December 201 1 , without restricting the invention to the such a specific solution. The above mentioned RFC 6455 is incorporated as a reference herein.

Figure 1 illustrates an exemplary system 100 that comprises a first access network 101 serving a first end user apparatus (i.e. a client device) 1 10, a second access network 102 serving a second end user apparatus 1 10'. The access networks may be of different types. For example the first access network 101 may be a public (non-dedicated or non-professional) broadband network provided by a service operator selling subscriptions to anyone (i.e. without restrictions), or a private (professional, dedicated) network, such as a TETRA-based network and the second access network a broadband based network, like LTE for public safety (LTE public-safety broadband network). Both access networks are connected via a corresponding first or second NAT (Network Address Translation) device (router) 120a, 120b to a corresponding a first or second DMZ ("demilitarized zone") subnetwork 103, 103'. Herein a NAT device covers also a NAPT (Network Address and Port Translation) devices. Both DMZ subnetworks comprise an HTTP proxy 130, 130' and are connected via a corresponding first or second firewall device 140, 140' to a corresponding first or second public Internet service provider network 104, 104'. Both Internet service provider networks 104, 104' are connected via a corresponding third or fourth NAT device 120c, 120d to Internet 105. In the illustrated example, the device management server 150 for public safety management locates in the second DMZ subnetwork 103'.

In the illustrated example there are two WebSocket connections: a first WebSocket connection 1 1 between the device management server 150 and the first end user apparatus 1 10, and a second WebSocket connection 12 between the device management server 150 and the second end user apparatus 1 10'. The second WebSocket connection 12 illustrates a WebSocket connection in its simplest form: the connection passes only via the second HTTP proxy 130' and the second NAT server 120b over the second DMZ subnetwork 103' and the second access network 102 between the second end user apparatus 1 10' and the public safety device management server 150. The first WebSocket connection 1 1 , passing through two firewall devices 140, 140' and three NAT devices 120a, 120b, 120c, and the first HTTP proxy 130, illustrates that a WebSocket connection for device management may be used in a heterogeneous system and/or for roaming end user apparatuses.

It should be appreciated that any prior art or future NAT/NAPT device, HTTP proxy, and firewall device, or any corresponding device/network apparatus or element, may be used. A more detailed description of them is irrelevant for the actual invention, it suffices that the connection may traverse them and when HTTP is used as a handshaking mechanism for WebSocket, it suffices that HTTP proxies provide the handshaking. Therefore the NAT/NAPT device, the HTTP proxy, and the firewall device are not discussed in more detail herein.

In the illustrated example, an end user apparatus 1 10, 100' is configured to act as a WebSocket device management client. The end user apparatus 1 10, 100' refers to a computing device (equipment). Such computing devices (apparatuses) include wireless mobile communication devices operating with or without a subscriber identification module in hardware or in software, including, but not limited to, the following types of devices: mobile phone, smart-phone, personal digital assistant (PDA), handset, laptop and/or touch screen computer, e-reading device, tablet, game console, notebook, multimedia device, a handheld radio terminal, a so called fixed radio apparatus in a vehicle, a dispatching workstation that may communicate over a fixed connection and/or wirelessly and a personal computer, or a corresponding apparatus communicating over a fixed connection. In the illustrated example the end user apparatuses 1 10, 1 10' comprises at least one TCP socket 1 10-1 , a WebSocket unit 1 10-2 configured to communicate via the TCP socket 1 10-1 towards the access network, and a device management (DM) client unit 1 10-3, the WebSocket unit comprising at least a device management (DM) protocol 1 10-21 for the device management, or more precisely for the device management client unit (client application). Typically, but not necessarily, the WebSocket unit comprises also other protocols, such as a protocol for a chat service. The TCP socket may be an HTTP port number 80 or port number 443, for example.

In the illustrated example, a device management server apparatus

150 is configured to act as a WebSocket device management server. The device management server apparatus 150 refers to a computing device (equipment) configured to contain a server component (unit), which sends out the management commands to the end user apparatuses.

In the illustrated example, the device management server apparatus

(DM server) 150 comprises least one TCP socket 150-1 , a WebSocket unit 150-2 configured to communicate via the TCP socket 150-1 towards the DMZ2 subnetwork 103', and a device management (DM) server unit 150-3, the WebSocket unit comprising at least a device management (DM) protocol 150- 21 for the device management, or more precisely for the device management server unit (server application). The TCP socket may be an HTTP port number 80 or port number 443, for example. If the server apparatus 150 is configured to act as multiple different servers, like a group communication server, or PTT (push-to-talk) server, the WebSocket may comprise protocols for corresponding server services. It should be appreciated that the device management server apparatus may comprise other units for the actual device management, like memory for storing different device management objects, etc.

Although not illustrated in the example, it should be appreciated that the end user apparatuses may be configured to support also other device management applications, i.e. device management enabling a third party to carry out procedures of configuring an apparatus on behalf of an end user of the apparatus. For example, if the illustrated device management is for public safety, there may a device management for access, the device management server locating in the access network and being configured either to use the WebSocket solution, or another device management solution for the device management for the access. It is obvious to a person skilled in the art that the system may also comprise other functions and structures that need not be described in greater detail here. The more detailed structure of the system is irrelevant to the actual invention.

Figures 2 to 5 illustrate exemplary signaling relating to device management, Figures 2 and 3 illustrating how a WebSocket connection is opened, Figure 2 when Transport Layer Security (TLS) handshake protocol is used and Figure 3 when no TLS is used and one or more of the proxies in the path is not WebSocket aware, i.e. does not support WebSocket protocol. If TLS is used the proxy traversal is performed using a common way used in the Internet. If TLS is not used the proxy on the path should be WebSocket-aware. If not, the DM client may detect that there is a WebSocket unaware proxy in the path because an unexpected answer will be received, and in response to that, use the process described in Figure 3. Alternatively, the DM client may be configured to use the procedure described in Figure 3, or the DM client may be configured to determine which process to use based on network information received in broadcast channel, for example.

The TLS handshake protocol provides connection security that has three basic properties: a peer's identity can be authenticated using asymmetric, or public key, cryptography; the negotiation of a shared secret is secure; and the negotiation is reliable. In other words, the TLS handshake protocol provides an encrypted TLS tunnel between the DM client and the DM server, thereby providing an additional layer of security and implied proxy traversal. Thanks to the encrypted TLS tunnel a proxy or any other device/apparatus on the path automatically forwards the signaling transparently since it cannot see what the encrypted HTTP or WebSocket signaling contains inside of the encrypted TLS tunnel and therefore cannot do more than forward data. A further feature of TLS is that it is application protocol independent. It should be appreciated that other protocols providing similar connection security, like Secure Sockets Layer protocol that is a proprietary predecessor of the IETF standardized TLS, may be used instead of the TLS handshake protocol.

Referring to Figure 2, the end user apparatus, or more precisely, the device management client in the end user apparatus detects in point 2-1 a triggering event. The end user apparatus may be configured to maintain the WebSocket connection all the time it is connected to the network (even covering temporary loss of connectivity) in which case the triggering event is network access signaling. In other implementations, the triggering event may be that a certain period of time has lapsed after the previous WebSocket connection for device management was closed, and/or it may be manually triggered by the user via a user interface and/or any other external event may be configured to be the triggering event. Triggering event could be automatically set up at network attachment time and persist as long as possible (even during temporary loss or connectivity). Alternatively, it can be periodically set-up or manually triggered by the user or any other external event.

In response to detecting the triggering event, the TCP handshakes

(messages 2-2) are performed between the DM client and the proxy and between the proxy and the DM server, as part of the proxy traversal, to establish corresponding TCP connections. When the TCP connections are established, the TLS handshake (messages 2-3) are performed between the DM client and the DM server, the handshake signaling traversing other network elements. After TLS connection is set-up, the WebSocket handshake is triggered by sending an upgrading HTTP GET message 2-4 to set up (establish) a WebSocket connection in a compatible way. Message 2-4 includes information indicating that the WebSocket connection is for device management (DM). In the illustrated example it also comprises device management -specific headers and security. The device management - specific headers are for carrying device management session parameters. Any kind of parameters may be used, i.e. there are no restrictions for the device management -specific headers. The same applies to the security (security information or security header(s)) in the message. The security is for supporting authentication and authorization. In other words, the DM-specific headers and security are for informing the DM server about the intent of the client to perform device management, and also receives additional information data (status of the device, software version, etc.) and credentials (identities, hashes of passwords, certificates) with which information the server may make a correct decision whether or not to accept the request of message 2-4.

When the device management server (DM server) receives message 2-4, the DM server determines in point 2-5 the device management objects the sending client needs to update or install, i.e. missing DM object(s). Then the DM server sends a response to message 2-4 in message 2-6, the response being HTTP 101 and containing, in addition to indicating that the WebSocket connection is for device management and the device management-specific headers and security, the missing DM objects piggypacked to the response. An advantage of the piggypacking is that it saves network resources by delivering all information without any additional signaling. It should be appreciated that message 2-6 may be sent without piggypacking DM objects in which case the DM objects are delivered using the delivery way illustrated in Figure 4 or 5, for example. Further, it should be appreciated that one or more of the header values in message 2-6 may be the same as in message 2-4 or different from the value in message 2-4.

When the DM client receives the DM objects, the DM client executes (implements) the DM objects in point 2-7 while the WebSocket connection (2-8) is available for later retrieval/delivery of DM objects.

In one implementation the WebSocket connection is established only for one-time management and closed after message 2-7.

It should be appreciated that if there is no proxies or corresponding devices between the DM client and the DM server, also the TCP connection may be established directly between the DM client and the DM server may sending messages 2-2 between the DM client and the DM server.

Referring to Figure 3, the end user apparatus, or more precisely, the device management client in the end user apparatus detects in point 3-1 a triggering event for device management. Examples of triggering events are described above with the description of Figure 2. Since in the example the TLS handshake protocol is not used, the DM client performs the TCP handshake (messages 3-2) with the proxy, and then sends to the proxy a request 3-3 to connect to the DM server, the request being HTTP CONNECT and containing an address of the DM server.

In response to receiving the request HTTP CONNECT, the proxy triggers TCP handshake (messages 3-4) with the DM server and responses by message 3-5 "HTTP 200" to the DM client. Should the DM client sent instead of the HTTP CONNECT the HTTP GET message, the WebSocket unaware proxy would have still responded with HTTP 200 (wrong response to HTTP GET message) causing the WebSocket connection establishment to fail. In other words, by sending HTTP CONNECT first, the proxy learns the address of the DM server and is "fooled" into forwarding the later signaling transparently.

In response to receiving HTTP 200 response, the DM client then sends to the proxy an upgrading HTTP GET message 3-6 to set up (establish) a WebSocket connection to the DM server. Message 3-6 is similar to message 2-4 described above. Since the proxy has established a TCP connection to the DM server, it forwards message 3-6 transparently to the DM server.

In the illustrated example, the DM server is not configured to piggypack DM object to HTTP 101 responses. Therefore the DM server responses (without performing any determination of DM objects) by sending message 3-7, i.e. HTTP 101 response to the proxy which then forwards message 3-7 to the DM client. Message 3-7 is similar to message 2-6, except that message 3-7 does not contain piggypacked DM objects. Then the WebSocket connection (8-8) is available for retrieval/delivery of DM objects.

It should be appreciated that the DM server may be configured to piggypack DM objects to the HTTP 101 response (message 3-7).

Further, it should be appreciated that if the DM client first sends the HTTP GET message and receives HTTP 200 as a response, the DM client is triggered to open the WebSocket connection using the signaling described with Figure 3, starting by sending HTTP CONNECT (message 3-2).

Figures 4 and 5 illustrate examples how the WebSocket connection between the DM client and the DM server (established either as described with Figure 2 or Figure 3) is used for delivery of DM objects. Depending on an implementation both push (Figure 4) and pull (Figure 5) may be used, or the DM server and the DM client may be configured to use only one of them, i.e. either push or pull.

Referring to Figure 4, the DM server determines in point 4-1 the device management objects the DM client needs to update or install, i.e. missing DM object(s), and then pushes them to the DM client in message 4-2 without a request from the DM client. The DM client executes (implements) the pushed DM objects in point 4-3.

Referring to Figure 5, the DM client sends a request for missing DM objects by message 5-1 requesting pull of device management data. In response to receiving the pull request, the DM server determines in point 5-2 the device management objects the requesting DM client needs to update or install, i.e. missing DM object(s), and then sends them to the DM client in message 5-3. The DM client executes (implements) the pushed DM objects in point 5-4.

As is evident from the above, the WebSocket-based device management provides an access operator independent mechanisms that traverses firewalls and proxies and NAT devices so that a WebSocket connection for device management can be established between a DM client and the DM server thereby allowing the device management, i.e. a third party to carry out procedures of configuring the apparatus on behalf of an end user of the apparatus.

Figure 6 is a simplified block diagram illustrating some units for an apparatus 600 configured to be an end user apparatus, i.e. an apparatus providing at least the WebSocket unit and the DM client unit and/or one or more units configured to implement at least some of the functionalities described above. In the illustrated example the apparatus comprises one or more interfaces (IF) 601 ' for receiving and transmitting communications, one or more user interfaces (U-IF) 601 for interaction with a user, a processor 602 configured to implement at least some functionality described above with a corresponding algorithm/algorithms 603 and a memory 604 usable for storing a program code required at least for the implemented functionality and the algorithms and for the address of the DM server. The memory 604 is also usable for storing information received by means of header values, addresses, names, identities and credentials of other clients, for example. The memory 604 is also usable for storing data destined for upload to the DM server and for storing management objects received from the DM server.

Figure 7 is a simplified block diagram illustrating some units for an apparatus 700 configured to be a device management server apparatus, i.e. an apparatus providing at least the WebSocket unit and the DM server unit and/or one or more units configured to implement at least some of the functionalities described above. In the illustrated example, the apparatus comprises one or more interfaces (IF) 701 ' for receiving and transmitting information, a processor 702 configured to implement at least some functionality described above with a corresponding algorithm/algorithms 703, and memory 704 usable for storing a program code required at least for the implemented functionality and the algorithms and for device management objects . The memory 704 is also usable for storing other information, such as identities, logs of actions including time and management objects delivered and/or retrieved, success of the actions, etc.

In other words, an apparatus configured to provide the end user apparatus, and/or an apparatus configured to provide the server apparatus, or an apparatus configured to provide one or more corresponding functionalities, is a computing device that may be any apparatus or device or equipment configured to perform one or more of corresponding apparatus functionalities described with an embodiment/example/implementation, and it may be configured to perform functionalities from different embodiments/examples/ implementations. The unit(s) described with an apparatus may be separate units, even located in another physical apparatus, the distributed physical apparatuses forming one logical apparatus providing the functionality, or integrated to another unit in the same apparatus.

The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding apparatus described with an embodiment/example/implementation comprises not only prior art means, but also means for implementing the one or more functions of a corresponding apparatus described with an embodiment and it may comprise separate means for each separate function, or means may be configured to perform two or more functions. For example, the WebSocket units, and/or DM client unit(s) and/or DM server unit(s) and/or algorithms, may be software and/or software- hardware and/or hardware and/or firmware components (recorded indelibly on a medium such as read-only-memory or embodied in hard-wired computer circuitry) or combinations thereof. Software codes may be stored in any suitable, processor/computer-readable data storage medium(s) or memory unit(s) or article(s) of manufacture and executed by one or more processors/computers, hardware (one or more apparatuses), firmware (one or more apparatuses), software (one or more modules), or combinations thereof. For a firmware or software, implementation can be through modules (e.g., procedures, functions, and so on) that perform the functions described herein. Software codes may be stored in any suitable, processor/computer-readable data storage medium(s) or memory unit(s) or article(s) of manufacture and executed by one or more processors/computers.

An apparatus configured to provide the end user apparatus, and/or an apparatus configured to provide the server apparatus, and/or an apparatus configured to provide one or more corresponding functionalities, may generally include a processor, controller, control unit, micro-controller, or the like connected to a memory and to various interfaces of the apparatus. Generally the processor is a central processing unit, but the processor may be an additional operation processor. Each or some or one of the units and/or algorithms and/or calculation mechanisms described herein may be configured as a computer or a processor, or a microprocessor, such as a single-chip computer element, or as a chipset, including at least a memory for providing storage area used for arithmetic operation and an operation processor for executing the arithmetic operation. Each or some or one of the units and/or algorithms and/or calculation mechanisms described above may comprise one or more computer processors, application-specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field-programmable gate arrays (FPGA), and/or other hardware components that have been programmed in such a way to carry out one or more functions or calculations of one or more embodiments. In other words, each or some or one of the units and/or the algorithms and/or the calculation mechanisms described above may be an element that comprises one or more arithmetic logic units, a number of special registers and control circuits.

Further, an apparatus implementing functionality or some functionality according to an embodiment/example/implementation of an apparatus configured to provide the end user apparatus, and/or an apparatus configured to provide the server apparatus, or an apparatus configured to provide one or more corresponding functionalities, may generally include volatile and/or non-volatile memory, for example EEPROM, ROM, PROM, RAM, DRAM, SRAM, double floating-gate field effect transistor, firmware, programmable logic, etc. and typically store content, data, or the like. The memory or memories may be of any type (different from each other), have any possible storage structure and, if required, being managed by any database management system. The memory may also store computer program code such as software applications (for example, for one or more of the units/algorithms/calculation mechanisms) or operating systems, information, data, content, or the like for the processor to perform steps associated with operation of the apparatus in accordance with examples/embodiments. The memory, or part of it, may be, for example, random access memory, a hard drive, or other fixed data memory or storage device implemented within the processor/apparatus or external to the processor/apparatus in which case it can be communicatively coupled to the processor/network node via various means as is known in the art. An example of an external memory includes a removable memory detachably connected to the apparatus.

An apparatus implementing functionality or some functionality according to an embodiment/example/implementation of an apparatus configured to provide the end user apparatus, and/or an apparatus configured to provide the server apparatus, or an apparatus configured to provide one or more corresponding functionalities, may generally comprise different interface units, such as one or more receiving units for receiving user data, control information, requests and responses, for example, and one or more sending units for sending user data, control information, responses and requests, for example. The receiving unit and the transmitting unit each provides an interface in an apparatus, the interface including a transmitter and/or a receiver or any other means for receiving and/or transmitting information, and performing necessary functions so that content and other user data, control information, etc. can be received and/or transmitted. The receiving and sending units may comprise a set of antennas, the number of which is not limited to any particular number.

Further, an apparatus implementing functionality or some functionality according to an embodiment/example/implementation of an apparatus configured to provide the end user apparatus, and/or an apparatus configured to provide the server apparatus, or an apparatus configured to provide one or more corresponding functionalities, may comprise other units.

The points, messages and related functions described above in Figures 2 to 5 are in no absolute chronological order, and some of the points may be performed simultaneously or in an order differing from the given one. Other functions can also be executed between the points or within the points. Some of the points or part of the points can also be left out or replaced by a corresponding point or part of the point. The messages are only exemplary and may even comprise several separate messages for transmitting the same information.

It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.

Claims

1 . A method comprising:

providing an apparatus with a device management application;

providing a WebSocket in the apparatus with a device management protocol for the device management application; and

establishing a WebSocket connection for device management.

2. A method as claimed in claim 1 , wherein the device management is for a third party to carry out procedures of configuring the apparatus on behalf of an end user of the apparatus.

3. A method as claimed in claim 1 or 2, wherein the apparatus is an end user apparatus and the device management application is a client application, the method further comprising:

starting establishment of the WebSocket connection by sending a

HTTP GET request from the apparatus to a device management server, the request containing an upgrading to WebSocket and identifying the device management protocol.

4. A method as claimed in claim 3, further comprising:

detecting by the client application that there exists between the end user apparatus and the device management server a HTTP proxy that does not support the WebSocket protocol;

sending a HTTP CONNECT request to the proxy prior to sending the HTTP GET request, the HTTP CONNECT request requesting an HTTP connection to the device management server via the HTTP proxy that does not support WebSocket protocol;

receiving a HTTP RESPONSE indicating that there exist the HTTP connection to the device management server; and

in response to the HTTP response, sending the HTTP GET request.

5. A method as claimed in claim 3 or 4, further comprising: receiving in a response to the HTTP GET request one or more device management objects; and

executing the received one or more device management objects.

6. A method as claimed in claim 3, 4 or 5, further comprising:

receiving after the WebSocket connection has been set up a device management push signal containing one or more device management objects;

executing the received one or more device management objects.

7. A method as claimed in claim 3, 4, 5 or 6, further comprising: triggering, after the WebSocket connection has been established, by the client a device management pull to obtain one or more device management objects.

8. A method as claimed in claim 1 or 2, wherein the apparatus is a device management server apparatus and the device management application is a server application, the method further comprising:

receiving in the device management server apparatus a HTTP GET request from an end user apparatus, the request containing an upgrading to WebSocket and identifying the device management protocol; and

establishing the WebSocket connection by sending a response to the HTTP GET request.

9. A method as claimed in claim 8, further comprising piggypacking one or more device management objects to the response.

10. A method as claimed in claim 8 or 9, further comprising sending after the response to the end user apparatus a device management push signal containing one or more device management objects.

1 1 . A method as claimed in claim 8, 9 or 10, further comprising receiving from the end user apparatus a pull request; and sending in a response to the pull request one or more device management objects.

12. An apparatus comprising means for performing a method as claimed in any one of claims 1 to 1 1 .

13. A computer program product comprising computer program code configured to perform a method as claimed in any one of claims 1 to 1 1 when executed on an apparatus.

14. A system comprising

at least one device management server; and

at least one end user apparatus comprising a device management application and a WebSocket with a device management protocol for the device management application, the at least one end user apparatus being configured to establish a WebSocket connection for device management to the device management server; wherein

the at least one device management server comprises a device management application and a WebSocket with a device management protocol for the device management application, and is configured to establish a WebSocket connection for device management with the at least one end user apparatus.

15. A system as claimed in claim 14, wherein the device management is for a third party to carry out procedures of configuring the end user apparatus on behalf of an end user of the apparatus.

16. A system as claimed in claim 14 or 15, wherein

the at least one end user apparatus comprises means for implementing a method as claimed in any one of claims 3 to 7; and

the at least one device management server comprises means for implementing a method as claimed in any one of claims 8 to 1 1 .