MD-ECI (Mobility and Disconnection Support for the Event-Based Communication Interface)



The MD-ECI (Mobility and Disconnection Support for the Event-Based Communication Interface) is an extension of the ECI publish/subscribe system. It handles the mobility of devices, implementing a solution for Mobility Management at the application layer using the SIP protocol. In addition, the system also implements mechanisms for handling disconnection of event producers and consumers, and also firewall and NAT traversal techniques, allowing the publish/subscribe system to be used on the Internet, and not only on local networks.


The existing work on the literature about mobility in publish/subscribe systems such as, (Caporuscio, Carzaniga et al., 2003), (Cugola, Di Nitto et al., 2001), (Fiege, Gartner et al., 2003), (Mühl, Ulbrich et al., 2004), (Zeidler e Fiege, 2003) consider the mobility of a device, used by a user registered on the system, as a sequence of move-in and move-out operations between different event brokers which belong to a distributed publish/subscribe infrastructure, established at different network locations. Thus, the existing work has its main focus of research on algorithms for the synchronization of subscriptions and routing of notifications between different event brokers on which the device (executing an event producer or consumer) attaches or detaches while moving. On the other hand, on the present work, the mobility of a device is interpreted as a change (predicted or not) of is IP address, considering that the device keeps registered on the same event broker.


Figure 1 – Mobility on the MD-ECI.

This kind of mobility support is interesting because there is no need for the device to predict network changes and at the same time, enabling it to have mobility awareness. This type of mobility does not prohibit the MD-ECI, in future work, to be extended to or incorporated at, a distributed publish/subscribe architecture with many event brokers interconnected by an overlay network.

The M-SIP-UserAgent API. The MD-ECI uses a mobility management solution on the application layer with the SIP protocol. This solution was developed as an API called MSIPUA (Mobility SIP User Agent). With this API the MD-ECI can provide support for the mobility of event consumers and producers. The M-SIPUA API is coupled with the ECIAgent and ECIBroker, allowing them to establish SIP communication sessions with each other.



Figure 2 – M-SIP-UserAgent use by ECIAgent and ECIBroker


When instancing ECIAgent or ECIBroker, the user URI which is using the system must be informed (on the ECIBroker a URI of a user representing the event broker must be created, such as sip:broker@domain). The M-SIP-UserAgent API so sends a REGISTER message to the SIP Server at the user´s domestic network (which must be configurable) with the mapping of the user´s URI to the real network address of the User Agent he is using.



Figure 3 – Registering on the SIP Server of the user´s domestic network

The URI of the event broker (the ECIBroker instance) also must be configured on the ECIAgent, because when the ECIAgent is initialized it has to establish a SIP session with the M-SIP-UserAgent of the ECIBroker, session which will be kept during the whole lifetime of both entities (see step 1 on Figure 4).



Figure 4 – Session establishment between ECIAgent and ECIBroker


Established the session between the ECIAgent and ECIBroker (see step 2 on Figure 4), the ECIBroker stores the session on the ECI Session Manager (described below), in order to use it when necessary. The ECIAgent only needs to keep the single established session with the ECIBroker. Both sides of the communication can then use the data contained in the SDP descriptions of the sessions to send and receive data, such as subscriptions, notifications or any other type of message (see step 3 of Figure 4).


SIP Sessions management and use. On the original ECI, the user was identified by its IP address and port. On the MD-EDI, the ECIBroker uses the user´s location-independent identifier (for instance, the URI). The SIP Sessions are used as the logical entity for organizing and managing the interaction with the users.



Figure 5 – SIP Sessions management on the ECIBroker

The ECI Session Manager, is the component of the ECIBroker responsible for managing all sessions established with the ECIAgents. When a user using an ECIAgent establishes a session with the ECIBroker´s M-SIP-UserAgent, the ECIBroker stores this session on the ECI Session Manager (on the ECIAgent it is stored just one session, the one established with the ECIBroker). The Figure 5 shows the ECIBroker´s ECI Session Manager with many sessions for different users.


One of ECI´s main logical entities is the Subscription, which contains the expression of interest (i.e. a filter over the content) of events which the client wishes to receive. On the original ECI, a Subscription was identified by the IP address and port of the device that sent that Subscription, and these data was used for the sending of notifications. With the use of the M-SIP-UserAgent as the Mobility Management solution, each Subscription is identified by the URI of the user it belongs. Thus, for sending a notification to the user, the ECIBroker uses the URI contained in the Subscription to find the user´s SIP Session, and to send the notifications to the real network address contained inside the SDP description which the user has specified on the session.


The Figure 6 shows an example of a Subscription identified by the user´s URI ( The subject “StockExchange” indicates a hypothetical subject about events related to data of the Stock Exchange. The subscription also contains a hypothetical expression of interest “(Stock == PETR4) and (Price < 25)”, on which is specified that the user is interested on events with the property “StockName” equals to “PETR4” and the property “Price” with value lower than 25.



Figure 6 – Subscription identified by the user´s URI


Terminal Mobility. The M-SIP-UserAgent API provides support for terminal mobility for the MD-ECI. The Figure 7 shows how this functionality is implemented using the SIP protocol. The RegistrationManager has a thread which monitors the device´s current IP address. When this module detects the change of the device´s address (possibly because of mobility), is dispatches the sending of a new REGISTER message to the Registrar on the user´s domestic network, in order to allow the user´s device to be located on its new network address (step 1 on Figure 7). Any existing active SIP Session is updated by the sending of a REINVITE message to the other participant (step 2 on Figure 7). Thus, the SIP and SDP data, together with media data are updated with the new IP address on both User Agents which are participants of the session. When the REINVITE is processed, both the SIP Communication Status and the Media Communication Status states are defined as CONNECTED, because it is assumed that after a session renegotiation, both participants have their media descriptions compatible with the IP addresses and ports on which they desire to change data (step 3 on Figure 7). Finally, both session participants can restore the normal exchange of data (step 4 on Figure 7).



Figure 7 – Session restore after the mobility of a publisher/subscriber


Disconnection Support. As all steps involved on the session renegotiation caused by mobility require some time, on which ECI event notifications cannot be delivered to the consumer, the service must also provide support to the temporary disconnection of clients (event publishers and subscribers). To handle disconnection, first it is necessary to define how this state is detected by the system´s components.


As explained in the M-SIP-UserAgent page, the Media Communication State (Remote Media State) contained inside the SIP Session, indicates whether the other participant can be contacted on the addresses it has specified on his SDP description. For example, a communication participant A, to send data to other participant B, gets the remote SDP description from the SIP Session (Remote SDP field), which contains the address on which the participant B is waiting to receive data. If the communication protocol to be used was TCP (which offers reliable data delivery), an exception thrown by the Socket during the sending of data would mean that the participant B is disconnected, because it cannot receive data on the address specified on the session description. However, for publish/subscribe systems the use of the TCP protocol would considerably increase the overhead on the communication between system´s components. The UDP protocol does not provide reliable data delivery, so in order to combine performance with reliability, an implementation of a reliable UDP protocol has been adapted for the MD-ECI (an for the MoCA) called RUDP (Reliable UDP) (Stevens e Narten, 1990; Pitt, 2006), this API can be found here.


This protocol gives to each datagram packet sent by a RUDP client a sequence number, which is used by the receiver (RUDP server) to detect an eventual loss of some UDP packet. The RUDP server sends an acknowledgement (ACK) packet for each packet it receives back to the client. The client has an expiration time to wait for ACKs before a retry on the sending of the packet. This expiration time is periodically tuned by a roundtrip time, a timer that calculates the time a packet takes to be transmitted and to be returned to the client as an ACK. Each sent and successfully confirmed packed is used by the roundtrip timer to define ACK the expiration time.


When a packet is sent and the client does not receive an ACK packet on time, if the maximum number of retries has not been achieved, the expiration time is exponentially increased (with a configurable exponential factor) to avoid overcharging the network with packets. If the maximum number of sending retries is achieved and a no ACK packet is received, an exception is thrown to the upper software layer which is using the RUDP protocol. Specifically to this work, when the publish/subscribe system tries to send data through the network with a RUDP client and catches a sending exception, this means that the receiver of the message cannot be contacted and, thus, its Media State will be set as DISCONNECTED.



Figure 8 – Disconnection detection by the ECIAgent and ECIBroker


It is assumed that the event broker (ECIBroker) is always connected, on a node on the fixed network, when an ECIAgent can´t send data to the ECIBroker, the ECIAgent implicitly infers that there is some problem with it own connectivity. Therefore, it is defined that the ECIAgent can detect is own disconnection when the Remote Media Status of its SIP Session with the ECIBroker changes to DISCONNECTED.

The ECIAgent contains an auxiliary indicator (just for organizing purposes) which indicates its connectivity state with the ECIBroker, called ECIAgent Status. This indicator is actually always equal to the current state of the Remote Media Status indicator of the established session with the ECIBroker.


The ECIBroker can detect the disconnection of an ECIAgent when some data can’t be sent to the ECIAgent. When this happens the ECIBroker changes the Remote Media Status of the session with the correspondent ECIAgent to DISCONNECTED). The ECIBroker also contains an auxiliary state indicator for each user, which indicates the state of the ECIAgent´s connectivity with the system, called User Status. Therefore, for the ECIBroker, a session with the Remote Media State indicator set to DISCONNECTED represents that the user (session owner) is disconnected from the system (i.e. cannot be contacted by the system) and represent this situation setting the User Status auxiliary indicator do DISCONNECTED. On the other side, a session with the Remote Media State set as CONNECTED indicates that the user is connected and can be contated, consequently, the User Status indicator of this user will be defined as CONNECTED.


When a new session is established between the an ECIAgent and a ECIBroker, the Remote Media State inside the Session is defined as CONNECTED for both sides of the communication, since it is assumed that on the conclusion of a Session renegotiation both participants are ready to exchange data through the addresses specified on their Session´s SDP descriptions. This means that when a Session is updated, both participants become immediately reconnected (until some interruption occurs on the data exchange, which would define the state of the side which cannot be contacted as DISCONNECTED).


Subscriptions Expiration Time and Query of Subscriptions by the Client

The subscriptions are kept on the ECIBroker for some time, event for disconnected users. They contain an attribute which specified the limit of time they remain valid.



Figure 9 – Subscription with a defined expiration time


When the specified time of a subscription expires, the subscription is removed from the ECIBroker. This verification doesn’t need to be executed with a high periodicity, because the system doesn’t generate notifications for expired subscriptions. Therefore, the ECIBroker performs this verification every time it does the matching of events with subscriptions. If there are queued notifications for a disconnected user, correspondent to a cancelled subscription, they are not removed but are delivered normally when the user reconnects, because they have been generated when the subscription was still valid.


On a mobility scenario, a device could be disconnected because it is not on the range of the wireless network or because it has been turned off. On the case of the device being turned off, an ECIAgent running on it would lose all its state (e.g. awareness of subscriptions it has on the ECIBroker), so it would be necessary some persistent storage of subscriptions on the ECIAgent. A mechanism that resolves such question is the capacity of the ECIAgent to query the ECIBroker when needed (e.g. on initialization) to get the list of existing subscriptions.


Persistent Notifications.  When a user is disconnected from the system and a published event matches with the a user´s subscription, or when the user is still not defined as disconnected, but it is not possible to deliver the generated notification (on this case the user is defined as disconnected when the sending of the notification fails), the notification is stored to be delivered when the user reconnects. This storage is performed on queues inside the ECIBroker, indexed by the users´ URI. The ECIBroker´s configuration properties allow the definition of notifications queues maximum size.



The Agent API can be found here and the Broker API can be found here.



The MSIPUA API can be found here.


Deploying and Configuring

A sample configuration file for the Agent API which can be customized for use can be found here.


A sample configuration file for the Broker API which can be customized for use can be found here.


Using MD-ECI

A test application which can be used to illustrate the MDECI´s use and functionality can be found here.


The MDECI´s javadoc can be found here.



CAPORUSCIO, M. et al. Design and Evaluation of a Support Service for Mobile, Wireless Publish/Subscribe Applications. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING [S.I.], p. 1059-1071,  2003.


CUGOLA, G. et al. The JEDI Event-Based Infrastructure and Its Application to the Development of the OPSS WFMS. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING [S.I.], p. 827-850,  2001.


FIEGE, L. et al. Supporting Mobility in Content-Based Publish/Subscribe Middleware. LECTURE NOTES IN COMPUTER SCIENCE [S.I.], p. 103-122,  2003.


MÜHL, G. et al. Disseminating Information to Mobile Clients Using Publish-Subscribe. IEEE INTERNET COMPUTING [S.I.], p. 46-53,  2004.


PITT, E. Fundamental Networking in Java. Springer, 2006.


STEVENS, W.; NARTEN, T. Unix network programming. ACM SIGCOMM Computer Communication Review [S.I.], v. 20, n. 2, p. 8-9,  1990.


ZEIDLER, A.; FIEGE, L. Mobility support with REBECA. 2003. p.354-360.