Method for managing a remote device, communication method, management server and communication device

Abstract

Method and management of a remote device, communication method, management server and communication device. The method for managing a remote device (RD) implemented by a management server (MS) configured to manage said remote device via a current management channel (C1) established with the remote device, said method comprises: - a step of sending, to the remote device, via said management channel, a command to establish an occasional intervention channel (C2) with a latency lower than that of the management channel, - following the establishment of said occasional intervention channel, sending at least one management command to the remote device via said occasional intervention channel. Figure for the abbreviation: Figure 1

Description

Title of the invention: Method for managing a remote device, communication method, management server and communication device. Field of the invention

[0001] This invention relates generally to the field of communications between remote devices.

[0002] More specifically, the invention relates to a method for remotely managing a communicating device. Previous art

[0003] Internet access relies on the implementation of numerous network devices: servers, DSLAMs (Digital Subscriber Line Access Multiplexers), routers, gateways, etc. The proper functioning of these devices involves various management, maintenance, and sometimes troubleshooting actions. Such actions may, for example, include updating the computer systems (firmware) of these devices, adjusting their configuration parameters, or occasionally troubleshooting and testing to resolve malfunctions or failures.

[0004] Due to the varied nature of the network equipment to be managed, their number and their location (and incidentally, a possible difficulty in accessing this network equipment), it is necessary to use appropriate communication protocols to allow remote interaction with this network equipment.

[0005] Thus, for example, the TR-069 protocol (or CPE WAN Management Protocol, as defined in the technical report "TR-069: CPE WAN Management Protocol" of the DSL Forum of May 2004) is frequently used in the context of managing, from a wide area network, equipment belonging to a local area network, such as routers or gateways, often referred to as "internet boxes".

[0006] This protocol is particularly well suited in this context, since it allows maintenance and update operations to be carried out on a large number of equipment in a secure manner while limiting the associated network costs.

[0007] However, the TR-069 protocol and similar protocols are not designed for real-time communication. In the case of ad-hoc interventions, such as troubleshooting or investigating the causes of a network equipment malfunction, this limitation can lead to longer intervention times for technicians operating from a management server.

[0008] To address this problem, other so-called "real-time" protocols, such as the MQTT (originally Message Queuing Telemetry Transport) protocol, can be used. However, these protocols, which have lower latency, require a permanent connection between the management server and the network equipment on which intervention is planned in order to maintain an active communication channel between them. Although this allows for near-instantaneous interaction, maintaining such a permanent connection can be costly in terms of network resources, energy consumption, and infrastructure management, especially when intervention is required on a large number of network devices.

[0009] This requirement for constant connectivity poses a particular challenge for network operators seeking to optimize operational efficiency while managing expanding equipment fleets.

[0010] It follows that such so-called "real-time" protocols, due to their cost and the number of devices to be managed, are not used to carry out remote configuration or diagnostic operations.

[0011] Object and summary of the invention

[0012] The invention addresses, in particular, the problem of choosing between a cost-effective network and a network with lower latency, by proposing a method for managing a remote device, implemented by a management server configured to manage said remote device via a current management channel established with the remote device, said method comprising: - a step of sending, to the remote device, via said management channel, a command to establish an occasional intervention channel with a latency lower than that of the management channel, - following the establishment of said occasional intervention channel, the sending of at least one management command to the remote device via said occasional intervention channel.

[0013] The invention also relates to a communication method, implemented by a remote device communicating with a management server via a standard management channel, said method comprising: - a receiving step, from said management server via said current management channel, of a command to establish an occasional intervention channel with a latency lower than that of the management channel, - following the establishment of the intervention channel, a receiving step of at least one management command from the management server via the intervention channel.

[0014] The invention advantageously overcomes the limitations of prior art management solutions based solely on the use of a TR-069 or similar type communication protocol, and in particular their relatively low latency. consequently, by offering the management server the possibility of using, when necessary or relevant, a communication channel with lower latency and incidentally greater responsiveness.

[0015] By significantly reducing transmission times when two devices need to send each other a large number of requests and replies (request-reply) and when latency applies to each exchange, the invention advantageously allows a technician working on one or more network devices to perform shorter interventions. Consequently, they can perform more interventions within a given timeframe.

[0016] Thus, the invention proposes to have two channels for managing remote equipment:

[0017] - a current management channel (hereafter referred to interchangeably as the first channel), used by default for many common operations, such as retrieving usage information or updating internet gateways or routers via management servers. This common management channel typically uses remote device management protocols such as TR-069 or a similar protocol; and - an occasional intervention channel (hereafter referred to interchangeably as the second channel), which offers greater responsiveness than the regular management channel at the cost of a higher cost in terms of network resources, but whose activation is occasional and exceptional.

[0018] The fact that the occasional intervention channel may require more substantial network resources (for example because this channel requires that a permanent connection to the server be kept active) is thus counterbalanced by the fact that its activation is, in accordance with the invention, triggered occasionally, for example during a one-off troubleshooting or diagnostic operation.

[0019] According to a particular embodiment, the method of managing a remote device further includes a step of detecting a given event triggering the sending, to the remote device, via said management channel, of the command to establish the occasional intervention channel.

[0020] There is no limitation attached to the nature of the event triggering the sending of the establishment command. For example, this event could be the opening, from the management server, of a configuration panel associated with the remote network equipment, or when a support technician enters a customer reference number associated with a remote device into software implemented by the management server.

[0021] This embodiment advantageously makes it possible to condition the activation of an occasional intervention channel on a specific and pre-established triggering event, and therefore reduce the risk of an increase in network resources mobilized for non-exceptional actions associated by default with the management channel used for routine management operations

[0022] According to a particular embodiment of the communication process, the establishment of the occasional intervention channel is conditioned by an authentication of the establishment command received from the management server.

[0023] The authentication implemented for this embodiment can be authentication according to the SSL / TLS (Secure Socket Layer / Transport Layer Security) protocol or according to any other protocol known to a person skilled in the art.

[0024] This embodiment advantageously secures actions performed via the occasional intervention channel. For example, authentication ensures that the remote device does not receive information that could interfere with its proper functioning or, conversely, does not send sensitive information to an unauthorized management server.

[0025] On the other hand, the implementation of prior authentication before the order to establish the occasional intervention channel makes it possible to avoid unnecessary consumption of network resources in the event of an order to establish an intervention channel by an unauthorized management server.

[0026] According to a particular embodiment, the communication method further includes a step of deactivating the occasional intervention channel after a period of time known to the remote device.

[0027] Alternatively, the communication method further includes a step of deactivating the occasional intervention channel after a given period of inuse of said occasional intervention channel.

[0028] The value of this inactivity time can be communicated, in particular, when requesting activation of the occasional intervention channel. Optionally, the request to activate the second channel can be refused if no value is provided for this inactivity time or if the value provided exceeds a maximum time allowed by the remote device.

[0029] These embodiments advantageously limit energy consumption and bandwidth consumption associated with the occasional intervention channel. Making this interruption automatic in case of inactivity or conditioning it on a predetermined time limits the risk of excessively long activation of the occasional intervention channel, which would consume too many network resources. This embodiment also eliminates the need for a specific command to interrupt the occasional intervention channel, thus simplifying the implementation of the invention.

[0030] According to a particular embodiment, the management process further includes a step of sending a command to deactivate the occasional intervention channel to the remote device.

[0031] In correspondence, according to a particular embodiment, the communication method further includes a step of deactivating the occasional intervention channel upon receipt of a command from the server.

[0032] This embodiment advantageously avoids cases where the occasional intervention channel is open for too long and where the network costs incurred by maintaining its opening are no longer offset by the advantages provided by its responsiveness and the lower latency time between messages exchanged with the management server.

[0033] According to a particular embodiment, the occasional intervention channel conforms to the MQTT protocol.

[0034] The use of the MQTT protocol allows for near-instantaneous interaction between the management server and the remote device and therefore offers lower latency times than the default communication channel used to communicate between the management server and the remote device.

[0035] Since maintaining connections according to the MQTT protocol between a large number of communication devices can prove costly in terms of network resources, the invention makes it possible to limit the use of such a protocol to occasional uses.

[0036] According to a particular embodiment, the current management channel conforms to the TR-069 (Technical Report) protocol.

[0037] The invention also relates to a management server configured to manage a remote device via a current management channel established with the remote device, comprising: - a sending module configured to send to the remote device, via said management channel, a command to establish a temporary intervention channel with a latency lower than that of the management channel, - a management module configured to, following the establishment of said occasional intervention channel, send at least one management command to the remote device via said occasional intervention channel.

[0038] The invention also relates to a device capable of communicating with a management server via a standard management channel, said remote device comprising: - a receiving module, configured to receive, from said management server via said current management channel, a command to establish an occasional intervention channel with a latency lower than that of the management channel, - a receiving module, configured to, following the establishment of the occasional intervention channel, receive at least one management command from the management server via the intervention channel.

[0039] The invention finally relates to a communication system comprising: - a management server according to the invention, - a remote device according to the invention.

[0040] The invention further relates to a computer program comprising program code instructions for implementing management and communication methods according to any one of the particular embodiments described above, when said program is executed on a computer.

[0041] Such instructions can be stored permanently in a non-transient memory medium of a communication terminal implementing the management and communication processes according to the invention.

[0042] This program may use any programming language, and be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0043] The invention also relates to a computer-readable information or recording medium comprising instructions for a computer program as mentioned above.

[0044] The recording medium can be any entity or device capable of storing the program. For example, the medium can include a storage means, such as a ROM (Read Only Memory), for example a CD ROM (Compact Disc Read-Only Memory) or a microelectronic circuit ROM, or a magnetic recording means, for example a mobile medium, a hard disk or an SSD (Solid State-Drive).

[0045] On the other hand, the recording medium can be a transmissible medium, such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means, so that the computer program it contains is executable remotely. The program according to the invention can, in particular, be uploaded to a network, for example, an Internet-type network.

[0046] Alternatively, the recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned management and communication processes.

[0047] It can also be envisaged, in other embodiments, that the processes, the management and communication devices, and the communication system according to the invention present in combination all or part of the aforementioned characteristics.

[0048] Brief description of the drawings and appendix

[0049] Other features and advantages will become apparent upon reading particular embodiments of the invention, given by way of illustrative and non-limiting examples, and the accompanying drawings, among which:

[0050] Figure 1 represents a communication system according to the invention in a particular embodiment,

[0051] Figure 2 represents an example of a management server implementing the method for managing a remote device according to an embodiment of the invention,

[0052] Figure 3 represents an example of a remote device implementing the communication method according to one embodiment of the invention.

[0053] Figure 4 describes the steps of the management and communication processes according to one embodiment,

[0054] The appendix presents commands in Python® language that can be used by the remote device.

[0055] Description of an example of an architecture in which the communication methods are implemented

[0056] Figure [Fig.1] presents a communication system within which the management and communication processes according to the invention can be implemented in a particular embodiment.

[0057] This system comprises: - a management server (SG) conforming to the invention. The SG can be a dedicated server or any other device performing similar management operations (a computer, a DSLAM, a computer associated with a remote equipment maintenance application, etc.); and - at least one remote DD device, conforming to the invention, such as for example a gateway, a NAS (Network Attached Storage), a router or any other remote device capable of being managed by the SG server.

[0058] The server SG and said at least one remote device DD communicate via a communication network R. This network allows them to exchange information with each other, particularly within the scope of the invention. In this embodiment, the network R is a fiber network; however, alternatively, it can be any communication network known to a person skilled in the art.

[0059] In the example illustrated in [Fig. 1], for the sake of simplicity, a single remote device DD is considered. However, the management server SG can be configured to manage a plurality of remote devices in a similar or identical manner to that described here for the remote device DD.

[0060] In the example considered here, the SG management server corresponds to a device management system, commonly referred to by the acronym ACS (Auto-Configuration Servers). This type The management server is notably used for the remote management, configuration, and monitoring of devices such as routers, residential gateways, and IoT (Internet of Things) devices. However, the management server can correspond to any other type of system or server known to those skilled in the art. Typically, the management server (SG) communicates with the remote device (DD) to perform such remote management, configuration, and / or monitoring operations via a primary communication channel (Cl), also known as the default or current management channel, which uses a specific communication protocol.

[0061] In the example considered here, the current management channel conforms to the TR-069 management protocol. However, alternatively, it may also be a communication channel conforming to any other CoaP management protocol or to any other protocol known to a person skilled in the art.

[0062] According to the invention, the remote device DD and the management server SG can also communicate occasionally via a second communication channel C2, called the occasional communication channel or occasional intervention channel, using a given protocol different from the management protocol used by the default communication channel Cl and having a lower latency.

[0063] In the example considered here, the occasional intervention channel C2 conforms to the MQTT protocol.

[0064] However, alternatively, it may also be a communication channel conforming to the AMQP protocol or using KAFKA message buses or any other protocol known to a person skilled in the art, provided that it has a latency lower than that of the current management channel.

[0065] In accordance with the invention, the SG management server is equipped with: - of an MES sending module, and - of an MGS management module.

[0066] The remote device DD is equipped with: - of an MRD receiving module, - of an MGD receiving module.

[0067] The various functional modules of the SG management server and the DD remote device are described in more detail later.

[0068] Figure 2 presents the simplified structure of the SG management server, configured to implement the management process according to the invention, in a particular embodiment.

[0069] In the particular embodiment of the invention described herein, the steps executed by the management server SG are implemented by means of instructions from a computer program PG1. For this purpose, in the embodiment described herein, The SG management server has the classic architecture of a computer and includes in particular an ER1 transmit / receive module, a MEM1 memory, a UTR1 processing unit, equipped for example with a PROC1 processor, and controlled by the PG1 computer program stored in MEM1 memory. The MEM1 memory is a recording medium within the meaning of the invention.

[0070] As mentioned above, the PG1 computer program includes instructions for implementing the steps of the management process according to the invention, which are described later with reference to Figure [Fig. 4]. It thus defines functional modules of the SG server which include: - the MES sending module configured to send to the remote device, via the Cl management channel, a command to establish the occasional intervention channel C2 which has a lower latency than the Cl management channel, - the MGS management module configured to, following the establishment of said occasional intervention channel C2, send at least one management command to the remote device via said occasional intervention channel C2.

[0071] Figure 3 shows the simplified structure of the remote device DD configured to implement the communication method according to the invention in a particular embodiment.

[0072] In the particular embodiment of the invention described herein, the steps executed by the remote device DD are implemented by means of instructions in a computer program PG2. For this purpose, the device DD has the conventional architecture of a computer and includes, in particular, a transmit / receive module ER2, a memory MEM2, a processing unit UT2, equipped, for example, with a processor PROC2, and controlled by the computer program PG2 stored in memory MEM2. The memory MEM2 is a storage medium within the meaning of the invention.

[0073] As mentioned above, the PG2 computer program includes instructions for implementing the steps of the communication method according to the invention, which are described later with reference to Figure [Fig. 4]. It defines functional modules of the remote device DD, which include in particular: - the MRD receiving module, configured to receive, from said management server via said current management channel Cl, a command to establish the occasional intervention channel C2, - the MGD receiving module, configured to, following the establishment of the occasional intervention channel C2, receive at least one management command from the management server via this occasional intervention channel C2.

[0074] Description of the main steps of the management and communication processes.

[0075] Figure [Fig.4] describes the steps of the management and communication processes according to the invention in a particular embodiment in which the processes are implemented respectively by the management server SG and the remote device DD.

[0076] As described previously, it is assumed that during a preliminary step (not shown in [Fig. 4]), the current management channel Cl is established between the management server SG and the remote device DD. This communication channel Cl is used to enable exchanges between the management server SG and the remote device DD (including, in particular, the sending of management commands by the management server SG) within the framework of common remote management operations, such as updates to the remote device DD or the retrieval by the management server SG of usage data from the device DD.

[0077] However, in the context of an occasional management operation, the use of an occasional intervention channel with lower latency is considered preferable to the use of said regular management channel.

[0078] In the example considered here, the management and communication processes enabling the establishment of an occasional intervention channel are initiated following a given event, such as the opening, for the purpose of urgent troubleshooting, of a business application from the management server referring to an identifier corresponding to the remote device (such as a customer number attached to the remote device or an IP address, etc.).

[0079] However, alternatively, management and communication processes, enabling the establishment of an occasional intervention channel, are implemented as soon as a management and / or intervention operation justifies, from the point of view for example of an intervention technician or a support manager, the use of an occasional intervention channel.

[0080] Thus, in E401, the management server SG sends, to the remote device DD, via the current management channel Cl, a command to establish an occasional intervention channel C2.

[0081] The use of this occasional intervention channel C2 is exceptional and is intended only for a limited number of management operations for which, due to its lower latency and despite its increased cost in terms of network resources, the use of the intervention channel is justified by given constraints. These constraints may include, for example, the severity of a fault to be addressed, the processing time allocated to a technician for a particular type of intervention, etc.

[0082] According to this example, the sending of the establishment command is automatically triggered following a given event such as the opening of a business application from the management server referring to an identifier corresponding to the remote device (such as a customer number attached to the remote device or an IP address, etc.) or to any other event.

[0083] In the embodiment described here, the command to establish channel C2 results in the triggering, by the remote device DD, of a REST server embedded in the remote device serving as an activation point for an MQTT client.

[0084] The command to establish an occasional intervention channel C2 by the remote device DD also includes, in the embodiment described here, data enabling the remote device to authenticate the management server SG.

[0085] By way of example (from the appendix), a request enabling the secure activation (i.e., establishment command within the meaning of the invention) of the C2 channel according to the MQTT real-time protocol can take the following form: curl -X POST "$DD_URL" \ -H "Authorization: Bearer $AUTH_TOKEN" \ -H "Content-Type: application / json" \ -d'{ "action": "establish_channel", "protocol": "MQTT" r________________________________________________________________

[0086] In this example, we consider basic authentication. The AUTH_TOKEN parameter is an authentication data known to the remote device and the server.

[0087] Alternatively, authentication according to OAuth2.0 protocols or authentication based on X.509 certificates or any other type of authentication known to the person skilled in the art may be implemented.

[0088] In E402, the remote device DD receives from the management server SG via the default communication channel Cl, the command to establish an occasional intervention channel C2.

[0089] According to this embodiment, the remote device authenticates the management server SG from which the establishment command (or request) originates. If the management server SG is listed as a server authorized to issue such a command to the remote device DD, the management and communication processes continue; otherwise, the processes terminate.

[0090] The information that the management server is authorized to issue a command to establish an occasional intervention channel is, for example, previously entered in a configuration file or in a database internal to the remote device DD or accessible by the latter from an unrepresented third-party device (for example, a server or a remote computer).

[0091] In E403, the remote device DD establishes an occasional intervention channel (or second communication channel) C2 with the management server SG.

[0092] According to this embodiment, a REST server embedded in the remote device is used to activate an MQTT client in order to establish said occasional intervention channel.

[0093] Alternatively, the occasional intervention channel may use any other client corresponding to another communication protocol suitable for occasional intervention known to the person skilled in the art.

[0094] In E404, the remote device DD sends a connection request to the occasional intervention channel C2, destined for the management server SG.

[0095] As an example from the appendix, a prompt for establishing an MQTT connection via login / password on an MQTT client can take the following form in Python®: # Authentication information username = "your_username" password = "your_password" # Connecting to the broker with client authentication. `usemame_pw_set(username, password)` `client.connect($SG_BROKER_URL, 1883, 60)` `$SG_BROKER_URL is an example of a connection address to the management server` # Loop to process client messages.loop_start()

[0096] In E405, after accepting the connection request to the MQTT client, the management server SG sends at least one management command to the remote device DD via the occasional intervention channel C2.

[0097] In the example considered here, channel C2 is used to exchange data relating to the troubleshooting intervention mentioned above. Alternatively, the occasional intervention channel C2 is used for specific (i.e., non-routine) diagnostics, troubleshooting, or configuration of the remote device, or any other intervention relevant to a person skilled in the art.

[0098] According to this embodiment, the communication channel Cl can continue to be used, in parallel with the occasional intervention channel C2, to transmit data relating to current management operations.

[0099] In order to enhance security, the REST server used to trigger the MQTT client also implements strict authentication and authorization mechanisms, ensuring that only messages from the management server are accepted, thus preventing any unauthorized activation of the MQTT client.

[0100] This authentication mechanism is based on the same information used in E402 to verify that the management server is authorized to issue a command to establish a casual intervention channel. Alternatively, the REST server implements a separate authentication mechanism, such as, by default, the "https (Hypertext Transfer Protocol Secure) over TLS (Transport Layer Security) 2-way" mode with mutual identification of the client and server certificates, including a proxy between the server and the client which would perform basic access authentication.

[0101] According to another example, it is also possible to define in addition an addressing path ("url path" in English) with an endpoint of a communication channel ("endpoint" in English) including an encrypted identifier known only to the server.

[0102] In E406, once the data has been exchanged, the occasional intervention channel C2 is deactivated.

[0103] In the embodiment described here, the occasional intervention channel C2 is configured to be deactivated after a predefined time known to the remote device DD. This predefined time is provided beforehand to the remote device, for example during the implementation of the remote device's operating system or following a prior configuration step of the device.

[0104] According to another embodiment, the occasional intervention channel C2 is configured to be deactivated after a period of inactivity, that is, after a specified time during which no messages have passed through the occasional intervention channel. Similarly, the value of this inactivity period for the second channel is entered during the initialization of the remote device or prior to the implementation of the processes.

[0105] According to another embodiment, the occasional intervention channel is configured to be deactivated after a time specified by the management server. This could, for example, be a connection time passed as a parameter when the request to establish the occasional intervention channel C2 is made, or when a specific command is issued, or even via a command to close the occasional intervention channel sent by the management server SG after a given time, this time being able to be specified beforehand at the server or application level from the management server, which initiated the request to establish the occasional intervention channel.

[0106] According to yet another embodiment, the occasional invention channel is deactivated by the remote device after receiving a deactivation command issued by the server.

[0107] As an example from the appendix, a deactivation prompt by the remote device for the MQTT channel can take the following form in Python®: client.loop_stop() client.disconnect()

[0108] In conclusion, the invention advantageously allows, according to the embodiment described here, an intervention technician or any other person in the trade to intervene on a remote device via the communication channel most suited to the urgency of the situation.

[0109] According to this embodiment, the technician, or any other person skilled in the art, can use the management and communication processes iteratively each time that a particular intervention or management action requires, in his opinion, a communication channel with a lower latency than that of the current management channel.

[0110] The methods described here in the context of network equipment can also be applied generally to any connected object that one seeks to manage remotely. Appendix

[0111] Example of commands, in Python® language, that can be implemented by the MQTT client at the remote device level or at the management server level: import paho.mqtt.client as mqtt # Callback for connection def on_connect(client, userdata, flags, rc): print("Connected with the result code: " + str(rc)) # To subscribe to a topic after client login, `subscribe("example / topic")` # Callback for receiving messages def on_message(client, userdata, msg): print(f"Message received on {msg.topic}: {msg.payload.decode()}") # Create an MQTT client client = mqtt.Client() # Define callbacks client.on_connect = on_connect client.on_message = on_message # Authentication information username = "your_username" password = "your_password" # Connecting to the broker with client authentication. `client.usemame_pw_set(username, password)` `client.connect("broker.hivemq.com", 1883, 60)` # Replace with your broker's address # Loop to process client messages.loop_start() # Post a message on a topic client.publish("example / topic", "Hello, MQTT!") # Keep the script running import time thne.sleep(lO) # Disconnect client.loop_stop() client.disconnect()

Claims

Demands

1. Method for managing a remote device (RD), implemented by a management server (MS) configured to manage said remote device via a current management channel (C1) established with the remote device, said method comprising: - a step of sending (E401), to the remote device, via said management channel, a command to establish an occasional intervention channel (C2) having a latency lower than that of the management channel, - following the establishment of said occasional intervention channel, the sending (E405) of at least one management command to the remote device via said occasional intervention channel.

2. The management method according to claim 1 further comprises a step of detecting a given event triggering the sending, to the remote device, via said management channel, of the command to establish the occasional intervention channel.

3. A management method according to any one of the preceding claims further comprising a step of sending a command to deactivate the occasional intervention channel to the remote device.

4. A communication method, implemented by a remote device communicating with a management server via a current management channel, said method comprising: - a receiving step (E402), from said management server via said current management channel, of a command to establish an occasional intervention channel having a latency lower than that of the management channel, - following the establishment of the intervention channel (E403), a receiving step of at least one management command from the management server via the intervention channel.

5. A communication method according to claim 4 wherein the establishment of the occasional intervention channel is conditioned by an authentication of the establishment command received (E401) from the management server.

6. A communication method according to claims 4 or 5 further comprising a channel deactivation step occasional intervention after a known period of time from the remote device.

7. A communication method according to claims 4 or 5 further comprising a step of deactivating the occasional intervention channel after a given period of inactivity of said occasional intervention channel.

8. A communication method according to claims 4 or 5 further comprising a step of deactivating the occasional intervention channel upon receipt of a command from the server.

9. A method according to any one of the preceding claims wherein the occasional intervention channel conforms to the MQTT (Message Queuing Telemetry Transport) protocol.

10. A method according to any one of the preceding claims wherein the current management channel conforms to the TR-069 (Technical Report) protocol.

11. Management server (SG) configured to manage a remote device (DD) via a current management channel (Cl) established with the remote device, said management server comprising: - a sending module (MES) configured to send to the remote device, via said management channel, an establishment command, of an occasional intervention channel (C2) having a latency lower than that of the management channel, - a management module (MGS) configured to, following the establishment of said occasional intervention channel, send at least one management command to the remote device via said occasional intervention channel.

12. A remote device (RD) capable of communicating with a management server via a regular management channel, said remote device comprising: - a receiving module (RMD), configured to receive, from said management server via said regular management channel, a command to establish a temporary intervention channel with a latency lower than that of the management channel, - a receiving module (MGD), configured to, following the establishment of the temporary intervention channel, receive

13. at least one management command from the management server via the intervention channel. Communication system comprising: - a management server according to claim 11, - a remote device according to claim 12.