Prototyping an Enhanced SMS Service for theTeleweaver Application Server

Mosiuoa Tsietsi and Alfredo TerzoliDepartment of Computer Science

Rhodes University, P.O. Box 94, Grahamstown 6140Tel: +27 (046) 603 8787, Fax +27 (046) 636 1915

{m.tsietsi, a.terzoli}@ru.ac.za

Abstract—The Siyakhula Living Lab is a joint initiative betweenRhodes University and the University of Fort Hare. Its mainaim is to introduce Information and Communication Technology(ICT) services into a rural area in the Eastern Cape province ofSouth Africa. The living lab provides an ideal environment forthe delivery of such services due to the network connectionsand equipment that have been deployed at various locationsin the area. In conjunction with the Siyakhula Living Lab,Reedhouse Systems — a software company born out of RhodesUniversity — is in the process of integrating a software systemcalled Teleweaver which is intended to become the main accesspoint for the consumption of these services. Previous researchhas documented mobile phone use in the area. This data showsthat the majority of villagers use mobile phones to communicate,particularly with surrounding villages. Thus mobile phones havean important role to play in supporting communication betweenpeople in the area. This paper describes a software prototype thathas been developed using an open source software platform calledMobicents that is able to peer with Teleweaver to provide an SMSmessaging service accessible through the web. The two platformswork in tandem to create a system that enables villagers to createdigital versions of their social groups and send messages to themin bulk.

Index Terms—Converged Services, Internet Services and EndUser Applications

I. INTRODUCTION

THE coastal region of Dwesa is located in the formerhomeland of the Transkei in the Eastern Cape of South

Africa, and is the site of the Siyakhula Living Lab. Dwesa issimilar to many marginalised areas in South Africa becauseit lacks infrastructure, and due to its remoteness, is excludedfrom many of the economic developments in other parts of thecountry [1]. The Siyakhula Living Lab was launched in early2006 as an ICT4D (Information and Communication Technol-ogy for Development) project with the aim of using technologyas an enabler for social and economic development.The project is sustained by a four way partnership (known asa quadruple helix) which involves partners from four spheres:research, government, industry and the community. On theresearch side, there are numerous staff members and postgrad-uate students from Rhodes University and the University ofFort Hare who conduct research in the Siyakhula Living Lab.In the early stages of the project, network connectivity wasdeployed. A VSAT connection to the Internet was installed atone of the local schools and a WiMax base station was set up

to provide the distribution. WiMax CPEs (Customer PremisesEquipment) were subsequently installed at several locations inthe area. These connected zones are known as digital accessnodes and collectively share the VSAT backhaul.With network connectivity in place, researchers endeavouredto develop a suite of e-commerce applications that could beused by villagers in Dwesa. This includes e-government, e-health and e-learning applications [1]. Efforts towards develop-ing software solutions for digital inclusion have culminated inthe creation of a software company called Reedhouse Systems,which is hosted by Rhodes University. The objective of thecompany is to create a software platform called Teleweaverthat behaves as an integrated environment for hosting ser-vice modules that are developed by ICT4D researchers [2].Teleweaver is composed of free and open source software andis based on a Java standard known as OSGi (Open ServiceGateway Initiative).In 2009, a baseline study was compiled whose aim was todocument the social and economic status of the communitiesliving in Dwesa in order to properly advise the deploymentof ICT systems there [3]. One of the focus areas of thestudy was current technology and media use. In the analysis,researchers noted that traditional forms of communicating suchas community meetings and word of mouth were importantchannels of communication for people living close-by to eachother, but that mobile phones were being highly used to aidcommunication between remote villages.As part of the digitisation of the living lab and as a use case forthe Teleweaver system, a tool can be developed that can enablevillagers with or without mobile phones to send messages totheir contacts in the various communities through software andhardware infrastructure installed in the digital access nodes.This paper describes the initial step towards the developmentof such a system that has been developed using a serviceplatform called Mobicents that is able to work in conjunctionwith Teleweaver to provide an SMS service that leverages anetwork hosted address book to support group communication.The paper is structured as follows: Section II provides thecontext for the work. Section III provides the motivating fac-tors for the development of the system. Section IV provides anoutline of the system design and describes the implementationof the prototype. Section V describes different deploymentoptions that are available in a combined Mobicents-Teleweaver

ecosystem. Section VI provides details of system testing andresults. Section VII provides an analysis of the solution andSection VIII provides concluding remarks and items for futurework.

II. CONTEXT OF THE RESEARCH

The work related in this paper is set against a backdrop ofprevious research in the Siyakhula Living Lab that points to aneed for the development of mobile communication servicesfor the Dwesa region.

A. The Baseline Study: An Introduction

ICT is often treated as a monolithic and homogeneous entity.This way of conceptualising such projects often leads toproblems as it fails to comprehend the multi-faceted natureof ICTs [4]. The appropriate approach is a multi-disciplinaryone – one that respects the view that ICTs exist as part ofa socio-technical network, and are influenced by a specificinstitutional or cultural context [5]. This means that researchersmust have a holistic viewpoint of the systems they are creatingand deploying. It is in this spirit that a baseline study wasundertaken to help inform the process of ICT deployment inthe Siyakhula Living Lab.

The baseline study was conducted between March 2008 andApril 2009. The researchers involved in the study were fromdifferent backgrounds, namely Information Systems, Com-puter Science, Communications and Social Anthropology.There was additional industry input from Nokia SiemensNetworks. The aim of the study was to assess the social andeconomic status of the communities in the area at that time[3]. The Mpume village in Dwesa was chosen as the studyarea since it was found to be generally representative of thecommunities in Dwesa.

One of the findings of the study relates to community networksin Mpume. It was noted that community networks are veryimportant systems that help to preserve cultural heritage. Theharmony that is created through strong communal links wasseen to be a key enabler that lead villagers to collaboratewith each other and with others living in nearby villages forcultural events and to share information. The study suggestedthat ICTs could play a role in strengthening existing forms ofcommunication in various ways. Community members couldbenefit from an ICT system that could keep them abreast ofnews such as traditional ceremonies, weddings, funerals, sportsevents and church activities that are happening in the area.Families could also benefit from ICTs that could assist themin keeping in contact with those who have migrated from thearea in search of work.

B. The Baseline Study: Assessing the use of Modern ICTs

As part of the assessment of the use of modern ICTs, theresearchers examined the use of computers and cellphones. Ofthe two technologies, cellphones were found to be the mostaccessible technology and thus the most used. In 2009, 23%

of Mpume residents owned a cellphone and a further 27% hadaccess to a cellphone that they could borrow. Of those whoowned cellphones, the majority of them (77%) only owned asingle handset.In using cellphones, few used them to communicate withpeople in the local community. Only 10% did so, whilethe majority used word of mouth (90%). The reason forthe low volume was attributed to the high cost of usingcellphones in comparison to other available means. However,in communicating with surrounding villages, cellphones werethe most popular medium as 45% of Mpume residents usedthem for this purpose. Other competing mediums includedword of mouth (30%) and community meetings (19%). Asimilar trend was observed when collecting data regardingcommunication with people in other areas of the country. Inthis case, cellphones were the most popular medium at 58%,while public phones were used 33% of the time.

C. Web Service Wrappers for Service Creation

In 2010, a thesis was published at the University of Fort Harethat relates the author’s experiences in developing a suite ofcommunication services targeted for the Dwesa area [6]. Theaim of the project was to develop a middleware framework thatcould act as a platform for the creation of e-commerce servicesas an alternative to the monolithic systems that had beendeveloped in the past [7]. The prototype that resulted from theinvestigation provided web service implementations of SMS,MMS, Email and instant messaging services, in addition to aset of SOAP (Simple Object Access Protocol) methods thatcould be used by 3rd parties wishing to incorporate suchservices into their applications.

D. Teleweaver: A Service Platform

This project was in some senses a prelude to Teleweaver,as like Teleweaver, it attempted to move beyond the silo’sthat result when systems are developed independently ofeach other. As the new service integration platform for theSiyakhula Living Lab, Teleweaver has become the singledeployment environment for researchers working in the area.The OSGi standard upon which Teleweaver is based defines aflexible component model for the creation of services. Systemsdeveloped within an OSGi container such as Teleweaver mustbe composed of independent software building blocks calledbundles that can be reused and composed into larger systems[8].

E. Mobicents: A Telecommunications Platform

In a separate effort toward developing telecommunicationservices for next generation mobile networks, researchers atRhodes University have been using the open source Mobi-cents platform. Mobicents implements another Java standardknown as SLEE (Service Logic Execution Environment) [9].SLEE defines a component model for structuring applicationsthrough reusable service units, much like OSGi. Central tothe SLEE are resource adapters that adapt protocol messages

into an appropriate format for the container. It is this propertyof being a multi-protocol environment that makes a SLEEcontainer a powerful platform for developing communicationservices [10].As internal policy, it has been determined that functions thatrelate to telecommunication services should be developedwithin Mobicents, while Teleweaver should be used as ageneral purpose service platform.

III. ICTS FOR MOBILE COMMUNICATION

From the literature covered in Section II, it is evident thatthere is an opportunity for the development of ICTs that canpromote person to person and person to group communicationsusing mobile technology as an enabler. The challenge createdby the relatively low proportion of people with, or withaccess to a mobile phone, can be mitigated by a systemthat interfaces with the mobile network on the user’s behalf,thus removing the need for an actual mobile handset. Asan extension to the system described in Section II-C, thenew system would be supplemented by a network hostedaddress book that users could populate with their contacts.Contacts could be assigned to groups in order to supportbulk communication to one’s social networks. As an initialstep, we are interested in developing tools for SMS messagingand eventually transitioning to other forms of communicationsuch as MMS, instant messaging and voice communications.Section IV describes a solution that satisfies these goals.

IV. SYSTEM DESIGN AND IMPLEMENTATION

In this section, we provide a detailed account of the systemdesign and implementation.

A. Overall Design

Figure 1 shows an overall view of the system. The systemis supported by three servers: Mobicents, Teleweaver andGSM (Global System for Mobile communications) gateway. Inpractice, all servers can be co-located onto a single machine.The next section describes these components in more detail.

B. Components

The GSM gateway is implemented in software and interfaceswith a GSM modem through operating system device drivers.The gateway can be configured to route incoming SMSesto a software application that consumes them and to submitrequests from an application to the modem for delivery on amobile network. The modem interacts directly with the mobilenetwork via a SIM (Subscriber Identity Module) card that isplaced inside it.Teleweaver mainly provides the graphical interface to thesystem (other possible deployment options are described inSection V). The interface is developed as an OSGi-compliantweb application that can be accessed through a standardbrowser. It allows a user to create contacts that can be storedin a network hosted address book. Contacts can be assigned

to contact groups such as “Family”, “Arts and Crafts” and“Headmasters”. The interface also supports the actual sendingof SMSes by allowing a user to type the textual content ofthe SMS and to select a combination of contacts and contactgroups to send the message to.

Mobicents hosts the actual application logic of the service.This means that it can interrogate the request that it receivesfrom Teleweaver and it can customise it so that it can besuccessfully processed by the gateway. This hides the detailsof the SMS message syntax from Teleweaver and allowsthe Mobicents developer to customise any error messagesappropriately so they can be communicated to the Teleweaveruser in a friendly manner.

C. System Implementation

The prototype that has been implemented is made up of threeparts:

1) Kannel: Kannel is an open source GSM gateway and caninterface traditional GSM technologies such as SMS withInternet-style protocols such as HTTP. The Kannel instance wehave installed is made up of two components. The bearerboxcomponent provides a direct interface to mobile phones andaccepts SMSes and submits them to the second component,the smsbox, which actually provides the SMS gateway func-tionality [11]. It uses a single configuration file for configuringboth components. Configurations were made in this file and asuccessful connection was established with the SMSc of oneof the local mobile carriers.

2) Network Hosted Address Book : Mobicents provides anXML Document Management Server (XDMS) that imple-ments industry standards developed by the Open MobileAlliance (OMA) for managing XML documents that arestored on a network. [12]. One of the application usages (orappusages) defined for the XDMS is a resource list. A resourcelist provides the same functionality as a network address bookas it defines a way of creating lists of users who are identifiedby their contact addresses and storing them on a server. TheInternet Engineering Task Force (IETF), the main body behindglobal Internet standards, has defined an XML schema forthe creation of resource lists as XML documents that can bestored inside an XDMS [13]. The IETF also defines a protocolcalled XCAP (XML Configuration Access Protocol) which isa client protocol that can be used to perform CRUD (create,read, update, delete) operations on XDMS resources [14].

The Mobicents XDMS ships with support for standard ap-pusages such as resource lists, among others. There were nospecial configurations that were needed in order to support thisfunctionality.

3) Mobicents Service: In the Mobicents SLEE service, eachrequest must pass through a number of service building block(SBB) modules before it can be forwarded to the gateway.The request cascades through a chain of independent servicemodules that examine it and can modify it before passing iton to the next module in the chain. The flow of interactionsis shown in Figure 2.

Figure 1. Overview of the system.

Figure 2. Architecture of the Mobicents service.

The request from Teleweaver is received through the HTTPservlet resource adapter in the Mobicents container and isdelivered to a logical router within the SLEE. The SLEE routeris a standard SLEE component and is not part of the actualservice. Its job is to examine each request that comes into thecontainer and to send it to those services that have registeredinterest in receiving those events. The event is always sent tothe SBB with the highest event priority as set in its serviceconfiguration. In the case of the SMS service, the request mustinitially pass through a custom security module that ensuresthat the request originates from a recognised Teleweaver node.This is supported by a facility called a SLEE profile that allowsdevelopers to store and access service related data.

If the request successfully validates against the profile, itpasses on to the next SBB called BulkSmsHttpSbb. Thismodule examines the request for adherence to syntax rules toensure that it can be processed successfully further down theexecution chain. This involves checking that all the parametersin the request have been spelled correctly and that all themandatory fields that are defined by the API are in place. Ifthe module determines that the request does not comply withany of these requirements, it aborts further processing of therequest and generates a response back to the user, providinga human-readable error report that specifies what went wrongand what should be done to remedy the situation.

If the request satisfies all requirements, it passes on to theBulkSmsXcapSbb module which is responsible for correctly

resolving the targets of the SMS when group names arespecified in the request. The module queries the XDMS andobtains a list of numbers that appear under all specifiedgroups. Any duplicates are removed. The request then passeson to the BulkSmsAaaSbb module which is responsible forperforming accounting. Since the total number of recipients isknown and tariffs for the different operators can be stored andaccessed from a SLEE profile, this module can perform a basiccalculation and compare the total cost of sending the SMSeswith the balance in the user profile. Only if there are sufficientfunds should the request be allowed to proceed further. Thismodule has not yet been fully implemented, but Mobicentsprovides a Diameter stack and online billing primitives thatcan be used for this purpose.

The BulkSmsKannelSbb module submits the final requestto Kannel. It does so by composing the request in the ap-propriate format that Kannel requires. There are situationsthat have nothing to do with the format of the request thatcan lead to errors when the request is sent for handing byKannel. This includes hardware or network related problems.Mobicents receives these error reports from Kannel and canpresent them in a user friendly format to the Teleweaver user.For instance, an obscure class 4XX HTTP error message thatKannel returns can be customised to reflect the exact natureof the problem in such a way that a user can understand.

V. DEPLOYMENT OPTIONS

The description in the previous section describes the basicenablers that are required for the bulk SMS service. Asapplication servers, Mobicents and Teleweaver have similarcapabilities. As a result, there is some flexibility regardingwhich elements can be implemented in which applicationserver. Teleweaver and Mobicents can maintain their primaryroles as an interface point and a message proxy, respectively.However the billing, user profile and network hosted addressbook components can reside in any one of them.

In Section IV-C, no assumptions were made regarding thelocation of the user profile. This information can be hostedwithin Teleweaver, in which case when the user logs in atthe digital access node, a local database is consulted in order

to authenticate and identify them. Currently, Teleweaver doeshave this kind of functionality, however it is also possible tohost the user profile within Mobicents by re-using the XDMS.OMA has defined an additional XML schema for a user profilewhich is defined in [15] and since Mobicents ships with nativeOMA user profile support, this would allow easy incorporationand management of user profile data by our SLEE application.

The second enabler is billing. Billing functions are currentlybeing incorporated within Teleweaver through an auditingsystem that will allow applications to request auditing / billingto be performed on their behalf. Mobicents, as a telecommu-nication platform also supports prepaid and post-paid billingmodes through Diameter protocol support.

VI. TESTING AND RESULTS

In order to test the correct functioning of the system, we setup an experiment using three separate machines, each onerunning a single server. It would have been possible to runall services on a single machine, but distributing the solutionin this manner helped to test the correct functioning of theservice in a less trivial setting. All the machines that wereused in this experiment were running the open source UbuntuLinux operating system. This is in line with what is currentlybeing used at the digital access nodes. [16].

At the time of writing, there has not yet been an interfacedeveloped on Teleweaver that facilitates the generation ofSMS requests. Fortunately, since the service relies on plainHTTP, it was possible to create a simple web form tosimulate the Teleweaver web application. In the first stage,we created a new resource list for a test user. When the newlist is created, the system automatically creates a defaultgroup called “Ungrouped” in which all contacts that are notassociated with a group will be assigned to. The structure ofthe new list is given in Listing 1.

<?xml version="1.0" encoding="UTF-8"?><resource-lists xmlns="urn:ietf:params:xml:ns:resource-

lists"><list name="Ungrouped"/>

</resource-lists>

Listing 1. User resource list with a single empty group.

In the next stage, three new contacts are created. One isnamed Mamello Moeketsi, who is not assigned to a groupand will thus be automatically assigned to the “Ungrouped”group. Two additional contacts are also inserted, Jabu Puleand Sipho Gumede who are both assigned to a new groupcalled “Family”. The resource list that resulted is given inListing 2. As shown in the list, each contact is identified bya SIP (Session Initiation Protocol) address. SIP is typicallyused in VoIP (Voice over IP) applications. The user part ofthe address consists of the contact’s mobile number which isextracted when compiling a list of targets for an SMS. Thebenefit is that the use of SIP offers the possibility of usingthe contact list in VoIP applications in future.

Figure 3. SMSes delivered to two recipients in the same group.

<?xml version="1.0"encoding="UTF-8"?><resource-lists xmlns="urn:ietf:params:xml:ns:resource-

lists"><list name="Ungrouped">

<entry uri="sip:0786445362@192.168.10.10"><display-name>Mamello Moeketsi</display-name>

</entry></list><list name="Family">

<entry uri="sip:0837634456@192.168.10.10"><display-name>Jabu Pule</display-name>

</entry><entry uri="sip:0786221234@192.168.10.10">

<display-name>Sipho Gumede</display-name></entry>

</list></resource-lists>

Listing 2. User resource list with two groups.

In the final stage, an SMS was drafted in the web form andsubmitted to the service indicating the group “Family” asthe target. Figure 3 shows the SMS being received by twocellphones representing the two members of the group.As of February 2012, the code for the project is available onGoogle Code under an Apache License v2 [17].

VII. DISCUSSION AND ANALYSIS

In this section a discussion on the software design and imple-mentation is provided and the solution is analysed based onsustainability, security considerations and limitations.

A. Sustainability

One way in which software projects can be rendered un-sustainable is through the requirement that specialised soft-ware or hardware be used to drive it. Our entire prototypewas developed on a free, open source operating system thatdoes not require any licensing to install or distribute. Thisis important if the system is to be installed in differentlocations in Dwesa. Kannel is free and its license permits freeredistribution and use. Mobicents is also free and is releasedon a non-restrictive software license, though a support licensemust be bought when revenue is being generated due to theJEE (Java enterprise edition) server that ships with it. Thatsaid, it is possible that only a minimal number of supportlicenses will need to be acquired since multiple Teleweavernodes can be configured to connect to a single Mobicents host.

B. Security Considerations

There are a number of security considerations that must beaddressed when deploying such a system in order to keepit secure and to protect it from abuse. Fortunately, Kannelprovides native support for blacklisting and whitelisting IP(Internet Protocol) addresses in order to bar unauthorisedrequests. The benefit of the solution is that only one IP addressneeds to be whitelisted: that of the Mobicents server. Reducingthe number of servers in the whitelist reduces the risk of asecurity breach. This is in addition to the SLEE application’ssecurity layer that only authorises known Teleweaver nodes.

C. Limitations

The system has some limitations. For one, it is based on themanual entry of numbers to populate the address book. If auser has many contacts to add, it would take them a long timeto do so. Besides being a tedious process, it is also prone todata entry errors. Also, Kannel is not able to load balancebetween SMS centres, which means that if the SMSc thatKannel is configured to interact with is down or overloaded,the system can experience problems or delays.

VIII. CONCLUSION AND FUTURE WORK

This paper details the initial stage of the development of abulk SMS service within Mobicents that adds value to theTeleweaver system. It shows that the development of such asystem can be done effectively using free and open sourcesoftware components and that a network hosted address bookcan enhance a basic SMS service. The research is still at anearly stage, and more work is required to assess the suitabilityof the implementation and to identify any required adaptions.In future, the development of mobile applications will beinvestigated in order to provide automated contact synchro-nisation so that manual entry is avoided. An investigation willalso be conducted on the creation of a global, sharable addressbook that is searchable by all users. The ability to share anaddress book with the rest of the network may have the resultof connecting individuals who would otherwise have difficultyin connecting with each other. Needless to say, privacy controlswould need to be carefully considered in such a system.Lastly, given the fact that an address book can have varioustypes of contact information, users can add addresses fromtheir existing email, VoIP, Google Talk, Skype and other socialnetworks in order to support communication on a variety ofmediums using the underlying address book as an enabler. Asa multi-protocol service environment, Mobicents is well suitedfor supporting this extension.

IX. ACKNOWLEDGEMENTS

The work reported in this paper was undertaken in the TelkomCentre of Excellence in Distributed Multimedia at RhodesUniversity with financial support from Telkom SA, Tellabs,Easttel, Genband, Bright Ideas 39 and THRIP. The authorsalso wish to thank Dr Caroline Khene for verifying the detailsregarding the baseline study.

REFERENCES

[1] Mamello Thinyane, Lorenzo Dalvit, Hannah Slay, Thandeka Mapi,Alfredo Terzoli, and Peter Clayton. An Ontology based, Multi-modalplatform for the Inclusion of Marginalized Rural Communities into theKnowledge Society. In SAICSIT 2007: Annual Research Conferenceof the South African Institute of Computer Scientists and InformationTechnologists on IT Research in Developing Countries, pages 143–151,New York, NY, USA, 2007. ACM.

[2] Reedhouse Systems - Empowering Marginsalised and DisadvantagedCommunities through Practical ICT Solutions. Available Online, May2012. http://www.reedhousesystems.com.

[3] Caroline Pade-Khene, Robin Palmer, Mitchell Kavai, and SibukeleGumbo. Siyakhula Living Lab - Baseline Study Report. Technicalreport, Rhodes University and The University of Fort Hare, 2009.

[4] Maung Sein and Hari G Harindranath. Conceptualizing the ICT Artifact:Toward Understanding the Role of ICT in National Development. TheInformation Society, 1(20):15–24, 2004.

[5] Rob Kling. Learning about Information Technologies and SocialChange: The Contribution of Social Informatics. The InformationSociety, 16(3):217–232, 2000.

[6] Jimmy Samalenge. Developing SOA Wrappers for CommunicationPurposes in Rural Areas. Master’s thesis, University of Fort Hare,November 2010.

[7] Jimmy Samalenge and Mamello Thinyane. Deploying Web Ser-vices in Rural Communities for Services of Personal CommunicationSynchronous and Asynchronous. In SATNAC ’09: Southern AfricanTelecommunications Networks and Applications Conference, 2009. Workin Progress.

[8] Lindikaya Ntshinga, Mamello Thinyane, and Alfredo Terzoli. Blueprintsfor Software Components within Teleweaver, a Custom OSGi Container.In SATNAC ’11: Southern African Telecommunications Networks andApplications Conference, September 2011.

[9] Java Community Process. JSR 240: JAIN SLEE (JSLEE) v1.1. AvailableOnline, October 2008. URL: http://jcp.org/en/jsr/detail?id=240.

[10] Mosiuoa Tsietsi, Alfredo Terzoli, and George Wells. Using JAIN SLEEas an Interaction and Policy Manager for Enabler-based Services inNext Generation Networks. International Journal of Electronics andTelecommunciations, 56(2):117–124, June 2010.

[11] Kannel User’s Guide - Open Source WAP and SMS Gateway. AvailableOnline, May 2012. http://www.kannel.org/userguide.shtml.

[12] Douglas Silas, Eduardo Martins, Jared Morgan, andTom Wells. The User Guide for the MobicentsSIP Presence Service. Available Online, May 2011.http://hudson.jboss.org/hudson/job/MobicentsBooks/lastSuccessfulBuild/artifact/sip-presence/index.html.

[13] Jonathan Rosenberg. RFC 4826: The Extensible Markup LanguageFormats for Representing Resource Lists. Internet Engineering TaskForce, May 2007.

[14] Jonathan Rosenberg. RFC 4825: The Extensible Markup Language(XML) Configuration Access Protocol (XCAP). Internet EngineeringTask Force, May 2007.

[15] OMA. Enabler Release Definition for XML Document ManagementVersion 2.0. Open Mobile Alliance, August 2009.

[16] Ingrid Sieborger and Alfredo Terzoli. WiMax for Rural SA: The Experi-ence of the Siyakhula Living Lab. In SATNAC 2010: Southern AfricanTelecommuncations Network and Applications Conference, September2010.

[17] Open Bulk SMS. Available Online, February 2012.http://code.google.com/p/open-bulk-sms.

Mosiuoa Tsietsi is currently working as a postdoctoral researcher in thedepartment of Computer Science at Rhodes University. His research interestsinclude open source software, service delivery platforms and applicationprogramming interfaces to telecommunication systems.

Alfredo Terzoli is Professor of Computer Science at Rhodes University, andhead of the Telkom Centre of Excellence in Distributed Multimedia. Heis also Research Director of the Telkom Centre of Excellence in ICT forDevelopment at the University of Fort Hare. His main areas of academicinterest are converged telecommunication networks and ICT for development.