Marcus Eckert
email: marcus.eckert@etit.tu-chemnitz.de

Thomas Martin Knoll
email: knoll@etit.tu-chemnitz.de

QoE Management Framework for Internet Services in SDN Enabled Mobile Networks

Keywords: ISAAR, QoE framework, QoE, quality of experience, QoS, quality of service, measurement, estimation, monitoring, enforcement, DPI classification, traffic manipulation, flow-based QoE enforcement, Software Defined Networking, SDN, OpenFlow

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Internet based services have become an essential part of private and business life and the user experienced quality of such services is crucial for the users' decision to subscribe and stay with the service or not. However the experienced service quality results from the whole end-to-end line-up from participating entities. It starts from the service generation, covers potentially several transport entities and finishes up in the application displaying or playing the result on the end device's screen or audio unit. However, the contributing performances of the individual service chain parties can often not be separately assessed from the end user perspective. Sluggish service behaviour can thus stem from slow server reaction, transport delay or losses due to congestion along the forwarding path as well as from the end device capabilities and load situation during the information processing and output. More insight can be gained from the mobile network perspective, which potentially allows for a differentiated assessment of the packet flow transport together with a transparent and remote Quality of Experience (QoE) estimation for the resulting service quality on the end device. User satisfaction and user experienced service quality are strongly correlated and lead -from an Internet service provider point of view -either to an increase in subscription numbers or to customer churn towards competitors. Neither the capabilities and load situations on end devices nor the performance of content provider server farms nor the transport performance on transit links can be influenced by the operator of a mobile network. Therefore, this QoE framework will concentrate on the monitoring and enforcement capabilities of today's mobile networks in terms of differentiated packet flow processing and potentially SDN (Software Defined Networking) enabled forwarding. Since all competing providers will face similar conditions on either end of the service chain, the emphasis on the provider own match between service flow requirements and attributed mobile network resources in a cost efficient manner will be key for the mobile operator business success. That applies especially for SDN enabled networks, where a split between control and data path elements is made. This way, functions traditionally realized in specialised hardware can now be abstracted and virtualized on general purpose servers. Due to this virtualization, network topologies as well as transport and processing capacities can be easily and quickly adopted to the service demand needs under energy and cost constraints. One of the SDN implementation variants is the freely available OpenFlow (OF) standard [START_REF]The OpenFlow Switch Specification[END_REF]. With OF the path of packets through the network can be defined by software rules. OF is Ethernet based and implements a split architecture between so called OpenFlow Switches and Open-Flow controllers. A switch with OF control plane is referred to as "OpenFlow Switch". The switch consists of the specialised hardware (Flow Tables), the Secure Channel for communication between switch and OF controller and the OF protocol which provides the interface between them [START_REF] Ibm | OpenFlow: The next generation in networking interoperability[END_REF].

The Internet Service quality Assessment and Automatic Reaction (ISAAR) quality of experience framework takes this situation into account and leverages the packet forwarding and traffic manipulation capabilities available in modern mobile networks. It focuses on LTE and LTE Advanced networks, but is applicable to the packet domains in 3G and even 2G mobile networks as well. Since different services out of the broad variety of Internet services will ideally require individual packet flow handling for all possible services, the ISAAR framework will focus only on the major service classes for cost and efficiency reasons. The set of tackled services is configurable and should sensibly be limited to only the major contributing sources in the overall traffic volume or the strong revenue generating services of the operator network. The current Sandvine Internet statistic report [3] for instance shows that only HTTP, Facebook and YouTube services alone cover about 65% of the overall network traffic.

State of the Art

The standardization of mobile networks inherently addresses the topic of Quality of Service (QoS) and the respective service flow handling. The 3GPP defined architecture is called Policy and Charging Control (PCC) architecture, which started in Release 7 and applies now to the Evolved Packet System (EPS) [START_REF]Policy and Charging Control Architecture. 3GPP standard[END_REF]. The Policy and Charging Rules Function (PCRF) is being informed about service specific QoS demands by the Application Function (AF). Together with the Traffic Detection Function (TDF) or the optionally available PCRF intrinsic Application Detection and Control (ADC), traffic flow start and end events are detected and indicated to the PCRF. This in turn checks the Subscription Profile Repository (SPR) or the User Data Repository (UDR) for the permission of actions as well as the Bearer Binding and Event Reporting Function (BBERF) for the current state of already established dedicated bearers. As can be seen here, the 3GPP QoS control relies on the setup of QoS by reserving dedicated bearers. These bearers need to be setup, torn down for service flows or modified in their resource reservation, if several flows are being bundled into the same bearer [START_REF] Ekström | QoS Control in the 3GPP Evolved Packet System[END_REF]. Nine QoS Class IDs (QCI) have been defined by 3GPP for LTE networks, which are associated with such dedicated bearers. Today, IP Multimedia Subsystem (IMS) based external services and or provider own services make use of this well-defined PCC architecture and setup dedicated service flow specific reservations by means of those bearers. Ordinary Internet services, however, are often carried in just one (default) bearer without any reservations and thus experience considerable quality degradations for streaming and real time services. Therefore, network operators need to address and differentiate service flows besides the standardized QoS mechanisms of the 3GPP. HTTP based adaptive streaming video applications currently amount the highest traffic share (see [3]). They need to be investigated for their application behaviour and appropriate actions should be incorporated in any QoS enhancing framework architecture. An overview of HTTP based streaming services can be found in [START_REF] Ma | Mobile Video Delivery with HTTP[END_REF]. There are many approaches found in the literature, which address specific services and potential enhancements. HTTP Adaptive Streaming Services (HAS) [START_REF] Oyman | Quality of Experience for HTTP Adaptive Streaming Services[END_REF] for instance is a new way to adapt the video streaming quality based on the observed transport quality. Other approaches target the increasing trend of Fixed-Mobile Convergence (FMC) and network sharing concepts, which inherently require the interlinking of PCRF and QoS architecture structures and mechanisms (see e.g. [START_REF] Ouellette | A Potential Evolution of the Policy and Charging Control/QoS Architecture for the 3GPP IETF-Based Evolved Packet Core[END_REF]). This architectural opening is particularly interesting for the interlinking of 3GPP and non-3GPP QoS concepts, but has not yet been standardized for close QoS interworking. The proposed interworking of WiMAX and LTE networks [START_REF] Alasti | Quality of Service in WiMAX and LTE Networks[END_REF] and the Session Initiation Protocol (SIP) based Next Generation Network (NGN) QoE Controller concept [START_REF] Sterle | Application-Based NGN QoE Controller[END_REF] are just examples of the recent activities in the field. The ISAAR framework presented in this paper follows a different approach. It aims for service flow differentiation either within single bearers without PCRF support or PCRF based flow treatment triggering dedicated bearer setups using the Rx interface. This way it is possible to use ISAAR as a standalone solution as well as aligned with the 3GPP PCRF support. The following chapters document the ISAAR framework structure and work principle in detail.

QoE Framework Architecture

The logical architecture of the ISAAR framework is shown in Figure 1. The framework architecture is 3GPP independent but closely interworks with the 3GPP PCC. If available, it also can make use of flow steering in SDN networks using OpenFlow. This independent structure generally allows for its application in non-3GPP mobile networks as well as in fixed line networks. ISAAR provides modular service specific quality assessment functionality for selected classes of services combined with a QoE rule and enforcement function. The assessment as well as the enforcement is done for service flows on packet and frame level. It incorporates PCC mechanisms as well as packet and frame prioritisation in the IP, Ethernet, and the MPLS layer. MPLS as well as OpenFlow can also be used to perform flow based traffic engineering to direct flows in different paths. Its modular structure in the architecture elements allows for later augmentation towards new service classes as well as a broader range of enforcement means as they are defined and implemented. Service Flow Class Index and Enforcement Database register the available detection, monitoring and enforcement capabilities to be used and referenced in all remaining components of the architecture. ISAAR is divided into three functional parts which are the QoE Monitoring (QMON) unit, the QoE Rules (QRULE) unit and the QoE Enforcement (QEN) unit. These three major parts are explained in detail in the following chapters. The interworking with 3GPP is mainly realized by means of the Sd interface [START_REF] Alasti | Quality of Service in WiMAX and LTE Networks[END_REF] (for traffic detection support), the Rx interface (for PCRF triggering as application function and thus triggering the setup of dedicated bearers) and the Gx / Gxx interface [START_REF]Policy and Charging Control (PCC) over Gx/Sd reference point. 3GPP standard[END_REF] (for reusing the standardized Policy and Charging Enforcement Function (PCEF) functionality as well as the service flow to bearer mapping in the BBERF). Since ISAAR is targeting default bearer service flow differentiation also, it makes use of DiffServ Code Point (DSCP) markings, Ethernet prio markings, MPLS Traffic Class (TC) markings as well as OpenFlow priority changes as available. This is being enforced within the QEN by Gateway and Base Station (eNodeB) initiated packet header priority marking on either forwarding direction inside as well as outside of the potentially deployed GTP tunnel mechanism. This in turn allows all forwarding entities along the packet flow path through the access, aggregation and backbone network sections to treat the differentiated packets separately in terms of queuing, scheduling and dropping.

Figure 1: SDN enabled ISAAR framework

The modular structure of the three ISAAR units (QMON, QRULE and QEN) allow for a centralized as well as a decentralized deployment and placement of the functional elements.

QoE Monitoring (QMON)

Today's mobile networks carry a mix of different services. Each traffic type has its own network transport requirements in order to live up to the user expectation. To observe the achieved transport quality and its resulting user service experience, network operators need to monitor the QoE of the respective services. Since the quality of service experienced by the user is not directly measurable within the network, a new method is required, which can calculate a QoE Key Performance Indicator (KPI) value out of measurable QoS parameters. The most challenging and at the same time most rewarding service QoE estimation method is the one for video streaming services. Therefore, the paper will focus on video quality monitoring and estimation, not limiting the more general capabilities of ISAAR for all sorts of service KPI tracking. YouTube is the predominant video streaming service in mobile networks and ISAAR is consequently delivering a YouTube based QoE solution first. Within this YouTube monitoring we are able to detect and evaluate the QoE of MP4, Flash Video (FLV) as well as WebM video in Standard Definition (SD) and High Definition (HD) format. There are some client based video quality estimation approaches around (e.g. the YoMo application [START_REF] Wamser | YoMo: A YouTube Application Comfort Monitoring Tool[END_REF]), but we consider such end device bound solutions as being cumbersome and prone to manipulation. Therefore, ISAAR will not incorporate client-side solutions but concentrates on simple, transparent and network-based functionality only. Some other monitoring solutions follow a similar way of estimation, like the Passive YouTube QoE Monitoring for ISPs approach [START_REF] Schatz | Passive YouTube QoE Monitoring for ISPs[END_REF]. However, they are not supporting such a wide range of video encodings as well as container formats. Another approach is the Network Monitoring in EPC [START_REF] Wehbi | Mevico D5.1 "Network Monitoring in EPC[END_REF] system, but this does not focus on flow level service quality. The flow monitoring which is used in the ISAAR framework is explained in chapter 4.2 Flow Monitoring). However, before the QoE of a service can be estimated, the associated data flow needs to be identified. Chapter 4.1 Flow Classification) explains the flow detection and classification in detail.

Flow Classification

The ISAAR framework is meant to work with and without support of an external Deep Packet Inspection (DPI) device. Therefore it is possible to use a centralized DPI solution like the devices provided by Sandvine [16]. For unencrypted and more easily detectable traffic flows the cheaper and more minimalist DPI algorithm which is built in the ISAAR framework can be used. In the first demo implementation, the build in classification is limited to TCP traffic, focussing on YouTube video stream detection within the operator's network. Extended with SDN support there is a third possibility: given the proper configuration, the matching function from OpenFlow could be used to identify the supported service flows within the traffic mix. In the centralized architecture the flow detection and classification is most suitably done by a commercial DPI solution. In this case the QoE monitoring units have to be informed, that a data stream was found and the classification unit has also to tell them the data stream specific "five tuple". Contained in the five tuple are the source and destination IP address as well as the source and destination port and the used transport protocol. The QoE measurement starts, as soon as the flow identification information (five tuple) is available. Due to the new SDN features provided by OpenFlow it is not only possible to identify specific data flows within the Internet. OpenFlow is also capable of teeing out a stream which matches a specific pattern. Thereby, the QoE estimation could be distributed to different monitoring units e.g. depending on the specific Internet application. OpenFlow disposes the right flows to the right monitoring unit.

Flow Monitoring

In the ISAAR framework the flow monitoring is application specific, i.e. for each service, which should be monitored, a specific measurement algorithm has to be provided. Our current implementation comprises the YouTube Video QoE estimation. It works transparently and independently from the user's end device. Therefore, no tools have to be installed and no access on the end device has to be granted. Our QoE estimation method relies on video stalling events and their re-buffering timings as a quality metric for the video QoE instead of fine grained pixel and block structure errors. To determine the number and duration of re-buffering events it is necessary to comprehend the fill level of the play out buffer at the client, but without access to the end device QMON has to estimate the fill level out of the accessible TCP information within the operator network. Note, that focusing on YouTube video incurs TCP encoded HTTP streaming transport. The detailed description of the method can be found in [START_REF] Rugel | A Network-based Method for Measurement of Internet Video Streaming Quality[END_REF] and [START_REF] Knoll | An advanced network based method for Video QoE estimation based on throughput measurement[END_REF]. Three variants of the method exist -an exact method, an estimation-based method and a combination of the two.

Location aware monitoring

Due to the fact that it is probably not possible to measure all streams within an operator network, a subset of flows has to be chosen either randomly or in a policy based fashion. For example, the samples could be drawn based on the tracking area the flow goes to. If it is possible to map the eNodeB cell IDs to a tracking area, the samples also can be drawn in a regionally distributed fashion. With that, it could be decided whether a detected flow is monitored or not due to the respective destination region. Over the time, this sample selection procedure can shift the policy focus to regions with poor QoE estimation results in order to narrow down the affected regions and network elements.

QoE Policy and Rules (QRULE)

In this chapter the QoE Policy and Rules entity of the ISAAR framework is presented.

The QRULE gets the flow information and the estimated QoE of the corresponding stream form the QMON entity. It also contains a service flow class index in which all measurable service flow types are stored. The enforcement actions for the required flow handling are determined based on information from the subscriber Database and the general operator policy. Also the enforcement database within the QEN is taken into account. Combining all this information the QRULE maps the KPIs to the Per Flow Behaviour (PFB) for each data stream managed by ISAAR. PFBs are defined by appropriate marking of packets and frames. Each PFB has to be specified. Table 1 shows an example of PFB settings for video streaming, voice traffic and Facebook traffic. For video streams three possible PFBs (corresponding to three different markings) are provided. These PFPs depend on the buffer fill level. In the example (Figure 2) two buffer fill level thresholds are defined: th1 = 20 seconds and th2 = 40 seconds. If the QoE is poor, i.e. the video buffer fill level is below threshold 1 (t < th1), the EF class (101110) should be used. If the fill level is between threshold 1 and 2 (th1 < t < th2) a DSCP value like CS5 (101 000) should be chosen, because the video QoE is sufficient. Finally if the fill level exceeds threshold 2 (th2 < t) a DSCP value with a lower priority like BE (000 000) or LE (001 000) is taken, so that other flows might get preferred access to the resources.

Figure 2: Per flow behaviour dependent on the buffer fill level (YouTube example)

QRULE also decides which kind of marking is deployed depending on the networking technology. It is possible to apply IP DiffServ, Ethernet priority, MPLS traffic class marking and QCI tunnel mapping for GTP. The rules unit has to ensure that there are no oscillating effects in the network. Oscillating could occur on flow level if one flow that is lifted up in priority causes quality impairments for the neighbouring flows. Thus, the second flow will also require enforcement actions, which in turn causes the first one to deteriorate again. To overcome this effect QRULE has to consider which flows were manipulated and in which location they are. Continuous action triggering is an early indication for such race conditions, which results in QRULE dampening of enforcement actions. That is, the transport impairment are such, that ever increasing priority is simply not solving the issue. Oscillating could also occur not only on flow level but on local area level within the network. Thus regional impairment mitigation should not cause increased levels of impairments in neighbouring regions. If this is being detected by location aware QMON, QRULE should also dampen enforcement actions. Close interworking of ISAAR with network management systems fosters this detection of oscillation situations and provides vital information for root cause analysis. If the majority of the traffic would need to be precedented in priority, ISAAR has simply hit its limitation.

If there are OpenFlow enabled switches within the network it is also possible to influence the priority of the frames belonging to a critical flow by changing the OpenFlow Actions for that stream. As these mechanisms are often used in combination, there must be a consistent mapping between them. This mapping is also performed by the QRULE. Further details on the mapping can be found in [START_REF] Knoll | Cross-Domain and Cross-Layer Coarse Grained Quality of Service Support in IP-based Networks[END_REF].

For future investigation ISAAR is prepared to incorporate the interworking of GTP and MPLS LSPs in a transparent fashion. Further details on the interworking can be found in [START_REF] Windisch | Vergleich von QoS-und Mobilitätsmechanismen in Backhaul-Netzen für 4G Mobilfunk[END_REF].

QoE Enforcement (QEN)

The third functional block in the ISAAR framework is the QoE Enforcement (QEN) where the flow manipulation is performed. For data streams with estimated low QoE QRULE changes the PFBs and QEN reacts accordingly by applying suitable mechanisms to influence the transmission of the involved data frames or packets.

One possibility to influence the data transmission is to use the PCRF/PCEF and trigger the setup of dedicated bearers via the Rx interface.

A second option is to deploy layer 2 and layer 3 frame/packet markings. Based on these markings a differentiated frame/packet handling (scheduling, dropping) is enforced in the network elements which are traversed by the frames/packets (per hop behaviour). The marking is realized via IP DiffServ, Ethernet priority, MPLS traffic class priority and QCI for GTP tunnels. In case a consistent marking scheme across all layers and technologies is ensured by the QRULE entity, the QEN does not need to change the existing configuration of the network elements.

In the case of a mobile network with GTP tunnelling the marking has to be performed within the GTP tunnel as well as outside. The outside marking enables routers to apply differentiated packet handling also on GTP encapsulated flows without requiring a new configuration. For IPsec encrypted GTP the marking also has to be included into the IPsec header to avoid per hop decryption/encryption. The inner and outer IP markings are set in downstream direction by the SGW/PGW and in upstream direction by the eNodeB based on the flow information (five tuple) and the PFB obtained from QMON. During handover the five tuple and the PFB are automatically transferred to the new eNodeB that is known from the Mobility Management Entity (MME). As a third option -in case that the predefined packet handling configuration of the routers should not be used -the ISAAR framework is also able to perform a fully automated router configuration [START_REF] Eckert | Analyse und automatisierte Konfiguration klassenbasierter Paketvermittlung[END_REF]. With that, the QEN may explicitly change the router packet handling behaviour (e.g. packet scheduling and dropping rules) to influence the flows. With the SDN approach there is a fourth possibility to influence data flows by using OpenFlow features. For example, the priority of a flow can be changed in the forwarding configuration directly in an OpenFlow switch action list configuration. Furthermore, flow-specific traffic engineering could be realized. In order to use the OpenFlow features for flow enforcement ISAAR is connected to the control interfaces of the SDN enabled switches.

Summary

The ISAAR framework presented in this paper addresses the increasingly important quality of experience management for Internet based services in mobile networks. It takes the network operator's position to optimize the transport of packet flows belonging to most popular video streaming, voice, Facebook and other web services in order to satisfy the customer's service quality expectations. The framework is aware of the 3GPP standardized PCC functionality and tries to closely interwork with the PCRF and PCEF functional entities. However, 3GPP QoS control is mainly based on dedicated bearers and observations in today's networks reveal that most Internet services are carried undifferentiated within the default bearer only. ISAAR therefore sets up a three component logical architecture, consisting of a classification and monitoring unit (QMON), a decision unit (QRULE) and an enforcement unit (QEN) in order to selectively monitor and manipulate single service specific flows with or without the standardized 3GPP QoS support. This is mainly achieved by priority markings on (potentially encapsulated) service flow packets making use of the commonly available priority and DiffServ capabilities in layer two and three forwarding devices. In the case of LTE networks, this involves the eNodeBs and SGWs/PGWs for selectively bidirectional marking according to the QRULE determined service flow behaviour. More sophisticated mechanisms for location aware service flow observation and steering as well as direct router respectively OpenFlow switch configuration access for traffic engineered flow routing are optionally available within the modular ISAAR framework.

Due to the strong correlation between achieved video streaming QoE and customer satisfaction for mobile data services, the high traffic volume share of YouTube video streaming services are tackled first in the on-going ISAAR implementation activity. An optimized network-based precise video QoE estimation mechanism is coupled with automated packet flow shaping and dropping means guided by a three level play out buffer fill level estimation. This way, a smooth play out with reduced network traffic demand can be achieved. To prove the functionality of the network based video QoE estimation a demonstrator has been implemented which is capable of offline packet trace analyses from captured traffic as well as real time online measurements.

Since ISAAR is able to work independently of 3GPP's QoS functionality, it can be used with reduced functionality in any IP based operator network. In such setups, the service flow QoS enforcement would rely on IP DiffServ, Ethernet priority and MPLS LSP traffic class marking as well as SDN based flow forwarding only.

Table 1 : Per Flow behaviour settings (example)

 1

	Media	Key Perfor-	IP DSCP	OpenFlow	Ethernet	MPLS	3GPP	Action
	Type	mance Indicator		Actions	Prio	Traffic	QCI
						Class
	Video	Buffer Level in	CS5	set normal	101	101	6	Mark in S/P-GW
		Sec.	101 000	priority				and eNodeB with
		Th1 < t < Th2						high priority
		Buffer Level in	"Expedited	Change path	111	111	4	Mark in S/P-GW
		Sec.	Forwarding	+ set high				and eNodeB with
		t < Th1	(EF)"	priority				highest priority
			101 110
		Buffer Level in	"Best Effort	set low priority	000	000	9	Mark in S/P-GW
		Sec.	(BE)"					and eNodeB with
		Th2 < t	000 000					default priority or
			or even					even start drop-
			"Lower Effort					ping packets
			(LE)"
			001 000
	Voice	Delay in ms	EF	Choose best	111	111	4 & 1	Mark in S/P-GW
			101 110	path + set high			or 2	and eNodeB with
				priority				highest priority or
								even
								Create dedicated
								bearer with QCI 1
								or 2
	Face-	Page load time	CS5	Choose best	101	101	6	Mark in S/P-GW
	book		101 000	effort path				and eNodeB with
				+ set normal				high priority
				priority
	…


Torsten Teubler
email: teubler@fh-luebeck.de

Mohamed A Hail
email: hail@fh-luebeck.de

Horst Hellbrück
email: hellbrueck@fh-luebeck.de

Efficient Data Aggregation with CCNx in Wireless Sensor Networks

Keywords: Content Centric Networking, Aggregation, Wireless Sensor Networks, Internet Integration, Future Internet

CCNx is the reference implementation for a content centric networking (CCN) protocol developed by the Palo Alto Research Center CCNx group. It serves also as reference for our CCN-WSN, a CCNx implementation for wireless sensor networks (WSN). Efficient data aggregation with CCN-WSN is a challenge. In order to collect data from source in the network data sinks have to poll data sources with interests and exclude fields in interests are necessary bloating the interest messages. We solve the problem by introducing three building blocks in CCN-WSN: unicast faces for packet filtering and "link" abstraction, a forwarding service for creating network overlay structures used by applications and an intra-node protocol providing an API for applications to interact with the forwarding service. For evaluation purpose we implement an application using a forwarding service implementing a tree topology to collect data in the WSN.

Introduction

Wireless Sensor Networks (WSN) and Content Centric Networking (CCN) are two emerging technologies. WSN consist of spatially distributed often batterydriven autonomous sensors to monitor physical or environmental conditions. They gather real world data in applications like habitat or industrial monitoring, or agriculture. Data is processed in the network and aggregated information is provided to a gateway or a data sink within the network. Several WSN approaches use specialized routing and processing protocols which are different from today's protocols in the Internet. Recent approaches foresee even the use of IPv6 stacks [START_REF] Montenegro | Transmission of IPv6 Packets over IEEE 802[END_REF] on sensor nodes.

The Internet Protocol IP addresses nodes via hierarchical addresses based on location. However, users are interested in content and information instead of the location of data. To overcome this issue content centric networking (CCN) approaches have been developed in the recent past. CCN addresses data itself instead of the location where data is stored.

Users of WSN are also interested in content instead of the nodes that retrieve this content. Consequently, a content centric approach fits well in the WSN domain.

One emerging and advanced implementation in content centric networking is the CCNx protocol [START_REF] Jacobson | Networking Named Content[END_REF]. We have recently implemented CCN-WSN [START_REF] Zhong | CCN-WSN -a lightweight, flexible Content-Centric Networking Protocol for Wireless Sensor Networks[END_REF] a CCNx derivate which covers a subset of CCNx functionality.

In this paper we add the following contributions:

-We suggest unicast faces for wireless broadcast networks that enable packet filtering and provide a "link" abstraction. -We propose a forwarding service for creation of overlay structures, that offers efficient forwarding. -We develop an intra-node protocol as an API for applications to interact with forwarding services.

Section 2 discusses related work. Section 3 introduces fundamentals of CCNx. A problem statement for different request types is given in Section 4. Section 5 describes the concept followed by implementation details in Section 6. An example in Section 7 implements a forwarding service and an application. Section 8 concludes this work and discusses further topics of research.

Related Work

In this section we discuss related work in the area of routing, data exchange, and data aggregation in content centric networking (CCN) and wireless ad-hoc networks.

The goal of research of routing in CCN is efficient data delivery to requesters based on content names. The goal of [START_REF] Lee | An Energy-Efficient Routing Protocol for CCN-based MANETs[END_REF] and [START_REF] Sun | DHR-CCN, Distributed Hierarchical Routing for Content Centric Network[END_REF] is to reduce the overhead of interest routing in CCN by adding different information to the interest message like frequency of node usage. Interest routing needs extra mechanisms to route interests to certain nodes (unicast), otherwise interests are flooded. Our approach uses a forwarding service and unicast faces to route the content efficiently. [START_REF] Yuan | Scalable NDN Forwarding: Concepts, Issues and Principles[END_REF] argue that Named Data Networking (NDN) forwarding is complicated and challenging. The main concept of this approach is to reach large scale flows for efficient forwarding in NDN. The authors do not consider data traffic and network load for the total network using this approach.

Neighborhood-Aware Interest Forwarding (NAIF) [START_REF] Yu | Interest Propagation In Named Data MANETs[END_REF] achieves bandwidth reduction of interest flooding by forwarding only fractions of interest packets at eligible relays. A similar approach is introduced in [START_REF] Meisel | Ad Hoc Networking via Named Data[END_REF] and [START_REF] Meisel | Listen First, Broadcast Later: Topology-Agnostic Forwarding under High Dynamics[END_REF]. The authors discuss the forwarding of Interest messages based on the hop distance from the previous forwarder to the destination. [START_REF] Yu | Interest Propagation In Named Data MANETs[END_REF], [START_REF] Meisel | Ad Hoc Networking via Named Data[END_REF] and [START_REF] Meisel | Listen First, Broadcast Later: Topology-Agnostic Forwarding under High Dynamics[END_REF] virtually forward interests, whereas our approach forwards content objects.

The authors in [START_REF] Daras | Similarity Content Search in Content Centric Networks[END_REF] propose an approach to support content search and content retrieve as a native process of the network. The authors indicate that only end user has the possibility to aggregate data in the network. In contrast to our approach, intermediate nodes can aggregate data. Additionally, this approach is designed for PCs running Linux OS. Our approach is implemented on resource constraint devices in WSN like sensor nodes.

To the best of our knowledge, we are the first to propose a concept for data aggregation in WSN using CCNx implementation. Our approach is compatible to CCNx and therefore interoperable with existing CCNx implementations.

CCNx Overview

This section introduces to CCNx and highlights some features we use in this work. More detailed information is available on CCNx technical documentation web page [START_REF]CCNx Technical Documentation[END_REF] and [START_REF] Zhong | CCN-WSN -a lightweight, flexible Content-Centric Networking Protocol for Wireless Sensor Networks[END_REF].

Figure 1 illustrates the CCNx node model with the daemon and its main data structures Content Store (CS), Pending Interest Table (PIT), and Forward Information Base (FIB) on the left hand side. Applications, services, and physical interfaces (e.g. network interface cards) communicate via the CCNx daemon using faces. Faces in CCNx are a generalization of an interface comparable to TCP/IP sockets. In CCN-WSN the radio is a broadcast face that allows forwarding of interests and content within the network.

Message types in CCNx are interests and content objects. Interests request content objects by name.

CCNx follows a hierarchical naming scheme using the slash ("/") as name component delimiter. It is recommended that the first component is a registered unique DNS name to avoid name clashes among different content providing authorities. CCNx content names contain ASCII characters and bytes coded as two hexadecimal digits with a preceding percent character ("%"). A valid CCNx content name for example is: /fh-luebeck.de/forward/%C1.de.fhl.tree~1~17~0.

Interests are sent by applications or services. At interest reception, the daemon looks up the CS if it contains a content object matching the interest name. An interest name matches a content name, if the interest name equals the prefix of the content name and the prefix is the longest prefix among all compared content names. If no content object matches in the CS, the PIT is searched. If the PIT contains a matching interest, the incoming face of the recent interest is added to the list in this PIT entry. This allows forwarding incoming content objects matching this interest to that face as well. If no entry in the PIT matches, the FIB is searched for a matching face to forward the interest. If no matching face is found the interest is discarded. Otherwise the interest is forwarded to this face and an entry is created in the PIT. One important feature of interests is that they can have an optional scope to control the interest dissemination. Scope 0 means that an interest forwarded only to the daemon, scope 1 forwards an interest to the applications/services, and scope 2 forwards an interest to the neighboring nodes. Interests have a lifetime which is set by the originator.

Content objects are sent only as a response to an interest. They are stored in a CS and arrive through faces generated by applications or services. On reception of a content object the CS is searched and if a matching content object is found the new content object is discarded to avoid unnecessary copies of duplicated content. If no entry in the CS matches, the PIT is searched. If a matching interest is found in the PIT the content object is forwarded to the list of faces of that interest and stored in the CS for the lifetime of the content object. As the interest is satisfied the corresponding entry is removed from the PIT.

Problem Statement

This section discusses the problem of data aggregation with standard CCNx and CCN-WSN forwarding mechanisms for two request types. We distinguish between any and all requests.

Any Requests. An any request is the standard request type in CCNx. A node requesting some content sends an interest and receives exactly one matching content object from any node providing this content.

This situation is depicted in Figure 2. Node 17 is interested in some content. Nodes holding content objects matching the interests name are depicted in black. In the first step node 11, 15 and 19 have the available content. Node 17 sends an interest through the network along the communication links (dashed arrows in Figure 2(a)). However, node 19 does not forward the interest because it is able satisfy it.

The nodes forward the content objects back to the face the interest arrived. E.g. content object from node 19 reaches node 13 (Figure 2(b)) and is forwarded to node 17 (Figure 2(c)). Content object providers add additional information e.g. node id as name suffix which allows the originator of the request to learn about the content provider.

As node 13 already stored and forwarded the content object, the content object from node 11 is either stored but not forwarded because there is no matching interest or discarded if it is a duplicate. This behavior of CCNx is intentional by design and reasonable if the content of the matching content objects is identical.

However, if we consider that sensor nodes observe e.g. temperatures and an application sends an interest for temperature this application retrieve a temperature value from any node. In standard CCNx behavior, one node "wins". For many applications any requests are not satisfying e.g. when an average temperature is requested. For this case we need another type of request.

All Request. In contrast to the previously described any request the result of an all request is data provided from all nodes that originate this data under a specific name. Examples of all requests may include a list of all measurements or aggregated values like average, min or max values.

Standard CCNx supports only any requests but it is possible to build all requests with CCNx exclude mechanism. Excludes are content names added as field to an interest to avoid these content names from matching this interest. To make content objects unique the CCNx daemon adds a digest (SHA-256 digest of the encoded content object) as last component of the content objects name when provided by an application. In our CCN-WSN application the daemon adds the node identifier as a name component. By this mechanism every content name is unique.

Invoking an all request using excludes works as follows: an any request is sent and a content object is received. Using the name of the received content object in an exclude in a further any request, a second content object is delivered different from the first one. All content objects can be fetched from the network with that name prefix by iterative sending of any requests using excludes.

This approach works well but has some obvious drawbacks. For every content object an interest has to be sent. Even if some content objects got stored in nearby nodes as a result of the first interest-like the content object from node 11 stored in node 13 in Figure 2(c)-this is a significant overhead. Furthermore, not all content objects come closer to the requester by iteratively sending interests, see content object from node 15 Figure 2(c) Excludes occupy significant space in the message. This approach does not scale with the number of nodes in the network because messages have a limited length determined by the maximum transfer unit (MTU) of the physical layer.

These issues limit the use of CCNx with wireless resource constrained (especial energy constrained) devices. Sending takes a lot of energy and the MTU is very limited (e.g. 127 Byte with IEEE 802.15.4) in WSN. Our concept adds three main components to the CCNx-Model: forwarding service, unicast faces, intra node protocol as illustrated in Figure 3. This section introduces these components and their functionality.

Forwarding Service. The forwarding service builds an overlay network on top of the wireless broadcast network. This forwarding service provides efficient forwarding mechanisms for applications on top of existing CCNx forwarding mechanisms like the forwarding information base of the daemon. To save resources the overlay is constructed on demand of the application like a reactive routing protocol in ad-hoc networks. Furthermore, the forwarding service hands data to applications to allow aggregation of the data. Aggregated data from the application will be forwarded to the next node in the network by the forwarding service.

Unicast Faces. For WSN devices explicit faces based on TCP or UDP sockets across a network are not available like in the CCNx reference implementation. In wireless broadcast networks the radio is a broadcast face sending all interests and content objects to the neighborhood. Figure 4 illustrates this behavior for a single interest and content message exchange. In this scenario links between all nodes exist. In Figure 4(a) an interest with scope 2 is sent from node 1 to the neighbors node 2 and 3 (see dashed line) matching the content object stored on node 2. With the radio as broadcast face like illustrated in Figure 4(b) the content object is stored at node 3 as well because the content object matches the previously received interest from node 1. Node 3 will forward the content again to node 1.

With unicast faces in Figure 4(c) the content object is only stored and cached on node 1. Node 3 rejects the message because the destination address of the message of the content object is node 1. WSN benefit from reduced number of messages and less processing. Unicast faces are a basis for our forwarding service as inter node communication is now well under control and predictable. Intra Node Protocol. The intra node protocol allows an inter process communication between services and applications using CCNx command marker technique. Interests with command marker (so called commands) of an intra node protocol have scopes smaller or equal to one to avoid interest propagation beyond the node and use a special name component intra node.

Summarizing the concept, we foresee support for several applications e.g. one for each sensor and our approach is fully compatible with CCNx using only standard CCNx features. Therefore, it can be applied to all existing CCNx implementations. Implementation details are presented in the next section.

Implementation

In this section we describe the implementation of the unicast faces and the intra node protocol of our approach using CCNx. An example implementation of a forwarding service is given in Section 7.

Unicast Faces. Unicast faces are implemented as a part of the radio service depicted in Figure 3. The requirement is that the radio layer uses some node addressing scheme and radio packets include destination and source addresses. The service establishes a new unicast face automatically if a broadcast interest (destination is the broadcast address) from a neighboring node is received. The radio service maintains a mapping this new face and the neighbor address. Unicast faces have a limited lifetime. When links break the resources on the node are released.

Intra Node Protocol. Communication between applications and services is performed via faces and the daemon. For our approach we suggest an intranode protocol for communication with the forwarding service. Figure 5 shows a message exchange between forwarding service, CCNx daemon, and aggregation application(s) in a path time diagram. The intra-node communication is identified by the name component intra node. In the example presented here the aggregation application communicates with the forwarding service. Dashed arrows depict interests, solid arrows depict content objects. Interests with scope 0 are sent to the daemon only, whereas interests with scope 1 are forwarded to At node startup the application registers at the forwarding service. This interest (.../intra node/%C1.de.fhl.app~N) is implemented as a command denoted by the command marker %C1 with one parameter N (delimited by a tilde character ("~")) identifying the application. Application identifiers need to be globally unique and the same for all applications in the network. When a forwarding service receives this interest it sends an interest (.../intra node/%C1.de.fhl.appContent~N) also implemented as command with one argument (application identifier) and with scope 0 to receive content from the application. With the application identifier the forwarding service distinguishes between multiple applications running on a node. The lifetime of the two initial interests is as long as the predicted application lifetime.

If a content object is received from a neighboring node the forwarding service changes the name of this content object to same name of the interest sent from the application during the application registration to match even this interest. When the application receives a content object, it sends an interest with scope 0 to be able to receive further content objects from the forwarding service. This is necessary in the case where data from several nodes has to be collected for aggregation.

The application receives content objects from the forwarding service and processes the data. When the application finishes processing the data, it sends a content object matching the name of the interest sent during application registration by the forwarding service. An example for interaction of intra and inter node communication is provided in Section 7.

When the forwarding service receives a content object from the application it will then forward the content object with a new name on the network. As the interests from the application registration are satisfied the application registration has to be performed again.

Example of Data Aggregation

This section describes an implementation of a forwarding service as a proof of concept. The forwarding service named tree forwarding in this example constructs a directed tree. Along this tree data is forwarded by the service to the sink while it is collected and aggregated by the application. The application we implemented is a simple WSN node discovery which concatenates received lists (maybe empty) of node id's and adds its own node id.

Our example implementation has three phases. In phase zero the application registers as already described in Section 6. In phase one the tree is constructed. In phase two data is forwarded along the tree, collected and aggregated on the nodes. We describe phase one and two in detail in the following.

Phase One: Tree Construction. Figure 6 illustrates the steps for creating a tree graph according to [START_REF] Garcia-Luna-Aceves | Source-Tree Routing in Wireless Networks[END_REF]. Rectangles in Figure 6 aside the nodes show received interests. These interests are additionally stored in the tree forwarding service to make forwarding decisions later. In Figure 6(a) a tree construction interest (.../%C1.de.fhl.tree~1~17~0) is sent from node 17 because it is the sink in our example. The name follows the CCNx command message format with command name tree from namespace de.fhl. The first parameter is the application id ("1" in this example), the second parameter is the sender id and the third is a hop count. All tree construction interests are sent with scope 2 to reach the neighboring nodes only.

When the forwarding service receives a tree construction interest with a hop count smaller than its own interest it sends a new tree construction interest by adding its node id as second parameter and incrementing the hop count ( Phase Two: Forwarding. The end of phase one is detected if no more interests are received by the nodes for a certain time.

In phase two, the forwarding service of a leaf node starts to send data. Leaf nodes can be identified as the forwarding service has not received any tree construction interest from neighbors with a higher hop count.

The tree forwarding service sends a content object without data via the intranode protocol (see Section 6) to the application. The application itself sends a content object back to the forwarding service containing the current data (node id) using the intra node protocol.

Figure 7(b) shows an example where node 14 forwards data. At node 14, the forwarding service sends a content object named .../intra node/%C1.de.fhl.app~1 with empty data. The application sends back a content object named .../intra node/%C1.de.fhl.appContent~1

…~1~17~0 …~1~12~1 ...~1~13~1 …~1~17~0 …~1~13~1 …~1~12~1 …~1~17~0 …~1~13~1 …~1~12~1 …~1~16~2 …~1~10~2 …~1~19~2 …~1~13~1 …~1~16~2 …~1~18~3 …~1~11~3 …~1~13~1 …~1~10~2 …~1~14~3 …~1~13~1 ...~1~19~2 …~1~14~3 …~1~15~3 …~1~16~2 …~1~11~3 …~1~16~2 …~1~18~3 …~1~10~2 …~1~19~2 ...~1~14~3 …~1~19~2 …~1~15~3 (d) Step 4 (Finished)
Fig. 6. Phase 1: Tree construction containing data, in our example the node id 14. Content received from the application is forwarded by the forwarding service along the tree. The forwarding service changes the name of the content object received by the application to .../forward/%C1.de.fhl.tree~1~10~2 to forward the content to node 10. Node 10 is chosen because the interest from node 10 has a hop count less than the own hop count. The content object is forwarded on the unicast face the interest arrived. If several interests with a smaller hop count are available one of them is chosen.

The tree forwarding service on node 10 receives the content object. The received content objects name is changed to .../intra node/%C1.de.fhl.app~1 and handed to the application the same way as in node 14. At node 10 the aggregation application waits for content objects from all neighbors upwards the tree, aggregates the data and sends it to the tree forwarding service.

A special case occurs at node 19. Node 19 waits for data from node 14 and node 15. However node 14 forwarded data already to node 10. Therefore, intermediate nodes send their content object after a timeout even though they have not received the content object from all neighbors upwards the tree. Data is continuously forwarded until the sink is reached as shown in Figure 7(a). When a content object is received the interest with the matching name is removed from the PIT. Therefore, the forwarding service resends the interest with scope 0 to be able to receive further content objects matching the interest. Resending these interests is important e.g. in Figure 7(b) node 13 will receive content objects from node 16 and 19 as well. As all interests have a certain lifetime the tree discontinues if no more content objects are sent.

In this section we presented tree forwarding as an example implementation of a forwarding service. As an example application we implemented a node discovery providing a list of all nodes available in the WSN.

Summary and Outlook

In this paper we have motivated the need for a further development of CCN-WSN to achieve efficient data aggregation in wireless sensor networks. Our approach extends CCN-WSN by three major components: unicast faces to reduce the number of message in a broadcast medium, forwarding service to create overlay structures on a given physical topology, and an intra-node protocol for communication between applications and the forwarding service. The daemon as the main component and the interfaces of CCN-WSN (and CCNx respectively) are unchanged in this approach. The communication between the components follows the basic mechanisms of CCNx. We have shown in an example implementation that a tree routing can be easily integrated with this approach.

In the future we will perform an evaluation against 6LoWPAN and CoAP. We foresee that using CCN straight away on top of IEEE 802.15.4 will provide an efficient solution with less overhead. Furthermore, we will add applications and semantic functionality to query wireless sensor networks. To improve the performance we will provide a compression scheme for the content names and implement persistent memory for content. Furthermore, we will add lightweight security measures in the implementation to prevent passive and active attacks against CCN and design and implement a gateway for seamless integration of CCN-WSN into CCNx implementation.

Fig. 1 .

 1 Fig. 1. CCNx Node Model

Fig. 2 .

 2 Fig. 2. Any Request: Nodes with matching Content are marked in black

Fig. 3 .

 3 Fig. 3. Conceptual overview of our node model

Fig. 4 .

 4 Fig. 4. Need of unicast faces with wireless ad-hoc links

Fig. 5 .

 5 Fig. 5. Path Time Diagram of the Intra-node Protocol

  Figure 6(b)). Newly received interests are highlighted in bold face in Figure 6. For simplicity we show only the parameters instead of the whole interests beginning from Figure 6(b). As the network in our example has three hops from the sink tree construction takes four steps. Step three is illustrated in Figure 6(c). Figure 6(d) shows the final result of the tree construction process before phase two starts.

  17

Fig. 7 .

 7 Fig. 7. Phase 2: Forwarding

Table for mapping Face ßà Receiver Physical Radio Interface

Acknowledgments

This work was funded by the Federal Ministry of Education & Research of the Federal Republic of Germany (17PNT017, DataCast). The authors alone are responsible for the content of this work.


Marco Porsch
email: marco.porsch@etit.tu-chemnitz.de

Thomas Bauschert
email: thomas.bauschert@etit.tu-chemnitz.de

A Testbed Evaluation of the Scalability of IEEE 802.11s Light Sleep Mode

Keywords: wireless mesh networks, IEEE 802.11s, power save, green networking, energy efficiency

établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Today's smartphone users are struggling with the low battery runtime of their devices, as standby times of just one day average have become quite common. As groundbreaking new battery technologies are yet to be found, increasing the energy efficiency is the task at hand. Concerning the power consumption for connectivity, Wi-Fi is already a better choice than cellular for its higher rate and overall better energyefficiency under network load [START_REF] Castignani | Energy Considerations for a Wireless Multi-homed Environment[END_REF]. In the next generation of smartphones the Wi-Fi functionalities may be extended with the wireless mesh network amendment IEEE 802.11s, which-among other features-allows sharing multimedia contents without requiring the presence of an access point. 802.11s is a standard for wireless mesh networks based on regular Wi-Fi hardware as commonly found in today's laptops and mobile phones. It allows simple connectivity of user devices, similar to Wi-Fi Direct, but also allows meshed multi-hop connectivity when partaking in bigger networks. In IEEE 802.11s networks all mesh nodes are true peers and share the same behavioral rules. Concerning power save, this allows employing equally sophisticated power save schemes on all nodes. Of course there are also new issues; while in managed mode the client has to schedule only the access point's periodic beacon transmissions, in the meshed connectivity of 802.11s the power save scheme has to take all peers into account for its sleep schedule. In this paper we focus on the case of an idle network with no user data being sent or received. For typical user devices this case is very relevant: a smartphone rests in standby state in the user's pocket most of the time and just periodically checks for incoming mails; a laptop or tablet does not send or receive data while the user is reading a web page. Conserving energy in these situations is most crucial for proper battery runtime. Key contributions of this paper are testbed measurements of the IEEE 802.11s power save algorithm's effects on current consumption and an analysis of its scalability with respect to an increasing number of peers. The paper is structured as follows: section 2 gives an introduction on the main concepts of IEEE 802.11s power save before section 3 shows and interprets measurements done in our mesh testbed. Subsequently, section 4 concludes and summarizes this paper.

IEEE 802.11s Power Save

The 802.11s power save schemes are defined in the IEEE 802.11 standard for wireless LAN [START_REF]11™-2012[END_REF] which, in its 2012 revision, incorporates the 802.11s amendment of 2011. All 802.11 family protocols have a common approach to power save; for saving energy the radio is suspended in times of no activity. With the complex receiver baseband processing disabled the device power consumption is reduced drastically. This makes it more useful than transmission power control as it especially allows idle nodes to conserve energy. Also, without any receiver interrupts, the CPU may spend more time in low power sleep states. The radio will be reactivated for sending a packet or for a scheduled receipt, e.g. of a neighbor beacon.

To reliably schedule doze and wakeups in any of the 802.11 family power save schemes, a tight synchronization is required. The time reference is given by maintaining a local clock and transmitting beacon frames periodically at the TBTT (target beacon transmission time). Dissimilar to wireless LAN ad-hoc and managed mode, mesh mode does not shift the TBTT to a common time; instead, it focuses on keeping the arbitrary offsets between the TSF and TBTT of neighboring nodes constant in the presence of imperfect reference clocks. With the time references synchronized, a power save schedule may be set up to doze and wakeup according to the neighbor TBTTs. Again, the IEEE 802.11s schemes differ from those of managed and ad-hoc mode. Other than waking up at the singular IBSS or access point TBTT in mesh mode there are multiple wakeup events given by multiple peer TBTTs and the own beacon transmission. Also while infrastructure and ad-hoc WLAN employ just a singular power mode towards all neighbors, in IEEE 802.11s the power mode is set for each peer link individually by both parties. This power mode is not a binary representation of power save being on or off; instead three power modes are defined: active, light sleep and deep sleep mode. A link in active mode may receive packets anytime and therefore the radio cannot be suspended at all. A peer link in light sleep mode will only receive packets at certain times. This allows suspending the radio while there are no receipts scheduled on any link. A link in deep sleep mode behaves similarly but the amount of wakeups-and also the possible performance-is further reduced.

Links operating in deep sleep mode require special routines for synchronization and frame forwarding which are left undefined in the 802.11 standard. Therefore, we will focus solely on light sleep mode in the remainder of this paper. The link-specific power mode currently used is announced in unicast frames towards the corresponding peer. If any of a node's links is in power save mode, this is also indicated in broadcast frames. The standard leaves the rules defining which power mode to choose for a link up to the implementation.

Fig. 1 illustrates the behavior of a peer link in light sleep mode; here both peers A and B are in light sleep mode towards each other. In this example no further links are established and the sleep/doze schedule is solely determined by the own and the single peer's TBTT. After waking up to transmit its own beacon, node A stays awake for the awake window duration, which is advertised in an information element within the beacon. During this time interval peer B may transmit frames to A. After the awake window passed, node A resumes its doze. B wakes up just before the TBTT of its light sleep peer A to receive its beacon frame. Equally, peer A will later wake up before B's TBTT to receive its beacon. This process repeats periodically with the beacon interval. Beacon frames may contain a TIM (traffic indication map) information element with information about buffered frames, which may be polled during the awake window as part of a subsequent Peer Service Period. For more information on traffic forwarding on mesh links in light sleep mode we would like to refer the interested reader to [START_REF] Porsch | A Testbed Analysis of the Effects of IEEE 802.11s Power Save on Mesh Link Performance[END_REF] where we examine this topic using testbed measurements or to [START_REF] Alam | Performance Study of IEEE 802.11s PSM in FTP-TCP[END_REF] where similar research has been conducted by Alam et al. using ns-2 simulations.

An issue of the IEEE 802.11s power save algorithm is its scalability concerning the number of peers; with more peers more wakeups are necessary when links are in light sleep mode. Theoretically, this should not be much of an issue, as the time needed to receive a mesh beacon is typically very low compared to the beacon interval. But to the actual receive time there are additional delays due to CSMA channel access and the delays for powering up the receiver's radio, processing the beacon and resuming doze.

Testbed Implementation and Results

In order to evaluate the power save algorithm of IEEE 802.11s we chose to test it under real-life conditions in a testbed. In cooperation with cozybit Inc. [5] we implemented the routines necessary in the Linux kernel's Wi-Fi stack [START_REF]Linux Kernel wireless driver API for SoftMAC devices, mac80211 kernel module source code[END_REF]. Most of these are made open source and are available in current Linux distributions. Given suitable hardware, the full range of the 802.11s power save schemes can be implemented in software. In our testbed we used two types of off-the-shelf Wi-Fi routers using the "ath9k" device driver: Netgear WNDR3800 and TP-Link TL-MR3020. In our test setup we measured the overall device power consumption which also includes unrelated power sinks like CPU, Ethernet controller and others. We used a 1Ω shunt resistor in line with a lab voltage supply of 12V for the WNDR3800 and 5V for the TL-MR3020. The measurements are plotted with a Tektronix TLS-216 digital oscilloscope and logic analyzer. Unless defined differently all plots use a sampling rate of 1kS/s and a scale of 50mV/div vertical and 200ms/div horizontal. To reduce transients and noise effects all plots shown use an averaging factor of 10. Fig. 2 shows the doze and wakeup cycle during one beacon interval for a single peer link with both nodes in light sleep mode. Clearly visible is the sharp spike in power consumption when the beacon frame is transmitted followed by the awake window. The spike of the lower plot serves as trigger source for the oscilloscope. Both nodes are configured with an awake window duration of 100TU and a beacon interval of 1000TU. It can be seen that just before one node transmits its beacon, the peer node wakes up to receive it and goes back to doze just afterwards. When compared to Fig. 1 it is visible that the testbed implementation precisely follows the standard's mandate. The upper plot is the WNDR3800 with current levels of 337mA in doze and 390mA in awake state, the lower plot corresponds to the TL-MR3020 with 108mA and 139mA readings. The area under the graphs between the drawn reference bars corresponds to the current consumption per beacon interval of both devices. Given that the network is idle, this curve will periodically repeat for each beacon interval. The oscilloscope readings show that the WNDR3800 consumes 352,81mAs per beacon interval, the TL-MR3020 112,59mAs respectively. The generally higher energy consumption of the WNDR3800 is due to the more complex design of this router model with its additional hardware and our measurement setup where we measure the overall device power consumption. Fig. 3 shows a similar setup as Fig. 2 but here both routers each have seven mesh peer links established. It is obvious that the current consumption is increased due to the further wakeups necessary; now the current consumption per beacon interval is 358,04mAs for the WNDR3800 and 118,16mAs for the TL-MR3020. In case the wakeups do not overlap, it can be expected that the energy savings will decrease linearly with increasing number of light sleep peers as each peer adds another wakeup per beacon interval. We can also expect that with a sufficient number of peers the doze ratio will decrease until the device is practically active full-time. It should be noted that wakeups may randomly overlap, thus reducing the overall awake time. We will subsequently assume the worst case scenario for power save which corresponds to the case of no overlapping wakeups. Fig. 4 shows the calculated effectiveness of the power save algorithm in relation to the number of established peer links. In the diagram the energy savings due to the power save algorithm are shown as percent value of the difference between the active mode consumption and the consumption with the Wi-Fi device off. The lower limit of 0% energy savings is given by the consumption in active state when the radio is never put to doze, while 100% energy savings would mean that the Wi-Fi functionality draws no power at all. In the graph a situation with zero peers achieves the maximum energy savings of around 80% for both devices. Here no additional wakeups are per- formed except for transmitting the own beacon every 1000TU and the subsequent awake window of 100TU in our setup. The remaining consumption of the Wi-Fi chipset is due to the mentioned beacon transmission and awake window, but also due to the now activated MAC coprocessor and host interface. One interesting observation is that the power save effectiveness decreases more rapidly for the TL-MR3020 router.

The linear interpolation shows that the WNDR3800 would be effectively awake fulltime with approximately 84 peers, the TL-MR3020 with 42 peers respectively. The reason for this effect may already be seen in Fig. 3 where the TL-MR3020 in the lower plot showed wider consumption spikes for its wakeups. Fig. 5 and Fig. 6 analyze the characteristics of a peer TBTT wakeup in more detail using a higher sampling rate of 50kS/s and a horizontal scale of 4ms/div. Here we measure about 12ms from waking up until resuming doze for the WNDR3800 and 23ms for the TL-MR3020. This is due to the different hardware of both router models with different revisions of the built-in Wi-Fi chipset and different processing power of the CPU.

Conclusion

In this paper we have analyzed and evaluated the IEEE 802.11s power saving schemes in terms of scalability. By implementing these schemes in the Linux kernel's Wi-Fi stack, we provide energy consumption measurements of off-the-shelf hardware.

Our results show that, even for the not power-optimized router hardware, considerable energy savings are achieved. We analyzed that-unless TBTTs randomly overlapthe efficiency of the power save algorithm decreases linearly with the number of light sleep peers. The reason for this decrease is that the power-saving node has to wake up from doze for each light sleep peer link individually. The slope of the efficiency decrease depends on the hardware employed. In future work will aim to solve these scalability issues while staying in compliance with the 802.11 standard. Furthermore, we will address open implementation issues of links in deep sleep mode and intend to perform measurements with respect to energy-efficiency in bigger networks.

Fig. 1 .

 1 Fig. 1. Wakeup scheduling of two peers in light sleep mode towards each other

Fig. 2 .Fig. 3 .

 23 Fig. 2. Doze/wakeup cycle of nodes with one peer link in light sleep mode

Fig. 4 .Fig. 5 .Fig. 6 .

 456 Fig. 4. Energy savings for increasing number of peers with common beacon interval


Chris Drechsler

Marco Porsch

Gerd Windisch

HTTP Traffic Offload in Cellular Networks via WLAN Mesh enabled Device to Device Communication and Distributed Caching

Keywords: HTTP caching, device-to-device communication, cooperative caching

Mobile network operators are currently observing a tremendous increase of mobile data traffic due to the increased usage of smartphones or other Internet-enabled devices (e.g. tablets, laptops). A natural solution for reducing the transmission costs and for improving the QoE is caching of frequently requested content. In this contribution we propose a distributed caching architecture where the clients perform the caching of frequently requested HTTP content by allowing a partial use of the user equipments memory for local caching. Furthermore we engage clients to exchange content via WLAN mesh enabled device-to-device communication in order to offload traffic from the 3GPP radio access network.

Introduction

Internet usage has significantly evolved in the last few years and the growing data traffic contributes substantially to risings costs for network operators. Especially cellular network operators observe a tremendous increase of mobile data traffic due to increased usage of smartphones or other Internet-enabled devices (e.g. tablets, laptops). According to a recent study of Cisco [START_REF]Cisco visual networking index: Global mobile data traffic forecast update[END_REF] the global mobile data traffic grew by 70 % in 2012. To cope with the increasing data traffic in mobile networks and to reduce transmission costs, caching of frequently requested content within operator networks is a natural solution. Recent studies have shown that HTTP traffic accounts for up to 82 % of the average downstream traffic in mobile networks [START_REF] Erman | To cache or not to cache: The 3g case[END_REF] and that the potential of HTTP caching is quite high. Between 28 % -68 % of all bytes transferred via HTTP are basically cacheable [START_REF] Erman | Network-aware forward caching[END_REF], [START_REF] Ager | Revisiting cacheability in times of user generated content[END_REF].

In this context we investigate the question of applying caching in mobile networks. An obvious approach would be to deploy classic HTTP cache systems like Squid [1] at different locations within the core network of the mobile operator, e.g. at S-/P-GW sites. In contrast to that we propose a distributed caching approach where the clients perform the caching of frequently requested HTTP content. By allowing a partial use of the user equipments (UEs) memory for local caching (which is free of charge from the operators perspective), clients are engaged to share their already downloaded HTTP content with other clients. Besides the 3GPP air interface for default Internet access, we assume that the clients in parallel participate in an open WLAN mesh network via their WLAN interface. Thus, by device-to-device communication over the WLAN mesh network they can directly support each other in retrieving frequently requested HTTP content.

The paper is organized as follows: Section 2 provides an overview of related work in the context of caching in cellular networks close to UEs (e.g. at eNodeB sites) and of device-to-device communication. In Section 3 the new distributed cooperative caching approach is described and detailed information about its operation is provided. Section 4 concludes the paper.

Related Work

Ahlehagh et al. introduced in [START_REF] Ahlehagh | Video caching in radio access network: Impact on delay and capacity[END_REF] new ideas for caching video content at base stations. They propose to provide a large number of micro-caches (with up to 50 GByte capacity) basically one micro-cache for each base station. Together with new replacement strategies they demonstrate the feasibility and effectiveness of caching at the edge of the RAN. However contrary to our work they do not consider a distributed and cooperative caching approach with caching performed in the UEs.

Most contributions related to device-to-device communication in cellular networks (like, e.g. [START_REF] Fodor | Design aspects of network assisted device-to-device communications[END_REF]) contrary to our work assume that 3GPP radio resources are used for the device-to-device communication. Thus the main research question is on how to opti-mally allocate radio resources for device to device communication and how to minimize interference.

Other contributions consider traffic offload in mobile networks via WLAN hotspots [START_REF] Ristanovic | Energy efficient offloading of 3g networks[END_REF]. In contrast to our work the focus is on offloading delay tolerant traffic to the Internet. WLAN is used in infrastructure mode and not for device to device com-munication.

Distributed cooperative HTTP caching

Our distributed and cooperative caching approach is based on three main concepts:

-HTTP header field extension distributed caching architecture distributed cache operation In the following, these main concepts are explained in more detail.

HTTP Header Field Extension

One reason for the partly unused caching potential is that todays HTTP cache systems like Squid [1] mainly rely on the URL to detect duplicate transfers. But mechanisms like server load balancing and the placement of content on several servers within CDNs often lead to different URLs for one specific resource (URL aliasing). Another reason is the personalization of HTTP messages (e.g. via cookies or parameters in the query string).

To overcome this issues we propose to use a hash key for identifying the HTTP content more precisely than with URLs. The hash value is computed over the specific representation of a requested resource and is added to the header of the HTTP response messages (see figure 1).

Distributed Caching Architecture

The distributed caching architecture consists of two main entities (see figure 3):

-Origin HTTP server: The origin HTTP server is located in the domain of the content producer and acts like a normal HTTP server but with one difference: it adds the above explained header attribute with the hash value of the requested resource to the header of the transferred HTTP message (for details see chapter 3.1). -Sharing Clients: Sharing clients are the UEs in the domain of the mobile operator. On the one hand they are connected to the Internet via the 3GPP air interface and on the other hand they participate in an open WLAN mesh network via their Wi-Fi interface in order to directly share resources with nearby UEs. The sharing clients consist of the following three sub-entities:

• User agent: Sharing clients can act like normal clients by retrieving web content with an ordinary user agent (web browser) like e.g. Firefox.

The only change in our architecture is that the user agent forwards the HTTP traffic to the smart proxy (see below). • HTTP server: The sharing clients are running a normal HTTP server which acts like a simple file server with a flat hierarchy. Shared resources can be identified and accessed by their hash value (see chapter 3.1).

To announce which resources are shared, the client offers an index. In our approach a simple xml file (called ClientCacheIndex.xml) is made available on the HTTP server of each sharing client (see figure 2). • Smart proxy: The smart proxy is located in the data path between the origin server and the user agent (web browser), see figure 3. It serves as a central element and manages the data exchange of web content. By default the 3GPP interface is used. In case that at least one sharing client participating in the WLAN mesh network has a copy of the requested content, the WLAN interface is used. For a detailed explanation of the cache operation see chapter 3.3. The smart proxy fulfills the following two basic functions: * Indexing: The smart proxy builds an index of all resources that are shared by nearby sharing clients. For that it periodically (e.g. every 5-10 minutes) scans the mesh network for available sharing clients/UEs and queries each of them for the index of its shared HTTP resources. * Analyzing HTTP traffic: To enable the distributed cache operation the smart proxy analyzes all incoming HTTP traffic on the 3GPP interface wrt. the HTTP header attributes (that includes the hash value of the transferred content). In case a copy of the requested resource is available by at least one nearby sharing client/UE the smart proxy intercepts the HTTP transfer from the origin HTTP server and retrieves the content from the nearby sharing client.

Distributed Cache Operation

To explain the distributed cache operation in more detail we provide the following example which is based on the scenario depicted in figure 3.

The user agent of client A sends a HTTP request message (method GET) for a desired resource to its smart proxy (1), which forwards it directly to the origin HTTP server [START_REF]Cisco visual networking index: Global mobile data traffic forecast update[END_REF]. The origin HTTP server answers with a HTTP response message (3) and adds the header attribute with the computed hash value of the requested resource to the header of the transferred HTTP message. The smart proxy of client A analyzes the incoming HTTP response message and looks for the header attribute (4). In the example it is assumed that the smart proxy recognizes that a nearby sharing client B in the WLAN mesh network has an object with the same hash value. Therefore the smart proxy sends a HTTP request message (method GET) for the resource to the HTTP server of client B (5) and the client returns a HTTP response message with the resource contained in the body [START_REF] Erman | Network-aware forward caching[END_REF]. Thus, the smart proxy receives the resource from both, the origin HTTP server via the 3GPP interface and the client B via device to device communication over the WLAN mesh network. It concatenates the HTTP header received by the origin HTTP server with the HTTP body received by client B and forwards the message to the user agent of client A [START_REF] Fodor | Design aspects of network assisted device-to-device communications[END_REF]. As soon as the transfer is successful established the smart proxy aborts the connection to the origin HTTP server [START_REF] Ristanovic | Energy efficient offloading of 3g networks[END_REF].

There are frequent concerns regarding the sharing of copyright protected content in the Internet. With our caching architecture this concerns are repealed. As explained above, the origin server is always requested. If it responds with a 2xx HTTP response code (and if the header field extension is applied) then the smart proxy can intercept the transmission and the content might be retrieved from a nearby sharing client. On the other hand this means that no content can be retrieved from sharing clients if the content isnt available on the origin server.

Conclusion

In this contribution we present a distributed caching approach where the clients (UEs) perform the caching and support each other in retrieving frequently requested HTTP content via device-to-device communication in a WLAN mesh network. We already implemented the concepts of our approach in a testbed where notebooks are used instead of UEs. Currently we are replacing the notebooks with real smartphones and are porting the software to Android OS. For future work we plan to perform a comprehensive performance evaluation of our approach

Fig. 2 .

 2 Fig. 1. HTTP header field extension

Fig. 3 .

 3 Fig. 3. HTTP data flow in the distributed caching architecture (example)


Daniel Kuemper
email: d.kuemper@hs-osnabrueck.de

Eike Reetz
email: e.reetz@hs-osnabrueck.de

Daniel Hölker
email: d.hoelker@hs-osnabrueck.de

Ralf Tönjes
email: r.toenjes@hs-osnabrueck.de

Test-Enhanced Life Cycle for Composed IoT-Based Services

Keywords: SOA, IoT, Test, Life Cycle, Composition, Deployment

Major challenges in developing services for the Internet of Things (IoT) are based on heterogeneous interfaces and radio technologies. This paper proposes a knowledge driven service life cycle, which enables a structured utilisation of semantic descriptions for re-usability and testing. Furthermore the approach facilitates the process of encapsulating IoT resources into services.

Introduction

Scalability and interoperability are key challenges in the composition of Internet of Things (IoT) applications by reusing existing IoT resources like sensors and actuators. The IoT.est project aims at surmounting available silo architectures with varying, partly proprietary interfaces by re-using Service-Oriented Architecture (SOA) approaches to ensure compliance, scalability and the ability to test and monitor IoT services. The main approach is to encapsulate the communication with heterogeneous IoT resources into Representational State Transfer based (RESTful) [START_REF] Thomas Fielding | Architectural Styles and the Design of Network-based Software Architectures[END_REF] services that are linked to an extensive, formal description of their functional and non-functional capabilities. The encapsulation prevents the need of re-implementing proprietary IoT resource interfaces for every invocation and enables the usage of widespread clients, proxies and analysis tools. The service descriptions, stored in a semantic knowledge management, ensure re-usability and the ability to find services for composition by providing extensive information about their in-and outputs as well as their Quality of Service (QoS) and Quality of Information (QoI). The service descriptions are also used to facilitate the (semi-) automated derivation of test cases [START_REF] Kuemper | Test Derivation for Semantically Described IoT Services[END_REF] to ensure service reliability.

This work assumes that a common understanding of the service life cycle is crucial in order to build successful IoT-based services [3][4]. To ensure a knowledge driven service composition and testing approach the annotation process of the service becomes eminent. While previous life cycle approaches like the classical V-Model or agile programming such as Extreme Programming have already considered techniques like test-first [START_REF] Andrea | Envisioning the next-generation of functional testing tools[END_REF] and test-driven development they did not explicitly describe the process of knowledge annotation. The proposed life cycle approach overcomes these limitations by adding a clear view of knowledge representation, annotation and the process of test derivation from this knowledge.

In this project the creation and composition of new services is guided by a service life cycle framework that is aligned to support a consistent workflow [START_REF] Reetz | Test Driven Life Cycle Management for Internet of Things based Services: a Semantic Approach[END_REF]. The service life cycle employed in the IoT.est project is outlined in the following sections towards a brief definition of the utilised service model.

IoT.est Service Model

This work utilises RESTful interfaces to encapsulate IoT services for enhanced reusability. It defines two types of services to ensure direct usage and composition of IoT services without dealing with heterogeneous interfaces:

The Atomic Service (AS) is a RESTful web service, accessing 0 -n IoT resources via their own individual interfaces and radio technologies. It enables access to these resources via standardised Get, Post, Put, Delete request methods, whose invocation is defined in a dedicated Web Application Description Language (WADL) document [START_REF] Hadley | Web application description language (WADL)[END_REF]. Input parameters as well as response documents of these methods are extensively described in the semantic knowledge management, to e.g. identify a specific service parameter not just as a double but rather as a temperature/Celsius value. The implemented AS can be deployed to a run time environment for web services and is registered in the knowledge management.

The Composite Service (CS) enables a business process-based composition of various AS and CS. It also provides a RESTful interface for service invocation and does not directly connect to IoT resources using their proprietary interfaces. It only uses AS and CS interfaces to acquire sensor information and to control actuators. The interfaces are also described by WADL and a semantic description to enable reusability.

Life Cycle Phases

The documentation of life cycle iterations is stored in the projects knowledge management component. The following sections describe the different phases and stages of the life cycle that can be followed in Fig. 1. Stages are represented by circles. Short arrows show typical stage succession. Larger curved arrows show shortcuts, which occur if needed amendments are identified.

Modelling

Modelling)

Crea-on)and) Composi-on)

Deployment) Execu-on) instan-ate)new)life)cycle) B) C) D) E) F) G) H) I) J) K) L) A)

Modelling)

Crea-on)and) Composi-on)

Deployment) Execu-on) instan-ate)new)life)cycle) B) C) D) E) F) G) H) I) J) K) L) A) ) ) ))))))Instan-a-on)to)create))))))))))))))))))))))))))))))
missing)services))

Fig. 1. Phases and Stages of the Service Life Cycle

Outcomes: A human readable description of the functionality/goal of the service (e.g. for an atomic service: providing the heart rate of patients; for a composite service: providing monitoring and alarm functionality for patients with cardio-vascular issues). This description also includes non-functional capabilities like QoS requirements derived from the desired user experience and estimated usage.

Stage B: Service Modelling

Description: Identification of a technical realisation to achieve the goal of stage A.

Outcomes: Abstract view of an engineer on how to solve the problem using services (Block diagram, data flow, event-based behaviour, process description). Outcomes: If an AS is created: an implemented service that can be deployed to a run time environment. If a CS is composed: the available services required for the composition and the BPMN implementation of the service logic exists an is executable for testing.

Creation and Composition

Stage D: Finalisation of Functional Description of Services

Description: After the description of raw interfaces and data types, included during development via annotations, a semantic description of in-and output parameters and the stateful description of the service behaviour has to be added. The semantic description enables the developer to explicitly specify used parameters that can be reused for composition and test derivation.

Outcomes: The full semantic description of the service (functional features and expected QoS) and the service interface description (WADL).

Deployment Phase

Stage E: Identification of Provisioning Metadata Description: Based on the service description the resources for deployment ensuring functionality, connection to the IoT resources and QoS have to be determined to select a sufficiently equipped runtime environment.

Outcomes: Provisioning metadata -agreed by the service developer and the service provider. Platform independent deployment descriptor.

Stage F: Test Derivation

Description: The derivation of a System Under Test (SUT) and test cases is generated. Semantic information is used to narrow down the variety of test cases. E.g. the parameters of a service accepting latitude/longitude coordinates as input to deliver data are not simply modelled as two float-values. They will be described with an upper ontology as geo-coordinates each with possible value range {-90.0

Conclusion

The proposed SOA approach lowers the obstacle for integrating IoT resources into existing service architectures and shows a far-reaching applicability in the IoT domain. In combination with a structured development using a service life cycle, which is utilising semantic descriptions, it ensures re-usability of services and facilitates (semi-) automatic test derivation and composition. Next steps will be the automated monitoring and Service Composition Environment (SCE) based tracking of the service life cycle.

  PhaseStage A: Identification / Adaptation of the Business Process Description: Initial stage to identify the goal of a new service from a business perspective. Adaptation during further iterations of the life cycle due to enhanced requirements or technical restrictions. Business process adaptation leads to a new version of the service where older versions can independently be developed further.

		Service
	Identification/	Modelling
	Adaptation		Service
	of the Business		Composition and Creation
	Process
			Finalisation
	Run-Time		of Functional
	Evaluation		Description
			of Services
			Identification
	Monitoring &		of
	Adaptation		Provisioning
			Metadata
	Service
	Deployment		Test
	in Run-Time		Derivation
	Environment
			Deployment
	Service		in Sandbox
	Deployment		&
	Configuration		Test
		Test	Execution
		Evaluation

  Is the proposed service model feasible with available resources and can missing services be created or composed? Not possible: stage B; If new atomic services are needed and new life cycle instance for them is created: stage A (of new life cycle). After new creation or if the creation/composition is possible: stage C.

	Phase
	Stage C: Service Composition and Creation
	Description: Lookup for services that provide the required functionality to
	achieve the goal defined in Stage A/B. Composition of available services to
	create a composite service (described in Business Process Model and Nota-
	tion (BPMN)). Initiation of the creation of a non-available atomic or composed
	service by instancing a new life cycle.

Decision:

  • , 90.0 • }/{-180.0 • , 180.0 • }. With this information valid values for tests are clearly specified. Decision: If service description is conflicting or insufficient the service life cycle will return to stage D. A test developer analyses the results of the test case execution. Decision: If errors occur: report to stage C to redevelop the service. If service behaves like expected, go on to stage I.Outcomes: Go/No-go decision made by the test developer based on the resulting log files. After the service has been tested, one or more run time platforms are selected for service provisioning. Outcomes: Final form of the provisioning metadata and deployment descriptor (platform dependent -manifest file). While the service is running it is an on-going process to monitor service availability and functionality. In the IoT.est Framework CSs are not implicitly bound to specific service endpoints of ASs. If an alternative AS exists, which can deliver the same information, the CS is able to utilize this AS as service endpoint. Due to altering infrastructure conditions this stage monitors service behaviour and performs necessary actions to adapt the composite service infrastructure. Furthermore the monitoring delivers non functional service quality and load information that can be utilized during next iterations of the service life cycle. Outcomes: Report of service usage and availability, adaptation, QoS adherence, occurred malfunctions and alerts. The evaluation of stage K reports is used for further life cycle iterations. Furthermore the enquiry of user experience is used to advance the next service versions. Outcomes: Documentation of suggestions for service or runtime changes. E.g. the replacement of runtime or redevelopment of service if QoS issues occur.

	Stage G: Deployment in Sandbox & Test Execution Description: Based on stage E a sandbox environment is selected to execute a set of test cases created in stage F. The IoT resources are emulated during testing[9]. Outcomes: Test results (TTCN-3 log files) are stored in the knowledge man-agement to ensure detailed evaluation of failed test cases. Stage H: Test Evaluation Description: Stage I: Service Deployment Configuration Description: Stage J: Service Deployment in Runtime Environment Description: The deployment on the final run time platform is made. Outcomes: Deployable package (platform dependent e.g. war) deployed in run-time. Configured and instantiated service. The service is running and available for monitoring. 2.4 Run Time Phase Stage K: Monitoring & Adaptation Description: Stage L: Run Time Evaluation Description:
	Outcomes: Set of all executable test cases as Testing and Test Control Notation
	Version 3 (TTCN-3)[8] code.

Acknowledgments. The research leading to these results has received funding from the European Union Seventh Framework Programme for the IoT.est project under grant agreement n • 257521. http://www.ict-iotest.eu