1 Introduction

The energy required to keep mobile devices connected to the network over extended periods of time quickly dissipates which affects the promise of a truly mobile experience. In fact, energy is a critical resource in the design of wireless networks, since wireless devices are usually powered by batteries. Battery life time has been identified by TNS report [1] as the number one criteria for the majority of the consumers purchasing a mobile device. Reaffirming this, concern with depleting battery is one of the top reasons why consumers do not use advanced multimedia services on their mobile devices more frequently. The motivation for reducing energy consumption is also driven by international consortiums in a bid to place tighter control on global greenhouse gas emissions. It is estimated that Information Communication Technologies (ICT) contribute with 2–2.5 % of the global greenhouse gas emissions. And with the expansion of the ICTs in developing countries, the total figure of carbon emissions will continue to grow to an estimate 2.8 % of total global emissions by 2020 [2]. Due to the increasing demand for energy saving, it would be interesting to investigate how the techniques, such as context-aware and heterogeneous cooperative communications, could exploit their benefits and contribute to the energy savings of wireless communications.

Context awareness is a key feature of any cognitive radio, where understanding of the operational environment and situation state is crucial towards reasoning and decision making in resource allocation. One major challenge in the mobile system is to implement a module capable of extracting context information from the surroundings, and exploiting this for optimization and part of the learning process for enabling energy saving strategies for UEs. To accomplish this, it is necessary to establish a common understanding of the definition of context in our system. Context, in general, can be seen as higher level knowledge, derived from an aggregation of information or modes of parameters describing the operational environment, including information such as time, geographical location etc. This higher level knowledge is derived in a context engine. Operational context is closely linked to the actual application domain and the range of applicable situation, while environment information is dependent upon the actual use case. Context may include information about mobile terminal (MT), network and applications. Information that forms the context can be placed into two basic categories: Information about the device itself (radio interfaces, battery capacity, maximum transmission power, processing power etc.) and information about the network (cell load, cell capacity, QoS guarantees etc). Context itself is an aggregate of such individual pieces of information, which are collected from various types of sources, including physical sensing of the radio environment, equipment data sheets, optimization policies, etc. Context information and context-awareness are now widely used in telecommunication and other related fields e.g. in short range communication [3], heterogeneous networks [4], wirless mesh network [5] etc.

There has been an increased interest recently in device-to-device (D2D) communication, as manifested by the WiFi Direct specifications and proposals for Long Term Evolution-Advanced (LTE-A) D2D standardization. The motivation behind D2D communication and possible ways to connect devices can be found in [6]. Using D2D by exploiting direct communication between nearby mobile devices will improve spectrum utilization, overall throughput, and energy efficiency, while enabling new peer-to-peer and location-based applications and services [7]. Although, D2D communication can significantly reduce energy consumption of mobile devices but these practices are still in its initial stages. On the other hand, cooperation technologies have been developed with the goal of enhancing the individual and/or group wireless link capacity. However, in todays information world there is a rich ecosystem of mobile technologies available for use. There are the cellular technologies like LTE, UMTS, etc; and the close range technologies like Bluetooth, UWB, WiBree, etc. This fact creates a great number of opportunities for cooperation with the intent of power and energy saving in mobile communications. Cooperative communication results in improved communication capacity, high speed and high performance. Furthermore, cooperative communication reduces the battery consumption resulting in an extended network life time; it has been demonstrated to maximize the throughput and increases the stability region for multiple access schemes [8]. Cooperative communication also contributes to the enlargement of the transmission coverage area of both cellular and ad hoc networks. As a result, interest in cooperative wireless communication grew rapidly in the last decade, and the technology is continuously evolving in multiple directions.

Previously proposed systems and mechanisms, despite offering energy savings, limit their focus towards one technology only, i.e. the energy saving mechanisms in each wireless systems fail to consider the availability of alternate technology options in the near vicinity. Our proposed system advances beyond the current state-of-the-art by breaking with the non-cooperation paradigm, and proposing energy saving strategies that exploit more than one technology simultaneously. The main goal is to integrate context with short-range cooperation to provide a beyond 4G networks experience, new networking topology and architecture that is technology agnostic, and energy compliant.

The main contributions of this paper include:

  • New multiple interface node and testbed platform architecture.

  • Technology agnostic cooperative protocol layer that we refer to as: C2P layer.

  • Novel heterogeneous context based cooperative algorithm for energy saving.

  • Performance analysis on a custom-made cooperative HW platform.

The rest of this paper is organized as follows: Sect. 2 covers preliminaries, related work is presented in Sect. 3, the context architecture for mobile terminal is presented in Sect. 4, mathematical model for the proposed algorithm is presented in Sect. 5, details of the testbed node, platform architecture and radio module power configurations are presented in Sects. 6, 7 shows the scenario, results are presented in Sect. 8 and finally the paper is concluded in Sect. 9.

2 Preliminaries

2.1 Cooperative communication

Cooperative communication depends on relay based communication in order to boost the performance of the transmission. Each node transmits its own data, while it can also act as a cooperative agent (relay) to transmit other node’s data. A simple cooperative communication system consists of a source, a relay and a destination node as shown in Fig. 1. The source node broadcasts the message to the relay nodes, which then forward or process and forward the received message to the destination. The destination node receives messages from both source and relay and the signal to noise ratio (SNR) is enhanced, resulting in an improved performance [9–11]. Cooperative communication evolved in several different methods e.g. Decode and forward (DF) [12], Amplify-and-forward (AF) [13], coded cooperation method [14] and a number of variations of these relaying protocols. In AF (also called scale and forward) method the relay node amplifies the received signal from the source node and forwards it to the destination node. There is no decoding involved in the AF method by the relay node as shown in Fig. 1a. On the other hand, in DF method, the relay decodes and detects bits from source and then retransmits these bits to the destination as shown in the Fig. 1b. Another method is coded cooperation which integrates cooperation into channel coding [11]. In coded cooperation, the source and relay nodes use different codes for conveying messages as shown in Fig. 1c. Adopting such a method increases the complexity, but can obtain higher diversity gain. Single or multiple relays can be used in cooperative communication as shown in Fig. 2. In single relay cooperation, the source has only one option to relay its information to the desired destination as considered in [13, 15].In multiple relays cooperation [16], each source has more than one relay available as options to forward its data to the destination. In the case of a decentralized network, the source node selects the relay node while in a centralized network the central entity (node or base station) can help the source node to choose the relay. In single RAT (Radio Access Technology) cooperation both source and relay node use the same technology which is widely used in ad-hoc wireless networks. On the other hand, in multiple technology cooperation, the source node can send the information via one technology, while the relay node uses a different technology to forward the information to destination. A more recent work is presented in [17] that provide a classification of relays based on their distinct communication attributes, such as processing, multiple antennas, storage, channel estimation, density and security level.

Fig. 1
figure 1

Different cooperative methods

Full size image
Fig. 2
figure 2

Cooperative communication networks

Full size image

2.2 Context

Alternative views applied to context” lead to different definitions and different levels of applicability. The term context-aware appeared in [18] for the first time, where the authors described context as location, identities of nearby people, objects and changes to those objects” [19]. An application-centric definition that is more suitable for problem solving and system design is: Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between the user and the application, including the user and the application themselves” [20]. The definition states that context is always bound to an entity and that information describing the situation of an entity is context, including the task itself. Other authors agree that user’s actions are generally goal-driven and hence the activity of the user (defined as a set of simultaneous tasks) becomes central to the user context [21]. In wireless communications, context is broadly related to two main entities: MT and Network. The context related to network covers security, policies, coverage and QoS. Security defines the security level of the network access that is fundamental to the user to decide whether he is interested into accessing the RAT. Network policies which is set by operators, mainly depends on agreements between the end-user and the access provider, and on agreements between different operators. The category of network coverage comprises more elements that are usually static, and it provides the information about the coverage of the network and the co-existence of different networks. Both static and dynamic data exist in QoS context category that describes the maximum and current capabilities of the network.

On the other hand, MT context information mainly comprises device capabilities, mobility, application, energy and user preferences. Context information about device capabilities is composed of data describing the device itself, comprising both hardware and software (CPU, Operating System, Memory, Display Capabilities), with a particular focus on the network interfaces. Mobility context provides information about the current location of the MT and its velocity (comprising speed and direction of mobility). The application category contains information about applications currently in use by the MT, which determine the QoS requirements. The system we describe focuses on energy savings, and in fact an important set of context information regards the energy of the MTs. The energy category comprises the current battery level, the rate of energy consumption, and energy history of the terminal. The last category of context information is user preferences, which are a set of parameters that are defined by the user, to specify what the user wants or expects from its interaction with the network. A

2.3 WiMedia energy saving

Characteristics such as large bandwidth, low power requirements and precise positioning capabilities have made UWB more attractive for WPANs [22]. Based on multi-band orthogonal frequency division multiplexing (MB-OFDM) technology, the WiMedia platform is optimized for complementary WPAN technologies such as Bluetooth, Certified Wireless USB, Wireless 1394 and Wireless IP. The solution enables short-range multimedia file transfers at data rates of 480 Mbps+ with low power consumption, and operates in the 3.1–10.6 GHz UWB spectrum. WiMedia MAC provides fully distributed architecture. The main idea of WiMedia MAC is to subdivide time into superframes (65536 ms) what allows all devices in the network to synchronize to a common reference and enable coordination with optimal resource usage. The two major subdivisions of the superframe are: the beacon period (BP) and data transfer period (DTP). The beacon frame of UWB consists of a number of information elements (IEs) containing the timing and control information [23]. There are a number of available fields in the beacon frames that can be modified or new fields can be proposed to exchange novel information e.g. battery level and cooperation information of the device.

WiMedia provides two power management modes for energy saving in which devices can operate: active mode and hibernation mode. In the active mode devices transmit and receive beacons every superframe while in hibernation mode all network activity of the devices is suspended for a specified number of superframes [23]. Hibernation mode, according to [24], allows devices to access network over two periods: global access period (GAP), and local access period (LAP). The main idea behind GAP is to allow broadcast or multicast traffic (e.g. ARP traffic or LAP schedules) to be exchanged between neighbouring devices, while LAP is mainly used for unicast traffic. In order to provide the best possible performance in terms of energy conservation, the frequency of GAP and LAP can be set according to traffic intensity, power consumption needs, etc. Moreover, devices are capable of dynamically extending or shorten periods of awake depending on the needs. Additionally to power conservation introduced in the hibernation mode devices are capable of saving power also in the active mode. Having beacons broadcast Traffic Indication Map (TIM) for each superframe allow devices to sleep over greater part of the superframe and wake up only for Medium Access Slots (MAS) where the actual traffic exchange has been scheduled.

2.4 WiFi power saving

The IEEE 802.11 standard specifies how communication is achieved for wireless nodes existing in a Wireless Local Area Network (WLAN). Part of this standard is dedicated to describing a feature known as Power Save Mode (PSM) that is available for nodes existing in an infrastructure based 802.11 WLAN. PSM is based on a synchronous sleep scheduling policy, in which wireless nodes (stations) are able to alternate between an active mode and a sleep mode. A wireless station, using PSM for the first time, joins an infrastructure based WLAN, it must notify access point that it has PSM enabled. The access point then synchronizes with the PSM station allowing it to begin running its synchronous sleep schedule. When packets arrive for each of these PSM stations, the access point buffers them until their active period comes around again. At the beginning of each active period, a beacon message is sent from the access point to each wireless station in order to notify them of these buffered packets. PSM stations then request these packets and they are forwarded from the access point. Once all buffered frames have been received, a PSM station resumes with its sleep schedule wherever it left off. Whenever a PSM station has data to send, it simply wakes up, sends its packet, and then resumes its sleep schedule protocol as appropriate. The throughput achieved with these techniques is significantly less than with them disabled. While PSM may significantly reduce the energy consumed by a wireless station, many users prefer to sacrifice these power savings for an increase in performance. The main drawbacks of PSM mechanism are incapability of providing sufficient QoS for delay sensitive services such as VoIP [25]. The mentioned problem has been addressed by WiFi Alliance in WMM (WiFi Multimedia) Power Save [26]. WMM Power Save improves performance for delay sensitive services allowing more flexibility in power management (application dependent).

3 Related work

An interesting and challenging direction of the cooperative communication is the use of devices carrying multiple interfaces which forms the heterogeneous networks. In fact, very limited work in the literature had addressed context based heterogeneous cooperation using short range technologies in combination with medium or long range. Most of the existing work either followed the simple relay based cooperation using standard relaying techniques or the cooperation based on hybrid relaying concept, where MT adaptively changes its relaying techniques e.g. AF/DF etc. For instance, in [27] the work is based on a combination of different cooperation selection technique: decode-forward (DF) and amplify-forward (AF), non-orthogonal amplify-forward and dynamic decode-forward and non-orthogonal amplify-forward and compress-forward. Similarly, the work presented in [28–35] are based on adaptive relaying techniques or using a combination of the relaying protocols without considering multiple interfaces. For instance, in [35] the proposed protocol adaptively determine the transmission mode according to channel conditions by considering single technology and analytical results.In the context of cooperative heterogeneous wireless networks,a work is presented in [36] but limited to only call blocking/dropping probabilities. A game theoretical method is proposed in [37] to model packet forwarding in relay networks. Similarly, in [38] a model of cooperation in ad hoc networks, based on evolutionary game theory is presented but again only analytical results are provided. A more recent work on capacity maximization through energy-aware multi-mode relaying has been presented in [39].

On the other hand, some recent works have considered heterogeneous cooperative communications. For instance, in [40] the authors have investigated the use of multiple radio access technologies (RATs) to improve the energy efficiency in cooperative networks. Similarly, efficient resource utilization and spectral efficiency optimization in heterogeneous cooperative networks has been investigated in [41, 42]. Although the above mentioned works do consider multiple technologies for cooperation but the results are either analytically proven or based on simulations. A detailed survey covering the classification and various possible types of cooperative communications with its pros and cons is presented in [43]. Based on its application to wireless communication, cooperative communication is not only used for improved throughput and coverage but also widely considered for energy savings of mobile terminal and overall network. In [44], it has been shown that cooperative communication contributes considerably to an extended battery life time. In fact, in cooperative wireless communication, the path to the BS or destination node is divided into shorter links which results in lower transmission power and contributes to energy savings of the network [45–47]. Similarly, energy efficient relay selection protocols for cooperative communications are reported in [48–51]. Moreover, a comprehensive survey on on context-aware mobile and wireless networking is presented in [52] that can give users a more clear understanding of using context information.

As mentioned earlier, most of the above referenced works, despite offering energy savings, limit their focus on single technology or using multiple technologies but the findings are based on analytical or simulations results. Based on the limitations, our main contribution is the development of the testbed node based on the context information and its implementation for the energy efficient mobile terminal cooperation. Instead of exhaustive scanning, the context information are exploited to find the neighbours for cooperation and energy savings.

Fig. 3
figure 3

Testbed node context management architecture

Full size image

4 Context based node architecture

4.1 Testbed node context architecture

This section presents the architecture that is used for context management to implement the goal of energy efficient mobile terminal cooperation. Figure 3 presents the context architecture that is deployed on the testbed node. The functional blocks of the context aware architecture residing in the Context Aware Module (CAM) are explained as follows. The Context Provider (CX-Provider) is the entry point for context information into the system. In particular, it is responsible for providing to an entity (MT or Network) all the information that is not transmitted from another entity. Data is in raw form (unprocessed) for the Context Reasoner (CX-Reasoner) to process; the interaction of this component with the rest of the system depends on whether it is deployed on the network side or on a MT. An MT gets input from MT’s sensing units, and from internal databases keeping track of user preferences, while a network gets data from the policy database of the operator, and directly from the uplinks of the MTs. Output from CX-Provider is initiated when there is a change in state. The CX-Provider then provides data to the rest of the system through the CX-Reasoner.

The context manager is responsible for context information processing to provide the refined context to the decision engine. It consists of two blocks: CX-Reasoner and Context Filter (CX-filter). The CX-Reasoner collects raw context and generates rules for context filtering based on the constraints from the policy set. The CX-Reasoner also instructs the CX-Provider to provide more appropriate context and reduce the overhead. The reasoner may need to process the information to generate rules; however it will not alter the information content. The CX-filters filter the context information based on the rules generated by the CX-Reasoner and outputs the high level operational context for the decision engine.

The decision engine is the core of the context awareness framework; it makes decisions based on operational context information from the context manager and the constraints enforced from the policy set. The decisions are either related to vertical handovers or MTs cooperation, towards implementing energy saving. The policy set is the set of strategies that can be used by the radio, in other words it imposes constraints on the radio functionalities. In the proposed architecture, policy set is mapped to the policies on the network side and policy information as part of terminal CAM.

Configuration profiles represent a knowledge repository based on previous decisions. It represents the result seen as learning process. For example in a learning process, the implementation of a decision is evaluated. A good (energy efficient) decision is given a higher score. Good decisions with high scores are likely to be repeated in the future if the context setting permits. Such configuration profiles provide an option that context awareness could be realized by looking up the knowledge database.

Fig. 4
figure 4

C2P layer in the testbed node protocol stack

Full size image
Fig. 5
figure 5

Distributed C2P beacon frame structure

Full size image

4.2 C2P layer

The C2P layer is envisioned as part of the context based testbed mobile device, and forms part of the device’s protocol stack as presented in Fig. 4. Such a modular representation makes it easier to analyze and evaluate interoperability in context based network devices, in particular the interoperability of C2P layer functions with the existing protocol suite. As it can be seen, C2P node itself is independent from the underlying radio technology. However, the C2P node functionality is very much related to the MAC layer in the sense that it requires our system to understand what type of frame the device has received, and whether it is a data frame or a beacon frame, which in turn determines the further processing of the frame. The above mentioned functions are performed by C2P adaptation layer, which is able to intercept the C2P frames and data frames along with their data rate and SNR. Thus, the adaptation layer separates C2P layer from the underlying radio technologies specifics. In that sense, the adaptation layer is required to recognize specific radio interfaces and manage the transportation of C2P frames; also in the cases IE congestions and technologies that has no support for beaconing.

The C2P layer provides the functionalities to facilitate CX-Provider by extracting the raw and processed context. Apart from the above main application there is also a context extension plug-in. The main purpose of the plug-in is to extract various items of context information from other layers of the network device protocol stack. The context information is then made available to various modules of the C2P node, which utilizes it to decide about cooperation. For example, context information extracted from the lower layers is composed of SNR or packet data rate, or from higher layers the monetary cost of the service. As noted previously, the C2P layer application is technology agnostic, thus as C2P enabled node is capable of managing and having an interface to multiple radio technologies embedded in one device. Such knowledge enables our system to effectively employ and manage cooperative schemes, e.g. multi-radio cooperative relaying or multi-radio cooperative scanning.

4.3 Proposed Beacon frame structure

The testbed implemented C2POWER frame (C2P frame) is shown in Fig. 5 and reflects the variety of purposes it is used for. The C2P frame consists of a header which defines: the message type, addressing type (either 1 for Unicast or 0 for Multicast), supported RATs (the technologies which are available to the mobile node) and supported cooperative strategies (the cooperative strategies available to the user of the mobile node). After the header, the C2P frame contains a Destination address field, which shall utilize the MAC address of the destination device or the multicast MAC address (agreed by the nodes in the cluster) of the cluster or the broadcast address. The rest of the C2P frame contains a payload specific to each of the cooperative strategies that are employed. The proposed C2P frame yields not only the exchange of information between neighbouring devices, but also enables the creation of more complex networking forms such as clusters that enable application of energy saving schemes in cooperative manner.

Apart from the utilization of application specific payload of beacon frames in WiMedia and WiFi, there are situations where it might be beneficial to change the transport scheme of C2P frames based on the characteristics of the underlying technology. First of all, such situation occurs when the application specific payload of beacon frame is already utilized by other applications or by excessive inclusion of Information Element (IE congestion). Second, C2P frames based application might be utilized by a technology, which does not support beacon frame exchange, for example Bluetooth4. In both situations, C2P based application is required to perform frame adaptation, so that C2P frame is exchanged through the payload of data frames. In this particular situation, a C2P layer is required to provide mechanisms that enable users to choose which short-range technology is utilized to exchange C2P frames (by default WiMedia or 802.11 in such precedence are assumed if available). The adaptation function shall insert C2P frames into appropriate transport frames. If applicable, the adaptation function should also reserve data channel as well as read incoming C2P frames from the same technology. In case of IE congestion, C2P enabled device should either refrain from distributing C2P frames (there is no space in each of the consecutive beacon frames to include user specific data) or include into the beacon a pointer frame that indicates that the C2P Distributed Management frame will be included into the data frame payload. The pointer frame should have a separate Message Type and its value should replace the C2P frame payload.

Fig. 6
figure 6

Frame processing within C2P network device

Full size image

4.4 Frame processing

Based on the presented layered model, we now analyze the frame processing scheme of the proposed context based architecture available in a C2P testbed device. Each layer of the protocol stack encapsulates the out-going packet with its own header, thereby connecting to its peer layer on other devices, which can subsequently expand the received packet and read the included information. However, the proposed system does not generate its own control frames; instead it utilizes vendor specific information in the beacon frames already available in the technology. Figure 6 presents the frame processing scheme for a device equipped with our proposed system capabilities. The figure illustrates a set of key processing steps in a network; when a new frame is received from the channel, it is decoded in the PHY and MAC layers, which is outside of the C2P application. At this stage the frame can be dropped due to RSSI being below the received threshold, unrecognized type or unfixable errors. As an alternative, one can utilize maximum ratio combining, which requires the incorrectly received frames to be stored and combined with others to benefit from multiplexing gain. At that point, the frame is passed to the adaptation layer which determines whether it is a control or data frame.

4.5 Proposed context based relay selection algorithm

The proposed context based relay selection algorithm is depicted in Fig. 7. MT collects its internal context information from CAM and checks its battery level (BL) or SNR value with threshold values. Lower BL level and SNR trigger MT to pledge the cooperation process. Moreover, context information related to the MTs in the vicinity is stored in CAM and the optimal relay section process is propped up by context information. BL, SNR and Willingness (W) of the neighbor nodes are compared with the pre-defined threshold values and the optimal relay is selected to start the cooperation process.

Fig. 7
figure 7

Flowchart of the proposed context based relay selection algorithm

Full size image

5 Mathematical analysis

In this section we present our energy analysis using multiple interfaces nodes (WiFi and UWB) in cooperative relaying. Let \({T_D}\) be the time allocated to the transmission of data packet D. Each time slot is assumed to be fixed. Since, each node is equipped with two interfaces WiFi and UWB; we define the data rate offered by the UWB and WiFi as \({R_u}\) and \({R_w}\) respectively. The time spent by the originator node to send the packet D via UWB to the intermediate node is

$$\begin{aligned} {T_{org}}\, = \frac{D}{{{R_u}}} \end{aligned}$$
(1)

Similarly, the time spend by the intermediate node to send the data packet D to the WiFi access point (destination) is

$$\begin{aligned} {T_{\mathrm{int} \,}}\, = \frac{D}{{{R_w}}} \end{aligned}$$
(2)

Since the size of the data that the originator or intermediate node is sending is known, then size of each packet over WiFi or UWB is

$$\begin{aligned} D\, = \,\frac{{{T_D}\,{R_w}}}{N} \end{aligned}$$
(3)

where N is the total number of available slots.

From equation 1 and 3 we can get

$$\begin{aligned} {T_{org}}\,&= \frac{{{T_{D\,}}{R_w}}}{{N\,{R_u}}}\nonumber \\&=\frac{{{T_{D\,}}}}{{MN\,}} \end{aligned}$$
(4)

where

$$\begin{aligned} M = \,\frac{{{R_u}}}{{{R_w}}} \end{aligned}$$

M represents the ratio between the two transmission rates e.g. UWB and WiFi. Since \({R_u} > {R_w}\) then the time required for the transmission of same data over relay link is less than the direct link.

We now calculate the energy consumed by using direct WiFi connection and relaying the information via the intermediate node. It is known that:

$$\begin{aligned} E\, = \,{P_T}\, \times \,T \end{aligned}$$
(5)

where E is the energy consumed, PT is the power of transmission and T is the total time. Let \({P_u}\) be the transmit power of originator node using UWB, we then calculate the energy consumed as

$$\begin{aligned} {E_{u\,}} = \,{P_u}\, \times \,{T_{org}}\, = \,\frac{{{P_u}\,\,{T_D}}}{{M\,N}}\,\,\,\,Joules\, \end{aligned}$$
(6)

Similarly the energy consumed by using the WiFi Link is

$$\begin{aligned} {E_{u\,}} = \,{P_w}\, \times \,{T_{org}}\, = \,\frac{{{P_w}\,\,{T_D}}}{{M\,N}}\,\,Joules \end{aligned}$$
(7)

The intermediate node receives the packets from Originator node by using UWB ,and then by using WiFi, it sends the data to the AP. To achieve the desired QoS by using WiFi we denote the achieved data rate as \({R_w}\) , then the time spent in the transmission of D packets

$$\begin{aligned} {T_D} = \,\frac{D}{{{R_w}}} \end{aligned}$$
(8)

where \({T_D} = \,{T_{\mathrm{int}}}\) The intermediate node performs the cooperation and receives the packets via UWB, and then performs the coding to get the desired QoS , and send it via WiFi ; thus the total energy consumed is given as follow

$$\begin{aligned} {E_{c,\mathrm{int} }} = \,{P_{c,w}}\, \times \,{T_D}\, = \,\frac{{\,\,{T_D}{P_{c,w}}}}{{{R_w}N}} \end{aligned}$$
(9)

where \({P_{c,w}}\) is the power consumed by the intermediate node in WiFi mode to achieve \({R_w}\) date rate. The cost of relaying in cooperation mode is given as

$$\begin{aligned} {E_{coop}} = {E_{org,\mathrm{int} }}\, + \,{E_{c,\mathrm{int} }} \end{aligned}$$
(10)

where \({E_{org,\mathrm{int} }}\) is the energy consumed by the relay node in processing the packets send by the originator nodes over UWB. The cooperation has an associated cost because useful battery is consumed to perform the cooperation. Therefore, the cooperation gain G is the ratio of energy consumed in cooperation mode to the non-cooperation mode.

$$\begin{aligned} {G_{}}&= 1 - \frac{{{E_{coop}}}}{{{E_{non - coop}}}}\nonumber \\ \,\,\,\,\,\,\,&= 1 - \frac{{{E_{org,\mathrm{int} }} + {E_{c,\mathrm{int} }}}}{{{E_{c,\mathrm{int} }}}}\nonumber \\ \,\,\,\,\,\,\,&= \frac{{{E_{org,\mathrm{int} }}}}{{{E_{c,\mathrm{int} }}}} \end{aligned}$$
(11)

Since \({E_{org,\mathrm{int} }} = {E_{u\,}} \) then

$$\begin{aligned} G&= \frac{{N.\frac{{{P_u}{T_D}}}{{NM}}}}{{{T_D}{P_{c,w}}}}\nonumber \\&= \frac{{{P_u}}}{{M{P_{c,w}}}} \end{aligned}$$
(12)

The power saving gain from the energy consumed is calculated as follows

$$\begin{aligned} {G_p}&= \frac{{{E_u}}}{{{E_{c,\mathrm{int} }}}}\nonumber \\&=\frac{{\frac{{{P_u}{T_D}}}{{NM}}}}{{\frac{{{T_D}{P_{c,w}}}}{{N{R_w}}}}}\nonumber \\&= \frac{{{R_w}{P_u}}}{{M{P_{c,w}}}} \end{aligned}$$
(13)

Again, the power saving mainly depends on the transmit power consumed by UWB and WiFi and also the data offered data rates.

6 Testbed platform architecture

The testbed is composed of a number of C2POWER nodes (C2P Node) developed in C2POWER [53] project. The C2P Node is pictured in Fig. 8 and consists of three major modules; the Device under test (DUT), a Telemetry Controller (TC) and an Attenuation and Power Measurement Board (APM). Both the DUT and the TC have individual Ethernet connections to the testbed internal network.

Fig. 8
figure 8

C2P node architecture

Full size image

A new layer called C2POWER layer (C2P layer) is introduced that implements the cooperative algorithms and is controllable via another UPnP service interface. Control via the UPnP interface makes it possible for the Test Fixture Controller (TFC) or other external controller to enable or disable the C2P layer. Such control makes it possible to carry out automated comparisons between scenarios with and without the benefit of cooperative communications. Traffic passes via the C2P layer and the selected radio, either directly or via relaying and routing to an endpoint connected via the WiFi AP on the TFC. The Traffic Generator, UPnP device and C2P layer all reside in Linux user space.

The TC is a general purpose Commercial Off The Shelf (COTS) development board with a 32 bit CPU, 64MB RAM, and 512MB NAND flash running embedded Linux and has a wide selection of interfaces, including Ethernet, General Purpose Input/Output (GPIO) and Serial Peripheral Interface Bus (SPI). There are three main software modules in the TC: Universal Plug and Play (UPnP) device, a Programmed input/output (PIO) controller and an Analogue to Digital Converter (ADC) controller. The PIO controller sets the attenuators on the Attenuation and Power Measurement Board (APMB) in response to commands delivered over the Ethernet via a UPnP service interface. The ADC controller receives instructions to gather voltage and current readings from the power sensors on the APMB. The ADC controller can be configured over UPnP to buffer a number of readings for delivery to the TFC in response to later requests. Each measurement is time stamped by a local clock synchronized with the Network Time Protocol (NTP ) server on the TFC, which ensures that all readings from all nodes are synchronized across the testbed.

The final module is the Attenuator and Power Measurement Board (APBM). It has two RF attenuators inserted between the antenna connector of each radio. Each one is capable of inserting a wide enough range of attenuation approximately the same as 1–20 m of separation in a line of sight over-the-air arrangement. Three voltage/current measurement sensors are connected to the DUT to measure the power consumption of: the main CPU and ancillary hardware, and each of the WiFi and UWB radio modules.

Fig. 9
figure 9

Testbed platform architecture

Full size image

The testbed platform architecture is shown in Fig. 9. Each C2P Node is controlled by the Fixture Controller using UPnP protocols. UPnP provides standardized mechanisms for: Device discovery, Service discovery, Device control and Event notification. The TFC, shown in Fig. 9, is a Linux based system responsible for the control and management of the C2P nodes and the acquisition and storage of performance data and measurements, as well as the control of the programmable attenuators which modify the relative separation of the nodes in the wired radio environment. These functions are automated by a scripting engine and results are preserved in a data store. The scripting engine is Python based, which offers a powerful and well-known means for automating the testbed. Each node includes a Telemetry Controller (TC), which delivers power consumption measurements to the TFC under script control for display and analysis. The TFC provides a time reference propagated to all nodes across the internal network of the testbed to synchronize all nodes for the time-stamping of the current and voltage data and the accurate coordination of node behavior during the execution of cooperative scenarios. The data store holds all the results. The current implementation uses 802.11g. WiFi in the 2.4 GHz band and UWB operating in WiMedia Band Group 3 (6336-7920 GHz) [17].

A logical representation of the software layers that make up the Telemetry Controller and DUT and how they are interconnected is shown in Figs. 10 and 11. The automation scripts used to control the radio path attenuation, power logging and uPnP services are: TFC runtime scripts, TC runtime scripts and DUT Runtime scripts. TFC runtime scripts configure the IP routing information for either the Direct or Relay scenario and initiate the TCP/IP the network traffic generator (iperf) server. TC runtime scripts start the measurement run, for the direct and relay scenarios. DUT runtime scripts configure the IP routing tables for either the direct or relay path and start the iperf client to begin the file transfer.

Fig. 10
figure 10

DUT software architecture

Full size image
Fig. 11
figure 11

TC software architecture

Full size image

6.1 Radio module power configuration

The WiFi radio module selected for the C2P nodes is a COTS dual band Ralink 802.11 and is configured for 2.4 GHz operation which is most widely used. The current implementation uses 802.11 g WiFi in the 2.4 GHz band and UWB operating in WiMedia Band Group 3 (6336–7920 GHz). In order to determine and select the most optimal power saving mode, some investigations were undertaken in the RF screened room before any of the formal test runs. The WiFi radio module is configured in one of the three modes that directly affect power consumption.

  • Constant Awake Mode (CAM) is the normal mode for machines where power consumption is not an issue. CAM mode keeps the radio powered up continuously.

  • Power Save Mode (MAX-PSP) is recommended for devices where power consumption is a major concern, such as small battery powered devices. Power Save Mode causes the Access Point to buffer incoming messages. The Wireless Adapter must wake up periodically and poll the Access Point to see if there are any messages waiting. This has a big negative impact on throughput.

  • Fast Power Save Mode (Fast-PSP) switches between PSP and CAM based on network traffic. When retrieving a high number of packets, Fast-PSP Mode will switch to CAM to retrieve the packets. Once the packets are retrieved, it switches back to PSP mode. This has a small impact on throughput, around a 20 % reduction.

Table 1 WiFi radio power summery (Direct scenario)
Full size table
Fig. 12
figure 12

Testbed test scenarios

Full size image

Based on the testing, the WiFi driver configures the WiFi radio for fast-PSP mode, as it gives the best combination of high throughput and low power consumption. A summary of the measured power consumption figures for the WiFi Radio for each power mode is shown in Table 1.

7 Scenarios

7.1 Scenario 1

Scenario 1, depicted in Fig. 12, presents the testbed based analysis scenario for a coffee shop, office or indoor heterogeneous cooperative communication. The two nodes in this configuration are referred to as “Originator” and “Intermediate”. The Originator and Intermediate nodes are C2P nodes, equipped with UWB and WiFi and connected with Text Fixture Controller (TFC). The TFC acts as Context Aware Module (CAM) and is responsible for providing the context information and calculations of power and energy consumptions. The power consumption of the CPU, WUSB and WiFi radio modules on each node is measured, displayed and recorded whilst the Originator Node is performing the data transfer across the network from the AP. A USB analyzer is used to monitor the on-Air UWB traffic and to verify that traffic is being routed over the UWB radio via the Intermediate node. The Originator is connected with WiFi and when its battery level goes down, it receives the context information from CAM; based on the context information it then tries to connect to the Intermediate node via UWB. After connection establishment it sends the data via the Intermediate node to WiFi access point (AP).

The scenario involves a data transfer of 200MByte for 300s and the measurements are undertaken using two scenarios:

  • DIRECT- where the data is transferred from the Originator to the AP using only the WiFi.

  • RELAY- where the data is transferred via the Intermediate node using the UWB radio between the nodes and then from the Intermediate node to the AP using the WiFi radio.

7.2 Scenario 2

Scenario 2, right side of Fig. 12, represents the multiple relays configuration. In total, 4 nodes are involved in communication: two Originator nodes and two Intermediate nodes. Similar to scenario 1, the Originator and Intermediate nodes are multi-mode nodes and equipped with UWB and WiFi interfaces. These nodes are connected with TFC which acts as Context Aware Module (CAM) and is responsible for providing the context information and calculations of power and energy consumptions. Due to communication barrier, or low battery level the Originator node 2 has poor channel. Based on the internal context information the originator node 2 searches for the nearby available nodes for cooperation. The Originator node 2 has been provided random mobility and can change its location covering more wide area (upto 100m). Both Originator node 1 and 2 has a UWB link with Intermediate node 1, while intermediate nodes communicate via WiFi connection. The scenario 2 also involves a data transfer of 200 MB for 300 s and the measurements are undertaken by direct and relay based communication.

8 Results and discussions

This section presents the results of tests conducted on the C2P Node in an open office environment for both the direct and relay scenarios at various ranges from the AP.

8.1 Power measurement analysis

The power consumption of the CPU, WUSB and WiFi radio modules on each node is measured for a fixed duration of 300s, which is considered to be long enough to allow the file transfer to complete for all test cases. The Telemetry Controller generates a set of time-stamped log files of the measured power consumption of the CPU, WiFi and WUSB radio modules in each DUT. Four files are generated in total, two for the Originator node and two for the Intermediate node, grouped into sets—one for the DIRECT scenario and one for the RELAY scenario. The Originator generates a tabularized log of data throughput, time-stamped at 1 second intervals.

Figures 13 and 14 compare the power consumption of the two radio interfaces in the DIRECT scenario for WiFi CAM and Fast-PSP modes. The idle power of the WiFi radio (Blue line) in the CAM mode is 620 mW. The active power when transmitting is roughly the same as the CAM mode at 1200 mW, however, the idle power of the WiFi radio in the Fast-PSP mode is only 135 mW, waking up periodically to 620 mW. Both modes, CAM and Fast-PSP, take time duration of 118 s to transfer the same amount of data. Although, CAM provides best connectivity from users perspective but the idle power consumption of Fast-PSP mode is very low compared to the CAM mode which can contribute to the energy savings of the terminal. UWB power consumption is almost the same in both scenarios.

Fig. 13
figure 13

Originator node power consumption of WiFi (CAM mode) in direct scenario

Full size image
Fig. 14
figure 14

Originator node power consumption of WiFi (Fast-PSP) in direct scenario

Full size image

The power consumption of WiFi radio operating in MAX-PSP mode is shown in Fig. 15. Devices operating in MAX-PSP go to sleep mode once it receives information that no data is available for that station. The device turned off its transmitter for 10 beacons and wake up to listen for the 11th beacon. This process will continue until there is data available for the station to transmit or receive. Due to this periodic switching between sleep and wakeup modes, we can see the file transfer takes a very long time to complete; 900 s as opposed to the 118 s for the other two modes. Furthermore, it can be seen that the frequent switching off the radio results in a poor trade-off between power and throughput. Based on the testbed results, Fast-PSP is selected as a practical choice for the wireless testing in the energy calculations as it provides optimal battery life and network performance.

Central Processing Unit (CPU) of mobile terminals consumes considerable amount of energy which is neglected in most of the previous analysis. We include CPU power consumption as part of power analysis in cooperative communication as shown in Fig. 16. Power consumption of the node, considering the radio interfaces (WiFi and UWB) and CPU is show in Fig. 16. As depicted in the figure, the power consumption of CPU is much higher than the radio interfaces.

Fig. 15
figure 15

Originator node power consumption of WiFi (MAX-PSP) in direct scenario

Full size image
Fig. 16
figure 16

Power Consumption of the testbed’s radios and CPU in relay scenario

Full size image
Fig. 17
figure 17

Energy consumption comparison of direct and relay scenario (Fixed Durations 300 s)

Full size image

8.2 Energy measurement analysis scenario 1

This section presents energy analysis of the testbed nodes used in direct and cooperative heterogeneous communications. From the previous section it is determined that Fast-PSP mode of WiFi is the most suitable for energy savings and used in the rest of energy analysis tests.

Figure 17 shows the energy usage (UWB, WiFi and CPU) in both direct and relay scenarios in the fixed duration scenario (300 s). The direct link between Originator node and the AP is experiencing bad channel conditions which results in low data rate. Since each node has a context-aware module which provides information related to the available devices in the vicinity; the originator node decides to cooperate with the Intermediate node to achieve better energy efficiency by relaying its data on the short range UWB. The energy consumption is first calculated for the direct case where the Originator node uses direct connection with AP to send data. While in the relay case, the Originator node sends data to intermediate node via UWB link which then sends it to the AP via WiFi connection. As we observed in the previous section that the power consumption of WiMedia is much lower than that of WiFi and UWB can provide a data rate up to 480 Mbps; hence, UWB saves energy via cooperation. It is clear that the more energy is consumed in direct scenario compared to relay based communication. The total energy savings is also depicted in the Fig. 17.

Fig. 18
figure 18

Energy consumption comparison of direct and relay scenario (200 MB File Transfer)

Full size image
Fig. 19
figure 19

Total radio energy consumption comparison of direct and relay scenario (Fixed durations 300 s)

Full size image

Similarly, Fig. 18 shows the energy consumption comparison of direct and relay communication for a file transfer of 200 MB. Initially the energy saving is less when the Originator node is at a shorter distance from AP, in both direct and relay scenarios, but at a distance of 4 m and further away a considerable amount of energy is saved via relay based communication. At a distance of 1m the energy saving is 13.96 % which gradually increases and reaches to 68.64 % at a distance of 8m. In comparison to the fixed time duration scenario (300 s), high energy saving is achieved in fixed size data transfer scenario. For instance, 68.64 % energy is saved at a distance of 8m in fixed data scenario compared to 13.97 % in the fixed time duration scenario.

The previous Figs. 17 and 18, depicted the energy consumption and savings of the whole testbed node (interfaces and CPU). While, Fig. 19 shows the total radio (WiFi and UWB) energy consumed by the DUT over the duration of the test measurement period of 300s. Considering heterogeneous cooperative communication in comparison to direct communication, the total radio energy saving, in relay scenario, increase from 17.28 % at a distance to 45.13 % at distance of 8m. Considering as an example of energy consumption, the radio interfaces (WiFi and UWB) consumes 541.53 joules of energy at a distance of 8 m in direct communication compared to 244.38 joules of energy in case of heterogeneous cooperative communication. Clearly, transmitting via the RELAY path offers a distinct advantage as it utilizes the faster UWB radio which offers bandwidth and more power efficiency and thus saves energy.

The total radio energy (WiFi and USB) consumed by the DUT for the duration of the 200 Mbytes file transfer is shown in Fig. 20. The total energy saving of the interfaces in heterogeneous cooperation is more in fixed data scenario compared to the fixed time duration scenario. For instance, at a distance of 1m from AP, the energy savings of radio interfaces in cooperative communication is 31 % which further increase to 75 % at a distance of 8 m. There is a sudden boost in energy savings at distance of 4 m due to the more suitable propagation conditions. Viewed from this perspective, transmitting via the relay path offers a distinct advantage and an even greater saving which increases with distance from the AP.

Fig. 20
figure 20

Total radio energy consumption comparison of direct and relay scenario (200 MB File Transfer)

Full size image
Fig. 21
figure 21

Energy gain comparison analytical and testbed

Full size image

Based on the analytical calculations and testbed results, the energy gain comparison with respect to distance is depicted in Fig. 21. As we can see from equation 12, the energy gain mainly depends on the values of transmit powers of UWB and WiFi and the data rates offered by both technologies. Since, UWB offers high data rate (54–480 Mbps) at lower power consumption (100–300 mW) compared to WiFi; therefore high energy gain is achieved by using UWB compared to WiFi. Moreover, energy gain increases both analytically and via testbed when the Originator node moves away from AP. At shorter distance from the destination (AP in this case) the gain is very small which signifies that there is no need to apply cooperative strategies. On the other hand, with an increase in the distance from the destination, the channel can experience interference and having bad quality thus starts esteeming cooperative communication. Furthermore, the analytical gain is more in line to the real testbed results although the analytical calculations are not considering the interference and other propagation parameters.

8.3 Energy measurement analysis of scenario 2

Fig. 22
figure 22

Total energy consumption comparison of direct and relay scenario (Fixed duration) with respect to date rate

Full size image

Figure 22 show the energy consumption with respect to the Originator Node for both the DIRECT and RELAY scenarios over the fixed time period (300 s). Extrapolating from the two curves, from the perspective of the Originator Node there is about a 7 % energy saving for the RELAY scenario for all data rates.

Figure 23 show the energy consumption with respect to the Originator Node for both the DIRECT and RELAY scenarios over the duration of the 200 MByte file transfer. Extrapolating from the two curves, from the perspective of the Originator Node there is about a 7 % energy saving for the RELAY scenario for all data rates. This is lower than for the 2-Node scenario. Figure 24 show the total radio energy (WiFi and WUSB) of the Originator Node consumed by the DUT over the duration of the test measurement period of 300s. There is an energy saving for the RELAY scenario for all data rates. Considering just the radio energy consumed, clearly transmitting via the RELAY path via the two intermediate nodes offers a distinct advantage. There is a substantial energy saving for the RELAY scenario for all data rates due to the lower power consumption of the USB radio on the originator node. Extrapolating from the curves yields an energy saving of between 14– 23 % depending on the data rate.

Fig. 23
figure 23

Total radio energy consumption comparison of direct and relay scenario (200 MB File Transfer)

Full size image
Fig. 24
figure 24

Total radio energy consumption comparison of direct and relay scenario (Fixed duration)

Full size image
Fig. 25
figure 25

Total radio energy consumption comparison of direct and relay scenario (200 MB File Transfer)

Full size image

The total radio energy (WiFi and WUSB) of the Originator Node consumed by the DUT for the duration of the 200 Mbytes file transfer is shown in Fig. 25. Considering just the radio energy consumed, clearly transmitting via the RELAY path via the two intermediate nodes offers a distinct advantage. There is a substantial energy saving for the RELAY scenario for all data rates due to the lower power consumption of the WUSB radio on the originator node. Extrapolating from the curves yields a saving of between 20–25 % depending on the data rate.

In the previous sections, we have calculated the energy consumption of the Originator and Intermediate nodes in both the scenarios. However, there is also an associated cost of context sharing as well. Figure 26 depicts the cost of context information sharing using UWB and WiFi. A number of tests were performed varying the size of context information and send on both technologies. The cost of context information sharing is higher in case of WiFi compared to UWB but still negligible for the technologies compared to the overall energy gain of the mechanism.

Fig. 26
figure 26

Total radio energy consumption comparison of direct and relay scenario (200 MB File Transfer)

Full size image

9 Conclusion

In this paper, we propose a new testbed node and platform architecture, and use this as a vehicle for validating the C2POWER protocol pertaining to energy analysis of heterogeneous cooperative communication based on short range. The testbed is composed of several nodes called C2P Nodes and each node is equipped with UWB and WiFi radio interfaces. A new layer called C2P layer is introduced that implements the algorithms running over these multiple interfaces. The testbed is used for an indoor office or coffee shop scenario, and involves a data transfer of 200 MByte for 300 s in both direct and relay based communication. The WiFi power modes have been tested for the proposed scenario as suitable power modes can have a considerable impact on energy savings of the system. The most energy efficient mode is witnessed in Fast-PSP through testbed results. Fast-PSP resulted in higher throughput, compared to being always awake, and also resulted in 4 times reduction in the radio power in idle mode. In the fixed time duration scenario, the energy saving varied from 3 % at a distance of 1m to 14 % at 8m. Whereas in the duration of the file transfer scenario, the energy saving varied from 14 % at a distance of 1m to 68 % at 8m, indicating that applications which disconnect when idle, and handset operating systems that can shut down radios aggressively will benefit the most. The energy usage increased with distance, as the WiFi radio had to increase its transmit power in an attempt to maintain the throughput due to the rate adaptation, and due to the longer transmission time thus favoring relay based communication.