ONEChat: An Efficient Group Chatting Platformfor Opportunistic Networks

Heming CuiColumbia UniversityNew York, NY, USA

hc2428@columbia.edu

Suman SrinivasanColumbia UniversityNew York, NY, USA

sumans@cs.columbia.edu

Henning SchulzrinneColumbia UniversityNew York, NY, USAhgs@cs.columbia.edu

Abstract—With the increasing deployment of wireless net-works, opportunistic networks are already becoming common-place due to the limitation of Internet access points. As a result,developing communication tools for opportunistic networks isnecessary. Due to the fact that existing applications can notsupport group chatting efficiently for opportunistic networks, wepropose ONEChat to address this issue. ONEChat uses messagemulticasting in order to support group chatting as well as reducebandwidth consumption, and requires neither configuration norinfrastructure. Quantitative analysis indicates that ONEChatis an efficient group collaborations platform for opportunisticnetworks.

Index Terms—Opportunistic Networks, Group Chatting,BonAHA, Real-time Text.

I. INTRODUCTION

Despite the increasing availability of wireless networks,many locations do not have high-speed Internet connectivity.However, most mobile devices, from laptops to smart phones,can participate in local (single-hop) wireless networks. Suchtransient local networks are called opportunistic networks.Opportunistic networks might be formed by students sitting ina class room, riders traveling in a subway car or the audiencein a seminar. In some opportunistic networks, participants cantalk to each other; even so, text-based chatting applicationscan enhance collaboration and augment oral communications.We aim to support group chatting in opportunistic networksrather than traditional client-server networks.

Group chatting application is a kind of collaborative soft-ware (also referred to as groupware) designed to help peopleinvolved in a common task to achieve their goals. Groupchatting application is also an IM (Instant Messaging) tool,which is a form of real-time and text-based communicationapplication between two or more people.

Unfortunately, most existing group chatting applicationswork as a client-server manner and can not function inopportunistic networks. Recently, there are a few chattingapplications proposed for opportunistic networks, but as faras we know, they can not support group chatting efficiently.More details about related work will be introduced in SectionII.

In order to offer an efficient group chatting applicationfor opportunistic networks, We have implemented ONEChat(ONE Chatting application standing for opportunistic net-works) with Java. Even though we mostly focus on single-

hop opportunistic networks, ONEChat functions in any net-work that offers multicast communication. Besides, ONEChatrequires neither configuration nor infrastructure. The imple-mentation is greatly simplified by building on the BonAHAframework [1] and Real-time Text [15].

The rest of the article is organized as follows. SectionII briefly introduces related work, Section III proposes theimplementation details of ONEChat, Section IV analyzes theperformance of ONEChat and some similar work, and SectionV gives a conclusion.

II. RELATED WORK

There are already many chatting applications on Internetlike ICQ [4], GTalk [5], MSN [6], AOL [7], Skype [8], andMultiChat [9]. However, few of them support chatting foropportunistic networks because of their client-server workingmanner.

Recently, some chatting applications for opportunistic net-works are proposed, and among which, iChat [10], Social-ized.NET [11], the Opportunistic Chat [12], and the DTN(Disruption Tolerant Networks) Jabber Proxy [13] are rep-resentative. However, they do not support group chattingefficiently for opportunistic networks due to the drawbacksbelow.

Both iChat and Socialized.NET can work as a P2P manner,which fits into the nature of opportunistic networks. However,neither of them support message multicasting, so a messagehas to be sent for multiple times in order to reach allusers within a group, which would cost much bandwidth.The Opportunistic Chat introduces a Bluetooth-TCP/IP hybridapproach: if two users near to each other want to talk directly,they setup a Bluetooth link; if they are too far away to reachvia Bluetooth, or they want to chat within a group, thenthey should setup a client-server communication link via theTCP/IP network. Therefore, the Opportunistic Chat also cannot handle group chatting for opportunistic networks. TheDTN Jabber Proxy can work in opportunistic networks, butit still requires complicated server configuration.

In order to support group chatting for opportunisticnetworks efficiently, we have implemented a pure dis-tributed, lightweight and configuration-free application calledONEChat. As soon as ONEChat applications are setup,they can discover each other without querying any central

servers, and they can work without any configuration. Oncea ONEChat application enters or leaves the network, all theothers will be notified automatically. For each message, thereis only one multicast transmission to all the other groupmembers so as to save bandwidth. The following section willpropose the implementation details of ONEChat.

III. IMPLEMENTATION OF ONECHAT

In this section, we first introduce some basics of ONEChatwith BonAHA and Real-time Text, and then define differenttype of groups and messages for ONEChat, and then proposesome of its essential working procedures, including creating,joining and leaving a group, entering network notification, andexiting network notification.

A. Introduction to ONEChat

Figure 1 shows the GUI of ONEChat. The left part of theuser interface is the message list, the right part is the friendlist. The user name of the application is Kate, and there arealready two groups (Global Group and Room 1) in Kate’sONEChat application. Correspondingly, there are two tabs onthe left part of the application with the two group names, andtwo tree roots on the right part, also with those group names.The property of a group in the user interface includes a taband a tree root, and they are both identified by the exact groupname.

Figure 1. The user interface of ONEChat

There are two kinds of messages in ONEChat:system messages and normal messages. We useBonAHA to send and receive system messages in order to

keep track of the network states and perform backgroundinteractions for ONEChat applications, and Real-time Text tosend and receive normal messages in order to provide normalchatting functionality.

The system message publishing mechanism in ONEChat isbuilt on top of BonAHA, which works on mDNS (multicastDNS-based service discovery protocol) [3]. Opportunistic net-works are highly transient networks, it is necessary to keeptrack of network states like users entering and leaving thenetwork. We recognize these events as network events anduse BonAHA to perform multicast querying and responses. Wemanipulate these activities as system messages in ONEChat.

The programming interfaces of mDNS are raw and notsuitable for developing applications conveniently. BonAHAmanipulates the details of mDNS and allows engineers to focuson developing applications as well as keeping track of networkstates conveniently.

Each application built on BonAHA must implementtwo interface functions: serviceUpdated(BNode n) andserviceExited(BNode n). They are used to handle user-update and user-exit events, respectively. An entering networkevent is treated as a user-update event. All details of an eventis manipulated in the BNode object in the argument.

Once a user publishes a system message, ONEChatwould pass the message text into the text argument inthe set(String key, String text) function provided byBonAHA, and all the other users within his transmissionrange will receive this message via their serviceUpdatedfunction triggered. A user can decode the message text withthe get(String key) function, also provided by BonAHA.Note that the value of the key argument for this get functionmust be the same as that of the key argument for the setfunction in order to decode a message correctly. ONEChatuses one chat as the value of the key argument for boththe set and get functions. Table 1 summarizes the usage ofthe four BonAHA functions referenced in ONEChat.

Table 1. Usage of the four BonAHA functions in ONEChat

Function Name Usage

serviceUpdated It is triggered when someone else publisheda system message or entered the network.

serviceExited It is triggered when someone else exitedthe network.

set Call it when I am to publish a system message.get Call it when I am to know what someone else

has published.

The normal message publishing mechanism in ONEChatis built on top of Real-time Text (the implementation libraryis T140 [24]). Real-time Text defines an RTP (Real-timeTransport Protocol) Payload Type for Text Conversation. Itis conversational text that is sent and received on a characterby character basis. The characters are sent immediately oncetyped and also displayed immediately to the receiving personor people. This allows text to be used in the same conversa-tional mode as voice and video.

In ONEChat, we use Real-time Text to build two trans-mission modes for normal messages: line by line mode andcharacter by character mode. In line by line mode, we bufferall the characters in a message that a user has typed and thentransmit them to others; while in character by character mode,text is sent and received on a character by character basis.

As shown in Figure 1, users can choose the message modein Message Mode field. Once he chooses the character bycharacter mode, the Send button will become invalid sincehe does not need it (he just needs to type characters and theywill be sent). As long as the user switches back to line by linemode, the button will become valid again.

We provide primitive security feature to group chatting.There are two kinds of groups in ONEChat: Global Group andprotected groups. All the public messages published withinthe network are displayed in Global Group. By default, eachuser participates in Global Group and can not leave it. Allthe other groups which are created by users are protectedgroups. A protected group must be created with a password,and others who want to join this group must know thispassword. We assume that this password is distributed withsome out-of-bound methods (i.e., ONEChat will not send anypasswords to the network). All the messages published withina protected group will be encrypted with its group password.The encryption algorithm is AES with Counter Mode. Peoplejoin a protected group under the permission of the groupcreator, and leave this group freely.

Currently we do not consider malicious user bent on dis-rupting service. In multicast scenarios where the keys areshared between members, it is easy prove that a member ofthe group sent the packet, but difficult to prevent against amember impersonating another. Such problem called DOA(Data Origin Authentication) for multicast RTP sessions isa hard problem that needs a solution; while some promisingproposals are being investigated [16] [17] [18] [19], more workis needed to rigorously specify these technologies.

DOA can be done using signatures. There are two kinds ofapproaches: signing each RTP packet [16] [17], and amortizinga single signature over multiple packets or sessions [18] [19].The first approaches provides good source authentication butit has high computation overhead in signing and verifying thesignature for each packet. The second approach mitigates theoverhead but it is not satisfactory when transmission is lossy.However, in some scenarios like small group chatting throughwireless links, the computation overhead is not a bottle neck,but there is a high probability of bit errors in wireless links,the first approach is more acceptable.

BonAHA works in local (single-hop) opportunistic net-works, and the communication link can be either wired orwireless. As a result, ONEChat also focus on single-hopopportunistic networks. For each user, we define his networkas all users within his transmission range.

B. Messages in ONEChat

As mentioned above, there are two kinds of messages inONEChat. The first kind is called system message. Table 2

illustrates the usage of all the six kinds of system messages.System messages are handled by the set and get functionsintroduced in Section III.A. More details on how these systemmessages are published and processed will be introduced in thefollowing subsections. The other kind is normal message.System messages are published automatically to performbackground interactions among ONEChat applications, whilenormal messages are published by users manually. In addition,the file transfer and buddy icon update mechanisms also workon top of normal message transmissions.

Table 2. Usage of the six system messages

Type Usage

sys create Notifying others that a new group was created.sys join Notifying group members that I joined this group.sys join Notifying group members that I joined this group.sys reject Notifying someone the password he typed is wrong.sys enter Notifying others that I entered the network.sys exit Notifying others that I exited the network.

The normal message transmission mechanism is based onReal-tim Text, while Real-time Text works on top of RTP/UDPmulticast. Sending a file larger than 64KB over UDP multicastcauses fragmentation, while retransmission of lost packetsmay result in re-sending complete file several times, whichis a waste of bandwidth. It is necessary to look into theretransmission mechanisms in RTP/UDP to mitigate packetloss as well as bandwidth consumption. RFC 2354 [20]proposes several techniques, such as FEC (Forward ErrorCorrection), retransmissions, and interleaving, which may beconsidered to increase packet loss resiliency. Moreover, RFC4588 [21] proposes a comprehensive RTP RetransmissionPayload Format for both unicast and small multicast groups.This format defined in the AVPF profile (RFC 4585 [22]) isused by receivers to send retransmission requests. Currentlywe have added a file filter so that only the files under 64KBcan be seen by users in a file chooser box.

In addition, there are already some open source multicastfile transfer program like UFTP [23], but they are not based onRTP. As a result, the RTP-compatible retransmission mecha-nism mentioned in RFC 4588 may be more appropriate tomitigate the UDP fragmentation problem.

Both system and normal messages have these three fields:message type, destination group and message content.The value of the message type field can be any one in thefirst column in Table 2, or normal lbl, which means this isa normal message under line by line mode, or normal cbc,which means this is a normal message under character bycharacter mode. The value of the destination group fieldindicates which group this message belongs to. A user whoreceives a message would only display it on this exact group.If a user is not participating in that group, this message will bediscarded. The message content field stores the real contentof a message.

C. Creating, Joining and Leaving a Group

While a user is creating a new group, he is required toenter a password, and others who want to join the groupshould ask the group creator for this password. As shownin Figure 1, assume Kate creates a group named Room 2,and this event will be manipulated as a sys create (Table 2)message and broadcast automatically to all users within Kate’snetwork. Assume there is another user named Tom in Kate’snetwork, then Tom will receive this message and display it onthe message list of his global group, as shown in Figure 2.

Figure 2. Tom is informed that Kate created group Room 2

If Tom is interested in joining Room 2, he should doubleclick this message, then a popup window exists and requiresTom to enter the password Kate has entered while she wascreating the group. After Tom enters a password, the newgroup Room 2 will appear in Tom’s application, and asys join (Table 2) message will be sent with a common tagencrypted with the password he typed to all users in GroupRoom 2, notifying that Tom has joined this group. Then Katereceives this message, she uses her own (and the correct)password to decrypt the message and tries to get the tag, ifsucceeds, then Kate knows that Tom has typed the correctpassword (then Tom joins this group successfully), otherwise asys reject message will be sent to Tom to force his ONEChatto close the Room 2 tab. After Tom joins Room 2, he cantalk to Kate within this group. Figure 3 depicts what they aretalking about.

Figure 3. Tom and Kate talks within group Room 2

Please note that Tom is using a monkey’s picture as hisicon and Kate a girl’s picture, and the icons in the two

applications have been synchronized with the buddy iconupdate mechanism: once a user updates his icon, this iconwill be multicast to all users within the network, and thenother users can update this buddy icon. The buddy icon updatemechanism is manipulated as a kind of public normal message.

As described in Section III.B, the method how we identifywhich group a message belongs to is the destination groupfield. When a ONEChat user receives a message (can be eithersystem or normal), he decodes the message text, parses thisfield within the text, and checks whether he has joined thisgroup: if yes, then appends the message to the message list ofthis group; if no, then discards this message.

Figure 4. The sequence of the creating, joining and leaving group procedures

Assume Tom has to leave Room 2 for some reason, hejust closes the tab named Room 2 in his application, then asys leave (Table 2) message will be automatically multicastto all users within this group. This message will appear on themessage list of Kate’s Room 2, and Kate knows that Tom hasleft. Figure 4 depicts the interactive sequence of the creating,joining and leaving group procedures between two users.

D. Entering Network NotificationOnce a user enters the network, all the others in his network

will be notified by the serviceUpdated mechanism (Table1) in BonAHA. Figure 5 describes the procedure of enteringnetwork notification. We take Tom and Kate as example again.Once Tom launches a ONEChat application, a sys entermessage (Table 2) is generated automatically and published bythe set (Table 1) function provided by BonAHA, then all theothers in Tom’s network will receive this message immediatelyvia their serviceUpdated function triggered. Kate’s ONEChatthen parses the message type field to make sure this is asys enter message and displays it on the message list of herGlobal Group, and Tom will be listed in Kate’s friend list.

Figure 5. The Entering Network Notification procedure

E. Exiting Network Notification

ONEChat can capture a user-exit event as well as a user-enter event. We implement the procedure of exiting networknotification by overloading the serviceExited (Table 1) func-tion provided by BonAHA. Figure 6 describes the implemen-tation of this notification procedure.

We take Tom and Kate as example again. Assume Tomcloses his ONEChat application, and this action triggers asys exit event down to his BonAHA framework, and thisevent is multicast to all the others in Tom’s network, and thenall their serviceExited functions are triggered. For Kate, asystem message indicating Tom exited the network will bedisplayed on the message list of her Global Group and thename Tom will be deleted from her friend list.

Figure 6. The procedure of exiting network notification

IV. PERFORMANCE EVALUATION

As shown in Section II, there exist a few applicationsproviding chatting functions for opportunistic networks, andamong which, iChat and Socialized.NET work as a P2P

manner and require minimum configuration, so they mostlymatch the motivation of this article. This section proposesperformance analysis on ONEChat and these P2P applications(in short, we call it P2P). The performance metric is the totalamount of bytes sent to the network (bandwidth consumption)in the following scenario.

There is a group G0 with m users: {N1, ..., Nm}. Each userNi is within all the others’ single-hop communication range,and he is going to send ki messages to all the others withinthis group. Each message has the same size: L bytes. LetBONEChat denote the total amount of bytes sent by ONEChatand BP2P by P2P.

In P2P applications, each message has to be sent to everyoneelse within the group once (here we ignore message retrans-mission), so the total amount of bytes sent in the network is:

BP2P =m∑

i=1

L× ki × (m− 1)

In BonAHA, a multicast messge will be sent for a few timesfor implementation considerations. Using Wireshark [14], wefind that each system message is transmitted at most 3 times,and each normal message is transmitted once. Therefore,the average transmission times (in short, avt), which isdefined as the total number of transmitted messages divided bythe total number of distinct transmitted messages, is at most 3.Since ONEChat applications perform message multicasting forgroup chatting, the total amount of bytes sent in the networkis:

BONEChat =m∑

i=1

L× avt× ki

From the two equations above, we can see that when (m−1) > avt, the P2P applications will send more bytes to thenetwork than ONEChat in the same group chatting scenario.Given avt ≤ 3, if there is more than 5 users in a group,ONEChat definitely consumes less bandwidth than P2P, i.e.,ONEChat is more efficient than P2P.

V. CONCLUSION

This article proposes a group chatting application namedONEChat for opportunistic networks. There are two main con-tributions. First, ONEChat eliminates configuration and infras-tructure, making it easily deployed in opportunistic networks.Second, it uses multicast technique in order to mitigate band-width consumption in group chatting scenarios. Quantitativeperformance analysis shows that ONEChat outperforms P2P-based applications like iChat and Socialized.NET in bandwidthconsumption as long as there are more than 5 members in agroup. ONEChat is an efficient group chatting application foropportunistic networks.

Future work includes improving its security against mali-cious users, and mitigating the UDP fragmentation problemin large file transfer.

ACKNOWLEDGMENT

This work is supported by NSF XX-XXXXX.

REFERENCES

[1] Suman Srinivasan, Arezu Moghadam, Henning Schulzrinne, BonAHA:Service Discovery Framework for Mobile Ad-Hoc Applications. IEEEConsumer Communications & Networking Conference 2009 (CCNC’09),Las Vegas, USA, January 2009.

[2] Suman Srinivasan, Arezu Moghadam, Se Gi Hong, Henning GSchulzrinne, 7DS - Node Cooperation and Information Exchange inMostly Disconnected Networks. IEEE International Conference onCommunications (ICC), Glasgow, Scotland, Jun 2007.

[3] http://www.zeroconf.org/[4] http://www.icq.com/[5] http://www.google.com/talk/[6] http://www.msn.com/[7] http://www.AIM.com/[8] http://www.Skype.com/[9] J Schull, M Axelrod, L Quinsland, Multichat: Persistent, Text-As-You-

Type Messaging in a Web Browser for Fluid Multi-Person Interactionand Collaboration. Proceedings of the 39th Annual Hawaii InternationalConference on System Sciences, Hawaii, USA, 2006.

[10] http://www.apple.com/macosx/features/ichat.html[11] http://www.socialized.net/[12] Salvatore Sorce, Francesco Cinquegrani, Salvatore Anzalone, Dario

Cacca, Antonio Gentile, A Dynamic System for Personal Communica-tions: the Opportunistic Chat. International Conference on IntelligentPervasive Computing, Jeju City, South Korea, 2007.

[13] Ryan Metzger, Mooi Choo Chuah, Opportunistic information distribu-tion in challenged networks. Proceedings of the third ACM workshopon Challenged networks, San Francisco, California, USA, 2008.

[14] http://www.wireshark.org/[15] http://www.ietf.org/rfc/rfc4103.txt[16] Perrig, A., Canetti, R., Tygar, D. and D. Song, Efficient Authentication

and Signing of Multicast Streams over Lossy Channels. in Proc. of IEEESecurity and Privacy Symposium S&P 2000, pp. 56-73, 2000.

[17] Istemi Ekin Akkus, Oznur Ozkasap, and M. Reha Civanlar, SecureTransmission of Video on an End System Multicast Using Public KeyCryptography. Lecture Notes in Computer Science, pp. 603-610, Volume4105, 2006.

[18] Namhi Kang, and Christoph Ruland, MDS: Multiplexed Digital Signa-ture for Real-Time Streaming over Multi-sessions. Lecture Notes inComputer Science, pp. 824-834, Volume 3391, 2005.

[19] C. K. Wong and S. S. Lam, Digital signatures for flows and multicasts.In Proc. IEEE ICNP’98, 1998.

[20] http://www.ietf.org/rfc/rfc2354.txt[21] http://www.ietf.org/rfc/rfc4588.txt[22] http://www.ietf.org/rfc/rfc4585.txt[23] http://www.tcnj.edu/˜bush/uftp.html[24] http://sourceforge.net/projects/rtp-text-t140/