TECHNICAL FIELD

Embodiments presented herein relate to M2M communications, and particularly to address allocation for M2M communications. BACKGROUND

In general terms, machine to machine (M2M) communications refers to technologies that allow both wireless and wired systems to communicate with other devices of the same ability. In M2M communications an M2M device is arranged to capture an event (such as meter reading, inventory level, etc.), which is relayed through a network (wireless, wired or hybrid) to

an application server (hosting and executing for example a computer software program), that is arranged to translate the data of the captured event into meaningful information (for example, modification of temperature parameter relating to the read meter, indication of items needing to be restocked). Such communications was originally accomplished by having a remote network of machines relay information back to a central hub for analysis, which information would then be rerouted into a system like a personal computer.

However, modern M2M communications has expanded beyond a one-to-one connection and changed into a system of networks in which data is transmitted. The expansion of Internet Protocol (IP) networks has allowed for efficient M2M communications whilst lessened the amount of power and time necessary for information to be communicated between the M2M devices. Today each M2M device has it own physical address in the network. Due to the increasing number of connected M2M devices, an expansion of address space is needed. However, identities such as Internet protocol version 4 (IPv4) addresses used for M2M communications is a scarce resource. Lack of such identities is one of the challenges to handle the increased number of connected M2M devices and the communication to and from the M2M devices.

Some issues relating to the limited number of IPv4 addresses may be addressed by using so-called Network Address Translation, NAT..

In computer networking NAT is the process of modifying IP

address information in IP packet headers while in transit across a

traffic routing device. However, many of today's M2M services are server initiated e.g., meter readings. One drawback with NAT is that the application server no longer can initiate communication to the M2M devices since the address of a M2M device is frequently changed by the NAT. This leads to frequent so-called keep alive signalling and device registration update. Keep alive signalling is an attempt to maintain the server to client communication. Additionally, NAT may only be used to reduce the severity of the issues relating to the limited number of IPv4 addresses (and hence not to

completely resolve these issues).

The introduction of Internet protocol version 6 (IPv6) requires that a wide deployment of networks, terminals and M2M devices are updated. The introduction of IPv6 may thus require substantial infrastructure resources. The introduction of IPv6 may be used to increase the available address space, but the use of IPv6 will consume a considerable part of the scarce radio resources to cater for the IPv6 overhead.

Hence, there is still a need for an improved address allocation for M2M communications.

SUMMARY

An object of embodiments herein is to provide improved address allocation for M2M communications.

The inventors of the enclosed embodiments have realized that address allocation for M2M communications can be based on the fact that the communication behaviour and characteristics of M2M communications differ from traditional human initiated device communication; the M2M

communications can in many cases be predicted and therefore scheduled.

A particular object is therefore to provide improved address allocation for M2M communications based on a time frame allocation. According to a first aspect there is presented a method for address allocation in machine-to-machine, M2M, communications between a server device and a client device. The method is performed by an M2M server node. The method comprises receiving a request from one of a client device and a server device, the request pertaining to M2M communications between the client device and the server device. The method comprises allocating a device address from a set of allowable device addresses to the client device, the set of allowable device addresses being a strict subset of all available device addresses. The method comprises allocating a time frame associated with an Internet Protocol, IP, resource to be used for the M2M communications between the client device and the server device and during which time frame the client device is enabled to communicate with the server device. The method comprises providing the client device and the server device with information regarding the address allocation of the client device and the time frame allocation of the IP resource, thereby enabling the server device and the client device to communicate during the time frame.

Advantageously this enables address allocation suitable for an increasing number of M2M devices.

Advantageously this allows application servers to use standard addressing for all connected M2M devices. Advantageously this results in limited keep alive signalling and overhead traffic in the network and thus reduces the network resources required for efficient M2M communications.

Advantageously this does not require any changes in existing network infrastructures. According to a second aspect there is presented a method for address allocation in machine-to-machine, M2M, communications between a server device and a client device. The method is performed by the server device. The method comprises receiving information regarding device address allocation of the client device and a time frame allocation of an Internet Protocol, IP, resource. The method comprises communicating with the client device during the time frame. The device address has been allocated to the client device from a set of allowable device addresses, the set of allowable device addresses being a strict subset of all available device addresses. The time frame is associated with the IP resource and has been allocated to be used for M2M communications between the client device and the server device and during which time frame the client device is enabled to communicate with the server device.

According to a third aspect there is presented a method for address allocation in machine-to-machine, M2M, communications between a server device and a client device. The method is performed by the client device. The method comprises receiving information regarding device address allocation of the client device and a time frame allocation of an Internet Protocol, IP, resource. The method comprises communicating with the server device during the time frame. The device address has been allocated to the client device from a set of allowable device addresses, the set of allowable device addresses being a strict subset of all available device addresses. The time frame is associated with the IP resource and has been allocated to be used for M2M

communications between the client device and the server device and during which time frame the client device is enabled to communicate with the server device.

According to a fourth aspect there is presented machine-to-machine, M2M, server node for address allocation in M2M communications between a server device and a client device. The M2M server node comprises an input/output, I/O, interface arranged to receive a request from one of a client device and a server device, the request pertaining to M2M communications between the client device and the server device. The M2M server node comprises a processing unit arranged to allocate a device address from a set of allowable device addresses to the client device, the set of allowable device addresses being a strict subset of all available device addresses. The processing unit is further arranged to allocate a time frame associated with an Internet

Protocol, IP, resource to be used for the M2M communications between the client device and the server device and during which time frame the client device is enabled to communicate with the server device. The I/O interface is further arranged to provide the client device and the server device with information regarding the address allocation of the client device and the time frame allocation of the IP resource, thereby enabling the server device and the client device to communicate during the time frame.

According to a fifth aspect there is presented a server device 3 for address allocation in machine-to-machine, M2M, communications between a server device and a client device. The server device comprises an input/output, I/O, interface arranged to receive information regarding device address allocation of the client device and a time frame allocation of an Internet Protocol, IP, resource. The I/O interface is further arranged to communicate with the client device during the time frame. The device address has been allocated to the client device from a set of allowable device addresses, the set of allowable device addresses being a strict subset of all available device addresses. The time frame is associated with the IP resource and has been allocated to be used for M2M communications between the client device and the server device and during which time frame the client device is enabled to

communicate with the server device. According to a sixth aspect there is presented a client device for address allocation in machine-to-machine, M2M, communications between a server device and a client device. The client device comprises a receiver arranged to receive information regarding device address allocation of the client device and a time frame allocation of an Internet Protocol, IP, resource. The client device comprises a transmitter which in combination with the receiver is arranged to communicate with the server device during the time frame. The device address has been allocated to the client device from a set of allowable device addresses, the set of allowable device addresses being a strict subset of all available device addresses. The time frame is associated with the IP resource and has been allocated to be used for M2M communications between the client device and the server device and during which time frame the client device is enabled to communicate with the server device.

According to a seventh aspect there is presented a computer program for address allocation for machine-to-machine, M2M, communications between a server device and a client device, the computer program comprising computer program code which, when run on an M2M server node, causes the M2M server node to perform a method according to the first aspect.

According to a eight aspect there is presented a computer program for address allocation for machine-to-machine, M2M, communications between a server device and a client device, the computer program comprising computer program code which, when run on a server device, causes the server device to perform a method according to the second aspect.

According to a ninth aspect there is presented a computer program for address allocation for machine-to-machine, M2M, communications between a server device and a client device, the computer program comprising computer program code which, when run on a client device, causes the client device to perform a method according to the third aspect.

According to a tenth aspect there is presented a computer program product comprising at least one computer program according to at least one of the seventh, eight, or ninth aspect and a computer readable means on which the at least one computer program is stored. It is to be noted that any feature of the first, second, third, fourth, fifth, sixth, seventh, eight, ninth and/or tenth aspect may be applied to any other aspect, wherever appropriate. Likewise, any advantage of the first aspect may equally apply to the second, third, fourth, fifth, sixth, seventh, eight, ninth and/or tenth aspect, respectively, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated. BRIEF DESCRIPTION OF THE DRAWINGS

The invention is now described, by way of example, with reference to the accompanying drawings, in which:

Fig l is a schematic diagram illustrating an M2M based communication network where embodiments presented herein may be applied; Fig 2 is a schematic diagram showing functional modules of an M2M server node;

Fig 3 is a schematic diagram showing functional modules of a server device;

Fig 4 is a schematic diagram showing functional modules of a client device;

Fig 5 shows one example of a computer program product comprising computer readable means; and

Figs 6-11 are flowcharts of methods according to embodiments.

DETAILED DESCRIPTION

The present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. The present disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosed concepts to those skilled in the art. Like numbers refer to like elements throughout the description.

Fig l is a schematic diagram illustrating a machine-to-machine (M2M) based communication network 1 where embodiments presented herein may be applied. The communications network 1 comprises a number of client devices 4a, 4b, ..., 4η. The client devices 4a-n are arranged to communicate with a server device 3. The server device 3 is connected to an Internet network 4. In order to do so the client devices 4a-n are arranged to access a mobile radio access network 5. The mobile radio access network 5 is interconnected with the Internet network 4 via an M2M server node 2. Typical applications where M2M communications may be used include applications in the

manufacturing industry, applications for building automation (such as for heating, ventilation, and air conditioning), meter readings, traffic lights, digital billboards, telematics, in-vehicle applications, and monitoring systems. Typical examples of client devices 4a-n will be provided below. Also typical examples of server devices 3 and possible implementations of the M2M server node 2 will be provided below.

M2M communication is to a large extent possible to schedule. Scheduling of the M2M communication enables scheduling of identities. The embodiments disclosed herein relate to address allocation for M2M communications. In order to obtain address allocation for M2M communications there is provided an M2M server node 2, a method performed in the M2M server node 2, a server device 3, a method performed in the server device 3, a client device 4a-n, a method performed in the client device 4a-n, computer programs comprising code, for example in the form of a computer program product, that when run on at least one of the M2M server node 2, the server device 3, and the client device 4a-n causes at least one of the M2M server node 2, the server device 3, and the client device 4a-n to perform at least one of the methods. Fig 2 schematically illustrates, in terms of a number of functional modules, the components of an M2M server node 2. A processing unit 6 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate arrays (FPGA) etc., capable of executing software instructions stored in a computer program product 18 (as in Fig 5), e.g. in the form of a memory 8. Thus the processing unit 6 is thereby arranged to execute methods as herein disclosed. The memory 6 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The M2M server node 2 further comprises an input/output (I/O) interface 7 arranged to receive and to transmit signals to other devices, such as the server device 3 and the client device 4. The processing unit 6 controls the general operation of the M2M server node 2, e.g. by sending control signals to the I/O interface 7 and receiving reports from the I/O interface 7 of its operation. Other components, as well as the related functionality, of the M2M server node 2 are omitted in order not to obscure the concepts presented herein. According to one embodiment the M2M server node 2 is implemented as an independent device. According to another embodiment the M2M server node 2 is part of a Gateway General Packet Radio Service Support Node, GGSN. According to another embodiment the M2M server node 2 is part of a Session Border Gateway, SBG. According to another embodiment the M2M server node 2 is part of a router. The functional modules may be implemented as a

programmable logic array (PLA) or in a hardware chip set.

Fig 3 schematically illustrates, in terms of a number of functional modules, the components of a server device 3. A processing unit 9 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate arrays (FPGA) etc., capable of executing software instructions stored in a computer program product 18 (as in Fig 5), e.g. in the form of a memory 11. Thus the processing unit 9 is thereby arranged to execute methods as herein disclosed. The memory n may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The server device 3 further comprises an input/output (I/O) interface 10 arranged to receive and to transmit signals to other devices, such as the M2M server node 2 and the client device 4. The processing unit 9 controls the general operation of the server device 3, e.g. by sending control signals to the I/O interface 10 and receiving reports from the I/O interface 10 of its operation. Other

components, as well as the related functionality, of the server device 3 are omitted in order not to obscure the concepts presented herein.

Fig 4 schematically illustrates, in terms of a number of functional modules, the components of a client device 4. A processing unit 12 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate arrays (FPGA) etc., capable of executing software instructions stored in a computer program product 18 (as in Fig 5), e.g. in the form of a memory 14. Thus the processing unit 12 is thereby arranged to execute methods as herein disclosed. The memory 14 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The client device 4 may further comprise an input/output (I/O) interface 13 for receiving and providing information to a user interface. The client device 4 also comprises one or more transmitters 17 and receivers 15, comprising analogue and digital components and a suitable number of antennae 16 for radio communication with the mobile radio access network 5. The processing unit 12 controls the general operation of the client device 4, e.g. by sending control signals to the transmitter 17 and/or receiver 15 and receiving reports from the transmitter 17 and/or receiver 15 of its operation. Other components, as well as the related functionality, of the client device 4 are omitted in order not to obscure the concepts presented herein. According to an embodiment the client device 4, 4a, 4b, 4n is a connected communications device, such as a maintenance device, a sensor device, or a utility meter.

Figs 6 and 7 are flow charts illustrating embodiments of methods for address allocation in machine-to-machine, M2M, communications between a server device 3 and a client device 4, 4a, 4b, 4η as performed by an M2M server node 2. Figs 8 and 9 are flow charts illustrating embodiments of methods for address allocation in machine-to-machine, M2M, communications between a server device 3 and a client device 4, 4a, 4b, 4η as performed by the server device 3. Figs 10 and 11 are flow charts illustrating embodiments of methods for address allocation in machine-to-machine, M2M, communications between a server device 3 and a client device 4, 4a, 4b, 4η as performed by the client device 4, 4a, 4b, 4η. The methods are advantageously provided as computer programs 19a, 19b, 19c. Fig 5 shows one example of a computer program product 18 comprising computer readable means 20. On this computer readable means 20, a least one computer program i9a-c can be stored, which computer program I9a-c can cause the processing units 6, 9, 12 and thereto operatively coupled entities and devices, such as the memories 8, 11, 14, the I/O interfaces 7, 19, 13, the transmitter 17, the receiver 15 and/or the antennae 16 to execute methods according to embodiments described herein. In the example of Fig 5, the computer program product 18 is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product could also be embodied as a memory, such as a random access memory (RAM), a readonly memory (ROM), an erasable programmable read-only memory

(EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory. Thus, while the computer programs i9a-c are here schematically shown as a track on the depicted optical disk, the computer programs i9a-c can be stored in any way which is suitable for the computer program product 18.

A method for address allocation in machine-to-machine, M2M,

communications between a server device 3 and a client device 4, 4a, 4b, 4η, comprises receiving, in a step S2 and by the I/O interface 7 of the M2M server node 2, a request from one of the client device 4, 4a, 4b, 4η and the server device 3. The request pertains to M2M communications between the client device 4, 4a, 4b, 4η and the server device 3. This step may thus represent an initiation of service phase of a temporary addressing scheme; the client device 4, 4a, 4b, 4η may need to register to the M2M server node 2 before any M2M communications between the server device 3 and the client device 4, 4a, 4b, 4η is established. During this registration phase the client device 4, 4a, 4b, 4η may be required to provide an identity of the client device 4, 4a, 4b, 4η to the M2M server node 2. The M2M server node 2 may be arranged to store the identity in the memory 8. As will be disclosed next with reference to step S4 an address will be allocated to the client device 4, 4a, 4b, 4η. This address may be regarded as a temporary identity of the client device As noted above, the inventors of the enclosed embodiments have realized that since communication behaviour and characteristics of M2M communications differ from traditional human initiated device communication, the M2M communications can in many cases be predicted and therefore scheduled. The M2M communication can be scheduled in time, which enables sharing of addresses of the client devices 4, 4a, 4b, 4η.

The M2M server node 2 further determines an address to be used by the client device 4, 4a, 4b, 4η during M2M, communications with the server device 3. The processing unit 6 of the M2M server node 2 is therefore further arranged to, in a step S4, allocate a device address from a set of allowable device addresses to the client device 4a, 4b, 4η. This step may thus represent a first allocation phase of the temporary addressing scheme. The set of allowable device addresses is a strict subset of all available device addresses. That is, denote the number of all available device addresses to be N; and denote the number of allowable device addresses to be M. Then M < N.

According to embodiments M is several orders of magnitude smaller than N. The subset of all available device addresses may correspond to a particular type of device addresses. According to a first example the particular type of device addresses is Internet protocol version 4, IPv4, addresses. According to a second example the particular type of device addresses is Internet protocol version 6, IPv6, addresses. According to a third example the particular type of device addresses is International Mobile Subscriber Identity, IMSI, addresses. Shared IMSI addresses may require the use of cloned subscriber identity module or subscriber identification module (SIM) identities.

According to a fourth example the particular type of device addresses is IPv6 over Low power Wireless Personal Area Networks, 6L0WPAN, addresses. According to a fifth example the particular type of device addresses is port numbers for IP communications.

The M2M server node 2 further determines a time slot to be used by the client device 4, 4a, 4b, 4η during M2M, communications with the server device 3. The processing unit 6 of the M2M server node 2 is therefore further arranged to, in a step S6, allocate a time frame associated with an Internet Protocol, IP, resource to be used for the M2M communications between the client device 4, 4a, 4b, 4η and the server device 3. This step may thus represent a second allocation phase of the temporary addressing scheme. The client device 4, 4a, 4b, 4η is enabled to communicate with the server device 3 only during the allocated time frame. The M2M server node 2 is thereby arranged to determine during what time intervals each client device 4, 4a, 4b, 4η is available for M2M communications. The allocated address is only to be used for M2M communication with the client device 4, 4a, 4b, 4η during the specific time frame. Hence the same device address may thereby be used by other client device during other time frames. This will keep the number M of needed allowable device addresses to be small in comparison to the number N of all available device addresses. The client devices 4, 4a, 4b, 4η are therefore arranged to enable and disable their IP context to be active only during the time frame allocated by the M2M server node 2.

There may be many ways of determining the length of the time frame to be allocated. Further, the length of the time frame to be allocated may depend on a number of factors and parameters. In general terms, the length may depend on the underlying application necessitating the M2M communication between the server device 3 and the client device 4, 4a, 4b, 4η. In its most basic form the M2M communication between the server device 3 and the client device 4, 4a, 4b, 4η could even relate to scheduling of CPU resources of the client device 4, 4a, 4b, 4η. For example, the length may be explicitly requested. The I/O interface 7 of the M2M server node 2 may therefore further be arranged to, in a step S2a, receive a request for a length of the time frame to be allocated. The M2M communications may relate to an

application. According to an embodiment one device of the client device 4a, 4b, 4η and the server device 3 has knowledge of communications logics of the application. According to this embodiment the request is in step S2a received from the one device having knowledge of the communications logics of the application. Further, the time frame to be allocated may be associated with frequency of occurrence; that is, with a parameter relating to how often the time frame is to be used for M2M communication between the server device 3 and the client device 4, 4a, 4b, 4η. The I/O interface 7 of the M2M server node 2 may therefore further be arranged to, in the step S2a, receive a frequency of occurrence of the communications between the client device 4, 4a, 4b, 4η and the server device 3. According to an embodiment the time frame is associated with periodically repeated instances of occurrence. In general terms the period may depend on the underlying application necessitating the M2M communication between the server device 3 and the client device 4, 4a, 4b, 4η. For example, the time frame may be repeated in the order of once every second, minute, hour or day. According to another embodiment the time frame is associated with a single instance of occurrence. This may represent a case where a large amount of payload data is to be transmitted. In general terms, however, this should still allow at least one of the server device 3 and the client device 4, 4a, 4b, 4η to request a time frame although the time frame can be allocated in advance. That is, also M2M communications which is of a one time occurrence character may still be allocated a repetitive time frame signalling structure so as to allow for a new time frame for M2M

communications between the server device 3 and the client device 4, 4a, 4b, 4η to be negotiated and determined.

Further, the time frame to be allocated may be associated with a point in time; that is, with a parameter relating to at which point in time a first occurrence of the M2M communication between the server device 3 and the client device 4, 4a, 4b, 4η is to take place. The I/O interface 7 of the M2M server node 2 may therefore further be arranged to, in the step S2a, receive a point in time for the communications between the client device 4, 4a, 4b, 4η and the server device 3.

The M2M server node 2 further communicates the determined address allocation and time frame allocation the client device 4, 4a, 4b, 4η and the server device 3. The I/O interface 7 of the M2M server node 2 is therefore further arranged to, in a step S8, provide the client device 4, 4a, 4b, 4η and the server device 3 with information regarding the address allocation of the client device 4, 4a, 4b, 4η and the time frame allocation of the IP resource. This implies that the server device 3 is made aware of when in time the server device 3 is scheduled to communicate with a specific client device 4, 4a, 4b, 4η. The server device 3 may additionally be provided with the identity of the client device 4, 4a, 4b, 4η as stored in the memory 8 of the M2M server node 2. The server device 3 may thereby associate the identity of the client device 4, 4a, 4b, 4η with the address allocated to the client device 4, 4a, 4b, 4η. However, the server device 3 needs to utilize only the allocated address in order to communicate with the client device 4, 4a, 4b, 4η. This step may thus represent a phase where the temporary addressing scheme is executed. The server device 3 and the client device 4, 4a, 4b, 4η are thereby enabled to communicate during the time frame. In other words, the server device 3 is thereby able to communicate with the client devices 4, 4a, 4b, 4η using standard addressing and by that avoid problems caused by NAT translating and port forwarding. As noted above the information is received by the server device 3. A method for address allocation in machine-to-machine, M2M, communications between a server device 3 and a client device 4, 4a, 4b, 4η, thus comprises receiving, in a step S24 and by the I/O interface 10 of the server device 3, receiving S24 the information regarding device address allocation of the client device 4, 4a, 4b, 4η and the time frame allocation of the Internet Protocol, IP, resource.

As noted above the information is also received by the client device 4, 4a, 4b, 4η. A method for address allocation in machine-to-machine, M2M, communications between a server device 3 and a client device 4, 4a, 4b, 4η, thus comprises receiving, in a step S34 and by the receiver 15 of the client device 4, 4a, 4b, 4η, the information regarding device address allocation of the client device 4, 4a, 4b, 4η and the time frame allocation of the Internet Protocol, IP, resource. As noted above the device address has been allocated to the client device 4, 4a, 4b, 4η from a set of allowable device addresses, the set of allowable device addresses being a strict subset of all available device addresses; and the time frame is associated with the IP resource and has been allocated to be used for M2M communications between the client device 4, 4a, 4b, 4η and the server device 3 and during which time frame the client device 4, 4a, 4b, 4η is enabled to communicate with the server device 3.

The server device 3 may then communicate with the client device 4, 4a, 4b, 4η. The I/O interface 10 of the server device 3 is therefore arranged to, in a step S26, communicate with the client device 4, 4a, 4b, 4η during the time frame. Likewise, the client device 4, 4a, 4b, 4η may then communicate with the server device 3. The transmitter 17 and the receiver 15 of the client device 4, 4a, 4b, 4η are therefore arranged to, in a step S36, communicate with the client device 4, 4a, 4b, 4η during the time frame.

According to an embodiment the M2M communications between the client device 4, 4a, 4b, 4η and the server device 3 is routed via the M2M server node 2. The I/O interface 10 of the server device 3 may therefore be arranged to communicate with the client device 4, 4a, 4b, 4η via the M2M server node 2. Likewise the transmitter 17 and the receiver 15 of the client device 4, 4a, 4b, 4η may be arranged to be arranged to communicate with the server device 3 via the M2M server node 2. The M2M server node 2 may thereby take the role of a network traffic controlling router. The M2M server node 2 may, for example, be arranged to check for delays or any other errors related to the communications between the client device 4, 4a, 4b, 4η and the server device

3. Particularly, the I/O interface 7 of the M2M server node 2 may be arranged to, in a step S10, receive an M2M communications message from one of the client device 4, 4a, 4b, 4η and the server device 3. The M2M communications message is addressed to the other of the client device 4, 4a, 4b, 4η and the server device 3. The processing unit 6 of the M2M server node 2 is then arranged to, in a step S12, determine a time of arrival of the M2M

communications message at a recipient of the M2M communications message, where the recipient is the other of the client device 4, 4a, 4b, 4η and the server device 3.

The I/O interface 7 of the M2M server node 2 is then arranged to, in a step S14, forward the received M2M communications message to the recipient only in a case the time of arrival occurs within the allocated time frame. The M2M server node 2 may thereby be arranged to detect delays in the network (i.e. in the Internet network 4 and/or in the mobile radio access network 5) and only forward those messages which still are able to arrive at the destination within the allocated time frame. This may prevent the M2M communications message from being transmitted to the wrong recipient and/or to a recipient at which the receiving means is arranged to be disabled outside the allocated time frame.

As noted above, the request received by the I/O interface 7 of the M2M server node 2 in step S2 is received from one of the client device 4, 4a, 4b, 4η and the server device 3. Alternatively or additionally a uniform resource identifier (URI) may be translated by a Domain Name System (DNS) which generates a queue for each client device 4, 4a, 4b, 4η whilst awaiting the l8

M2M server node 2 to enable each client device 4, 4a, 4b, 4η for M2M communications with the server device 3. In general terms, a URI is a string of characters which may be used to identify a name or a resource. Such identification enables interaction with representations of the resource over a network (typically the Internet) using specific protocols. In general terms, a DNS is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet.

According to one embodiment the I/O interface 10 of the server device 3 is therefore arranged to, in a step S22, transmit a request to the M2M server node 2 pertaining to M2M communications between the client device 4, 4a, 4b, 4η and the server device 3. The information received in step 24 may then be received in response to this request.

According to another embodiment the transmitter 17 of the client device 4 is arranged to, in a step S32, transmit a request to an M2M server node 2 pertaining to M2M communications between the client device 4, 4a, 4b, 4η and the server device 3. The information received in step 34 may then be received in response to this request.

The present disclosure has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the present disclosure, as defined by the appended patent claims.