an ontology-based context inference service for mobile applications in next-generation networks

IEEE Communications Magazine • January 201160 0163-6804/11/$25.00 © 2011 IEEE

INTRODUCTION

The notion of context-enabled mobile applica-tions has been discussed by researchers and prac-titioners for several years. These applications areexpected to enhance the interaction with the userand to improve the experience by collecting infor-mation that supports the identification of theuser’s current situation. For instance, a cell phonethat is aware of the users daily commuting cansend out reminder when the train is about to

arrive and suggest to buy a ticket automatically.However, the development of a context-awareapplication or service is challenging. This isbecause the context of a person is defined by vari-ous factors such as location, social environmentor time and is inferred by using complex andmostly implicit rules. This requires a developmentof systems designed to support context-awareness.By offering context-aware applications, develop-ers would relief users of the burden to explicitlydefine what information is currently relevant tothem and could offer enriched services that arespecifically tailored to the user’s situation. Hence,the complexity of interaction with mobile applica-tions is reduced which is of major importanceespecially in mobile environments where the sameservice is used within various environments.

The need for a system design that supportscontext-awareness has led to the development ofseveral frameworks and architectures providingconcepts and concrete examples of potentialapplication designs. The goal of the architecturesis to simplify the development of context-awareapplications, to reduce redundant developmentefforts by consisting of reusable components aswell as to provide an infrastructure that allowsmultiple applications to gain access to the system.

The advent of next-generation networks (NGN)supports context inference in a way that it enables aservice to acquire rich user information from bothInternet and mobile spheres on the basis of com-mon IP-based communication standards. This isrealized by the IP Multimedia Subsystem (IMS)specification that has been developed as a potentialstandard for NGN architectures. The standardspecifies the access on mobile services from severalnetworks such as Global System for Mobile Com-munications (GSM), Universal Mobile Telecommu-nications System (UMTS), wireless local areanetwork (WLAN), or wireline broadband, and usesthe asynchronous Session Initiation Protocol (SIP)for a secure and reliable communication. However,a context service requires an interface that servesboth web and IMS purposes and provides a contextmodel that is simple, flexible, and expressive [1].

In respect of the inference of context, existingarchitectures source and process user information

ABSTRACT

Context enabled mobile applications are consid-ered to provide a richer experience and to enhancethe user interaction by acquiring information thatallows the identification of the user’s current situa-tion. Modern context inference infrastructures cansource, process and deliver user information. How-ever, a commercialization towards a context servicehas still been prohibited by the need for global ser-vice coverage and accurate context identification.With the advent of Next Generation Networks,telecom operators can leverage All-IP networks todesign external service interfaces that integrate adiverse set of sources and context inference pro-cesses that are easily scalable, extendable, androbust at the same time. This article presents atelecom operator service that supplies mobileapplications with context information to illustratehow context infrastructures can leverage NGNcapabilities. The article introduces an innovativecontext inference approach involving third Partyapplications within the inference process itself.This is done by structuring the ontology contextmodel in layers of complexity and inferring particu-lar context information via modules, which aredesigned in collaboration with third party develop-ers. Furthermore, the service is compliant withstate-of-the-art IP Multimedia Subsystem infras-tructures and provides an interface that usesHTTP/SOAP and HTTP/REST communication aswell as the Session Initiation Protocol of the IMS.A first proof of concept indicates an increased ser-vice adoption, a higher accuracy of context, and anincreased robustness towards errors.

NEW CONVERGED TELECOMMUNICATIONAPPLICATIONS FOR THE END USER

Philipp Gutheim, University of California Berkeley

An Ontology-Based Context InferenceService for Mobile Applications in Next-Generation Networks

GUTHEIM LAYOUT 12/16/10 12:32 PM Page 60

IEEE Communications Magazine • January 2011 61

in an adequate manner. These infrastructureshave been developed for both experimental usageand large-scale environments and distinguish exe-cutable functions such as information retrieval,storage, learning algorithms, and the inferenceitself. However, an NGN context service has toensure service coverage as well as a reliable andaccurate inference of context to meet user’s expec-tations. This requires an infrastructure, which pro-vides a scalable and extendable inference processthat pays particular attention to handle complexi-ty, ambiguity, and uncertainty of information [2].

This article demonstrates how a telecom opera-tor can leverage the potential of converged net-works by providing a context inference platformthat enables users to enrich mobile applicationswith context information. Our motivation is tooutline a service that requires an innovative imple-mentation on the basis of NGN, is compliant withcurrent standards and is designed for large-scaledeployment. We propose an implementation thatinvolves third party applications within the contextinferences process itself and identify improve-ments to previous implementations, namely anincreased service adoption, a higher accuracy ofcontext, and an increased robustness to errors. Forthat reason, we initially review two general contextmanagement models and the common layer designarchitecture of current context inference systems.On that basis, we outline the Telco service andderive an implementation that uses the proposedmodule-layer structure in combination with exist-ing web and communication standards. After-wards, we present a first evaluation of theimplementation and finally analyze how the pro-posed model contributes to a future execution ofcontext inference service in NGN.

BACKGROUND ONCONTEXT FRAMEWORKS

Most research in context-aware computing hasfocused on developing software architectures toallow an application to process and use contextinformation. Two distinct approaches can beidentified: architectures that follow a widgetmodel and those which use a blackboard model[3]. In this section, both approaches are

reviewed. Afterwards, a more abstract model inform of a layered middleware is presented.

CONTEXT MANAGEMENT MODELSWidget architectures allow applications to gainaccess to context information by a direct requestto a particular widget. Widgets are the intermedi-ary between sources and applications and providean external interface. For instance, a locationwidget retrieves information from the GPS sen-sor which provides the longitude and latitudeposition of the user, and establishes a publicinterface for applications. To access the data, anapplication posts a request to the widget andobtains the location information to use it inter-nally. The widget design constitutes a process ori-ented architecture model that uses asynchronousrequests (publish/subscribe). An advantage of themodel is that multiple sources can be combinedto derive context information of higher complexi-ty. In addition, the model enables the exchangeof widgets of the same type of information suchas a GPS widget and a W-LAN widget for loca-tion information. However, the model is less flex-ible for applications to subscribe and unsubscribeto widgets when user contexts quickly changes.Furthermore, the architecture is less robust tofailures of internal components [4] (Fig. 1).

A more sophisticated approach is the black-board architecture that enables applications toretrieve context by means of a subscription to acentralized component, the blackboard. Thisblackboard manages the internal informationretrieval and notifies applications when a prede-fined event occurs. To obtain specific contextinformation, an application requests the black-board or gets a notification about an event thatoccurred. The blackboard design is a data-cen-tric architectural model which provides asyn-chronous notifications to inform subscribedapplications. On the one hand, the advantage ofthe model is the ease of adding new or exchang-ing sensors and the ability to provide a flexibleconfiguration for dynamic changes. On the otherhand, the model is less efficient in communica-tion because requests are made via a centralizedserver (blackboard) as well as synchronizationflaws occur since the order of inference opera-tions is not predefined [5].

Figure 1. Widget and blackboard context management models.

Widget model

Widget

Sensor

Application Application Application...

...

...

Widget

Sensor

Widget

Sensor

Widget

Sensor

Blackboard model

Sensor

Application Application

Blackboard

Application...

...

Sensor Sensor

SensorWrapper Wrapper


IEEE Communications Magazine • January 201162

LAYER DESIGN FOR CONTEXT INFRASTRUCTURES

Although the context management models differin their design approach, most of the contextarchitectures apply a layered structure that splitsthe process of retrieving context information,processing the information, and providing it tothe application into five sub steps [3].

The sensor layer detects and registers newsources for context relevant information whichcan origin from physical, software, or logical sen-sors. For instance, this can be a GPS system(physical), a browser sensor to identify currentactivities (software), or a combination of sensorsto derive information by logical reasoning (logic).

The raw data retrieval layer provides interfacesto retrieve sensor information using more abstractfunctions. For example, the function getPosi-tion() can be provided by the layer to abstractdata retrieval from GPS or WLAN sources.

The preprocessing layer raises the complexityinto high level context information by interpretingthe available raw data. This is done by quantifica-tion and extraction of raw data and the handlingof conflictive, ambiguous, or uncertain informa-tion. For instance, when sensor data shows that itis Sunday evening, the user is at home and thebrowser accesses a social network, the context ofthe user can be interpreted as leisure time.

The storage/management layer stores contextinformation enables learning algorithms toenhance the inference and provides public inter-faces using both synchronous and asynchronouscommunication approaches.

The application layer implements the applica-tion and is primarily concerned with the userinteraction. Depending on the implementation,this layer can be detached from the infrastructureand can be integrated in third Party services.

SERVICE DESIGN AND ARCHITECTURE

OVERVIEWIn this article, we propose a telecom operatorsservice which allows users to enrich their mobileapplications with context information and thusenable their cell phone to be context aware. Atelco is particularly suitable to offer such a plat-form because it is an intermediary between theuser, who gets access to the communication net-work, and software developers, who use the NGNto provide enriched software solutions beyond theboundary of Internet. To leverage the position asan intermediary is of major importance because asingle application has less potential to aggregateall necessary information which is required toimplement the full functionality of context infer-ence and to include sensors in a uniform, stan-

dardized manner. The service itself has a userinterface on the mobile device which allows usersto connect an application to the platform. Onceconnected the application transmits user informa-tion to the platform and in turn gains access toinferred context information. This confirmationaddresses potential privacy concerns of the userand is similar to the approach that has been takenby social networks or mobile operating systemswhen installing new software (Fig. 2, steps 3–6).

Unlike context inferences services that havebeen proposed for large-scale deployment so far[6], the telco service involves mobile applicationdevelopers within the context inference processitself. In other words, developers can suggestrules how the information they provide have tobe processed with existing context informationfrom the platform in order to infer additionalcontext information of higher meaning. To real-ize this, the service requires developers to applyat the telco for authorization at first (Fig. 2, steps1 and 2). During this review process, the telcoprovides the current context model to develop-ers. That can be a list of high level context cate-gories such as location, social environment, oractivity. For each category, a set of predefinedstates and the information sources that supportthe particular inference is given. As an example,the category social environment could distinguishbetween business context and leisure context andenlist social networks, calendar, and GPS infor-mation as sensors to identify the state. Develop-ers in turn can analyze how their information cancontribute to the inference of a state or can iden-tify new, more complex states. Additionally, theyindicate which rules have to be applied for theinference. That could be a set of statements inthe form of “if state in category X is A, then thestate in category Y is B.” In case an applicationgets the approval by the telco, users are able toconnect the application into the context service.In that case, the service informs the user aboutall information that is exchanged between theplatform and the particular application. Eventhough the service design heavily involves appli-cation developers, the right to process, manage,and distribute context information still remainsexclusively at the telco, which was authorized bythe user at first place.

BENEFITS TO THE USER, DEVELOPERS, AND TELCOS

When taking the user’s perspective, the platformenables the cell phone and its applications to besmart and context-aware as described initially.Two distinct improvements in mobile applica-

Figure 2. Applications need to register in advance to be connected by the user to the context service.

User Context service interface on the cell phone

Applications

(6) Enables context-aware services

(1) Applies to the context service

(4) Provides user information

(5) Provides context information

(2) Confirms after review

(3) Connects application

Although the con-

text management

models differ in their

design approach,

most of the context

architectures apply a

layered structure that

splits the process of

retrieving context

information, process-

ing the information,

and providing it to

the application into

five sub steps.



tions can be distinguished, that is to pre-selectinformation, which is pulled by the user to reducethe user interaction or to proactively push infor-mation to the user in order to enable new formsof interaction. For instance, a cell phone can pre-select the business calendar or contacts whenbeing at work or proactively remind the user toby items in a shop nearby when leaving the officeto meet with friends. Such services reduce timeand effort for the user to search for relevantinformation as well as enable a new set of inno-vative mobile applications. In consequence, tele-com operators could consider a fix rate plan forthe user market as an eligible option to build abusiness case. This would enable telcos to lever-age their intermediary position and to bind theircustomers closer to them.

Application developers on the other side getthe opportunity to enhance their service offeringand thus increase the potential for additional rev-enue. That allows a developer business casewhich could be in the form of a revenue sharingmodel. In general, the crux of the service designis to provide incentives to the developers to con-tribute high quality user information. A businessmodel could charge every registered applicationwith a subscription fee. These fees would beredistributed among the developers according tohow often their contributed information is usedby other developers to infer a context. Forinstance, the shopping reminder uses locationand social environment information to measure ifit is appropriate to push shopping information.Hence, developers of these sensors would earn ashare of the fee. As a consequence, those devel-opers who drive sales when using context infor-mation are willing to pay for it and those whocan provide valuable user information can gener-ate revenue beyond the subscription fee. In thisbusiness model, telecom operators could set aservice fee of several percentages for providingthe infrastructure and maintenance of the system.

On the telecom operator side, the servicedesign has particular benefits in comparison toother approaches that have been proposed [6].First, less effort has to be spent to have the ser-vice scaling up and to become widely used. Byproviding incentives to register an applicationand to offer valuable user information, thirdparty developers relief the burden of the telco toaggregate and preprocess user information on itsown. Second, there is more context informationavailable which enables a more accurate and lesserror-prone context inference. This is because ahigh amount of sensors allows compensating sen-sor failure with complementary ones and increasereliability of inference. However, particular atten-tion has to be paid to ambiguity or conflicts ininference rules and sensor information as well asto complexity in the inference structure.

IMPLEMENTATIONThe implementation of the service is embeddedwithin the IMS infrastructure of the telco. It usesa state-of-the-art blackboard context managementmodel and organizes the infrastructure in fivefunctional layers, i.e., sensor, raw data retrieval,preprocessing, storage/management, and applica-tion layer. The interface implements common SIP,

HTTP/SOAP, or HTTP/REST protocols and usesan ontology-based context model in combinationwith XML. This section focuses on the interfacedesign and the inference process and presents anew approach to process the context informationwithin the preprocessing layer. The article makesparticular effort to illustrate how that is suitable tothe service design described earlier.

INTERFACE DESIGN TO DEVELOPERSRegarding interfaces to developers, it is impor-tant to distinguish among interfaces to externalsensors to obtain user information and interfacesto applications to provide context information.External sensors can be integrated either by theSession Initiation Protocol (SIP) or HTTP usingSOAP or REST compliant communication. Inparticular, the interface uses theSUBSCRIBE/NOTIFY capabilities of the SIPEvent Framework to implement asynchronousevent handling and reliable session control. Inthis case, telcos will poll the information, exter-nal parties will upload the data or event-basedcommunication will be used. On the other hand,HTTP/SOAP and HTTP/REST represent com-mon synchronous and client-triggered communi-cation protocols for web services. This approachallows developers to use existing web standardsand to implement the interface with less effort.

The context retrieval instead implements onlythe SIP protocol because changes in context arefrequently sent between the server (platform ser-vice) and the client (application). An implemen-tation using synchronous protocols such asHTTP would require the client to constantly pollfor updates from the server or to developworkarounds.

Towards applications, the platform provides aSIP API for Java and major mobile operatingsystems such as Android (Google) , iOS(iPhone/Apple), and webOS (Palm). The JavaAPI can be implemented by J2ME-based Midletson mobile devices as well as Servlets of web ser-vices. The SIP communication is realized usingSIP J2ME Specification (Java SpecificationRequest [JSR] 180) that is based on MobileInformation Device Profile (MIDP) 2.0 and SIPServlet Specification (JSR 116) for web services.The SIP interface has been developed by theJava Community Process to enable SIP servicesto resemble the common Java Servlet architec-ture, also called SIP servlets. For applicationsthat are based on the Android OS, iOS orwebOS, a similar approach is taken. Even thougha particular SIP API has not been released forthese operating systems so far, SIP arises ashighly suitable to leverage proactive, push-basedcommunication and low battery drainage. TheSIP API particularly provides listener and notifi-cation classes to enable asynchronous communi-cation that can be used between the platformand the sensors either to provide context infor-mation or transmit user information.

The HTTP/SOAP API and HTTP/REST APIallow establishing a loosely coupled communica-tion towards sensors enabling developers toimplement lightweight protocols on the basis ofpopular web standards and XML communica-tion. This synchronous API can be used for pro-viding user information to the platform (Fig. 3).

The implementation

of the service is

embedded within

the IMS infra-

structure of the

telco. It uses a state-

of-the-art blackboard

context management

model and organizes

the infrastructure in

five functional layers:

sensor, raw data

retrieval, preprocess-

ing, storage/manage-

ment, and

application layer.



COMMUNICATION LANGUAGE FOR CONTEXT

In respect of the communication language, anontology-based context model such as WebOntology Language (OWL) that is embedded ina PIDF specified XML-based communication isused.

The context model provides high-level ontolo-gies for context information such as movementand position for the domain location. If thedomain allows a more detailed specification,additional subdomains are provided. For exam-ple, position could be distinguished in moredetail, namely at home, office, and city center.This structure forms an ontology-based hierar-chical tree as a suitable model to provide thirdparty developers with a simple, flexible andexpressive context model [7].

To realize this approach, the service uses thePresence Information Data Format (PIDF) as aXML specification for exchanging context infor-mation (RFC 3863). Additionally, the Rich Pres-ence Information Data Format (RPIDF) and itsTimed Presence extension, both backwards com-patible with PIDF, are used to include morecomplex and historic/future context informationif available (RFC 4480 and RFC 4481). This

approach particularly ensures a standard compli-ant communication and allows applications andplatform to exchange required information suchas context domain, time stamp of the informa-tion and a confidence value to trade-off betweenconflictive information.

MANAGEMENT AND PROCESSING OFCONTEXT ON TELECOM OPERATOR SIDE

We propose a context architecture that resemblesa state-of-the-art context layer design (sensor, rawdata retrieval, preprocessing, storage/manage-ment, and application layer) and is designed afterthe blackboard context management approach. Inparticular, the sensor layer is realized by a set ofdistributed sensors (hardware, software, or logicalsensors), which register via SIP REGISTER mes-sage or HTTP POST requests at the raw dataretrieval layer (Fig. 4). Having registered to theplatform, the sensors implements a topic-basedSIP PUBLISH/SUBSCRIPTION communicationor again HTTP to transmit the user informationto the platform. Having obtained the sensor infor-mation, the platform categorizes the user infor-mation according to its context domain. Thisallows the raw data retrieval layer to provide

Figure 3. The service architecture.

Sensors

Communication infrastructure

Web services

SIP/HTTP

SIP/HTTP SIP/HTTP

SIP/HTTP

SIP

SIP

SIP/HTTP

SIP/HTTP

Mobile devices Urban

environment

Workstations

www

www

Context service

User’s cell phone

Context service

Context-enabled mobile applications

We present a

module-layer

structure for the

context manager

which is located in

the preprocessing

layer of the infra-

structure. This

approach delivers

several benefits: it

allows inferring

context information

more gradually,

hence reducing com-

plexity, and enables

developers to extend

and adapt the

functionality easily at

runtime.



functions to the preprocessing layer that abstractfrom the type of sensor and instead focus on itscontext domain. The inference of context itself isdone in the preprocessing layer using a module-layer design. This step is described in more detailin the next section. The storage/managementlayer handles the storage of information, thelearning process based on previous (domain andcontext) information as well as provides an inter-face to the applications. In particular, the storageof information is done by calling the functions ofthe raw data layer or requesting context informa-tion from the preprocessing layer and storing theinformation into the database. Additionally,learning algorithms are applied on raw data andhigh level context information to derive patternthat contribute to the quality of context inference.The interface uses SIP protocol and applies thePIDF or RPIDF specification for XML-basedcommunication to provide context information toa set of distributed clients that are connected tothe platform.

A CONCEPT TO PROCESS CONTEXTThe inference of context in particular is a com-plex process since information can be conflictive,ambiguous or uncertain and because context ismostly inferred by implicit rules. Therefore, wepresent a module-layer structure for the contextmanager which is located in the preprocessinglayer of the infrastructure. This approach deliv-ers several benefits: it allows inferring contextinformation more gradually, hence reducingcomplexity, and enables developers to extendand adapt the functionality easily at runtime. Inaddition, it incorporates a structure that counter-vails synchronization issues as well as it resem-bles the internal ontology based context model.

The design organizes three layers according tothe degree of their complexity starting from pro-cessing raw data up to high-level context informa-tion (Fig. 5). Furthermore, each layer can use theinformation that has been inferred within one ofthe layers before. For instance, the low complexi-ty layer requests location information (e.g., GPS)and the browser activity from the raw data layer.This information is used to infer what locationdomain (e.g., home, office, city center) and brows-er activity domain (e.g., social networks, compa-ny’s intranet, and news) applies to the user’scurrent situation. The medium complexity layeruses this context information to identify the user’sactivity domain. As an example, the user is athome but accesses the office computer at workvia browser login. Hence, the user’s activitydomain is work. The high complexity layerrequests time and date from the raw data layerand the activity domain from the medium com-plexity layer to anticipate potential activitiesbased on learning algorithms. For example, theuser always works from home on a Monday morn-ing but leaves at 1:30 pm to take public trans-portation. Consequently, the high complexitylayer could infer a high probability for the upcom-ing context to be train for the movement domain.

To translate lower level information intohigher-level information, each layer contains aset of modules. A module infers a particularaspect of the user’s context by resembling thedomains of the ontology based context model. In

the example above, raw data information wasused to infer the location domain and browseractivity. To realize this, the low complexity layerwould contain two modules, one for the locationdomain and one for the browser activity. Thesemodules infer the particular context domain andprovide the information back to the low com-plexity layer which in turn can provide the infor-mation to the medium or high complexity layer.

Modules can be added or adapted at run-time and sensors can be connected or discon-nected since they can be substituted by others.Also information conflicts, uncertainty, andambiguity are managed by the modules internal-ly. This is done by requesting required informa-tion, quantification of the information usingstatistical methods, fuzzification, which is to ana-lyze if the quantified value is within or outside apredefined value and finally to apply rules toinfer the context information [8, 9].

FIRST EVALUATION ANDLESSONS LEARNED

As a first prove of concept for the module-layercontext inference design, a simplified version ofthe service has been implemented in the form ofa Java Servlet (platform) and an Android-basedmobile client. Three sensors were developed, amobile GPS (hardware) sensor, a social network(software) sensor, and a logical sensor andimplemented in the module-layer structure with-in the preprocessing layer. By using the conceptof neural networks, particularly the NeurophJava Neural Network Framework, the applicabil-

Figure 4. Processing of context information within the service infrastructure.

Context service

Applications

Storage/management

Preprocessing/context inference

Raw data retrieval

Sensors

User information

Context information

Context information

Domain information

Domaininformation

GUTHEIM LAYOUT 12/16/10 12:32 PM 5


ity of rule-based context inference within a mod-ule and the structure as a hole was tested.

Even though not fully implemented, severallessons learnt could be derived from the testimplementation. The approach supports the ser-vice design with an ontology context model and arule-based reasoning that is particularly feasiblefor application developers since it resembles dailylife issues of users. Additionally, the layers providea clear hierarchy, which breaks up the contextinference into several sub-steps, and the modulesabstract from actual sensors. This lowers the com-plexity of inference and makes the platformdynamically extendable and adaptable. However,tests show that particular attention has to be paidto the governance of the platform, which requirestelcos to maintain the logic order of modules with-in the layer structure and monitor conflictive rulesand occurring errors. Moreover, a fast scaling ser-vice can cause an excessive server-client communi-cation particularly for intermediaries such as SIPProxies. In order to address this issue, learningalgorithms can be used to reduce context updatesand schedule requests to the server.

CONCLUSION AND FUTURE WORKContext awareness services have the potential toenhance user interaction on mobile devices if thecontext inference process is scalable, robust andextendable as well as the interface design pro-vides a SIP- and HTTP-based communication.This article presented a service that allows usersto enrich mobile applications with context infor-mation by connecting them with a telecom opera-tor platform. Based on an overview about currentmodels to process context, the service design andits implementation have been described. Thearticle presented a new module-layer approach toresemble context domains within a layered infer-ence structure and a first prove of concept wasoutlined. More specifically, the approach promis-es more accurate context inference, which is lesserror-prone at the same time. Additionally, the

service design is supposed to have a faster adop-tion by third party developers and thereforescales up faster. Future research needs to investi-gate how the module-layer structure can be main-tained and governed as well as the server-clientcommunication can be reduced.

ACKNOWLEDGMENTThis research was funded by Vodafone R&DGroup Munich, Germany. The author thanksAnas Al-Nuaimi, Petromil Petkov, and JulianPye for their review and valuable input.

REFERENCES[1] M. Ilyas, IP Multimedia Subsystem (IMS) Handbook, CRC

Press, 2009.[2] J. Krumm (Ed.), Ubiquitous Computing Fundamentals,

CRC Press, 2010.[3] M. Baldauf et al., “A Survey on Context-Aware Sys-

tems,” Int’l. J. Ad Hoc Ubiquitous Comp., vol. 2, no. 4,2007, pp. 263–77.

[4] A. K. Dey and G. D. Abowd, “A Conceptual Frameworkand a Toolkit for Supporting Rapid Prototyping of Con-text-Aware Applications,” Human-Comp. Interactions J.,vol. 16, no. 2, 2001, pp. 97–166.

[5] T. Gu, H. K. Pung, and D. Q. Zhang, “A Service-OrientedMiddleware for Building Context-Aware Services,” J.Net. Comp. Apps., vol. 28, no. 1, 2005, pp. 1–18.

[6] Y. Oh, J. Han, and W. Woo, “A Context ManagementArchitecture for Large-Scale Smart Environments,” IEEECommun. Mag., vol. 48, no. 3, 2010.

[7] T. Strang and C. Linnhoff-Popien, “A Context ModelingSurvey,” Wksp. Advanced Context Modeling, Reason-ing, Management, Ubiquitous Comp., 2004.

[8] L. A. Zadeh, “Fuzzy Sets as a Basis for a Theory of Possi-bility,” Fuzzy Sets Sys., vol. 100, no. 1, 1999, pp. 9–34.

[9] S. Guillaume, “Designing Fuzzy Inference Systems fromData: An Interpretability-Oriented Review,” IEEE Trans.Fuzzy Sys., vol. 9, no. 3, 2001.

BIOGRAPHYPHILIPP GUTHEIM ([email protected]) is currently work-ing toward his M.S. in information management and sys-tems at the University of California Berkeley. His researchinterest includes new end-user services in NGN, IMS, con-text-aware systems, and ubiquitous computing. He receivedhis B.S. degree from the Munich School of Management,Ludwig-Maximilians-University Munich in 2009 and anHonor degree in technology management from the Centerof Digital Technology and Management in Munich.

Figure 5. The inference model establishes a three-layer structure.

High complexity layer

Preprocessing/context inference

Storage/management

Raw data retrieval

Movement domain module

Medium complexity layer Activity domain module

Low complexity layer Location domain module

Browser activity module

Context awareness

services have the

potential to enhance

user interaction on

mobile devices if the

context inference

process is scalable,

robust and

extendable as well as

the interface design

provides a SIP- and

HTTP-based

communication.


an ontology-based context inference service for mobile applications in next-generation networks

Documents