## 4 M2M Communication
### Extensible Messaging and Presence Protocol (XMPP)  
XMPP has been developed to enable message oriented communication services applicable in the Internet context on top of TCP/IP. The XMPP communication architecture is based on distributed client-server model; however, also client-to-client (peer to peer) communication is enabled. The core services of XMPP includes support for presence information, secure messaging (TLS), overlay communication over IP, near real-time messaging, authentication, contact list management, and service discovery. Each XMPP client has an account hosted by a XMPP server, and the client can be addressesby unique Jabber ID (JID). XMPP JID contains three parts: user, domain and resource as shown in Table 4, RFC 6122/RFC3921 [118]. In XMPP, network domain-part of JID must be a fully qualified domain name or IP address. Each domain presents one logical groups with one user account database. Each domain may present own user account policies. The device owner is usually considered to be also a user of the M2M domain and an owner of at least one XMPP user id. All devices share same user id (local-part and domain-part) with their owner. Separation of devices is done by examining the resource part of JID. A client connects to the server to send and receive messages, the servers routes messages to the others enabling client-to-client communications over multiple servers, Figure 9. The procedure for M2M client establishing connection with the XMPP server is shown in Figure 10. Discovery can be done directly using a domain part as a server address or discovering server address with SRV lookup from DNS. All clients connect to only their own server specified by JID. Connections are persistent XML streams over TCP and optionally encrypted by Transport Layer Security (TLS) layer. Encryption of TCP stream is strongly recommended, but not required. An administrator of a domain may specify that encryption is mandatory and it is up to administrator or designer to choose whether TLS certificates should be checked. Most client libraries accepts self-signed certificates, this should be taken into account when considering security aspects of client-to-server connections. The availability of each client can be detected with the aid of presence messages. Presence information is shared only with XMPP users that are in the roster/address book of the client sending the presence information. Server to server connection is an XML stream over a TCP connection, similar to client to server connections. The most important difference is that server to server connections are not authenticated because they happen in between different domains that do not share a common user database. XMPP servers may use XMPP Dial back (XEP-0220), to verify the domain of the connecting server. The domain administrator may require stronger identification verification by using TLS certificates and Simple Authentication and Security Layer (SASL). When M2M clients located in different domains would like to exchange messages, routing of messages will be done by the domain specific servers, see Figure 11. Then, a communication link between servers of the domains is negotiated to enable messaging between the referred M2M clients. The capability for handing presence information has been developed for XMPP. The availability of each client can be detected with the aid of presence messages. XMPP offers mechanisms to select how, when and to whom presence information is shared to, as described in requirements listed in [119]. For example, presence can be shared only with contacts that are in roster/address book of client sending the presence information. The related presence information (JIDs) is critical information in the system and it is stored in the roster database. Another useful feature is the publish-subscribe model (XEP0060), which can be used by XMPP entities to subscribe information of the presence of other entities, and receive notifications accordingly.