Cloud-over-WOBAN (CoW): an Offloading-Enabled Access Network Design

Transcription

1 Cloud-over-WOBAN (CoW): an Offloading-Enabled Access Network Design Abu (Sayeem) Reaz, Vishwanath Ramamurthi, and Massimo Tornatore University of California, Davis, USA October 9, 2010 Abstract Today s access networks are increasingly shaped by the services that they provide to the end users. In a hybrid wireless-optical broadband access network (WOBAN), to access any service, the corresponding requests for the services and responses require multi-hop communication over the wireless mesh network (WMN) and Passive Optical Network (PON) subsequently over the Internet to some server in the application service provider s domain. This may cause bottlenecks in the WMN and may result in degraded performance. In this paper, we propose a design for WOBAN that integrates a cloud over WOBAN (CoW) that provides different cloud services from within the access network. This has multiple benefits: 1) it offloads traffic over wireless links, 2) it reduces bottleneck from the gateways of WOBAN, 3) it reduces delays, and 4) it allows providers to facilitate different cloud services with their access network. In this paper, we study the issue of determining how the cloud components providing the services should be placed in WOBAN in order to optimize the resources while providing better service. We formulate this problem as a Mixed-Integer Linear Program (MILP) and solve it using CPLEX. We show that, by integrating cloud with WOBAN, we can obtain significant performance improvement. 1 Introduction Recent industry research [1] shows that wired and wireless networking technology must be treated as an integrated entity to create a flexible, service-centric network architecture. A possible such architecture is a Wireless-Optical Broadband Access Network (WOBAN) that has a wireless mesh network (WMN) to provide end users access and an optical backhaul network to carry the aggregated traffic collected over the WMN [2]. The optical backhaul network comprises of a Passive Optical Network (PON) [3] with an Optical Line Terminal (OLT) in the Central Office (CO) which is connected via optical fiber to multiple Optical Network Units (ONU). At the front-end of WOBAN, a set of wireless nodes 1

2 (routers) form a WMN. An architecture such as WOBAN shown in Fig. 1 can achieve cost-effectiveness of a WMN while having higher performance due to the high-capacity optical backhaul network. End users, both mobile and stationary, connect to the network through these wireless nodes, whose locations are generally fixed. Data usually travels in a WMN over multiple wireless hops, known as wireless backhaul. A selected set of these nodes, called gateways, are connected to the optical part of the network. Usually, gateways are attached to one of the ONUs [2] as shown in Fig. 1. Figure 1: Architecture of a WOBAN. Today s access networks, such as a WOBAN, are increasingly shaped by the services that they provide to the end users. Generally, these services are accessed from a cloud. A cloud is anything that facilitates storage, deployment, and delivery of services over the Internet. Many of such services are storage, localized applications, software-as-a-service (SaaS) etc. Figure 2: Traditional cloud access in WOBAN. 2

3 In current scenario, in a WOBAN, these cloud services are accessed using WiFienabled end devices [4] (WiFi is usually free in most of the cases) from cloud servers that can be anywhere in the network. Consequently, in a WOBAN, a user s request for a cloud service must be transported through the wireless mesh, possibly over multiple hops, to reach the OLT via the gateways and delivered to an appropriate server. The response from the server for the different services are also transported over multiple wireless hops to the end users. This traditional setting is shown in Fig. 2 where each service requested by an end user consumes wireless bandwidth in the WMN which is is limited because of contention, interference, and limited capacity [5]. Moreover, because most traffic flows have to go through one of the few gateways, links near the gateways become bottleneck. In this work, we propose an architecture, Cloud-over-WOBAN addresses these limitations. In CoW, we propose to integrate cloud components (CC), such as storage [6] and servers [7], within the WMN of a WOBAN. Many cloud services are local and the geographic relevance of these services is within the footprint of the front end of a WOBAN. Unlike a typical content distribution system, a CoW hosts and serves these cloud services locally using the CCs. These services can be accessed from the CCs through ubiquitous web-based interfaces and are enabled by the recent developments of secure communications [8]. Figure 3: A Cloud-over-WOBAN (CoW). Availability of these low-cost, easy to deploy CCs [6, 7] makes CoW a technologically feasible and practically deployable architecture. Such an architecture, as shown in Fig. 3, can offload the traffic of some of the cloud services to the locally hosted CCs of the wireless and optical backhaul of WOBAN. This reduces the volume of traffic needed to be carried over the wireless backhaul. As practitioners in the industry are considering offloading as a technique to reduce bottleneck in the backhaul [9], this inherent offloading property of CoW makes it an attractive architecture. Offloading of service traffic reduces wireless contention, frees-up capacity for other traffic which can be used to increase the 3

4 offered load of the network, and reduces congestion near the gateways. As a result, significant performance improvement of WOBAN can be achieved. In this paper, we discuss the architecture and implementation options for a CoW. We also present an intelligent placement scheme of CC in a CoW through a Mixed- Integer Linear Program (MILP). Our performance evaluation shows that CoW allows a significant reduction of average network-wide packet delay and increases the offered load of WOBAN. The rest of the paper is organized as follows. Section 2 discusses the related work. Section 3 introduces CoW. Section 4 presents optimal placement of cloud components in a CoW. Illustrative numerical examples are shown in Section 5. Section 6 concludes the study. 2 Related Work There are several proposal for improving services over WOBAN. Capacity and Delay-Aware Routing Algorithm (CaDAR) [10] performs optimum capacity distribution on wireless links and performs shortest-delay-path routing in WOBAN. Cost-effective capacity enhancement of the WMN is shown in [5] to improve the performance over wireless backhaul. However, none of the solutions integrates cloud with WOBAN for a service-oriented design. There are several papers in the literature that discuss architecture designed for services. An overview of service-oriented architecture through web services is presented in [8]. It discusses different types of distribution that vary from cluster-based homogeneous systems to supporting a variety of operating services and environments. It provides schematics of service interactions in serviceoriented environments. In [11], a traditional view of Service-Oriented Architecture (SoA) presented as providing service through web-based interfaces and enterprise-level service integration through a common platform such as XML. In another similar approach, [12] promotes visualization of information technology related services and its potential value generation and technology adaptation that enables it. In [13], service-oriented network design is derived from these concepts of SoA where the network plays a key role exchanging information among different components of SoA through transmitting data rapidly and reliably. A service-oriented network design for wireless sensor networks is presented in [14] where each layer of the sensor network is divided in to several planes to incorporate service-oriented network architecture to provide better understanding of the network. Many of the services requested by the users are local; hence location dependent services are important to identify. An overview and classification of services that are location dependent and local are discussed in [15]. It opines that for any wireless access network such as WOBAN, location-based services, i.e., local services, are an additional source of revenue generated from the investments in the infrastructure [15]. However, none of them discusses an infrastructure-based integration of cloud with an access network for an SoA. 4

5 3 Cloud-over-WOBAN (CoW) In order for a service provider to guarantee the cutting-edge cloud services to its users, it is important to integrate the services into network provisioning and planning [16]. Hence, we present CoW, an architecture that integrates clouds with an access network. 3.1 Why CoWs are Important? Many of the cloud services requested by the end users are local, and quite often, it is possible to serve them locally. For example, a spam originating from a WOBAN can be blocked within the wireless front-end without the need for it to go to the OLT; finding parking locations, rates, and finding parked cars can be served with local information. Moreover, if the service is local, (e.g., parking location) it is better to manage the local changes locally. These local services can be served by a WOBAN if a cloud is integrated with it. Hence, CoW offloads traffic from wireless backhaul and reduces its bandwidth usage, removes bottleneck near gateways by diverting traffic away, increases offered load of the network by responding to requests locally, and keeps updates local, as shown in Fig. 3. It is important to note that integrating a cloud is particularly suitable for a WOBAN. As a WOBAN is driven by an OLT from a central office, it is shown in [10] that it is possible to route and manage the wireless and optical traffic together. As a result, the traffic to the CCs, e.g., storage, in CoW can be managed through routing over WOBAN. 3.2 CoW Architecture In a CoW, we add CCs, such as storage, or a server, with the wireless nodes of a WOBAN. If a cloud-service request can be served from within, it is forwarded to the appropriate CC instead of the OLT. Then, the CC sends back the corresponding response. Depending on the policy of the service provider, equipment provider, and types of services, these CCs may differ. If a CC is integrated and served with a wireless node, we refer to it as the host node for the service. With today s technology, memory and processing power is available within reasonable cost [7]. On the other hand, wireless backhaul bandwidth is scarce [17]. Thus, this architecture is technologically feasible with current technology. When an end user needs to access a cloud service from a CoW, a cloud request is sent to the wireless node it is connected to. When the request reaches the wireless node from the user, if the service is available from CC attached to that wireless node, directly responds to the end user after processing. If the service is not available, the wireless node sends the request to a nearby host node if the service is available from WOBAN. Otherwise the request is sent to the OLT. The following two are the major ways of implementing a CoW: 1. CoW-I: if the WMN part of a WOBAN is deployed using the implementation model of Wisper [18], which keeps user development space on WMN products, and provides blank wireless box for development, then each CC can be integrated within the wireless node. For this Integrated CC (ICC) based implementation, additional hardware need is minimal as each node has some 5

6 spare processing capacity and memory that can be utilized to host services. In that case, cost of bandwidth is more prominent than hardware cost. But in such an implementation, each node may host only a few cloud services, so the services are needed to be distributed among all the nodes. This design is called CoW-I as shown in Fig. 4(a). 2. CoW-S: for other implementation models, such as Firetide [19] (separate base stations for user access in Fig. 4(b)) or Tropos [20] (integrated base stations for user access in Fig. 4(b)), additional Selective CCs (SCC), e.g., a light weight or thin server [7], or a storage [6], with capability to serve local cloud services, are connected via Ethernet to some wireless nodes based on the traffic demands. For this implementation, as additional SCCs are deployed, each of them can potentially host several services, so only a few of such server is needed. The design goal is to deploy as few SCC as possible while serving all the desired services. This design is called CoW-S as shown in Fig. 4(b). (a) CoW-I (b) CoW-S Figure 4: Various implementation approaches for a CoW. 4 Optimum Placement of CC in CoW To design a CoW, a set of wireless nodes needs over WOBAN to be selected that should be be equipped with CCs. This CCs are distributed based on the demands and requirements of the cloud services. To have a cost-effective solution, the number of such nodes needs to be minimized in such a way that it increases the bandwidth efficiency. Here, the cost of each application has two parts: a) cost of processing and memory, and b) cost of bandwidth. Note that we only consider the wireless backhaul capacity, where we intend to gain our performance improvement. We do not consider user access because usually each node have dedicated resources (a dedicated radio) to communicate with the end users. Our objective is to minimize deployment cost while assigning the CCs to CoW, under the constraints that hosts for each service should be reached within certain hops, and the deployment cost is within the budget. We develop the following MILP to formulate our problem and assign CCs to WOBAN: 6

7 4.1 Inputs to the MILP: ω(n) = set of N nodes of WMN of a WOBAN (K) = set of K services to be deployed over WOBAN u = a node in WMN of a WOBAN, u ω(n) v = a neighbor of node u in WMN of a WOBAN, node u has a transmission link to node v, v ω(n) k = a cloud service to be deployed in WOBAN, k (K) i = a node in WMN of a WOBAN with a demand for a cloud service, i ω(n) h = maximum number of hops a service-response travels over the wireless backhaul C u = radio capacity of node u I uv = set of links that interfere with link (u, v) 1 α uv = fraction of background traffic (regular mesh traffic) on each link (u, v) D I u = Cost of an SCC deployment at node u D k m = Cost of memory for Service k D k p = Cost of processing for Service k D k BW = Cost of unit flow over a link for Service k M = a large number R k m = Memory resource required for Service k R k p = Processing resource required for Service k φ m u = Memory resource available at node u φ p u = Processing resource available at node u γ k i = aggregated demand for Service k from node i z k,i u,h = 1, if demands for Service k from node i is served by node u within h hops 1 Let SNR uv = signal-to-noise ratio of link (u, v), P uv = transmitted power over link (u, v), G uv = distance(u, v) a, a = polynomial constant, σ = thermal noise at receiver, β = threshold for SNR uv, S = set of links s.t. k = u, v, x = v. A link (p, q) I uv if P SNR uv = uvg uv (k,v) S P kxg kv +σ 2 β when link (p, q) is active. 7

8 4.2 Variables for the MILP: x k u = 1, if Service k is served from node u y u = 1, if an SCC is deployed at node u w k,i u = 1, if Service k is served from node u for a demand from node i λ k,i vu = flow on link (u, v) for Service k for a demand from node i C uv = capacity on link (u, v) Minimize : k D k + u y u D I u (1) D k = x k u (Dm k + Dp) k + u (λ k,i uv DBW k ); k (2) i u v k y u xk u ; u (3) M (x k u Rm) k φ m u ; u (4) k (x k u Rp) k φ p u; u (5) k (x k u z k,i u,h ) 1; k (6) u v λ k,i vu v λ k,i uv = γ k i w k,i u ; k, u, i(i = u) (7) wu k,i x k u; u (8) wu k,i = 1; k, i (9) u i k λ k,i uv (1 α uv ) C uv ; u, v (10) C uv + C vu C u ; u (11) v v C vu + C pq C u ; u (12) v (p,q) I uv x k u,y u, w k,i u {0, 1}; k, u, i (13) The objective function, Eqn. (1), minimizes cost for all services. The first part of Eqn. (1) is the sum of processing, memory, and bandwidth cost for each service. The second part of Eqn. (1), expressed by Du, I is the cost of CC deployment and it is applicable only if CoW-S is deployed. For CoW-I, all 8

9 the values of Du I are 0. Among the constraints, Eqn. (2) defines the cost of each service: the first part indicates the processing and memory cost of each cloud service, and the second part describes the cost of bandwidth. If a wireless link (u, v) carries some traffic for any Service k, then it will incur a cost of bandwidth, otherwise not. Equation (3) indicates if an SCC is deployed at a node u. Equations (4) and (5) bound the processing capacity and memory at each node such that the total processing and memory need for all services at any node u should be less than its available processing capacity and memory. Equation (6) puts the hop-bound for all the nodes for each cloud service such that every node that requests any Service k should be covered by at least one node within h hops over the wireless backhaul. The value of h should not be large because with larger number of wireless hops, the performance of WMN would degrade. This constraint holds when for any Service k, at least one of the nodes that are reachable from node i within h hops hosts Service k and the corresponding indicator variable x k u takes the value 1. Equation (7) gives the flow constraint. If a request from any node i for Service k is terminated at node u, then the demand γi k is served at u. Compared to the classical flow constraint in network design problems, here the destination is not known in advance; it can be any of the host nodes of Service k, including node i. The variable wu k,i determines if node u is the destination for a demand from node i. If node u is the destination, the flow constraint takes up the value γi k, otherwise 0. Moreover, Eqn. (7) ensures that if node i hosts Service k, then there is no flow introduced to the network for a demand from node i. Equation (8) ensures that a request from any node i for Service k is served by one of the host nodes of Service k. Equation (9) ensures only one node u serves a request from node i for Service k. Equation (10) is the capacity constraint: it ensures that the service traffic is within the capacity that are not used by background traffic. Equations (11) and (12) are specific to wireless capacity assignment [17]. Equation (11) describes that a wireless node s transmission capacity is shared with the reception capacity, as a wireless radio cannot transmit while receiving. Similarly, Eqn. (12) describes that the reception capacity of a wireless node is shared with all the links for which the signal to noise and interference ratio is higher than a threshold. Equation (13) defines binary indicator variables for each node, u. If any node u should host Service k, the value of x k u is 1, otherwise the value is 0. Similarly, the value of wu k,i is 1 if a request from any node i for Service k is served by node u. 5 Illustrative Numerical Examples To study the advantages of a CoW, we use the 23-node wireless network with three gateways in the Segundo Housing area of University of California, Davis, as shown in Fig. 1. Each radio has a capacity of 54 Mbps. We analyze the impact of different deployment of services in WOBAN and how it affects the performance. In our performance evaluation, we consider that if a service is served within the network, it should be reached within h hops over the wireless backhaul. 9

10 System delay (msec) Traditional CoW I CoW S Background load at each node (Mbps) Figure 5: System delay vs. background load for 4 services for h = 1. We evaluated the performance of both CoW-S and CoW-I described in Section 3.2. First, we solve the MILP described in Section 4 and design CoW by distributing 4 and 8 cloud services and assign the cloud components to different nodes accordingly. Each service vary in processing and memory requirements. We assume that a CC can host several services, based on the processing and memory requirements. We created the demand matrix of services by taking the average of 1000 randomly generated demands for each service for each node. We solved the LPs using ILOG CPLEX 9.0 on a Ubuntu Linux operating system on a Intel Core 2 Duo machine with 1 Gigabyte RAM. The MILPs were solved between 0.4 to 2.16 seconds for 4 services and between 35.5 seconds to 6.8 hours for 8 services. After allocating the services, we evaluate each solution by satisfying the demand for services and inserting background traffic to the network. The formulation in Section 4 gives the design of a CoW by providing the placements of CCs. To evaluate this design, we use CaDAR [10], an efficient routing algorithm for WOBAN, for the routing of the demands in CoW to obtain the flows on links. Performance of CaDAR compared to other schemes is presented in [10]. We used the performance parameter system delay which is the average networkwide packet delay [21] to compare the performance of various implementations in the network in Fig. 1. In our evaluation, for fair comparison, we first insert the cloud traffic in the network. Then, we increase the background traffic and evaluate the performance. In this way, we obtain the overall system delay based on the total (both cloud and background) traffic demand. Note that in each of the illustrative examples, all the graphs have the same cloud traffic, so we only compare based the additional background traffic. Figure 5 shows the impact of deploying 4 services for a CoW. Here, service delivery from the cloud is allowed to travel only 1 wireless hop. We see that 10

11 0.7 System delay (msec) Traditional CoW S (1x load) CoW S (2x load) CoW S (3x load) Background load at each node (Mbps) Figure 6: Sensitivity analysis of cloud traffic for h = 1 and 4 services. the CoW carries almost twice the background traffic after satisfying the cloud s demands with about half the system delay than a traditional deployment of WOBAN in Fig. 1. This performance improvement is due to offloading of cloud traffic from wireless backhaul. We see that CoW-S carries almost the same traffic as the CoW-I with slightly higher delay. This is because the CoW-S minimizes the number of deployed SCCs, and hence introduces some traffic in the WMN while nodes with CoW-I mostly serve locally. For sensitivity analysis, Fig. 6 shows the system delay variations for increasing cloud traffic for h=1 for 4 services. We observe that with lower service traffic demand, the performance of our design is better than traditional approach. With increasing (up to three times) service load, our approach performs consistently better. We also observe that for lower background traffic, higher service traffic can be accommodated leading to lower the system delay as more traffic demands are served locally. Figure 7 shows the performance of a CoW when service delivery is allowed to travel up to 2 wireless hops. We do not consider any more hops because, in Fig. 1, 3 or more hops carries traffic to gateways from any node. Moreover, any higher number of wireless hops will result in degraded performance. We observe that increasing the number of hops does not impact the performance of CoW-I as most of the services are served locally by this approach. For CoW-S with 2 hops, the number of SCC deployed in the network decreases (Fig. 9) as cloud traffic is allowed to travel more hops to satisfy the demands. But this leads to higher system delay and reduced background traffic carried by CoW. Figure 8 shows the performance of the CoW when the number of cloud services served by the network is 8. CoW-I does not have a feasible solution if only 1 hop is allowed because the integrated routers cannot host a large number of services (Section 3.2). If 2 hops are allowed, CoW-I carries higher background traffic as 11

12 0.5 System delay (msec) CoW I (1 hop) CoW S (1 hop) CoW I (2 hops) CoW S (2 hops) Background load at each node (Mbps) Figure 7: System delay vs. background load for 4 services for h = 1. most of the service traffic is absorbed locally. We see that CoW-S with 2 hops has higher delay than 1 hop because it introduces more traffic to the network. But it carries more background traffic as it diverts more traffic away from the gateways. Figure 9 shows the relative cost of traditional, CoW-I, and CoW-S. We consider wireless router cost as unit cost. Because SCCs are built on system boards [7] and requires additional memory, we assume that a SCC costs twice that of wireless router. We consider that at least one cloud server is required for traditional implementation, with at least a cost twice that of an SCC. Because of volume discount, we consider the cost of CoW-I to be 2.5 times the cost of a wireless node. We see from Fig. 9 that the CoW-S requires a slight increase of cost while CoW-I costs almost twice that of the traditional approach. This is because the objective of our placement formulation (Eqn. (1)) minimizes the number of SCC. We see from our performance evaluation that the CoW-I achieves better performance, but does not support higher number of services, and has higher cost. On the other hand, CoW-S achieves significant performance gain over the traditional implementation with a slight increase of cost, and can support higher number of services. 6 Conclusion Service-centric behavior of end-users is shaping the traffic pattern of today s networks. As a cost-effective access technology, WOBAN delivers such services to end-users. But these services are mostly destined to an external cloud that take up wireless backhaul bandwidth, create bottleneck at the gateways, and have 12

13 System delay (msec) CoW I(2 hops) CoW S (1 hop) CoW S (2 hops) Background load at each node (Mbps) Figure 8: System delay vs. background load for 8 services for h = 1 and 2. a possibility of stale server updates. Equipping WOBAN with cloud components leads to an intelligent access network design, called CoW, that addresses these limitations. We presented a optimum design for a CoW using an MILP. We observed that, CoW can achieve significant performance improvement through offloading of traffic even for low service demand. We conclude that CoW is a technologically viable access network design that can improve the performance of a WOBAN in a cost-effective way. References [1] Butler Group, Application delivery: Creating a flexible, servicecentric network architecture. Delivery-Creating-R663-21/, Sep [2] S. Sarkar, S. Dixit, and B. Mukherjee, Hybrid wireless-optical broadband access network (WOBAN): A review of relevant challenges, IEEE/OSA Journal of Lightwave Technology, vol. 25, no. 11, pp , Nov [3] F. Effenberger, D. Clearly, O. Haran, G. Kramer, R. Li, M. Oron, and T. Pfeiffer, An introduction to PON technologies, IEEE Communication Magazine, vol. 45, no. 3, pp. S17 S25, Mar [4] ABI Research, Wi-fi capable handsets. Aug [5] A. Reaz, V. Ramamurthi, S. Sarkar, D. Ghosal, and B. Mukherjee, Hybrid wireless-optical broadband access network (WOBAN): Capacity en- 13

14 Hop 2 hops 40 Relative Cost Traditional CoW I CoW S CoW S 4 Services 8 Services Implementation Scheme Figure 9: Relative cost of different implementation models. hancement for wireless access, in Proc. IEEE Globecom, New Orleans, LA, pp. 1 5, Dec [6] CTERA Networks, Cloudplug. [7] PC Engines, ALIX system boards. [8] L. Srinivasan and J. Treadwell, An overview of service-oriented architecture, web services and grid computing, HP Software Global Business Unit, vol. 2, Nov [9] P. Donegan, R. Brandon, A. Jones, T. Naveh, and T. Hack, Backhaul to the future: Mobile broadband profitability requires smarter backhaul networks. Light Reading Webinar, Sep [10] A. Reaz, V. Ramamurthi, S. Sarkar, D. Ghosal, S. Dixit, and B. Mukherjee, CaDAR: An efficient routing algorithm for a wireless-optical broadband access network (WOBAN), Journal of Optical Communications and Networking, vol. 1, no. 5, pp , Oct [11] T. Erl, Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services, Prentice Hall PTR, [12] N. Bieberstein, S. Bose, L. Walker, and A. Lynch, Impact of serviceoriented architecture on enterprise systems, organizational structures, and individuals, IBM Systems Journal, vol. 44, no. 4, no. 4, pp ,

15 [13] Zeus Technology Limited, Building a service oriented network using a service delivery controller. Building a Service Oriented Network.pdf, [14] D. Graˇcanin, M. Eltoweissy, A. Wadaa,, and L. DaSilva, A service-centric model for wireless sensor networks, IEEE Journal of Selected Areas in Communications, vol. 23, no. 6, pp , Jun [15] B. Rao and L. Minakakis, Evolution of mobile location-based services, Communications of the ACM, vol. 46, no. 12, pp , Dec [16] Comarch Information Technology, Service-centric OSS. Comarch Whitepaper, Jul [17] V. Ramamurthi, A. Reaz, and B. Mukherjee, Optimal capacity allocation in wireless mesh networks, in Proc. IEEE Globecom, New Orleans, LA, Dec [18] Devcom Solutions AB, Wisper wireless. [19] Firetide, Wireless mesh products. [20] Tropos Networks, Wireless mesh products. [21] L. Kleinrock, Queueing Systems, Volume II: Computer Applications, Wiley- Interscience,