Docstoc

NETWORK RESOURCE AWARENESS AND PREDICTION ON .pdf

Document Sample
NETWORK RESOURCE AWARENESS AND PREDICTION ON .pdf Powered By Docstoc
					NETWORK RESOURCE
AWARENESS AND PREDICTION
ON MOBILE DEVICES
Arjan Peddemors
NETWORK RESOURCE AWARENESS AND PREDICTION ON MOBILE DEVICES
      Telematica Instituut Fundamental Research Series 1998 - 2008
    Recent publications
015 G. Guizzardi, Ontological Foundations for Structural Conceptual Models
016 M. van Setten, Supporting People in Finding Information: Hybrid Recommender Systems and
    Goal-Based Structuring
017 R. Dijkman, Consistency in Multi-viewpoint Architectural Design
018 J.P.A. Almeida, Model-Driven Design of Distributed Applications
019 M.C.M. Biemans, Cognition in Context: The effect of information and communication support on
    task performance of distributed professionals
020 E. Fielt, Designing for Acceptance: Exchange Design for Electronic Intermediaries
021 P. Dockhorn Costa, Architectural Support for Context-Aware Applications: From Context Models
    to Services Platforms
022 T. Broens, Dynamic Context Bindings: Infrastructural Support for Context-Aware Applications
023 Y. van Houten, Searching for Videos: The Structure of Video Interaction in the Framework of
    Information Foraging Theory

      Novay PhD Research Series 2009 –
024 L. Efimova, Passion at Work: Blogging Practices of Knowledge Workers
025 S.V. Pokraev, Model-Driven Semantic Integration of Service-Oriented Applications




      For all dissertations in this series see www.novay.nl/dissertations
Network Resource Awareness and
Prediction on Mobile Devices

A.J.H. Peddemors




Enschede, The Netherlands, 2009
Novay PhD Research Series, No. 026 (Novay/PRS/026)
Cover Design:               Morskieft Ontwerpers, Enter
Book Design:                Lidwien van de Wijngaert and Henri ter Hofte
Printing:                   Universal Press, Veenendaal




Novay PhD Research Series, No. 026 (Novay/PRS/026)
ISSN (print) 1877-8739; No. 026
ISSN (online) 1877-8747
ISBN 978-90-75176-71-1
Novay, P.O. Box 589, 7500 AN Enschede, The Netherlands
E-mail: info@novay.nl; Internet: http://www.novay.nl/
Telephone: +31 (0)53-4850485; Fax: +31 (0)53-4850400




                             © 2009, Novay, The Netherlands

Some rights reserved. Except where otherwise noted "Network Resource Awareness and Prediction on Mobile
Devices" by A.J.H. Peddemors is licensed under the Creative Commons Attribution-Non-Commercial-Share
Alike 3.0 Netherlands License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-
sa/3.0/nl/deed.en Permissions beyond the scope of this license may be available at copyright@novay.nl

Digital and hard copies of this work could be obtained at www.novay.nl/dissertations
NETWORK RESOURCE AWARENESS AND
  PREDICTION ON MOBILE DEVICES



                          PROEFSCHRIFT




                  ter verkrijging van de graad van doctor
                   aan de Technische Universiteit Delft,
       op gezag van de Rector Magnificus prof.dr.ir. J.T. Fokkema,
                voorzitter van het College van Promoties,
in het openbaar te verdedigen op dinsdag 20 oktober 2009 om 12:30 uur




                                door
                  Arend Jan Hendrik PEDDEMORS
                     elektrotechnisch ingenieur
                        geboren te Weerselo
Dit proefschrift is goedgekeurd door de promotor:
Prof.dr.ir. I.G.M.M. Niemegeers


Samenstelling promotiecommissie:
Rector Magnificus,                    Voorzitter
Prof.dr.ir. I.G.M.M. Niemegeers,      Technische Universiteit Delft, promotor
Dr.ir. E.H. Eertink,                  Novay
Prof.dr.ir. H.J. Sips,                Technische Universiteit Delft
Prof.dr.ir. S.M. Heemstra de Groot,   Technische Universiteit Delft
Prof.dr.ir. I. Moerman,               Universiteit Gent
Prof.dr. E.O. Postma,                 Universiteit Tilburg
Prof.dr. F.M.T. Brazier,              Vrije Universiteit Amsterdam




Dit onderzoek is ondersteund door het Nederlandse Freeband Kennisimpuls
onderzoeksprogramma (4GPLUS project) en het Nederlandse Freeband Communication
onderzoeksprogramma (Awareness project) onder contract BSIK 03025.
Acknowledgements
Many people supported my research. They inspired me, motivated me to
keep going, helped finishing this dissertation, or contributed to this work in
another way. Let me start by saying that I fully appreciate these efforts –
even though I will not be able to mention all – and that I could not have
finished without them.
    I am greatly indebted for the support I received from my advisers Ignas
Niemegeers and Henk Eertink. Henk helped to initiate my PhD track
within Telematica Instituut (now Novay) while I was a research engineer,
and allowed me to pursue the research I found most worthwhile. His
insightful remarks and always quick feedback improved my work highly.
Although I was an external PhD candidate staying only occasionally in Delft,
Ignas quickly made me feel part of his group. I very much appreciated his
encouragements to explore different lines of research and his open attitude
towards multidisciplinary approaches and methods.
    Special thanks go to my direct collaborators, co-authors, and reviewers
of my work. Through the whole of my PhD track, Mortaza Bargh provided
valuable analysis and feedback. Henri ter Hofte and Raymond Otte helped
with preparing and executing the CoSphere experiment. Bob Hulsebosch
guarded the trial data anonymity. Rogier Brussee and Jan de Gooijer
(Universiteit van Amsterdam) provided input on my prediction ideas. Hans
Zandbelt helped with early mobility management software and experiments.
Kate Wac (now at Carnegie Mellon University), Pravin Pawar (Universiteit
Twente), and Eiko Yoneki (University of Cambridge) initiated spin-off
work. Mortaza, Henri, Bob, Jan, and Kate, gave feedback on parts of this
dissertation.
    Many thanks to all Novay and TU Delft colleagues who supported me
through the years. It was a privilege to share thoughts and company with
Paul Porskamp and Xander van Pelt. Marc Lankhorst encouraged me from
the very beginning to start this track. Chris Vissers and Caroline Kamphuis
helped in the formal transition from an engineering track to a PhD track.
VIII                                                          ACKNOWLEDGEMENTS



       The discussions with the people of the CogNet seminars in Delft provided
       interesting insights and were fun. Also, it was encouraging and helpful to
       exchange experiences with the other Novay PhD researchers. Others who
       supported me are: Johan de Heer, Cristian Hesselman, Ingrid Mulder,
       Maarten Wegdam, Hermen van der Lugt, and Herma van Kranenburg.
       Thanks to the colleagues who participated in the CoSphere experiment.
           My special appreciation goes to the colleagues I worked with in ‘4Gplus’
       and ‘Awareness’, the larger projects of which my PhD work was a part.
       Thanks to Marten van Sinderen (Universiteit Twente), Erik Meeuwissen
       (TNO), Jacco Brok (Sigmax), Aart van Halteren (Philips), and many others.
       Thanks to Ing Widya and Bert-Jan van Beijnum (both at Universiteit
       Twente) for co-supervising Stephan Hegge.
           Finally, I want to thank my daughters, Mara and Ella, for being patient
       when their father had to finish yet another paper or one more chapter
       during weekends. And many, many thanks to Karin, for her continuous love
       and understanding, and for putting up with me throughout this work.

                                                                      Arjan Peddemors
                                           Enschede, The Netherlands, September 2009
             Contents
Chapter 1.   Introduction                                                      1
             1.1 A motivating example                                          3
             1.2 Research challenges                                           4
             1.3 Network resource model and abstraction layer                  7
             1.4 Network event prediction based on best predictor selection    8
             1.5 Contributions                                                 9
             1.6 Dissertation organization                                    10
Chapter 2.   Background and Related Work                                      13
             2.1 Protocol layering                                            14
             2.2 Mobile device connectivity                                   15
             2.3 Protocols for mobility management                            18
             2.4 Network resource adaptation                                  19
             2.5 Network resource models                                      20
             2.6 Event prediction in data streams                             21
             2.7 Trajectory prediction                                        23
             2.8 Mobility prediction                                          24
Chapter 3.   Network Resource Abstraction                                     25
             3.1 Application awareness                                        25
             3.2 Network resource model                                       35
             3.3 Example of NRM usage                                         46
             3.4 Summary and discussion                                       46
Chapter 4.   State Notification and Control                                   51
             4.1 NAL design overview                                          52
             4.2 State notification                                           53
             4.3 State control                                                59
             4.4 NAL system service                                           63
             4.5 Summary and discussion                                       65
X                                                                            CONTENTS



Chapter 5.    Evaluating the NRM and NAL                                          69
              5.1 NAL reference implementation                                    69
              5.2 System resource usage                                           74
              5.3 Ease of deployment and abstraction appropriateness              76
              5.4 Summary and discussion                                          82
Chapter 6     Network Visibility Data                                             85
              6.1 Trial description                                               86
              6.2 Trial execution                                                 91
              6.3 Trace analysis and characterization                             92
              6.4 Summary and discussion                                          99
Chapter 7.    Event Prediction                                                   101
              7.1 Definitions and approach                                       103
              7.2 Kernel density estimation                                      108
              7.3 Kernel conditional density estimation                          114
              7.4 Best predictor selection                                       116
              7.5 Prediction evolution                                           121
              7.6 Analysis of computational complexity                           128
Chapter 8.    Prediction Results                                                 133
              8.1 Comparing strategies for predictor selection                   134
              8.2 Influence of occurrence threshold of event sets                149
              8.3 Influence of multi-network interface information               154
              8.4 Prediction performance evolution with increasing stream size   158
              8.5 Application: prediction of synchronization opportunities       161
              8.6 Summary and reflections                                        163
Chapter 9.    Conclusions                                                        167
              9.1 Contributions                                                  167
              9.2 Reflections and limitations                                    169
              9.3 Future work                                                    173
Appendix A.   Network Resource Model Schema                                      179
Appendix B.   Informed Consent Form                                              195
Appendix C.   Prediction with Variable Event Sets                                197
Appendix D.   Prediction Performance Evolution                                   205
              References                                                         209
              Summary                                                            217
              Samenvatting                                                       219
              Curriculum Vitae                                                   221
                                                              Chapter

                                                                        1
1. Introduction
   In the past several years, personal mobile devices have developed rapidly as
   open computing platforms that can install and run software from different
   origins. Growing hardware capabilities, together with general-purpose
   operating systems and abundant possibilities for network communication,
   have made the mobile device platform an environment that enables many
   exciting applications. The proliferation of these devices on a truly global
   scale brings these applications within reach of a substantial part of the world
   population.
       Most mobile applications beyond simple voice calls depend on access to
   the internet. Often, devices are equipped with multiple wireless network
   interfaces supporting this access through one or more networks, such as
   those based on cellular network technologies and wireless local area
   network technologies. The properties of network resources on mobile
   devices, however, are dynamic in many situations. As users are mobile and
   walk in and out of range of wireless networks, applications on mobile
   devices experience intermittent connectivity or fluctuations in available
   throughput capacity when communicating with other nodes on the internet.
   Mobile applications may benefit from taking into account aspects of these
   dynamics – for instance, by adapting data rates to maximum available
   capacity or controlling when to scan and activate specific networks.
   Furthermore, they may provide a better service to the user when taking into
   account in a proactive manner the availability of these networks over time.
       Solutions exist that assist an application to sustain a communication
   session with another internet node when the device changes its point(s) of
   attachment to the internet. When using these solutions, it is also useful to
   know or to decide which attached networks carry the session packets. For
   this purpose, current operating systems provide a variable set of application
   programming interfaces (APIs) to inform applications about the state of
   available network resources. However, these APIs are mostly operating
2   CHAPTER 1                                                      INTRODUCTION



    system specific and it is hard to link information coming from one API to
    the information of another.
        A unique aspect of personal mobile devices is that they are typically
    carried by their owners on a permanent basis. Additionally, they are
    designed to be always on to assure the owner is reachable by phone or other
    means of communication. Under the assumption that people regularly
    repeat their behavior, this offers an opportunity to predict the availability of
    network resources in the future.

    This dissertation covers two aspects that are important for applications
    dealing with dynamic network resources on personal mobile devices. We
    define (1) a mechanism that provides applications with awareness of and
    control over current resources in a comprehensive, cross-layer way, and (2)
    we describe an approach to predict the future time of the occurrence of a
    network resource event, such as getting into range or moving out of range
    of a particular network, using traces of resource availability in the past.
        We have developed an extensible network resource model (NRM) that
    describes the available network entities and their interrelationships below
    the application layer. Applications can take different views on available
    network resources using the NRM such that they provide just enough
    information to match the applications’ decision making needs. They
    connect to the network abstraction layer (NAL) middleware service on the
    mobile device to be notified of changes and to control available resources.
        To forecast the occurrence of a network event in time, our approach
    keeps track of the probability of this event occurrence given the occurrence
    of another event that already happened. For instance, to compute the
    probability of getting in range of a user’s home wireless local access network
    (WLAN) between now and the next hour, we use the distribution of the
    time difference between moving out of range of the office WLAN (that has
    just happened) and moving in range of the home WLAN, as observed in the
    past. Now, multiple preceding events may exist: we examine strategies to
    select the one to use as the preceding event for the forecast.
        This chapter is organized as follows. In Section 1.1, we provide an
    example that motivates why mobile applications must flexibly adapt to
    dynamically available network resources. Section 1.2 describes the research
    challenges considered in this dissertation. Section 1.3 and Section 1.4 give an
    overview of our approach. Section 1.5 provides a brief summary of the
    contributions of this dissertation. And finally, Section 1.6 discusses the
    dissertation organization.
                            A MOTIVATING EXAMPLE                                                          3



                 1.1        A motivating example
                            To illustrate the importance of awareness of and control over currently
                            available network resources as well as the benefit of a good prediction of the
                            future availability of these resources on mobile devices, we now discuss an
                            example from the healthcare domain. This example is a healthcare monitoring
                            application centering on a personal mobile device carried by a patient. The
                            patient is engaged in regular activities at home and elsewhere and needs to
                            be monitored to anticipate acute as well as chronic health problems or to
                            follow a recovery process. The device gathers data from physiological
                            sensors on the body of the patient and sensors in the device itself. These
                            sensors keep track of the condition of the patient and his surroundings and
                            reflect such aspects as heart rate, blood pressure, electrocardiogram signals,
                            geographical location, acceleration, etc. (see Figure 1-1).

Figure 1-1 Healthcare
monitoring application
which         selectively
uploads sensory data to                                                                       Network A
a healthcare center
                                                                                              Network B



                                                                                  HOME




                                                            TRAVELING

                                                               Network A

                                                                                      critical, real-time
                                                                                     data to healthcare
                                                                                            center

                                                                     non-critical data to
                                                                     healthcare center:
                                                                       now or later?




                            Depending on the patient’s condition, a part of this data must be received
                            in real time by a healthcare center while another part can be received with a
4         CHAPTER 1                                                       INTRODUCTION



          delay of up to a certain maximum. The delayed data is used for diagnosis of
          longer term changes in the condition of the patient. The healthcare center
          analyzes all data and takes appropriate action in emergencies.
              To send the critical, real-time data, the monitoring application keeps track
          of the currently available wireless networks that grant the patient access to
          the internet. It decides upon network usage based on a balanced set of
          criteria such as the maximum speed of the network, the monetary cost of
          usage, and the power consumption per amount of data. If circumstances
          change (i.e., if the set of available networks changes because the patient is
          mobile) and the application determines that another network than the
          currently used network is better suited to carry the real time data, it will
          handover the data stream to the new best network. To do so, the
          application must know about the state of link and network layer entities,
          and must be able to control the activation and usage of these entities.
              The non-critical sensor data is cached on the device but must not arrive at
          the healthcare center too stale. The monitoring application prefers to send
          this data over a high-speed low-cost network, such as the patient’s 802.11
          home network, because the amount of data involved may be large.
          Furthermore, this data must be transferred over a trusted network to
          minimize the risk of loss of sensitive personal data. If it is clear that the
          preferred networks will not be available in time to upload the cached data
          before it gets too stale, the application decides to initiate sending over a less
          suitable network. So, the application needs to be able to identify trusted
          networks, possibly based on technology specific parameters such as the
          basic service set identifier (BSSID) of an 802.11 network access point.
          Furthermore, it uses predictions of the future availability of preferred
          networks (if not available at this moment) to decide to wait or to initiate an
          upload through a less preferred network.


    1.2   Research challenges
          A leading motivation for the work presented in this dissertation was the
          realization that, despite the availability of various mobility management
          mechanisms, mobile applications require a varying level of awareness and
          control over network resources available on the mobile device. This is a
          departure from the layered model of the internet protocol stack, which
          offers a transport layer abstraction to applications and implies that a static
          link exists that can carry the traffic between this host and others on the
          internet. A mobile device simply has a high level of diversity and choice
          when it comes to the configuration and usage of its link(s). Taking this one
          step further, some mobile applications benefit from knowing the probability
          of being in range or out of range of a wireless network in the future,
      RESEARCH CHALLENGES                                                          5



      especially those applications that have a degree of delay tolerance in their
      communication with other nodes. When it is likely that a more suitable
      network will be in range soon, an application may decide to postpone
      communication until then.
          In terms of relevance, it is clear that the mobile device as entry point to
      the internet is becoming a major platform. At the end of the year 2007,
      almost half of the world population (over 3 billion people) owned a mobile
      phone [57]. With a rising fraction of these phones providing access to the
      internet, assistance for applications on these devices to use network
      resources in the best possible way is important.

1.2.1 Flexible network resource abstraction
      Modern mobile devices are equipped with multiple network interfaces that
      provide varying degrees of access to the internet over time. At any given
      moment, the device may be in range of multiple wireless networks that
      grant internet connectivity to the device. The device is then faced with the
      choice to activate or not activate one or more of these links. Furthermore,
      when multiple links are active, for each outgoing Internet Protocol (IP)
      packet the device has to choose the link that will carry this packet.
          Mobile applications often require influence on these decisions: they may
      want to activate a particular network, when available, because it is better
      suited for the kind of traffic the application generates. Or, likewise, when
      multiple links to the internet are available, the application may want to
      force its traffic over one of these links because of the link’s favorable
      characteristics (such as higher speed or prolonged availability over time or
      monetary cost of usage). To influence these decisions, applications need an
      overview of the state of the available network resources (including their
      characteristics) on the device, at the layers below the application layer. This
      state description must indicate the relationships between the entities within
      layers but also between layers, so that an application can find out, for
      example, which link supports an outgoing path.
          Some models exist that define cross-layer entity relationships, such as
      the Management Information Base (MIB) [76] and the Common
      Information Model (CIM) [24], but we found that the scope and objectives
      of these models are much more on remote management of complete
      systems and environments than on supporting local applications.
      Furthermore, they do not support a wide variety of wireless network
      technologies. The IEEE 802.21 standardization effort [55] defines a Media
      Independent Information Service, which provides amongst others a list of
      available networks. This work in progress, however, focuses primarily on
      the realization of fast and efficient handovers.
6          CHAPTER 1                                                        INTRODUCTION



              A main challenge in providing lower layer state information to
           applications is to restrain the level of detail. The application is easily flooded
           with details that are not important for making its decisions on network
           resource usage. We therefore need a flexible abstraction of the network
           resources on the mobile device.

    1.2.2 Unifying mechanism for state update and control
           A major difficulty in providing status information to applications is the
           fragmented, incomplete and often technology-specific view offered by
           system Application Programming Interfaces (APIs). On most operating
           systems, an API exists for obtaining routing table entries, which include
           information about available network interfaces and local IP addresses (e.g.,
           the netlink API on Linux [111] and the IP Helper API on Windows [78]).
           Link technology specific information, however, such as the current 802.11
           WLAN mode of an 802.11 WLAN interface [51] or the Bluetooth nodes in
           range as observed through the Bluetooth interface [52], are provided by a
           wide variety of APIs. In some cases, these APIs are supplied by the
           manufacturer of the interface hardware, which means that even on devices
           with the same operating system and the same type of interface, the way to
           obtain technology specific state information about this interface is different.
               For controlling the network resources, the same APIs can be used,
           although the standard Berkeley Sockets API [120] also gives some control –
           especially over the routing of outgoing packets. This API is the basic
           transport layer interface to applications, allowing them to communicate
           with other nodes using transport layer protocols such as UDP and TCP.
           Some operations on links of different technologies are highly similar, such
           as getting a list of in-range networks for cellular and 802.11 interfaces.
           These generic operations can be found in the technology specific APIs,
           although each may treat this operation differently. So we see that unifying
           this kind of operations would simplify the design of applications.
               A consequence of reading state information through different APIs is the
           difficulty of linking entities together into one single snapshot of the whole
           state. For instance, to associate technology specific interface information
           with routing table entries, the involved APIs must identify interfaces in the
           same way, which is not always the case, or is done in a way that is difficult
           to extract from the documentation. To overcome these problems, we need
           a mechanism that can join the functionality of these different APIs. This will
           greatly improve the necessary effort to build adaptive mobile applications.

    1.2.3 Visibility prediction
           Apart from state information at the present time, applications may also
           consider indications of the availability of wireless networks at a future time.
      NETWORK RESOURCE MODEL AND ABSTRACTION LAYER                                  7



      These indications may help to proactively improve the service offered by the
      application to the user (e.g., by increasing performance or usability).
      Instead of using a less suitable resource available now, an application may
      defer communication with other nodes until a more suitable network
      resource is in range, if, at least, it does not arrive too late. A suitable
      network may be expected to be available on short notice with a certain
      probability (for instance within a few minutes), but also may be expected to
      become available later much later (e.g., many hours or even days from the
      current time). Such an indication therefore is relevant for short as well as
      long time-frames in the future.
           Existing work mainly focuses on predicting the next point of attachment
      to a network in single technology environments (e.g., see [18]), which
      mostly has a short time scope. Furthermore, these approaches are often
      infrastructure oriented, while our focus is on devices having access to a set
      of heterogeneous networks. From an infrastructure point of view, knowing
      the next point of attachment of a device is helpful for efficient and fast link
      layer handovers. Assuming that human mobility is characterized by
      reoccurring patterns, we can use the visibility of networks in the past to
      forecast their visibility in the future. Obviously, a relation may exist between
      the visibility in time of entities from different technologies: e.g., when
      Bluetooth node ‘A’ is visible, the device is highly likely in range of 802.11
      network ‘B’. Or, when cellular base station ‘C’ gets out of range, it is highly
      likely to get in range of 802.11 network ‘D’ in between one and two hours
      from that time. In these cases, we may benefit from taking cross-technology
      visibility relationships into account.
           The challenge now consists of predicting short as well as long term network
      visibility, using all information about all network resources observed on the
      mobile device in the past.


1.3   Network resource model and abstraction layer
      In this dissertation, we propose a Network Resource Model (NRM) and a –
      closely related – Network Abstraction Layer (NAL) to address the challenge of a
      flexible network resource abstraction and the challenge of a unifying
      mechanism for state update and control. We provide a short summary of
      the NRM and the NAL in this section.
          The NRM is a model of the network resources available at the link layer,
      the network layer and the transport layer on a personal mobile device. It
      defines the relationships between the entities at the different layers, such as
      the relationship between an 802.11 network and the IP routes it supports.
      Often, these relationships and their cardinality capture major features of a
      technology. For instance, a cellular network interface can detect multiple
8         CHAPTER 1                                                       INTRODUCTION



          cellular networks in range, but at any given time can only connect to one of
          them. The NRM defines these ‘in-range’ and ‘connected’ relationships and
          their cardinalities between the NRM cellular interface type and the NRM
          cellular network type. Furthermore, it describes the characteristics of these
          entities, such as the maximum throughput speed for links, with a set of
          attributes.
              The NRM is used to describe the current state of the network resources
          to interested applications. The structure of the model is a type hierarchy,
          which can be extended to incorporate new network technologies as they
          become available. As such, it is both flexible in the provided level of detail
          and capable of incorporating the heterogeneity of network resources found
          on mobile devices.
              The NAL is a system service running on the mobile device, used by
          mobile applications to receive network resource state updates and to
          influence this state. This middleware facility allows applications to obtain a
          view on the state of the network resources that is tailored to their needs: it
          provides a mechanism to subscribe to status change notifications in a
          flexible manner, so that an application receives updates with a level of detail
          that matches its decision making process. This mechanism utilizes the type
          hierarchy of the NRM, by letting applications subscribe to the type(s)
          disclosing an appropriate level of information. The NAL offers influence
          over network resources using control messages.


    1.4   Network event prediction based on best predictor
          selection
          To addresses the challenge of wireless network visibility prediction from the
          perspective of a personal mobile device, we propose a prediction method based
          on best predictor selection. We give a short overview of this method in this
          section.
              At any given time, multiple network entities (such as wireless access
          points and base stations, or entire wireless networks) may be visible on a
          mobile device, and often entities are visible in a certain order, reflecting, for
          instance, the traveling from home to work or vice versa. We can therefore
          expect that a time correlation exists between the visibility of network
          entities seen in-order, and that the visibility of one such entity may be used
          to predict the visibility of another.
              Now, by using the historical data on observed network visibility, we can
          construct a probability density estimation of, for instance, the time
          difference between the occurrences of two visibility events (i.e., the event of
          a network or network entity getting in-range or out-of-range). Our
      CONTRIBUTIONS                                                                 9



      approach uses an existing technique called kernel density estimation, to
      construct such estimations. When the first event takes place, we then have a
      predictor for the second event – the event we are interested in. However, at
      a particular moment in time, multiple visibility events may have occurred
      that all predict the visibility of the network entity of our interest. In that
      case, the question arises which one of these predictors is the best. We have
      formulated and evaluated a number of different strategies to select the best
      predictor.


1.5   Contributions
      In this dissertation, we show the necessity for mobile applications to be
      informed of and have control over the current state of available network
      resources at different levels of detail, and we show the benefits of future
      resource availability forecasts. We propose a network resource model
      (NRM) and a network abstraction layer (NAL) middleware facility to
      provide these applications with such resource awareness and control.
      Furthermore, we formulate a prediction method based on letting already
      happened visibility events forecast the future occurrence of other visibility
      events. Our methods of evaluation were based on examining the usage of
      our middleware implementation by a real-world application and using
      mobility traces of real users gathered over a prolonged period of time to
      obtain prediction results. We have made the following contributions:
      – An analysis of the needs of different kinds of applications on personal
          mobile devices to be aware of the locally available network resources and to
          have control over these resources. (Chapter 3)
      – The formulation of a network resource model (NRM) dedicated to flexibly
          express the state of network resources on personal mobile devices for
          the benefit of applications running on these devices. This includes a
          definition of this model suitable to describe resources for common
          mobile devices. (Chapter 3)
      – The definition of a network abstraction layer (NAL), using the above
          network resource model, as a middleware facility notifying mobile
          applications of network resource state changes and allowing them to
          influence this state. Additionally, a reference design of this facility,
          targeting common mobile devices, is provided. (Chapter 4)
      – The evaluation of the NRM and NAL based on a real world audio streaming
          application, using the reference NRM and a NAL implementation on a
          Windows CE device. We show that a NAL implementation can be
          lightweight (i.e., consumes few computing resources) and that it can be
          easily deployed for this application. Furthermore, we show that the
          offered abstraction is appropriate for this application. (Chapter 5)
10         CHAPTER 1                                                          INTRODUCTION



           –   The data set resulting from the execution of a user trial (the CoSphere
               trial). This trial gathered the network traces for 12 participants over a
               period of approximately one month, using the NAL reference
               implementation. It shows that it is possible to simultaneous collect state
               information from three different wireless network interfaces: cellular,
               802.11 and Bluetooth. The data provides insight into the richness and
               dynamics of the visibility of wireless networks from the perspective of a
               personal mobile device. (Chapter 6)
           –   The definition of a prediction method based on best predictor selection, using
               kernel density estimation and kernel conditional density estimation, to
               forecast the next future occurrence that a network entity will be visible
               – based on the observed visibility of other network entities. The method
               defines a number of strategies to select the best predictor amongst a set
               of predictors. (Chapter 7)
           –   The generation of prediction results for our prediction method using the
               data from the trial (CoSphere) and the data from another publicly
               available data set (Rice). Using a cross validation approach on large
               portions of the data set and a particular set of measurement points to
               calculate the performance, we show that in most cases the strategy
               selecting the best predictor based on the highest mean likelihood is the
               best strategy. Furthermore, we found that including predictors of infrequently
               visible network entities results in better predictions using the best strategy
               (i.e., more data results in better predictions). Also, we found that cross-
               technology information in most cases improves the prediction performance. Or, in
               other words, to predict the visibility of entities of a single network
               technology, such as 802.11 access points, it helps to use the visibility of
               other types of entities such as cellular and Bluetooth entities. (Chapter 8)


     1.6   Dissertation organization
           This dissertation consists of two parts. The first part covers the network
           resource abstraction, state notification and state control concerning
           currently available resources. The second part deals with the visibility of
           network resources in the future. Each part consists of multiple chapters, as
           indicated in Figure 1-2.
              The rest of this dissertation is organized as follows. Chapter 2 discusses
           background information and gives an overview of related work. Chapter 3
           provides an analysis of the needs of mobile applications concerning
           awareness and control of network resources and introduces the NRM.
           Chapter 4 shows the application interaction with the NAL and describes the
           NAL design. Chapter 5 discusses the NAL implementation for the Windows
           CE operating system and evaluates the usage of the NRM and NAL by a real
                          DISSERTATION ORGANIZATION                                                11



                          world streaming audio application. Chapter 6 describes the CoSphere trial.
                          Chapter 7 introduces the prediction method and discusses the technique of
                          kernel density estimation applied in this method. Chapter 8 discusses the
                          prediction evaluation method, indicates the prediction results, and provides
                          an example of using the predictions. Chapter 9 summarizes the results
                          presented in this dissertation and provides conclusions and directions for
                          future work.

Figure 1-2 Dissertation
structure
                                                             Chapter

                                                                       2
2. Background and Related Work
   Over the last 10 years, the features and capabilities of small portable
   computing devices connected to the internet have increased rapidly, and
   have now arrived at a point where they offer sophisticated networked
   applications to a large group of users. Dealing with the dynamics in the
   network resources experienced by these mobile devices has been an active
   topic of research. We put our results in perspective by discussing existing
   work in the areas of network resource adaptation and network resource
   prediction. While the adaptation work has a longer tradition, the prediction
   work more recently has gained considerable attention due to the possibility
   of generating mobility traces by monitoring network interfaces on devices of
   real users and by monitoring user mobility from an infrastructure
   perspective (i.e., observing the point of attachment to the network). In this
   chapter, we describe existing work that is generally relevant to our research
   and indicate where our work differs from existing approaches.
       This chapter is structured in the following way. We begin with a few
   sections on background material, covering internet principles and layering
   in Section 2.1, an overview of network technologies found on common
   personal mobile devices (Section 2.2), and a description of existing protocols
   that can be used to manage sessions during mobility (Section 2.3). Then, we
   discuss related work on adaptation to available network resources in Section
   2.4, followed by an overview of existing network resource models in Section
   2.5. Section 2.6 provides on overview of methods for the prediction of
   events in a data stream, and Section 2.7 discusses trajectory prediction.
   Finally, we survey the existing work on predicting the future point(s) of
   attachment to the network infrastructure in Section 2.8.
14         CHAPTER 2                                    BACKGROUND AND RELATED WORK



     2.1   Protocol layering
           The protocols used for internet communication are ordered in the context
           of a layered model. Each layer is responsible for supporting a distinctive
           part of the communication taking place between nodes in a network, and
           offers a well-defined interface to the protocols in the layer above. From top
           to bottom, the internet architecture discerns the following four different
           layers: the application layer, the transport layer, the network layer, and the link
           layer [11]. Sometimes a fifth layer below the link layer – the physical layer – is
           defined. The main benefit of layering is the separation of concerns allowing
           the protocols to concentrate on a dedicated area of functionality, although
           layering also may result in inefficiencies such as duplication of error control,
           (as described in the section ‘Layering Considered Harmful’ in [14]). As our
           research concerns cross-layer interaction and we bypass to some extent the
           information-hiding features of a strictly layered model, we provide a short
           overview of the different layers defined for the internet protocol suite.
               The protocols in the application layer are numerous and serve many
           different applications. A few of these protocols are used to support the
           proper operation of the internet, such as the Dynamic Host Configuration
           Protocol (DHCP) [32] and the Domain Name System (DNS) protocol
           [84]. Many other standardized (as well as proprietary) protocols exist that
           support a service directly to the user, of which the Hypertext Transfer
           Protocol (HTTP) [39] , the Simple Mail Transfer Protocol (SMTP) [63]
           and the BitTorrent peer-to-peer file sharing protocol [23] are a few widely
           used examples. It is likely that some differences exist between the
           popularity of protocols used on fixed hosts compared to those used on
           mobile devices, but in principle any existing application layer protocol can
           be used on mobile nodes.
               The transport layer offers end-to-end communication facilities to
           applications. Compared to the application layer, the transport layer has
           significantly fewer protocols – only a handful – where the stateless User
           Datagram Protocol (UDP) [104] and the stateful Transmission Control
           Protocol (TCP) [103] are by far the most important. More recent protocols
           are the Stream Control Transmission Protocol (SCTP) [121] and the
           Datagram Congestion Control Protocol (DCCP) [64]. We discuss SCTP in
           Section 2.3, because it is capable of sustaining a session between hosts even
           when one or both ends change their point of attachment to the internet, as
           is common on mobile devices. The functionality of the transport layer
           protocols is offered to applications through the Berkeley Sockets API, or
           simply Sockets API [120].
               The core protocol in the internet protocol suite resides in the network
           layer and is called the Internet Protocol (IP). The transport layer protocols
           use IP to send data packets from source host to destination host. Currently,
      MOBILE DEVICE CONNECTIVITY                                                   15



      there are two versions of this protocol: the first publicly-used version 4
      (IPv4) [102] and the later introduced version 6 (IPv6) [29]. The main
      motivation for IPv6 is IPv4 address exhaustion, although to this date the
      deployment of IPv6 is minimal – also on mobile devices. Still, with the
      expected large number of mobile devices to be connected to the internet,
      IPv6 may see a much higher deployment on these devices, which is the
      reason we take IPv6 into account in the definition of our NRM.
          The lowest layer we consider here, the link layer, again incorporates
      many different protocols – as is the case for the application layer. This is
      caused by the many different network technologies used to carry IP packets.
      Examples of these technologies are Ethernet [50] and ADSL [1]. For
      mobile devices, a number of wireless technologies are currently most
      important; we discuss these in the next section.
          The implementation of a set of these above protocols on a host is called
      a network stack or protocol stack. At least one protocol must be available in
      each layer to have a system capable of internet communication. A
      cornerstone of the internet architecture is the end-to-end principle [15] that
      states that for the communication between nodes, no state in the network is
      kept. In reality though, little state is sometimes kept, for instance in case of
      network address translation (NAT) [118].


2.2   Mobile device connectivity
      Modern mobile devices offering connectivity to the internet are often
      equipped with multiple network interfaces. In this section we provide an
      overview of common network technologies that are used to carry IP traffic
      on these devices, to put into context the choices concerning the definition
      of link layer types of the NRM (Chapter 3). Wireless network technologies
      are often classified according to their range, being a wide area network
      (WAN) technology, a local area network technology (LAN) or a personal
      area network technology (PAN).
          The most common interfaces are based on cellular, 802.11 WLAN, and
      Bluetooth technologies, while less frequently used interfaces are based on
      Infrared (IR) signaling or on the fixed Universal Serial Bus (USB)
      technology (i.e., USB is commonly found on modern devices but not always
      configured to support internet access). Other wireless interfaces that are
      not designed for IP communication but sometimes found on mobile devices
      are those based on short range radios such as Radio Frequency
      Identification (RFID) [56] or Near Field Communication (NFC) [34].
          Furthermore, a number of wireless communication technologies
      currently under development or in early deployment are likely to find their
      way into mobile devices in the future, for example IEEE 802.16e (or
16   CHAPTER 2                                  BACKGROUND AND RELATED WORK



     mobile WiMAX) [54] or those based on Ultra-wideband (UWB). Also the
     short-range low-rate ZigBee technology [53], which is, like Bluetooth, from
     the IEEE 802.15 family of standards, may be included. From the above list,
     it is clear that mobile devices are configured – now and in the future – with
     strongly heterogeneous wireless technologies.
          Two concepts that are currently in the research phase are worth
     mentioning here, because, when successful, they may have substantial
     impact on how mobile devices establish wireless connections. The first
     concept is software defined radio [80], which uses general purpose hardware
     such that some or all of the physical layer functions are defined by software.
     It enables mobile devices to connect to different kinds of networks without
     requiring dedicated hardware for each of these networks. The second
     concept is cognitive radio [81], which more efficiently uses the available radio
     spectrum and avoids interference by observing the current spectrum usage
     and changing transmission and reception parameters. This may for instance
     increase transmission rates and reduce power consumption.

     WAN
     The most popular wide-area cellular network technologies deployed today
     are from the second (2G) and third generation (3G), where the GSM
     standard is most widely used for 2G and the UMTS and CDMA2000
     standards are most widely used for 3G. The GPRS extension to GSM
     supports internet data communication with download speeds typically in
     the 28 – 64 kbit/s range. The initial download speeds for UMTS are 384
     kbit/s and for CDMA2000 144 kbit/s, although various enhancements have
     pushed both standards towards speeds of multiple Mbits/s.
         Typically, cellular networks based on these standards have upload and
     download speeds that are asymmetric, i.e., reserve more capacity for
     download than for upload. An important characteristic of these cellular
     technologies is their ability to handover an existing link from one cell to
     another, so that when the user moves, the link is not broken. From a
     network layer perspective, the device remains attached to the internet with
     the same IP address. A cellular interface keeps track of the signal strength of
     nearby base station (which coverage area is called a cell) to initiate handover
     to the best cell. Furthermore, the interface can scan for the availability of
     networks of other operators, to roam from one operator to another – for
     instance when the current operator does not have coverage at a certain
     location. At any given time, the interface can only connect to a single base
     station of a single operator network.
         Typically, the cellular interface on a personal mobile device is always
     connecting to an operator network to allow the owner to be reachable: the
     cellular standards define sophisticated mechanisms to minimize the energy
     level required to stay connected. The monetary cost of generating data
MOBILE DEVICE CONNECTIVITY                                                17



traffic over cellular networks depends on the type of subscription with the
operator; in some cases, subscribers pay per amount of data, in other cases
they pay a flat fee without additional costs.

LAN
Almost all WLANs deployed today are based on the IEEE 802.11 set of
standards [51], having maximum speeds from 11 Mbit/s for 802.11b to 54
Mbit/s for 802.11g. Application level throughput however is often less than
half these maximum rates, and rates are further reduced when the signal
quality between the device and the 802.11 access point becomes lower (as
is the case for the above cellular technologies). Most 802.11 networks
consist of a single access point (AP), although some networks have many
more APs such as those installed on campuses and those deployed by
hotspot operators. The 802.11n standard currently under development
extends the previous 802.11 standards by adding multiple-input multiple-
output (MIMO) capabilities. This standard increases the maximum raw data
rate to 600 Mbit/s.
    As long as a device stays inside one network, its IP address is likely to
remain unaltered, but at the moment the device connects to another
network, the address is highly likely to change. An 802.11 interface
selectively keeps track of in-range 802.11 APs, to switch to a new one when
the currently used AP gets out of range. As with cellular networks, at any
given time an interface can only support a single active connection to an
802.11 network. The current state of technology is such that an 802.11
interface consumes considerable amounts of energy when in use, which is
unfavorable for battery-powered mobile devices. Therefore, 802.11
interfaces are often switched off when not used. Many users access 802.11
networks in their homes or at their workplace without additional monetary
costs.
    Note that some wide area technologies may be extended with so called
femto cells which typically have local area coverage. These cells are part of
the cellular operator network through a plug into a broadband fixed
internet connection.

PAN
On mobile devices, the Bluetooth [52] interface serves a range of different
purposes, often related to exchanging data with other devices and
appliances. Bluetooth version 1.1 and 1.2 have a maximum bit rate of
around 700 kbit/s, while version 2.0 supports a maximum rate of
approximately 2 Mbit/s. As a local-area technology, other Bluetooth nodes
must be in the immediate vicinity of the mobile device.
   To specify the purpose of a device, the standard defines a list of
Bluetooth profiles, such as a Headset Profile to use a device’s mobile phone
18         CHAPTER 2                                 BACKGROUND AND RELATED WORK



           features in combination with a Bluetooth-enabled headset. For internet
           access, two profiles are important: the Dial-up Networking Profile for IP
           over a serial link, and the Personal Area Networking Profile for connecting
           a group of nodes into an ad-hoc network capable of carrying IP traffic. To
           find other Bluetooth nodes, the interface upon request performs an inquiry,
           and those nodes that are in a ‘discoverable’ state reply. This means that only
           those nodes that are discoverable can be detected. Bluetooth
           communication is power efficient and in many cases a mobile device
           therefore can keep the interface active on a continuous basis without
           draining the battery too much.


     2.3   Protocols for mobility management
           A number of network layer and transport layer protocols are able to sustain
           end-to-end sessions in case of a change of attachment to the internet. We
           provide an overview of these protocols here, because their mobility
           management features makes them candidates to be deployed on personal
           mobile devices. In the next chapter we show that our NRM is capable of
           accommodating Mobile IP and SCTP protocol state. Note, however, that we
           do not rely on the availability of an implementation of these protocols on a
           mobile device: we observed that these protocols do not have a widespread
           deployment on currently available high-end devices. For those devices,
           applications must deal with reestablishment of session themselves.
               Most transport layer connections are interrupted when one of the end
           points changes its IP address. The Mobile IP protocol [99][59] tackles this
           problem by making sure that a mobile node always has a static IP address:
           the home address. This is the address the node gets when in the ‘home
           network’. When attached to the internet at another point, the node (or an
           entity in the foreign network called the ‘foreign agent’) establishes a tunnel
           to the ‘home agent’ in the home network, so that any traffic directed to the
           home address will be received over the tunnel. By setting up connections to
           other nodes using the home address, the connections will be maintained in
           case of roaming. The main disadvantage of Mobile IP is the inefficiency of
           routing traffic through the tunnel, which makes the path between source
           and destination longer. This is fixed by a feature called ‘binding updates’,
           which can notify the other end of the real location of the mobile node, but
           this requires the other node to be Mobile IP aware. Mobile IP
           implementations typically work with a virtual interface, representing the
           tunnel that uses real network interfaces to carry the tunnel traffic.
               Another approach to managing dynamics in the points of attachment to
           the internet is to use a transport layer protocol that can change a session’s
           IP addresses on the fly: the SCTP protocol [121]. An SCTP connection is
      NETWORK RESOURCE ADAPTATION                                               19



      called an association, and can have features from both UDP and TCP
      communication (i.e., can choose between reliable and unreliable transport,
      between ordered and unordered delivery, etc.). Every end point in an
      association can consist of more than one IP address. Furthermore, SCTP
      has an extension that defines the dynamic reconfiguration of addresses
      involved in an association [122], so that an association can be maintained in
      case of roaming. Obviously, end points that want to communicate using
      SCTP must have SCTP functionality and existing applications using other
      transport layer protocols must be changed to benefit from the features
      offered by SCTP.
          Apart from the above standards track protocols, a number of
      experimental and research oriented protocols exist that provide a solution
      to maintaining connections in case of mobility. The Host Identifier
      Protocol (HIP) [85] works by decoupling the node identifier role and the
      locator role of an IP address, using a separate Host Identity namespace (see
      also Section 3.4 for further discussion). The approach described by Snoeren
      [116] uses a session token to let TCP connections continue after a host
      changes its IP address.


2.4   Network resource adaptation
      The challenges concerning the adaptation to available network resources
      and the influence on these resources have been quite extensively
      investigated from different perspectives. In this section, we describe a
      number of approaches dealing with these challenges.
          The API presented in [6] shows similarities with our NAL interface. It
      has a modular architecture and defines a query interface for retrieving link-
      layer information structured as a type hierarchy. It focuses primarily,
      however, on the link layer – rather than providing a full cross-layer
      interaction – which makes it harder for applications to take into account
      relevant network- and transport layer aspects such as available paths and the
      state of mobility-management facilities. Furthermore, it does not show how
      the different application needs are handled.
          The authors in [109] provide a formal definition of network context for
      ad hoc mobile nodes. They primarily look into specifying ad hoc network
      topology within the vicinity of a mobile host and define the cost for paths
      taken through this topology, but they do not elaborate on other aspects,
      such as mobility-management facilities.
          Many approaches focus on the adaptation of mobile applications to
      changing resources. The work we present proposes a means of supplying
      information about network resources so that applications can adapt, but
      doesn’t specify a mechanism for application-layer adaptation itself. The
20         CHAPTER 2                                 BACKGROUND AND RELATED WORK



           actual strategies for adaptation or mechanisms forcing the application in a
           certain form to adapt are important, however, because they provide hints
           on what kind of information is relevant. The Odyssey platform (for adaptive
           mobile data access) models the adjustment of applications around the high
           level concepts of agility and fidelity. The adaptation functionality is divided
           between the application and the operating system. Experience with this
           system shows that adaptation must strike a balance between agility and
           stability [88]; for a more continuous service to the user, rapid changes in
           network resources must not always result in swift adaptation. The system
           proposed in [47] delivers multimedia streams to mobile hosts. It uses an
           application-level protocol, based on the SIP and SDP standards, which
           supports stream adaptation in case of changing network resource
           availability. The media player application makes adaptation decisions based
           on information about changes in attachment to the internet, the user’s
           preferences, and the offered quality levels of the media stream.
               Other researchers have also proposed many solutions to separate actual
           mobility management from application logic, be it at the network layer or
           the transport layer, to hide most or all roaming aspects for the application.
           Our work argues against such a separation for certain types of applications.
           One proposed mechanism [128], for example, is based on Mobile IP in
           which the host has multiple home addresses to support the concurrent use
           of multiple network interfaces. It defines an API to control the mobility-
           management process, but does not provide details on how applications can
           conveniently use it.
               In our definition of the NRM, a mobile host can provide multiple
           facilities for mobility management to handle the dynamically changing
           internet attachment points. Another work [129] introduces a mechanism
           that adapts mobility management depending on the application’s behavior –
           that is, the kind of connection the application initiates. The application
           itself is not adaptive.
               A completely different approach is followed by applying cognitive
           techniques to resource adaptation. An outline of challenges and possibilities
           of this approach is provided in [31].


     2.5   Network resource models
           When we started trying to provide better support for network resource
           adaptation in mobile applications, we realized that two basic aspects were
           lacking. First, we needed a mechanism that let applications look further
           down the protocol stack through a view that matched their needs. Second,
           we needed a model to explicitly describe the network resources in a cross-
           layer fashion that could produce these flexible views. Such a model needs to
      EVENT PREDICTION IN DATA STREAMS                                             21



      capture essential characteristics of entities at several layers and, equally
      important, indicate the relations between them. Surprisingly, we found that
      such a model did not exist: the management information base (MIB) types
      [76] and the types of the Common Information Model (CIM) [24] do
      define cross-layer entity relations, but the scope and objectives are quite
      different; for instance, they do not support a wide variety of wireless
      networks.
          The IEEE 802.21 standardization effort [55] defines a Media
      Independent Information Service, which provides amongst others a list of
      available networks. This work in progress, however, focuses primarily on
      the realization of fast and efficient handovers.


2.6   Event prediction in data streams
      The visibility of network resources over time, as observed on a mobile
      device, can be described with a data stream consisting of event occurrences.
      These occurrences indicate when a resource gets in range and when it goes
      out of range. As our objective is to forecast the visibility of these resources
      in time, we are, at a more generic level, interested in forecasting these
      events in a data stream. Extracting knowledge from data streams, including
      predicting patterns and events, is an active area of research ([41]),
      stimulated by the abundant processing and memory resources available on
      modern computing equipment and the increasing availability of data
      streams, for instance in the form of sensory data. Data streams are analyzed
      for varying purposes, each with their own set of computational tools.
      Although many of these tools do not fit our purpose of predicting the time
      of the next occurrence of an event of interest (or only partly fit this
      purpose), we provide a short overview of the most relevant ones, to place
      our own approach into context. For a more complete overview on temporal
      knowledge discovery and temporal data mining, see [108] and [2].
          In time series analysis ([10]), the data usually consists of a sequence of
      numerical values, with observations at equally spaced intervals of time. The
      objectives are to find cycles, trends, and shapes in the data to characterize it
      and forecast future data points. It is clear that our event-based stream does
      not fit into this paradigm, because it is not numerical and observations are
      not necessarily on fixed evenly spaced times. Therefore, techniques from
      time series analysis are not directly applicable to our problem.
          Another frequent objective is to predict the sequence of events in a data
      stream. This problem is concerned with the logical order of events, not the
      exact timing between events, and therefore, like time series analysis, less
      applicable to our problem. Additionally, it often assumes that events occur
      in-order, while in our case multiple events may occur at the same time.
22   CHAPTER 2                                 BACKGROUND AND RELATED WORK



     Approaches to tackle this problem originate from such domains as natural
     language processing and data compression. An example of such an approach
     is to model sequences using n-grams (see [73], pp. 191). An n-gram is
     assigning probabilities to observing a next event given the (n – 1) previous
     events. They are comparable to (n – 1)th order Markov models. In natural
     language processing, n-grams are used to predict the next occurrence of a
     character in a text, or, at a higher level, the next occurrence of a word or
     phrase in a text. Additionally, n-grams may be constructed as hierarchies, to
     capture patterns of varying lengths and to increase prediction performance
     ([101]).
         The work presented in [74] focuses on a particular kind of temporal
     pattern called a T-pattern. It indicates the relationship between the
     occurrences in time of two events, by using the time distance between them
     as observed in the past. If this distance is frequently within certain
     boundaries, called the Critical Interval, the relationship between the two
     events is marked as a T-pattern. The critical interval is chosen such that the
     number of observed time distances within the interval is higher than
     expected when the two events were randomly distributed in time. The
     algorithm for determining T-patterns takes into account that T-patterns
     themselves may consist of other T-patterns, so that a pattern hierarchy may
     be built. The T-pattern approach was applied to various problems from the
     domain of behavioral research, e.g., to find patterns in the interaction
     between two playing children.
         This approach is somewhat comparable to ours. We also use the time
     relationships between two events as a starting point. Furthermore, both
     approaches do not consider the strict ordering of events as is the case with
     n-grams. However, our method models the relationship between two events
     using both the regular probability density of the relative distance and the
     conditional probability density of occurrence times relative to a chosen
     stream periodicity (see Chapter 7). The regular density has some overlap
     with a T-pattern, but it contains more information (i.e., assigns a
     probability to the occurrence of the event of interest for every possible
     future interval, which is not supported by a T-pattern). The conditional
     density is not present in the T-pattern approach, although it may be
     adapted to incorporate periodicity information. We do not accommodate
     hierarchies and the computational effort involved with calculating densities
     is most likely higher than with determining T-patterns. The biggest
     difference, however, is that the T-pattern approach is designed to find
     patterns, while our approach is designed to predict events. Both approaches
     model the occurrence of an event of interest in relation to the occurrence
     of a preceding event. However, at any given time, multiple preceding events
     may have occurred, thus supplying multiple models for the prediction of
     the event of interest. Our approach explicitly deals with this situation by
      TRAJECTORY PREDICTION                                                      23



      formulating strategies for selecting the best model in such a case; something
      which does not exist in the T-patterns approach.
          In some situations, a spatial component is added to the data stream,
      such that event occurrences are associated with both a moment in time and
      a geographical location. The work presented in [13] considers such a case,
      to predict in time the occurrence of criminal incidents at locations in a
      specified geographical area, given a set of particular constant features such
      as population density, household income, shortest distance to highway, etc.
      Although the presented approach uses density estimation like we do, it is
      not comparable because it does not predict events of interest relative to
      other events. Using geographical information, however, may be a means to
      improve the prediction performance in our approach, for instance, by
      defining arriving at a particular location as a preceding event and use that
      event to predict the event of interest. Another example of spatio-temporal
      forecasting, focused at numerical (time series) values, is the work presented
      in [71].


2.7   Trajectory prediction
      A specific instance of geographical data prediction is trajectory forecasting.
      This is relevant to our approach, because the observation of trajectories
      coincides with the observation of network entities in case these entities have
      a fixed geographical location. Methods for predicting trajectories therefore
      may be applied to predict the visibility of stationary networks. Obviously,
      the visibility of non-stationary network entities can not be predicted in this
      way.
          The work in [42] is concerned with recognizing ‘trajectory patterns’,
      called T-patterns (not to be confused with the T-patterns described in the
      previous section), which mark the geographical locations observed on a
      trajectory and the time spent to move from one location to another. It
      mainly focuses on mining frequent trajectory patterns, not on predicting the
      course of a trajectory given previous data. The proposed approach can not
      be directly applied to our problem because we do not assume to have
      geographical location as input data. However, in case we do have combined
      network visibility and geographical location data – which is not unrealistic
      given that many modern mobile devices come equipped with GPS receivers
      – the proposed method is an alternative to ours.
          The method presented in [66] focuses on predicting routes between
      locations where the user often resides (called ‘bases’), using GSM cell traces
      as data. Paths between locations are clustered together when they are
      similar. Time aspects such as the duration of routes and length of stay in
24         CHAPTER 2                                 BACKGROUND AND RELATED WORK



           bases are not incorporated, which makes this approach less suitable for our
           problem.


     2.8   Mobility prediction
           Mobility prediction is concerned with the forecasting of future point(s) of
           attachment (or potential points of attachment) to one or multiple network
           infrastructures. Our prediction problem falls into this category, with a
           specific focus on the time aspect (i.e., when a network resource becomes
           available or becomes unavailable). Most existing work, however, investigates
           the forecasting of the next point of attachment to a single infrastructure, and
           therefore does not consider the – possibly long term – future visibility of
           arbitrary network entities (see for example [70][9] and also [18] for a
           survey).
               The authors in [117] compare a number of prediction algorithms using
           real-user 802.11 infrastructure traces. The prediction concerns the next
           access point given a history with a fixed or dynamic length, using an n-order
           Markov model approach and a compression-based approach. Our approach
           differs in the sense that our primary interest is in the time aspects of
           visibility and not the logical order. Also, our dataset is produced on the
           device side, not in the infrastructure, and therefore gives a more complete
           view on what is visible from the mobile device perspective, although it is by
           far not as large as their 802.11 traces.
               The approach in [79] considers multi-homed devices but still mainly
           focuses on the next point of attachment. The work in [40] touches upon
           long term predictions, considering the future sequence of in-range entities
           but without looking at the time aspects.
               The following approaches do takes time into consideration. The work
           presented in [68] explicitly focuses on the transient behavior of access point
           association by using a semi-Markov model. The density estimation is based
           on a histogram approach which is known to be, for many situations, less
           accurate than kernel density estimation (which we use). Furthermore, the
           out-of-range prediction is based on the interval duration of previous access
           point associations, which is similar to [69], and does not incorporate a
           conditional parameter as we do or vary the density estimate with the time of
           day. This may influence the density estimation accuracy. The approach
           described in [69] is partially based on parametric density estimation where
           residence time is fitted to a Weibull distribution. Both papers use the same
           data set (the Dartmouth data set available at the CRAWDAD archive [28])
           collected at the infrastructure side.
                                                                Chapter

                                                                          3
3. Network Resource Abstraction
      Mobile devices are often equipped with multiple network interfaces that are
      capable of carrying IP traffic. Applications running on mobile devices have
      variable needs to exploit these resources, and require information
      describing the state of network resources at different layers in the protocol
      stack with different levels of detail. A major difficulty in providing status
      information to applications is the fragmented, incomplete and often
      technology-specific view offered by system APIs. This chapter presents an
      abstraction in the form of a Network Resource Model (NRM) that is both
      flexible in the provided level of detail and capable of incorporating the
      heterogeneity of network resources found on mobile devices. The NRM
      provides an explicit definition of the relationships between the entities at
      the different layers. Interested applications receive status updates based on
      the NRM. The structure of the model is a type hierarchy, which can be
      extended to incorporate new network technologies as they become
      available.
          This chapter is organized as follows. In Section 3.1, we provide an
      analysis of the level of network resource awareness required by different
      kinds of applications. Then, in Section 3.2, we introduce the NRM and its
      type hierarchy. Section 3.3 discusses a number of example applications that
      use the NRM. The final Section 3.4 provides a summary and discussion of
      this chapter. Parts of this chapter are based on [98], [91], [96] and [94].


3.1   Application awareness
      From a data communication perspective, the primary difference between
      mobile devices and more traditional stationary computers such as desktops
      and servers is the difference between a dynamic and a relatively static
      network stack configuration. A traditional host typically has a single fixed
      fully operational Ethernet interface that gets configured at startup, and
26                         CHAPTER 3                                NETWORK RESOURCE ABSTRACTION



                           keeps these setting until shutdown. On a mobile device, however, wireless
                           network hardware can be in any one of multiple modes, such as ‘off’,
                           ‘sleep’, ‘power save’, or ‘fully on’, and can detect multiple networks with
                           different and fluctuating capacity. A mobile device dynamically connects to
                           these different wireless networks and autonomously changes its IP
                           configuration accordingly.

Figure 3-1 Example of a
                                                                           TCP_1      UDP_1
dynamic configuration of
the transport, network
and link layer for a                               UMTS
moving personal mobile                                                    101.1.1.1   102.2.2.2
device                                             802.11g



                                                                           UMTS       802.11g

                                            HOME



                                                                           TCP_1

                                                   UMTS

                                                                          101.1.1.1




                                                                           UMTS
                                          TRAVELING




                                                                           TCP_1      TCP_2       TCP_4
                                                                                       TCP_3

                                                   GPRS
                                    USB
                                                                          101.1.1.1   103.3.3.3   104.4.4.4
                                                   802.11b



                                                                           GPRS       802.11b       USB

                                            WORK


                           An illustration of such a dynamic network stack configuration is provided in
                           Figure 3-1. It shows a personal mobile device with three different network
                           interfaces, carried by an owner that moves from home to work. The figure
                           indicates the stack configuration for the link, network and transport layers
                           at three different locations. The device owner has continuous access to a
                           cellular network based on GPRS and UMTS technology, and wireless LAN
      APPLICATION AWARENESS                                                          27



      802.11g connectivity at home and 802.11b connectivity at work.
      Furthermore, the device connects to a fixed network through a USB serial
      link at work. For every active link, the device obtains an IP address, which
      in turn is used to establish connection oriented (TCP) and connectionless
      (UDP) end-to-end communication with other internet hosts. For example,
      the TCP connection TCP_2 is established using IP address 103.3.3.3
      configured for the wireless LAN interface accessing an 802.11b network.
      Note that the transport layer state may be long-lived: the connection TCP_1
      remains established even when the device owner moves over a considerable
      distance and the link layer technology switches from GPRS to UMTS. Also
      note that a single interface may be capable of connecting to networks based
      on a family of standards rather than a single standard, as is the case for the
      wireless LAN interface (which connects to the ‘b’ and ‘g’ types of networks
      of the 802.11 range of standards).
          In the layered model of the internet protocol stack, the transport layer
      provides the abstraction for end-to-end best-effort message transfer, to
      applications above the transport layer. This abstraction uses the IP address
      of a host in combination with a port number to identify communication
      end points. It hides some of the aspects of the dynamic (re)configurations
      at lower layers, but not all: existing transient state at the transport layer, for
      instance TCP connections, may break in case of an IP address change. For
      traditional computers such as desktop PCs and servers, this rarely poses a
      problem, because the characteristics and configuration of lower layer
      functionality changes infrequently. For mobile hosts, however, this is clearly
      not the case, as shown in Figure 3-1. Mobile hosts often have multiple
      means to connect to the internet – they are multi-homed – which allows an
      application to select the interface and network that best matches the
      application requirements. The Mobile IP mobility management protocol
      deals with this problem effectively (see also Section 2.3), so that, when
      deploying Mobile IP functionality, the regular transport layer abstraction
      suffices also in mobile settings – at least at first sight.
          In this section, however, we argue that many applications running on a
      mobile device must be selectively aware of the state of all layers of the
      protocol stack. We explore the various levels of awareness and control of
      four example applications, and use these results to identify application types.
      Based on these results, we formulate guidelines for defining a flexible
      network resource model.

3.1.1 Example applications
      We describe the network resource usage of the following four mobile
      applications:
      – Web browsing
28   CHAPTER 3                                   NETWORK RESOURCE ABSTRACTION



     –   Remote control
     –   Streaming media player
     –   Video newsfeed
     The applications fall into the following categories: web applications (running
     inside a mobile web browser), wireless control and monitoring applications, and
     multi-media applications. We realize that there are application categories we
     do not cover with these examples applications, such as the category of
     mobile peer-to-peer (P2P) applications and messaging applications (e.g., email and
     instant messaging). Furthermore, we recognize that the mobile device as a
     computing platform is currently evolving very rapidly, which influences the
     kinds of applications being possible and in demand. Still, the four
     applications touch upon a wide variety of network resource aspects, some of
     which also are applicable in other categories (e.g., the remote control
     application may establish direct connections with appliances, which is an
     action also relevant for P2P applications). The guidelines we define later
     using these examples, therefore apply to a broad spectrum of mobile
     applications. We have left out, on purpose, applications with very strong
     real-time requirements such as Voice over IP (VoIP), because these have
     been extensively studied in relation to dynamic network resources, with a
     primary focus on fast handovers [65][107].
         We place some of these example applications in a scenario with a
     particular mobile device configuration and network environment, to clearly
     bring forward important aspects of network resource usage. The
     descriptions below allow us to identify concrete actions taken by real-world
     applications, which subsequently are used to derive different types of
     operations.

     Web browsing
     A web browser uses the Hypertext Transfer Protocol (HTTP) [39] over
     TCP connections to retrieve web pages from a server. When such a TCP
     connection is established over an interface with intermittent network
     access, there is a chance that it will be interrupted. Individual TCP
     connections for HTTP data transfer are typically short-lived and therefore
     not likely to be interrupted due to loss of network access. Additionally, the
     accumulated time that HTTP data is transferred from the server to the host
     (over one or multiple HTTP requests) is relatively short compared to the
     time that no data is transferred, so that a loss of network access is more
     probable at times when no data is transferred.
         We on purpose refer to the time of an HTTP request and not to the
     lifetime of the underlying TCP connection, because of the following. To
     reduce the overhead of repeated handshakes for TCP connection
     establishment and tear-down, the HTTP protocol supports a keep-alive
     mechanism, allowing an HTTP session to send multiple requests over a
APPLICATION AWARENESS                                                      29



single TCP connection. After a request has finished, the TCP connection is
kept open for some time to handle subsequent requests (the default
timeout value for the Apache 2.0 web server [4] is 15 seconds). Therefore,
there is a higher chance on interrupting the underlying TCP connection
than the HTTP request. The cost of breaking an idle keep-alive connection
is limited, requiring only one extra handshake for TCP connection
establishment for the next request.
    In case an HTTP request is accidentally interrupted because the used
interface has lost network access, the web browser making the request may
indicate to the user that the web page or image retrieval failed. Assuming
that the device has access to the internet through multiple interfaces, the
user can easily reinitiate the retrieval of the web page by pushing the reload
button. The request data is then obtained using another interface that has
an active connection to the internet. Alternatively, mobile device web
browsers may automatically reload the page upon a broken underlying TCP
connection, which makes user interaction unnecessary.
    So, the web browser is an application that does not care which
underlying network it uses. The speed of HTTP data retrieval is not critical
(unless done over a very slow link), so that any available internet connection
will suffice. There is no need to have persistent TCP connections because
HTTP requests break seldomly and, in case of an interruption, can be easily
fixed through limited user interaction. In other words, for this application,
the standard transport layer abstraction works well.

Remote control
Let us now consider a range of applications that provide control over
appliances and other electrical equipment in the user’s surroundings. This
equipment could be, amongst others, audio sets, televisions, household
appliances, or home automation gateways. We assume that these appliances
are reachable through a wireless network, either as a facility incorporated
into the appliance or by means of an in-building network (i.e., they do not
expose a control interface to the public internet), and that communication
with them is done over IP. A remote control application initiates control
connections as soon as the mobile device is within reach of those networks,
to provide up-to-date information about the availability and state of the
appliance to the user.
    Except for the wide area (cellular) network interface, the link
establishment policy on present mobile devices is to only connect to
networks upon initiation by an application or directly by the user. An
important reason for this is to conserve energy, although other reasons such
as privacy also play a role. This means that the remote control application
must tell the operating system to occasionally scan for available networks
and activate those that allow connections to known appliances.
30   CHAPTER 3                                 NETWORK RESOURCE ABSTRACTION



         This makes the application more directly involved in below-IP layer
     operations. It must know through which available network interface(s) the
     appliance is reachable. Furthermore, it must interact with the operating
     system using technology specific APIs to activate network interfaces, initiate
     scanning to find relevant networks or nodes, and establish link layer
     connectivity. If not done by default, the remote control application must
     initiate the IP configuration over the link. It is clear that this application
     needs information beyond what is available through the transport layer.
         One way to reduce the scan execution time on a network interface
     which potentially provides access to an appliance, is to associate the
     accessibility of an appliance with the currently visible cell on the wide area
     network interface. For instance, if a cell is visible that is never in-range
     when at home, scanning for the home 802.11 network does not make
     sense. Obviously, this implies that the application must have knowledge
     about which base station is currently in range, which requires information
     that is hidden by the IP layer.

     Streaming media player
     The third example is a media player that receives audiovisual content
     streamed by a server on the internet to the user’s mobile device, using a
     streaming protocol. While the user is mobile, the capacity of the available
     networks fluctuates, which requires the application to adapt the amount of
     data that passes over the connection with the server. In all circumstances,
     the player tries to present a continuous stream to the user, but adapts the
     quality of the content depending on the available bandwidth. Next to the
     capacity adaptation, it has to solve the following issues: deal with a sudden
     loss of connectivity and consider newly available, currently unused networks
     as possible candidates to carry the data.
         Although any part of the path between the mobile device and the
     streaming server may be a capacity bottleneck, in some cases – i.e., when a
     low speed wireless link connects the mobile device to the rest of the
     internet – it is likely that the first hop is the path segment with the lowest
     maximum throughput. Certainly, the end-to-end throughput will not
     exceed the limit imposed by this first hop, and this upper bound, contrary
     to the upper bounds of other parts of the path, can be determined at the
     mobile device.
         The different wireless networks that are in-range over time each have
     their own bandwidth characteristics: for example, there can be three orders
     of magnitude in throughput difference between cellular and 802.11
     networks. If, in this case, the stream switches from the 802.11 network to
     the cellular network, its available bandwidth is drastically reduced. The
     player is interested in a maximum speed indication for available networks
     and therefore does not need to know technology-specific characteristics
APPLICATION AWARENESS                                                       31



(i.e., it does not need to know it is using a cellular network or an 802.11
network).
    At the moment that a wireless network used for data transfer gets out of
range, the data stream must be transferred to another network (through the
same or another network interface). A mobility management protocol such
as Mobile IP may be in place that takes care of this transition. When this is
not the case, the player is responsible for reinitiating a connection over the
new network and signal the server to continue the stream from where it left
off. At the same time, the player then may signal to the server to alter the
bandwidth consumption for the stream, given the maximum throughput
expected on the new wireless network.
    Mobile IP leaves the transport layer state associated with the stream
unchanged. However, even then, knowing the underlying network’s
throughput characteristics is still very valuable, because it allows the
application to take immediate action when it is certain that the stream’s
bandwidth consumption is too high. Without such information, it will take
some time before the player has sufficient confidence that indeed the path’s
maximum throughput has changed. Note that the stream handover is not
very time critical, assuming that the player buffers a part of the received
stream.
    If multiple networks are available at a certain moment in time, the
application may want to choose the network interface that best matches the
application criteria. These criteria can be technical – for instance, requiring
a low level of jitter and a minimum bandwidth for optimal playback. Or
they can be non-technical, such as requiring limited monetary cost of data
transfer, which may be especially relevant for a streaming player receiving
large amounts of data.
    From the usage of network resources by this streaming player, we again
see that lower layer information can be highly relevant for an application.
This information is not always technology specific, but concerns
characteristics that are defined for a broad range of network technologies
(e.g., maximum throughput).

Video newsfeed
The fourth and final example we provide here is a video news player with
integrated download functionality. This application tries to obtain the most
recent video news items from a selected set of newsfeeds, and caches these
items locally on the mobile device. Contrary to the previous example, this
application does not show streaming content but rather plays the local
copies, providing in this way relatively fresh news also when the user is
temporarily deprived from network connectivity. This player may, for
instance, be used by commuters that watch news while on the train, having
their news items downloaded through their home or office networks. We
32         CHAPTER 3                                 NETWORK RESOURCE ABSTRACTION



           assume that news items are retrieved using TCP connections on top of
           Mobile IP, to deal with handovers in case of network interruptions.
               When trying to download new news items, the player is interested in
           knowing which networks are available, because some networks are not
           suitable for downloading large amounts of data at low monetary costs. At
           the same time, it wants to set up end-to-end connections over Mobile IP
           and indicate over which outgoing path Mobile IP will establish its tunnel, so
           that traffic generated over the Mobile IP virtual link will use the right
           physical link. In case access to the used network is lost, the newsfeed player
           wants to specify to which other link (if any) Mobile IP must make a
           handover. The selection of suitable networks is based on generic network
           characteristics such as expected bandwidth and cost of usage.
               Here we see that an application interacts with functionality at different
           layers at the same time. So also for this example, the need for cross-layer
           information and control exists.

     3.1.2 Network resource operations
           The application examples illustrate different kinds of network resource
           operations. We identified the following types of operations:
           – Detection. Deals with controlling the detection and scanning of wireless
              networks and wireless nodes through the network interfaces available on
              the device. Detection and scanning is generally costly in terms of energy
              consumption and can interfere with data transfer. Controlling this may
              require application logic that is able to deal with network-technology
              specific information.
           – Activation. Takes care of activating one or – if supported by the
              technology – multiple links over a particular network interface as well as
              configuring IP settings for these links. This operation requires
              understanding of how to identify networks, where network identifiers
              may be network technology specific. Link activation credentials, such as
              the keys for 802.11 authentication and encryption, as well as IP
              configuration parameters may be cached by the OS (this is not
              necessarily an application concern).
           – Path selection. Involves the selection of a path to carry the data, if
              multiple paths are available at the same time. In case of Mobile IP usage,
              path selection determines over which access network the Mobile IP
              traffic is carried.
           – Monitoring. Involves the monitoring of end-to-end data transfer
              characteristics such as throughput and jitter.
                          APPLICATION AWARENESS                                                         33



Table 3-1 Indication of   Operation        Web browsing   Remote control   Streaming player Video newsfeed
network operation usage   Detection        X              ●●               ●●              ●●
for the four example
applications              Activation       X              ●●               ●●              ●●
Legend:                   Path selection   X              ●                ●●              ●●
●● = extensive usage
● = limited usage         Monitoring       X              X                ●●              ●
X = no usage
                          A summary of the usage of these network operations by the different
                          example applications is provided in Table 3-1. Except for monitoring, all
                          these operations require that the application has interaction with lower
                          layer functionality, i.e., functionality below the transport layer.

               3.1.3 Observations and guidelines
                          The examples above show that cross-layer interaction is important to a wide
                          range of applications. Much of the interaction is based on the existence of
                          relationships between the various entities within and between the layers (is
                          available network X activated through interface Y?) and on the general
                          characteristics of these entities (e.g., the maximum throughput for a link).

                          Observation 1: level of control diverges from level of information
                          In general, applications need varying degrees of control and information,
                          from almost nothing to highly technology-specific interaction. Considering
                          the examples above, it is clear that mobile applications need to operate on
                          network resources at different layers. This goes against the principle of the
                          layered model, where an application uses only the interfaces offered by the
                          transport layer functionality. Still, many choices can be made using the
                          transport layer interface, typically the Socket API [120]. Most network
                          stack implementations can be configured such that binding a socket to a
                          local IP address determines over which link the outgoing traffic will be
                          directed. And, for most practical configurations, determines that the
                          incoming traffic for that socket will be received over the same link, although
                          this decision is not taken by the mobile host but by the routing
                          infrastructure (see Section 4.3.2 for a more detailed discussion on this
                          matter).
                              This means that local address binding allows an application to choose, for
                          example, that packets for a TCP connection are sent out over a link
                          available through a physical interface with certain desired maximum
                          throughput characteristics, or over a Mobile IP virtual link and interface
                          which will sustain the TCP connection even in the event of alternating
                          availability in networks. An application, however, can only make this kind of
                          decisions when it has received information that associates a local IP address
                          with a link and a link with an interface, and characteristics such as
34   CHAPTER 3                                  NETWORK RESOURCE ABSTRACTION



     maximum link throughput: essentially cross-layer information. The
     following observation can be made.
     For the enforcement of the usage of network resources the current
     interface between the application and transport layer offers substantial
     (albeit not completely sufficient) possibilities, while the cross-layer
     information used for the decision on which network resources to use
     cannot be obtained through this interface. This observation was a strong
     motivation for the creation of the network resource abstraction presented
     in this chapter: we have existing means to enforce the usage of network resources
     but do not have proper input to the decision process. The purpose of the NRM is
     to fill this gap.

     Observation 2: dedicated APIs for lower-layer control
     As the examples show, not all enforcement can go through the Socket API.
     Many lower layer (network, link) operations, however, seem to have a form
     that is common over a range of different technologies, e.g., operations such
     as ‘enable scanning’ or ‘activate link’, that can be defined as abstract
     operations. There is, however, no commonly used mechanism or API
     offering such abstract operations over multiple technologies. This leads to
     the following observation.
     Applications that need highly specific lower-layer control over network
     resources use dedicated APIs next to the Socket API. For example,
     applications use technology specific APIs to detect fixed Ethernet link
     characteristics, or to manipulate specific 802.11 settings, or to control
     Bluetooth behavior.

     Observation 3: use Mobile IP opportunistically
     Our next observation concerns the usage of Mobile IP on mobile devices.
     Mobile IP is designed to offer a permanent IP address to a host that
     attaches to the internet at different points over time. This enables
     applications to realize end-to-end data transfer without the necessity to deal
     with changing IP addresses at any of the end points.
         Mobile IP comes at a cost: it introduces considerable complexity at the
     network layer and may be forced to operate in a mode that delivers non-
     optimal routing performance (in tunneling mode). For those applications
     that need to take into account the change in characteristics of the access
     network carrying the application data, the extra overhead of restoring the
     end-to-end connection may be small compared to the actions that need to
     be done anyway. For instance, the streaming media player must signal the
     server to provide a stream with different quality (because the new access
     network has another maximum throughput). It is a small effort to do this
     quality renegotiation over a new connection with the server.
      NETWORK RESOURCE MODEL                                                         35



         Additionally, Mobile IP so far is not deployed on a large scale on mobile
      devices. When assuming that Mobile IP is always available, we impose
      unrealistic requirements on the system configuration of mobile devices.
      Given that the benefits of Mobile IP do not always compensate its
      drawbacks and given the limited availability of Mobile IP on current mobile
      devices, we come to the following observation.
      Mobile IP is best used in an opportunistic manner, when available and suitable for
      a particular application. This consideration applies to any mobility
      management protocol providing a similar kind of network transparency,
      such as the Host Identity Protocol (HIP) ([85]).

      Guidelines
      Given the analysis of the examples and the considerations above and given
      that our target platform is the state-of-the-art mobile device, the following
      list of guidelines for the network resource abstraction are formulated:
      1. Cross-layer network resource information should be presented ‘as is’:
           reflecting what is generally understood as basic elements and concepts
           inside the layered stack model, as well as inside network technologies.
           This enables straightforward interoperability with existing well-known
           APIs.
      2. The abstraction must be capable of reflecting the state of network-
           related hardware and operating system components on modern (state-
           of-the-art) mobile devices.
      3. It must offer flexible levels of abstraction to provide applications with a
           view that matches their decision making needs, without providing the
           application with unnecessary details.
      4. It must allow for simple and light-weight interaction between
           application and operating system. Mobile devices are battery powered,
           have relatively few resources and therefore are only capable of
           accommodating additions that consume little energy and few of these
           resources.


3.2   Network resource model
      The network resource abstraction we propose here takes on the form of a
      model: the Network Resource Model (NRM). The NRM is a hierarchical
      data model used to describe the state of all available network resources on a
      mobile device in an explicit manner. In this section, we discuss the features
      of this model and introduce a reference version capable of representing the
      state of network resources on state-of-the-art mobile devices. The
36          CHAPTER 3                                  NETWORK RESOURCE ABSTRACTION



            evaluation in Chapter 5 of the abstraction as well as the middleware offering
            this abstraction to applications (Chapter 4) uses this reference version.

     3.2.1 Basic entities
            To identify the basic elements needed to describe network resources, we go
            back to the concepts that are fundamental for each of the layers ([60]).
            They are widely known, although the inter-relationships between them are
            often not explicitly expressed. The NRM considers entities at three
            different layers of the protocol stack: the link layer, including everything
            below; the network layer; and the transport layer.
                At the (physical and) link layer, bits and frames are transferred over
            links, which a network interface maintains. An example is the link setup
            between a host’s Ethernet interface and an Ethernet switch. At the network
            layer, network nodes send packets over paths that consist of a concatenation
            of links. At the transport layer, data travels over end-to-end transports, which
            use one or multiple paths. We use the term transport here to refer to
            stateless communication (e.g., UDP) as well as stateful communication
            (e.g., TCP and SCTP) between internet nodes. Because links, paths, and
            transports come and go over time, we refer to them as transient entities.
                Each of these fundamental entities is managed by the hardware and
            software functionality at the respective layers; network interfaces maintain
            links, IP stacks maintain paths, and transport-layer stacks maintain
            transports. These pieces of functionality we respectively call Link Layer
            Elements, Network Layer Elements, and Transport Layer Elements, and are defined
            as basic entities in the model. All NRM entities are described by their
            properties and their relationships with other entities. At the transport layer,
            and especially the network layer, the available entity types are relatively few,
            but at the link layer they can be numerous, depending on how many
            network technologies need to be incorporated.
                The types are defined following an object-oriented paradigm resulting in
            type hierarchies: basic and abstract types define generic characteristics,
            whereas derived types define more specific characteristics. Note that the
            NRM also supports ad hoc networking, because such networks can simply
            be modeled with links and paths. Although here we define only those link-
            layer technologies that are present in currently available devices, we can
            extend the NRM to form a broad taxonomy, through inheritance and by
            introducing new top level types.
                Our abstract model covers only those segments of paths (single hop)
            that are directly connected to the host, not full end-to-end paths, because a
            multihop path is not completely visible from the host’s standpoint. Thus,
            the host can not uniquely identify an entire multihop path; the host can,
            however, provide a good description of a path’s first segment. While the full
                            NETWORK RESOURCE MODEL                                                      37



                            path of end-to-end data transfer is dynamic (i.e., individual packets may
                            take different routes to the destination), the first segment at either side is
                            static because it is associated with the IP address of that end point.
                                For mobile hosts, the first hop in the path is often highly relevant, as it
                            is usually over a wireless link, which is often the path segment with the most
                            restricted resources and also the one with the highest influence on cost of
                            usage – at least from the user’s perspective. So, information about the first
                            hop of available outgoing paths provides, in many situations, valuable
                            information to applications generating network traffic. Additionally, the
                            path’s first segment is the only part that mobile hosts select. Typically,
                            NRM path segments coincide with the entries found in the operating
                            system’s routing table. In the NRM we define gateway path segments for
                            multihop paths to other Internet nodes and local path segments for singlehop
                            paths to hosts on local networks.

Figure 3-2          Basic
(abstract) NRM entities
and their relationships




                            Considering the discussion above, we now have a model with abstract types
                            as depicted in Figure 3-2, which indicates the general cardinality of the
                            relationship between the entities (not the properties). A transport layer
                            element may maintain between zero and more transports, but a transport is
                            always associated with a single transport layer element. Likewise, a transport
                            uses one or more path segments and a path segment supports between zero
                            and more transports.
                                When replacing these abstract entity types with concrete types, we can
                            get a view of the NRM as provided in Figure 3-3. Note that the cardinality of
                            the relationship between the TCP connection and the IPv4 path segment
38                       CHAPTER 3                                    NETWORK RESOURCE ABSTRACTION



                         has changed compared to the abstract case: a TCP connection uses a single
                         path, but in general, transports may use multiple paths (such as the case for
                         SCTP). Furthermore, this figure indicates that the 802.11 interface has two
                         relationships with, possibly, multiple 802.11 networks: one to indicate the
                         802.11 networks in range (zero or more) and one to indicate the currently
                         active network (zero or one).
                             So we see that the nature of the relationships is often protocol and
                         technology specific and a simple model is capable of capturing major
                         characteristics. Similarly, the IPv4 stack has a relationship that reflects all IPv4
                         paths segments and a relationship with one particular path segment (if
                         available) that marks the default route, i.e., the path segment that is selected
                         when a connection is not explicitly tied to a specific path segment.

Figure 3-3     Example
NRM view for an IPv4
enabled host with a
WLAN interface




               3.2.2 Type hierarchy
                         The existence of type hierarchies allows applications to choose the level of
                         abstraction of the network resource description offered to them. A real-
                         world mobile device configuration may involve many different types which
                         not all may be of interest to the application. Suppose an application is only
                         interested in choosing the outgoing path which is best suited to carry a
                         certain data stream. It uses the maxSpeed characteristics defined for the
                         abstract type Link to select suitable link entities and uses the local IP
                         address of the available gateway path segment realized over this link to setup
                         the data stream connection. This application is only interested in entities
                          NETWORK RESOURCE MODEL                                                     39



                          that are instances of two specific types and uses – for the link information –
                          only generic characteristics, not technology specific characteristics.


Figure 3-4          Two
examples of a type
hierarchy in the NRM




                          Furthermore, type hierarchies allow the model to be extended. When a new
                          link layer technology becomes available it can ‘hook’ into the model by
                          deriving from the available abstract type that best matches the technology.
                          For instance, a GPRS cellular interface may be defined that derives from the
                          more generic CellularInterface type. This more specific interface type
                          may, as an extension, provide means to read out the GPRS class, indicating
                          whether the interface is capable of supporting simultaneous voice and data
                          sessions. Although we focus on packet switched networks here, this
40                       CHAPTER 3                                 NETWORK RESOURCE ABSTRACTION



                         information indicates the possibility of experiencing data traffic
                         interruption caused by the calling behavior of the device owner.
                             The two type hierarchy examples in Figure 3-4 show how the type
                         characteristics become more specific with derived types.

               3.2.3 Technology taxonomy
                         Extending the type hierarchy as described above essentially builds a
                         taxonomy of network technologies. In part, this can be observed in Figure 3-
                         4: the 802.11 network interface is a physical interface, which is a network
                         layer element. Building this taxonomy is the same as making a classification
                         of network technologies.
                             We can apply different criteria to classify network technologies and
                         protocols. For lowest layer wireless technologies, certain radio technology
                         characteristics such as modulation, channel coding, transmission power,
                         and frequency band can be used. Transport layer protocols can be classified
                         based on whether they are stateless or guarantee in-order delivery. As the
                         lower layers (link and below) have the most diverse technologies, we expect
                         to see its taxonomy to be most elaborate.

Figure 3-5        Type
hierarchy for the link
layer element types in
the NRM




                         The reference version of the NRM we introduce here has a relatively simple
                         type hierarchy considering that there are many different wireless
                         technologies, some of which have multiple variants (such as the range of
                         802.11 WLAN technologies, or the family of GSM/UMTS cellular
                         technologies). This is illustrated in Figure 3-5 for the link layer element
                         types. Having a simple taxonomy is motivated by the fact that the most
                         critical features are sufficiently captured by a simple model: the basic types
                         indicate availability and generic characteristics such as maximum
                         throughput, while simple derived types make the technology specific
                         relationships between entities explicit. Adding details in the form of more
                         explicit types is only useful for a small fraction of applications that select
      NETWORK RESOURCE MODEL                                                      41



      network resources based on highly technology specific information.
      Additionally, we focus here on what is commonly available on high-end
      mobile phones, which limits the range of technologies. In this figure, as well
      as the other figures showing NRM types, Mobile IP is abbreviated as MIP.
          Occasionally, a new type may be equally well classified as a subtype of
      multiple existing types when extending the type hierarchy. We do require
      that the NRM type hierarchies use single inheritance, because multiple
      inheritance has known ambiguities and increases complexity [114].
      Therefore, in such a case, the new type must derive from one of the suitable
      subtypes.

3.2.4 Mobility management protocols
      Mobile IP offers an IP address that does not change in case a mobile device
      attaches at different points to the internet. While the device owner roams,
      the transport layer protocols relying on a static IP address, such as TCP, can
      continue to operate when using this home address. As we have seen in the
      description of the example applications in Section 3.1, in the case of Mobile
      IP usage, an application may benefit from knowing which underlying access
      networks are used over time. We describe here how the NRM provides this
      information towards applications. Furthermore, we discuss how the
      operation of the SCTP protocol – which can support end-to-end
      associations while roaming – can be modeled using the NRM.
          The Mobile IP protocol can operate in different modes, depending on
      the level of Mobile IP support at the remote host and the visiting networks.
      When in a foreign network, the packets from the other end (the
      ‘correspondent node’) are sent to the ‘home agent’ which tunnels the data
      towards the foreign network. The tunnel end point is either at the ‘foreign
      agent’ in the foreign network or at the mobile device itself. When in the
      home network, the mobile host does not use a tunnel for data transfer with
      the correspondent node, but rather sends and receives packets in the
      conventional IP way.
          The mobile device or the foreign agent has two alternatives to send
      packets to the correspondent node when in a foreign network. It either
      sends them directly, or it sends them through the tunnel – so called reverse
      tunneling. Although the direct alternative is more efficient, many gateway
      routers prohibit forwarding packets that do not have a source address from
      the address range of their access networks for security reasons (which is
      referred to as ‘ingress filtering’ [38]). Furthermore, sending packets directly
      to the correspondent node requires the correspondent node to be aware
      that Mobile IP is used.
          Given the slow uptake of Mobile IP in end nodes, we assume here that
      foreign networks do not support Mobile IP and that correspondent nodes
42                       CHAPTER 3                                 NETWORK RESOURCE ABSTRACTION



                         are not Mobile IP enabled. This means that the Mobile IP tunnel always
                         ends at the mobile device and that all traffic going back and forth between
                         the end points is going through the tunnel, except when in the home
                         network. We then have two situations: one where the device is in a foreign
                         network and using the tunnel, and another where the device is in the home
                         network and communicating directly with the correspondent node. The
                         latter situation is simply modeled with a path segment available through a
                         physical interface.

Figure 3-6         NRM
modelling of Mobile IP
and SCTP operation




                         We model the Mobile IP tunnel as a link entity, because it is used to
                         establish a gateway path segment: the one that is configured with the home
                         address. Applications that require their transport layer connections to be
                         managed by Mobile IP use this gateway path segment. The Mobile IP tunnel
                         link type is special, because it uses another path segment to send the tunnel
                         data. This path segment is typically realized over a physical link, and
                         therefore changes over time as physical links appear and disappear. This
                         situation is depicted in Figure 3-6, where first the Mobile IP tunnel uses the
                         path segment with foreign IP address 1 and later the path segment with
                         foreign IP address 2. Although the gateway path segments in this figure
                         show IPv4 address, the same situation applies to path segments with IPv6
                         addresses. The current Mobile IPv4 and Mobile IPv6 standards, however,
                         do not provide facilities to set up and maintain the tunnel using a mixture
                         of IPv4 and IPv6 path segments ([123]).
                             An SCTP association can use multiple paths to send data between two
                         end points. With an extension for dynamic address reconfiguration ([122]),
                         it can be deployed in mobility scenarios where the set of addresses used for
                         the association changes over time. As such, it can serve as a replacement of
                         TCP over Mobile IP, although the other end point must be able to support
                         NETWORK RESOURCE MODEL                                                43



                         SCTP (including the extension) Figure 3-6 shows an SCTP association that
                         first uses the foreign IP address 1 to send and receive data from another
                         node and later use foreign address 2, using an SCTP stack that implements
                         the dynamic address reconfiguration extension. Note that TCP, Mobile IP
                         and SCTP can coexist without problems. Contrary to Mobile IP, an SCTP
                         association can use a mix of IPv4 and IPv6 addresses.
                         1    <xs:complexType name="Link" abstract="true">
                         2      <xs:sequence>
Figure 3-7 The part of   3        <xs:element name="linkId" type="Id"/>
the    NRM    schema     4        <!-- Ref. to type (derived from) LinkLayerElement -->
describing    cellular   5        <xs:element name="ifId" type="Id"/>
networks                 6        <xs:element name="state" type="xs:unsignedInt"/>
                         7        <xs:element name="services">
                         8          <xs:complexType>
                         9            <xs:sequence>
                         10             <!-- Ref. to type (derived from) LinkService -->
                         11             <xs:element name="service" type="Id"
                         12               minOccurs="0" maxOccurs="unbounded"/>
                         13           </xs:sequence>
                         14         </xs:complexType>
                         15       </xs:element>
                         16       <xs:element name="maxSpeed" type="xs:unsignedInt"/>
                         17       <xs:element name="mtu" type="xs:unsignedInt"/>
                         18     </xs:sequence>
                         19   </xs:complexType>
                         20
                         21   <xs:complexType name="BaseStation">
                         22     <xs:sequence>
                         23       <xs:element name="cid" type="xs:unsignedInt"/>
                         24       <xs:element name="lac" type="xs:unsignedInt"/>
                         25       <xs:element name="rssi" type="xs:int"/>
                         26     </xs:sequence>
                         27   </xs:complexType>
                         28
                         29   <xs:complexType name="CellularNetwork">
                         30     <xs:complexContent>
                         31       <xs:extension base="Link">
                         32         <xs:sequence>
                         33           <xs:element name="operatorName" type="xs:string"/>
                         34           <xs:element
                         35             name="operatorNumber" type="xs:unsignedInt"/>
                         36           <xs:element name="baseStation" type="BaseStation"/>
                         37           <xs:element name="baseStationList">
                         38             <xs:complexType>
                         39               <xs:sequence>
                         40                 <xs:element
                         41                   name="baseStation" type="BaseStation"
                         42                   minOccurs="0" maxOccurs="unbounded"/>
                         43               </xs:sequence>
                         44             </xs:complexType>
                         45           </xs:element>
                         46         </xs:sequence>
                         47       </xs:extension>
                         48     </xs:complexContent>
                         49   </xs:complexType>
44         CHAPTER 3                                 NETWORK RESOURCE ABSTRACTION



     3.2.5 Notation
           The NRM is defined using XML Schema ([127]); network resource
           descriptions that adhere to the model can be expressed as XML documents
           with structures dictated by the model’s XML schema. We use various XML
           Schema mechanisms to describe the model: abstract types, deriving
           (concrete) types, keys and key references to enforce uniqueness of
           identifiers. Figure 3-7 shows a small part of our model’s integral schema,
           describing the transient state part of cellular networks; the complete
           schema is provided in Appendix A.
               The CellularNetwork type (lines 29-49) derives from the abstract
           type Link (lines 1-19). A link refers to its interface with the ifId identifier
           and has several elements to describe its characteristics: the up or down state
           (state), the maximum throughput (maxSpeed), and the maximum
           transmission unit (mtu). Furthermore, it refers to services associated with
           this link (services), with type LinkService (not included here). These
           are services that are typically only accessible through this link, such as DNS
           servers and HTTP proxies.
               The CellularNetwork type indicates the currently used base station
           (baseStation, line 36), if any, as well as the list of all this operator’s in-
           range base stations (baseStationList, line 37). The elements cid, lac,
           and rssi in BaseStation (lines 21-27) represent, respectively, the cell
           ID, location area code, and received signal strength indication of a base
           station.
               Alternatively, applications can get network resource descriptions by
           means other than via XML documents, given that XML is not the preferred
           format for all types of applications. We merely use the NRM schema as a
           formal notation to define the model: it can have different “bindings” in the
           form of XML, C, scripting, Java, and so on.

     3.2.6 NRM type overview
           A full overview of all defined types for the NRM reference model is
           provided in Figure 3-8. The types are positioned according to their layer and
           whether they belong to the device’s hardware and software components or
           to the transient state. The link service types at the bottom right are not part
           of the transport, network or link layer: strictly speaking, they represent
           application layer functionality (e.g., the DNS protocol is an application layer
           protocol). These types are included here because they constitute an
           essential part of the internet infrastructure.
                         NETWORK RESOURCE MODEL                                                                                45



                          hardware / software components                                                         transient state
Figure 3-8 Overview of
NRM types
                                                                                                      Link

                         Application Layer
                                                                                                    Service
                                                                                                   (abstract)

                                                                                               DNS
                                                                                                              Gateway
                                                                                              Server



                                                       Transport
                                                                                                   Transport
                                                     Layer Element
                                                                                                   (abstract)
                                                       (abstract)
                         Transport Layer




                                             TCP        UDP          SCTP               UDP           TCP         SCTP
                                             Stack      Stack        Stack            Listener      Listener     Listener


                                                                                            TCP               SCTP
                                                                                          Connection        Association


                                                      Network Layer                              Path
                                                         Element                               Segment
                                                        (abstract)                             (abstract)
                            Network Layer




                                                                                 Local                            IPv6 Local
                                                     IPv4          IPv6                       IPv4 Local
                                                                                  Path                               Path
                                                     Stack         Stack                     Path Segment
                                                                                Segment                            Segment

                                                                                Gateway                          IPv6 Gateway
                                                                                             IPv4 Gateway
                                                                                  Path                               Path
                                                                                             Path Segment
                                                                                Segment                            Segment


                                                             Link Layer
                                                                                                    Link
                                                              Element
                                                                                                 (abstract)
                                                             (abstract)

                                                      Physical       Virtual
                                                                                   WLAN           Access        Loopback
                                                      Interface     Interface
                                                                                  Network          Point         Network
                                                     (abstract)    (abstract)
                         Link Layer




                                                      Cellular     Loopback       Cellular         Base           MIP
                                                     Interface     Interface      Network         Station        Tunnel


                                                     Bluetooth        MIP         Bluetooth      Bluetooth      Bluetooth
                                                     Interface     Interface      Network           Link          Node


                                   Serial             WLAN         Ethernet        Serial        Ethernet
                                 Interface           Interface     Interface      Network        Network
46         CHAPTER 3                                 NETWORK RESOURCE ABSTRACTION



     3.3   Example of NRM usage
           We now discuss an example usage of the NRM to give a snapshot of the
           state of the network resources on a mobile device. The device is equipped
           with a number of different network interfaces and provides support for
           Mobile IP and SCTP, in addition to standard IPv4-based network stack
           facilities. We assume that the device has a single Mobile IP home address,
           actively managed by a home agent not located in one of the currently
           accessible networks.
               As depicted at the top of Figure 3-9, the example device is in range of
           multiple wireless networks and connects to a serial link. It has five physical
           interfaces (instance numbers 1-5), and one virtual interface, the Mobile IP
           interface (number 6). The serial, WLAN, and cellular interface are active
           and connect to a network (numbers 11, 12, and 15 respectively). Both the
           WLAN and the cellular interface detect other networks.
               The active cellular network (number 15) does not have an active IP
           configuration: no path segments are defined for this network. The serial
           network (number 11) provides access to the internet through a gateway
           path segment (number 18), which is used to carry the data for the Mobile
           IP tunnel (number 17). The gateway path segment offered by this tunnel
           (number 19) is configured with the Mobile IP home address. Applications
           that require a long-lived address must use the gateway path segment. On
           top of the WLAN network, two path segments are configured: one gateway
           path segment (number 20) providing access to the internet and a local path
           segment (number 21) giving access to nodes on the local 802.11 network.
               Applications on the device are engaged in data communication using
           various transports (using the UDP, TCP, or SCTP protocols). These
           transports are not further specified here.
               A part of the transient state of Figure 3-9, is described in XML in Figure
           3-10. This description conforms to the NRM Schema as discussed in Section
           3.2.5. An application interested in receiving a snapshot of the state of the
           network resources on the device in XML form, would obtain it in the form
           as depicted in Figure 3-10.


     3.4   Summary and discussion
           In this chapter, we presented a network resource model that can provide
           information to mobile applications about the heterogeneous network
           resources available on a mobile device. We argued that different types of
           applications require different levels of information about the dynamic
           resources below the application layer. Additionally, we showed that the
                           SUMMARY AND DISCUSSION                                                                                47



                           simple abstraction offered by the transport layer is in many cases not
                           sufficient.
                               A number of guidelines (Section 3.1.3) contributed to the design of the
                           NRM.
                           – The NRM types reflect closely the entities found at the different layers and
                               explicitly define the relationship with other types (guideline 1).

Figure 3-9          NRM                                                      ■
                                                                        14
instances for an example                                                                                     15
device having access to                                                                                          ■
multiple networks




                                        11                                                                             16
                                             ♦
                                                                                                                        ■




                                                 13
                                                      ●                                                 12
                                                                                                   ●

                           hardware / software components                                                         transient state

                                    8                 9           10

                            UDP          TCP              SCTP
                            Stack        Stack            Stack          Various transports



                                                      7                              18            19             20         21
                                                                         IPv4             IPv4           IPv4          IPv4
                                         IPv4                            Gateway          Gateway        Gateway       Local
                                         Stack                           PathSeg          PathSeg        PathSeg       PathSeg



                            ‡       4   ▲             5   ◘         6            ◘            17
                                                          MIP
                            Ethernet     Bluetooth        Interface              MIP Tunnel
                            Interface    Interface        (virtual)              (virtual link)


                            ♦       1    ●            2   ■        3     ♦           11   ●        12        ■          14
                                                                                             ●      13          ■         15
                            Serial       WLAN             Cellular       Serial           WLAN                      ■
                                                                                                             Cellular         16
                            Interface    Interface        Interface      Network             WLAN
                                                                                          Network 1              Cellular
                                                                                                             Network 1
                                                                                             Network 2               Cellular
                                                                                                                 Network 2
                                                                                                                     Network 3
48                         CHAPTER 3   NETWORK RESOURCE ABSTRACTION




Figure 3-10         XML
description      of    a
selection of the example
entities in Figure 3-9,
conforming to the NRM
Schema
SUMMARY AND DISCUSSION                                                     49



–   Furthermore, the NRM is a type hierarchy that allows for extensions in
    a flexible manner, to incorporate new technologies and protocols as they
    become available. It allows for flexible views on the network resources
    by using generic or more specific types, depending on what the
    application requires (guideline 3).
We showed an example with a richly equipped mobile device and used a
reference version of the NRM to describe the network resource state of this
device.
    There are several shortcomings in the reference model we presented
here. One of them is that not all protocol features have been fully translated
to proper relationships and types in the NRM. For example, a Mobile IP
tunnel is modeled to use a path segment for tunnel data transfer to the
Home Agent, which is replaced by another path segment when the old path
segment is lost. This implies that any mix of IPv4 and IPv6 path segments
may be used over time, while in reality such a mix is not possible (at least
not for implementations that adhere to the Mobile IPv4 and Mobile IPv6
standards). So, in this case, the NRM would be more correct when having
different types for different Mobile IP versions. Note that this shortcoming
does not occur with SCTP, because SCTP address sets allow any mix of
IPv4 and IPv6 addresses at the end points.
    Although the most important relationships between the entities at the
different layers as well as the main characteristics of the basic types are
captured by the NRM, we are aware that bringing in all the detailed aspects
of all covered protocols requires a very significant effort – an effort that
goes beyond the work covered by this dissertation. For instance, the
hardware and software types are not in all aspects balanced with their
associated transient state types: we have defined virtual and physical
interfaces, while the (transient) link type hierarchy does not make this
distinction. Or, as another example, we have defined a separate Bluetooth
link type (subtype of ‘link’ and supertype of ‘Bluetooth network’) to make a
distinction between Bluetooth nodes that are merely visible and those that
can carry IP traffic (i.e., support the Bluetooth LAN access profile). A
similar distinction we have not made for serial links, because of pragmatic
reasons: the USB serial links established on the devices we used in our
experiments always supported IP communication. Also, we realize that the
reference NRM left out some of the network technologies that may be
relevant on future mobile devices such as WiMax [54].
    We have not provided NRM types for the experimental Host Identifier
Protocol (HIP), a protocol that is specifically designed to meet the
challenges of mobility and multi-homing ([85], [87]). This protocol
removes the role of an IP address as a host identifier, without breaking
common protocols in the transport layer. It is likely that incorporating HIP
in the NRM will introduce new types. At the same time, however, the
50   CHAPTER 3                               NETWORK RESOURCE ABSTRACTION



     principle that some applications require knowledge about the actual
     networks used will remain valid in that situation. In that sense, HIP does
     not differ from Mobile IP: transport layer connections do not break but
     information about which networks carry the traffic is still necessary.
                                                               Chapter

                                                                         4
4. State Notification and Control
   With the abstraction provided by the NRM, we have a means to describe a
   device’s available network resources at the different layers of the internet
   protocol stack and to indicate the inter-relationships between resource
   entities. In this chapter, we propose and discuss a middleware facility to
   deliver state change notifications to applications based on the NRM and
   enable them to change that state. This facility, the Network Abstraction Layer
   (NAL), is a system component running on the mobile device.
       The NAL allows applications to obtain a view on the state of the
   network resources that is tailored to their needs: it provides a mechanism to
   subscribe to status change notifications in a flexible manner, so that an
   application receives updates with a level of detail that matches its decision
   making process. This mechanism utilizes the type hierarchy of the NRM, by
   letting applications subscribe to the type(s) disclosing an appropriate level
   of information.
       This chapter is structured as follows. Section 4.1 introduces the high level
   design of the NAL. Section 4.2 discusses the interaction between an
   application and the NAL service to realize state notifications. This section
   incorporates a number of examples to illustrate the flexibility of the
   subscription mechanism. Section 4.3 discusses how applications can
   influence the state of network resources using the NAL. Section 4.4 provides
   the more detailed design of the NAL system service, with its different ways for
   application interfacing and its pluggable setup. The NAL implementation
   described in the next chapter is based on this design. In Section 4.5 we give
   a summary and discussion. Parts of this chapter are based on [98], [91],
   [96] and [94].
52                    CHAPTER 4                               STATE NOTIFICATION AND CONTROL



             4.1      NAL design overview
                      The high level design of the NAL concerning the state notification and state
                      control of an application is shown in Figure 4-1. The NAL is responsible for
                      keeping track of the network resource state on the mobile device using a set
                      of operating systems APIs. The application reads this state and receives
                      notifications of state changes through an API offered by the NAL. The state
                      received by the application is described in terms of the NRM. Furthermore,
                      the NAL allows an application to influence the network resource state –
                      through the same API – by mapping operations on the state as seen by the
                      application to operating system specific operations. This mapping uses the
                      information stored in the ‘control map’.

Figure 4-1 NAL high
level design




                      As such, the NAL simply is a layer between the application and the
                      operating system, translating operating system specific state into NRM state
                      and mapping actions on NRM state entities to operating system specific
                      operations. When an application issues a command through the NAL
                      interface, the network resource state stored by the NAL changes indirectly:
                      the NAL updates its internal network resource state only after receiving a
                      state change indication of the operating system (and subsequently
                      communicates the change back to the application).
                          Now, multiple applications may use the NAL at the same time, receiving
                      state updates and issuing commands through the NAL interface concurrently
                      (not depicted). The NAL does not prevent any concurrency problems that
                      may arise when using the operating system APIs. For instance, if two
                      applications are aware of the existence of an active network interface, and
      STATE NOTIFICATION                                                        53



      both applications want to disable this interface at the same time using an
      operating system API, the first application issuing the disable command
      through the API succeeds and the second fails (because the interface is
      already disabled). The same situation may occur when issuing the command
      through the NAL interface. On the other hand, the NAL does not introduce
      additional fundamental concurrency problems, because it reflects the state
      as known by the operating system. The only issue that may arise is that the
      NAL state changes always lag the operating system state changes – by at
      least a few CPU cycles – which may increase the chance of applications
      making control decisions based on old data. Obviously, assuming a
      preemptive operating system, delays may also occur with applications
      accessing the operating system APIs directly.
          In the next two sections, we focus on the details of the interaction
      between the application and the NAL. We argue for an interaction based on
      messages, and define all possible messages for state notification and control
      in these sections.


4.2   State notification
      Adaptive mobile applications depend on network resource information at
      different moments in time. In some cases, an application needs a snapshot of
      the resource state at the moment it establishes a connection with another
      node – to decide and control which resources to use for this connection. A
      simple mechanism suffices to provide this functionality. For instance, the
      system could keep track of the current network resources in a document
      stored on the file system, structured according the NRM schema (Section
      3.2.5). Then, the application only needs to read and parse that file to know
      the resource state.
          Other types of applications depend on quick reactions to state changes
      (i.e., want to be notified of changes quickly after they occur). Notification
      must happen, for instance, when a used resource disappears or when
      another more appropriate resource becomes available. Then a file-based
      interface is hardly appropriate, because it lacks a change notification
      mechanism. In these cases, the NAL must supply a mechanism that keeps
      applications continuously informed about the changes in the network
      resource state. The state notification aspects of the NAL are the focus of
      this section.
          The interaction between an application and the NAL is based on message
      passing. This widely used communication paradigm fits well with the
      asynchronous nature of state notifications, and is used for local as well as
      distributed communication. We assume that a two-way communication
      channel exists between the application and the NAL, and that both sides
54                         CHAPTER 4                                STATE NOTIFICATION AND CONTROL



                           send and receive messages. An alternative interaction mechanism, more
                           close to the file-based interaction above, can be provided by a shared
                           database. Applications then connect to this database to read the dynamic
                           resource state. This mechanism is less well suited for notifications and also
                           does not provide intuitive support for resource control. We will see,
                           however, that we require a rudimentary notion of a transaction – a
                           fundamental concept in database systems to enforce data consistency –
                           when updating the network resource state with messages.

                4.2.1 State views
                           One of the guidelines in Section 3.1.3 (guideline 3) prescribes that the
                           abstraction offered to applications must provide a view with an amount of
                           information that matches the application’s decision making needs. We
                           discuss now the nature of those views, using the example presented in
                           Section 3.3. As can be seen in Figure 3-9 and Figure 3-10, a fairly
                           straightforward mobile device configuration can already result in a full
                           NRM state description with more than a few instances (over 20, not
                           counting the ongoing transports). Using a limited view on the full state
                           substantially reduces the number of entities.


Figure 4-2 Selective
view     on    available
network      resources,
based on the example in
Section 3.3 without
Mobile IP




                           Now, let us consider what happens in a typical roaming scenario. Assume
                           we have a mobile device with a configuration such as the one in Figure 3-9,
                           with Mobile IP disabled, and the device moving in and out of various
                           networks’ coverage. It runs an application that takes into account the
                           current maximum available throughput on the links used for connections
                           with other nodes. With no mobility-management facilities available for TCP
                           and UDP traffic, the application manages its own connections. It therefore
                           instructs the NAL to only send status changes for instances of the link type
                           and the path segment type (including those that are subtypes). At a certain
                           moment, it then has a resource snapshot such as the one depicted in Figure
                           4-2. The gateway path segments indicate a means of reaching other nodes
                           on the internet, and the links give the maximum throughput for these
                           STATE NOTIFICATION                                                         55



                           potential paths. Subsequently, this view on the resources is used to select
                           the path segment with a link that suits best the application’s needs for
                           bandwidth. Note that the application does receive information about the
                           link technologies used, because instance number 11 is a serial link and
                           instance number 12 is an 802.11 link, but it only uses the generic
                           maxSpeed link characteristic. So, effectively, the application does not need
                           to know about technology specific link aspects.
                               Now, consider the same application with Mobile IP enabled. In this
                           case, Mobile IP will maintain the connections as the user roams, so the
                           application must know the path that the Mobile IP tunnel manages. It thus
                           instructs the NAL to send status updates on the path segment and Mobile
                           IP tunnel types (see Figure 4-3), but still takes into account the maximum
                           throughput, which changes as the tunnel moves from one physical network
                           to another, reflected by an update of the tunnel entity (number 17 in the
                           figure). The application notices that only one path segment (number 19)
                           can be used to setup the Mobile IP managed connection. Contrary to the
                           previous case, it now requests a specific link type, the Mobile IP tunnel, so
                           the other available links are not described by the NAL.


Figure 4-3 Selective
view    on     available
network resources to
choose     Mobile     IP
managed             path
segments, based on the
example in Section 3.3.




                           Note that for both cases, path segment information is requested, not
                           gateway path segment information, because the node that must be
                           contacted may be in the same local network as the mobile device. In that
                           case, the local path segment must be used to establish the connection (see
                           also Section 3.2.4 for a discussion on this matter). By requesting path
                           segments, the status changes in both the gateway path segment and the local
                           path segment instances are received.
                               Different kinds of applications can use the NRM abstraction and the
                           NAL in different ways. The examples in Figure 4-2 and Figure 4-3 show that
                           even in a more elaborate network configuration, a designer can create a
                           highly simplified view that captures information relevant to the application’s
                           decision process regarding network resource usage.
56                       CHAPTER 4                                      STATE NOTIFICATION AND CONTROL



               4.2.2 Subscriptions
                         A NAL client establishes a view on the current network resource state by
                         means of a subscription. The application in the cases above has used this
                         mechanism to get asynchronous updates on path segments, links and
                         Mobile IP tunnels. We now discuss the design of the subscription
                         mechanism provided by the NAL.
                             The NAL supports subscribing to different sorts of information: it allows
                         specifying a subscription for 1) all entities in a layer of the protocol stack, 2)
                         all entities of a specific NRM type, and 3) individual instances of a NRM type.
                         Elements of these subscription types can be combined to form a single
                         subscription specification. If a status change matches with any of the
                         elements in the subscription specification, it is communicated to the NAL
                         client. By combining subscription elements it is possible to flexibly define
                         which information to receive.
                             When an application connects to the NAL for status information, it
                         sends a subscription message to the NAL containing the subscription
                         specification. From that point on, the NAL returns information concerning
                         the status matching the elements in the subscription. If the client wants to
                         change the subscription at a later stage, it simply reconnects and resends the
                         subscription message with the changed specification, after which the NAL
                         sends back information according to that new specification.

Table 4-1         NAL    Subscription element type         Parameter
subscription   element   NAL_SUBSCRIBE_LAYER               Identifier of the layer. One of :
types                                                      NAL_LAYER_LINK
                                                           NAL_LAYER_NETWORK
                                                           NAL_LAYER_TRANSPORT
                                                           NAL_LAYER_OTHER
                         NAL_SUBSCRIBE_TYPE                Identifier of the type:
                                                           NAL_TYPE_...
                         NAL_SUBSCRIBE_INSTANCE            Identifier of the type and the identifier of the instance:
                                                           NAL_TYPE_...
                                                           instanceid


                         The number of elements in the subscription specification is unlimited: the
                         subscription message therefore has a variable length. Table 4-1 shows the
                         three subscription element types and their parameters. The
                         NAL_SUBSCRIBE_LAYER type takes a layer parameter corresponding to the
                         layers defined for the NRM. The NAL_LAYER_OTHER value is used for those
                         NRM entities that do not fall in any of the regular layers, such as the
                         DNSServer NRM type. The NAL_SUBSCRIBE_TYPE type takes the type
                         identifier of the NRM type that must be subscribed to. This can be any of
                         the NRM types, from very generic to highly technology specific. Typically,
      STATE NOTIFICATION                                                         57



      the   type    identifier   is    named      NAL_TYPE_<TYPENAME>,        e.g.,
      NAL_TYPE_PATHSEGMENT for the             NRM type PathSegment. The
      NAL_SUBSCRIBE_INSTANCE type has          two parameters: one to specify the
      NRM type of the instance and the other the instance identifier. We have
      defined instance identifier to be unique for the generic abstract NRM types,
      which may mean that instances of different types may have the same
      identifier (examples of instance identifiers are the linkId and
      pathSegmentId values in Figure 3-10). Therefore, it is necessary here to
      also specify the type.
          To show that a subscription specification can be flexibly assembled, let
      us look at a few examples. The subscriptions for the cases in Figure 4-2 and
      Figure 4-3 are easily created by using NAL_SUBSCRIBE_TYPE types. For the
      first case, the PathSegment and Link types are joined in a subscription
      message. For the second case, the PathSegment and MIPTunnel types are
      joined. Assume we have another case, where we design an application that
      needs to know about all changes at the network layer (IP stack, paths) and
      the status of the 802.11 networks. In that case, we join a
      NAL_SUBSCRIBE_LAYER type for the network layer with a
      NAL_SUBSCRIBE_TYPE type for the WLANNetwork NRM type.
          Instance subscriptions are useful in cases we want to follow the changes
      for a single entity. These kinds of subscriptions assume we know the
      instance identifier of the entity. Suppose we want to know when an
      Ethernet interface is connected to a network by a cable plugged into the
      interface. In that case, we subscribe using a NAL_SUBSCRIBE_INSTANCE
      type with NAL_TYPE_ETHERNET and the instance identifier as parameters.

4.2.3 State updates
      After receiving a subscribe message from a client, the NAL provides a
      snapshot of the current state to the client for those entities that match with
      the subscription. From that point on, the NAL indicates changes in relation
      to the previous state; it does not send a full snapshot after every state
      change. In this way, a client is informed exactly where the state changes
      have taken place and it does not have to find out these changes itself by
      comparing an old snapshot with a new snapshot. As a drawback of this
      approach, the client is required to keep track of that part of the state it is
      interested in. If preferred, though, a client can always get a new snapshot of
      the state of interest by disconnecting and reconnecting to the NAL and then
      resend the subscribe message.
          Now, let us consider state updates in more detail. The state snapshot
      describes the state of all network resource entities covered by the
      subscription, and it does so in a consistent way. With consistency we mean
      here that the NRM instances refer to other instances in a consistent way (no
58                      CHAPTER 4                                     STATE NOTIFICATION AND CONTROL



                        dangling references) and that the descriptions of all entities reflect the
                        current state. When the state changes, for instance a new 802.11 network
                        gets into range, the NAL notifies the client of this change. This notification,
                        however, concerns not only the new WLANNetwork but also the existing
                        WLANInterface, because the interface refers to the networks currently in
                        range. Therefore, we can not simply notify the client of the existence of a
                        new network, followed by the notification of the change of the interface,
                        because in between these notifications the state is inconsistent: a new
                        network exists but the associated interface does not refer to this network
                        (yet). This problem can be tackled by the usage of a transaction mechanism.
                        Then, any state change notification takes place in the context of a
                        transaction, so that the client knows that first the transaction must end in
                        order to have a consistent state again. Note that this transaction system is
                        only used to consistently communicate state changes from the NAL to the
                        application, and not for changing the state with control messages.

Table 4-2 NAL message   Message type                  Description / Parameters / Data
types                   NAL_MSG_TRANS_BEGIN           Indicate start of transaction. No parameters
                        NAL_MSG_TRANS_END             Indicate end of transaction. No parameters
                        NAL_MSG_CREATE                Data of newly created entity
                        NAL_MSG_UPDATE                Data of updated entity
                        NAL_MSG_DELETE                Identifier of deleted entity
                        NAL_MSG_SUBSCRIBE             Subscribe to parts of the resource description.
                                                      Takes a subscribe array as parameter
                        NAL_MSG_IOCTL_CALL            Execute an ioctl command. Parameters:
                                                      callid (this call’s identifier)
                                                      type (instance type)
                                                      id (instance identifier)
                                                      ioctl (ioctl number)
                                                      params (ioctl parameters)
                        NAL_MSG_IOCTL_RESULT          Result of an ioctl call. Parameters:
                                                      callid (call identifier)
                                                      result (boolean indicating call success )
                                                      output (output of the call)


                        A NAL transaction is implemented using two messages: the
                        NAL_MSG_TRANS_BEGIN and the NAL_MSG_TRANS_END messages. All state
                        change notifications are provided in a sequence of NAL messages, starting
                        with NAL_MSG_TRANS_BEGIN and ending with NAL_MSG_TRANS_END.
                        When an entity has changed and it matches the client subscription, the
                        NAL sends a NAL_MSG_UPDATE message with the complete data describing
                        that entity. Similarly, when a new entity arrives, a NAL_MSG_CREATE
                        message is sent and when an existing entity is removed, a NAL_MSG_DELETE
                         STATE CONTROL                                                             59



                         message is sent. A complete overview of existing NAL messages is provided
                         in Table 4-2 (ioctl messages are discussed in Section 4.3). The session
                         between application and NAL, including all its messages, are defined at the
                         end of Appendix A.

Figure 4-4 Interaction
between NAL client and
NAL to obtain state
updates




                         The state update interaction between the NAL client and the NAL is
                         depicted in Figure 4-4. Both the initial snapshot of the state as well as all
                         subsequent state updates are performed in a transaction context. Note that
                         we use create messages to describe the state snapshot, while all the change
                         messages (create, update or delete) are used for state updates. An arbitrary
                         number of change messages may be sent within a transaction context.
                         When no entities match the subscription, an empty snapshot is provided.


               4.3       State control
                         Applications influence the state of the network resources on the mobile
                         device in various ways, even those that simply use the transport layer
                         abstraction: when an application for instance establishes a straightforward
                         TCP connection with another node on the internet, the operating system
                         creates transport layer state associating this connection with a local IP
                         address and port used to send packets over one of the existing links.
60          CHAPTER 4                                  STATE NOTIFICATION AND CONTROL



                In this section, we discuss the explicit actions (in contrast to the implicit
            action above) that applications take to influence the state of the network
            resources, most notably at the network and link layer. The availability and
            configuration of network resources, however, is also influenced by
            functionality in the operating system. We therefore begin this section with a
            discussion on the interaction between application influence and operating
            system influence on the state of the network resources. Furthermore, we
            observed (in Section 3.1.3) that the Socket API provides a means to partially
            influence the state: in particular, it allows applications to select the outgoing
            path(s) for a transport initiated through the Socket API. We describe this
            method of control in detail, and point out the differences between a
            number of operating systems. We position the NAL as a facility coexisting
            with the Socket API, in such a way that functionality covered by the Socket
            API is not repeated by the NAL. It therefore is important to have a clear
            overview of the control capabilities of the Socket API. Finally, we discuss
            the NAL facilities that influence the state.

     4.3.1 Interaction with default system behavior
            The decision to have network interfaces activated, connect to in-range
            wireless networks, and select outgoing paths is partly the responsibility of
            the operating system. The interaction between applications and system –
            when it comes to the activation and assignment of available resources – has
            been an extensive topic of study (see for example [88]). The target platform
            is a single-user mobile device with a general purpose operating system that
            simultaneously runs multiple applications. We take a straightforward
            approach by assuming that the operating system implements default
            behavior that can be overridden by applications. We do not consider
            mechanisms that may help to resolve conflicts between applications: we
            think of this as a responsibility of the user. A conflict, for example, exists
            when one application decides to activate an available 802.11 network, while
            another application decides to activate another available 802.11 network.
            We assume that the user is aware of applications running on the mobile
            device and is aware of the potential conflicts that may arise when running
            applications concurrently.
                We adhere to the following principles. On the one hand, the up front
            default operating system configuration for the activation and assignment of
            network resources is determined by a rough estimate of the needs of the
            applications that will run on the devices. On the other hand, the
            applications are designed with a general notion of this default system
            behavior in mind. For instance, the OS assumes that at least one network
            interface must be activated to offer internet connectivity to applications. A
            network resource unaware application assumes IP connectivity to the
      STATE CONTROL                                                               61



      internet, while an aware application may activate and use other networks
      than the system activated network to better match application needs. When
      looking at the examples in Section 3.1, certain actions such as network
      discovery settings and network activation decisions may therefore already be
      realized by the system: in that case the application only needs to select from
      what is available. This can be done by obtaining a snapshot of the currently
      available network resources, decide which outgoing path to use, and bind to
      this path – using the Socket API – during connection initiation.

4.3.2 Interaction with the Socket API
      When creating a UDP or TCP socket using the Socket API, it is possible to
      assign it a local IP address; an action which is called binding. We assume that
      when an application wants to initiate a connection to a host elsewhere on
      the internet and it wants to force the traffic for this connection over a
      specific network interface, it binds the local socket for that connection
      explicitly to the IP address associated with the preferred interface. The
      mobile device forces outgoing packets over the preferred interface and the
      routing infrastructure delivers incoming packets on this interface. This
      outgoing routing behavior is default for Windows Mobile and Windows XP.
      For the Linux operating system, however, the situation is different.
          By default, the Linux kernel selects the outgoing interface for an IP
      packet based on the destination address only (checked for kernel version
      2.4). In this case, the kernel always forwards the outgoing IP packets to the
      gateway directly reachable through the default interface, even when the
      socket is bound to an IP address associated with a non-default interface.
      The packets leave the host through the default network interface with a
      source address that belongs to another interface. While this may work in
      terms of end-to-end communication, it results in a return path that is
      different from the outbound path. In practice, the outgoing packet is
      dropped by the gateway router because of ingress filtering [38]. More
      importantly, the communication partly goes through a non-preferred local
      network.
          Fortunately, Linux supports more advanced ways of route selection in
      the form of policy based routing (see [75] and [72]). This functionality
      (available from kernel version 2.2 and up) uses multiple routing tables and a
      routing policy database (RPDB) to select routes based on a number of
      criteria such as the source address. It supports the configuration of multiple
      routing tables. To route an outbound IP packet, the kernel selects a table
      based on a number of attributes associated with the packet.
          A Linux based mobile device can configure the policy based routing
      facilities in such a way that the outgoing IP packets leave the mobile host
      through the interface that is associated with the source address. For every
62         CHAPTER 4                                 STATE NOTIFICATION AND CONTROL



           network with a gateway to other networks, typically to the internet, it
           configures a dedicated routing table that is essentially a copy of the main
           routing table except for the default route. The dedicated routing table has a
           default route that points to the gateway reachable through this specific
           network and interface. A rule in the RPDB prescribes that the dedicated
           routing table must be used when the source address matches the address
           associated with this interface. For applications that do not explicitly set the
           source address, the default route in the main routing table applies. The
           device changes the default route in the main table when it decides that the
           regular default route must point to another network. A network without a
           gateway does not get a dedicated routing table, because it is used only for
           local communication.
               So, we see now that a few very common network stack implementations
           are configured by default or can be configured such that binding a socket to
           a local IP address determines over which link the outgoing traffic will be
           directed. This gives the application control over which (wireless) networks
           to use, and gives means to determine whether a connection should be
           managed by Mobile IP. The information on the IP address of each interface
           and the characteristics of the associated link is obtained through the NAL.

     4.3.3 Control messages
           The Socket API gives a fair amount of control over the usage of network
           resources, but does not support technology specific actions such as wireless
           scanning and wireless network activation. Some of the required actions may
           be taken by the operating system by default. However, in case an
           application needs to override this default behavior, it must use technology
           specific APIs to execute the actions.
               We have defined two NAL messages that can be used to implement
           NRM type specific actions. The concept is loosely based on the UNIX
           ioctl() system call (see [119], pp. 67) that manipulates hardware device
           parameters. These messages are NAL_MSG_IOCTL_CALL and
           NAL_MSG_IOCTL_RESULT and are listed in Table 4-2, together with their
           parameters. A NRM type may define ioctl numbers for specific actions
           such as ‘execute a scan’ or ‘active visible network X’. A NAL client performs
           this action by sending a NAL_MSG_IOCTL_CALL message to an existing
           entity (with the specified type and instance identifier) and provides the
           ioctl number and, when necessary, the ioctl parameters. Furthermore,
           the client specifies a callid call identifier which is used to uniquely
           identify this ioctl call per application. When the NAL returns the result of
           the call with the NAL_MSG_IOCTL_RESULT message, it passes back the call
           identifier so that the client knows to which call the result applies.
                            NAL SYSTEM SERVICE                                                              63




Figure 4-5 State update
to all applications after           application                 application                 application
change        by     one
application (right)

                                                                   API
                                NAL
                                                     network
                                                                              control map
                                                  resource state



                                   API                    API                  API                    API


                                                           operating system



                            When specified for generic types, an ioctl operation may apply to a broad
                            range of technologies. The NRM is a data model and therefore does not
                            specify operations. We have chosen for this mechanism to be able to
                            flexibly add operations when the need arises.
                                Obviously, when one application changes the state of the network
                            resources, the other applications subscribed to state changes will be
                            notified. This is depicted in Figure 4-5, where a control action from one
                            application results in calls to two system APIs. Note that state changes are
                            only communicated to the applications when the operating system signals
                            the state change (in the figure indicated through two system APIs).


                 4.4        NAL system service
                            So far, we discussed the interface the NAL provides to applications. We
                            now propose a design for the NAL that is suitable to implement on
                            currently available mobile devices, and that can be used to evaluate the
                            abstraction provided by the NRM and NAL interface in a real environment.
                                The NAL may be implemented in various ways. It can be a library that
                            links with the application, retrieving necessary device and technology
                            specific information directly from the operating system. Alternatively, it
                            may be deeply embedded inside the operating system kernel, as a kernel
                            module or a similar kernel extension facility. Or, the NAL functionality may
                            be implemented by a standalone process in user space, with client
                            communication based on inter-process communication (IPC). The main
                            drawback of a library solution is that the same information must be
64                       CHAPTER 4                                STATE NOTIFICATION AND CONTROL



                         retrieved multiple times if multiple applications use it. A kernel module
                         may be most appropriate when optimization of the NAL functionality is
                         important, or when direct access to kernel state is necessary to provide
                         NAL functionality. We have chosen to develop the NAL as a standalone
                         process that accesses the network resources through available system calls
                         and libraries. It keeps track of the state of these resources and
                         communicates any changes to its clients, depending on their subscriptions.
                         The process executes actions on the resources – if not possible through the
                         Socket API – on behalf of the client applications.
                             The NAL has two types of interfaces: one for interaction using binary
                         messages and another for interaction with XML messages. Using XML
                         messages has as advantages that they are platform neutral and that they carry
                         instance data according to the NRM schema definition. The messages as
                         discussed in the previous sections are part of the NRM schema definition.
                         The messages over the binary interface use native representations of the
                         NRM types, which can be easily handled at the client side without requiring
                         XML parsing. The native interface, however, requires linking the
                         application with the NAL client library. Both interfaces offer the same
                         functionality: the application designer chooses the interface most
                         convenient for the application.

Figure 4-6 Design of




                                                                                                  Application
the NAL system service




                                                                                                  NAL
                                                                                                  OS




                         The NAL has a modular, multi-threaded design, consisting of the following
                         components:
                         – IPC handler (thread)
                         – Message handlers (one thread per handler)
      SUMMARY AND DISCUSSION                                                       65



      –   Repository storing the current network resource entity state and keeping
          track of the ioctl methods registered by the plug-ins
      – Plug-in handlers (one thread per plug-in)
      – Client library (exposing the NAL API for native interaction)
      These components are depicted in Figure 4-6.
          As part of the core NAL functionality, the IPC handler thread waits for
      channel establishment by an application. A new channel is immediately
      passed on to a message handler thread; the IPC handler goes back to
      listening for incoming client connections. The message handler checks the
      incoming message: if it is a NAL_MSG_IOCTL_CALL message, a lookup of
      the method is performed using the entity / method repository, the method
      is executed, and results are passed back to the client. If the incoming
      message is of type NAL_MSG_SUBSCRIBE, the message handler registers the
      channel to the repository – so that later changes to the entity states in the
      repository can be passed back to the client – and then provides a snapshot
      of the current repository content (taking the subscription specification into
      account).
          The current state of the available network resources is stored in the
      repository. The NAL follows a fully ‘pluggable’ architecture: the content of
      the repository is kept up to date through plug-ins. A plugin is responsible
      for monitoring and controlling a particular system service or physical
      interface. This makes the NAL extensible and easy to configure for different
      kinds of mobile devices. Each plug-in is responsible for its own set of NRM
      types. At startup, the NAL looks for plug-ins, typically implemented as
      shared libraries, and starts the plug-in entry point function in its own
      thread. Every change to the repository by plug-ins is executed in the
      context of a simple internal transaction (not to be confused with the
      message transactions defined in Section 4.2.3). Every internal transaction
      consists of three phases: a main phase where the major changes to the
      repository are made, a hook phase where all other plug-ins have a chance to
      react to these changes, and a fix phase that gives the transaction initiator the
      opportunity to make final fixes before the end of the transaction. This
      phased transaction is convenient when references between entities managed
      by different plug-ins must be made. At the end of the transaction, the
      repository will notify all subscribers – if necessary – of the changes.


4.5   Summary and discussion
      In this chapter, we have introduced a middleware facility for network
      resource state notification and control to mobile applications, building on
      the NRM resource abstraction described in the previous chapter. This
      network abstraction layer, abbreviated as NAL, provides applications with a
66   CHAPTER 4                                 STATE NOTIFICATION AND CONTROL



     flexible view on relevant resources, which is necessary to prevent flooding
     the application with state updates and to make sure that the updates are not
     too detailed. We have chosen a mode of operation where the interaction
     between application and NAL is based on messages.
         The resource views are realized with subscriptions specified by the
     application. A subscription can be defined for state updates on all NRM
     instances of a complete layer of the protocol stack, for all the instances of a
     specific NRM type, or for changes in the state of a single entity. By
     combining these subscriptions and selecting the right level in the NRM type
     hierarchy, an application can precisely tune which state information to
     receive.
         Resource state updates are provided by the NAL in an incremental
     manner: when a NAL client connects and subscribes, it first receives a full
     snapshot of the current state, matching with the subscription. Subsequently,
     it receives NAL messages that indicate create, update, or delete state
     changes for individual resource entities. To ensure a consistent state
     description, all state change messages occur in the context of a transaction.
         We have shown that an application can control a fair amount of
     resources by binding a local IP address to a network interface using the
     Socket API. Additional means to control network resources, such as the
     activation of network interfaces, the initiation of wireless network scanning,
     and the connection to wireless networks, is provided by the NAL with
     ioctl type of messages.
     The NAL can be implemented in different ways. We propose a NAL design
     as a system service in a standalone process. Applications connect to this
     service using inter-process communication. The design is modular, where
     plug-ins are responsible for keeping track of a range of NRM types, which
     makes it easier to add new link technologies and protocols when they
     become available. The NAL design supports both binary as well as XML
     based message interaction with clients. It is expected that this design can be
     implemented on mobile devices without consuming many resources, such
     as CPU cycles and memory.

     One feature of the NAL that can be regarded as a drawback is the usage of
     loosely defined operations for NRM types through ioctl-style calls.
     Although it is a highly flexible mechanism, we have not defined in a rigid
     manner operations on network entities. It may be possible to integrate
     operations in the NRM definition and then provide access to the operations
     with additional NAL message types. We have not investigated to which level
     operations on wireless network technologies can be abstracted without
     giving up fine-grained control. High level operations provide control
     without the need for applications to know about the underlying technology.
     This is a topic for further research.
SUMMARY AND DISCUSSION                                                  67



    Another improvement can probably be made by adding a
NAL_MSG_READ      message to allow clients to directly read the data for a
particular NRM instance. This will support even more flexible client-NAL
interaction. It supports, for instance, navigating through the graph of NRM
instances by following references from one instance to another, which does
not require a dump of the full state.
                                                                 Chapter

                                                                           5
5. Evaluating the NRM and NAL
      In the previous chapters, we have illustrated the usefulness of the
      introduced network resource abstraction with a number of examples and
      scenarios. This chapter evaluates the NRM and NAL using a NAL
      implementation on the Windows CE operating system. It focuses on three
      aspects: the overhead in terms of system resource usage, the ease of
      deployment for an existing streaming audio application, and the
      appropriateness of the abstraction for that application.
          This chapter consists of the following sections. In Section 5.1 we discuss
      the NAL reference implementation. Section 5.2 shows the results for
      resource usage of this implementation. Section 5.3 provides the evaluation of
      the ease of deployment as well as the appropriateness of the abstraction.
      Section 5.4 provides an overview of the results and a discussion. Parts of this
      chapter are based on [96] and [94].


5.1   NAL reference implementation
      The implementation of the NAL is based on the design provided in Section
      4.4. We have considered a number of platforms as the target for this
      implementation, including Symbian, Windows CE, and Linux running on a
      high-end mobile device. We required hardware with multiple wireless
      interfaces to be able to explore whether the NAL could be implemented
      and used with a variety of different network technologies. This led to the
      choice of Windows CE as the target operating system, because at the time
      of the NAL implementation and evaluation (first half of 2006), the few
      available mobile devices with integrated cellular, 802.11 and Bluetooth
      technology were based on this operating system. The NAL system service is
      implemented in the C programming language, because access to network
      resources is in many cases only possible through low-level system APIs in
70                       CHAPTER 5                                  EVALUATING THE NRM AND NAL



                         the C language. The NAL client library is implemented in C as well, because
                         many Windows CE applications are based on C or C++.
                             We will discuss now the implementation of the NAL on Windows CE,
                         starting with an implementation overview. Furthermore, we describe the
                         NAL plug-ins (modules) we have implemented and discuss the client library
                         used by applications to access the NAL service.

               5.1.1 Implementation overview
                         The implementation of the NAL system service consists of a small
                         executable that starts two threads on startup: one thread that creates the
                         repository, loads the modules as dynamically linked libraries (DLLs) and
                         then acts as IPC handler, and another thread that handles the graphical user
                         interface (GUI) of the NAL. This part of the service is called nal_core.
                             Most work in the NAL service implementation takes place in the
                         modules, each responsible for keeping up to date the resource state of a set
                         of NRM types. When a module is loaded, a number of module entry points
                         will be called by nal_core. The typereg entry point registers all the types
                         this module is responsible for, which is necessary to map type names to
                         type representations, for instance when an XML client subscribes. The
                         transhook entry point registers the module functions that are called
                         during the three phases of a repository transaction (see the end of Section
                         4.4). Finally, the threadproc entry point is started in its own thread, to
                         take care of inserting state changes in the repository when they occur. As
                         depicted in Figure 5-1, we have created five modules.

Figure 5-1 Overview of
NAL implementation
                                                                                                 Application
                                                                                                 NAL
                                                                                                 OS
                        NAL REFERENCE IMPLEMENTATION                                                         71



                        Every module has its own .h header file defining the types it keeps track of
                        as C structs. These header files are used by C and C++ based applications
                        that communicate with the NAL over the binary interface: the state updates
                        over the binary channel consist of these structs. The NRM type hierarchy is
                        realized with nested struct definitions, where the super-struct is defined as
                        the first element in the sub-struct. According to the ANSI C99 standard
                        ([16], paragraph 6.7.2.1, item 13), this allows for casting an instance
                        pointer from one type to another, because a pointer to a struct object is
                        guaranteed to point to its initial member. So, even though the C language is
                        not object oriented, we support the NRM type hierarchies using this
                        mechanism.
                            The NAL implementation consists of approximately 11000 lines of C
                        code (.c and .h files) and has a combined executable size (executable file
                        and module files) of 90kB.

              5.1.2 Service modules
                        Every supported physical link layer technology has its own module in the
                        NAL reference implementation. Furthermore, an additional module,
                        nal_base, takes care of reflecting state changes for the other NRM
                        entities. An overview of the available modules is provided in Table 5-1. Let
                        us now take a closer look at the individual modules.

Table 5-1 NAL modules   Module       NRM type definitions                          Windows CE system API usage
                        nal_base All abstract types and all non-abstract types IPHLPAPI
                                     that do not represent physical link technologies WINSOCK2
                        nal_ndis 802.11 types                                      NDISUIO
                        nal_ras      Serial link types                             RAS
                        nal_cell Cellular types                                    RIL
                        nal_bt       Bluetooth types                               WINSOCK2


                        The nal_base module is a catchall plug-in for those NRM types that are
                        expected on a typical Windows CE mobile device, such as the loopback
                        interface and network and the stack elements in the network and transport
                        layer. Contrary to the other modules, we expect this module to be always
                        present on a device: the other modules are only relevant in case the device
                        is equipped with the link technology covered by that module. This module
                        uses several Windows CE system APIs, of which the IP helper API
                        (iphlpapi) and the Socket API (WINSOCK2) are the most prominent.
                            The nal_ndis module is responsible for reflecting the state of the
                        802.11 resources available on the device. To scan for available 802.11
                        networks and gather information about access points and received signal
72   CHAPTER 5                                   EVALUATING THE NRM AND NAL



     strengths, it uses the ‘NDIS User Mode I/O’ driver (NDISUIO). On active
     interfaces, the default scan interval is 5 seconds.
          The nal_ras module keeps track of the state of the fixed serial link –
     typically a USB connection – using the ‘Remote Access Service’ (RAS) API.
          The nal_cell module uses the ‘Radio Interface Layer’ (RIL) to obtain
     status updates on the available operator networks as well as in-range base
     stations and their signal strengths. Unfortunately, on the devices we used,
     the RIL API is only able to provide information of the currently used base
     station. It does give information about in-range operators. By default, we
     refresh the currently used base station every 5 seconds and update the list of
     in-range operators every 5 minutes.
          The nal_bt module performs an inquiry on nearby Bluetooth nodes
     using the Socket API in combination with a Microsoft Bluetooth stack. It
     indicates the Bluetooth device address and user-friendly name of in-range
     devices to the NAL core. By default, this module inquires for in-range
     nodes every 3 minutes.
          Note that neither nal_base nor another module supports Mobile IP
     types, because we have chosen not to include this functionality in the NAL
     reference implementation. The evaluation of the NRM and NAL is based on
     a scenario that does not require the usage of Mobile IP. Also, very few (if
     any at all) commercially available Windows CE devices have Mobile IP
     functionality included by default.
          The scanning intervals on the wireless interfaces as indicated above are
     chosen to reflect changes quickly, without severely interrupting the regular
     usage of the wireless interface. On our target device, scanning for available
     operators may take considerable time (up to 30 seconds), so we only do
     this once every 5 minutes. Likewise, scanning for Bluetooth nodes takes
     around 10 seconds during which regular Bluetooth communication is
     halted. As far as we observed, obtaining the current cellular base station
     information does not influence cellular operation at all, and 802.11 only
     little, so we use shorter intervals for these technologies.
          The threads of the individual modules and the NAL core execute as long
     as the device is in an active power mode. The version of Windows CE we
     used, however, has a power manager that brings the device in a suspended
     mode of operation at the moment the user no longer has interaction with
     the device (through the screen or the buttons). In this mode, no CPU
     operations are executed, which implies that the NAL no longer registers the
     state of the network resources on the devices. This is not a problem,
     because the applications on the device acting as NAL clients do not run
     either. The transition from one power state to another, however, can
     influence the state of the network interfaces: it is therefore common to see
     more state dynamics in the event of power changes. An example is the
     802.11 interface, which is often deactivated in a suspended power state to
                           NAL REFERENCE IMPLEMENTATION                                             73



                           save battery power, and is reactivated when the power state transitions into
                           the active state. The NAL picks up this situation: at reactivation of the
                           802.11 interface, the 802.11 networks are not immediately available, and
                           an IP configuration temporarily does not exist.
                               We have found that various pieces of functionality of the NAL
                           implementation are device specific (i.e., behave differently on different
                           hardware). The initial hardware platform we targeted with this reference
                           implementation is the Qtek 9090 Windows CE device, equipped with
                           GSM/GPRS, 802.11, Bluetooth and USB network interfaces. Later, we also
                           tested and used the NAL on other devices (see Chapter 6), but this is no
                           guarantee that the implementation works well over a wider range of
                           Windows CE devices. The diversity in hardware, as well as the configuration
                           of Windows CE and manufacturer specific components in the operating
                           system, make it difficult to have a highly portable NAL, especially for the
                           plugins.

                5.1.3 Client library
                           The NAL client library is a dynamically loadable library providing an
                           interface in the C programming language to the NAL functionality. It has
                           means to setup a channel with the NAL service, and provides functionality
                           to handle NAL messages and NRM types. The interface consists of a set of
                           C header files.

Figure 5-2 NAL GUI
(left) and NAL command
line client (right) on a
Windows CE device




                           The IPC channel between the client and service is realized with an
                           implementation of a full duplex (reliable) pipe, using Windows CE message
                           queues. The NAL server has two mount points, one for the binary interface
74         CHAPTER 5                                    EVALUATING THE NRM AND NAL



           and one for the XML interface, that receive incoming pipe setup requests.
           After pipe establishment, and sending an initial subscription or ioctl
           message, the client receives incoming messages from the NAL by reading
           from the pipe handler. Alternatively, the client may first wait for the pipe
           handler to have pending messages before it starts reading them, which is
           useful in case the client wants to avoid blocking on a read call.
               Over the binary channel, NRM objects are received as C structs in native
           (i.e., machine dependent) format. For those types that have variable size
           attributes – represented in C with pointers – the object is serialized at the
           sending side and deserialized at the receiving side. The XML channel carries
           messages in XML text, which can be used by non-C clients. Note, however,
           that the pipe functionality is not part of the regular Windows CE IPC
           mechanisms, which requires XML based clients to still use the NAL client
           library for the pipe functionality. We have provided Java and C# library
           implementations that wrap the C library pipe functionality and translate
           XML objects to Java and C# objects. The Java library is used by another
           effort described in [90], and the C# interface in the trial software in
           Chapter 6.
               Figure 5-2 shows two examples of NAL clients. At the left hand side, the
           NAL GUI provides a network resource state summary in a Windows CE
           bubble. Although running inside the NAL service process, the GUI thread
           acts as a NAL client. At the right hand side, the output of a NAL command
           line client shows, amongst others, the update of an 802.11 network inside a
           transaction context.


     5.2   System resource usage
           Compared to a personal computer, a mobile device has limited computing
           resources. Its CPU is slower, the amount of available RAM memory and
           persistent storage is less, and it is restricted by the amount of available
           battery power. Software running on a mobile device must therefore be
           designed to limit the consumption of computing resources as much as
           possible, especially, as is the case for the NAL service, when this software is
           running in the background continuously. While processing performance
           and amount of memory is expected to grow in line with Moore’s law, and
           therefore is less of a concern for future devices, the battery technology does
           not improve at an exponential rate, which makes careful power
           consumption crucial, now and in the years to come.
              The NAL design and implementation has a number of features that
           limits resource consumption. The NAL does not rely on a large framework
           to exchange messages with clients, such as libraries for XML remote
           procedure calls [3], but instead uses simple messages over a low-level IPC
                          SYSTEM RESOURCE USAGE                                                                      75



                          mechanism. This reduces the amount of processing needed to send
                          messages back and forth and limits the necessary amount of memory.
                          Furthermore, the NAL is implemented in C, which does not require a
                          runtime environment such as necessary for interpreted or bytecode
                          languages (e.g., script languages, C# or Java). Also, the subscription and
                          notification mechanism ensures that clients receive instant updates of the
                          state changes without polling.
                              We have investigated the resource consumption of the NAL service
                          implementation on a Qtek 9090 Windows CE device. This device has an
                          ARM CPU with a clock rate of 400 MHz, 128 MB of RAM memory, and
                          48 MB of persistent solid state memory. It is equipped with a GSM/GPRS
                          cellular network interface, an 802.11 WLAN interface, a Bluetooth 1.1XXX
                          network interface, and a USB serial interface. This device has a back-lit
                          touch screen with a dimension of 240 x 320 pixels. User input is provided
                          through the touch screen and via a set of hardware buttons.
                              When running the NAL on this device, the memory usage of the NAL is
                          well below 100 KB, whether a client is connected or not. The observed
                          CPU usage is very low (close to 0%), under a low intensity of clients
                          connecting and disconnecting.

Figure 5-3 Influence of                                 100
the NAL service on the
power consumption of a
                                                         95
test device

                                                         90
                             battery energy level (%)




                                                         85


                                                         80


                                                         75


                                                         70


                                                         65       NAL off, 802.11 off
                                                                  NAL on, 802.11 on
                                                                  NAL off, 802.11 on
                                                         60
                                                              0      20           40          60         80   100   120
                                                                                        time (minutes)



                          We have executed the following experiment to measure the extra power
                          consumption caused by the NAL service. The device is placed in a static
                          environment, meaning that it stays in a fixed geographical location and is in
                          range of a relatively static number of wireless networks. We perform several
76         CHAPTER 5                                    EVALUATING THE NRM AND NAL



           two hour runs in which the energy level of the device’s battery is recorded,
           starting every run with a fully charged battery. In the first run, the network
           interfaces are activated and the NAL service does not execute. In the second
           run, the interfaces are activated and the NAL service is running. The
           command line client connects to the NAL and subscribes to all information
           from all layers (i.e., the broadest possible subscription). In the third run, we
           activate all network interfaces except the 802.11 interface, and do not
           execute the NAL service. The results of these runs are depicted in Figure 5-
           3.
               From this figure, it is clear that running our NAL service
           implementation consumes virtually no extra energy, because the two lines
           ‘NAL off, 802.11 on’ and ‘NAL on, 802.11 on’ coincide almost completely.
           In this two hour period, the NAL produces around 40 messages at startup,
           to provide a full snapshot of the available network resources, and slightly
           more than one update per minute for the rest of the run. These updates
           reflect minor changes in the network resources, such as signal strength
           changes and occasional changes in the set of visible networks. In contrast,
           the figure shows that switching off the 802.11 interface does make a
           significant difference. We therefore conclude that from a perspective of
           system resources consumption, it is very well feasible to offer NAL
           functionality on mobile devices.


     5.3   Ease of deployment and abstraction appropriateness
           One way to evaluate a middleware facility is to apply it in an existing
           application scenario and then analyze the effort this took. We call this the
           ease of deployment, where a limited deployment effort can be considered as a
           benefit. In our specific case, another way to evaluate our middleware is to
           apply it in an existing scenario and determine how appropriate the offered
           abstraction is: how well the NRM and NAL features match the task at hand.
           We call this the abstraction appropriateness. Obviously, ease of deployment and
           abstraction appropriateness are closely related. We therefore consider these
           two aspects jointly in a real world case, by applying the NAL reference
           implementation in an existing streaming audio setup.
               It is not our intention to measure handover performance here, because
           fast handover functionality is not what our middleware is meant to support.
           The NRM and NAL report on a fast handover process if it is taking place,
           for instance by notifying that a Mobile IP tunnel is moved from one
           interface to another very quickly after a new network becomes available.
           Faster handover functionality is likely to influence scanning activities and
           network activation activities, which requires that a NAL implementation
           running in conjunction with fast handover software must take this influence
      EASE OF DEPLOYMENT AND ABSTRACTION APPROPRIATENESS                          77



      into account. Although this would require further research, we expect that
      joining the NAL functionality and the fast handover functionality into a
      single system service helps to more easily coordinate such activities as
      scanning.
          We start this section with a definition of the experiment we executed
      with the audio streaming application (Section 5.3.1). Then, in Section 5.3.2
      we discuss in detail the code modifications that were necessary to support
      this application with the NAL. Furthermore, in Section 5.3.3 we analyze the
      interaction between the streaming client and the NAL. Finally, we discuss
      the streaming results (Section 5.3.4).

5.3.1 Experiment definition
      The application we use for evaluating the NRM and NAL is a streaming
      audio player, running on the mobile device of the user and using a
      heterogeneous set of networks to obtain the audio stream from an audio
      server. This server is located in the home of the user and contains the user’s
      personal audio collection. We choose this application, because it is
      demanding in terms of the transferred amount of data and also because it
      may adapt the playback audio quality given the maximum available
      throughput between server and player at a particular moment.
          We use existing software to stream to and play music on the mobile
      device. The server software is the open source SlimServer streaming server
      [115], which is primarily used to stream high quality audio to dedicated
      audio hardware, but also has functionality to stream to software clients over
      the HTTP protocol. The client software is the open source GSPlayer audio
      player [44], which is able to handle these audio streams over HTTP. Both
      products are not designed to support continuous audio playback in case of
      internet attachment changes at the client side.
          In this experiment, we adapt these products to play a selection of the
      user’s music collection in a continuous way on the mobile device – with the
      best possible quality given the wireless networks available at the client side.
      To do this for the GSPlayer software, we use the abstraction and the
      functionality offered by the NRM / NAL combination. At the server side,
      we must modify the SlimServer to maintain session state in case of
      interrupted client connectivity. Because our middleware resides on the
      client side, we mostly focus on the software changes for the GSPlayer.
          To assess that the changes we made deliver the required continuous
      audio playback, we execute the software in the following dynamic
      environment. The server machine is connected to the internet and runs the
      modified SlimServer software with a collection of audio files in the MP3
      format [82]. The mobile device runs the NAL reference implementation
      and the modified streaming audio player. The player interacts with the NAL
78                      CHAPTER 5                                   EVALUATING THE NRM AND NAL



                        and requests the server to stream a part of the music collection at a quality
                        level that matches the available network resources, aiming to get the best
                        MP3 audio quality available (up to the bitrate of the original MP3 file,
                        which is typically in the 128 kbps – 256 kbps range). If the available
                        network resources do not support the best quality stream, the player
                        requests the stream at a lower quality level. The mobile device has
                        intermittent connectivity with an 802.11 network and continuous
                        connectivity to a cellular GPRS network. The player therefore has to switch
                        stream quality when the 802.11 network becomes available or unavailable.
                        The evaluation environment is depicted in Figure 5-4.

Figure 5-4 Evaluation
environment based on
an audio streaming
application




                        Obviously, a significant change in the stream quality will be audible for the
                        listener. We assume here that this is acceptable for the listener and that the
                        only requirements for the stream are that an interruption of playback is
                        short (i.e., up to a few seconds) and that it keeps in sync over time (i.e.,
                        that it does not repeat or delay). Any interruption time is compensated such
                        that after the interruption, the time in the playing song is as if the
                        interruption had not happened. This is similar to a radio broadcast that is
                        interrupted for a few seconds, for example when driving through a short
                        tunnel.
                            This experiment is executed with the same device as the resource usage
                        experiment in Section 5.2. It is configured such that both the cellular and
                        the 802.11 interface are active, and that it remains fully on to enable audio
                        playback. The device does not have mobility management facilities such as
                        Mobile IP. This requires the player to reinitiate the stream with the server
                        after a network change. Access to the 802.11 network (when available) and
                        IP settings for the 802.11 interface, are automatically obtained by the
      EASE OF DEPLOYMENT AND ABSTRACTION APPROPRIATENESS                        79



      system. The 802.11 network consists of a single access point, that is
      switched on and off to realize intermittent 802.11 connectivity – simulating
      that the user walks in range and out of range.
          The above evaluation scenario resembles the streaming media player
      example discussed in Section 3.1.1.

5.3.2 Application modifications
      To support different stream qualities, the original MP3 files stored at the
      server must be transcoded to lower qualities. SlimServer is capable of
      transcoding on the fly, but we found that this sometimes introduces a delay.
      Therefore, we stored the music collection in different qualities on the
      server hard disk. We used the Lame encoder [67] to transcode the original
      files to files with a 16 kbps and 160 kbps bitrate, with a sample frequency
      of 22.05 kHz. These MP3 qualities are defined as part of the MPEG2
      standard [83]. The 16 kbps bitrate has a sound quality comparable to a
      shortwave radio transmission, while the 160 kbps bitrate has a quality
      virtually undistinguishable from the original. The 16 kbps stream can be
      carried over a GPRS link, which typically has a throughput of 28 kbps and
      up. The 802.11 interface can easily sustain the 160 kbps stream.
           SlimServer is implemented in the Perl interpreted programming
      language [100], which makes it relatively easy to make changes to this
      product. It has functionality to keep track of the session of a client and to
      take into account the requested bitrate of the stream. We added
      functionality to start the stream at an exact time during a song. A client
      sends a stream request in the form of an HTTP Uniform Resource Locator
      (URL) [7], and indicates the session identifier, bitrate, and stream begin
      time as URL parameters. This gives the client full control over the start
      time and quality of the stream. The additional functionality increased the
      SlimServer source code with 52 lines.
           GSPlayer is a multi-threaded native Windows CE application,
      implemented in the C++ programming language. It uses a data buffer that
      is filled by the stream from the server and emptied by playing the audio.
      Whenever the buffer is full, no more data is read from the TCP connection
      to the server and TCP flow control lets the server stop sending more data.
      This means that when the client connects and the play buffer is empty, a
      burst of data is transferred over the TCP connection until the buffer is
      filled. We use information about the amount of data in the buffer in
      combination with information from the NAL to decide to reinitiate the
      stream over another network interface. Furthermore, we keep track of the
      current time of the received song data, so that at stream reconnection the
      client can start receiving data from that time on.
80          CHAPTER 5                                    EVALUATING THE NRM AND NAL



                The modified GSPlayer runs a NAL client thread that subscribes to
            NRM link types and IPv4 gateway path segment types (the code in Figure 5-
            5 shows how instances of these types are read from the NAL pipe). At all
            times, it marks the path segment over the link with the highest maximum
            throughput as the best path segment. The stream receiver thread checks if
            the preferred path segment has changed, and if this is the case, disconnects
            the stream over the currently used path segment and reinitiates the stream
            over the new preferred path segment. It uses two stream qualities, with a
            bitrate of 16 kbps and a bitrate of 160 kbps, and requests the maximum
            stream quality that can be carried by the link. Obviously, in case the wireless
            link is not the bottleneck, the stream quality may be too high to sustain: the
            receiver thread therefore switches to a lower quality (if possible) when the
            amount of data drops below a third of the total buffer capacity and then
            does not consider that path for a while as a viable option to carry the stream
            data. We used a buffer size of 30 seconds, which provides plenty of time to
            re-establish the connection with the server.
                The functionality added to GSPlayer increased the source code size with
            518 lines (in .h and .cpp files combined). In comparison, the NAL
            command line client described in Section 5.1.3 consists of a single .c file
            with 589 lines of code. Subscribing to the NAL and handling NAL
            notifications in the NAL client thread contribute around 300 lines of code
            to the total increase (more than half). Although this may seem like a lot,
            this functionality is very straightforward and takes a few simple steps: setting
            up a subscription array, connecting to the NAL, writing the subscription
            message, constructing the thread framework, waiting for notification of
            network resource state, and calculating the best local IP address to bind the
            socket to. The rest of the functionality – incorporating stream
            reestablishment in the core logic of the GSPlayer – was more complex.
            Most of this new functionality concerns the timing aspects of the song and
            management of the buffer size for streams with different bitrates. We
            conclude from this that the effort of staying informed of network resource
            state through the NAL was small compared to the effort of managing the
            stream handover. The deployment of the NAL interface and NRM
            abstraction was easy because it took only a few simple steps.

     5.3.3 Interaction analysis
            The interaction between the GSPlayer and the NAL service is
            straightforward, and largely the same as the example in Figure 4-2. To
            decide which path segment to choose for stream establishment, the player
            requires the following information: it must know which routes are available
            to connect to the streaming server, and it must know the maximum
            throughput of the available paths to the server – as far as possible. We do
                        EASE OF DEPLOYMENT AND ABSTRACTION APPROPRIATENESS                      81



                        not know the maximum throughput of every hop on these paths, but we do
                        know this for the first (wireless) hop. The player is not interested in the
                        network technology used.
                        int CReceiver::obj_read(struct nal_pipe *pipe,
                                                unsigned int size) {
Figure 5-5 GSPlayer       char *buf;
C++ code for reading      struct nal_array type_info;
gateway path segment      unsigned int i, type;
and link updates from     int type_len;
the NAL pipe (error       void *obj;
handling removed)         struct nal_type *tp = NULL;
                          size_t obj_size;

                            buf = (char *) malloc(size);

                            nal_array_init(&type_info, sizeof(uint32_t));
                            nal_pipe_read(pipe, buf, size);

                            type_len = nal_array_unpack(&type_info, buf, size);

                            for (i = 0; i < type_info.length; i++) {
                              nal_array_elem_get(&type_info, i, &type);
                              if (type == NAL_TYPE_IPV4GATEWAYPATHSEGMENT) {
                                tp = (struct nal_type *) IPv4GatewayPathSegmentType;
                                obj_size = sizeof(struct IPv4GatewayPathSegment);
                                break;
                              }
                              if (type == NAL_TYPE_LINK) {
                                tp = (struct nal_type *) LinkType;
                                obj_size = sizeof(struct Link);
                                break;
                              }
                            }

                            obj = malloc(obj_size);
                            memset(obj, 0, obj_size);

                            nal_obj_init(tp, obj);
                            nal_obj_unpack(tp, obj, buf + type_len, size - type_len);

                            if (type == NAL_TYPE_IPV4GATEWAYPATHSEGMENT)
                              update_pathsegment(obj);
                            else if (type == NAL_TYPE_LINK)
                              update_link(obj);

                            free(obj);
                            free(buf);
                            nal_array_clear(&type_info);

                            return 0;
                        }

                        This information is exactly the information offered by the NAL when
                        subscribing to the NRM link type and the NRM gateway path segment. We
                        do require two types because the throughput information is only available
                        for links. Because of the defined relation between path segments and links
82         CHAPTER 5                                   EVALUATING THE NRM AND NAL



           in the NRM, it is easy for a designer to understand that these two types are
           required to obtain this information. We therefore conclude that the offered
           abstraction was appropriate for this streaming audio application.

     5.3.4 Streaming results
           The application setup as described above delivers continuous streams over
           GPRS and 802.11 networks and switches between them when the 802.11
           network is switched on and off. The switch is audible due to the difference
           in quality as well as a little loss of sync of less than 1 second.
           Synchronization can most likely be improved when the start time indication
           is expressed in milliseconds instead of seconds.


     5.4   Summary and discussion
           In this chapter we have evaluated the NRM and NAL in a running system
           environment, using the NAL reference implementation for the Windows
           CE operating system. We have shown that the NAL can be implemented
           using few system resources such as memory, CPU cycles and battery power.
           Furthermore, we have shown that the NRM and NAL can be easily
           deployed in real world applications. To demonstrate this we chose an
           example that streams audio to a mobile device, such that it adapts the
           stream based on the available network resources. Also, we have shown that
           the abstraction offered to this application by the NRM and NAL matches its
           needs.

           We realize that evaluating middleware is generally hard, because it usually
           targets a broad class of applications. To get a full appreciation of its
           performance, we ideally exercise many applications covering this full range
           of applications. Although we have presented multiple examples and
           scenarios in the previous chapters, the real-world evaluation here clearly
           does not have this broad scope, which requires that its results must be
           interpreted accordingly. Still, by having running code with an existing
           application modified for a dynamic network context, we show that our
           abstraction proposal is very well feasible. Furthermore, our middleware has
           been used by others: the work in [90] shows a running healthcare tele-
           monitoring service that uses the NAL to select paths on a multi-homed
           Windows CE device.
               The NAL reference implementation by default keeps track of wireless
           networks in range. A useful optimization would be to take the current client
           subscriptions into consideration when deciding to start a scan activity: if no
           NAL client is interested in state updates for in-range wireless networks,
SUMMARY AND DISCUSSION                                                     83



there is no need to keep this state up to date in the NAL. This would
require insight into the available subscriptions by modules.
    We have chosen to keep the NAL interface simple, which keeps the
client library compact. This results in more client side code for actions that
may be generic for a wider range of applications. An alternative would be to
put more of this common functionality, such as selection of path segments
based on link speed, into the library.
                                                              Chapter

                                                                        6
6. Network Visibility Data
   The network resource model and abstraction layer introduced in the
   previous chapters allows mobile applications to deal in a flexible manner
   with status changes in the availability of network resources. The mode of
   operation for these applications is typically reactive, where they change their
   data communication behavior after an observed change in the network
   resource state. By tracing the visibility of networks over time, however, we
   may be able to forecast future changes in the network resource state, thus
   allowing applications to work in an anticipatory mode. Given that a
   significant amount of movements of people are governed by habits, we can
   use the data on the visibility of networks as seen by a person in the past to
   predict the visibility of these networks in the future.
       Chapters 7 and Chapter 8 deal with predicting future network events, such
   as the event of getting in range of a wireless network or the event of losing
   the visibility of a network. To validate the approach introduced in Chapter 7,
   we need real-world network status data collected on personal mobile
   devices that capture the visibility in time of surrounding wireless networks.
   We have executed an experiment with a duration of approximately 5 weeks
   that collects status changes on mobile devices with multiple network
   interfaces, using the CoSphere NAL software described in Chapters 4 and
   Chapter 5. This chapter describes that experiment. We refer to the
   experiment, here and in the following chapters, as the CoSphere trial. The
   experiment was part of a larger effort, the SocioXensor/CoSphere study
   that, apart from collecting network resource visibility data, also surveyed the
   activities of the participants and their willingness to take incoming
   communication requests from others (see [124]).
       The NAL service offers the possibility to receive information about all
   available network resources on a mobile device. This enables us to
   investigate prediction properties over a wide range of network technologies
   (see for results Section 8.1, Section 8.2, and Section 8.4). Additionally, we
   expect that information describing the visibility of networks through one
86         CHAPTER 6                                          NETWORK VISIBILITY DATA



           network interface may be used to enhance the prediction of the visibility of
           networks through another interface (see Section 8.3). To investigate this
           effect, we require traces from as many interfaces as possible. The network
           traces collected on mobile devices that are available as public data sets often
           incorporate only one technology (see for example the Haggle iMote
           experiments collecting Bluetooth readings [19], or the 802.11 data on
           PDAs described in [77]) or at most two different network technologies (see
           [33] for cellular and Bluetooth, and [106] for cellular and 802.11). Our
           objective was to concurrently collect data from those three interfaces that
           are now common on many higher-end mobile phones: the cellular, the
           802.11 and the Bluetooth interface.
               This chapter is organized as follows. Section 6.1 provides a description of
           the CoSphere trial including the kind of information gathered. Section 6.2
           discusses the execution of the trial, and Section 6.3 provides a high-level
           trace analysis and data characterization. The final Section 6.4 summarizes
           and discusses the results. Parts of this chapter are based on [92].


     6.1   Trial description
           We require data describing the visibility of wireless network resources as
           observed on personal mobile devices of real users, to evaluate methods to
           predict the visibility of these network resources over time. A wireless
           network resource may be an individual wireless network entity such as a
           cellular base station or a Bluetooth node, or be a wireless network made up
           of one or more individual entities. When defining an experiment that
           delivers such data, we need to take into account a number of important
           aspects: 1) we must understand the implications of gathering data in an
           accurate manner and 2) we must realize what it means to collect data from
           real users.

     6.1.1 Network detection accuracy
           The detection of wireless networks is done through the available network
           interfaces on the mobile device. Depending on the network technology and
           the current usage of a network interface, this may require a scan to
           determine which networks are available. A Bluetooth interface, for example,
           that has no active connections with other Bluetooth nodes must perform an
           inquiry to obtain a list of Bluetooth nodes in vicinity. If it has active
           connections, the interface knows that at least those connected nodes are
           within range. Alternatively, information about in-range networks may
           already be – wholly or partly – present within the interface driver or
           hardware. For instance, when a device connects to a cellular network, the
       TRIAL DESCRIPTION                                                              87



       cellular network interface is aware of the base station it uses, and may be
       aware of other nearby base stations in case it needs to select another, i.e.,
       due to user mobility or due to other reasons the current base station no
       longer can be used. Also, in some cases the information about nearby
       networks is cached in the network interface hardware or driver, so that it is
       necessary to force the interface to do a new scan in order to obtain an up to
       date list of visible networks. Therefore, for an accurate list of networks
       visible at a certain point in time, we must always take into account that it
       may be necessary to actively instruct the interface to execute a new scan,
       either because visibility information is (partly) not available, or because the
       visibility information is stale.
           To accurately register the visibility of networks over time, we must, in
       the ideal case, sample the network interfaces with a high frequency. This
       requires the interfaces to be switched on to scan for networks on a
       continuous basis. The maximum scanning frequency is determined by the
       network technology: for example, 802.11 requires in the order of hundreds
       of milliseconds for a full scan over all channels, while Bluetooth takes in the
       order of seconds to finish an inquiry. It is important to realize that not all
       technologies provide a scanning mechanism that guarantees that all visible
       network resources are actually detected. Bluetooth, for instance, may
       occasionally deliver an incomplete list in an environment with many
       Bluetooth nodes, as shown in [5]. Furthermore, when scanning for other
       network resources, a network interface is often not available for regular data
       communication.

6.1.2 Implications for participants
       A personal mobile device is carried by its owner during many daily
       activities. Even in cases when it is not carried, for instance at home or
       during sports activities, the device is often in the nearby surroundings of the
       owner. For most owners, the applications offered by the various kinds of
       mobile phones – such as communication with others and access to the
       internet – are worth the burden of semi-permanently holding on their
       phone [20]. To execute the experiment, we provided the participants with
       a trial device. We wanted the participants to regard and use their trial
       device as a regular mobile (smart) phone, offering the kinds of applications
       that they expect from such a device. Device owners have certain
       expectations for the ‘look and feel’ of the software on the device. Most
       device owners rely on existing environments and their productivity tools
       (such as mail synchronization) they are accustomed to: choosing an
       experimental OS and GUI – as we did for our application adaptation study
       in [98] – makes it harder for participants to use the device for their every
       day activities. If the trial device would not provide these applications (i.e., if
88                         CHAPTER 6                                          NETWORK VISIBILITY DATA



                           its sole purpose was to scan for surrounding networks), we expected the
                           participants to be not sufficiently motivated to carry it with them all the
                           time – at least not for a prolonged period of time. Also, in that case, the
                           participants would need to carry two devices: one for the trial and one as
                           their regular mobile phone. Therefore, we chose to collect data on devices
                           that participants can use for their daily activities. We want the participants
                           to notice as little as possible from the measurements taking place on their
                           device.
                               People use the network interfaces on their mobile devices in various
                           ways. The cellular interface is often active and used for voice calls and
                           internet connectivity. The 802.11 interface is typically used for internet
                           access at locations where the device is in range of an accessible 802.11
                           network. The Bluetooth interface is used for many different purposes such
                           as point-to-point data exchange, connections to GPS or other sensor
                           devices, connections to an internet access point, or as a means to use the
                           device as an internet access router for other devices such as laptops
                           (sometimes referred to as ‘tethering’). A fixed network interface, such as a
                           USB port, is frequently used for data exchange with a PC (music files,
                           photos, etc.) or for synchronizing mail and calendar data.
                               High end mobile phones typically need to be recharged every few days
                           under normal usage, and more often with heavy usage. If the device power
                           lasts less than a day, the charging process becomes impractical because it
                           requires the owners to take a charger with them or have chargers at
                           multiple locations. Furthermore, process memory and storage on mobile
                           devices is limited – at least compared to PCs. Owners expect that
                           applications running on the device do not waste memory.

Figure 6-1        Mobile
devices used during the
CoSphere trial: the HTC
Prophet (left) and the
HTC Wizard 200 (right)




                6.1.3 Balancing accuracy and usability
                           Comparing the implications of measuring network resource visibility in an
                           accurate way and the implications of having a trial device that must be
                           practical for the participants, we observe a number of conflicts and indicate
      TRIAL DESCRIPTION                                                            89



      how to deal with these conflicts. For accurate scanning we prefer a device
      which we can fully control, i.e., have access to the full hardware
      specifications and the source code of the operating system. The kinds of
      devices participants are used to, however, are off-the-shelf products that are
      not fully open. At the time of the definition phase of the trial (end 2006 /
      beginning 2007), the majority of high end devices had one of a few
      operating systems installed: Symbian, Microsoft Windows Mobile, and
      RIM’s Blackberry OS. Only a few of them – almost all Windows Mobile
      devices – combined the three wireless network interfaces in a single device.
      This was an important reason for us to select Windows Mobile as the
      platform for the NAL software. It was also the reason we used Windows
      Mobile for the trial. We chose two off-the-shelve devices, the HTC Wizard
      200 (also branded as the Qtek 9100, T-Mobile MDA, etc.) and the HTC
      Prophet (also known as the Qtek S200, i-mate JAMin, etc.) (see Figure 6-1).
      The drawback is that it is harder to control the network interfaces at a fine
      grained level. We were, for instance, not able to get a list of all nearby
      cellular base stations with these HTC devices, but only could get
      information about the currently associated base station, even though the
      information about other base stations is (partly, and perhaps not always up
      to date) available within the driver or the hardware.
          Scanning available network resources can be costly in terms of power
      consumption, especially for 802.11, so a high scan frequency may result in
      the need to charge the device more often than once a day, which is highly
      demanding for the participant. We therefore tuned the scanning frequency
      for each interface in such a way that under normal circumstances the device
      battery lasts at least one day. In that way, a participant can charge the device
      during the night. We found that activating the 802.11 interface for 1
      minute every 10 minutes, and scan for nearby Bluetooth nodes every 5
      minutes, is acceptable in terms of power usage. Another reason to not scan
      continuously is the fact that participants use the network interfaces for their
      regular activities.

6.1.4 Trial software
      The software platform used for executing the SocioXensor/Cosphere study
      consists of a number of cooperating components. The NAL server
      described in Chapter 4 provided the information about changes in the
      available network resources. A battery level component kept track of the
      remaining battery power and a logger component is responsible for storing
      the collected data in log files on a storage card inserted in the participant’s
      device. A graphical user interface (GUI) component conducted short
      surveys on the activity and interruptability of the participant. Finally, a
      monitor executable was responsible for starting some of the components,
90   CHAPTER 6                                            NETWORK VISIBILITY DATA



     periodically activating the 802.11 interface and keeping the device in the
     right power state. We do not further discuss the survey software and survey
     activities here, as it had very little influence on the collection of the network
     resource visibility data: only in case the participant had the 802.11 interface
     activated by default, extra information about nearby 802.11 access points
     was collected during the time – usually around 1 minute – that a survey
     took place. A maximum of 10 surveys per day were conducted during one
     or two weeks (depending on the participant). More information about the
     SocioXensor results can be found in [124].
         The NAL server used existing NAL modules for cellular, 802.11 and
     Bluetooth monitoring, as well as IP configuration notifications. The cellular
     module reflected changes in the currently used cell by means of
     notifications. It could not provide information about in-range nearby cells,
     but could indicate operator names of available cellular networks. Operator
     names were scanned every 5 minutes; cell id notifications were
     asynchronous, i.e., they were generated at the moment of change.
         To run a successful experiment, the NAL software needed several
     extensions. For 802.11 logging, the 802.11 network interface had to be
     occasionally activated after which the Windows Mobile Wireless Zero
     Configuration (WZC) started scanning for available networks and initiated
     802.11 associations according to the default wireless LAN preferences of
     the user. Taking into account its power consumption, the 802.11 interface
     was active for 1 minute every 10 minutes. Within that minute, the NAL
     generated events reflecting the scanning results and possible associations.
     The NAL Bluetooth module inquired for in-range nodes every 5 minutes.
     The Bluetooth interface was forced to stay into the discoverable mode, so
     that the participants detected other participants when nearby.
         A difficult part of the platform implementation was the management of
     the overall power state transitions. When the user pushed the power button
     to shut off the display, the devices we used for the trial went into suspend
     mode. In this state, the CPU did not execute instructions and the operating
     system only resumed after a hardware interrupt. In such a state, the
     measurement platform was neither able to process NAL notifications nor
     able to initiate the activation of a network interface at regular intervals. This
     meant that the platform had to make sure that the device would not enter
     the suspend mode. To further complicate the power management, the
     802.11 interface could only be activated when the device power state was
     fully on – which is the reason that the 802.11 interface activation and
     power state management were combined in the monitor component. Also,
     the cell id updates were only generated reliably if the power state stayed
     above a certain value. Although our software tackled all these issues
     successfully, the power management functionality was the most delicate
     part of the trial platform.
      TRIAL EXECUTION                                                            91



6.1.5 Collected data
      The CoSphere trial collected the following information on the personal
      mobile phones of the trial participants:
      – the cellular operator name, operator number, location area code (LAC),
         cell id (CID), and the received signal strength indication (RSSI) of the
         associated base station (monitored continuously, storing a new base
         station when the association changes)
      – the cellular operator name and operator number of all in-range cellular
         networks (scanned once every 5 minutes)
      – the service set identifier (SSID), the basic service set identifier (BSSID),
         the association state, and the received signal strength indication (RSSI)
         of all in range 802.11 access points (monitored during 1 minute, every
         10 minutes)
      – the Bluetooth device address (BD_ADDR) and device name of all in
         range Bluetooth nodes (scanned once every 5 minutes)
      – the IP address(es) and gateway router(s) (monitored continuously)
      – the remaining battery power percentage (every minute)

      We expected that the participants have habits that reoccur at different time
      scales. Given the above scanning intervals, we did not accurately capture the
      behavior that has a short period (i.e., in the order of minutes or less),
      because that would require more frequent scanning. In the trial, we aimed
      to capture those habits that appeared at a time scale in between a quarter of
      an hour and a day. We therefore wanted to collect data for at least two
      weeks per participant, so that patterns that reoccurred (almost) daily or
      more often could be identified.


6.2   Trial execution
      The CoSphere trial collected network resource visibility data for 12
      participants, in the time frame from February 1st until March 14th 2007.
      The participants were all Novay colleagues, some working mostly at the
      office and others more often traveling. Compared as a group with the
      Dutch general public, they can be characterized as researchers and
      knowledge workers with an above average interest in and usage of ICT
      technology. Before starting, the participants received instructions about the
      goal of the study and gave us permission to collect and use the trial data by
      filling out an informed consent form (see Appendix B).
           The measurement software was installed on the participant’s devices in
      the course of a few days. After the software installation on the device, the
      gathering of data started immediately, so that the start time of the
92                          CHAPTER 6                                         NETWORK VISIBILITY DATA



                            experiment was not exactly the same for all participants. Half of the
                            participants received a trial device they had not used before, and the other
                            half had the software installed on a device they already owned. After roughly
                            five weeks, we collected the data from the SD cards and uninstalled the
                            measurement platform.

Figure 6-2          Trial
duration per participant
in days (line indicates
duration average)




                            During the execution of the experiment, a number of problems occurred.
                            One participant stopped after 14 days due to software stability problems.
                            This participant used a device with a different operating system version.
                            Another three participants did not log network resource information during
                            the first two weeks of the experiment due to a bug triggered on non-English
                            language devices. This was one reason to ask the participants to stay in the
                            trial one additional week, extending the trial from the planned 4 weeks to
                            roughly 5 weeks (another reason was to get better survey data). Participant
                            8 experienced several clock resets to the extent that it was not possible to
                            restore the chronological order of the logged events.
                                Most participants experienced a device reboot every few days, due to an
                            intended device shutdown, reboot or due to a system crash, which mostly
                            interrupted the logging for up to a few minutes and occasionally for a longer
                            period of time. The time that the logging of data was discontinued
                            constituted 13.5% of the total trial time, which is comparable with the
                            percentage reported in a similar mobile phone experiment (14.7% in [33]).
                            Some of the participants reported that the device battery did not last a full
                            day without a recharge, especially when making phone calls more often or
                            longer than normal.
                                We have released the trial data as a public data set within the
                            CRAWDAD repository. It is available for download at [26].


                 6.3        Trace analysis and characterization
                            For 11 participants, not counting participant 8, the accumulated
                            experiment duration is 373 days with an average duration of 33 days per
                            participant (see Figure 6-2). The minimum duration is 14 days, which
                          TRACE ANALYSIS AND CHARACTERIZATION                                         93



                          allows us to identify patterns that occur multiple times during a two week
                          period, for each participant. This also means that events that occur regularly
                          with daily intervals will be present multiple times in the data set. As a
                          prerequisite for prediction, events must occur multiple times in the data
                          set: without event history, no input exists to predict upcoming events. The
                          collected data set therefore is suitable for events that occur multiple times
                          during 14 days including those events that occur regularly with a daily
                          interval. The basic numbers for the amount of global network entities (i.e.,
                          the entities observed by the complete group of participants) is shown in
                          Table 6-1.

Table 6-1 Basic global    Network entity                         Unique entity count
network entity count as   GSM cell                               4120
observed during the
CoSphere trial            operator                               18
                          802.11 access point                    3787
                          802.11 network                         1725
                          Bluetooth node                         6679


                          The number of unique cells and the number of different in-range operators
                          looks large at first impression. But, the participants cover all five active
                          operators in the Netherlands, Novay is close to the German border so that
                          the signal of German operators is picked up by participants that move close
                          to the border, and some participants have been abroad in Germany,
                          Belgium and the UK during the trial period. Also, the variation between
                          participants is quite large, indicating a big difference in traveling patterns.
                              The individual number of unique in-range 802.11 access points also
                          shows a large variation between participants, although a correlation does
                          not look strong: for instance, participants 4 and 9 have observed a below
                          average number of access points and an above average number of cells.
                              A complete overview of the number of unique in-range network entities
                          per participant is provided in Figure 6-3. The upper horizontal line in every
                          subfigure indicates the average per participant, while the lower horizontal
                          line indicates the total number of unique entities – taken over all
                          participants – divided by the number of participants. The closer the two
                          lines, the less overlap in network entity visibility between participants. For
                          instance, the lines for the number of unique in-range operators are far
                          apart, indicating that there is a large overlap between participants in the
                          observed operators. The average number of operator networks seen by the
                          participants during the trial was almost 10, while the total number of
                          unique operator networks observed by the complete group of participants
                          was 18 (see Table 6-1), which results in 1.5 when divided by the total
                          number of participants (12). Obviously, this large overlap is caused by the
94                         CHAPTER 6                                     NETWORK VISIBILITY DATA



                           fact that operator networks cover large geographical areas and that the
                           participants live and work in roughly the same area.

Figure 6-3 Number of
unique in-range network
entities per participant
      TRACE ANALYSIS AND CHARACTERIZATION                                        95



      The lines for the unique in-range Bluetooth nodes are close to each other,
      which means that the overlap in observed Bluetooth nodes between
      participants is small. Note that the definition of an 802.11 network is based
      on the SSID string value: all access points with the same SSID are counted
      as being in one network. In practice, these access points may not actually
      form one network, but may coincidentally have the same name.

6.3.1 Individual mobility data
      To give an impression of the mobility data in the CoSphere data set, we
      took a closer look at the data of one of the participants. The mobility of
      participant 2 within visited cellular networks can be expressed with a
      mobility graph indicating the transitions between associated base stations.
      The cellular interface is almost continuously associated to a base station and
      can never be associated with more than one. This means that, when moving,
      the device will be connected to multiple consecutive base stations. Figure 6-
      4 shows a subset of the base stations seen by participant 2 during the trial,
      and indicates the transition between base stations. Every node is a base
      station and an edge indicates the transition between two base stations.
          When a transition between two nodes occurs more frequently, the edge
      is drawn thicker. A frequently visited node has a darker color than a less
      often visited node. The graph clearly shows routes taken frequently and
      other routes taken less frequently. The layout of the graph is not related to
      the geographical location of the base stations: it is determined solely by the
      used graph visualization software.
          The visibility in time of 802.11 access points is provided by Figure 6-5.
      The x-axis is the time and the y-axis indicates the access point identifier.
      The mobile device may be in range of multiple access points at any given
      time, belonging to one or more 802.11 networks. However, it will only be
      associated - actively connected - to one access point at a given time. A dot
      indicates that the access point is in range and a cross represents an access
      point used for association. The access points belonging to the same network
      are clustered together on the y-axis (clusters not depicted). Furthermore,
      the ordering of the clusters depends on the number of times the mobile
      device associated with a network: a high identifier means frequent
      association.
          Similarly, Figure 6-6 shows the visibility of Bluetooth nodes for
      participant 2. The mobile device may be in range of multiple nodes at any
      given time. A node identifier is assigned based on the number of times the
      node is in range: the node most often in range has the highest identifier.
          Even though they only provide a global view, it is clear from both figures
      that there are distinct patterns in the visibility in time of the 802.11 and
96                         CHAPTER 6                                      NETWORK VISIBILITY DATA



                           Bluetooth entities. For example, some entities of the same technology are
                           visible in clusters.

Figure 6-4 Detail of the
cellular mobility graph
of participant 2
                           TRACE ANALYSIS AND CHARACTERIZATION   97




Figure 6-5    Visibility
(dots) and association
(crosses) of 802.11
access    points     as
observed by participant
2 during the CoSphere
trial
98                           CHAPTER 6   NETWORK VISIBILITY DATA




Figure 6-6      Visibility
(dots) of Bluetooth
nodes as observed by
participant 2 during the
CoSphere trial
      SUMMARY AND DISCUSSION                                                      99



      This is easily explained by the fact that entities that are close to each other
      are often detected at the same time or within a short time period. The
      clustering also takes place between technologies: the visibility of frequently
      associated 802.11 access points at the top of Figure 6-5 coincides with the
      frequently in-range Bluetooth nodes at the top of Figure 6-6. Our method
      for the prediction of visibility events (Chapter 7) is based, in part, on the
      time correlation between subsequent events.


6.4   Summary and discussion
      We have collected data on network resource availability in a real user
      experiment – the CoSphere trial – covering three different wireless
      technologies. As far as we know, no other public data sets exist that unite
      the information from these three common mobile device interfaces for a
      prolonged period of time. This data serves as input for the evaluation of our
      network resource prediction method introduced in the next chapter. We
      expect that the duration of the experiment, slightly more than one month
      per participant on average, allows us to discern patterns in the resource
      visibility of individual participants that reoccur multiple times with a daily
      period or less. The frequency of scanning of the wireless interfaces,
      however, does not allow for capturing very short term patterns of up to a
      few minutes. The definition of the experiment is such that it provides a
      balance between the accuracy of the data and the unobtrusiveness with
      which the data is gathered.

      Although the purpose of the trial was to obtain data from multiple network
      interfaces and use this data for the evaluation of network event prediction,
      the experiment can also be considered an additional validation of the
      implementation of the abstraction layer presented in Chapter 5. The
      CoSphere NAL was the central component in the trial software and ran for
      considerable time on the devices of 12 persons (on average one month per
      participant), notifying the visibility of many different network entities. As a
      whole, the trial software caused occasional crashes of the trial devices of the
      participants (more frequently for one participant), but this could be mainly
      attributed to the power management functionality, not to the NAL server.
      Therefore, the trial shows that the abstraction and notification mechanism
      implemented by the NAL works in real-user environments.

      One aspect that struck us while analyzing the trial data was the large
      number of network entities that participants observed in their daily lives.
      The proliferation of wireless network technology has resulted in multiple
      visible entities at many visited locations. Also, it is interesting to see the
100   CHAPTER 6                                        NETWORK VISIBILITY DATA



      dynamics of network visibility at different time scales and at different
      displacement scales: distinct patterns already appear when looking at the
      overview figures in Section 6.3.1.
          This rich view on the environment of a person can be used for more
      than network resource usage and prediction, because entities often mark a
      geographical location – when they are stationary – or are associated with
      the closeness of other persons. Data about the contacts between people can,
      for instance, be used to find dynamics in social networks [49]. We expect
      that with the maturing of personal mobile devices and their increasing
      capabilities to observe the owners environment with a rich set of sensors,
      large amounts of data will be generated that can be used to better adapt
      application behavior to the circumstances of the user.

      Obviously, the set of trial participants and their environments are not
      representative for the population of their region, let alone the world
      population as a whole. It is likely that the participants are inclined to
      surround themselves with more technology than the average person in their
      area, which may influence the number of wireless networks in-range.
      Furthermore, on a global scale there are big differences in the level of
      wireless technology penetration. So, it is necessary that any conclusions
      drawn from the CoSphere data set – such as those in Chapter 8 – must
      consider that the participants do not represent a large population.
                                                                      Chapter

                                                                                7
7. Event Prediction
   This chapter focuses on a method to predict the visibility in time of wireless
   network entities as they are observed from the perspective of a personal
   mobile device. Knowing when a network will get in range, or knowing when
   a network will be out of range, is important information for various data
   communication applications. A data synchronization job, for instance, may
   require uninterrupted connectivity to synchronize local data with data at a
   remote location, in which case it benefits from an accurate estimate on how
   long a candidate network remains visible – and therefore staying available to
   carry the synchronization data traffic.
       The approach taken here relies on the continuously updated
   information describing the visibility over time of network entities as seen on
   the wireless interfaces of a personal mobile device. When examining this
   stream of information, the patterns in the visibility of a network entity
   correspond with the day-to-day patterns in mobility of the owner of the
   device, for those network entities that are stationary. At any time, multiple
   network entities may be visible, and often entities are visible in a certain
   order, reflecting, for instance, the traveling from home to work or vice
   versa. We can therefore expect that a time correlation exists between the
   visibility of network entities seen in-order, and the fact that the visibility of
   one such entity may be used to predict the visibility of another.
       Although we use examples and synthetic data sets in this chapter that
   stay close to the problem of predicting network visibility, we describe our
   method in generic terms so that it may be applied to other prediction
   problems as well. In generic terms, we want to predict in time the next
   occurrence of an event of interest in a stream consisting of multiple reoccurring events.
   This stream can be thought of as comprised of a number of sequences equal
   to the number of different events, with every sequence marking the times at
   which the particular event occurs. The moment of obtaining visibility and
   the moment of losing visibility of a particular network entity each
   correspond with a separate event. Therefore, the number of different events
102   CHAPTER 7                                                EVENT PREDICTION



      in the stream is twice the number of different network entities. As we will
      see, the proposed method requires the stream to be periodic and the events
      in the stream to be relatively sparse to assure tractability.
          The focus of this chapter is on a method for event prediction that can be
      applied to the prediction of network entity visibility. The link with the
      NRM (Chapter 3) and NAL (Chapter 4) is that the NAL generates the data
      about network visibility, in a format dictated by the NRM, which may serve
      as input for the prediction method. This dissertation, however, does not
      provide an explicit mapping from NRM types and instances to events,
      although we realize that such mapping must exist to integrate the prediction
      information with the NRM and NAL. We consider this a topic for future
      research.
          To predict an event taking place in the future, we may use different
      models. A prediction may be based on estimating the probability of the
      occurrence of an event at a point in time relative to the beginning of the
      current period in the stream, assuming that the period duration is known.
      Or, it may be based on estimating the probability of the occurrence of the
      event relative in time to the previous occurrence of this event. The main
      focus of this chapter, however, is on estimating the probability of the time
      of the occurrence of a future event of interest given the previous time of
      occurrence of any of the defined events (including the event of interest
      itself). Now, as there may be more than one conditional previous event,
      each predicting the event of interest, a part of the method consists of
      selecting the best estimator.
          A common approach to predicting events in a system is to associate
      events with system states and then model the state transitions with a Markov
      model. This approach has a number of drawbacks when predicting network
      visibility:
      1. It may be hard to define states for a stream with different events,
          especially when the number of events is large and keeps growing, and
          when they may occur at the same time. Various data clustering
          techniques may help to extract stream states, although these techniques
          must be applied with care (see [36]).
      2. Furthermore, we are interested in the future time that another state is
          entered for the first time after the current state, which is a classical
          Markovian problem, known as the first passage time. It is in general
          difficult to solve analytically, even for Markov models with time-
          homogeneous state transitions, and requires exponential time to
          compute recursively (see [61], pp. 25) for discrete time models.
      The approach presented here does not require the definition of system
      states and needs polynomial computing time, but lacks the appealing
      simplicity of Markov models.
                       DEFINITIONS AND APPROACH                                                         103



                           The contributions of this chapter are the following. It provides a novel
                       method to predict the time of the next occurrence of an event of interest
                       given a stream consisting of multiple reoccurring events, including the event
                       of interest itself. It formulates a number of different strategies to select
                       amongst available predictors in the method, which can be evaluated later
                       using real data. Furthermore, it provides insight into the prediction
                       evolution in case of a growing data set, using synthetic data.
                           This chapter is organized as follows. Section 7.1 introduces the
                       definitions and the outline of our approach. Section 7.2 provides an overview
                       of kernel density estimation and its applicability to our problem, and Section
                       7.3 does the same for kernel conditional density estimation. Section 7.4
                       introduces strategies for best predictor selection, followed by Section 7.5
                       discussing the evolution of prediction strategy performance. Section 7.6
                       finally discusses the computational complexity of our proposed strategies.
                       Parts of this chapter are based on [92] and [93].


                7.1    Definitions and approach
                       Consider a process that monitors entities that are part of a system or
                       environment. An entity has one or more attributes, each with a dynamic
                       attribute value. The process receives a sequence of events associated with
                       these entity attributes. We use the term stream to refer to this sequence of
                       events.
                           An example is a network resource monitor on a mobile device, such as
                       the NAL (Chapter 4), that scans for available wireless network entities such
                       as cellular base stations, WiFi access points, and Bluetooth nodes. The
                       visibility of a network entity is represented with one boolean attribute
                       where a value ‘true’ indicates being in range and a value ‘false’ indicates
                       being out of range. An event is generated when the attribute value changes
                       from ‘true’ to ‘false’ (get out of range) and another event is generated when
                       the attribute value changes from ‘false’ to ‘true’ (get in-range).
Definition 7-1 Event   When observing a system consisting of entities whose properties are described with
                       one or more attributes, the occurrence of an event zi marks a specific change or a
                       specific temporal feature in the value of such an attribute.

                       We do not specify the value of an attribute, as the approach described here
                       exclusively deals with events derived from attribute values, not the attribute
                       values themselves. An attribute can be discrete, such as in the example
                       above, or it may be continuous. An arbitrary number of events may be
                       defined for each attribute. In the continuous case, for example, different
                       events may be generated at the moment of crossing, in upward or
104                        CHAPTER 7                                                                   EVENT PREDICTION



                           downward direction, a number of threshold values. A temporal feature of
                           an attribute is, for instance, the duration of a continuous attribute staying
                           below a specific threshold value.
Definition 7-2   Set of    Given a set of k attributes, the set of events is defined as z={z1, z2, …, zl} with
events
                           l≥k .

Definition 7-3     Time    For every event zi∈ z, the time sequence of past event occurrences, given the
sequence     of     past
occurrences of an event    present time tp, is defined as z i, p = {t i,1 , t i,2 ,..., t i,c i } , where i=1, 2, …,l, with
                           arbitrary distance between consecutive points in time so that ti,j+1 – ti,j > 0 and
                           all points in time ti,j < tp.

                           The index ci is the size of this time sequence and varies per event zi, because
                           some events occur more often than others. Note that the time points
                           between two time sequences are not necessarily synchronized (i.e., tx,j ≠
                           ty,j). In a similar way, we use the following definition.
Definition 7-4     Time    For every event zi∈ z, the time sequence of future event occurrences, given the
sequence of future
occurrences of an event    present time tp and its sequence of past occurrences zi,p, is defined as
                            z i, f = {t i, c i +1 , t i, c i +2 ,...} , where i=1, 2, …,l, with arbitrary distance between
                           consecutive points in time so that ti,j+1 > ti,j and all points in time ti,j > tp.

                           The time t i, c i denotes the most recent occurrence of event zi and time t i, c i +1
                           denotes the first occurrence of this event after the present time tp. To
                           simplify notation, we use index c instead of ci from now on, keeping in mind
                           that c is variable with i.
Definition 7-5 Stream of   The stream of past events is defined as Z p = {z1, p , z2, p ,..., z l , p } .
past events


Definition 7-6 Stream of   The stream of future events is defined as Z f = {z1, f , z2, f ,..., z l , f } .
future events

                           The stream can be regarded as a multidimensional or multivariate time
                           series with one dimension for every event, as depicted in Figure 7-1,
                           although it does not have the typical uniformly spaced time intervals used
                           often for time series analysis.
                               Our objective is to predict the first occurrence of an event after the
                           current time tp, so we are interested in the probabilities associated with the
                           future time that the first occurrence of event zi takes place, given the past
                           data on all other events. Therefore, we want to know
                                                                       tb
                                     P( ta < t i,c+1 < tb | Z p ) = ∫ f i,c+1 (t| Z p )dt                               (7-1)
                                                                      ta
                                DEFINITIONS AND APPROACH                                                                           105



                                for all tp < ta < tb ,where fi,c+1 is the probability density function of the time
                                of the next occurrence of event zi given the complete stream of past events.
                                Our task now is to estimate fi,c+1.

Figure 7-1 Subdivision
of stream in multiple
dimensions,        one
dimension for every
event




                                The outline of our approach is as follows. We assume no prior knowledge
                                of the relation in time between occurrences of different events, but use only
                                the historical information in Zp. Let zi be the event we want to predict and
                                let zj be any other event in z including zi itself (zj ∈ z). We are interested in
                                the waiting time Tw,i of event zi at the moment of the occurrence of an event
                                zj, which means that the most recent occurrence of zj coincides with the
                                present time, tj,c = tp. Let bp,i,j be all pairs {tj,y, ti,x} in Zp with tj.y < ti,x that
                                mark the first occurrence of zi after an occurrence of zj. In other words, bp,i,j
                                essentially holds the time values for all previous cases with the first
                                occurrence of event zi after zj. Now, extract bp,i,j from Zp and use the pairs to
                                estimate the probability density function of the waiting time. Note that the
                                waiting time is relative to the time of the occurrence of zj, whereas the {tj,y,
                                ti,x} pairs are relative to the time origin of the stream, as depicted in Figure
                                                                                 ˆ
                                7-2. The waiting time estimate is denoted as Tw , i and the associated estimated
                                                                    ˆ so that
                                probability density function is f w , i
                                                                                      tb
                                    P( ta < Tw , i < tb | bp, i, j , t j,c = t p ) = ∫ ˆw , i ( t| bp, i, j , t j,c = t p )dt ,
                                            ˆ                                            f                                        (7-2)
                                                                                        ta

                                for all tp < ta < tb.

Figure 7-2 Event times
tj,y and ti,x are relative to
the time origin of the
stream, while the waiting
time Tw,i is relative to the
time of event zj (tj,y)
                                A straightforward way to calculate ˆw , i is by only looking at the previous
                                                                      f
                                waiting times. Alternatively, when assuming that the stream is periodic, i.e.,
                                is showing dominant patterns in a cyclic manner, we can also calculate ˆw , i
                                                                                                          f
                                depending on the value of tj,y relative to the current period. In that case,
106                           CHAPTER 7                                                             EVENT PREDICTION


                               ˆ is a conditional probability density function and we need to translate
                                fw,i
                              the tj,y values in bp,i,j relative to their periods.
                                   For instance, continuing the example at the beginning of this section,
                              network entities are often visible in daily reoccurring patterns – the period
                              is 24 hours – and it may matter highly at which moment during this period
                              event zj occurs. When zj is the event of getting in range of a GSM cell on the
                              road in between home and work, the waiting time for getting in range of
                              the home WiFi network (zi) is considerably different when this cell is seen
                              in the morning than when it is seen in the late afternoon. A substantial part
                              of our method deals with estimating conditional probability densities. For
                              that part to apply, the stream must be periodic.
Definition 7-7 Waiting        The waiting time probability distribution of the occurrence of event zi ∈ z, given
time          probability
distribution                  the occurrence of event zj ∈ z, describes the probabilities of observing a waiting
                              time for event zi at the moment that zj occurs. This distribution is not time-
                              invariant (i.e., it is only valid at the moment that zj occurs).

                              When observing the stream, with every occurrence of event zj we have a
                              predictor for the next occurrence of zi.
Definition 7-8 Predictor      A predictor assigns probabilities to the future time of the next occurrence of an
                              event zi ∈ z given the occurrence of an event zj ∈ z.

                              A predictor is equivalent to the waiting time probability density
                               ˆ ( t | b , t = t ) . To simplify notation, we will also use f ( t | z ) for
                                fw,i           p, i , j j , c       p                                          w,i   j
                                f w , i ( t | bp, i, j , t j, c = t p ) . When repeating the density estimation for multiple
                              conditional events zj, we have a set of predictors for zi so that at a given time
                              multiple predictors may apply because their associated events have occurred
                              in the stream. In that case, we intend to select the best predictor for event
                              zi.

Figure 7-3 Increasing
predictor      availability
with time for an example
stream
                                                      ˆ
                                                      f w,1 (t | z2 )                                    ˆ
                                                                                                         f w,1 (t | z2 )


                                                                                                                    ˆ
                                                                                                                    f w,1 (t | z3 )




                              Figure 7-3 illustrates the dynamics in predictor availability in an example
                              stream. We keep track of all applicable predictors using a list. At the
                             DEFINITIONS AND APPROACH                                                                           107



                             occurrence of event zi, this list of predictors is cleared, because previous
                             predictors do not apply anymore. Note that by choosing zj = zi, there is
                             always at least one predictor available; predictor ˆw , i ( t | z i ) is then
                                                                                         f
                             immediately inserted in the cleared list. We will address density estimation
                             and conditional density estimation in Sections 7.2 and 7.3 and best predictor
                             selection in Section 7.4.
                                 With a predictor ˆw , i ( t | z j ) , we can determine the zi waiting time
                                                       f
                             probabilities at the time of the occurrence of event zj. Now, as long as event
                             zi has not occurred yet, we want to be able to predict its next occurrence
                             not only at the times that events such as zj occur, but rather at arbitrary
                             times when we require such a prediction – we can not assume that these
                             times coincide. Therefore, we are interested in the remaining waiting time or
                             the residual waiting time. This is illustrated in Figure 7-3. In this figure we
                             show the occurrence of 3 events z1, z2, and z3. At time tp, we want to predict
                             when z1 will occur the next time. The current time tp is in between the
                             event z2 and the event of interest z1 (left) and similarly, in between the
                             events z2 and z3 and the event of interest z1 (right).
Definition             7-9   The remaining waiting time probability distribution of the occurrence of event zi ∈
Remaining waiting time
probability distribution     z, given a previous occurrence of event zj ∈ z, describes the probabilities of
                             observing a waiting time for event zi at a moment after the occurrence of zj,
                             provided that zi has not occurred since the occurrence of zj.

                             The relation between the waiting time density fw,i and the remaining waiting
                             time density fr,i , with tp the present time, is given by
                                                                                     f w , i (t| bp, i, j , t j,c = t p )
                                  f r , i ( t| bp, i, j , t j,c < t p ) =       ∞                                              (7-3)
                                                                            ∫   tp
                                                                                     f w , i ( u| bp, i, j , t j,c = t p )du

                             It shows that the remaining waiting time can be derived from the waiting
                             time. This is a result known from, amongst others, reliability theory, where
                             the remaining waiting time is called the residual lifetime. Note that the
                             remaining waiting time can be the same as the waiting time, when the
                             density function has a ‘memoryless’ exponential shape. We will also use
                               f r , i (t | z j ) to denote f r , i ( t | bp, i, j , t j, c < t p ) .

                             The density estimation for a predictor may involve a considerable
                             computational cost when the stream history is large. This may force us to
                             use only a part of the history to reduce this cost. Moreover, exhaustive
                             computation of all l predictors in a stream may be intractable. In that case,
                             only the predictors that apply most frequently may be used, or the
108         CHAPTER 7                                                  EVENT PREDICTION



            predictors that are within a time window together with the event of
            interest. We discuss computational issues in Section 7.6.
                We want to apply this approach in on-line scenarios, i.e., in situations
            where the density estimation and best predictor selection take place while
            the stream data continues to be collected. We do assume that the process
            generating the data is not completely stationary, so we are interested in the
            convergence properties of the density estimates and the dynamics in the
            order of the best predictor list. In some situations, the number of
            dimensions in the stream grows with time. The on-line aspects of our
            approach are discussed in Section 7.5.


      7.2   Kernel density estimation
            Estimating the probability density function of a random variable from a set
            of observed values is important for a wide range of tasks. Two main
            approaches exist for density estimation: parametric and nonparametric. The
            parametric approach assumes that the probability density function has a
            known shape, and selects the parameters for this known shape such that it
            best matches with the data. This approach is useful when there are strong
            indications that the shape assumption is justified. The nonparametric
            approach does not make this assumption and aims to capture the
            distribution of values more directly from the data instead of matching a
            rigid shape to the data. We use the nonparametric approach here because
            we do not have strong hints on the shape of the waiting time distribution.
            Nonparametric density estimation has received considerable attention from
            statisticians [113][112][125]. We discuss histograms and kernel density
            estimation in this section

      7.2.1 Histogram
            The most simple nonparametric density estimation is a histogram. This well
            known method subdivides a value range in intervals or bins and counts the
            number of observations that fall into each bin. Although easy to construct, a
            histogram has the disadvantage of providing a discontinuous (not smooth)
            density function and a density shape that may depend strongly on the
            choice of the origin of the bins, even when using the same bin width.
                For the illustration of the density estimation methods discussed in this
            chapter, we introduce a synthetic example data set consisting of 15 visibility
            intervals of a single network entity, as observed on the mobile device of a
            person. Each interval has a begin time and an end time, expressed as time
            relative to the day of the begin time, and each interval has a duration of less
            than 24 hours. This entity is visible most of the time during the evening and
                             KERNEL DENSITY ESTIMATION                                               109



                             all of the time during the night, and can be thought of as a wireless home
                             network. We call this data set SynthSet-I (see Figure 7-4).
                                 We use this synthetic data set to estimate the end time te of an interval
                             on a 24 hour scale with a histogram. Using a bin width of 0.7 hours, the
                             histogram clearly shows moderate end time probability during the evening
                             and a peak probability in the morning around 8:00 hours. The shape of this
                             peak, however, depends highly on the choice of the bin origin, as shown in
                             Figure 7-5, which illustrates that histograms are less suitable for precise
                             density estimation.

Figure 7-4       Synthetic
data                   set
SynthSet-I
consisting        of   15
visibility intervals




Figure 7-5 Shift in bin
origin of 0.2 hours
results in a significant
histogram shape change
for the SynthSet-
I end times, using a bin
width of 0.7 hours
110                           CHAPTER 7                                                  EVENT PREDICTION



                  7.2.2 Kernel density estimation basics
                              Another well known method for nonparametric density estimation – the
                              one we use for our event prediction – is kernel density estimation (KDE). We
                              give a short overview of kernel density estimation in this section because it
                              is one of the basic tools we use for on-line event prediction in a multi-
                              dimensional event stream. For a more elaborate discussion on kernel
                              density estimation, see [113] and [46].
                                  Consider a sample generated by observing a single random variable.
                              From this data set, construct a set of functions, one for each observation, so
                              that the sum of all functions in this set defines the probability density
                              estimation for the variable. Each function is essentially weighing the
                              contribution of a single observation to the overall density. Such a function is
                              called a kernel function, often notated as K, and has the following property
                                                      ∞
                                                  ∫   −∞
                                                           K ( x )dx =1 ,                              (7-4)

                              so that a kernel function is a probability density function itself. A kernel
                              function typically is symmetric and smooth, resulting in a smooth overall
                              density function. Common shapes for K are Gaussian, Epanechnikov [35]
                              and triangular.

Figure 7-6 Construction
of a density estimate
(continuous line) by
summation over a set of
weighted           Gaussian
kernels (dashed lines),
each associated with an
observation (marked on
the       x-axis).     The
smoothing parameter h
is set to 0.5.
                              Figure 7-6 shows the construction of a density function from the kernel
                              functions associated with individual observations, using a Gaussian kernel.
                              The probability density f(x) is estimated from a data set {xi} by

                                             ˆ ( x) = 1
                                                           n
                                                              x−x
                                             fh         ∑ K( h i ) ,
                                                      nh i =1
                                                                                                       (7-5)

                              where n is the number of values in the data set and h is the smoothing
                              parameter, also called the window width or bandwidth.
                              The above equation has two parameters to choose: the kernel and the
                              smoothing parameter. As illustrated in [113], the kernel shape has
                              remarkable little influence on the approximation performance and
      KERNEL DENSITY ESTIMATION                                                  111



      therefore may be chosen based on other criteria such as the computational
      cost. Unless specified otherwise, we use the Gaussian kernel given by
                       x − xi      1 −(( x − x i ) / h )2 / 2
                  K(          )=      e                       .                 (7-6)
                         h       h 2π
      The smoothing parameter, in contrast, has a large impact on the
      performance of the estimator and therefore must be selected with care. It
      determines the width of the kernel which delivers a highly smooth density
      for large values and a less smooth density for low values. With a large data
      set, the optimal smoothing parameter is expected to become small.

7.2.3 Optimal smoothing parameter
         A widely used measure to express the closeness of the estimator ˆh to    f
      the true density f is the mean integrated square error (MISE) [110], defined as
                                     ∞
              MISE( ˆh ) = E( ∫ { ˆh ( x ) − f ( x )}2 dx ) ,
                    f             f                                             (7-7)
                                    −∞

      where MISE depends on the true function f ( x ) , the estimator ˆh ( x ) and
                                                                             f
      on the random sample used to construct the estimate. This measure is used
      to show that the kernel shape has relatively little influence on the estimation
      error. It can not be calculated, however, unless we know the true density,
      which is generally not the case (also not here).
          Now, trying to use the observations themselves seems an appropriate
      step for determining the optimal smoothing parameter. A widely studied
      form of this data-driven smoothing is the method of cross-validation. One
      well known approach, based on MISE as a measure, is least-squares cross-
      validation. Asymptotically, for a large data set, least-squares cross-validation
      provides the optimal smoothing parameter h that minimizes the integrated
      square error.
          Another frequently used, elegant method for determining the optimal
      smoothing parameter is called likelihood cross-validation. This method is based
      on the idea of using the likelihood of the parameter values of a statistical
      model or hypothesis given the data, to serve as a measure for comparison
      with other values of the parameters; then the values that deliver the
      maximum likelihood provide the best fit. The principle of maximum
      likelihood has applications in a wide range of domains.
          Suppose we have a density estimate ˆh for a random variable and a set
                                                   f
      of observations {xi}. The likelihood of this sample depends on h and is
      given by ∏ i ˆh ( x i ) . The estimate itself, however, also requires a sample,
                      f
      and usually we do not have multiple sets of observations. This problem can
      be solved by using the same set as input to the density estimate and as input
      to calculate the likelihood. Applying the likelihood cross-validation method
112   CHAPTER 7                                                     EVENT PREDICTION



      to find the optimal smoothing parameter now consists of the following
      steps. First, determine the likelihood of each observation in the data set
      with a density estimate that uses all (n-1) other observations. This measures
      how well an independent observation matches with an estimate based on
      (n-1) other observations, repeated for all observations in the sample
      because no single observation has more relevance than another. Second,
      calculate the logarithm of the likelihood of the entire data set as the sum of
      the logarithm of the likelihoods of each observation. Using the logarithm of
      the likelihood here is more convenient than the likelihood, because the
      likelihood tends to become very small, being a product rather than a sum.
      The normalized log likelihood of the data set is then
                               1 n
                     L( h) =    ∑ log( ˆ− i, h ( x i )) ,
                               n i=1
                                       f                                           (7-8)

      where ˆ− i, h denotes the leave-one-out kernel density estimate with
                f
      smoothing parameter h using all observations except observation i. The
      thirds step consists of using L to compare different values for h: the h value
      that provides the maximum log likelihood value is optimal.

      Contrary to the least-squares cross-validation, the likelihood cross-
      validation is not directly connected with the MISE performance measure. It
      is, however, linked to the Kullback-Leibler divergence DKL, such that the
      optimal choice for the smoothing parameter h minimizes DKL. The
      Kullback-Leibler divergence is a fundamental result from information
      theory and expresses the information difference between two probability
      distributions. For two probability distributions p and q, it is given by
                                     ∞                p( x )
                 DKL ( p|| q) = ∫        p( x ) log          dx ,                  (7-9)
                                    −∞                q( x )
      where DKL(p||q)≥0, with equality only if p = q. So, when two probability
      distributions become more alike, their DKL is getting closer to zero. For the
      likelihood cross-validation, the optimal smoothing parameter brings
       DKL ( f || ˆh ) closest to zero and therefore delivers a density estimate that
                   f
      is closest to the real density.
          Kernel densities based on likelihood cross-validation have a number of
      disadvantages. A density estimate may become oversmooth in case the data
      set contains an outlier value, especially for kernel functions with finite
      support. The likelihood of an outlier xi calculated with ˆ− i, h ( x i ) may easily
                                                                  f
      become 0, and therefore result in L(h) = -∞, unless h is sufficiently
      increased. Maximizing the likelihood therefore obtains a smoothing
      parameter that is large enough to bridge the gaps between data points, even
      if some of the gaps are disproportionately large. Related to this, and of a
KERNEL DENSITY ESTIMATION                                                 113



more fundamental theoretical concern, are the inconsistent estimates of the
density in case of n→∞: the expected value for h would then go to 0. For
many real distributions with a tail, however, this is not the case, because
also for large n there may be large gaps in between the data points in the
tail. Loosely speaking, using kernels with a ‘light tail’ will result in an
oversmooth density estimate for densities with a ‘long tail’. A possible
solution to this problem is the usage of a variable width kernel which
applies less smoothing if the local density of the data is high and vice versa
[12]. For an in-depth discussion on the relation between the Kullback-
Leibler divergence and the choice of the kernel in likelihood cross-
validation, see [45].
     Although its asymptotic properties are less favorable than those for the
least squares cross-validation, we use the likelihood cross-validation method
here, primarily because it has significant computational benefits and has a
known computational optimization for the case of kernel conditional
density estimates [48] – discussed in the next section. Furthermore, using
likelihood cross validation on bounded densities does result in consistent
estimates in the asymptotic case [21]. Our waiting time observations have a
natural limit because the total observation time is always bounded, which
means that even if the real distribution of waiting times has a long tail, the
values far in the tail will never be observed. Nevertheless, outliers may still
occur and therefore it is good to carefully consider the range of possible h
values.
     The method of kernel density estimation using likelihood cross-
validation can be applied on the data set SynthSet-I. Figure 7-7 shows the
estimated densities for the interval begin time tb (a) and the interval end
time te (b), expressed as time relative to a period of 24 hours, as well as the
estimated density of the duration of intervals (te - tb) in hours (c). The
kernel is Gaussian and the optimal value of the smoothing parameter is 0.7,
0.9 and 1.1 respectively, calculated by comparing h values in the range [0.1,
10.0] with a step size of 0.1. Figure 7-7b is the kernel density equivalent of
the end time histogram estimates in Figure 7-5.
     The duration density in Figure 7-7c shows a shortcoming of kernel
estimates for densities that are naturally bounded on one or both sides. It is
clear that the duration of an interval can not have a negative value, and
consequently, the density estimate should be 0 for (te - tb) < 0. The
estimate in Figure 7-7c, however, erroneously shows a positive density for
negative durations. This shortcoming normally occurs only when there are
observations close to the boundary and the smoothing parameter is not
sufficiently small. Although existing approaches tackle this problem
successfully, they come at a cost of, for instance, a more elaborate kernel or
the insertion of phantom data (e.g., [27]).
114                             CHAPTER 7                                                  EVENT PREDICTION




Figure 7-7 Probability
density estimates for tb
(a), te (b) and te-tb (c) for
the SynthSet-I
data set intervals, using
a       kernel       density
estimation       with       a
Gaussian kernel, and
corresponding optimal h
values of 0.7, 0.9, and
1.1




                                So far, our discussion has focused largely on determining the optimal
                                smoothing parameter. An open issue that remains is the difference between
                                a calculated estimate with an optimal smoothing parameter and the real
                                density, because both introduced metrics that could be used to determine
                                this difference, MISE and DKL, depend on the real density. Unfortunately,
                                there is little theoretical work on computing confidence bands using only
                                the available observations, so instead of focusing on the difference between
                                the real and the estimate density, our attention goes to formulating multiple
                                models and then select the best model using its likelihood.


                   7.3          Kernel conditional density estimation
                                As explained in the outline of our approach on predicting events in a
                                stream, we are interested in the waiting time distribution for an event given
                                the occurrence of another event. To estimate the waiting time density in a
                                nonparametric fashion, we therefore need the conditional variant of kernel
                                density estimation, called kernel conditional density estimation (KCDE). We
                                discuss kernel conditional density estimation in this section, because this
                                method is the foundation for the prediction model ˆw , i ( t | z j ) . Although
                                                                                          f
                                the body of work covering the theory on conditional estimates is much
                                smaller than regular kernel densities, and only recent advances have
                                provided an outlook on efficient computational approaches, it is now well
                                enough established to be used here as a tool.
                                    To a large extent, the mechanisms found in KDE are also used for
                                KCDE. The conditional density is estimated with a double kernel, so that
                                for a given set of observations {xi, yi} it is written as
KERNEL CONDITIONAL DENSITY ESTIMATION                                                115



                          n

                        ∑ K(( y − y ) / h )K(( x − x ) / h )
                                            i      1               i      2
    ˆ ( y | x) =
    f h1 h2              i =1
                                                                               ,   (7-10)
                                      n

                                    ∑ K(( x − x ) / h )
                                     i =1
                                                       i      2


where n is the number of value pairs in the data set and h1 and h2 are the
smoothing parameters for y respectively x. This form is known as the
Nadaraya-Watson estimator (see [112], pp. 220). Other more elaborate
forms exist with potentially better properties [30]: for simplicity, however,
we use this form here and in the remaining chapters. Now, finding the best
conditional density translates to selecting the optimal value of these two
parameters. As a method to do this, we again turn to likelihood cross-
validation which – for the conditional case – has the following normalized
log likelihood of the data set
                     1 n
    L( h1 , h2 ) =    ∑ log( ˆ− i, h1 , h2 ( y i | x i ) ˆ− i, h2 ( x i )) ,
                     n i=1
                             f                           f                         (7-11)

with ˆ− i, h1 , h2 the leave-one-out kernel conditional density estimate with
        f
smoothing parameters h1 and h2 using all observations except observation i,
and ˆ− i, h2 the regular leave-on-out kernel density estimate using smoothing
      f
parameter h2 (Equation 7-8). It is based on the probability P(xiyi) of the
combined occurrence of the two events.
    When applying this equation to the data set SynthSet-I, the optimal
parameter values are h1 = 0.8 and h2 = 0.7, resulting in a conditional
density as depicted in Figure 7-8 – in a three dimensional form and a
contour form. These plots clearly show that the shape of the interval end
time event density varies considerably given different begin times and
therefore offers more information than can be extracted from the
accumulated density in Figure 7-7b. The density is estimated using a
conditional begin time value relative to a 24 hour period in the input
stream.
    Note that the conditional density at the left-hand side is not the same as
the density at the right-hand side of the plots in Figure 7-8 – when
wrapping the plots around in the horizontal direction we would expect a
smooth period boundary transition. This anomaly happens because we map
all observations to a single period without compensating for the kernel
bandwidth looking beyond the boundaries of this period. By mirroring the
data set to period -1 and period +1, however, at least for those
observations that are within the bandwidth, we obtain a conditional density
estimate that can be wrapped around the conditional axis (not depicted).
116                            CHAPTER 7                                                EVENT PREDICTION




Figure 7-8 3D plot (top)
and      contour       plot
(bottom) of the kernel
conditional        density
estimation of f(te | tb) for
the SynthSet-I
data set intervals, using
a Gaussian kernel and
optimal parameters h1
= 0.8 and h2 = 0.7




                   7.4         Best predictor selection
                               In this section, we assume we have a set of simple models (or predictors) in
                               the form of probability densities that predict the time of a future
                               occurrence of an event we are interested in. These models estimate the
                               waiting time given the occurrence of a single preceding event in the input
                               stream. Using KCDE, we can construct a set of conditional density
                               estimates – one for every conditional preceding event – to predict this
                               event. Or, using straightforward KDE, we can generate density estimates for
       BEST PREDICTOR SELECTION                                                117



       the (unconditional) duration between the preceding event and the event of
       interest. This section discusses the dynamic selection over time of the best
       predictor from this set of available models. It introduces a number of
       strategies to dynamically select the best predictor (i.e., re-evaluating
       predictor performance during the interval between two occurrences of the
       event of interest), and defines metrics to compare these strategies.

7.4.1 Selection example
       In the previous sections, a number of different models were introduced that
       predict the end time of the intervals in the SynthSet-I data set. The
       model in Figure 7-7b simply shows the probability density of the occurrence
       of the interval end time on a 24 hour period. Assuming that intervals never
       have a duration longer than one day, we can estimate, at the moment the
       interval begins, when during the next 24 hours the interval will end –
       irrespective of the time value of the beginning. The model in Figure 7-7c
       uses the relative duration of an interval, again not depending on the begin
       time value. The model in Figure 7-8 predicts the end time value given – as a
       conditional – the begin time value on a 24 hour period.
           A fundamental statistical method to compare different models is to
       determine the likelihood of each model given available data and then select
       the model with the highest likelihood as the preferred model. When
       applying this method of maximum likelihood to our models, the data in
       SynthSet-I is used to calculate the density of the end time for every
       model, at the moment the interval begins: the likelihood of the data is then
       the product of all end time densities. To prevent working with extreme
       small values, however, most commonly the logarithm of the likelihood is
       used so that the log likelihood is the sum of the log of – in this case – the
       end time densities. Now, when calculating the log likelihood of the data set
       for the available models, the first model has a value of -27.1, the second a
       value of -37.5 and the third a value of -19.8. This suggests that the
       conditional density of the third model delivers the best prediction
       performance, although for a more careful evaluation we may need to use
       two separate data sets: one to estimate the densities and another to
       calculate the log likelihood. This example shows the use of the maximum
       likelihood method to select the best model out of a set of available models.

7.4.2 Selection strategies
       Considering the more general case, with multiple preceding events such as
       illustrated in Figure 7-3, a density estimation associated with a preceding
       event only applies when this preceding event has occurred. So, contrary to
       the example above, the available models are not always applicable; they can
       be considered only at the moment that the associating event occurs. As time
118   CHAPTER 7                                                                EVENT PREDICTION



      proceeds and more preceding events take place, the set of applicable
      models is therefore expected to grow. The question we want to address
      now is: given a set of applicable models, each associated with a single
      preceding event, which one of these models is the best predictor of the
      event of interest? Or, more precisely, without determining the multivariate
      remaining waiting time conditional density fr,i(t|zk, zl, zm, …) for event of
      interest zi with preceding events zk, zl, zm,…, which of the univariate
      estimated conditionals densities ˆr , i ( t | z k ) , ˆr , i (t | z l ) , ˆr , i (t | z m ) , … is
                                          f                 f                   f
      closest to the multivariate conditional density?

      Concurrent events
      From a theoretical perspective, it is possible to select between two models
      in the special case when one event zk always occurs in conjunction with
      another zl (but not necessarily vice versa). In that case, the univariate
       ˆ (t | z ) is the same as the multivariate ˆ ( t | z z ) so that it provides
        fr,i                                            fr,i
                 k                                            k l
      the desired model. The number of observations in the input stream of event
      zk is then always less than or equal the number of observations of event zl.
            This principle of single-sided concurrence can be extended to more than
      two events, requiring that if one event is observed, also all other events are
      observed. If events in an input stream do have many of these particular
      inter-relationships, this characteristic could be exploited for model
      selection.

      Lowest variance
      When considering an input stream reflecting human mobility, the time
      between two often observed events during the traveling of a person can be
      highly constant (i.e., can have a low variance). For example, the occurrence
      of an event observed on the way from work to home may be a good
      predictor for the arrival at home. So, the variance of a predictor may be a
      good indicator of the performance of that predictor – being closer to the
      multivariate conditional density than predictors with high variance. Also, in
      this case the most recent preceding events may be better predictors than
      those happened longer ago.
          Note, however, that both low variance and event recentness are not
      guaranteed to be good indicators for prediction performance: if they are, it is
      a heuristic that applies only to certain kinds of input streams. With single-
      sided concurrence, for instance, the least frequent event may predict with a
      higher variance than the most frequent event, even though it is the better
      predictor.

      Best mean likelihood
      In the above maximum likelihood example, the prediction of the end time
      of an interval is measured with a data set consisting of begin and end time
      BEST PREDICTOR SELECTION                                                       119



      pairs. For every data pair {tb, te}, it essentially answers the question: given
      this begin time tb, what is the probability of seeing the end time te for each
      of the models? This implies that we are only interested in predicting the
      end time at the moment an interval begins. In reality, however, we may
      want to predict the end time at several moments before the end of the
      interval, using the residual waiting time of Equation 7-3. Model performance
      may change considerably with increasing time in an interval, because the
      shape of the residual waiting time may change considerably, for instance by
      bringing forward features in the tail of the waiting time density that only
      appear when scaled up sufficiently. Now, translating to the general case
      with multiple preceding events, this adds another reason to selecting
      models dynamically as time proceeds.
          When calculating the performance of the models at different moments
      in time (i.e., not only at times when events occur), we can build up a
      history of model performance, for instance based on the likelihood. Then,
      for every fr,i(t | zj), we keep track of the mean likelihood, or, alternatively,
      the median likelihood.

7.4.3 Selection strategy summary
      Taking the above discussion in consideration, we define the following
      strategies for dynamic model selection:
      1. Self conditional. This strategy serves as a baseline for comparison with the
          other more sophisticated strategies. It uses the previous occurrence of
          the event of interest as a conditional event. As such, it uses the minimal
          amount of historical information available from the input stream.
      2. Last conditional. Using the most recent preceding event as a conditional
          event. Contrary to self conditional, this strategy uses different
          conditional events as time progresses and new events occur.
      3. Lowest variance. From the set of available predictors, select the one which
          has, at the time of evaluation, a residual waiting time with the lowest
          variance.
      4. Event concurrence. Filter out the predictors based on events that always
          concur with other preceding events. Use lowest variance selection on
          the reduced set of predictors.
      5. Best likelihood. For every fr,i(t | zj), keep track of the likelihood at previous
          predictor evaluation moments. Use the predictor which has the highest
          likelihood mean, or, alternatively, the highest median likelihood.

      These strategies are evaluated in the next chapter, using real-world traces.
      Some aspects of the prediction performance evolution of these strategies as
      the data set increases are discussed in the next section.
120         CHAPTER 7                                                  EVENT PREDICTION



      7.4.4 Metrics for prediction performance
            We now describe a number of metrics to measure the prediction
            performance.

            Maximum likelihood
            A common metric to compare the prediction performance of different
            models is, as discussed in the example above, the likelihood of a relevant
            data set for each model. This method has as practical disadvantage that for
            some observations the probability might be zero, which would result in a
            log likelihood with a negative infinite value. To deal with this problem, a
            minimum probability is used during likelihood calculation. Still, a few
            observations with zero probability may considerably influence the overall
            likelihood of a data set for a given model.

            Likelihood winner
            An alternative usage of the likelihood as a metric is to compare for every
            model the probability of each observation and mark the model with the
            highest probability as the winner. Then, the model with the highest winner
            fraction – the number of times the model is a winner divided by the total
            number of observation – is the best model. This metric does not provide a
            ‘weighted’ likelihood, but is less susceptible to zero probability influences.

            Mean squared error
            Another very common metric to determine the prediction performance of a
            model is the mean squared error (MSE) which is defined as the average of the
            square of the error. Here, the error is the difference in time between the
            expected occurrence time of the event of interest and the observed
            occurrence time. Using Equation 7-3, the expected occurrence time is given
            by
                                          ∞
                           E(Tr , i ) = ∫ t. f r , i (t| z j )dt                    (7-12)
                                          tp


            By taking the square over the error, outlier values of the expected error
            strongly influence the overall MSE value for a model. Also, if the residual
            waiting time is far in the future, the error is likely to be larger than with a
            short waiting time, which makes MSE more suitable to measure long term
            prediction performance than short time prediction performance: the long
            term errors overshadow the short term errors.

            Mean absolute percentage error
            As an alternative we can use the mean absolute percentage error (MAPE),
            defined as
      PREDICTION EVOLUTION                                                      121



                           1 n ˆi − x i
                                  x
                            ∑ x ,
                           n i =1
                                                                              (7-13)
                                    i

      which measures the relative error and therefore balances long and short
      term errors. Like MSE, it uses the difference in time between the expected
      occurrence time of the event of interest and the observed occurrence time.

7.4.5 Measurement points
      A final aspect to take into account when selecting the best predictor – next
      to the applied selection strategies and the used performance metric – is the
      distribution of points on the timeline where the prediction performance is
      measured. A straightforward approach is to measure at regular intervals,
      until the event of interest has occurred. If, however, prediction
      performance is more important when the residual waiting time is becoming
      shorter, i.e., we want our model to predict better if the event of interest is
      imminent, more measurement points close to the event of interest provides
      a stronger emphasis on short term prediction performance. In that case, a
      set of measurement points with increasing distance between them when
      counting backwards from the observed event time is more suitable. Ideally,
      the measurement points are determined by the application using the
      predictions.

7.4.6 Summary
      In summary, we have formulated five strategies for the dynamic selection of
      a model out of a set of models predicting an event of interest in a stream:
      ‘self conditional’, ‘last conditional’, ‘lowest variance’, ‘event concurrence’,
      and ‘best likelihood’. Each model describes the relation between a single
      event in the stream and the event of interest, either as a probability density
      of the relative duration between these events, or as a conditional probability
      density with the event time relative to the period of the stream.
      Additionally, we have identified four metrics to measure prediction
      performance: ‘maximum likelihood’, ‘likelihood winner’, MSE, and MAPE.
      And finally, we discussed two possibilities for setting points on the timeline
      to measure the performance: ‘regular intervals’, and ‘backward increasing
      distance’.


7.5   Prediction evolution
      Over time, as more and more history of the event stream is known, the
      density estimations and prediction performance changes. For a number of
122   CHAPTER 7                                                   EVENT PREDICTION



      reasons, knowledge about these changes is valuable. It determines how
      much stream history is necessary to let the density estimations converge to a
      point where additional history does not provide substantial better
      prediction. This helps to estimate how much storage of stream data is
      necessary and at which point data can be discarded. Furthermore, it
      provides an indication how much stream history is required to have a
      minimum level of prediction performance.
          In this section we show an example of prediction performance evolution
      on a synthetic data set. At the same time, it offers a comparison of three
      model selection strategies: ‘self conditional’, ‘last conditional’, and ‘lowest
      variance’, using maximum likelihood and likelihood winner metrics, with a
      backward increasing distance between measure points. The data set, called
      SynthSet-II and depicted in Figure 7-9, shows, in a simplified way, the
      visibility of networks as observed on the mobile device of a person over a
      period of 25 days, by aggregating the visibility of many networks into 4
      ‘main’ networks.
          The data set stream has 8 events, because the visibility of a network is
      represented with a begin event and an end event. The waiting time
      estimates are based on conditional densities, with the conditional event
      time represented on a periodicity scale of 24 hours, providing 8 predictors
      for every event of interest.
          We examine the prediction performance evolution over time for the 6
      events associated with the visibility of the ent1, ent2, and ent3 entities
      (ent4 events are left out due to infrequent occurrence). Every time that the
      event of interest occurs, the optimal smoothing parameters h1 and h2 are
      calculated for the density estimates of the waiting time, using likelihood
      cross-validation with a Gaussian kernel, and as input the event pairs
      available in the stream up to that point in time. Then, these parameter
      values are used for the measurement points defined up to the next
      occurrence of the event of interest. The measurement points start at 5
      minutes before the occurrence of the event, counting backwards with an
      exponential step size equal to 5n/60 hours, where n is the step count.
          The log likelihood of the different selection strategies is calculated over a
      maximum of 100 preceding measurement point densities, and then
      normalized to obtain a balanced plot. The prediction performance of the
      strategies for the 6 events of interest is depicted in Figure 7-10, showing
      slightly better performance for the ‘lowest variance’ strategy.
          The winner is determined by comparing the densities of the overall
      model defined by the different selection strategies at each measurement
      point. The winner fraction for a strategy is then calculated by taking the
      fraction of times this strategy has been the winner for all previous measure
      points. These results are shown in Figure 7-11. Here, the ‘lowest variance’
                              PREDICTION EVOLUTION                                                       123



                              strategy is in most cases the best. Also, as shown in this figure, in most cases
                              the fractions converge before the end of the data period.
                                  A possible way to measure the convergence of prediction is to determine
                              the evolution of the Kullback-Leibler divergence (Equation 7-9) for the
                              available waiting time density estimations. If DKL descends below a
                              predefined threshold, the density estimation has converged sufficiently.

Figure 7-9      Synthetic
data                  set
SynthSet-II
consisting       of     the
visibility of four network
entities     –      ent1
(dashed black), ent2
(solid gray), ent3
(solid      black),    and
ent4 (dashed gray),
observed by a single
person during a period
of 25 days
124                          CHAPTER 7   EVENT PREDICTION




Figure 7-10 Normalized
log likelihood evolution
for selection strategies
‘self        conditional’
(selfcond),          ‘last
conditional’ (lastcond),
and ‘lowest variance’
(lowestvar) using data
set SynthSet-II
PREDICTION EVOLUTION   125
126                          CHAPTER 7   EVENT PREDICTION




Figure 7-11        Winner
fraction evolution for
selection strategies ‘self
conditional’ (selfcond),
‘last         conditional’
(lastcond), and ‘lowest
variance’      (lowestvar)
using       data       set
SynthSet-II
PREDICTION EVOLUTION   127
128         CHAPTER 7                                                EVENT PREDICTION



      7.6   Analysis of computational complexity
            This section provides an analysis of the usage of computational resources of
            the model selection strategies introduced above, including the usage of the
            basic kernel density algorithms. Additionally, it discusses some aspects of
            the timing of calculations, to investigate the possibilities to spread the
            computational load over different machines. The elementary calculation
            considered here is a single computation of the kernel function K.

      7.6.1 Basic KDE and KCDE computational complexity
                 The straightforward calculation of the best smoothing parameters for
            KDE and KCDE has the following time cost. The computation of the KDE
            cross-validated likelihood for a single value of the smoothing parameter h
            (Equation 7-8) requires n (n – 1) kernel calculations with n the number of
            observations in the data set. Likewise, the KCDE cross-validated likelihood
            for a single {h1, h2} smoothing parameter set (Equation 7-11) requires n (2
            (n – 1) + (n – 1)) = 3n (n – 1) calculations. To find the optimal
            smoothing parameter(s), we need to repeat these calculations for a range of
            smoothing parameter values. When assuming m different smoothing
            parameter values, exhaustively determining the optimal value(s) therefore
            requires O(mn2) kernel calculations for KDE and O(m2n2) kernel calculations
            for KCDE.
                 This polynomial time means that with an increase of the number of
            observations in a data set or with an increase of parameter granularity, the
            cost of computation is going up considerably. Note, that the number of
            observations in a data set is not the same as the total number of events that
            have occurred in the stream: a data set is extracted from the stream to hold
            all information relevant for a model, such as a set of durations for KDE or a
            set of {conditional event, event of interest} pairs for KCDE. So, even when
            the stream grows large, the size of some data sets may still be limited. In
            case a data set is large, however, previous research on optimizing kernel
            density calculations fortunately has resulted in more efficient approaches.
            Gray and Moore [43] show several orders of magnitude improvement for
            KDE and the approach in [48] provides substantial improvements for
            KCDE. Also, the process of finding the best smoothing parameter(s) may be
            substantially accelerated with limited error when using a gradient descent
            method instead of an exhaustive method. This method consists of choosing
            a starting value in the one or two dimensional parameter space and then
            making a next step to a nearby parameter value that has a lower associated
            cross-validated likelihood – until a local minimum is reached. For the on-
            line re-calculation of the smoothing parameter(s), we can select the best
            parameter value(s) of the previous calculation as a starting point for the
      ANALYSIS OF COMPUTATIONAL COMPLEXITY                                       129



      gradient descent algorithm. In the case of converging parameter values, the
      old values are close to the new values, so that the gradient descent method
      very quickly finds the new optimal values. Given these possibilities for
      optimizing kernel density calculations, it is reasonable to assume that also
      for larger data sets, the computational load of the KDE and KCDE parts in
      our approach will be within practical limits; we will further investigate this
      statement in the next chapter (Chapter 8).

7.6.2 Smoothing parameter(s) re-calculation
      Now, depending on the choice of the model selection strategy, the number
      of different kinds of models (duration based or periodicity based), and the
      event of interest, it is necessary to repeat the best smoothing parameter
      calculation.
          Assuming a scenario where the event of interest is predicted by
      selecting, in the worst case, between all other events as conditional events,
      with conditional events expressed as values on a chosen periodicity of the
      stream, a total of l KCDE best smoothing parameter calculations must be
      performed. In case we do not know the event of interest up front, and we
      want to predict – worst case – any of the l events for this scenario, a total of
      l2 calculations must be performed. This is showing that the computational
      cost may depend considerably on the number of defined events.
          The re-calculation of the best smoothing parameter(s) is only relevant
      when new observations are added to the data set, i.e., when the stream
      grows, and the event of interest has reoccurred. In the time between two
      occurrences of the event of interest, the best smoothing parameters do not
      change and therefore do not need to be calculated every time we are
      interested in a prediction during this interval. Also, in case of highly
      converged densities with larger data sets, one or a few new observations of
      the event of interest will only marginally change the best smoothing
      parameter values. Therefore, the best smoothing parameter calculations are
      suitable for executing off line, on a periodic time scale.

7.6.3 Predictor selection
      The best predictor selection process has the following cost. For every
      preceding event available at the time a prediction is needed, the waiting
      time density must be scaled to obtain the residual waiting time, in
      accordance with Equation 7-3. This integration over the waiting time density
      is simply a succession of density calculations, using the pre-calculated best
      smoothing parameters. Every evaluation of the density function requires n
      kernel calculations for KDE and 2n for KCDE (Equation 7-5 and Equation 7-
      10). When the density function is smooth, a high integration accuracy is
      reached with relatively few density calculations, so we choose the
130         CHAPTER 7                                                    EVENT PREDICTION



            integration delta depending on the level of smoothing by setting it the h /
            10 for KDE and h1 / 10 for KCDE. When integrating to an infinite
            boundary, as is the case for Equation 7-3, we must find a suitable cutoff
            point after which no further points need to be calculated because their
            values are very close to zero. For a Gaussian kernel (Equation 7-6) and a
            positive infinite boundary, we have set this to the maximum value in the
            data set increased with 4 h (KDE) or 4 h1 (KCDE), as
                           2
             e −( 4 h / h ) / 2 = 3.35 ⋅10 −4 is sufficiently small. So, the number of density
            calculations depends on the smoothing parameter and the size of the
            smoothing parameter is usually smaller with larger n, which would result in
            a higher number of density calculations for a larger n. There is, however, an
            upper bound on the increase of density calculations due to a smaller
            smoothing parameter, because the smoothing parameter has a lower and
            upper bound. So, even though the number of density calculations depends
            on the smoothing parameter, the integral can be calculated in linear time.
                  When using the lowest variance strategy for best predictor selection, the
            variance of the residual waiting time density must be calculated. This
            involves determining the mean of the residual waiting time with a cost
            similar to integrating, followed by the calculation of the variance using this
            mean, also with a cost similar to integrating. The optimizations for the
            calculation of the integral – adapt the number of density calculation using
            the smoothing parameter and select a suitable cutoff point at the infinite
            boundaries – can also be applied to calculate the variance.

      7.6.4 Example calculation times
            Considering the previous paragraphs, it is clear that the step of calculating
            the optimal smoothing parameters is most expensive. To illustrate this cost,
            we have measured their calculation times for the strategy comparison in the
            previous section using SynthSet-II, determining the KCDE best values
            for all possible 8 conditional events for the 6 events of interest. The
            algorithm is implemented in the Python programming language [105] and
            was executed in the mainstream Python runtime environment, version
            2.5.1. The program was run on a laptop with Windows XP and a dual core
            Intel T5500 CPU with a speed of 1.66 GHz and with 2 GB RAM, in a
            single thread – using only one of the cores. We compare the calculation
            time of the standard KCDE algorithm that walks over the entire two
            dimensional parameter space with a step size of 0.1 and limits between [0.1
            , 10.0], with the gradient descent KCDE optimized algorithm. The gradient
            descent algorithm uses 5 different starting points for the first calculation
            and selects the best smoothing parameters from these five. All subsequent
            calculations select the previous best parameters as starting point.
                             ANALYSIS OF COMPUTATIONAL COMPLEXITY                                    131



                                 The results are depicted in Figure 7-12, showing the accumulated
                             calculation times for the best smoothing parameters for all conditional
                             events for an event of interest, as it changes when more data becomes
                             available. The standard algorithm (top) requires considerable calculation
                             time of up to 2000 seconds and has a clear polynomial shape for all entities.
                             The optimized algorithm (bottom) also requires more calculation time
                             when more data becomes available, although the shape is less pronounced,
                             and has more peaks for some of the entities. The highest peak for entity
                             ent3 between 300-350 hours can be explained by the fact that this entity is
                             skipped for the first time on day 11 (see Figure 7-9), which changes the
                             optimized parameters considerably and therefore requires the gradient
                             descent algorithm to make many more steps. Going to 600 hours, the
                             calculation time is around 0.2 seconds, which is a multiple order
                             improvement compared to the standard algorithm – corresponding with
                             the reduced number of steps taken in the parameter space.

Figure 7-12 Calculation
time of the KCDE
optimal parameters for
all conditional events for
a given entity from
synthetic     data     set
SynthSet-II,
executed      with     the
standard algorithm (top)
and the gradient descent
optimized       algorithm
(bottom)
132        CHAPTER 7                                                EVENT PREDICTION



               Using the gradient descent algorithms comes at a price, however,
           because in not all cases the optimal smoothing parameters are found. For
           the strategy comparison calculations on SynthSet-II, the optimized
           algorithm finds smoothing parameters that do not have the optimal
           likelihood in a fraction of 0.052 of the cases. When executing model
           comparison on the last 20% of the stream, i.e., when calculating smoothing
           parameters using 80% or more of the stream data, the fraction of deviation
           from the optimal likelihood is 0.025, showing that the optimized algorithm
           performs better with more data. This is a favorable property, because with
           more data we must rely on optimized algorithms to limit calculation times.

      7.6.5 Memory
           So far, this section has discussed computing time, not memory, because
           above operations require few memory resources. Some opportunities exist
           to exchange time for memory, so that we can calculate faster to the expense
           of more memory usage. This is the case for calculating the integral, mean,
           and variance based on the residual waiting time density. After calculation of
           the optimal smoothing parameters, the density function may be pre-
           calculated with a delta value depending on the level of smoothing. These
           pre-calculated density function points are then to be used for the
           subsequent steps.

      7.6.6 Summary
           Summarizing this section, we conclude that calculating the optimal
           smoothing parameters are most costly in terms of time – compared to the
           other operations of the various strategies. Applying the gradient descent
           optimization algorithms can speed up this calculation considerably,
           although it still is of O(n2) complexity. This is the reason that we can only
           use the method described in this chapter on data streams that have
           relatively sparse event occurrences.
                                                              Chapter

                                                                        8
8. Prediction Results
   In this chapter, we provide the results on predicting network entity visibility
   in data streams collected on the personal devices of real users. These
   streams represent the events associated with the visibility of heterogeneous
   network entities, i.e., entities such as access points and base stations as
   detected through the wireless interfaces available on the devices. The main
   objective of this chapter is to compare the different predictor selection
   strategies introduced in the previous chapter (Chapter 7), using real world
   data.
       We are interested in knowing the availability of current and future
   wireless networks for all wireless technologies on a personal device, because
   applications on personal devices have different network communication
   needs in different situations. Here, we focus on the prediction in time of
   network entities getting in range and getting out of range, using two data
   sets: the data collected during the CoSphere trial (Chapter 6) and the public
   data set from Rice University, described in [106]. The CoSphere data set
   was gathered with the middleware software implementing the CoSphere
   NAL (see Chapters 4 and 5). The Rice data set was generated in a similar
   experiment with almost the same duration and number of participants,
   gathering cellular and 802.11 visibility data at a higher scan rate than in the
   CoSphere trial. It does not, however, contain Bluetooth information.
   Another reason for using information from all network interfaces is to study
   whether events related to one network technology can be used as predictors
   for events of another technology.
       As discussed in the previous chapter, many parameters play a role in the
   calculation of the prediction of events and evaluation of the prediction
   performance. The kernel density estimation needs smoothing parameter
   boundaries and can be calculated with different (optimizing) algorithms.
   The data stream may be preprocessed in various ways. The measurement
   points used to calculate a prediction may be selected in many ways. It is
   clear that we can not exercise all parameters values in all combinations, and
134         CHAPTER 8                                                PREDICTION RESULTS



            therefore, we make choices on the settings of these parameters in the
            different parts of this chapter.
                The outline of the chapter is as follows. Section 8.1 presents the main
            results of the strategy comparison – based on cross validation – and
            provides a detailed description of the method and algorithm used to
            compare the prediction performance. It exercises all the strategies and
            metrics defined in the previous chapter. Section 8.2 shows the influence of
            using different sets of preceding events on the prediction performance. It
            addresses the question whether it is worthwhile in term of prediction
            performance to add more event data – including those events that occur
            infrequently. Section 8.3 discusses the influence of cross-technology
            information on the prediction performance, making a distinction between
            cellular, 802.11 and Bluetooth events. Section 8.4 shows the prediction
            performance of a number of strategies as it evolves over time; this is
            relevant for most real world scenarios. Section 8.5 describes an example
            application, using the prediction method to select suitable synchronization
            occasions. In the final Section 8.6, we provide a summary of the results of
            this chapter. Parts of this chapter are based on [92] and [93].


      8.1   Comparing strategies for predictor selection
            In this section, we determine which predictor selection strategy, as
            described in the previous chapter, delivers the best prediction performance
            for the visibility of network entities as observed over time by a single device.
            We have already defined a set of criteria to measure prediction performance
            and we also have defined two ways to determine measurement points on
            the timeline at which these criteria must be applied for individual events of
            interest (Section 7.4). When comparing strategies on a real-world data set,
            however, we are interested in the performance aggregated over all potential
            events of interest, not just one of them. As with the selection of
            measurement points, the selection of potential events of interest is
            application specific: some applications may need predictions for a highly
            selective set of network events that are best predicted with one strategy,
            while other applications require predictions for a different set of events that
            are best predicted with another strategy. Here, we determine the prediction
            performance based on broad sets of events of interest and broad sets of
            preceding events, providing a strategy comparison based on large portions
            of the data set. We vary the set sizes by working with different threshold
            values representing the minimum number of times an event has occurred
            during the time of the experiment. It is good, however, to keep in mind
            that this provides a generalized comparison of the strategies, and that
            application specific event sets may lead to different results.
                            COMPARING STRATEGIES FOR PREDICTOR SELECTION                                135



                 8.1.1 Single event prediction performance
                            In a real-world system, the calculation of the prediction performance for a
                            single event zi at a single measurement point tp, based on a selection of
                            possible preceding events, is determined by executing a number of steps.

Figure 8-1 First three
steps of the single event
occurrence prediction
performance calculation




                            The description of the steps is given below. Steps 1, 2 and 3 are illustrated
                            in Figure 8-1.
                            1. First, identify the preceding events that have occurred since the previous
                                occurrence of the event of interest zi (between the times ti,x-1 - tp).
                            2. Then, if not done already at a previous measurement point in between
                                ti,x-1 and ti,x, calculate the best smoothing parameters for the waiting time
                                probability density estimations ˆw , i ( t | z j ) for every preceding event
                                                                       f
                                zj.(see Definition 7-7). Per zj, there are two estimates: one KDE estimate
                                for the relative time between the two event times tj,y - ti,x (the relative
                                predictor, Equation 7-5), and one KCDE estimate for the period time of zi
                                expressed as time relative to the current period of zj, using the time of zj
                                on its own period as a conditional (the periodic predictor, Equation 7-10).
                            3. For all occurred preceding events, compute the relative and periodic
                                remaining waiting time estimates at time tp of the measurement point mp,
                                using their waiting time estimates (Equation 7-3).
                            4. For each strategy under consideration, select the best predictor
                                according to that strategy. For the strategies ‘lowest variance’, ‘event
                                concurrence’, and ‘best likelihood’, this requires additional
                                computation.
                            5. Per best predictor, calculate the performance using the set of defined
                                metrics. The metrics ‘maximum likelihood’ and ‘likelihood winner’ only
                                need one calculation of the estimated probability density function, but
136         CHAPTER 8                                                PREDICTION RESULTS



               metrics MSE and MAPE use the expected occurrence time of zi, by
               taking the integral as in Equation 7-12.

            In a real-world system, the smoothing parameter calculation in step 2 can
            only take into account the data seen so far in the stream, i.e., the data
            observed up to the point in time of the previous occurrence of the event of
            interest (at zi-1). Going over the stream in this way gives an indication of the
            prediction performance evolution in time: we investigate the performance
            evolution in Section 8.4. Now, however, we are interested in determining
            the best strategy using as much data of the whole stream as possible.
            Therefore, we do not restrict the data used for calculating smoothing
            parameters to be chronologically before the measurement point.

      8.1.2 Cross validation approach
            A common way to validate a model given a data set is to divide the available
            data into a subset used to build the model (the training set) and another
            subset used to measure the performance of this model (the validation set).
            To use the available data as much as possible, the whole data set is often
            broken up in many subsets, where each subset is used once to validate and
            the rest of the subsets are used to train. This cross validation approach (see
            [126], pp. 149) is essentially the same as the leave-one-out approach
            applied to finding the optimal smoothing parameters for KDE/KCDE
            (Equation 7-8 and Equation 7-11).
                To apply this cross validation approach to the prediction of a single
            event, we must subdivide the stream into parts. A logical subdivision is to
            treat the data for each time interval between two occurrences of this event
            as a subset, so that the number of subsets equals the number of event
            occurrences. It is not possible to further break up these subsets, because in
            that case the training set would contain event data about the exact event
            occurrence we want to predict. It is possible to use larger subsets, for
            instance by working with a fixed number of intervals – so called k-fold cross
            validation – smaller than the number of occurrences of the event of interest,
            but that wastes at least a part of the data. Additionally, using k-fold cross
            validation, we must be careful to not mix data for the same event
            occurrence between the training set and validation set. Therefore we choose
            to use the minimum size subsets, even though it is more expensive to
            compute. For step 2 in the above calculation, it means that we use all data
            in the stream that is not in the ti,x-1 and ti,x interval, to determine the best
            smoothing parameters (see Figure 8-2), resulting in a number of
            recalculations of these parameters less or equal to the number of times zi
            occurs. We are interested in the aggregated prediction results for the entire
                           COMPARING STRATEGIES FOR PREDICTOR SELECTION                            137



                           set of events of interest we are considering, so we repeat the above cross
                           validation for all zi and average the results.

Figure 8-2 Training set
and validation set for
two succeeding intervals
for event zi




                8.1.3 Measurement points
                           When using a regular distance scheme or a backward increasing distance
                           scheme for the determination of the measurement points in a
                           straightforward way, the number of measurement points increases with the
                           number of events of interest. To limit the necessary computing time, we
                           therefore use a fixed number of measurement points regardless of the
                           number of events of interest. We make sure, however, that these
                           measurement points have a distribution over the event intervals that match
                           with the straightforward application of the schemes. More specifically, in
                           case of a backward increasing scheme, the distribution of the time between
                           the measurement points and the to-be-predicted event of interest has a
                           decreasing shape (for instance, Pareto or exponential). We draw the
                           measurement points such that they have the same distribution as the
                           straightforward scheme, covering all events of interest.
                               For the remainder of this chapter – unless stated otherwise – we use a
                           statistical backward increasing distance scheme with an exponential
                           distribution equal to λe − λx , with λ = 1.5 , and we draw 2000
                           measurement points per participant. This may mean, especially for a larger
                           number of events of interest, that some event intervals do not have any
                           measurement points. The average time between the measurement point and
                           the to-be-predicted event is less than the average distribution value of 1 λ
                           hours (40 minutes), because there is bounded time between consecutive
                           occurrences of an event. Note that, as with the training sets and validation
138         CHAPTER 8                                                PREDICTION RESULTS



            sets, the measurement points are specific for a single event of interest, i.e.,
            they are not used to determine the prediction performance of all events of
            interest at that point in time.

      8.1.4 Strategy comparison algorithm
            Our evaluation method for the determination of the best prediction strategy
            can be summarized as follows. We calculate performance results per event
            of interest, using interval cross validation. The measurement points at which
            the calculations take place are distributed such that the distance between a
            measurement point and the next occurrence of the event of interest is
            backward exponential. We use a fixed number of measurement points per
            participant, and apply every predictor selection strategy at every
            measurement point and average their performance over all measurement
            points. Then these averaged results are used to compare the performance of
            a strategy, for every participant. Comparing the strategy performance for all
            participants provides an indication of the general performance of a strategy.
                We now provide a more detailed overview of the algorithm used to
            perform the strategy comparison. As input, we assume a stream containing
            all observed network events and their time stamps.

            Two step approach
            The comparison consists of two steps. First, for every measurement point,
            we compute a few basic properties for every available predictor at the time
            of that measurement point. These properties are the log likelihood, the
            remaining waiting time mean and the remaining waiting time variance, both
            for the relative and the periodic variant of the predictor. Second, we use
            those basic predictor properties to apply the predictor selection strategies
            and to calculate the performance of each strategy. We use a minimum log
            likelihood of -10.0 for the remainder of this chapter.

            First step
            The algorithm in Figure 8-3 shows the first step. It consists of a function
            called basicperf(), in Python-like pseudocode. This function takes three
            arguments: the stream of events, and two threshold values, evticount and
            evtccount. These threshold values mark the minimum number of
            occurrences that an event of interest respectively a preceding event must
            have occurred between the begin time and the end time of the stream to be
            considered in the performance evaluation. So, a value of 50 for evticount
            means: only those events of interest that have occurred 50 or more times in
            the stream are used for evaluation. And a value of 5 for evtccount means:
            only those preceding (or conditional) events that have occurred more than
            5 times in the stream are considered as predictors for the events of interest.
                            COMPARING STRATEGIES FOR PREDICTOR SELECTION                 139



                            ______________________________________________________
                            1 def basicperf(stream, evticount, evtccount):
                            2   evtilist = selectevents(stream, evticount)
Figure 8-3 First step of    3   evtclist = selectevents(stream, evtccount)
strategy     comparison     4
algorithm, in Python-like   5   # first calculate optimal KDE/KCDE smoothing parameters
pseudo code                 6   smoothingparams = {}
                            7   for evti in evtilist:
                            8     intervals = eventintervals(stream, evti)
                            9
                            10    for evtc in evtclist:
                            11      pairs = extractpairs(stream, evti, evtc)
                            12
                            13      for interval in intervals:
                            14        pairsxv = trainingpairs(interval, pairs)
                            15        h = bestparamkde(pairsxv)
                            16        h1, h2 = bestparamskcde(pairsxv)
                            17        smoothingparams[(evti, evtc, interval)] = (h, h1, h2)
                            18
                            19 # now calculate basic performance indicators
                            20 perf = {}
                            21 mps = generatemeasurementpoints(stream, evtilist)
                            22 for evti in evtilist:
                            23    perf[evti] = []
                            24    intervals = eventintervals(stream, evti)
                            25
                            26    for ival in intervals:
                            27      mpsinterval = mps[evti][ival]
                            28
                            29      for mp in mpsinterval:
                            30        evtcintervals = currentprecedingevents(stream,evti,mp)
                            31
                            32        mpresult = {}
                            33        mpresult['interval'] = ival
                            34        mpresult['measurementpoint'] = mp
                            35        mpresult['cresults'] = {}
                            36        perf[evti].append(mpresult)
                            37        for evtc in evtcintervals:
                            38          cresult = {}
                            39          mpresult['cresults'][evtc] = cresult
                            40          pairs = extractpairs(stream, evti, evtc)
                            41          pairsxv = trainingpairs(ival, pairs)
                            42          h, h1, h2 = smoothingparams[(evti, evtc, ival)]
                            43
                            44          # relative predictor
                            45          cresult['kdellh'] = kderwt(pairsxv, h, mp, ival)
                            46          cresult['kdemean'] = kdemean(pairsxv, h, mp)
                            47          cresult['kdevar'] = kdevariance(pairsxv, h, mp)
                            48
                            49          # periodic predictor
                            50          cresult['kcdellh']=kcderwt(pairsxv,h1,h2,mp,ival)
                            51          cresult['kcdemean'] = kcdemean(pairsxv,h1,h2,mp)
                            52          cresult['kcdevar'] = kcdevariance(pairsxv,h1,h2,mp)
                            53
                            54 return perf

                            ______________________________________________________
140   CHAPTER 8                                               PREDICTION RESULTS



      The count threshold values allow us to investigate the effects of using
      frequently occurring and less frequently occurring events on the overall
      prediction performance. As a return value, basicperf() provides a
      dictionary with a list of measurement point results per event of interest.
          After the selection of the events of interest and possible preceding
      events with selectevents() at lines 2 and 3, we calculate the optimal
      smoothing parameters, based on interval cross validation, for all possible zj-
      zi pairs (lines 6-17). The function trainingpairs() simply extracts all
      pairs that do not belong to the current interval. The KDE-based estimate is
      used for the prediction of the relative duration of the time between the
      current measurement point and the occurrence of the upcoming event of
      interest. The KCDE-based estimate takes into account – as the conditional
      variable – the time of the measurement point relative to its current 24 hour
      period (time of day). So, per preceding event, we have two predictors.
          Knowing the optimal smoothing parameters, we then execute the actual
      calculation of the basic performance properties. The complete, fixed size
      list of measurement points is obtained at line 21 using
      generatemeasurementpoints(), using the backward exponential
      distribution. The nested for loops at lines 26-52 basically calculate the log
      likelihood (kderwt() and kcderwt()), remaining waiting time mean
      (kdemean()) and kcdemean()) and variance (kdevariance()) and
      kcdevariance()) for all predictors available at all measurement points,
      using the cached optimal smoothing parameters.

      Second step
      The second step of the strategy comparison, which we do not show here in
      pseudocode, takes the result from the first step as input. It consists of
      preprocessing the basic predictor properties – necessary for a number of
      strategies – followed by the selection of the best predictor according to
      each individual strategy. These strategy selection results are then used to
      average the performance per strategy with the set of given performance
      metrics.
          The strategy ‘self conditional’ uses the previous occurrence of the event
      of interest to predict the next occurrence. As we saw, we have a relative and
      periodic predictor per preceding event, which means that for this strategy
      there are always two predictors. Therefore, for this strategy we report on
      the results for the relative and periodic predictors separately. A similar
      consideration is true for the ‘last conditional’ strategy. An overview of the
      considered strategies and their preprocessing and predictor selection during
      the second step of the strategy comparison is given in Table 8-1. This table
      also shows the strategy abbreviations we will use from now on.
          To be able to filter out the preceding events that always concur with
      other preceding events, for strategy evtconcur, it is necessary to keep
                           COMPARING STRATEGIES FOR PREDICTOR SELECTION                                            141



                           track of the mutual occurrence of every event pair. For our comparison
                           based on cross validation, this means a recalculation of the event
                           concurrence for every new interval, using all other intervals (the training
                           set).
                               Similarly, with bestll, we must keep track of the previous
                           performance of each predictor, by calculating the average likelihood for a
                           predictor at the measurement points that fall in the same time range as the
                           training set. For this, we use the likelihood values determined during the
                           basic properties step in the intervals in the training set. Note that these
                           values are calculated using the stream data in the other intervals, including
                           the interval for which we want to determine the average likelihood of the
                           predictor. An effect of this approach is that the performance of a predictor
                           is suppressed when the to-be-predicted event is an outlier. Therefore, this
                           effect may have an influence on the performance of the bestll strategy in
                           cross-validation scenarios.
                               An alternative approach would be to recalculate the likelihood at a
                           measurement point in a training interval using only the data in other
                           training intervals. Unfortunately, this requires additional (n-1) smoothing
                           parameter calculations per interval, for n the number of event occurrences,
                           lengthening the computing time with one to two orders of magnitude. The
                           average likelihood must be recalculated – during preprocessing – for every
                           new interval. We will see that the above effect is minimal when comparing
                           the bestll strategy performance evolution with the cross-validated
                           performance.

Table 8-1      Predictor   Strategy          Abbreviation Pre-       Predictor
selection           and                                   processing
preprocessing during the   Self conditional selfcondr no             KDE based on previous occurrence of event itself
second step in the         (relative)
strategy    comparison
algorithm                  Self conditional selfcondp no             KCDE based on previous occurrence of event itself
                           (periodic)
                           Last conditional lastcondr no             KDE based on most recent preceding event
                           (relative)
                           Last conditional lastcondp no             KCDE based on most recent preceding event
                           (periodic)
                           Lowest variance lowestvar no              Predictor (KDE or KCDE) with the lowest remaining
                                                                     waiting time variance
                           Event             evtconcur yes           Same as lowestvar, but only for preceding
                           concurrence                               events that do not always concur with other
                                                                     preceding events
                           Best likelihood   bestll       yes        Predictor (KDE or KCDE) with highest average log
                                                                     likelihood
142                         CHAPTER 8                                              PREDICTION RESULTS



                 8.1.5 Computational cost
                            A number of causes make the calculation of the cross validated prediction
                            performance costly in terms of computing time and memory. As we showed
                            in the previous chapter, the calculation of the smoothing parameters
                            requires polynomial time with respect to the number of event pairs.
                            Therefore, frequently occurring events of interest in combination with
                            frequently occurring preceding events require substantial more computing
                            time than less frequently occurring events.

Figure 8-4 Number of
events (log scale) with
an occurrence count
above different threshold
values,      for      the
participants in the
CoSphere data set




Figure 8-5 Number of
events (log scale) with
an occurrence count
above different threshold
values,      for      the
participants in the Rice
data set




                            Compared with the SynthSet-II data set, the CoSphere data set and
                            especially the Rice data set have many more events and also more
                            frequently occurring events. Figure 8-4 depicts the number of events that
                            have an occurrence count above a given threshold value, for the participants
                            in the CoSphere data set. It uses two subfigures to more clearly show the
                            number of events for individual participant. For a threshold value of 110,
                            there are only in the order of 10 events with a higher occurrence count for
                            the participants. A threshold value of 5, however, provides in the order of
                            several hundred qualifying events per participant. Figure 8-5 shows the same
                            information for the Rice dataset. The number of events for this data set is
COMPARING STRATEGIES FOR PREDICTOR SELECTION                               143



substantially larger, mainly because the Rice experiment sampled for in-
range networks with a higher frequency.
    Another cause of a substantial computing time is inherent to the
operation of cross validation: for every interval of an event of interest, it is
often necessary to recalculate the optimal smoothing parameters, especially
for the most expensive, frequently occurring preceding events.
Furthermore, the calculation of the basic performance properties is
expensive because it requires multiple integration actions per predictor at
every measurement point. For the Rice data set, we therefore randomly
select 100 events of interest from those events that have occurred at least 5
times in the stream, and use this limited initial set throughout the rest of
the calculations (i.e., apply the threshold values on this limited set).
    In terms of memory usage, the most demanding parts are the caching of
intermediary results such as the cross validated smoothing parameters and
the basic performance properties.
    To keep the calculation time as well as the memory usage within
practical limits, we applied a number of optimizations. The strategy
comparison is executed within a Python runtime environment [105], which
is relatively slow compared to compiled code. By executing some of the
core KDE and KCDE algorithms as native code, we realized a substantial
speed increase. On the algorithmic side, we calculate smoothing parameters
with a gradient descent optimization, which is much faster than the full
algorithm (see Section 7.6). Additionally, by taking into account that the
density estimates are constructed with Gaussian kernels, we were able to
simplify the integration steps necessary for scaling the waiting time to the
remaining waiting time and necessary for determining the expected
remaining waiting time, resulting in faster calculation. Finally, we stored
intermediary results in compressed form so that less disk space was
required.
    The above optimizations do not alter the selection of the optimal
smoothing parameters, except for the gradient descent algorithm. We have
executed a comparison of the gradient descent algorithm with one start
point (‘regular gradient descent’), the gradient descent algorithm with
multiple starting points (‘weighted gradient descent’) and the full algorithm.
This comparison has used a random selection of over 4000 event pairs
covering all 11 participants in the CoSphere data set. For KDE, this
resulted in different smoothing parameters in 11.5% of the cases for the
regular gradient descent algorithms compared to the full algorithm. For
KCDE, this was 7.2%. For the KCDE weighted gradient descent algorithm
this difference was only 0.1%. Additionally, we have executed the strategy
comparison with a full KDE algorithm and a weighted gradient descent
KCDE algorithm for the CoSphere data set and found no differences in the
overall results. Therefore, we conclude that we can apply the regular
144         CHAPTER 8                                               PREDICTION RESULTS



            gradient descent optimization for the smoothing parameter calculations in
            this chapter.

      8.1.6 Strategy comparison results
            We have executed the strategy comparison for different combinations of the
            set of events of interest and the set of preceding events using the CoSphere
            and Rice data sets. The size of both event sets is determined by the
            occurrence count threshold applied for that set: only those events in the
            stream with an occurrence count above the threshold are part of the set.
            Obviously, the sets are equivalent in case both threshold values are the
            same. The CoSphere stream contains cellular, 802.11 and Bluetooth
            network events and the Rice stream cellular and 802.11 network events, so
            that the prediction of individual events of interest may be based on
            preceding events from any of these technologies. Apart from not containing
            Bluetooth events, the Rice data set differs from the CoSphere data set in
            the following respects: it has a higher sampling frequency, reporting on
            network visibility every minute, and it captures information about all in-
            range cellular base stations – not only the actively used base station as with
            the CoSphere data set.
                The stream data contains interruptions caused by device resets during
            the collection of the data (see also Chapter 6). We have preprocessed the
            stream such that short interruptions less than 15 minutes are considered to
            not change the stream state: we assume no events happen during these
            short interruptions. If the interruption is longer than 15 minutes, we
            assume we do not know the events during that time and consequently
            discard all stream data during the interruption and the time before the
            interruption from the current event of interest interval.
                Some of the events in the stream show a high frequency alternating
            occurrence, in combination with one or more other events. This typically
            takes place in cellular networks, where a stationary device sometimes
            frequently switches between base stations. To dampen this effect, we limit
            the on-off behavior by removing from the stream short term off states with
            a duration less than 15 minutes. By greatly reducing the number of
            occurrences of some of the events in this way, we also limit the necessary
            computing time. The numbers in Figure 8-4 and Figure 8-5 refer to the
            situation after removing short interruptions and short-term off states. Note
            that this scheme does not influence the occurrence of events associated
            with network entities that are visible for a short time once during a longer
            period (i.e., visible shorter than 15 minutes), for instance in case of
            traveling. This information is retained in the stream.
                            COMPARING STRATEGIES FOR PREDICTOR SELECTION                                                            145




Table 8-2        Strategy


                            Participant
comparison     for the




                                                                                                               evtconcur
                                                                                       lastcondp



                                                                                                   lowestvar
                                                               selfcondp



                                                                           lastcondr
                                                   selfcondr
CoSphere data set,


                                          metric




                                                                                                                           bestll
with the best strategy
performance         value
printed     in       bold    p1           ll       -2.29       -1.89       -1.59       -1.65       -2.16       -1.99       -0.33
(occurrence threshold is                  win      0.02        0.03        0.12        0.04        0.25        0.11        0.42
10).                                      mse      1166        1218        155         202         1001        1047        120
                                          mape     25.3        22.8        7.98        7.73        14.0        15.1        5.74
                             p2           ll       -2.62       -2.43       -1.73       -1.89       -1.83       -1.74       -0.86
                                          win      0.02        0.02        0.10        0.06        0.29        0.16        0.35
                                          mse      661         624         84.9        119         206         225         64.1
                                          mape     19.1        16.9        6.57        6.45        6.37        7.32        4.09
                             p3           ll       -1.89       -1.89       -1.12       -1.29       -1.64       -1.18       -0.51
                                          win      0.03        0.02        0.17        0.07        0.21        0.13        0.36
                                          mse      194         230         28.4        37.3        48.3        115         11.2
                                          mape     10.4        9.58        3.31        3.49        2.71        5.32        1.78
                             p4           ll       -2.58       -2.17       -1.42       -1.79       -2.00       -1.65       -0.50
                                          win      0.04        0.02        0.13        0.04        0.29        0.11        0.38
                                          mse      775         739         94.8        115         291         224         81.8
                                          mape     19.2        16.4        6.22        6.45        7.53        7.64        4.44
                             p5           ll       -2.35       -2.28       -1.57       -1.74       -2.03       -1.91       -0.31
                                          win      0.03        0.01        0.08        0.04        0.25        0.12        0.47
                                          mse      769         796         90.1        99.9        371         400         102
                                          mape     20.1        17.4        6.62        6.07        7.96        8.50        4.46
                             p6           ll       -2.89       -2.84       -1.92       -2.28       -2.20       -1.90       -0.58
                                          win      0.01        0.01        0.09        0.03        0.28        0.11        0.46
                                          mse      1358        1378        148         142         577         384         127
                                          mape     31.2        28.8        8.93        8.00        11.8        10.2        5.66
                             p7           ll       -1.57       -1.48       -1.04       -1.42       -1.28       -1.23       -0.43
                                          win      0.03        0.03        0.13        0.05        0.28        0.15        0.33
                                          mse      118         173         13.5        22.8        46.2        66.3        28.9
                                          mape     8.57        8.58        2.55        2.97        3.22        4.27        2.45
                             p9           ll       -2.45       -2.25       -1.87       -2.06       -1.83       -1.85       -0.95
                                          win      0.03        0.04        0.14        0.05        0.29        0.13        0.32
                                          mse      818         845         164         202         378         316         100
                                          mape     20.2        18.6        8.64        8.21        8.81        8.59        5.54
                             p10          ll       -1.67       -1.73       -1.42       -1.69       -1.69       -1.51       -0.66
                                          win      0.03        0.02        0.16        0.04        0.26        0.13        0.36
                                          mse      260         285         71.4        73.5        370         272         60.1
                                          mape     9.98        8.83        5.04        4.86        5.82        5.59        3.30
                             p11          ll       -1.55       -1.37       -1.09       -1.20       -1.38       -1.28       -0.29
                                          win      0.03        0.04        0.09        0.07        0.27        0.16        0.35
                                          mse      388         352         45.5        48.6        117         157         55.5
                                          mape     12.6        9.96        3.83        3.55        3.80        4.93        2.99
                             p12          ll       -2.59       -2.40       -1.72       -1.91       -1.72       -1.74       -0.84
                                          win      0.02        0.02        0.11        0.06        0.29        0.16        0.35
                                          mse      902         836         139         206         347         335         157
                                          mape     22.5        20.3        8.58        9.23        9.17        9.90        7.33
146                        CHAPTER 8                                                                          PREDICTION RESULTS




Table 8-3       Strategy


                           participant
comparison for the




                                                                                                                  evtconcur
                                                                                      lastcondp



                                                                                                  lowestvar
                                                              selfcondp



                                                                          lastcondr
                                                  selfcondr
Rice data set, with the


                                         metric




                                                                                                                              bestll
best            strategy
performance        value
printed     in      bold    p1           ll       -2.02       -1.91       -1.19       -1.55       -1.56           -1.52       -0.27
(occurrence threshold is                 win      0.00        0.01        0.10        0.04        0.23            0.13        0.49
10).                                     mse      673         721         26.8        35.2        200             266         66.0
                                         mape     17.0        16.6        3.24        3.62        5.63            7.64        3.18
                            p2           ll       -1.21       -1.67       -0.73       -1.38       -1.28           -0.60       0.46
                                         win      0.02        0.02        0.08        0.02        0.19            0.11        0.56
                                         mse      25.7        65.4        4.85        14.0        1.23            5.58        1.40
                                         mape     3.92        4.73        1.36        2.57        0.56            0.73        0.60
                            p3           ll       -2.30       -2.31       -1.40       -1.80       -1.63           -1.87       -0.41
                                         win      0.01        0.01        0.08        0.02        0.29            0.14        0.45
                                         mse      1181        1279        106         119         291             396         65.4
                                         mape     21.7        21.9        4.98        5.48        6.12            8.99        3.55
                            p4           ll       -2.64       -2.76       -1.69       -2.02       -1.81           -1.77       -0.27
                                         win      0.01        0.00        0.05        0.04        0.29            0.13        0.48
                                         mse      1815        2102        165         125         327             514         84.4
                                         mape     31.0        31.1        6.85        6.66        8.06            12.9        4.50
                            p5           ll       -2.03       -2.07       -1.49       -1.73       -1.21           -1.31       -0.36
                                         win      0.01        0.01        0.06        0.01        0.30            0.12        0.49
                                         mse      716         686         56.1        46.1        136             148         50.4
                                         mape     18.6        16.8        4.84        4.46        5.44            6.38        3.43
                            p6           ll       -2.61       -2.42       -1.79       -2.08       -1.47           -1.64       -0.36
                                         win      0.00        0.01        0.04        0.02        0.32            0.11        0.51
                                         mse      781         724         72.0        66.6        107             273         54.9
                                         mape     22.6        20.1        5.97        5.80        5.79            9.26        3.76
                            p7           ll       -2.61       -2.56       -1.80       -2.20       -2.07           -2.06       -0.44
                                         win      0.00        0.00        0.05        0.02        0.26            0.08        0.59
                                         mse      723         749         67.8        80.7        127             210         82.9
                                         mape     20.9        19.9        6.15        6.60        6.76            9.33        4.38
                            p8           ll       -3.18       -3.19       -1.91       -2.28       -2.74           -2.71       -0.50
                                         win      0.00        0.00        0.06        0.01        0.27            0.10        0.56
                                         mse      3298        3152        229         266         1266            2922        138
                                         mape     44.0        41.2        9.74        9.97        19.0            24.0        7.25
                            p9           ll       -2.01       -2.11       -1.51       -1.97       -1.72           -1.59       -0.23
                                         win      0.02        0.01        0.05        0.01        0.28            0.12        0.52
                                         mse      266         311         34.8        48.9        71.0            156         23.7
                                         mape     12.5        12.5        4.09        4.90        3.87            6.78        2.17
                            p10          ll       -2.31       -2.46       -1.55       -2.05       -1.84           -1.33       -0.17
                                         win      0.01        0.00        0.04        0.01        0.26            0.13        0.55
                                         mse      462         441         73.0        103         165             181         29.5
                                         mape     16.5        14.8        5.44        6.31        5.77            6.66        2.37
COMPARING STRATEGIES FOR PREDICTOR SELECTION                             147



The results in Table 8-2 show the CoSphere prediction performance per
participant for 7 different predictor selection strategies, measured with 4
different metrics. Participants are denoted by ‘p’ followed by a number.
They concern the prediction using an occurrence threshold value of 10, for
both the set of events of interest and the set of preceding events, with an
average of 145 events per set. Per row, the best prediction value is indicated
in bold. From this table, it is clear that bestll is the best predictor
selection strategy for all applied metrics, when considering all participants
combined. The lastcondr strategy is better from the perspective of mse
for 4 participants, but the other 7 participants have better results for
bestll using the same metric. A similar result for the best strategy can be
observed for the Rice prediction performance, as provided in Table 8-3.
    When considering a broader range of occurrence threshold values, the
bestll strategy shows the best overall results for most metrics, although
for higher threshold values lastcondr is catching up and exceeds bestll
for a threshold value of 110. Especially with metric mse, the lastcondr
strategy is quickly becoming the preferred strategy for higher threshold
values. Also for higher threshold values, the strategies lastcondp and
lowestvar start being best for some participants.
    These results can be observed in Figure 8-6 and Figure 8-7. It shows the
number of participants that have a strategy-metric pair as best predictor, for
the strategies lastcondr, lastcondp, lowestvar and bestll, with
different values for the occurrence threshold for both sets. The other three
strategies are left out, because they are not once marked as a best predictor
selection strategy. For the CoSphere data set, the total number of
participants for every metric-threshold pair is 11, except for the threshold
values 90 and 110, in which case this number is 10. This is caused by the
fact that participant 2 does not have events with an occurrence count above
or equal to 90 (see also Figure 8-4). For the Rice data set, the total number
of participants is 10.
    When looking at the second best strategy for predictor selection, the
outcome is much more varied. For the case of an occurrence threshold
value of 5, for instance, which is dominated by bestll as the best strategy,
the second best strategy is hard to determine because it is more or less
equally spread over lastcondr, lastcondp, lowestvar and evtconcur.
For specific metrics, some are preferred: the evtconcur strategy, for
example, is best for the maximum likelihood metric.
    One notable outcome of this comparison is that evtconcur is not
always better than lowestvar, as would be expected from Chapter 7. It is
better for some metrics, but not all, and it is never a best strategy, while
lowestvar is a best strategy occasionally (with higher threshold values).
This may be caused by the effect of frequently occurring preceding events
being pushed away by far less frequently occurring preceding events, while
148                           CHAPTER 8                                              PREDICTION RESULTS



                              the less frequently occurring events do not have enough data to form a
                              stationary estimate. In that case, under cross validation, the estimate
                              changes considerably from interval to interval, resulting in a less accurate
                              prediction.

Figure 8-6 Comparison
of the lastcondr,
lastcondp,
lowestvar           and
bestll strategies for
all four metrics and for
different values of the
occurrence threshold for
the CoSphere data
set




Figure 8-7 Comparison
of the lastcondr,
lastcondp,
lowestvar and
bestll strategies
for all four metrics and
for different values of the
occurrence threshold for
the Rice data set




                              Another notable outcome is the prediction performance of predictors based
                              on relative estimates versus those based on periodic (daily) estimates. For
                              the selfcond and lastcond strategies, overall the periodic variants do not
      INFLUENCE OF OCCURRENCE THRESHOLD OF EVENT SETS                          149



      provide better predictions than the relative variants and vice versa. The
      other strategies sometimes choose a periodic predictor and at other time a
      relative predictor. The lowestvar and evtconcur strategies behave
      almost the same: they choose a relative predictor 50 percent of the times
      for an occurrence threshold of 5, dropping to 25 percent for an occurrence
      threshold of 110. The bestll strategy has a more stable relative predictor
      selection percentage of around 65 for all occurrence threshold values. This
      means that bestll considers a period predictor to have a better historical
      likelihood in 35 percent of the times, which is an indication that taking into
      account periodicity is improving the prediction performance. Note that we
      used the data of all available days in the CoSphere and Rice data sets,
      without making a distinction between work days and weekend days.
      Focusing on work days (or weekend days) may provide different results than
      we found for the complete data set. The example in Section 8.5 uses
      weekdays only.

8.1.7 Comparison conclusions
      The general conclusions from the cross validation strategy comparison are
      now the following. Overall, the best strategy for predictor selection is the
      bestll strategy: most convincingly for cases when we have a large set of
      events of interest being predicted by an equally large set of preceding
      events. For the metrics mse and mape, the lastcondr strategy is on par
      with bestll, and even surpasses it in case of highly frequently occurring
      events of interest and preceding events. Using a preceding occurrence of an
      event to predict the next occurrence of this event does not provide a good
      prediction, not for the relative nor for the period case. And finally, when
      comparing the periodic predictors with the relative predictors, none of
      these two predictor categories have a high prevalence over the other. These
      conclusions apply to both the CoSphere and the Rice data set.


8.2   Influence of occurrence threshold of event sets
      In this section we investigate the influence of the size of both the set of
      events of interest and the set of preceding events on the prediction
      performance. We want to answer the following question: given a set of
      events of interest, what is the influence of enlarging the set of preceding
      events (i.e., essentially having more information) on the prediction of the
      events of interest?
         We do this by taking the bestll strategy and applying the normalized
      log likelihood as metric, to measure, in a cross validated manner, the
      prediction performance with different occurrence threshold values. As with
150          CHAPTER 8                                               PREDICTION RESULTS



             the strategy comparison, we use the events of all three network technologies
             available in the original CoSphere stream and the events of the two
             network technologies in the Rice stream and use occurrence threshold
             values that are in [5, 10, 30, 50, 70, 90, 110].
                 When using more information to predict an event of interest, in case of
             a growing data set caused by a decreasing occurrence threshold, we expect
             to see two opposing effects. The first effect is that more information allows
             for better prediction. The second effect is that predictors based on little
             historical data deteriorate the prediction performance. We describe both
             effects in more detail below.

      8.2.1 Effect of more information
                 The first effect is that more information allows for better prediction,
             because it helps to identify specific situations that would otherwise be
             unnoticed. For example, when a participant occasionally meets a person at
             the office at the end of a working day, indicated by the event of this
             person’s Bluetooth device coming in range, it always takes longer before the
             participant arrives within range of his home network (perhaps because they
             join for an after-work activity). Now, if this Bluetooth event does not occur
             very often, it will quickly be filtered out by the occurrence threshold, and
             therefore will not be considered as a predictor.

      8.2.2 Effect of predictors with little history
                 The second effect is lack of stability of a predictor caused by an optimal
             smoothing parameter calculation with relatively few observations, which
             may mark a predictor as very good (high average likelihood for strategy
             bestll) simply because the few observations in the stream happen to be
             close to each other. In such a case, this predictor is chosen by bestll as
             the best predictor, while the next occurrence is likely to yield a low
             likelihood and not being predicted well at all. For instance, in the example
             above, all first few observations may indicate an arrival at home at 20:00
             hours while the next observation shows an arrival time of 22:00 hours.
             Obviously, it is easy to set a minimum number of pairs required to have a
             valid predictor, but if set high, only the most frequently occurring events
             can serve as predictors. The cross validation performance algorithm applies
             a minimum of 3 pairs to calculate optimal smoothing parameters, which
             allows for many predictors for all participants (for an occurrence threshold
             value of 5 the maximum number of predictors is close to 250 on average, as
             can be seen in Figure 8-4, and around 1100 for the Rice data set, as shown
             in Figure 8-5). Note that even when an event occurs 5 times in the stream,
             the number of pairs used to calculate the best smoothing parameters may
             be less than 4, because multiple pairs may be related to the interval for
       INFLUENCE OF OCCURRENCE THRESHOLD OF EVENT SETS                           151



       which we want to predict, and our cross validation approach only uses data
       from intervals other than the one we want to predict. If, in such a case, the
       number of pairs drops below 3, we do not consider that predictor.

8.2.3 Prediction results with variable event sets
           The results of the prediction performance are depicted in the
       participant 3D grid plots in Figure 8-8 for participants 1 and 12 of the
       CoSphere data set, and in Figure 8-9 for participants 1 and 10 of the Rice
       data set. A full overview of all participants can be found in Appendix C.
           The x-axis and y-axis of the plots indicate the occurrence threshold for
       the set of events of interest (oc-evti) and the occurrence threshold for the
       set of preceding events (oc-evtc), and have a value between 5 and 110.
       The z-axis marks the normalized log likelihood. For every CoSphere
       participant, the [oc-evti = 10, oc-evtc = 10] point can be found back
       in Table 8-2, with metric ll and strategy bestll (and in a similar manner
       for Rice in Table 8-3).
           From the plots, we can get a qualitative indication of the prediction
       performance change for a fixed set of events of interest, while applying
       different sizes of the preceding event set. For instance, for CoSphere
       participant 1, the events of interest set with oc-evti = 10 shows that a
       large preceding events set with oc-evtc = 5 provides the best prediction
       performance. The performance decreases with higher oc-evtc values until
       50, from which on there is an upward trend again.
           When using the plots to get an indication of changing normalized
       prediction performance for a fixed preceding events set, we must realize
       that different event of interest sets have different measurement point
       distributions. Sets with only highly frequent events are much less likely to
       see measurement points long before the event of interest occurs, which may
       impact the prediction performance.

8.2.4 Conclusions on variable occurrence thresholds
       Considering the plots of all participants, we conclude the following. Under
       cross validation, there is a clear trend for the CoSphere data set that using a
       larger number of predictors, including predictors that occur infrequently,
       results in a better prediction performance given a fixed set of events of
       interest. The effect of a possible lack of predictor stability does not seem to
       play an important role: in most cases, events that occur infrequently are also
       useful to take into account. For the Rice data set, however, this trend is
       less strong, but can still be observed for most participants.
152                          CHAPTER 8                                                   PREDICTION RESULTS




Figure 8-8 Normalized                                        participant 1
log      likelihood     of
predictions with the
bestll strategy, for
different combinations
of     the      occurrence        -0.2
threshold values for the          -0.3
events of interest (ot-           -0.4
evti)          and     the        -0.5
preceding events (ot-             -0.6
                                  -0.7
evtc). Depicted are               -0.8
participant 1 and 12              -0.9
from the CoSphere                   -1
data set.
                                                                                                    20
                                                                                               40
                                         20   40                                          60    ot-evtc
                                                        60                          80
                                              ot-evti         80      100     100




                                                             participant 12




                                  -0.5
                                  -0.6
                                  -0.7
                                  -0.8
                                  -0.9
                                    -1
                                  -1.1
                                  -1.2
                                  -1.3
                                  -1.4


                                                                                                    20
                                                                                               40
                                         20   40                                          60    ot-evtc
                                                        60                          80
                                              ot-evti         80      100     100
                             INFLUENCE OF OCCURRENCE THRESHOLD OF EVENT SETS                             153




Figure 8-9 Normalized                                        participant 1
log      likelihood     of
predictions with the
bestll strategy, for
different combinations
of     the      occurrence       -0.44
threshold values for the         -0.46
events of interest (ot-          -0.48
                                  -0.5
evti)          and     the       -0.52
preceding events (ot-            -0.54
                                 -0.56
evtc). Depicted are              -0.58
participant 1 and 10              -0.6
                                 -0.62
from the Rice data set.          -0.64


                                                                                                   20
                                                                                              40
                                         20   40                                         60    ot-evtc
                                                        60                          80
                                              ot-evti         80      100     100




                                                             participant 10




                                 -0.55
                                  -0.6
                                 -0.65
                                  -0.7
                                 -0.75
                                  -0.8
                                 -0.85
                                  -0.9
                                 -0.95


                                                                                                   20
                                                                                              40
                                         20   40                                         60    ot-evtc
                                                        60                          80
                                              ot-evti         80      100     100
154         CHAPTER 8                                                PREDICTION RESULTS



      8.3   Influence of multi-network interface information
            The CoSphere data set consists of cellular, 802.11 and Bluetooth events,
            but so far we selected events without differentiating on type of technology.
            In this section we investigate the influence of using different types of
            network events on the prediction performance. Knowing this influence
            helps to make decisions on which network interfaces to use to collect
            network events: if we want to predict Bluetooth events and the availability
            of 802.11 wireless LAN events does not positively contribute to a better
            prediction, then it is not wise to invest resources to gather these 802.11
            events.
                We again turn to cross validation to determine the prediction
            performance of a number of events of interest sets. In this case, we use a set
            of events of interest for every participant with a minimum occurrence
            threshold of 10, and filter this set based on the type(s) of network events
            we want predict. We choose sets of preceding events in the same way, based
            on the network events we want to use to predict. The rest of the prediction
            calculations are executed in the way explained in the first section of this
            chapter.

      8.3.1 Cross-technology results
            The results of these calculations on the participant data in the CoSphere
            data set are presented in Table 8-4. The events of interest in four different
            sets (evti set) are predicted using the bestll strategy, where the
            prediction performance is indicated by the normalized log likelihood taken
            over all measurement points for a participant. Each type of network
            technology has its own character: ‘c’ indicates cellular events, ‘w’ are 802.11
            wireless LAN events and ‘b’ are Bluetooth events. A set marked as ‘cwb’
            therefore holds all three types of network events, while a set marked as ‘b’
            holds only Bluetooth events.
                The seven sets of preceding events (evtc set), used as predictor sets,
            constitute all possible combinations of network technology event types. The
            last column shows the aggregated results over all participants. An entry with
            dashes is the case that – on average – delivers the best prediction results for
            a particular evti set. The other results in that column for the same evti
            set indicate the average log likelihood difference between that entry and
            the ‘best result’ entry. As such, this weighted difference indicates how much
            worse that entry predicts compared to the best entry: the more negative this
            result, the worse the prediction. Note that individual participants may show
            a different preference order than the average preference order. For those
            entries where the best prediction deviates from the best average, the log
            likelihood values are shown in bold. Also note that the results for the sets
      INFLUENCE OF MULTI-NETWORK INTERFACE INFORMATION                            155



      with all network types included (evti set = ‘cwb’, evti set =
      ‘cwb’)   differ slightly from the results in the straightforward cross validation
      in Section 8.1, for an occurrence threshold value of 10, because they were
      acquired during another run of the performance calculation algorithm.
          In all four cases, the average prediction results are best when using all
      types of network events. Therefore, when interested in the best
      performance, all network type events should be used to predict well in
      general. In most cases, however, leaving out Bluetooth events lowers the
      performance only marginally. And in individual cases, leaving out certain
      types of network events increases the prediction performance (such as not
      using Bluetooth when predicting cellular events only).
          The prediction of events for individual network technologies benefits
      most from using preceding events of the same technology type. This is
      clearly the case for the cellular and 802.11 network technologies, where not
      having cellular respectively 802.11 preceding events reduces the
      performance significantly. This effect is less strong for Bluetooth, however:
      in general, using cellular only events is comparable with using Bluetooth
      only events as preceding events. For quite a number of individual
      participants, the cellular events predict Bluetooth events better than
      Bluetooth events themselves.

8.3.2 Conclusions for cross-technology prediction
      Given these results, we conclude the following. In general, using more types
      of network events increases the prediction performance of sets combining
      events from arbitrary technology types. In individual situations however,
      this is not always the case. In general, events from the same technology
      contribute most to increasing the prediction performance. Again, this is not
      always true for individual cases. So, when deciding to collect or not collect
      events of a certain network type, there are a number of rules of thumb to
      apply upfront, although it is understood that this is not always best for
      individual cases. For a better indication of the influence of events of
      different network types, it is necessary to measure performance at the
      individual participant level.
156                          CHAPTER 8                                             PREDICTION RESULTS




Table 8-4a Prediction        evti set   evtc set   p1      p2      p3      p4         p5      p6
performance for event
sets using different types   cwb        cwb        -0.38   -0.89   -0.50   -0.63      -0.33   -0.61
of network technology
events       for       the              cw         -0.41   -0.92   -0.53   -0.74      -0.41   -0.71
CoSphere data set.
                                        cb         -0.46   -0.95   -0.61   -0.82      -0.42   -0.73

                                        wb         -0.51   -1.00   -0.95   -1.03      -0.71   -1.46

                                        c          -0.54   -1.04   -0.71   -0.86      -0.58   -0.71

                                        w          -0.62   -1.10   -1.03   -1.23      -0.96   -2.01

                                        b          -1.49   -1.12   -1.46   -1.29      -0.86   -1.58

                             c          cwb        -0.25   -1.13   -0.57   -0.83      -0.55   -0.72

                                        cw         -0.26   -1.08   -0.60   -0.86      -0.59   -0.72

                                        cb         -0.39   -1.12   -0.64   -0.83      -0.60   -0.75

                                        wb         -0.35   -1.27   -1.12   -1.48      -1.22   -1.69

                                        c          -0.50   -1.18   -0.68   -1.01      -0.66   -0.81

                                        w          -0.48   -1.32   -1.11   -2.22      -1.40   -2.43

                                        b          -1.88   -1.22   -1.37   -1.50      -1.61   -1.74

                             w          cwb        -0.79   -0.89   -0.63   -0.72      -0.54   -1.18

                                        cw         -0.83   -0.97   -0.64   -0.69      -0.57   -1.20

                                        cb         -0.93   -0.97   -0.89   -1.43      -0.59   -1.58

                                        wb         -1.00   -1.07   -0.90   -0.82      -0.73   -1.14

                                        c          -1.02   -1.02   -0.84   -1.51      -0.78   -1.78

                                        w          -1.03   -1.18   -1.00   -0.79      -0.81   -1.28

                                        b          -1.39   -1.16   -1.53   -1.92      -0.81   -1.83

                             b          cwb        -0.79   -0.84   -0.44   -0.87      -0.45   -0.96

                                        cw         -0.90   -0.94   -0.54   -0.95      -0.60   -1.07

                                        cb         -0.96   -0.83   -0.67   -0.87      -0.52   -1.10

                                        wb         -0.94   -1.00   -0.53   -1.17      -0.75   -1.34

                                        c          -1.18   -1.08   -1.12   -1.06      -0.85   -1.22

                                        w          -1.48   -1.09   -0.74   -2.60      -0.84   -2.19

                                        b          -1.24   -1.15   -0.84   -1.21      -0.78   -1.37
                        INFLUENCE OF MULTI-NETWORK INTERFACE INFORMATION                      157




Table 8-4b (continued   evti set   evtc set   p7      p9      p10     p11     p12     all
from previous page)
                        cwb        cwb        -0.48   -1.02   -0.75   -0.31   -0.87   --

                                   cw         -0.53   -1.31   -0.82   -0.39   -0.88   -0.08

                                   cb         -0.54   -1.19   -0.90   -0.51   -0.99   -0.12

                                   wb         -0.52   -1.07   -0.84   -0.35   -0.94   -0.24

                                   c          -0.64   -1.86   -1.11   -0.73   -1.11   -0.29

                                   w          -0.66   -1.21   -0.94   -0.43   -1.10   -0.41

                                   b          -0.65   -1.24   -1.14   -0.59   -1.32   -0.54

                        c          cwb        -0.60   -1.74   -0.89   -0.70   -1.15   --

                                   cw         -0.74   -1.95   -0.90   -0.90   -1.13   -0.06

                                   cb         -0.71   -1.78   -0.91   -0.81   -1.19   -0.06

                                   wb         -0.70   -1.87   -1.13   -0.85   -1.35   -0.35

                                   c          -0.89   -2.03   -0.98   -1.12   -1.28   -0.18

                                   w          -0.87   -2.46   -1.21   -1.01   -1.52   -0.63

                                   b          -0.75   -1.84   -1.32   -0.77   -1.28   -0.56

                        w          cwb        -0.62   -0.77   -0.74   -0.19   -0.86   --

                                   cw         -0.68   -0.86   -0.82   -0.27   -0.93   -0.05

                                   cb         -0.58   -1.15   -1.15   -0.33   -1.06   -0.25

                                   wb         -0.59   -0.85   -0.73   -0.29   -0.97   -0.11

                                   c          -0.69   -2.01   -1.47   -0.56   -1.07   -0.44

                                   w          -0.76   -0.88   -0.88   -0.23   -1.09   -0.18

                                   b          -0.78   -1.11   -1.32   -0.41   -1.28   -0.51

                        b          cwb        -0.49   -1.05   -0.95   -0.67   -0.90   --

                                   cw         -0.59   -1.50   -1.23   -0.74   -1.04   -0.15

                                   cb         -0.59   -1.16   -1.09   -0.89   -1.03   -0.12

                                   wb         -0.58   -1.08   -0.94   -0.71   -1.05   -0.15

                                   c          -0.64   -1.73   -1.49   -1.05   -1.08   -0.37

                                   w          -0.76   -1.56   -1.15   -0.73   -1.23   -0.54

                                   b          -0.67   -1.18   -1.11   -1.06   -1.38   -0.33
158         CHAPTER 8                                                 PREDICTION RESULTS




      8.4   Prediction performance evolution with increasing
            stream size
            In Chapter 7, we discussed the prediction performance evolution of a
            number of predictor selection strategies using a synthetic data set. We now
            present the evolution results for the CoSphere data set, using the strategies
            we also compared in the cross validation section in this chapter.
            The evolution comparison differs from the cross validation comparison in
            terms of the used algorithm. We use the same scheme for determining
            measurement points (i.e., backward increasing distance, exponential
            distribution). The best smoothing parameters, however, are not calculated
            on the data of all other intervals except the current interval, but instead are
            determined using the data of preceding intervals only. When going over the
            measurement points for a participant, this means that the prediction
            calculation at measurement points later in time are based on more historical
            data than those earlier in time. It is interesting to see whether the strategy
            preference observed for the cross validation comparison holds for the case
            where we have a growing data set – the case that better reflects real
            scenarios.
                The performance at a certain point in time is calculated over the
            preceding measurement points that fall into a sliding window. This is
            necessary, because the performance at individual measurement points may
            fluctuate considerably, making it hard to compare strategies visually in a
            plot. We set the window size to 1/3 of the total time a participant had his
            data collected, and average the results for the measurement points in that
            window. For the first part of the stream, this scheme averages over few
            measurement points, which makes that part less suitable for comparison.
            Note that participants have been in the trial with different duration, with an
            average duration of almost 34 days.

      8.4.1 Prediction performance evolution results
            When looking at the likelihood evolution for the bestll prediction
            strategy for all participants in Figure 8-10, the general trend is a rising value
            for the first half of the observation time followed by a stable or slightly
            increasing value in the second half.
                We must interpret these results with care, however, because the
            absolute value of the likelihood may not be directly linked with the
            prediction performance. If, for instance, a participant has a very different
            behavior later on in the trial, the density function of the predictors may be
            flattened, which leads to lower likelihoods. In that case, we expect to see a
                             PREDICTION PERFORMANCE EVOLUTION WITH INCREASING STREAM SIZE                                            159



                             decrease of the absolute likelihood – something that may be the case for the
                             outlier prediction evolution for one participant at the end of the upper plot
                             in Figure 8-10. Likewise, if we assume stationary behavior, we expect to see
                             a rising absolute likelihood, flattening off with time, which is generally the
                             case for this figure.

Figure 8-10           Per
                                                                                       occurrence threshold = 5
participant (not further
specified) weighted log                                     0
likelihood evolution for
prediction strategy bestll
on the CoSphere data                                      -0.5
set.
                                weighted log likelihood




                                                           -1


                                                          -1.5


                                                           -2


                                                          -2.5


                                                           -3
                                                                 0   0.1   0.2   0.3      0.4     0.5        0.6   0.7   0.8   0.9   1
                                                                                             time fraction


                                                                                   occurrence threshold = 110
                                                            0


                                                          -0.5
                                weighted log likelihood




                                                           -1


                                                          -1.5


                                                           -2


                                                          -2.5


                                                           -3
                                                                 0   0.1   0.2   0.3      0.4     0.5        0.6   0.7   0.8   0.9   1
                                                                                             time fraction
160                        CHAPTER 8                                                                                PREDICTION RESULTS



                           We use the likelihood metric now to compare different strategies. The
                           results from the cross validation comparison show that the bestll,
                           lastcondr, lowestvar, and lastcondp strategies deliver the best
                           predictors: we therefore focus on these strategies here.

Figure 8-11 Strategy
                                                                                            participant 1
comparison           for
participant 1 and 12 of                                  0
the CoSphere data set.

                                                       -0.5
                             weighted log likelihood




                                                        -1


                                                       -1.5


                                                        -2


                                                       -2.5


                                                        -3
                                                              0     0.1   0.2    0.3    0.4      0.5        0.6    0.7   0.8     0.9    1
                                                                                            time fraction

                                                              lastcondr         lastcondp              lowestvar               bestll


                                                                                            participant 12
                                                         0


                                                       -0.5
                             weighted log likelihood




                                                        -1


                                                       -1.5


                                                        -2


                                                       -2.5


                                                        -3
                                                              0     0.1   0.2    0.3    0.4      0.5        0.6    0.7   0.8     0.9    1
                                                                                            time fraction

                                                              lastcondr         lastcondp              lowestvar               bestll
      APPLICATION: PREDICTION OF SYNCHRONIZATION OPPORTUNITIES                  161



      The prediction evolution for these strategies for participant 1 and 12 of the
      CoSphere data set is shown in Figure 8-11, with an occurrence threshold
      value of 10. A full overview of all participants is provided in Appendix D. For
      all participants, the bestll strategy quickly shows the best performance.
          In order to compare the evolution results with the cross validation
      results, we took the likelihood values for a fixed set of events of interest
      with an occurrence threshold of 50 and varied the preceding events set size.
      The trend observed for the evolution values is the same as the cross
      validation values: in general, the prediction performance increases with a
      lower threshold value. Also, individual trends are the same for the evolution
      and cross validation cases.

8.4.2 Prediction performance evolution conclusions
      For all participants, the bestll strategy is quickly the one with the highest
      weighted log likelihood. This brings the evolution strategy comparison in
      line with the cross validation comparison. When doing the same calculation
      for different occurrence thresholds (not depicted here), the results are also
      in line with the cross validation results: for higher threshold values, the
      lastcondr strategy is often better. Also, we noticed that with higher
      threshold values, the likelihood for the different strategies is very close to
      each other.


8.5   Application:            prediction            of       synchronization
      opportunities
      In this section we apply – by means of example – the density estimation
      method introduced in Chapter 7 to a part of the data collected during the
      CoSphere user experiment, using the occurrence of a single fixed preceding
      event to predict the occurrence of another event. The preceding event
      marks the occurrence of getting in range of a network entity and the event
      of interest marks the occurrence of moving out of range of that network
      entity.
          Suppose we have a data synchronization job that needs to use a network
      resource for an uninterrupted long duration, say one hour. Then, we would
      prefer to only use those network entities that have a low probability of
      losing visibility in the next one hour. So, as example, we now want to
      determine all the occasions during weekdays that for a visible network
      entity the probability of getting out-of-range in the next one hour is lower
      than, say, 0.1. We assume that the type of the network entity is irrelevant,
      so that cellular, 802.11 and Bluetooth entities are all considered. By doing
      so, we are capable of comparing and characterizing the different
162                          CHAPTER 8                                                 PREDICTION RESULTS



                             technologies. Also, for sake of simplicity, we do not take into account that
                             some entities form larger networks that already offer uninterrupted
                             connectivity below the network layer, such as office wireless LANs. Indeed,
                             if we did, this would create more occasions with low probability of
                             interruption.
                                 To calculate out-of-range event probabilities, we make choices on
                             threshold values, parameter values and the candidate strategies for best
                             predictor selection. These choices are the responsibility of the application
                             designer: we make them here for illustration purposes, not to obtain the
                             best prediction results (i.e., to indicate which kinds of decisions must be
                             made to be able to calculate out-of-range event probabilities).

Figure 8-12 Number of
matching         intervals
(upper part of bar) and
non-matching intervals
(lower part of bar) for
cellular, 802.11 and
Bluetooth entities during
the CoSphere trial (per
participant)




                             We configure the probability calculation in the following way. The stream is
                             filtered to only contain weekday events, and is adjusted so that 1) short
                             interruptions (< 5 minutes) do not change the stream state and 2) short
                             term network entity invisibility (< 10 minutes) is erased. We compute the
                             probability of losing visibility for the next hour using KCDE estimates
                             conditional on the 24 hour period of the stream with the preceding event as
                             conditional (i.e., we use a single best predictor selection strategy: the
                             selfcondp strategy in Table 8-1). We use the top 5 most-visible entities
                             for every technology, in terms of total accumulated duration (not in terms
                             of number of visibility intervals). The probability is calculated for every
                             interval for every top 5 entity, in steps of 15 minutes, starting after the first
                             10 minutes of visibility: if the current measurement time gives a probability
                            SUMMARY AND REFLECTIONS                                                    163



                            larger than 0.1, we increment the time with 15 minutes and recalculate. If
                            the probability is below 0.1 for any time, the interval is marked as a match.
                            The set of event pairs also contains the current interval, and the optimal
                            smoothing parameters are calculated using the full set. This has little impact
                            on the density estimate, however, because the sets of intervals typically
                            consist of 30 or more samples.

Figure 8-13 Average
number        of     sync
opportunities per day for
cellular (lower part of
bar), 802.11 (middle
part of bar) and
Bluetooth (upper part of
bar) per participant




                            When doing this for all top 5 entities, we get a result as depicted in Figure
                            8-12, where the light gray parts of the bar are intervals that have at a certain
                            moment during their existence a probability of less than 0.1 to get out-of-
                            range in the next hour. The dark gray parts have not. It clearly shows that
                            cellular, and to a lesser extent, 802.11 entities have more matching
                            intervals. Translating this to the number of matches per day, we see the
                            result as depicted in Figure 8-13.


                 8.6        Summary and reflections
                            In this chapter, we have described the prediction results obtained by
                            comparing and using the prediction strategies defined in Chapter 7. We used
                            two independent real-world data sets, the CoSphere data set (Chapter 6)
                            and the Rice data set, to get these results. A summary of these results and a
                            number of reflections is given below.

                            The bestll strategy is preferred in most cases
                            The main conclusion from this chapter is that the bestll strategy is in
                            most cases (i.e., for most event set combinations and metrics) the best
                            strategy of those identified in Chapter 7. This is true for the cross validation
                            comparison as well as the evolution comparison. More precisely, the
                            bestll strategy is preferred for cases when we have a large set of events of
164   CHAPTER 8                                               PREDICTION RESULTS



      interest being predicted by a large set of preceding events. For the metrics
      mse   and mape, the lastcondr strategy performs equal to bestll, and
      surpasses it in case of highly frequently occurring events of interest and
      preceding events. In that case, however, the prediction evolution shows that
      the performance of all strategies is not very much different.
          Using a preceding occurrence of an event to predict the next occurrence
      of this event does not provide a good prediction, not for the relative nor for
      the period case. Additionally, when comparing the periodic predictors with
      the relative predictors, none of these two predictor categories have a high
      prevalence over the other. Note that we have used all events in the data set:
      we did not make a distinction between week days and weekend day, or
      other similar distinctions, which may have substantial impact on the density
      estimates. Making this distinction may result in a significant performance
      difference between relative and periodic predictors. Related to this, we have
      used the same 24 hours period throughout this chapter for periodic
      predictors. Perhaps, certain patterns in the stream have a periodicity
      different from a single day, for instance a periodicity of one week.
      Identifying the periodicity of these patterns – preferably directly from the
      data – may help to calculate better predictors.

      More data on infrequent events provides better predictions
      Under cross validation using the bestll strategy, there is a clear trend that
      using a larger number of predictors, including those predictors that occur
      infrequently, results in a better prediction performance given a fixed set of
      events of interest. The effect of a possible lack of predictor stability does
      not seem to play an important role: in most cases, events that occur
      infrequently are also useful to take into account.

      Cross-technology information improves the prediction performance
      When considering cross-technology prediction with the bestll strategy we
      found the following two results (based on the cellular, 802.11 and
      Bluetooth events in the CoSphere data set). First, using more types of
      network events increases the prediction performance of sets combining
      events from arbitrary technology types. In individual participant cases
      however, this is not always the case. And second: in general, events from the
      same technology contribute most to increasing the prediction performance.
      Again, this is not always true for individual participant cases. So, when
      deciding to collect or not collect events of a certain network type, there are
      two rules of thumb to apply upfront, although it is understood that this is
      not always best for individual cases. For a better indication of the influence
      of events of different network types, it is necessary to measure performance
      at the individual level.
SUMMARY AND REFLECTIONS                                                     165




Reflections
It is important to note that the above results are based on using two real
world data sets. Although collected at different geographical locations, they
can not represent what is observed by a very large population. Therefore,
we can not assume that these results hold for all possible network event
streams collected on personal mobile devices.
    We calculated the prediction performance based on event sets with a
broad range of events, and have not focused on individual events. It is
unlikely that single applications require visibility predictions for all possible
events. In addition, we used a set of measurement points with a distinct
distribution for the time between the measurement points and the to-be-
predicted events, and have not investigated the effect of changing this
distribution (for instance, by varying λ ). Ultimately, the prediction
performance is application specific, because the application determines at
which points in time predictions are necessary and which (types of) events
are important.
    For the results on varying event sets and cross-technology influence, we
have used the bestll strategy. These results are therefore valid for this
strategy only: other prediction methods may obtain different outcomes.
    It is clear that the computational costs of our approach will become very
high in case of a long stream with many different events. This is not a
hypothetical situation, because the gathering of data may take place on a
continuous basis, following device owners for many months or even years.
We have used a number of optimizations here, but we see many additional
possibilities to reduce the computation time, a few of which we indicate
here. A good starting point may be to investigate which historical data is still
relevant: the habits of persons change over time so it makes sense to reduce
the historical length of the stream. Another is to carefully choose which
smoothing parameters to calculate at which moment. Some event pair sets
are large and will not influence the smoothing parameters if the set gains a
few extra pairs. Other sets have few observations, which require smoothing
parameter recalculation for every new pair, but fortunately smoothing
parameters based on these small sets are not expensive to calculate.

This chapter has focused on network visibility events. Given the increasing
number of sensors in mobile devices, such as GPS receivers and
accelerometers, the integration of data from all these event sources –
including network interfaces – into a single stream may provide additional
benefits. Much in the same way as cross-technology information helps to
predict events, cross-sensor information may do the same. This can benefit
both sides: the network visibility events are predicted better when including
166   CHAPTER 8                                           PREDICTION RESULTS



      other sensor data, and the sensor data events are predicted better using
      network visibility information. Overall, we see a great future for the
      personal mobile device as a versatile sensing platform.
                                                                  Chapter

                                                                            9
9. Conclusions
      The heterogeneous and dynamic network resource state existing on mobile
      devices results in a number of challenges which we addressed in this
      dissertation. The first challenge is the need for a flexible network resource
      abstraction, supporting adaptive applications to get a cross-layer view of the
      network resources available on a device, in a manner that does not flood
      them with too many details. The second challenge is the need for a unifying
      mechanism for network resource state update and control, that lets adaptive
      applications receive cross-layer state notifications and lets them control this
      state through a single API, without relying on link-layer specific APIs (but
      in conjunction with the Socket API). The third challenge is the prediction of
      the visibility of (wireless) networks and individual network entities such as
      base stations and access points, given their visibility as observed in the past.
      Knowing the future availability or inavailability of network resources can
      greatly benefit the application’s functionality and performance.
          In this chapter, we provide an overview of the conclusions drawn in the
      previous chapters. In Section 9.1, we summarize the contributions of this
      dissertation. Section 9.2 puts our work into perspective by reflecting on the
      results and discussing limitations. Finally, in Section 9.3 we provide an
      outline of possibilities for future work.


9.1   Contributions
      To provide the required awareness and control over network resources to
      applications on mobile devices and to forecast the visibility of these network
      resources, this dissertation has made the following contributions.
168         CHAPTER 9                                                       CONCLUSIONS



      9.1.1 Network resource model and abstraction layer

            Application analysis (Chapter 3)
            An analysis of different kinds of applications on personal mobile devices
            assessed their needs to be aware of and have control over locally available
            network resources. This analysis showed that different levels of cross-layer
            awareness and control are necessary: for some applications, the standard
            transport layer abstraction suffices, while other applications need to interact
            with functionality offered by the network and link layer. This is a departure
            from the layered protocol model, which prescribes that applications use
            interfaces to the transport layer only.

            Network resource model (Chapter 3)
            We formulated a network resource model (NRM) dedicated to flexibly
            express the state of network resources on personal mobile devices for the
            benefit of applications running on these devices. This includes a definition
            of this model suitable to describe resources for common mobile devices.
            The NRM essentially is a type hierarchy, which supports taking a view on
            the state with a variable level of detail.

            Network abstraction layer (Chapter 4)
            A network abstraction layer (NAL) using the above network resource model
            was defined, being a middleware facility notifying mobile applications of
            network resource state changes and allowing them to influence this state.
            Additionally, a reference design of this facility, targeting common mobile
            devices, was provided.

            Evaluation of the NRM and NAL (Chapter 5)
            The NRM and NAL were evaluated, based on a real world audio streaming
            application, using the reference NRM and a NAL implementation on a
            Windows CE device. We showed that a NAL implementation can be
            lightweight (i.e., consumes few computing resources) and that it can be
            easily deployed for this application. Furthermore, we showed that the
            offered abstraction is appropriate for this application. The NAL
            implementation is available for downloading at [25].

      9.1.2 Network event prediction based on best predictor selection

            Trial data (Chapter 6)
            A user trial, gathering network traces for 12 participants over a period of
            approximately one month, using the NAL reference implementation (the
            CoSphere trial), was executed. This trial showed that it is possible to
      REFLECTIONS AND LIMITATIONS                                               169



      simultaneous collect state information from three different wireless
      network interfaces: cellular, 802.11 and Bluetooth. The data provided
      insight into the richness and dynamics of the visibility of wireless networks
      from the perspective of a personal mobile device. The full data set is
      available for downloading at [26].

      Visibility prediction method based on best predictor selection (Chapter
      7)
      We defined a prediction method to forecast the next future occurrence that
      a network entity will be in range or out of range, using the occurrence of
      already happened visibility events as predictors. In case of multiple
      preceding events, the method selects one of them as best predictor. It
      defines five strategies to select the best predictor amongst the set of valid
      predictors. Although used here for network resource prediction, this
      method has applicability to a broader range of problems that require
      predicting future events occurrences in an event stream.

      Prediction results (Chapter 8)
      We generated prediction results for our prediction method using the data
      from the executed trial (CoSphere) and the data from another publicly
      available data set (Rice). The following results were obtained:
      – Using a cross validation approach on large portions of the data set and a
          particular set of measurement points to calculate the performance, we
          showed that in most cases the strategy selecting the best predictor based
          on the highest mean likelihood is the best strategy.
      – We found that including predictors of infrequently visible network
          entities results in better predictions using the best strategy (i.e., more
          data results in better predictions).
      – Cross-technology information in most cases improves the prediction
          performance. Or, in other words, to predict the visibility of entities of a
          single network technology, such as 802.11 access points, it helps to use
          the visibility of other types of entities such as cellular and Bluetooth
          entities.


9.2   Reflections and limitations
      We now reflect on the results presented in this dissertation, and summarize
      limitations of our approach on dealing with network resources on personal
      mobile devices.
170   CHAPTER 9                                                             CONCLUSIONS



      Future network interface configurations on mobile devices
      The approach we proposed here is based on the assumption that mobile
      applications require influence over the network resources used to connect
      to the internet. In case of multiple available networks, an application may
      choose to select the one that best matches the application needs. Likewise,
      given the probability of having access to a preferred network in the future,
      an application may decide to advance or postpone data transfer.
          The current state of network technology is such that high-end personal
      mobile devices are equipped with multiple network interfaces, because the
      different technologies such as 3G cellular and 802.11 have sufficiently
      different characteristics in terms of bandwidth, coverage, monetary costs
      and power consumption to justify such configuration. However, as network
      technologies evolve, cellular networks may become sufficiently fast to
      support the majority of applications, and monetary cost differences may
      disappear when assuming that many users have flat-rate cellular
      subscriptions.
          In such a case, we may return to a more classical configuration, with a
      single network interface which supports virtually continuous connectivity to
      the internet: a configuration that does not require a sophisticated cross-
      layer facility as proposed here. We realize that the future applicability of our
      middleware depends on the evolution of network interface configurations, influenced
      by technology as well as business aspects. Obviously, other reasons than
      speed and monetary costs may play a role as well.

      Proposed methods operate within the current internet infrastructure
      The challenges tackled here all relate to the architecture of the current
      internet and the inherent problems it has with node mobility. For instance,
      to force outgoing traffic for a TCP socket over a preferred network in a
      multi-homed situation, we use knowledge about IP addresses assigned to
      the local network interfaces. By binding a local address to the socket, the
      outgoing traffic for this socket goes over the preferred interface (and hence
      the preferred network) (see also the discussion in Section 4.3.2).
          This shows that we work with the limitation of inter-layer dependencies
      (TCP relying on IP addresses to identify connections [17]) as well as the
      limitation of the IP address having both a locator role and an identifier role
      [8]. We are aware of ‘clean slate’ initiatives [37] that argue for a complete
      new architecture that better addresses the aspects of mobility, which may
      take away part of the problems we considered. However, our challenges
      concern applications and systems that operate with the existing internet infrastructure
      now and in the foreseeable future.
REFLECTIONS AND LIMITATIONS                                                    171



Types of future applications
Although we have provided an analysis of application requirements for
cross-layer information and control, and have argued for the usefulness of
network visibility predictions there remains some uncertainty about the kinds of
applications that will emerge on the personal mobile device platform, mainly because
this platform is evolving so quickly at this moment. Eventually, the types of
applications will give direction to the detailed features of the NRM and
NAL, and will determine whether it makes sense to forecast network
resources (i.e., whether the forecasting makes sense in terms of benefits
versus costs, and whether the events of interest for these applications can be
predicted sufficiently accurate).

Limitations of NRM and NAL
Now follow more detailed observations on limitations of the NRM and
NAL (which were already partially addressed in the Chapters 3-5).
    The reference NRM we used for evaluation has a number of
shortcomings. It does not fully represent all the features and details of the
included protocols and stack functionalities, because adding these represent
an effort that goes beyond the work of this dissertation. Furthermore, some
protocols and technologies that currently have a limited role in mobile
systems and wireless networks are missing (such as HIP and WiMAX). As
these become more widely used, they must be added to the NRM.
    The NAL defines an ioctl mechanism to manage network resources,
which we have not further investigated with respect to the possibilities to
define abstract, technology independent operations. Also, the NAL
implementation offers functionality to obtain a complete overview of all
available network resources, which implies that scanning on network
interfaces is a continuous process. Scanning, however, comes at a cost
(CPU cycles, power consumption, etc.) which is often undesirable or even
unacceptable. We have not included features in the NAL mechanism to deal
with this efficiently and do not provide application control over the
intensity to execute scanning. One partial solution is to only collect the
state (and therefore execute scanning operations) of those resources that
clients subscribe to.
    The evaluation of the NRM and NAL (Chapter 5) is based on a single
application, which makes it difficult to generalize the results of this
evaluation. Although not part of this evaluation, the NRM and NAL have
been used in the trial (Chapter 6) and also in a healthcare experiment [90],
which shows that the NAL can be used in other scenarios and environments
than the streaming application in the evaluation.
172   CHAPTER 9                                                        CONCLUSIONS



      Limitations of event prediction approach
      The following observations concern limitations of the event prediction
      approach (Chapters 6-7).
          The obtained prediction results are based on the visibility data for a
      limited set of users (two data sets with a total of 21 participants) and
      collected for a limited amount of time (approximately 1 month for both
      data sets). Most participants can be considered above average users of
      mobile and wireless technologies, work in offices, and live in a western-
      world country and culture. This data can therefore not be considered
      representative for a large population: when interpreting the results, we must
      keep this in mind.
          Our approach for event prediction is computationally demanding, and
      only tractable when using a limited number of events which occur relatively
      sparsely. However, the computing capacity of mobile devices continues to
      grow exponentially, making these kinds of calculations more feasible.
      Obviously, calculating the density parameters in our approach – the most
      demanding part – may be executed by a back end service without requiring
      real-time results (i.e., the mobile device uses cached parameters until
      updated results become available). Calculating predictions using these
      parameters may be executed locally, as they require less computing
      resources, but likewise may be executed by a back end if the cost of local
      calculation is higher than the combined cost of communicating with the
      back end and calculation at the back end. Note that although we have used
      a few improvements to reduce the calculation load, it is likely there is plenty
      opportunity for further improvement.
          Part of the prediction relies on time values relative to a taken periodicity
      of the stream. We have used a period of a single day (24 hours), assuming
      that at least a part of the user behavior repeats at daily intervals. The period
      duration, however, is an input parameter to our prediction method: we do
      not provide means to derive this period directly from the data. Other
      approaches such as described in [62] may be used to derive dominant
      periodicity patterns in the data, and use these data-derived durations as
      input to our method.
          Likewise, as an input to calculating smoothing parameters for event
      occurrence densities, we have selected basic network entities such as base
      stations, access points and individual network nodes. For some applications,
      it is necessary to predict the events associated with the visibility of the
      aggregated network (instead of the individual entities of that network) such
      as the visibility of a complete 802.11 network in contrast to the visibility of
      individual 802.11 access points. It may be possible to unite the probabilities
      of individual events into the probability of the aggregated network, but this
      requires multiple remaining waiting time calculations. Alternatively, it is
      possible to recalculate the smoothing parameters, but this can not be done
      FUTURE WORK                                                                173



      on the fly. In our approach we assume that the designer of the application
      specifies which events to predict and selects the set of preceding events as
      predictors.


9.3   Future work
      We have identified the following items as topics for future work. The first
      three items clearly extrapolate the existing work, while the other items
      focus on longer-term lines of research.

      Incorporate prediction data into the NRM and NAL
      In this dissertation, we have treated the current state notification and
      control separate from the prediction of network visibility. Joining these two
      aspects, such that the prediction results are directly coupled to the NRM
      data types and prediction updates are communicated through the NAL, is
      beneficial from a number of viewpoints. The prediction approach requires
      as input visibility events in time, which can be delivered by the NAL; joining
      these aspects is therefore sensible from this perspective. An important
      advantage is that applications need not map between identifiers used by the
      NAL and identifiers used by the prediction service, if these were available as
      separate services. Furthermore, applications may express interest in (i.e.,
      subscribe to) information about wireless networks that have certain
      statistical and probabilistic characteristics, such as the average time spent in
      range per day – information which is currently not defined in the NRM.
          The following three issues must be resolved to incorporate prediction
      data into the NRM and NAL. 1) The NRM data types must be extended to
      accommodate prediction information. 2) We must find a way to express
      interest in the prediction of one or more visibility events through the NAL
      interface, possibly by extending the existing NAL subscription mechanism.
      3) Furthermore, it seems apt to provide statistical views on the visibility
      data gathered in the past.

      Dealing with incomplete data
      An interesting problem is that of dealing with partial visibility information
      collected from the network interfaces. Visibility traces may not be
      complete, because of the cost associated with executing wireless scans: to
      reduce the power consumption, for instance, a NAL implementation may
      be forced to selectively scan. Our prediction approach, however, assumes
      that the history of entity visibility does not contain gaps in the observation.
      Obviously, a solution to this problem is to filter out those event pairs that
      have an observation gap between the times of the occurrences of the events
      (something we did to sanitize the trial data, which contained short gaps due
174   CHAPTER 9                                                      CONCLUSIONS



      to device resets and software errors). However, if done on a large scale, this
      results in a substantial reduction of the number of event pairs to use as
      input for the density parameter calculation, and therefore is likely to result
      in a decrease of the prediction performance.
          Several aspects play a role in properly handling incomplete data. A
      starting point may be to carefully consider the prediction needs of the
      involved applications and only collect data for events the application is
      interested in, and only do this at times that the application needs these
      predictions. If, for instance, an application only requires forecasts in the
      morning, data collection may be halted at other periods during the day.
      Another approach is to substantially reduce data collection for those events
      for which we already have a lot of historical data. In that case, additional
      observations only marginally change the density parameters, and therefore
      the prediction itself. Finally, an approach may be to stop collecting data for
      event pairs that have a limited time correlation – where the preceding event
      has little forecasting power for the event of interest. This has as additional
      benefit that the set of possible predictors is reduced.

      Applying prediction results
      The prediction results (Chapter 8) have focused on the aggregated results of
      a broad range of events in the data sets. We realize that we have not focused
      on the prediction performance of specific cases, for instance the
      performance of predicting the arrival into the range of the participant’s
      home 802.11 networks, and the change of this prediction performance
      throughout the day. Exploring the predictability for specific applications
      may contribute to understanding in which cases and under which
      circumstances tracing visibility data is useful, and therefore is recommended
      as future work.
          Network visibility events provide a view on the dynamic context of the
      person carrying the mobile device. This rich view can be used for more than
      network resource usage and prediction, because entities often mark a
      geographical location – when they are stationary – or are associated with
      the closeness of other persons. Data about the contacts between people can,
      for instance, be used to find dynamics in social networks [49]. Or traces of
      cellular and 802.11 entity visibility help to identify meaningful locations
      [89]. For these kinds of applications, forecasting may play an important
      role, and applying prediction methods as proposed here may support this
      prediction.

      Cognitive networks
      The research domain of ‘cognitive networking’ focuses on applying
      cognitive approaches to problems in networking. Cognitive networks are
      adaptive and learn to optimize their operation over time, using machine
FUTURE WORK                                                              175



learning methods and techniques [31]. The initiating vision described in
[22] proposes a computer network management facility, called the
Knowledge Plane, responsible for adaptively tuning the operation of a
network infrastructure. Important tasks in cognitive networks are anomaly
detection, fault diagnosis, intruder detection, network configuration and
network optimization.
    Although our focus is on mobile multi-homed nodes residing on the
outmost edges of the network, the challenges addressed here can be
regarded as cognitive networking problems. The prediction results help to
configure network resources and optimize the usage of these resources over
time. Furthermore, the trial data can be used to identify patterns in
network resource availability and usage. However, it is clear that our work
covers only a small fraction of the cognitive networking domain, and is
especially lacking in the aspects of self adaptation and self tuning (i.e.,
without requiring explicit application interaction). As we indicate in [95],
we consider these aspects an exciting direction for future research.
    When focusing on adapting to the dynamic network environment of a
single personal mobile device, we may find mechanisms that apply to a
larger set of personal devices and services under the control of the user,
interconnected by a ‘personal network’ [86][58]. A personal network
interconnects personal devices and services in close vicinity of the user, but
also those that are farther away, such as equipment at home, in a person’s
car, and work-related devices. Keeping these devices efficiently connected
in a highly dynamic environment is a major challenge, and is certainly not
feasible with manual configuration, especially when considering that the
average user has little knowledge about data networks. Cognitive networking
techniques may therefore significantly improve the operation of personal
networks.

Mobile device as large-scale sensing platform
More and more people carry powerful computing devices with them on a
nearly continuous time basis, mostly in the form of personal devices such as
advanced mobile phones (at the end of the year 2007, approximately half of
the world population has a mobile phone [57]). These personal computing
devices often contain a rich set of different sensors that can be used to
almost continuously perceive the surroundings of the owner. The data we
collected by monitoring network interfaces shows the possibility of
capturing relevant features such as owner mobility, network location, and
social interaction. Other more recently deployed sensors register light,
acceleration, device touch, geographical location and orientation and
limited audio and video. The true revolution of this development lies in the
fact that, for the first time in history, we have a computing platform capable
of sensing the direct environment of a substantial part of the world
176   CHAPTER 9                                                       CONCLUSIONS



      population. This platform is not only capable of enhancing the perception
      of individuals by sensing beyond what is possible with the human senses,
      but also facilitates the easy sharing of these perceptions by means of
      ubiquitous data network technologies.
          An exciting direction of future research is to explore the possibilities to
      deliver an accurate world model to personal computing devices based on
      the perception of this world by a large cooperating group of devices [97].
      Such a world model is important to many applications, as a primary input
      or as a source for enhancement of existing functionality. For instance, it
      may reliably tie stationary objects to geographical locations (a spatial
      feature) and it may reflect that a main road has been blocked in a certain
      direction because the associating frequently traveled pattern, represented by
      a common sequence of observations in time, suddenly is not used anymore
      (a temporal feature). By sharing the perception of the world between peers
      in the group, it may be possible to 1) increase the accuracy of the
      perception as taking place on a single device – by taking into account what
      is perceived as common between devices – as well as 2) to provide a model
      of environments that are new to an owner and have not been observed in
      the past, drawing solely on what has been sensed by others.
          A fundamental question is how to represent such a model so that it can
      be stored on, used by, and exchanged between computing devices. It must
      be able to accommodate the different kinds of data coming from the
      sensors and the fused data from multiple sensors. Also, it must be capable
      to capture spatio-temporal aspects as well as capture uncertainty. A possible
      approach is to detect elementary patterns directly derived from simple
      sensor information such as the concurrent occurrence of sensor values
      (spatial) or the strong correlation between occurrences of sensor events in
      time (temporal), and that is capable of generating knowledge at higher
      levels of abstraction.
          Another important question is the impact of the distribution of
      perception data between mobile peers on the timeliness and accuracy of
      shared data available on individual mobile devices. A primary aspect is the
      safeguarding of the privacy of individuals in a group of participants and the
      protection against the insertion of corrupt or false data by an – intentionally
      or unintentionally – rogue participant. As a consequence, it may be
      appropriate to rely on peer-to-peer (P2P) distribution mechanisms, also
      applied in various forms in internet file sharing, because a fully distributed
      P2P mechanism lacks a centralized role which may easily compromise
      privacy.

      Bridging between probabilistic data and application logic
      When observing sensory events on mobile devices such as the availability of
      networks, we likely are able to identify event patterns without being able to
FUTURE WORK                                                             177



assign specific semantics to these patterns. These patterns, however, may
serve as triggers for actions to be executed by applications. For instance,
when two Bluetooth nodes are observed in order, the user establishes with a
high probability a connection to his television. When this pattern is
observed often, the device may anticipate this behavior and already establish
the connection upfront – without assigning meaning to seeing the two
Bluetooth nodes in order.
    An open question is how to accommodate this kind of functionality,
which is capable of matching identified probabilistic data with application
logic. This question is relevant for cognitive networks and large scale
cooperative sensing on mobile phones (the two previous future work
topics), but also for using sensor data in general.
                                                             Appendix

                                                                         A
A. Network Resource Model Schema
   This appendix describes the full Network Resource Model (Chapter 3) in
   XML Schema.


   <?xml version="1.0"?>

   <!-- Network Resource Model (NRM) -->

   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns="http://cosphere.telin.nl/nrm/nrm-types"
              targetNamespace="http://cosphere.telin.nl/nrm/nrm-types"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified">


     <!-- ================================================================== -->
     <!-- Identifier types. -->
     <!-- ================================================================== -->

     <xs:simpleType name="Id">
       <xs:restriction base="xs:unsignedInt"/>
     </xs:simpleType>

     <xs:simpleType name="TypeId">
       <xs:restriction base="xs:string"/>
     </xs:simpleType>

     <!-- ================================================================== -->
     <!-- Basic (abstract) types describing link layer functionality -->
     <!-- ================================================================== -->

     <!-- Link layer elements describe characteristics of functionality at the
     physical and link layer; deal with transferring bits and frames over one
     or more links. Typically, these elements are network interface cards with
     associating driver software or virtual network interfaces. If state is 0,
     the link layer element is down, if 1 it is up. -->
     <xs:complexType name="LinkLayerElement" abstract="true">
       <xs:sequence>
         <xs:element name="linkLayerElementId" type="Id"/>
         <xs:element name="name" type="xs:string"/>
         <xs:element name="descr" type="xs:string"/>
180   APPENDIX A                              NETWORK RESOURCE MODEL SCHEMA



           <xs:element name="state" type="xs:unsignedInt" default="0"/>
         </xs:sequence>
       </xs:complexType>

       <!-- A physical interface represents a hardware network interface (and
         associating driver software). Types deriving from this type must indicate
         available links (derived from Link) that have a corresponding
         technology type, e.g. an IEEE 802.11 interface referring to IEEE 802.11
         links. -->
       <xs:complexType name="PhysicalInterface" abstract="true">
         <xs:complexContent>
           <xs:extension base="LinkLayerElement">
             <xs:sequence>
               <xs:element name="links">
                 <xs:complexType>
                    <xs:sequence>
                      <!-- Reference to type (derived from) Link. -->
                      <xs:element name="link" type="Id"
                        minOccurs="0" maxOccurs="unbounded"/>
                    </xs:sequence>
                 </xs:complexType>
               </xs:element>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- A virtual interface represents a logical element that can act as a
         link layer element but does not map directly to a hardware component.
         In most cases, a virtual interface uses another link layer element for
         the actual transfer of data. -->
       <xs:complexType name="VirtualInterface" abstract="true">
         <xs:complexContent>
           <xs:extension base="LinkLayerElement">
             <xs:sequence>
               <xs:element name="baseInterfaces">
                 <xs:complexType>
                   <xs:sequence>
                     <!-- Reference to type (derived from)
                       LinkLayerElement. -->
                     <xs:element name="baseInterface" type="Id"
                       minOccurs="0" maxOccurs="unbounded"/>
                   </xs:sequence>
                 </xs:complexType>
               </xs:element>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- Link layer data link, responsible for carrying bits and frames, and
       established by a link layer element (derived of LinkLayerElement).
       When a link is active (state is 1), it can be used to setup a network layer
       path. A link can have multiple associated services; facilities supporting
       communication, not necessarily confined to the link layer (deriving from
       LinkService). -->
       <xs:complexType name="Link" abstract="true">
         <xs:sequence>
           <xs:element name="linkId" type="Id"/>
           <!-- Reference to type (derived from) LinkLayerElement -->
           <xs:element name="ifId" type="Id"/>
APPENDIX A                                                                     181



     <xs:element name="state" type="xs:unsignedInt" default="0"/>
     <xs:element name="services">
       <xs:complexType>
         <xs:sequence>
           <!-- Reference to type (derived from) LinkService -->
           <xs:element name="service" type="Id"
             minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>
     <xs:element name="maxSpeed" type="xs:unsignedInt"/>
     <xs:element name="mtu" type="xs:unsignedInt"/>
   </xs:sequence>
 </xs:complexType>

 <!-- Service associated with a link layer link. Such a service could be
 a DNS server, proxy server, transcoding service, IP routing facility,
 etc. that is associated with a link, typically because it is only
 accessible through this link. Note that this service is not limited
 to link layer functionality. Information about the existence of this
 service is obtained through such protocols as the Dynamic Host
 Configuration Protocol (DHCP). -->
 <xs:complexType name="LinkService" abstract="true">
   <xs:sequence>
     <xs:element name="linkServiceId" type="Id"/>
   </xs:sequence>
 </xs:complexType>


 <!-- ================================================================== -->
 <!-- Basic (abstract) types describing network layer functionality -->
 <!-- ================================================================== -->

 <!-- Network layer elements describe characteristics of functionality at
 the network layer. They deal with paths (or routes) of network packets,
 which by themselves are concatenated links. Types derived from this type
 must indicate available paths (derived from Path) corresponding with
 their own type, e.g. an IPv4 stack referring to IPv4 paths. Without
 additional parameterization, outgoing packets will be send over the
 default path.-->
 <xs:complexType name="NetworkLayerElement" abstract="true">
   <xs:sequence>
     <xs:element name="networkLayerElementId" type="Id"/>
     <xs:element name="name" type="xs:string"/>
     <xs:element name="descr" type="xs:string"/>
     <xs:element name="routes">
       <xs:complexType>
         <xs:sequence>
           <!-- Reference to type (derived from) PathSegment. -->
           <xs:element name="route" type="Id"
             minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>
     <!-- Reference to type (derived from) PathSegment. -->
     <xs:element name="defaultRoute" type="Id" minOccurs="0"/>
   </xs:sequence>
 </xs:complexType>

 <!-- Network layer path segment, indicating one hop of a route taken by
 network layer packets. A path segment always has a one-to-one mapping with
182   APPENDIX A                              NETWORK RESOURCE MODEL SCHEMA



       a link layer link (derived from Link). -->
       <xs:complexType name="PathSegment" abstract="true">
         <xs:sequence>
           <xs:element name="pathSegmentId" type="Id"/>
           <!-- Reference to type (derived from) Link. -->
           <xs:element name="link" type="Id"/>
         </xs:sequence>
       </xs:complexType>

       <!-- A local path segment can be used to establish routes to nodes
       available directly through the used link (nodes on the same local
       network). A local path segment is - at one end - always attached to the
       current host. -->
       <xs:complexType name="LocalPathSegment">
         <xs:complexContent>
           <xs:extension base="PathSegment">
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- A gateway path segment can be used to establish routes to nodes
       available directly through the used link as well as nodes that are more
       than one hop away. Paths to non-local nodes are established through the
       gateway. A gateway path segment is - at one end - always attached to the
       current host. -->
       <xs:complexType name="GatewayPathSegment">
         <xs:complexContent>
           <xs:extension base="PathSegment">
             <xs:sequence>
               <xs:element name="gateway" type="Id"/>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>


       <!-- ================================================================== -->
       <!-- Basic (abstract) types describing transport layer functionality -->
       <!-- ================================================================== -->

       <!-- Transport layer elements describe characteristics of functionality at
       the transport layer. These elements deal with communication over end-to-end
       connections (or channels, or pipes). The data over the end-to-end
       connection travels through one or more network layer paths. Types derived
       from this type must indicate existing transport layer links (derived from
       Transport) corresponding with their own type, e.g. a TCP stack referring
       to TCP connections. -->
       <xs:complexType name="TransportLayerElement" abstract="true">
         <xs:sequence>
           <xs:element name="transportLayerElementId" type="Id"/>
           <xs:element name="transports">
             <xs:complexType>
               <xs:sequence>
                 <!-- Reference to type (derived from) Transport. -->
                 <xs:element name="transport" type="Id"
                   minOccurs="0" maxOccurs="unbounded"/>
               </xs:sequence>
             </xs:complexType>
           </xs:element>
         </xs:sequence>
       </xs:complexType>
APPENDIX A                                                                     183



 <!-- Transport layer transport, responsible for end-to-end data
 transmission. Types derived from this type must indicate which one or
 more paths (derived from PathSegment) are used for the connection. -->
 <xs:complexType name="Transport" abstract="true">
   <xs:sequence>
     <xs:element name="transportId" type="Id"/>
     <!-- Reference to type TransportLayerElement. -->
     <xs:element name="stack" type="Id"/>
   </xs:sequence>
 </xs:complexType>


 <!-- ================================================================== -->
 <!-- Specific (real) types describing link layer functionality -->
 <!-- ================================================================== -->

 <!-- Cellular interface. Multiple networks may be visible but only one
 can be active at a given time. This interface may support multiple modes
 (GPRS = 1, EDGE = 2, CDMA2000_RTT = 3, UMTS = 4) of which one is currently
 used. -->
 <xs:complexType name="CellularInterface">
   <xs:complexContent>
     <xs:extension base="PhysicalInterface">
       <xs:sequence>
         <xs:element name="currentMode" type="xs:unsignedInt"/>
         <xs:element name="supportedModes" maxOccurs="4">
           <xs:complexType>
             <xs:sequence>
               <xs:element name="supportedMode" type="xs:unsignedInt"/>
             </xs:sequence>
           </xs:complexType>
         </xs:element>
         <!-- Reference to type (derived from) CellularNetwork. -->
         <xs:element name="activeLink" type="Id" minOccurs="0"/>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- Cellular network base station. Indicates cell id, location area code,
 and received signal strength indication. -->
 <xs:complexType name="BaseStation">
   <xs:sequence>
     <xs:element name="cid" type="xs:unsignedInt"/>
     <xs:element name="lac" type="xs:unsignedInt"/>
     <xs:element name="rssi" type="xs:int"/>
   </xs:sequence>
 </xs:complexType>

 <!-- Cellular network. The baseStation indicates currently used base
 station and baseStationList indicates all detected base stations in
 range for this operator. -->
 <xs:complexType name="CellularNetwork">
   <xs:complexContent>
     <xs:extension base="Link">
       <xs:sequence>
         <xs:element name="operatorName" type="xs:string"/>
         <xs:element name="operatorNumber" type="xs:unsignedInt"/>
         <xs:element name="baseStation" type="BaseStation"/>
         <xs:element name="baseStationList">
184   APPENDIX A                              NETWORK RESOURCE MODEL SCHEMA



                 <xs:complexType>
                   <xs:sequence>
                     <xs:element name="baseStation" type="BaseStation"
                       minOccurs="0" maxOccurs="unbounded"/>
                   </xs:sequence>
                 </xs:complexType>
               </xs:element>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- Interface representing IEEE 802.11 Wireless LAN physical and MAC
       layer functionality. Multiple links (i.e. WLAN networks) may be accessible
       through this interface, although only one may be active at a given time.
       This interface may support multiple modes (802.11a = 1, 802.11b = 2,
       802.11g = 3) of which one is currently used. -->
       <xs:complexType name="WLANInterface">
         <xs:complexContent>
           <xs:extension base="PhysicalInterface">
             <xs:sequence>
               <xs:element name="currentMode" type="xs:unsignedInt"></xs:element>
               <xs:element name="supportedModes">
                 <xs:complexType>
                   <xs:sequence>
                     <xs:element name="supportedMode" type="xs:unsignedInt"
                       maxOccurs="3"/>
                   </xs:sequence>
                 </xs:complexType>
               </xs:element>
               <!-- Reference to type (derived from) WLANNetwork. -->
               <xs:element name="activeLink" type="Id" minOccurs="0"/>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- WLAN network access point. Indicates access point mac address (bssid),
       and received signal strength indication (rssi). -->
       <xs:complexType name="AccessPoint">
         <xs:sequence>
           <xs:element name="bssid" type="xs:string"/>
           <xs:element name="rssi" type="xs:int"/>
         </xs:sequence>
       </xs:complexType>

       <!-- Representation of an IEEE 802.11 Wireless LAN network. -->
       <xs:complexType name="WLANNetwork">
         <xs:complexContent>
           <xs:extension base="Link">
             <xs:sequence>
               <xs:element name="ssid" type="xs:string"/>
               <xs:element name="accessPoint" type="AccessPoint"/>
               <xs:element name="accessPointList">
                 <xs:complexType>
                   <xs:sequence>
                     <xs:element name="accessPoint" type="AccessPoint"
                       minOccurs="0" maxOccurs="unbounded"/>
                   </xs:sequence>
                 </xs:complexType>
               </xs:element>
APPENDIX A                                                                  185



       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- Bluetooth node. Indicates Bluetooth device address (BD_ADDR) and
   the user-friendly name. -->
 <xs:complexType name="BluetoothNode">
   <xs:sequence>
     <xs:element name="BD_ADDR" type="xs:string"/>
     <xs:element name="name" type="xs:string"/>
   </xs:sequence>
 </xs:complexType>

 <!-- Interface representing Bluetooth physical and link layer functionality.
 Multiple potential links to other Bluetooth nodes may be visible through
 this interface and multiple links may be active. -->
 <xs:complexType name="BluetoothInterface">
   <xs:complexContent>
     <xs:extension base="PhysicalInterface">
       <xs:sequence>
         <!-- Local node info -->
         <xs:element name="localNode" type="BluetoothNode"/>
         <xs:element name="activeLinks">
           <xs:complexType>
             <xs:sequence>
               <!-- Reference to type (derived from) BluetoothLink. -->
               <xs:element name="link" type="Id"
                 minOccurs="0" maxOccurs="unbounded"/>
             </xs:sequence>
           </xs:complexType>
         </xs:element>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- Representation of a Bluetooth link with another Bluetooth node.
 This link is not necessarily suitable for carrying IP traffic; it is
 used to inform about in-range Bluetooth nodes. -->
 <xs:complexType name="BluetoothLink">
   <xs:complexContent>
     <xs:extension base="Link">
       <xs:sequence>
         <!-- Peer node. -->
         <xs:element name="node" type="BluetoothNode"/>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- Representation of a Bluetooth network based on the Bluetooth LAN
 access profile. -->
 <xs:complexType name="BluetoothNetwork">
   <xs:complexContent>
     <xs:extension base="BluetoothLink"/>
   </xs:complexContent>
 </xs:complexType>

 <!-- Interface representing IEEE 802.3 Ethernet physical and MAC layer
   functionality. -->
186   APPENDIX A                               NETWORK RESOURCE MODEL SCHEMA



       <xs:complexType name="EthernetInterface">
         <xs:complexContent>
           <xs:extension base="PhysicalInterface">
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- Representation of an IEEE 802.3 Ethernet network. -->
       <xs:complexType name="EthernetNetwork">
         <xs:complexContent>
           <xs:extension base="Link"/>
         </xs:complexContent>
       </xs:complexType>

       <!-- Serial interface -->
       <xs:complexType name="SerialInterface">
         <xs:complexContent>
           <xs:extension base="PhysicalInterface"/>
         </xs:complexContent>
       </xs:complexType>

       <!-- Serial network. -->
       <xs:complexType name="SerialNetwork">
         <xs:complexContent>
           <xs:extension base="Link"/>
         </xs:complexContent>
       </xs:complexType>

       <!-- The loopback interface allows (applications on) the host to transmit
       data to itself. Therefore, this virtual interface does not stack on top of
       another interface. -->
       <xs:complexType name="LoopbackInterface">
         <xs:complexContent>
           <xs:extension base="VirtualInterface">
             <xs:sequence>
               <!-- Reference to type (derived from) LoopbackNetwork. -->
               <xs:element name="nwId" type="Id"></xs:element>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- Loopback network directly associated with loopback interface. -->
       <xs:complexType name="LoopbackNetwork">
         <xs:complexContent>
           <xs:extension base="Link"/>
         </xs:complexContent>
       </xs:complexType>

       <!-- Mobile IP virtual interface. -->
       <xs:complexType name="MIPInterface">
         <xs:complexContent>
           <xs:extension base="VirtualInterface">
             <xs:sequence>
               <xs:element name="tunnel" type="MIPTunnel" minOccurs="0"/>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- Mobile IP tunnel. -->
APPENDIX A                                                                     187



 <xs:complexType name="MIPTunnel">
   <xs:complexContent>
     <xs:extension base="Link">
       <xs:sequence>
         <xs:element name="pathSegment" type="GatewayPathSegment"
           minOccurs="0"/>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>


 <!-- ================================================================== -->
 <!-- Specific (real) types describing network layer functionality -->
 <!-- ================================================================== -->

 <!-- Internet Protocol version 4 stack. Many more parameters may be defined
 here: see RFC 2011. -->
 <xs:complexType name="IPv4Stack">
   <xs:complexContent>
     <xs:extension base="NetworkLayerElement">
       <xs:sequence>
         <xs:element name="forwarding" type="xs:boolean"/>
         <xs:element name="defaultTTL" type="xs:unsignedByte"/>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- Internet Protocol version 4 local path segement. -->
 <xs:complexType name="IPv4LocalPathSegment">
   <xs:complexContent>
     <xs:extension base="LocalPathSegment">
       <xs:sequence>
         <xs:element name="address" type="xs:string"/>
         <xs:element name="net" type="xs:string"/>
         <xs:element name="prefix" type="xs:unsignedByte"/>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- Internet Protocol version 4 gateway path segement. -->
 <xs:complexType name="IPv4GatewayPathSegment">
   <xs:complexContent>
     <xs:extension base="GatewayPathSegment">
       <xs:sequence>
         <xs:element name="address" type="xs:string"/>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- Internet Protocol version 6 stack. -->
 <xs:complexType name="IPv6Stack">
   <xs:complexContent>
     <xs:extension base="NetworkLayerElement"/>
   </xs:complexContent>
 </xs:complexType>

 <!-- Internet Protocol version 6 local path segment. -->
188   APPENDIX A                              NETWORK RESOURCE MODEL SCHEMA



       <xs:complexType name="IPv6LocalPathSegment">
         <xs:complexContent>
           <xs:extension base="LocalPathSegment"/>
         </xs:complexContent>
       </xs:complexType>

       <!-- Internet Protocol version 6 gateway path segment. -->
       <xs:complexType name="IPv6GatewayPathSegment">
         <xs:complexContent>
           <xs:extension base="GatewayPathSegment"/>
         </xs:complexContent>
       </xs:complexType>


       <!-- ================================================================== -->
       <!-- Specific (real) types describing transport layer functionality -->
       <!-- ================================================================== -->

       <!-- User Datagram Protocol stack. Responsible for sending and receiving
       UDP packets. Many (statistical) parameters possible: see RFC 4113. -->
       <xs:complexType name="UDPStack">
         <xs:complexContent>
           <xs:extension base="TransportLayerElement">
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- User Datagram Protocol listener. Receives incoming packets for a
       certain port number. The localPathsSegment is 0 when not bound to a
       specific IP number. -->
       <xs:complexType name="UDPListener">
         <xs:complexContent>
           <xs:extension base="Transport">
             <xs:sequence>
               <!-- Reference to type LocalPathSegment. -->
               <xs:element name="localPathSegment" type="Id"/>
               <xs:element name="port" type="xs:unsignedShort"/>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- Transmission Control Protocol stack. Responsible for creating,
       maintaining, and terminating TCP connections. Many (statistical)
       parameters possible: see RFC 2012. -->
       <xs:complexType name="TCPStack">
         <xs:complexContent>
           <xs:extension base="TransportLayerElement">
             <xs:sequence>
               <xs:element name="maxConnections" type="xs:unsignedInt"/>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- Transmission Control Protocol listener. Waits for connection
       establishment on a certain port number. The localPathsSegment is 0 when
       not bound to a specific IP number. -->
       <xs:complexType name="TCPListener">
         <xs:complexContent>
           <xs:extension base="Transport">
APPENDIX A                                                                    189



       <xs:sequence>
         <!-- Reference to type LocalPathSegment. -->
         <xs:element name="localPathSegment" type="Id"/>
         <xs:element name="port" type="xs:unsignedShort"/>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- Transmission Control Protocol connection. A TCP connection uses one
 path for incoming / outgoing packets. State indicates the local socket
 TCP state (CLOSED, SYN_SENT, ESTABLISHED, CLOSE_WAIT, etc.). -->
 <xs:complexType name="TCPConnection">
   <xs:complexContent>
     <xs:extension base="Transport">
       <xs:sequence>
         <!-- Reference to type PathSegment. -->
         <xs:element name="pathSegment" type="Id"/>
         <xs:element name="localPort" type="xs:unsignedShort"/>
         <xs:element name="remoteAddress" type="xs:string"/>
         <xs:element name="remotePort" type="xs:unsignedShort"/>
         <xs:element name="state" type="xs:unsignedInt"/>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- Stream Control Transmission Protocol stack. Responsible for creating,
 maintaining, and terminating SCTP associations/connections. -->
 <xs:complexType name="SCTPStack">
   <xs:complexContent>
     <xs:extension base="TransportLayerElement">
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- Stream Control Transmission Protocol listener. Waits for connection
 establishment on a certain port number. The localPathsSegment is 0 when
 not bound to a specific IP number.-->
 <xs:complexType name="SCTPListener">
   <xs:complexContent>
     <xs:extension base="Transport">
       <xs:sequence>
         <!-- Reference to type LocalPathSegment. -->
         <xs:element name="localPathSegment" type="Id"/>
         <xs:element name="port" type="xs:unsignedShort"/>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- Stream Control Transmission Protocol association. An SCTP connection
 uses one or more paths for incoming / outgoing packets. State indicates
 the local socket SCTP state (CLOSED, COOKIE_WAIT, ESTABLISHED,
 SHUTDOWN_PENDING, etc.).-->
 <xs:complexType name="SCTPAssociation">
   <xs:complexContent>
     <xs:extension base="Transport">
       <xs:sequence>
         <xs:element name="pathSegments" type="Id">
           <xs:complexType>
190   APPENDIX A                              NETWORK RESOURCE MODEL SCHEMA



                   <xs:sequence>
                     <!-- Reference to type PathSegment. -->
                     <xs:element name="pathSegment" type="Id"
                       minOccurs="1" maxOccurs="65536"/>
                   </xs:sequence>
                 </xs:complexType>
               </xs:element>
               <xs:element name="localPort" type="xs:unsignedShort"/>
               <xs:element name="remoteAddresses">
                 <xs:complexType>
                   <xs:element name="remoteAddress" type="xs:string"
                     minOccurs="1" maxOccurs="65536"/>
                 </xs:complexType>
               </xs:element>
               <xs:element name="remotePort" type="xs:unsignedShort"/>
               <xs:element name="state" type="xs:unsignedInt"/>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>


       <!-- ================================================================== -->
       <!-- Link associated services (DNS, proxies, gateways, etc.). -->
       <!-- ================================================================== -->

       <!-- Domain Name System service. When defaultResolver is true, this DNS
       server is used to query the DNS. -->
       <xs:complexType name="DNSServer">
         <xs:complexContent>
           <xs:extension base="LinkService">
             <xs:sequence>
               <xs:element name="address" type="xs:string"/>
               <xs:element name="defaultResolver" type="xs:boolean"/>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <!-- IP Gateway. -->
       <xs:complexType name="Gateway">
         <xs:complexContent>
           <xs:extension base="LinkService">
             <xs:sequence>
               <xs:element name="address" type="xs:string"/>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>


       <!-- ================================================================== -->
       <!-- Session definition (client-server) -->
       <!-- ================================================================== -->

       <xs:complexType name="Msg">
       </xs:complexType>

       <xs:complexType name="Instance">
         <xs:complexContent>
           <xs:extension base="Msg">
APPENDIX A                                                                   191



        <xs:choice>
          <xs:element name="CellularInterface" type="CellularInterface"/>
          <xs:element name="CellularNetwork" type="CellularNetwork"/>
          <xs:element name="WLANInterface" type="WLANInterface"/>
          <xs:element name="WLANNetwork" type="WLANNetwork"/>
          <xs:element name="BluetoothInterface" type="BluetoothInterface"/>
          <xs:element name="BluetoothNetwork" type="BluetoothNetwork"/>
          <xs:element name="BluetoothLink" type="BluetoothLink"/>
          <xs:element name="EthernetInterface" type="EthernetInterface"/>
          <xs:element name="EthernetNetwork" type="EthernetNetwork"/>
          <xs:element name="SerialInterface" type="SerialInterface"/>
          <xs:element name="SerialNetwork" type="SerialNetwork"/>
          <xs:element name="LoopbackInterface" type="LoopbackInterface"/>
          <xs:element name="LoopbackNetwork" type="LoopbackNetwork"/>
          <xs:element name="MIPInterface" type="MIPInterface"/>
          <xs:element name="IPv4Stack" type="IPv4Stack"/>
          <xs:element name="IPv6Stack" type="IPv6Stack"/>
          <xs:element name="IPv4LocalPathSegment" type="IPv4LocalPathSegment"/>
          <xs:element name="IPv4GatewayPathSegment"
type="IPv4GatewayPathSegment"/>
          <xs:element name="IPv6LocalPathSegment" type="IPv6LocalPathSegment"/>
          <xs:element name="IPv6GatewayPathSegment"
type="IPv6GatewayPathSegment"/>
          <xs:element name="UDPStack" type="UDPStack"/>
          <xs:element name="TCPStack" type="TCPStack"/>
          <xs:element name="SCTPStack" type="SCTPStack"/>
          <xs:element name="UDPListener" type="UDPListener"/>
          <xs:element name="TCPListener" type="TCPListener"/>
          <xs:element name="TCPConnection" type="TCPConnection"/>
          <xs:element name="SCTPListener" type="SCTPListener"/>
          <xs:element name="SCTPConnection" type="SCTPConnection"/>
          <xs:element name="DNSServer" type="DNSServer"/>
          <xs:element name="Gateway" type="Gateway"/>
        </xs:choice>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="InstanceId">
    <xs:complexContent>
      <xs:extension base="Msg">
        <xs:sequence>
          <xs:element name="type" type="xs:string"></xs:element>
          <xs:element name="id" type="Id"></xs:element>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>


  <xs:complexType name="MsgTransBegin">
    <xs:complexContent>
      <xs:extension base="Msg"/>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="MsgTransEnd">
    <xs:complexContent>
      <xs:extension base="Msg"/>
    </xs:complexContent>
  </xs:complexType>
192   APPENDIX A                                NETWORK RESOURCE MODEL SCHEMA



       <xs:complexType name="MsgCreate">
         <xs:complexContent>
           <xs:extension base="Instance"/>
         </xs:complexContent>
       </xs:complexType>

       <xs:complexType name="MsgUpdate">
         <xs:complexContent>
           <xs:extension base="Instance"/>
         </xs:complexContent>
       </xs:complexType>

       <xs:complexType name="MsgDelete">
         <xs:complexContent>
           <xs:extension base="InstanceId"/>
         </xs:complexContent>
       </xs:complexType>

       <xs:complexType name="MsgSubscribe">
         <xs:complexContent>
           <xs:extension base="Msg">
             <xs:choice maxOccurs="unbounded">
               <xs:element name="layer">
                 <xs:simpleType>
                   <xs:restriction base="xs:string">
                     <xs:enumeration value="transport"/>
                     <xs:enumeration value="network"/>
                     <xs:enumeration value="link"/>
                   </xs:restriction>
                 </xs:simpleType>
               </xs:element>
               <xs:element name="type" type="TypeId"/>
               <xs:element name="instance">
                 <xs:complexType>
                   <xs:sequence>
                     <xs:element name="type" type="TypeId"/>
                     <xs:element name="id" type="Id"/>
                   </xs:sequence>
                 </xs:complexType>
               </xs:element>
             </xs:choice>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <xs:complexType name="MsgIoctlCall">
         <xs:complexContent>
           <xs:extension base="Msg">
             <xs:sequence>
               <xs:element name="callid" type="xs:unsignedInt"/>
               <xs:element name="type" type="TypeId"/>
               <xs:element name="id" type="Id"/>
               <xs:element name="ioctl" type="xs:unsignedInt"/>
               <xs:element name="input" type="xs:hexBinary"/>
             </xs:sequence>
           </xs:extension>
         </xs:complexContent>
       </xs:complexType>

       <xs:complexType name="MsgIoctlResult">
APPENDIX A                                                                    193



   <xs:complexContent>
     <xs:extension base="Msg">
       <xs:sequence>
         <xs:element name="callid" type="xs:unsignedInt"/>
         <xs:element name="result" type="xs:boolean"/>
         <xs:element name="output" type="xs:hexBinary"/>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

 <!-- A client-server session uses messages for interaction. Typically, the
 following interaction takes place: 1) session is established, 2) client
 indicates interest in receiving notifications from server by sending a
 subscribe message, 3) server sends notifications on current state using
 create, updated, delete messages. The key and keyref definitions ensure
 existence and uniqueness of the various identifiers, and enforce that
 referenced elements exist. Changes (create, update, delete) always take
 place in a transaction context, i.e. a series of notifications are
 preceded by a TransBegin message and succeeded by a TransEnd message. -->
 <xs:element name="session">
   <xs:complexType>
     <xs:choice minOccurs="0" maxOccurs="unbounded">
       <xs:element name="MsgTransBegin" type="MsgTransBegin"/>
       <xs:element name="MsgTransEnd" type="MsgTransEnd"/>
       <xs:element name="MsgCreate" type="MsgCreate"/>
       <xs:element name="MsgUpdate" type="MsgUpdate"/>
       <xs:element name="MsgDelete" type="MsgDelete"/>
       <xs:element name="MsgSubscribe" type="MsgSubscribe"/>
       <xs:element name="MsgIoctlCall" type="MsgIoctlCall"/>
       <xs:element name="MsgIoctlResult" type="MsgIoctlResult"/>
     </xs:choice>
   </xs:complexType>

   <xs:key name="linkLayerElementKey">
     <xs:selector xpath="*/*"/>
     <xs:field xpath="@linkLayerElementId"/>
   </xs:key>
   <xs:keyref refer="linkLayerElementKey" name="linkLayerElementKeyRef1">
     <xs:selector xpath="*/*/baseInterfaces"></xs:selector>
     <xs:field xpath="baseInterface"></xs:field>
   </xs:keyref>
   <xs:keyref refer="linkLayerElementKey" name="linkLayerElementKeyRef2">
     <xs:selector xpath="*/*"></xs:selector>
     <xs:field xpath="ifId"></xs:field>
   </xs:keyref>

   <xs:key name="linkKey">
     <xs:selector xpath="*/*"></xs:selector>
     <xs:field xpath="@linkId"></xs:field>
   </xs:key>
   <xs:keyref refer="linkKey" name="linkKeyRef1">
     <xs:selector xpath="*/*/links"></xs:selector>
     <xs:field xpath="link"></xs:field>
   </xs:keyref>
   <xs:keyref refer="linkKey" name="linkKeyRef2">
     <xs:selector xpath="*/*"></xs:selector>
     <xs:field xpath="link"></xs:field>
   </xs:keyref>

   <xs:key name="linkServiceKey">
194   APPENDIX A                               NETWORK RESOURCE MODEL SCHEMA



            <xs:selector xpath="*/*"/>
            <xs:field xpath="@linkServiceId"/>
          </xs:key>
          <xs:keyref refer="linkServiceKey" name="linkServiceKeyRef">
            <xs:selector xpath="*/*/services"></xs:selector>
            <xs:field xpath="service"></xs:field>
          </xs:keyref>

          <xs:key name="networkLayerElementKey">
            <xs:selector xpath="networkLayerElements/*"/>
            <xs:field xpath="@networkLayerElementId"/>
          </xs:key>

          <xs:key name="pathSegmentKey">
            <xs:selector xpath="*/*"/>
            <xs:field xpath="@pathSegmentId"/>
          </xs:key>
          <xs:keyref refer="pathSegmentKey" name="pathSegmentKeyRef1">
            <xs:selector xpath="*/*/routes"></xs:selector>
            <xs:field xpath="route"></xs:field>
          </xs:keyref>
          <xs:keyref refer="pathSegmentKey" name="pathSegmentKeyRef2">
            <xs:selector xpath="*/*"></xs:selector>
            <xs:field xpath="defaultRoute"></xs:field>
          </xs:keyref>
          <xs:keyref refer="pathSegmentKey" name="pathSegmentKeyRef3">
            <xs:selector xpath="*/*"></xs:selector>
            <xs:field xpath="localPathSegment"></xs:field>
          </xs:keyref>
          <xs:keyref refer="pathSegmentKey" name="pathSegmentKeyRef4">
            <xs:selector xpath="*/*"></xs:selector>
            <xs:field xpath="pathSegment"></xs:field>
          </xs:keyref>
          <xs:keyref refer="pathSegmentKey" name="pathSegmentKeyRef5">
            <xs:selector xpath="*/*/pathSegments"></xs:selector>
            <xs:field xpath="pathSegment"></xs:field>
          </xs:keyref>

          <xs:key name="transportLayerElementKey">
            <xs:selector xpath="transportLayerElements/*"/>
            <xs:field xpath="@transportLayerElementId"/>
          </xs:key>

          <xs:key name="transportKey">
            <xs:selector xpath="*/*"/>
            <xs:field xpath="@transportId"/>
          </xs:key>
          <xs:keyref refer="transportKey" name="transportKeyRef">
            <xs:selector xpath="*/*/transports"></xs:selector>
            <xs:field xpath="transport"></xs:field>
          </xs:keyref>

        </xs:element>
      </xs:schema>
                                                                        Appendix

                                                                                    B
B. Informed Consent Form
   This appendix presents the text of the informed consent form that was
   signed by all participants of the CoSphere trial (Chapter 6). The telephone
   numbers in the form are withheld.


   SocioXensor/CoSphere study into mobile network contexts, availability and disclosure
   Informed Consent Form
   The SocioXensor/CoSphere study lasts at least two and at most four weeks. The study is
   conducted by Telematica Instituut as part of the research projects FRUX and AWARENESS. The
   goal of this study is to explore (the relation between) wireless data networks people (c.q. the
   mobile devices they carry) encounter in daily life, availability of people for communication and
   context information people are willing to disclose.

   During the study, measurement software on your mobile device will collect the following data:
   - (during 1 minute every 10 minutes) signal strength, name and ID of Wi-Fi stations visible
   from your device;
   - (once every 5 minutes) addresses and names of discoverable Bluetooth devices;
   - (once every minute) remaining battery percentage;
   - (continuous) Cell ID, operator ID and operator name of the GSM cells visible from your
   device;
   - (continuous) local IP settings for Bluetooth, Wi-Fi and GPRS network resources;
   N.B. We do NOT collect network traffic data, nor data about with whom you communicate.

   During the first week of the study, we ask you to answer about 10 short surveys per day
   (experience sampling).

   Despite our efforts to keep risks and discomfort to a minimum, you may experience:
   - your device's radios, such as Wi-Fi and Bluetooth, are turned on more often;
196   APPENDIX B                                                      INFORMED CONSENT FORM



      - your device consumes more power than normal, which may mean you have to charge your
      device each day;
      - your device may (briefly) lose Bluetooth connections established with other devices
      (e.g. Bluetooth TomTom mouse: 10 seconds each 5 minutes);
      - you may receive about 10 additional reminders per day (for experience sampling).

      The data that is collected in this study is kept confidential: it is stored in an encrypted form on
      your device and will be stored on a safe and secure server to which only three researchers have
      access (Henri ter Hofte, Arjan Peddemors, and Raymond Otte). Results of the study are only
      made public (e.g. in papers and presentations in journals and at conferences and as a dataset on
      the internet) in anonymous form, i.e. in such a way that data can ordinarily not be traced back to
      a particular person.

      You may always, without giving a reason and without penalty or loss of benefits to which you
      would otherwise be entitled:
      - use “not now” (a function that allows occasionally not answering an experience sample);
      - use “suspend” (a function that stops all data collection for a while);
      - request deletion of all data collected during a specific period;
      - terminate your participation in the study entirely.

      As a token of our gratitude, you may keep the 2 GB miniSD memory card (and SD card adapter)
      that we used during the study. Alternatively, you may choose not to keep the 2 GB miniSD
      memory card but receive a CD/DVD voucher worth €25 instead.

      For further questions about :
      - the study itself : Henri ter Hofte (xx-xxxxxxxx) or Arjan Peddemors (xx-xxxxxxxx); also outside
      work hours.
      - your rights as subject: Bob Hulsebosch (xxx-xxxxxxx) only during working hours.

      I have read and agree with the statements above and confirm that my participation in this study is
      voluntary

      Place:   __________________________________________

      Date:    __________________________________________

      Name:    __________________________________________

      Signature:
                                                                              Appendix

                                                                                         C
C. Prediction with Variable Event Sets
    This appendix provides the prediction results as discussed in Section 8.2.

    CoSphere data set

                                              participant 2




                   -0.7
                   -0.8
                   -0.9
                     -1
                   -1.1
                   -1.2
                   -1.3
                   -1.4


                                                                                   20
                                                                              40
                          20   40                                        60    ot-evtc
                                         60                         80
                               ot-evti         80      100    100




                                              participant 3




                  -0.45
                   -0.5
                  -0.55
                   -0.6
                  -0.65
                   -0.7
                  -0.75
                   -0.8


                                                                                   20
                                                                              40
                          20   40                                        60    ot-evtc
                                         60                         80
                               ot-evti         80      100    100
198   APPENDIX C                                    PREDICTION WITH VARIABLE EVENT SETS



                                              participant 4




                   -0.4
                   -0.5
                   -0.6
                   -0.7
                   -0.8
                   -0.9
                     -1
                   -1.1


                                                                                   20
                                                                              40
                          20   40                                        60    ot-evtc
                                         60                         80
                               ot-evti         80      100    100




                                              participant 5




                   -0.2
                   -0.3
                   -0.4
                   -0.5
                   -0.6
                   -0.7
                   -0.8
                   -0.9
                     -1


                                                                                   20
                                                                              40
                          20   40                                        60    ot-evtc
                                         60                         80
                               ot-evti         80      100    100




                                              participant 6




                   -0.5
                   -0.6
                   -0.7
                   -0.8
                   -0.9
                     -1
                   -1.1
                   -1.2
                   -1.3
                   -1.4
                   -1.5


                                                                                   20
                                                                              40
                          20   40                                        60    ot-evtc
                                         60                         80
                               ot-evti         80      100    100
APPENDIX C                                                                           199



                                         participant 7




              -0.4
             -0.45
              -0.5
             -0.55
              -0.6
             -0.65
              -0.7


                                                                               20
                                                                          40
                     20   40                                         60    ot-evtc
                                    60                          80
                          ot-evti         80       100    100




                                         participant 9




              -0.9
                -1
              -1.1
              -1.2
              -1.3
              -1.4
              -1.5
              -1.6
              -1.7


                                                                               20
                                                                          40
                     20   40                                         60    ot-evtc
                                    60                          80
                          ot-evti         80       100    100




                                         participant 10




              -0.6
             -0.65
              -0.7
             -0.75
              -0.8
             -0.85
              -0.9
             -0.95
                -1
             -1.05
              -1.1


                                                                               20
                                                                          40
                     20   40                                         60    ot-evtc
                                    60                          80
                          ot-evti         80       100    100
200   APPENDIX C                                     PREDICTION WITH VARIABLE EVENT SETS



                                               participant 11




                   -0.15
                    -0.2
                   -0.25
                    -0.3
                   -0.35
                    -0.4
                   -0.45


                                                                                     20
                                                                                40
                           20   40                                         60    ot-evtc
                                          60                          80
                                ot-evti         80       100    100




      Rice data set


                                               participant 2




                     0.2
                    0.15
                     0.1
                    0.05
                       0
                   -0.05
                    -0.1
                   -0.15
                    -0.2


                                                                                     20
                                                                                40
                           20   40                                         60    ot-evtc
                                          60                          80
                                ot-evti         80       100    100
APPENDIX C                                                                          201



                                         participant 3




              -0.5
             -0.55
              -0.6
             -0.65
              -0.7
             -0.75
              -0.8


                                                                              20
                                                                         40
                     20   40                                        60    ot-evtc
                                    60                         80
                          ot-evti         80      100    100




                                         participant 4




              -0.6
             -0.65
              -0.7
             -0.75
              -0.8
             -0.85
              -0.9


                                                                              20
                                                                         40
                     20   40                                        60    ot-evtc
                                    60                         80
                          ot-evti         80      100    100




                                         participant 5




             -0.56
             -0.58
              -0.6
             -0.62
             -0.64
             -0.66
             -0.68
              -0.7


                                                                              20
                                                                         40
                     20   40                                        60    ot-evtc
                                    60                         80
                          ot-evti         80      100    100
202   APPENDIX C                                     PREDICTION WITH VARIABLE EVENT SETS



                                               participant 6




                   -0.66
                   -0.68
                    -0.7
                   -0.72
                   -0.74
                   -0.76
                   -0.78
                    -0.8
                   -0.82
                   -0.84


                                                                                    20
                                                                               40
                           20   40                                        60    ot-evtc
                                          60                         80
                                ot-evti         80      100    100




                                               participant 7




                    -0.7
                   -0.75
                    -0.8
                   -0.85
                    -0.9
                   -0.95
                      -1
                   -1.05
                    -1.1
                   -1.15
                    -1.2


                                                                                    20
                                                                               40
                           20   40                                        60    ot-evtc
                                          60                         80
                                ot-evti         80      100    100
APPENDIX C                                                                          203



                                         participant 8




             -0.75
              -0.8
             -0.85
              -0.9
             -0.95
                -1
             -1.05


                                                                              20
                                                                         40
                     20   40                                        60    ot-evtc
                                    60                         80
                          ot-evti         80      100    100




                                         participant 9




              -0.4
             -0.45
              -0.5
             -0.55
              -0.6
             -0.65


                                                                              20
                                                                         40
                     20   40                                        60    ot-evtc
                                    60                         80
                          ot-evti         80      100    100
                                                                                                           Appendix

                                                                                                                           D
D. Prediction Performance Evolution
   This appendix provides the prediction results as discussed in Section 8.4.


                                                                              participant 2
                                           0


                                         -0.5
               weighted log likelihood




                                          -1


                                         -1.5


                                          -2


                                         -2.5


                                          -3
                                                0     0.1   0.2    0.3    0.4      0.5        0.6    0.7    0.8     0.9    1
                                                                              time fraction

                                                lastcondr         lastcondp              lowestvar                bestll


                                                                              participant 3
                                           0


                                         -0.5
               weighted log likelihood




                                          -1


                                         -1.5


                                          -2


                                         -2.5


                                          -3
                                                0     0.1   0.2    0.3    0.4      0.5        0.6    0.7    0.8     0.9    1
                                                                              time fraction

                                                lastcondr         lastcondp              lowestvar                bestll
206   APPENDIX D                                                                  PREDICTION PERFORMANCE EVOLUTION



                                                                                  participant 4
                                               0


                                             -0.5




                   weighted log likelihood
                                              -1


                                             -1.5


                                              -2


                                             -2.5


                                              -3
                                                    0     0.1   0.2    0.3    0.4      0.5        0.6    0.7   0.8     0.9    1
                                                                                  time fraction

                                                    lastcondr         lastcondp              lowestvar               bestll


                                                                                  participant 5
                                               0


                                             -0.5
                   weighted log likelihood




                                              -1


                                             -1.5


                                              -2


                                             -2.5


                                              -3
                                                    0     0.1   0.2    0.3    0.4      0.5        0.6    0.7   0.8     0.9    1
                                                                                  time fraction

                                                    lastcondr         lastcondp              lowestvar               bestll


                                                                                  participant 6
                                               0


                                             -0.5
                   weighted log likelihood




                                              -1


                                             -1.5


                                              -2


                                             -2.5


                                              -3
                                                    0     0.1   0.2    0.3    0.4      0.5        0.6    0.7   0.8     0.9    1
                                                                                  time fraction

                                                    lastcondr         lastcondp              lowestvar               bestll
APPENDIX D                                                                                                                  207



                                                                            participant 7
                                         0


                                       -0.5




             weighted log likelihood
                                        -1


                                       -1.5


                                        -2


                                       -2.5


                                        -3
                                              0     0.1   0.2    0.3    0.4      0.5        0.6    0.7   0.8     0.9    1
                                                                            time fraction

                                              lastcondr         lastcondp              lowestvar               bestll


                                                                            participant 9
                                         0


                                       -0.5
             weighted log likelihood




                                        -1


                                       -1.5


                                        -2


                                       -2.5


                                        -3
                                              0     0.1   0.2    0.3    0.4      0.5        0.6    0.7   0.8     0.9    1
                                                                            time fraction

                                              lastcondr         lastcondp              lowestvar               bestll
208   APPENDIX D                                                                  PREDICTION PERFORMANCE EVOLUTION



                                                                                  participant 10
                                               0


                                             -0.5




                   weighted log likelihood
                                              -1


                                             -1.5


                                              -2


                                             -2.5


                                              -3
                                                    0     0.1   0.2    0.3    0.4      0.5        0.6    0.7   0.8     0.9    1
                                                                                  time fraction

                                                    lastcondr         lastcondp              lowestvar               bestll


                                                                                  participant 11
                                               0


                                             -0.5
                   weighted log likelihood




                                              -1


                                             -1.5


                                              -2


                                             -2.5


                                              -3
                                                    0     0.1   0.2    0.3    0.4      0.5        0.6    0.7   0.8     0.9    1
                                                                                  time fraction

                                                    lastcondr         lastcondp              lowestvar               bestll
       References
[1]    American National Standards Institute (ANSI) Standard T1.413-1998, Network
       and Customer Installation Interfaces – Asymmetric Digital Subscriber Line (ADSL)
       Metallic Interface, 1998
[2]    Antunes, C., and Oliveira, A., Temporal Data Mining: an overview, In Workshop on
       Temporal Data Mining (KDD’01), August 2001
[3]    Apache Axis2 Simple Object Acces Protocol (SOAP) implementation,
       http://ws.apache.org/axis2/
[4]    Apache HTTP server project, http://httpd.apache.org/
[5]    Asthana, S., and Kalofonos, D., The Problem of Bluetooth Pollution and
       Accelerating Connectivity in Bluetooth Ad-Hoc Networks, In Proceeding of 3rd
       International Conference on Pervasive Computing and Communications (PerCom’05), March
       2005
[6]    Bandholz, M., Gefflaut, A., Riihijärvi, J., Wellens, M., and Mähönen, P., Unified
       Link-Layer API Enabling Wireless-Aware Applications, In Proceedings of the
       International Symposium on Personal, Indoor and Mobile Radio Communications
       (PIMRC’06), September 2006
[7]    Berners-Lee, T., Fielding, R., and Masinter, L., Uniform Resource Identifier
       (URI): Generic Syntax, RFC 3986, Internet Engineering Task Force, January 2005
[8]    Bhagwat, P., Perkins, C., and Tripathi, S., Network Layer Mobility: An
       Architecture and Survey, IEEE Personal Communications, Vol. 3, Issue 3, pp. 54-64,
       June 1996
[9]    Bhattacharya, A., and Das, S., LeZi-Update: An Information-Theoretic Framework
       for Personal Mobility Tracking in PCS Networks, Wireless Networks 8, pp. 121-135,
       2002
[10]   Box, G., Jenkins, G., and Reinsel, G., Time Series Analysis: Forecasting & Control, Wiley
       Series in Probability and Statistics, 4th edition, Wiley, 2008
[11]   Braden, R., Requirements for Internet Hosts -- Communication Layers, RFC
       1122, Internet Engineering Task Force, October 1989
[12]   Breiman, L., Meisel, W., and Purcell, E., Variable Kernel Estimates of Multivariate
       Densities, Technometrics, Vol. 19, No. 2, pp. 135-144, 1977
210          REFERENCES



      [13]   Brown, D., Liu, H., and Xue, Y., Mining Preferences from Spatial-Temporal Data,
             In Proceedings of the 1st SIAM International Conference on Data Mining (SDM’01), April
             2001
      [14]   Bush, R., and Meyer, D., Some Internet Architectural Guidelines and Philosophy,
             RFC 3439, Internet Engineering Task Force, December 2002
      [15]   Carpenter, B., Architectural Principles of the Internet, RFC 1958, June 1996
      [16]   C programming language, International Standard ISO/IEC 9899:TC3 (ANSI C99)
      [17]   Cerf, V., and Cain, E., The DoD Internet architecture model, Computer Networks,
             Vol. 7, Number 5, pp. 307-318, 1983
      [18]   Cheng, C., Jain, R., Van den Berg, E., Location Prediction Algorithms for Mobile
             Wireless Systems, Handbook of Wireless Internet (Ed. Furht, B., and Ilyas, M.), CRC
             Press, 2003
      [19]   Chaintreau, A., Hui, P., Crowcroft, J., Diot, C., Gass, R., and Scott, J., Impact of
             Human Mobility on the Design of Opportunistic Forwarding Algorithms, In
             Proceedings of the 25th IEEE International Conference on Computer Communications
             (INFOCOM’06), April 2006
      [20]   Chipchase, J., Persson, P., Piippo, P., Aarras, M., and Yamamoto, T., Mobile
             Essentials: Field Study and Concepting, In Proceedings of the 2005 Conference on
             Designing for User eXperience (DUX’05), November 2005
      [21]   Chow, Y.-S., Geman, S., and Wu, L.-D., Consistent Cross-Validated Density
             Estimation, The Annals of Statistics, Vol. 11, No. 1, pp. 25-38, 1983
      [22]   Clark, D., Partridge, C., Ramming, C., and Wroclawski, J., A Knowledge Plane for
             the Internet, In Proceedings of the Conference on Applications, Technologies, Architectures,
             and Protocols for Computer Communication (SIGCOMM’03), August 2003
      [23]   Cohen, B., The BitTorrent Protocol Specification, Version 11031, February 2008,
             Retrieved on 11-2-2009 from http://bittorrent.org/beps/bep_0003.html
      [24]   Common          Information       Model       (CIM)      Schema,       Version       2.20,
             http://www.dmtf.org/standards/cim/cim_schema_v220
      [25]   CoSphere Network Abstraction Layer (NAL), http://cosphere.novay.nl/nal/
      [26]   CoSphere trial data set, http://crawdad.cs.dartmouth.edu/novay/cosphere
      [27]   Cowling, A., and Hall, P., On Pseudodata Methods for Removing Boundary Effects
             in Kernel Density Estimation, Journal of the Royal Statistical Society. Series B
             (Methodological), Vol. 58, No. 3, pp. 551-563, 1996
      [28]   CRAWDAD: A Community Resource for Archiving Wireless Data at Dartmouth,
             http://www.crawdad.org/
      [29]   Deering, S., and Hinden, R., Internet Protocol, Version 6 (IPv6) Specification,
             RFC 2460, Internet Engineering Task Force, December 1998
      [30]   De Gooijer, J. and Zerom, D., On Conditional Density Estimation, Statistica
             Neerlandica, Vol. 57, pp. 159-176, 2003
      [31]   Dietterich, T., and Langley, T., Machine Learning for Cognitive Networks:
             Technology Assessment and Research Challenges, Cognitive Networks (Ed.
             Mahmoud, Q.), Wiley, July 2007
      [32]   Droms, R., Dynamic Host Configuration Protocol, RFC 2131, Internet
             Engineering Task Force, March 1997
       REFERENCES                                                                          211



[33]   Eagle, N., and Pentland, A., Reality mining: sensing complex social systems,
       Personal and Ubiquitous Computing, Vol. 10, Issue 4, pp. 255-268, March 2006
[34]   Ecma Standard ECMA-340, Near Field Communication Interface and Protocol
       (NFCIP-1), 2nd edition, December 2004
[35]   Epanechnikov, V., Nonparametric Estimation of a Multidimensional Probability
       Density, Theory of Probability and its Applications, Vol. 14, Issue 1, pp. 153-158, 1969
[36]   Estivill-Castro, V., Why so many clustering algorithms – a position paper, ACM
       SIGKDD Explorations Newsletter, Vol. 4, Issue 1, pp. 65-75, June 2002
[37]   Feldmann, A., Intenet clean-slate design: what and why?, ACM SIGCOMM Computer
       Communication Review, Vol. 37, Issue 3, pp. 59-64, July 2007
[38]   Ferguson, P., and Senie, D., Network Ingress Filtering: Defeating Denial of Service
       Attacks which employ IP Source Address Spoofing, BCP 38, RFC 2827, Internet
       Engineering Task Force, May 2000
[39]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and Berners-
       Lee, T., Hypertext Transfer Protocol -- HTTP/1.1, RFC 2817, Internet
       Engineering Task Force, June 1999
[40]   François, J-M., Leduc, G., Entropy­Based Knowledge Spreading and Application to
       Mobility Prediction, In Proceedings of the International Conference On Emerging
       Networking Experiments And Technologies (CoNEXT’05), October 2005
[41]   Gaber, M., Zaslavsky, A., and Krishnaswamy, S., Mining Data Streams: A Review,
       ACM SIGMOD Record, Vol. 34, Issue 2, pp. 18-26, June 2005
[42]   Giannotti, F., Nanni, M., Pinelli, F., and Pedreschi, D., Trajectory pattern mining,
       In Proceedings of the 13th ACM SIGKDD Conference on Knowledge Discovery and Data
       Mining (KDD’07), August 2007
[43]   Gray, A., and Moore, A., Rapid evaluation of multiple density models, In Proceedings
       of the 9th International Workshop on Artificial Intelligence and Statistics, January 2003
[44]   GSPlayer software, http://hp.vector.co.jp/authors/VA032810/
[45]   Hall, P., On Kullback-Leibler Loss and Density Estimation, The Annals of Statistics,
       Vol. 15, No. 4, pp. 1491-1519, 1987
[46]   Härdle, W., Smoothing Techniques, with Implementation in S., Springer Series in
       Statistics, Springer Verlag, 1990
[47]   Hesselman, C., Eertink, E., Widya, I., and Huizer, E., Delivering Live Multimedia
       Streams to Mobile Hosts in a Wireless Internet with Multiple Content Aggregators,
       Mobile Networks and Applications, Vol. 10, Issue 3, pp. 327-339, June 2005
[48]   Holmes, M., Gray, A., and Isbell, C., Fast Nonparametric Conditional Density
       Estimation, In Proceedings of the Conference on Uncertainty in Artificial Intelligence
       (UAI’07), 2007
[49]   Hui, P., Crowcroft, J., and Yoneki, E., BUBBLE Rap: Social Based Forwarding in
       Delay Tolerant Networks, In Proceedings of the 9th International Symposium on Mobile
       Ad-Hoc Networking and Computing (MobiHoc’09), May 2008
[50]   Institute of Electrical and Electronics Engineers (IEEE) Standard 802.3 – 2005,
       Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access
       Method and Physical Layer Specifications, December 2005
212          REFERENCES



      [51]   Institute of Electrical and Electronics Engineers (IEEE) Standard 802.11 – 2007,
             Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
             Specifications, June 2007
      [52]   Institute of Electrical and Electronics Engineers (IEEE) Standard 802.15.1 – 2005,
             Wireless medium access control (MAC) and physical layer (PHY) specifications for
             wireless personal area networks (WPANs), May 2005
      [53]   Institute of Electrical and Electronics Engineers (IEEE) Standard 802.15.4 – 2006,
             Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications
             for Low-Rate Wireless Personal Area Networks (WPANs), September 2006
      [54]   Institute of Electrical and Electronics Engineers (IEEE) Standard 802.16e – 2005,
             Physical and Medium Access Control Layers for Combined Fixed and Mobile
             Operation in Licensed Bands, February 2006
      [55]   Institute of Electrical and Electronics Engineers (IEEE) 802.21 standardization
             effort, http://ieee802.org/21/
      [56]   International Organization for Standardization / International Electrotechnical
             Commission (ISO/IEC) Standard 14443, Identification cards - Contactless
             integrated circuit(s) cards - Proximity cards, April 2000
      [57]   ITU World Telecommunication / ICT Indicators Database 2008, 12th Edition,
             Retrieved on 5/2/2009 from http://www.itu.int/ITU-D/ict/statistics/ict/index.html
      [58]   Jacobsson, M., Personal Networks: An Architecutre for Self-Organized Personal Wireless
             Communications, PhD Disseration, TU Delft, 2008
      [59]   Johnson, D., Perkins, C., and Arkko, J., Mobility Support in IPv6, RFC 3775,
             Internet Engineering Task Force, June 2004
      [60]   Kawadia, V. and Kumar, P., A Cautionary Perspective on Cross Layer Design, IEEE
             Wireless Communication, February 2005
      [61]   Kijima, M, Markov Processes for Stochastic Modeling, Chapman and Hall, 1997
      [62]   Kim, M., and Kotz, D., Periodic properties of user mobility and access-point
             popularity, Personal and Ubiquiteous Computing, Vol. 11, No. 6, 2007
      [63]   Klensin, J., Simple Mail Transfer Protocol, RFC 5321, Internet Engineering Task
             Force, October 2008
      [64]   Kohler, E., Datagram Congestion Control Protocol (DCCP), RFC 4340, Internet
             Engineering Task Force, March 2006
      [65]   Koodli, R., and Perkins, C., Fast Handovers and Context Transfers in Mobile
             Networks, ACM SIGCOMM Computer Communications Review, Vol. 31, Issue 5,
             October 2001
      [66]   Laasonen, K., Clustering and Prediction of Mobile User Routes from Cellular
             Data, In Proceedings of the Conference on Principles of Data Mining and Knowledge Discovery
             (PKDD’05), October 2005
      [67]   LAME MPEG Audio Layer III (MP3) encoder, http://lame.sourceforge.net/
      [68]   Lee, J-K., and Hou, J., Modeling Steady-state and Transient Behaviors of User
             Mobility: Formulation, Analysis, and Application, In Proceedings of the International
             Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc’06), May 2006
       REFERENCES                                                                         213



[69]   Lelescu, D., Kozat, U., Jain, R., and Balakrishnan, M., Model T++: An Empirical
       Joint Space-Time Registration Model, In Proceedings of the International Symposium on
       Mobile Ad Hoc Networking and Computing (MobiHoc’06), May 2006
[70]   Levine, D., Akyildiz, I., and Naghshineh, M., The Shadow Cluster Concept for
       Resource Allocation and Call Admission in ATM-Based Wireless Networks, In
       Proceedings of the 1st International Conference on Mobile Computing and Networking
       (MobiCom’95), November 1995
[71]   Li, Z., Liu, L., and Dunham, M., Considering Correlation between Variables to
       Improve Spatiotemporal Forecasting, In Proceedings of the 7th Pacific-Asia Conference on
       Knowledge Discovery and Data Mining (PAKDD’03), April 2003
[72]   Linux Advanced Routing & Traffic Control, http://lartc.org/
[73]   Manning, C., and Schütze, H., Foundations of statistical natural language processing,
       Edition 6, MIT Press, 2003
[74]   Magnusson, M., Discovering hidden time patterns in behavior: T-patterns and their
       detection, Behavior Research Methods, Instruments & Computers, Vol. 32, Issue 1, pp.
       93-110, 2000
[75]   Marsh, M., Policy Routing with Linux, Sams, 2001
[76]   McCloghrie, K., and Rose, M. (Ed.), Management Information Base for Network
       Management of TCP/IP-based internets: MIB-II, RFC 1213, Internet Engineering
       Task Force, March 1991
[77]   McNett, M., and Voelker, G., Access and Mobility of Wireless PDA Users, Mobile
       Computing and Communications Review (MC2R), Vol. 9, Issue 2, pp. 40-55, April 2005
[78]   Microsoft Developer Network (MSDN) library, http://msdn.microsoft.com/library/
[79]   Misra, A., Roy, A., and Das, S., An information-theoretic framework for optimal
       location tracking in multisystem 4G wireless networks, In Proceedings of the 23rd
       Annual Joint Conference of the IEEE Computer and Communications Societies
       (INFOCOM’04), March 2004
[80]   Mitola, J., The software radio architecture, IEEE Communications Magazine, Vol. 33,
       Issue 5, pp. 26-38, May 1995
[81]   Mitola, J., and Maguire, G., Cognitive radio: making software radios more
       personal, IEEE Personal Communications, Vol. 6, Issue 4, August 1999
[82]   MPEG 1 Coding of moving pictures and associated audio for digital storage media
       at up to about 1,5 Mbit/s – Part 3: Audio, ISO/IEC 11172-3:1993, 1993
[83]   MPEG 2 Generic coding of moving pictures and associated audio information –
       Part 3: Audio, ISO/IEC 13818-3:1998, 1998
[84]   Mockapetris, P., Domain Names – Concepts and Facilities, RFC 1034, Internet
       Engineering Task Force, November 1987
[85]   Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T., Host Identity
       Protocol, RFC 5201, Internet Engineering Task Force, April 2008
[86]   Niemegeers, I., and Heemstra de Groot, S., Research Issues in Ad-Hoc Distributed
       Personal Networking, Wireless Personal Communications, Vol. 26, Issue 2-3, pp. 149-
       167, August 2003
214           REFERENCES



      [87]    Nikander, P., Henderson, T., Vogt, C., and Arkko, J., End-Host Mobility and
              Multihoming with the Host Identity Protocol, RFC 5206, Internet Engineering
              Task Force, April 2008
      [88]    Noble, B., and Satyanarayanan, M., Experience with adaptive mobile applications
              in Odyssey, Mobile Networks and Applications, Vol. 4, Issue 4, pp. 245-254,
              December 1999
      [89]    Nurmi, P., and Koolwaaij, J., Identifying meaningful locations, In Proceedings of the
              3rd Annual International Conference on Mobile and Ubiquitous Systems, Networks and
              Services (MobiQuitous’06), July 2006
      [90]    Pawar, P., Van Beijnum, B-J., Peddemors, A., and Van Halteren, A. Context-Aware
              Middleware Support for the Nomadic Mobile Services on Multi-Homed Handheld
              Devices, In Proceedings of the 12th IEEE Symposium on Computers and Communications
              (ISCC’07), July 2007
      [91]    Peddemors, A., Eertink, H., and Niemegeers, I. Communication Context for
              Adaptive Mobile Applications, In Workshop Proceedings of the 3rd Conference on Pervasive
              Computing – Middleware Support for Pervasive Computing Workshop (PerWare’05), March
              2005
      [92]    Peddemors, A., Eertink, H., and Niemegeers, I., Density Estimation for Out-of-
              Range Events on Personal Mobile Devices, In Proceedings of the 1st ACM SIGMOBILE
              International Workshop on Mobility Models for Networking Research, May 2008
      [93]    Peddemors, A., Eertink, H., and Niemegeers, I., Predicting mobility events on
              personal devices, To appear in the Pervasive and Mobile Computing Journal – Special
              Issue on Human Behaviour in Ubiquitous Environments
      [94]    Peddemors, A., Eertink, H., Niemegeers, I., and Bargh, M., Network Resource
              Awareness and Control in Mobile Applications, In IEEE Internet Computing – Special
              Issue on Roaming, March/April 2007
      [95]    Peddemors, A., Niemegeers, I., and Eertink, H., A System Perspective on
              Cognition for Autonomic Computing and Communication, In Proceedings of the
              16th International Conference and Workshop on Database and Expert System Applications –
              Self-Adaptive and Autonomic Computing Systems Workshop (SAACS’05), August 2005
      [96]    Peddemors, A., Niemegeers, I, and Eertink, H., An Extensible Network Resource
              Abstraction for Applications on Mobile Devices, In Proceedings of the 2nd
              International Conference on Communication System Software and Middleware
              (COMSWARE’07), January 2007
      [97]    Peddemors, A., and Yoneki, E., Decentralized Probabilistic World Modeling with
              Cooperative Sensing, In Proceedings of KIVS Workshop on Global Sensor Networks
              (GSN'09), March 2009
      [98]    Peddemors, A., Zandbelt, H., and Bargh, M., A Mechanism for Host Mobility
              Management Supporting Application Awareness, In Proceedings of the 2nd
              International Conference on Mobile Systems, Applications, and Services (MobiSys’04), June
              2004
      [99]    Perkins, C., IP Mobility Support for IPv4, RFC 3220, Internet Engineering Task
              Force, January 2002
      [100]   Perl Directory, http://www.perl.org/
        REFERENCES                                                                             215



[101]   Pfleger, K., On-line Learning of Predictive Compositional Hierarchies, PhD. Disseration,
        Stanford University, 2002
[102]   Postel, J., Internet Protocol, RFC, 791, Internet Engineering Task Force,
        September 1981
[103]   Postel, J., Transmission Control Protocol, RFC 793, Internet Engineering Task
        Force, September 1981
[104]   Postel, J., User Datagram Protocol, RFC 768, Internet Engineering Task Force,
        August 1980
[105]   Python Programming Language, http://www.python.org/
[106]   Rahmati, A., and Zhong, L., Context-for-Wireless: Context-Sensitive Energy-
        Efficient Wireless Data Transfer, In Proceedings of 5th International Conference on
        Mobile Systems, Applications, and Services (MobiSys’07), June 2007
[107]   Ramani, I., and Savage, S., SyncScan: Practical Fast Handoff for 802.11
        Infrastructure Networks, In Proceedings of the 24th Annual Joint Conference of the IEEE
        Computer and Communications Societies (INFOCOM’05), March 2005
[108]   Roddick, J., and Spiliopoulou, M., A Survey of Temporal Knowledge Discovery
        Paradigms and Methods, IEEE Transactions on Knowledge and Data Engineering, Vol.
        14, No. 4, July/August 2002
[109]   Roman, G.-C., Julien, C., and Huang, Q., Network Abstractions for Context-
        Aware Mobile Computing, In Proceedings of the 24th International Conference on Software
        Engineering, May 2002
[110]   Rosenblatt, M., Remarks on some nonparametric estimates of a density function,
        The Annals of Mathematical Statistics, Vol. 27, No. 3, pp. 832-837, 1956
[111]   Salim, J., Khosravi, H., Kleen, A., and Kuznetsov, A., Linux Netlink as an IP
        Services Protocol, RFC 3549, Internet Engineering Task Force, July 2003
[112]   Scott, D., Multivariate Density Estimation: Theory, Practice and Visualization, Wiley Series
        in Probability and Statistics, Wiley, 1992
[113]   Silverman, B., Density Estimation for Statistics and Data Analysis, Monographs on
        statistics and applied probability, Chapman and Hall, 1986
[114]   Singh, G., Single Versus Multiple Inheritance in Object Oriented Programming,
        ACM SIGPLAN OOPS Messenger, Vol. 5, Issue 1, January 1994
[115]   SlimServer software, http://www.slimdevices.com/
[116]   Snoeren, A., and Balakrishnan, H., An End-to-End Approach to Host Mobility, In
        Proceedings of the 6th Annual International Conference on Mobile Computing and Networking
        (MobiCom’00), August 2000
[117]   Song, L., Kotz, D., Jain, R., and He, X., Evaluating location predictors with
        extensive Wi-Fi mobility data, In Proceedings of the 23rd Annual Joint Conference of the
        IEEE Computer and Communications Societies (INFOCOM’04), April 2004
[118]   Srisuresh, P., and Egevang, K., Traditional IP Network Address Translator
        (Traditional NAT), RFC 3022, Internet Engineering Task Force, January 2001
[119]   Stevens, R., Advanced Programming in the UNIX Environment, Addison-Wesley, 1992
[120]   Stevens, R., UNIX Network Programming Volume 1, Networking APIs: Sockets and XTI,
        2nd edition, Prentice Hall, 1998
216           REFERENCES



      [121]   Stewart, R., Stream Control Transmission Protocol, RFC 4960, Internet
              Engineering Task Force, September 2007
      [122]   Stewart, R., Xie, Q., Tüxen, M., Maruyama, S., and Kozuka, M., Stream Control
              Transmission Protocol (SCTP) Dynamic Address Reconfiguration, RFC 5061,
              Internet Engineering Task Force, September 2007
      [123]   Tsirtsis, G., and Soliman, H., Problem Statement: Dual Stack Mobility, RFC 4977,
              Internet Engineering Task Force, August 2007
      [124]   Ter Hofte, H., Xensible Interruptions from Your Mobile Phone, In Proceeding of the
              9th International Conference on Human Computer Interaction with Mobile Devices and
              Services (MobileHCI’07), Sept. 2007
      [125]   Wasserman, L., All of Nonparametric Statistics, Springer texts in statistics, Springer,
              2006
      [126]   Witten, F., and Frank, E., Data Mining: Practical Machine Learning Tools and
              Techniques, 2nd edition, Morgan Kaufman, 2005
      [127]   XML Schema, W3C, http://www.w3.org/XML/Schema
      [128]   Ylitalo, J., Jokikyyny, T., Kauppinen, T., Tuominen, A., and Laine, J., Dynamic
              Network Interface Selection in Multihomed Mobile Hosts, In Proceedings of he 36th
              Annual Hawaii International Conference on System Sciences (HICSS'03), January 2003
      [129]   Zhao, X., Castelluccia, C., and Baker, M., Flexible Network Support for Mobility,
              In Proceedings of the 4th Annual International Conference on Mobile Computing and
              Networking (MobiCom’98), October 1998
Summary
In the past several years, personal mobile devices have developed rapidly as
versatile computing platforms, capable of installing and running many
different applications. Often, these devices are equipped with multiple
(wireless) network interfaces supporting internet access through one or
more networks. The availability of these networks is dynamic over time,
because the device owners move in and out of range during their daily
activities: a device may connect to an ultra-wideband access point at home,
simultaneously use a Bluetooth network and a cellular network while
traveling, and connect to an 802.11 wireless local area network (WLAN) at
work. Applications on mobile devices therefore experience intermittent
connectivity or fluctuations in available throughput capacity when
communicating with other nodes on the internet.
    To deal with these dynamics, mobile applications require a mechanism
that provides awareness of and control over current resources in a
comprehensive, cross-layer way. We present an extensible network resource
model (NRM) that describes the available network entities and their
interrelationships below the application layer. The NRM supports different
views on available network resources, allowing applications to obtain only
those types of information that are required for their decision making
needs. Applications connect to our abstraction layer (NAL) middleware
service on the mobile device to be notified of changes and to control
available resources.
    We provide an evaluation of the NRM and NAL based on a real world
audio streaming application, using a reference NRM and a NAL
implementation on a Windows CE device. We show that a NAL
implementation can be lightweight (i.e., consumes few computing
resources) and that it can be easily deployed for this application.
Furthermore, we show that the offered abstraction is appropriate for this
application.
218   SUMMARY



          A unique aspect of personal mobile devices is that they are carried by
      their owners on a (virtually) permanent basis. Under the assumption that
      people regularly repeat their behavior, this offers an opportunity to predict
      the availability of network resources in the future. Applications may offer a
      better service to the user when taking into account the expected availability
      of networks over time. To forecast the future occurrence of a network
      availability event, such as the event of getting in- or out-of-range, we
      propose an approach that keeps track of the probability of this event
      occurrence given the occurrence of another event that already happened.
      For instance, to compute the probability of getting in range of a user’s
      home WLAN between now and the next hour, we use the distribution of
      the time difference between moving out of range of the office WLAN (that
      has just happened) and moving in range of the home WLAN, as observed in
      the past. Now, multiple preceding events may exist: we examined strategies
      to select the one to use as the preceding event for the forecast (selection of
      the best predictor).
          We executed a user experiment that gathered traces for multiple
      network interfaces on the mobile devices of twelve participants over a
      period of approximately one month, using the NAL reference
      implementation. We used this data, together with another publicly available
      data set, to obtain results for our prediction approach. For our
      configuration, we showed that in most cases the best strategy is to select the
      best predictor based on the ‘highest mean likelihood’. Furthermore, we
      found that including predictors based on infrequently visible network
      entities results in better predictions using the best strategy. Also, we found
      that cross-technology information in most cases improves the prediction
      performance.
Samenvatting
In de afgelopen jaren hebben mobiele telefoons zich ontwikkeld tot
veelzijdige apparaten waarop veel verschillende soorten toepassingen
geïnstalleerd en gebruikt kunnen worden. Vaak zijn deze persoonlijke
apparaten uitgevoerd met meerdere (draadloze) netwerk interfaces die
toegang tot het internet kunnen bieden via verschillende netwerken en
netwerktechnologieën. Omdat gebruikers mobiel zijn bewegen ze
regelmatig in- en uit het bereik van één of meerdere specifieke netwerken.
Een apparaat kan bijvoorbeeld thuis verbinden met een ultra-wideband
access point, onderweg een Bluetooth netwerk en een UMTS netwerk
gebruiken, en op het werk verbinden met een 802.11 ‘wireless local area
network’ (WLAN). Toepassingen op mobiele apparaten hebben daardoor te
maken met onderbroken verbindingen en wisselingen in de beschikbare
doorvoer capaciteit tijdens het communiceren met andere apparaten op het
internet.
    Om met deze dynamiek om te gaan, moeten mobiele toepassingen op
de hoogte zijn van beschikbare netwerk middelen en in staat zijn om op het
gebruik van netwerk middelen invloed uit te oefenen. Hiervoor hebben we
een uitbreidbaar ‘network resource model’ (NRM) ontwikkeld dat
beschikbare netwerk entiteiten en hun onderlinge relaties onder de
applicatie laag beschrijft. Het NRM ondersteunt het beschrijven van deze
middelen vanuit verschillende perspectieven. Toepassingen zijn hierdoor in
staat om precies die informatie te verkrijgen die nodig is om beslissingen te
nemen over het gebruik van netwerk middelen. Die informatie wordt
geleverd door de door ons ontwikkelde ‘network abstraction layer’ (NAL):
een software component die toepassingen tevens in staat stelt om de
netwerk functionaliteit op het mobiele apparaat te configureren. Het NRM
en de NAL worden gebruikt door de ontwikkelaars van mobiele
toepassingen en zijn niet zichtbaar voor de eindgebruiker.
    We hebben het NRM en de NAL geëvalueerd op basis van een echte
‘audio streaming’ toepassing, waarbij gebruik werd gemaakt van een
220   SAMENVATTING



      referentie NRM en een NAL implementatie op een Windows CE apparaat.
      Daarbij hebben we laten zien dat een NAL implementatie toe kan met
      weinig reken capaciteit en geheugen en dat een dergelijke implementatie
      eenvoudig ingezet kan worden voor deze toepassing. Verder hebben we
      laten zien dat de geboden abstractie passend is voor deze toepassing.
          Een uniek aspect van persoonlijke mobiele apparaten is dat deze op een
      (bijna) permanente basis worden gedragen door hun gebruikers.
      Aangenomen dat mensen hun gedrag op een regelmatige basis herhalen,
      biedt dit een mogelijkheid om de toekomstige beschikbaarheid van netwerk
      middelen te voorspellen. Toepassingen kunnen een betere dienst leveren
      aan hun gebruiker als deze rekening houden met de verwachte
      beschikbaarheid van netwerk middelen in de tijd. Om het toekomstige
      optreden van een ‘netwerk event’ te voorspellen, zoals de gebeurtenis van
      het in- of uit bereik raken van een netwerk, stellen we een aanpak voor
      welke de waarschijnlijkheid van het optreden van deze gebeurtenis bijhoudt,
      gegeven het optreden van een andere gebeurtenis die al heeft
      plaatsgevonden. Hiermee kan bijvoorbeeld worden berekend wat de
      waarschijnlijkheid is om tussen nu en het komende uur in het bereik te
      komen van het WLAN thuis, als de gebruiker net het kantoor heeft verlaten.
      We gebruiken dan de kansverdeling van het tijdsverschil tussen het uit
      bereik raken van het werk WLAN (wat net is gebeurd) en het in bereik
      raken van het thuis WLAN, zoals waargenomen in het verleden. Nu kunnen
      er meerdere reeds opgetreden gebeurtenissen bestaan: we hebben
      strategieën onderzocht om de opgetreden gebeurtenis (een ‘voorspeller
      event’) te selecteren die wordt gebruikt voor de voorspelling (selectie van de
      beste voorspeller).
          We hebben een experiment uitgevoerd waarin we alle netwerk events op
      de mobiele telefoons van twaalf personen hebben gemeten gedurende een
      periode van ongeveer één maand. Deze telefoons waren uitgerust met de
      NAL component voor het vastleggen van deze events. We hebben deze data
      gebruikt, samen met een andere publiek beschikbare data set, om
      verschillende strategieën voor de selectie van de beste voorspeller met elkaar
      te vergelijken. Voor onze configuratie hebben we laten zien dat de beste
      strategie gebruik maakt van de ‘highest mean likelihood’. Verder hebben we
      bepaald dat het meenemen van voorspeller events die gebaseerd zijn op
      infrequent zichtbare netwerk entiteiten resulteert in betere voorspellingen,
      bij gebruik van de beste strategie.
          Ook hebben we laten zien dat in de meeste gevallen de event
      voorspelling beter is als de set van voorspeller events bestaat uit events die
      behoren bij meerdere netwerk technologieën, in vergelijking met een set
      die bestaat uit events behorende bij één netwerk technologie.
Curriculum Vitae

Personalia
Name               Arjan Peddemors
Date of birth      June 12, 1969
Place of birth     Weerselo, The Netherlands
Nationality        Dutch


Profile
Arjan Peddemors is a researcher in the domain of pervasive and mobile
computing, with a broad system software and network engineering
background. After his graduation as an electrical engineer at the University
of Twente, he worked as an R&D software engineer in industry and the
non-profit sector for 10 years, specializing on internet and mobile
technologies. More recently, he combined his research engineering role
with pursuing a PhD degree, at the Wireless and Mobile Communications
group of the faculty of Electrical Engineering, Mathematics, and Computer
Science (EEMCS) of Delft University of Technology. Arjan is currently
employed by Novay (former Telematica Instituut).


Work experience
Jul 2009 – now           Researcher, Novay (former Telematica Instituut)
Apr 1999 – Jun 2009      Research Engineer, Novay
Oct 1996 – Mar 1999      Scientific Programmer, Universiteit Amsterdam
Jan 1995 – Sep 1996      UNIX Software Engineer, Ericsson
222   CURRICULUM VITAE



      Oct 1994 – Dec 1994           Software QA Engineer, Matrix Software
      Sep 1993 – Aug 1994           Group Leader, Royal Dutch Army (mil. service)


      Education
      1987 – 1993           Electrical Engineering (Ir.), Universiteit Twente
      1981 – 1987           VWO, Twents Carmel Lyceum


      Professional and supervision activities
      Program Committee member of the 1st ACM International Workshop on
         Hot Topics of Planet-scale Mobility Measurements (HotPlanet'09) (co-
         located with ACM MobiSys'09)
      Reviewer for Pervasive and Mobile Computing Journal
      Reviewer for IEEE Pervasive Computing
      Reviewer for Wireless Personal Communications Journal
      Reviewer for EuroSSC'09
      (Co-)Supervision of Master of Science thesis assignment Stephan Hegge


      Publications

      Peddemors, A., Eertink, E., and Niemegeers, I., Predicting mobility events on
      personal devices, To appear in the Pervasive and Mobile Computing Journal – Special
      Issue on Human Behaviour in Ubiquitous Environments
      Wac, K., Bargh, M., Van Beijnum, B-J., Bults, R., Pawar, P., and Peddemors, A.,
      Power- and Delay-Awareness of Health Telemonitoring Services: the MobiHealth
      System Case Study, In IEEE Journal on Selected Areas in Communications (JSAC) - Special
      Issue on Wireless and Pervasive Communications in Healthcare, Vol. 27, Issue 4, pp. 525-
      537, May 2009
      Peddemors, A., and Yoneki, E., Decentralized Probabilistic World Modeling with
      Cooperative Sensing, In Proceedings of KIVS Workshop on Global Sensor Networks
      (GSN'09), March 2009
      Peddemors, A., Eertink, H., and Niemegeers, I. Density Estimation for Out-of-
      Range Events on Personal Mobile Devices, In Proceedings of the 1st ACM SIGMOBILE
      International Workshop on Mobility Models for Networking Research, May 2008
      Pawar, P., Van Beijnum, B-J., Peddemors, A., and Van Halteren, A. Context-Aware
      Middleware Support for the Nomadic Mobile Services on Multi-Homed Handheld
      Devices, In Proceedings of the 12th IEEE Symposium on Computers and Communications
      (ISCC’07), July 2007
CURRICULUM VITAE                                                                    223



Peddemors, A., Eertink, H., Niemegeers, I., and Bargh, M. Network Resource
Awareness and Control in Mobile Applications, In IEEE Internet Computing – Special
Issue on Roaming, March/April 2007
Peddemors, A., Niemegeers, I, and Eertink, H., An Extensible Network Resource
Abstraction for Applications on Mobile Devices, In Proceedings of the 2nd
International Conference on Communication System Software and Middleware
(COMSWARE’07), January 2007
Peddemors, A., Eertink, H., and Niemegeers, I., Experience-Based Network
Resource Usage on Mobile Hosts, In Proceedings of the 2nd Conference on Future
Networking Technologies - Student Workshop Poster (CoNEXT'06), December 2006
Van Kranenburg, H., Bargh, M., Iacob, S., and Peddemors, A., A Context
Management Framework for Supporting Context-Aware Distributed Applications,
In IEEE Communications Magazine, August 2006
Bargh, M., and Peddemors, A., Towards an Energy-Aware Network Activation
Strategy for Multi-Homed Mobile Devices, In Proceedings of the International
Conference on Pervasive Systems and Computing (PSC'06), June 2006
Eertink, H., Peddemors, A., Poortinga, R., Arends, R., and Wierenga, K., Overview
and Comparison of Inter-domain Authentication Protocols, Extended abstract for
TERENA Networking Conference (TNC'06), May 2006
Peddemors, A., Niemegeers, I., and Eertink, H., A System Perspective on
Cognition for Autonomic Computing and Communication, In Proceedings of the
16th International Conference and Workshop on Database and Expert System Applications –
Self-Adaptive and Autonomic Computing Systems Workshop (SAACS’05), August 2005
Eertink, H., Peddemors, A., Arends, R., and Wierenga, K., Combining RADIUS
with Secure DNS for Dynamic Trust Establishment between Domains, Extended
abstract for TERENA Networking Conference (TNC'05), June 2005
Peddemors, A., Eertink, H., and Niemegeers, I. Communication Context for
Adaptive Mobile Applications, In Workshop Proceedings of the 3rd Conference on Pervasive
Computing – Middleware Support for Pervasive Computing Workshop (PerWare’05), March
2005
Van Eijk, R., Salden, A., Peddemors, A., De Heer, J., Määttä, P., and Haataja, V.,
Handling Heterogeneity in Context Aware Services, In International Journal of
Pervasive Computing and Communications (JPCC), Vol. 1, Issue 1, pp. 25-30, 2005
Bargh, M., Zandbelt, H., and Peddemors, A., Managing Mobility in Beyond-3G
Environments, In Proceedings of the 7th IEEE International Conference on High Speed
Networks and Multimedia Communications (HSNMC'04), June 2004
Peddemors, A., Zandbelt, H., and Bargh, M. A Mechanism for Host Mobility
Management Supporting Application Awareness, In Proceedings of the 2nd
International Conference on Mobile Systems, Applications, and Services (MobiSys’04), June
2004
Van Eijk, R., Peddemors, A., Salden, A., De Heer, J., Määttä, P., and Haataja, V.,
Handling Heterogeneity in Location Information Services, In Proceedings of the
Communication Networks and Distributed Systems Modeling and Simulation Conference
(CNDS'04), Jan. 2004
224   CURRICULUM VITAE



      Van Kranenburg, H., Van Eijk, R., Bargh, M., Peddemors, A., Zandbelt, H., and
      Brok, J., Federated Service Platform Solutions for Heterogeneous Wireless
      Networks, In Proceedings of the 7th International Symposium on Digital Signal Processing
      and Communication Systems (DSPCS'03), Dec. 2003
      Peddemors, A., Lankhorst, M., and De Heer, J., Presence, location and instant
      messaging in a context-aware application framework, In Proceedings of the 4th
      International Conference on Mobile Data Management (MDM'03), Jan. 2003
      Belloum, A., Kaletas, E., Van Halderen, A., Afsarmanesh, H., Hertzberger, L., and
      Peddemors, A., A Scalable Web Server Architecture, In Journal on World Wide Web:
      Internet and Web Information Systems (WWW), Volume 5, Issue 1, Jan 2002
      Lankhorst, M., Van Kranenburg, H., Salden, A., and Peddemors, A., Enabling
      technology for personalizing mobile services, In Proceedings of the Hawaii International
      Conference on System Sciences (HICSS'02), Jan. 2002
      Hesselman, C., Eertink, H., and Peddemors, A., Multimedia QoS adaptation for
      inter-tech roaming, In Proceedings of the 6th IEEE Symposium on Computers and
      Communications (ISCC'01), July 2001
      Peddemors, A., and Hertzberger, L., A high performance distributed database
      system for enhanced Internet services, In Journal on Future Generation Computer
      Systems (FGCS), Vol. 15, Issue 3, pp. 407-415, April 1999
      Belloum, A., Peddemors, A., and Hertzberger, L., JERA: A Scalable Web Server, In
      Proceedings of the International Conference on Parallel and Distributed Processing Techniques
      and Applications (PDPTA'98), July 1998
      Peddemors, A., and Hertzberger, L., A high performance distributed database
      system for enhanced Internet services, In Proceedings of the International Conference on
      High-Performance Computing and Networking (HPCN'98), April 1998
NETWORK RESOURCE
AWARENESS AND PREDICTION
ON MOBILE DEVICES

Arjan Peddemors
On modern mobile devices, most applications beyond simple
voice calls depend on access to the internet. Often, these
devices are equipped with multiple wireless network interfaces
supporting this access through one or more networks, such
as those based on cellular network technologies and wireless
local area network technologies. The properties of network
resources on mobile devices, however, are dynamic in many
situations. As users are mobile and walk in and out of range of
wireless networks, applications on mobile devices experience
intermittent connectivity or fluctuations in available throughput
capacity when communicating with other nodes on the internet.
Mobile applications may benefit from taking into account
aspects of these dynamics – for instance, by adapting data
rates to maximum available capacity or controlling when to
scan and activate specific networks. Furthermore, they may
provide a better service to the user when taking into account in
a proactive manner the availability of these networks over time.


This dissertation covers two aspects that are important for
applications dealing with dynamic network resources on
personal mobile devices. We define (1) a mechanism that
provides applications with awareness of and control over
current resources in a comprehensive, cross-layer way, and
(2) we describe an approach to predict the future time of the
occurrence of a network resource event, such as getting into
range or moving out of range of a particular network, using
traces of resource availability in the past.




ISBN: 978-90-75176-71-1

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:11/7/2012
language:Unknown
pages:236
shensengvf shensengvf http://
About