BTP

Hybrid Cellular Networks:
Architectures, Protocols, and Pricing
A Project Report
submitted in partial fulfillment of the requirements

for the award of the degree of
Bachelor of Technology
in
Computer Science and Engineering
by
Vyas Sekar
under the guidance of
Prof. C. Siva Ram Murthy
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

INDIAN INSTITUTE OF TECHNOLOGY MADRAS
April 2003
Certificate
This is to certify that the project entitled Hybrid Cellular Networks: Archi-
tectures, Protocols, and Pricing submitted by Vyas Sekar in partial fulfillment
of the requirements for the award of the degree of Bachelor of Technology, is a
bona-fide record of work carried out by him under my supervision and guidance at
the Department of Computer Science and Engineering, Indian Institute of Technology
Madras.
Place: Chennai [Prof. C. Siva Ram Murthy]

Date:
Acknowledgments
I am grateful to Prof. C. Siva Ram Murthy for his motivation and guidance during
my project work. I would like to thank my batchmates Archana, Gaurav, Jagadeesan,
and Vidhyashankar and Manoj for their invaluable support and inputs. I would like
to thank the WDM group (Raghu Kiran, Harsha, Srinivas, and Sushanth) for their
company both in the lab and outside. I would also like to thank the MS and Ph. D
scholars at the HPCN lab for providing a congenial working environment.
My experiences at the Department of Computer Science and Engineering, IIT
Madras have helped me gain a lot, both intellectually and psychologically. I am also
grateful to the Head of the Department Prof. S. Raman, for the excellent computer
facilities and my faculty advisor Prof. R. Kalyanakrishnan, for his guidance during
my undergraduate student career.
Place: Chennai [Vyas Sekar]

Date:
Abstract
The phenomenal growth of the Internet and wireless connectivity has caused an enor-
mous need for higher capacity cellular wireless networks which can efficiently handle
a variety of network loads, service highly mobile users with smooth hand-offs, offer
connectivity through a variety of access points, manage both best-effort and real-time
connections concurrently with QoS support for delay sensitive applications and above
all be extendible from the existing infrastructure to form the basis of the next gener-
ation 4G cellular systems. The capacity of future cellular systems can be enhanced
by using various throughput enhancement techniques such as multihop relaying, the
use of sectorized/directional antennas, and the use of efficient routing and resource
allocation strategies. We have identified three new architectures that belong to the
vast domain of hybrid cellular architectures, and present the various issues involved
and the solutions we have proposed. We also present a brief overview of pricing
as a means to stimulate cooperation in multihop relaying networks and discuss new
reimbursement schemes for pricing for data traffic in hybrid cellular networks.
We present a new architecture for Multihop Cellular Networks (MCNs), which
uses a single wireless interface for both the control and data transmission. We pro-
pose an efficient routing protocol for single interface MCNs and compare it with an
existing prototype implementation. The primary motivation for exploring this single
interface mechanism is to provide low cost, low power consumption mobile devices.
We compare our routing protocol Single interface MCN Routing Protocol (SMRP)
with Base driven Multihop Bridging Protocol (BMBP) through simulation studies
using GloMoSim.
Multihop relaying in wireless networks has found a variety of applications in
diverse domains such as Ad hoc wireless networks, wireless mesh networks, wireless
sensor networks, and hybrid cellular architectures such as MCNs. Pricing frameworks
are essential to enforce participation, and also provide a good billing and accounting
system for realistic deployment. We present some of the current pricing solutions in
diverse domains, and also enumerate the key issues that need to be addressed in other
deployment scenarios that do not have any current pricing proposals. Since pricing
in hybrid cellular architectures such as MCNs is a key issue which is not addressed so
far, we propose a set of incentive-based pricing schemes for packet based traffic that
are not bound by mobility or load constraints. The suggested reimbursement schemes
also take into account the retransmission attempts made by the intermediate nodes.
The rapid emergence of Wi-Fi hotspots that are aimed at providing broadband
wireless access to users in and around places of commercial interest presents the unique
problem of integrating the existing Cellular/GSM networks with these. In this report,
we present a hybrid architecture that explores the interoperability issues between the
hotspots, which we model as an MCN, and the traditional Cellular network. We
study the architecture under various network conditions, and also identify some of
the key issues such as differentiated service and pricing.
The use of Wireless in Local Loop (WiLL) has generated considerable interest
due to the advantages it offers such as the ease and low cost of deployment and main-
tenance. With an increase in the number of subscribers in the network, it becomes
expedient to employ spectrum reusability techniques such as the use of multihop re-
laying and directional antennas, in order to improve the capacity and throughput of
the WiLL system. We propose a new system for the WiLL called DWiLL that employs
multihop relaying and the use of directional antennas for throughput enhancement.
We study the performance of the DWiLL system through extensive simulations and
identify some of the key issues involved in realistic deployment of such a system.
iv
Table of Contents
Acknowledgments ii
Abstract iii
List of Figures viii
List of Tables 1
1 Introduction 2
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Our Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Organization of this Report . . . . . . . . . . . . . . . . . . . . . . . 4
2 Multihop Relaying in Cellular Networks 5

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 The MCN Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 The MuPAC Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Routing Protocol in MuPAC . . . . . . . . . . . . . . . . . . . 8
2.4 Real-time Architectures . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 TWiLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 RT-MuPAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 The Single Interface MCN Architecture 13

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Base-driven Multihop Bridging Protocol (BMBP) . . . . . . . . . . . 14
3.2.1 Messages used in BMBP . . . . . . . . . . . . . . . . . . . . . 14
3.2.2 Protocol Description . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Issues in Routing for the Single Interface MCN Architecture . . . . . 16
3.4 Single Interface MCN Routing Protocol (SMRP) . . . . . . . . . . . . 16
3.5 Comparison of Control Overhead . . . . . . . . . . . . . . . . . . . . 19
3.5.1 SMRP Control Overhead . . . . . . . . . . . . . . . . . . . . . 19
3.5.2 BMBP Control Overhead . . . . . . . . . . . . . . . . . . . . 20
3.6 Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6.1 Performance Comparison of SMRP and BMBP . . . . . . . . 21
3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Pricing in Multihop Wireless Networks 24

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Issues in Pricing for Multihop Wireless Networks . . . . . . . . . . . 24
4.3 Pricing in Military and Tactical Applications . . . . . . . . . . . . . . 26
4.4 Pricing in Multihop Wireless WANs . . . . . . . . . . . . . . . . . . . 26
4.5 Pricing in Ad hoc Wireless Networks . . . . . . . . . . . . . . . . . . 27
4.6 Pricing in Hybrid Cellular Architectures . . . . . . . . . . . . . . . . 28
4.6.1 A Micropayment Scheme for MCNs . . . . . . . . . . . . . . . 28
4.6.2 Pricing for Voice Traffic . . . . . . . . . . . . . . . . . . . . . 29
4.6.3 Pricing for Data Traffic . . . . . . . . . . . . . . . . . . . . . . 30
4.6.4 EESR (End-to-End Success Reimbursement Scheme) . . . . . 31
4.6.5 ERSR (End-to-end and Retransmit Attempts Scheme of Reim-
bursement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6.6 HHSR (Hop by Hop Successful Delivery Reimbursement) . . . 34
4.6.7 HRSR (Hop by hop Successful Delivery and Retransmit At-
tempts Scheme for Reimbursement) . . . . . . . . . . . . . . . 35
4.6.8 Simulation Results for Pricing Schemes . . . . . . . . . . . . . 36
4.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 A Framework for Interoperability of Wi-Fi Hotspots and Wide Area

Packet Cellular Networks 43
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Wi-Fi Service Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4 Routing Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5.1 Number of Hotspots . . . . . . . . . . . . . . . . . . . . . . . 48
vi
5.5.2 Privileged Users . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5.3 Varying Offered Load . . . . . . . . . . . . . . . . . . . . . . . 50
5.5.4 Varying Node Density . . . . . . . . . . . . . . . . . . . . . . 50
5.5.5 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6 Pricing Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6 On the Use of Directional Antennas and Multihop Relaying in Wire-

less in Local Loop Systems 56
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2 Directional Antennas . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3 The DWiLL Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.1 System Parameters and Issues . . . . . . . . . . . . . . . . . . 59
6.3.2 Routing and Call Setup . . . . . . . . . . . . . . . . . . . . . 59
6.3.3 The Call Setup Procedure . . . . . . . . . . . . . . . . . . . . 60
6.4.1 Number of Single-hop Channels . . . . . . . . . . . . . . . . . 61
6.4.2 Varying θ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.4.3 Varying Offered Load . . . . . . . . . . . . . . . . . . . . . . . 63
6.4.4 Varying Locality . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.4.5 Interference Parameters . . . . . . . . . . . . . . . . . . . . . 63
6.4.6 Node Density Results . . . . . . . . . . . . . . . . . . . . . . . 64
6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7 Conclusions and Future Work 65

7.1 The SMCN Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2 A Framework for Integration of MCNs and Ad hoc Wireless Networks 66
7.3 Open Problems in Pricing for Multihop Wireless Networks . . . . . . 67
7.4 Interoperability Issues in Hybrid Cellular Networks . . . . . . . . . . 67
7.5 Directional Multihop Relaying in WiLL Systems . . . . . . . . . . . . 68
Bibliography 69
vii
List of Figures
2.1 MCN best-effort architecture . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Packet transmission in a 2-channel MuPAC . . . . . . . . . . . . . . . 9
2.3 MCN real-time architecture (a) Call setup (b) Path break (c) Interference 10
2.4 Nodes affected by transmission in hop(A, B) . . . . . . . . . . . . . . 10
3.1 Messages in BMBP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 SMRP control routing . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Performance Vs node density at no mobility . . . . . . . . . . . . . . 22
3.4 Performance Vs density with limited mobility 2 m/s . . . . . . . . . . 22
3.5 Performance Vs locality at 100 nodes at no mobility . . . . . . . . . . 22
3.6 Performance Vs load at 100 nodes at no mobility . . . . . . . . . . . 22
3.7 Performance Vs mobility at 100 nodes with UDP mean inter arrival
time 30ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.8 Effect of route cache on packet delivery ratio with UDP mean inter
arrival time 30ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1 EESR pricing information reporting . . . . . . . . . . . . . . . . . . . 32

4.2 Schematic representation of the pricing schemes . . . . . . . . . . . . 36
4.3 Average net expenditure of nodes . . . . . . . . . . . . . . . . . . . . 37
4.4 Average net expenditure of nodes . . . . . . . . . . . . . . . . . . . . 37
4.5 Variation in net expenditure of nodes with distance at UDP mean
inter arrival time 20ms with 150 nodes and 6 cells Distance from Base
= ((x-1)*50 - x*50 ) metres . . . . . . . . . . . . . . . . . . . . . . . 38
4.6 Average net expenditure of nodes with UDP mean inter arrival time
20ms with 10% nodes generating traffic . . . . . . . . . . . . . . . . . 38
4.11 Service providers income Vs load . . . . . . . . . . . . . . . . . . . . 39
4.12 Service providers income Vs locality . . . . . . . . . . . . . . . . . . . 39
4.13 Effect of α on service providers revenue . . . . . . . . . . . . . . . . . 40
4.17 Percentage of nodes making a profit Vs locality at 10% nodes generat-
ing traffic in ERSR and HRSR schemes . . . . . . . . . . . . . . . . . 41
5.1 The proposed architecture . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Routing scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Performance Vs number of hotspots . . . . . . . . . . . . . . . . . . . 49
5.4 Performance Vs number of hotspots . . . . . . . . . . . . . . . . . . . 49
5.5 Performance Vs number of Type 1 MSs . . . . . . . . . . . . . . . . . 50
5.6 Performance Vs offered load . . . . . . . . . . . . . . . . . . . . . . . 50
5.7 Performance Vs number of MSs . . . . . . . . . . . . . . . . . . . . . 51
5.8 Performance Vs mobility . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.9 Total number of handoffs Vs mobility . . . . . . . . . . . . . . . . . . 52
5.10 Fraction of nodes in cellular mode Vs mobility . . . . . . . . . . . . . 52
6.1 The DWiLL architecture . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.2 Call acceptance ratio Vs number of SCs . . . . . . . . . . . . . . . . . 62
6.3 Call acceptance ratio Vs theta (SCs= 26) . . . . . . . . . . . . . . . . 62
6.4 Call acceptance ratio Vs load . . . . . . . . . . . . . . . . . . . . . . 63
ix
6.5 Call acceptance ratio Vs locality . . . . . . . . . . . . . . . . . . . . . 63
6.6 Performance with increasing interference range . . . . . . . . . . . . . 64
6.7 Call acceptance ratio Vs node density . . . . . . . . . . . . . . . . . . 64
x
List of Tables
3.1 Simulation parameters used for SMRP . . . . . . . . . . . . . . . . . 21
5.1 Simulation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2 Notations used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1 DWiLL parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

CHAPTER 1
Introduction
1.1 Motivation
Even though wireless networks offer enormous advantages over the traditional wired
networks in terms of ease of installation, ease of use, cost of operation etc., they
are often plagued by problems such as congestion, limited bandwidth, high bit error
rate, time varying channel properties, and low throughput. With recent performance
improvements in computer and wireless technologies, advanced mobile wireless com-
munication is expected to encounter extensive use and application in the near future.
The phenomenal growth of the Internet and wireless connectivity has caused an explo-
sive need for higher capacity wireless networks which can efficiently handle a variety
of network loads, service highly mobile users with smooth hand-offs, offer connectivity
through a variety of access points, manage both best-effort and real-time connections
concurrently with QoS support for delay sensitive applications and above all be ex-
tendible from the existing infrastructure to form the basis of the 4G cellular systems.
In the recent past there has been a rather heavy proliferation of mobile subscribers.
While the subscriber density increases, the electromagnetic spectrum’s capacity re-
mains the same thus limiting the number of subscribers who can be simultaneously
served. This is the single biggest stumbling block faced by wireless network operators
in expanding their network and improving their subscriber base thus boosting profits.
Hybrid cellular networks are a viable alternative to traditional cellular networks
for throughput enhancement and also supporting a greater number of subscribers.
These networks incorporate characteristics of both traditional cellular networks and
Ad hoc wireless networks. Ad hoc wireless networks were intended for military, tac-
tical, and emergency search and rescue applications, where the need for an instant,
infrastructure-less, and reliable communication network that could be deployed with
very low cost and low time-investment, was felt. Gradually though, the applications
have extended to civilian domains, for providing low cost network access to homes
and mobile users. The key idea that hybrid cellular architectures borrow from the
Ad hoc wireless networks is the concept of multihop relaying of data. Some of the
important requirements of the next generation architectures include greater capacity,
ability to work with multiple types of devices, ability to interoperate with other access
networks, and providing real-time services. Pricing frameworks are essential to en-
force participation, and also provide a good billing and accounting system for realistic
deployment. In Ad hoc wireless networks, the absence of a centralized infrastructure
makes pricing very complex, and it also requires a security framework to detect and
prevent misbehavior by the nodes. In some of the hybrid cellular architectures, the
pricing should be as realistic as possible for large scale commercial deployment.
1.2 Related Work
Lin and Hsu have proposed in [1], a novel cellular architecture where a connection
between the source and the destination is established over a multihop path. [1] dis-
cusses through analysis and simulations, the throughput enhancement achieved by
decreasing data transmission power or equivalently increasing the distance between
BTSs. This has stimulated the development of an extended architecture and routing
protocols in [2] for unicast best-effort and real-time traffic. Lin and Hsu have also
suggested a prototype implementation for Multihop Wireless LANs (MWLANs) in
[3]. A best-effort routing protocol, a real-time protocol and extensions to the MCN
architecture were suggested in [2]. [4] has addressed the issue of power conservation
in MCNs by proposing the use of multiple wireless interfaces operating at a wide
range of transmission ranges, and the transmission of data uses the lowest possible
power for transmission. In [5] the authors identified the use of multihop relaying as
a useful throughput enhancement alternative to traditional Wireless in Local Loop
(WiLL) systems. Since intermediate nodes are involved in call relaying, it is imper-
ative that some form of cost reimbursement be provided. Christo et. al. have also
proposed in [5] three pricing schemes for call relaying in a multihop relaying architec-
ture for enhancing throughput in Wireless in Local Loop system. Microeconomic and
micropayment models have been suggested for enabling forwarding and stimulating
cooperation in a multihop environment.
1.3 Our Work
Our contributions to the domain of Hybrid Cellular Networks include the following:
• We have identified a new MCN architecture that unifies the control and data
planes. We have also proposed and simulated an efficient control and data
routing protocol called SMRP for the Single interface MCN (SMCN) architec-
ture.
• We have proposed a framework for the interoperability of Wi-Fi hotspots, which
are an emerging network accesss mechanism, and Wide Area Packet Cellular
Networks (similar to GSM networks). We have identifed the key issues such as
service differentiation, interoperability, and routing in such a system that has
multiple service providers.
• We have studied a novel architecture for WiLL systems, that uses both direc-
tional and multihop relaying to enhance the capacity of the network.
• We have proposed four reimbursement based schemes for pricing for data traffic
in MCNs, which can be easily extended to other hybrid cellular networks.
3
These schemes differ in the extent of reimbursement that they provide to the
intermediary forwarding nodes. We have proposed two schemes that take into
account the retransmission attempts made by the intermediary nodes. We have
also presented a pricing framework for the interoperability framework between
Wi-Fi hotspots and Wide Area Cellular Networks.
1.4 Organization of this Report
The rest of the report is organized as follows. In Chapter 2 we present a brief overview
of the existing hybrid cellular architectures and the routing protocols. These include
the MCN architectures proposed by Lin and Hsu [1], Ananthapadmanabha et. al.
[2], the MuPAC architecture [4], and the TWiLL architecture [5]. Chapter 3 presents
a brief overview of the motivation for pricing in multihop wireless networks, some of
the issues involved, and some of the existing pricing frameworks for Ad hoc wireless
networks. We also present new reimbursement schemes for MCNs: EESR, ERSR,
HHSR, and HRSR. Chapter 4 discusses the proposed hybrid framework that supports
the interoperability of Wi-Fi hotspots and Wide Area Packet Cellular Networks. We
identify some important service and pricing models for Wi-Fi technologies, and study
the system under varied network conditions. In Chapter 5 we briefly introduce the
concept of directional relaying in wireless networks and its advantages. The DWiLL
architecture is presented in Chapter 5 and the system performance is also studied.
We conclude the report in Chapter 6, and also give directions for future work in the
areas we have explored.
4
CHAPTER 2
Multihop Relaying in Cellular Networks
2.1 Introduction
The basic ingredient in most throughput enhancement attempts has been the in-
troduction of Ad hoc wireless network characteristics. Ad hoc wireless networks [6]
are networks formed without any central administration or infrastructure. Extensive
research has been done in the development of routing protocols for Ad hoc wireless
networks such as Dynamic Source Routing (DSR) protocol in [7], Ad hoc On-Demand
Distance Vector (AODV) routing protocol in [8], Wireless Routing Protocol (WRP)
in [9] and Location-aided Routing (LAR) protocol in [10]. Ad hoc wireless networks,
due to their inherent absence of centralized control, rely heavily on the cooperation
of mobile hosts (MHs). An MH is any single user of the wireless system. Distributed
operation, dynamic network topology, fluctuating link capacity and low power de-
vices are some of the aspects of Ad hoc wireless networks that lead to the biggest
challenges faced by research in this field viz. security, fairness, billing, signaling over-
head and QoS support for real-time applications. Nevertheless, reducing the power
of transmission and hence reaching the destination in multiple hops is one of the best
known techniques to enhance the network throughput, to increase the network service
area and to enable higher data rates due to lesser signal to interference ratio (SIR)
at the receiver node. In recent years, there has been a proliferation of bandwidth
intensive applications that transmit data with real-time characteristics such as inter-
active audio and video. This has inspired the development of systems with enhanced
throughput such as Multihop Cellular Network architecture (MCN) proposed by Lin
and Hsu in [1] and which was further extended by Ananthapadmanabha et. al., in [2],
Integrated Cellular and Ad Hoc Relaying System (iCAR) proposed by H. Wu et. al.,
in [11] and Hybrid Wireless Network (HWN) proposed by Hsieh et. al., in [12]. MCN
is a futuristic variation of traditional cellular networks. MCN attempts to increase
the network capacity by reducing the data transmission power of MHs, and setting
up a multihop path between the sender and the receiver. Thus MCN endeavors to
pick the best of Ad hoc wireless networks viz. high throughput, and that of cellular
networks viz. the presence of base stations which are very powerful centralized points
of control, computation and communication. iCAR is a true cellular system with
some Ad hoc character infused in the form of multihop relay paths. iCAR aspires to
balance the load in the system, thereby increasing the network throughput by relay-
ing excess traffic to adjacent cells through a multihop path over special routers called
Ad hoc Relaying Stations (ARSs). HWN chooses between cellular and ad hoc modes
of operation depending on the network topology. In other words, if the density of
nodes is less the network operates in cellular mode and if the density of nodes is high
it operates in ad hoc mode.
2.2 The MCN Architecture
Lin and Hsu have proposed in [1], a novel Cellular architecture where a connection
between the source and the destination is established over a multihop path. [1]
discusses through analysis and simulations, the throughput enhancement achieved by
decreasing data transmission power or equivalently increasing the distance between
Base Stations (BSs). This has stimulated the development of routing protocols in
[2] for unicast best-effort and real-time traffic. We discuss the original proposal and
move on to the modifications suggested in [2].
[1] suggests that the transmission power of the mobile hosts and the BS over the
data channel be reduced to a fraction k1 of the cell radius. This means that more
than one node (in fact up to a maximum of k 2 ) can transmit simultaneously on the
same channel. Henceforth we refer to the parameter k as the reuse factor i.e., it
describes the maximum extent to which bandwidth in the system can be reused. The
node density is fairly high in typical cellular networks, which guarantees that the
chances of a network partition within the cell are quite small. The analysis in [1]
proves that the average hop count for a path between the source and the destination
increases linearly with k and that the number of channels increases as k 2 . Hence the
throughput is expected to increase linearly with k. This analysis however assumes
that the straight line path between the source and destination will be available, and
moreover that the routing protocol is capable of discovering it. Hence, the actual
gain will be probably lower because of the overhead of the routing protocol and the
possibility of absence of relaying nodes along the straight line path.
A unicast routing protocol, a real-time protocol and extensions to the above archi-
tecture were suggested in [2]. Both the protocols assume an approximate knowledge
of the network topology by the BS. This is achieved by deploying a contention-free
beacon protocol whereby MHs discover their neighbors. All MHs in a cell take part
in the topology discovery wherein each MH regularly sends to the BS, information
about the beacon power received from its neighbors. This information is used by the
BS to estimate distances between MHs.
Here we give a brief introduction to the MCN unicast routing protocol for best-
effort connections before moving on the the real-time counterpart. For best-effort
communication all the cells share a single data channel and a single control channel
(unlike in [1] where the bandwidth is divided over clusters as in voice networks).
While the transmission range on the data channel is kept at half of the cell radius,
that on the control channel is equal to the cell radius. The value of k = 2 in [1]
was arrived at as a compromise between increasing the spatial reuse and keeping the
number of wireless hops to a minimum.
The unicast routing protocol (illustrated by Figure 2.1) operates exclusively over
6
R/k
R= Cell radius BS
RReq RRep
D
A C B
Path from Node A to B is A−C−D−B

Figure 2.1: MCN best-effort architecture
the control channel. An on-demand approach is used in routing best-effort traffic

through the system. The routing protocol has a route discovery phase and a route
maintenance phase. When a source A has a packet to send to a destination B to
which a path is not known, it sends a Route Request (RReq) to the BS over the control
channel. The BS responds with a Route Reply (RRep) containing the route, which is
sent back to A over the control channel. This route is computed by Dijkstra’s shortest
path search algorithm with an enhanced weight function. Intuitively, the weight of a
wireless hop should be indicative of the number of nodes affected by transmission over
that hop. Note that a node could be a BS or an MH. If a transmission is taking place
over hop(X, Y ) where X and Y are nodes in the system, let N (X) and N (Y ) represent
the sets of nodes within the transmission range of nodes X and Y respectively. The
following weight function taking into account nodes X and Y as well is used.
w(X, Y ) = | N (X) ∪ N (Y ) | + 2
The source A upon reception of the RRep, transmits the data packet with the entire
route information contained in it, to the next node on the path which forwards it.
This path is also cached in its local Route Cache (RC). Subsequent packets to the
same destination are source routed using the same path until the RC entry times out
or a route break is detected. When a node C detects a break in hop(C, D) on the
route from node A to B, C sends a packet similar to a RReq to the BS which sends a
new route from A to B, to A (used for subsequent packets headed for B) and a route
from C to B, to C (used to forward the packets that got buffered at C due to the
7
route break).
2.3 The MuPAC Architecture
MuPAC [4] is a multi-power scheme for packet data cellular networks. This scheme
was primarily proposed to overcome the limitations posed by the MCN architecture
and to enhance the throughput further. In the MCN architecture [2] the nodes use a
transmission range of r which is 1/k fraction of the cell radius. The parameter k is
called the reuse factor.
The n-channel MuPAC uses (n+1) channels with different transmission ranges.
The available bandwidth is divided among n data channels and a control channel,
thus denoted as (n,r1 ,b1 ,...,rn ,bn ), where ri is the transmission range of the ith data
channel and bi is the bandwidth of the ith data channel. The transmission range of
the control channel is R, the cell radius.
The idea behind the use of multiple channels is to control the number of hops in
transmission and to lower the transmission power thus providing a greater reuse and
hence a better throughput. The use of higher power data channel serves the following
purpose.
1. Partitioning in the network is avoided by using higher transmission power and

thus making secluded nodes reachable.
2. In case of a route established using multiple hops, higher channels serve as
backups to avoid link breaks. This means, if the node on the next hop which
was reachable using the ith data channel is no longer reachable using the same
then, MuPAC upgrades the transmission to the (i+1)th data channel.
3. They may be used to reduce the number of hops in a multihop transmission.
2.3.1 Routing Protocol in MuPAC
The routing protocol of MuPAC is very similar to that of MCN. As in MCN the nodes
transmit Hello beacons using the transmission power of rn and the nodes hearing this
record their neighbors and the received power from the neighbors. This information
is conveyed to the base using the control channel which helps the base to maintain
the connectivity graph of the network. The connectivity graph is necessary to answer
route requests sent over the control channel by nodes to the base. Since MuPAC is a
multi-power scheme unlike MCN which uses a fixed transmission power to transmit
data over the next hop, MuPAC chooses the transmission power as follows: For a
given route the data is transmitted to the next hop using the data channel given by
ri > α ∗ dapprox ; where α > 1 is the safety factor and dapprox is the distance estimated
using the received power of the Hello beacons. If the next hop is not reachable over
the nth data channel (the highest power data channel) then a Route Error message is
sent to the base. The packet transmission in a 2-channel MuPAC is shown in Figure
2.2.
8
Channel 2
R/2
R/3
Channel 1
Figure 2.2: Packet transmission in a 2-channel MuPAC
MuPAC-2 refers to specific case of the MuPAC architecture in which the number
of data channels is 2, and similarly MuPAC-3 has three data channels. From the
simulation studies in [4] the MuPAC-2, the optimal performance is obtained when
r1 is R/3 and r2 is R/2 with b1 = b2 = 2.5Mbps when the bandwidth for control
channel is 1Mbps. MuPAC-3 uses r1 = 170m, r2 = 220m and r3 = 250m for a cell
radius (R) of 500m. b1 = 0.75Mbps, b2 = 1.25Mbps and b3 = 3Mbps.
2.4 Real-time Architectures
The extensions suggested in [2] include a protocol for real-time support over the MCN
architecture. Unlike the protocol for best-effort traffic, here the entire bandwidth
available is split into one control channel and several data channels. These data
channels are not clustered between the cells and hence can be used throughout the
system area. Similar to the protocol for best-effort traffic, the transmission range on
the data channels is kept at half of the cell radius, and that on the control channel
is equal to the cell radius. The value of 2 for the parameter k is chosen for the same
reason as in the best-effort routing protocol. The call establishment process is shown
in Figure 2.3(a). To establish a call an MH sends a packet similar to the RReq to
the BS over the control channel. The BS computes a route from the MH to itself
using the same method as in best-effort path setup. Using the channel allocation
scheme described below, the BS also chooses the data channels to be used along each
wireless hop in this route. The BS then broadcasts this information (the path and
the channels to be used in every hop) over the control channel. On reception of this
information, the sender, the intermediate nodes and the destination become aware of
the call setup so that they may do the needful. If the call cannot be established, the
9
BTS(B) BTS(B) BTS(B)
RErr
D RErr
D C D
C
RReq
C
A A A
(a) (b) (c)

Broadcast message containing path and channel information
Control packets like call setup request and reroute request
Full duplex wireless hop
Interference
Figure 2.3: MCN real-time architecture (a) Call setup (b) Path break (c) Interference
sender is appropriately informed by a unicast packet over the control channel.
U V
Figure 2.4: Nodes affected by transmission in hop(A, B)
A channel ch that is already in use in hop(A, B) can be reused in hop(C, D) if the

following constraints are satisfied. Note that these two hops can belong to different
connections.
r ≥ d(C, D) (2.1)
r ≤ min(d(A, C), d(A, D), d(B, C), d(B, D)) (2.2)
10
where d(A, B) gives the Euclidean distance (estimated approximately at the BS)
between nodes A and B, and r is the transmission range. The second constraint
essentially implies that no hop with either end in the dotted area in Figure 2.4 can
reuse the channel used in hop(A, B). The channels for each hop in the wireless path
obtained are allocated through a first-available-channel allocation policy. For each
hop the channels are checked in a predetermined order and the first channel that
satisfies the above constraints is used.
At some point in the duration of the call the wireless path may become unusable.
This may happen because one of the above two constraints was violated at some
wireless hop in the path. An MH can detect a violation of the first constraint from
the power of the hello beacons that are sent by its neighbors. An MH can detect
a violation of the second constraint when interference is detected on the channel.
Under such circumstances a new route is built from scratch. The call reroute process
is shown in Figures 2.3(b) and 2.3(c). The MH that detects the violation sends a
packet very similar to the RReq packet to the BS, which computes a new route and
broadcasts the information to all MHs in the cell. In order to reduce the chance of
r
call dropping, some channels are reserved for rerouting calls, i.e., of Nch channels, Nch
r
are reserved for handling handoff requests. The more the value of Nch the lesser is
the probability of dropping during hand-offs.
2.4.1 TWiLL
In this section we describe a wireless multihop architecture based on MCN for local
loops called Throughput enhanced Wireless in Local Loop (TWiLL). The bandwidth
available is split into one control channel and several data channels which are not
clustered between cells. One way to solve the problem of network partitions in a
multihop system is to allocate a channel ch in single-hop mode, whenever the MH
requesting call setup finds itself in partition i.e., there does not exist a multihop path
to the BS. Following the above philosophy in TWiLL, every channel will be designated
as a multihop channel (MC) or a single-hop channel (SC). An MH transmits in the
control channel and SCs with a range of R (cell radius) and in the MCs with a range
of r = R/2 thus keeping the reuse factor k = 2 among the MCs. The introduction of
some single-hop channels into a multihop environment is done to keep the network
m
connected in case a partition occurs. Let the number of MCs be Nch and the number
s
of SCs be Nch . The call establishment process is similar to that in MCN. To establish
a call an MH sends a Route Request (RReq) to the BS over the control channel.
The BS computes a multihop path and allocates MCs along the path from the MH
to itself using the same method as in MCN. If such a path cannot be obtained,
then the MH is given an SC to communicate directly with the BS. The allocation of
channels in single-hop mode will reduce the spatial reuse of bandwidth thus reducing
the network throughput, but will also increase the number of accepted calls when the
node density is lesser than required, thus increasing the network throughput. When
a call is requested to be setup, the probability that the calls’ destination is within
the same cell as the call’s source is defined as the locality of the system. Locality
11
does not affect the throughput of WLL since, irrespective of its value two channels
will be setup. However in TWiLL, locality can be used to improve the throughput
by a technique called Shortcut relaying.
2.4.2 RT-MuPAC
In this section, we discuss RT-MuPAC (Real-time Multi-Power Architecture for Cel-

lular Networks) for real-time communication in cellular networks in detail. When a
node makes a call (by sending a Call Request packet over the control channel to its
base), a path (possibly over multiple hops) is computed by the base. The base now
reserves channels over every hop on this path (marks these channels as reserved, to
be exact). The channel allocation and the address of the relaying nodes for this call
are now broadcast over the control channel, so that the intermediate nodes in the
path can receive packets over one channel and forward it to the next node in the path
over another channel. Multiple powers are used in RT-MuPAC as follows: over each
hop, the power used is a function of the distance between the nodes communicating
over that hop. Thus, each channel operates independently at its own power: the
power used by a node over a channel is purely a local decision made at the node.
The base only specifies the channel to be used over every hop in the path: the nodes
decide the power to be used over this channel based on the power of the Hello beacons
from the next hop. These Hello beacons are transmitted by all nodes periodically so
that each node knows its neighbors and can decide what transmission range to use
in a transmission with each neighbor. This architecture provides better performance
compared to SCN and offers advantages to the network operator (who can support a
greater number of users and earn greater revenue without additional infrastructure)
and the users (who can enjoy greater throughput).
12
CHAPTER 3
The Single Interface MCN Architecture
3.1 Introduction
Wireless networks are considered as the future of networking. Even though wireless
networks offer enormous advantages over the traditional wired networks in terms
of ease of installation, ease of use, cost of operation etc., they are often plagued
by problems such as congestion, limited bandwidth, high bit error rate, time varying
channel properties, and low throughput. Multihop cellular networks were suggested as
a viable alternative to normal cellular networks for throughput enhancement. These
networks incorporate characteristics of both traditional cellular networks and Ad hoc
wireless networks. The key difference between the two types of wireless networks
is with respect to the presence of Base Stations (BSs), which act as a centralized
coordinating authority. Most current proposals of MCNs, for example the proposals
in [2] and [4], and similar hybrid architectures like iCAR [11] assume the existence of
more than one interface on every wireless device in the network, and the existence of at
least one interface which has a transmission range equal to that of the cell radius. This
has an enormous impact on the performance of the network, the power consumption of
the battery-powered devices and the cost of operation of the devices. The requirement
of multiple wireless interfaces operating at different transmission ranges is undesirable
as supporting more interfaces will only lead to increase in the cost of such devices.
The use of an additional long range interface, with transmission range equal to the cell
radius, used exclusively for the frequent exchange of control information between the
base and the hosts will, over a long interval of time, lead to a tremendous consumption
of battery power. In this chapter we propose a routing protocol Single interface
MCN Routing Protocol (SMRP) and compare its performance with the Base driven
Multihop Bridging Protocol (BMBP) [3]. We propose both data routing as well as
control routing procedures, that aim to overcome the limitations of the single interface
architecture, namely the absence of a control channel, in as elegant a way as possible.
The rest of the chapter is organized as follows. In Section 3.2 we discuss the
Base Driven Multihop Bridging Protocol (BMBP). In Section 3.3 we identify the
key issues involved in routing for the SMCN architecture. Section 3.4 explains the
proposed routing protocol for the Single interface MCN (SMCN) architecture, Single
interface MCN Routing Protocol (SMRP). The simulation parameters and details are
presented in Section 3.6. Section 3.7 summarizes the chapter.
3.2 Base-driven Multihop Bridging Protocol (BMBP)
Lin and Hsu have also suggested a prototype implementation for Multihop Wireless
LANs (MWLANs) in [3]. The protocol BMBP (Base-driven Multihop Bridging Pro-
tocol) is implemented in both the Mobile Stations (MSs) and the Access Points (APs)
to enable multihop routing and roaming. The AP that computes the bridging table
for a particular MS is the Associated AP of the MS. When a new packet arrives and
the node has a routing entry for the destination then the packet is forwarded to the
next hop, else the packet will be sent to the Associated AP possibly through multiple
hops. The protocol works by building bridging tables at each node, either a MS or
an AP. In the bridge table the destination sequence number [13] is used to prevent
loops in routing. The MS additionally timestamps the entry to avoid stale entries.
For each destination in the bridge table the node records the next hop and the hop
count.
3.2.1 Messages used in BMBP
The protocol has four message types, Beacon, Hello, Bridge, and Care-Of. The APs
and MSs will periodically generate the Beacon and Hello messages respectively to let
the neighbors know of their presence. The Beacon is flooded to help the MS identify
their Associated AP s, these are forwarded by MSs which receive them. The Hello
messages are also broadcast messages that are relayed toward the AP through other
MSs that will append their information (the address and a sequence number). The
bridges are computed by the AP on receiving the Hello messages and are sent to the
respective MSs to update their bridging tables. Each node increments its sequence
number on transmitting either a Beacon or a Hello. The format and use of the
message types is as follows :
• Beacon : The Beacon message is originated by an AP that wishes to advertise
its presence to the MS around it. The MS which receives the Beacon will
forward the Beacon by rebroadcasting the packet with its own information.
• Hello : The Hello messages are periodically generated by the MSs toward
the Associated AP s. Each MS on receiving the Hello will append its own
information as it forwards the Hello, and also increments the Entry Count
field. The maximum hop count that the Hello message can be fixed to reduce
the vulnerability of wireless paths.
• Bridge : The Bridge message is originated by the AP, which on receiving a Hello
message can compute the partial bridging table for the nodes that were involved
in the propagation of that Hello message. Each Bridge message consists of one
or more entries corresponding to other nodes, where the information contained
comprises the destination address, the destination sequence, the next hop and
the hop count.
• Care-Of : The Care-Of Message is an information interchange over the wired
network that interconnects the APs. This contains a list of MSs that are
14
AP
MS
Care Of Message
Bridge Message
Beacon Mesage
Hello Message
Figure 3.1: Messages in BMBP
currently associated with the AP.
All the messages except the Bridge message are in broadcast mode. Figure 3.1 de-
scribes in brief the nature and direction of the different message types in BMBP.
3.2.2 Protocol Description
As part of the protocol, specific procedures must be executed at the MSs and the
APs to achieve multihop routing. Each MS keeps track of the set of APs from which
it has received a Beacon message in an array data. If the hop count specified by the
new Beacon is less than the hop count to the MSs current Associated AP then the
node alters the Associated AP entry to the new AP. In case the Beacon is from its
Associated AP and sequence number indicates a newer packet then it updates the hop
count in its data array to indicate the change. Each MS will consider a Hello message
for propagation only if the Associated AP field in the Hello message corresponds to its
Associated AP, otherwise the MS just ignores the Hello. The message is also dropped
if the hop count field of the Hello message has reached the threshold of maximum
number of wireless hops. At the AP when a Hello is received, it does a sanity check
if the Hello is indeed intended for it, and then proceeds to process the Hello message.
The path taken by the Hello message gives the AP a partial bridge table which it
computes and stores in local memory in the form of the structure BSTable. If the
hop count indicated by the newer Hello indicates a shorter path then it sends a
Bridge message to the MS in the Hello message. It is crucial that the processing of
15
MSs proceeds from those nearer to the AP, only then can the Bridge messages be
forwarded to the farther nodes. When a MS receives a Bridge message, it checks if
it is the intended destination of the message. If it is the destination it just replaces
its bridging table entries with those given in the message. Otherwise it looks up is
local bridge table to find the next hop to the destination, and forwards the Bridge if
an entry exists. The AP on receiving a Care-Of message just records the address of
the remote MS and its Associated AP. In this section we propose an efficient routing
mechanism for the single interface MCN architecture Single interface MCN Routing
Protocol (SMRP). SMRP provides mechanisms for routing of both control and data
packets, possibly through multiple hops.
3.3 Issues in Routing for the Single Interface MCN Architecture
The fundamental problem that we encounter when we consider single interface MCN
systems is the transfer of control information between the MSs and the BSs. The MCN
routing protocol proposed in [2] assumes that all control information can be reliably
sent in a single hop from or to the BS through the control interface. Also since the
control packets are sent on a separate interface the data packets can typically be sent
with a higher success rate. Even though the success rate in a single interface system
will be reduced, the reduction must be viewed as less significant when compared to
the added advantages of reduced power consumption, and lower cost of devices. In the
routing protocol suggested in [2] each MS can identify its BS as it receives a Beacon
transmitted with a power corresponding to the cell radius. However in this proposal
all nodes transmit data using a single transmission power corresponding to half the
cell radius. Using a lower range would typically result in the formation of a greater
number of partitions, a situation wherein a MS is isolated from other nodes in the
network. The solution to the problem of partition typically involves the use of the
control channel itself for data transmission, but in the single interface scenario this
mechanism fails. In fact in the multiple interface situation nodes can register even
when they are in a partition, the same does not hold for the single interface case. We
have addressed the issues of how to route the control packets efficiently and also how
an MS can find the BS that is nearest to it and register over multiple hops.
3.4 Single Interface MCN Routing Protocol (SMRP)
The main types of protocol messages are
• Registration Request (RegReq)

• Registration Acknowledgment (RegAck )
• Route Request (RouteReq)
• Route Reply (RouteRep)
• Neighbor Message/Beacon
16
• Neighbor Update (NeighUpdt)
Each node, both BSs and MSs will periodically generate the Neighbor or Beacon
messages. This message will contain the data regarding the set of BSs that the node
has a route to and also the hop count to that particular BS. For example, when the
BS generates the Beacon it will send as part of the message its own address and
the hop count to be 0. When a Beacon reaches a MS it has to process the message
and suitably find the BS nearest to it on the basis of the hop count metric. Each
node will keep track of the data such as the list of BSs that are accessible to it, the
hop count to that BS and the next hop to that BS. When the Beacon arrives, if the
Beacon has come from the MSs current next hop to its registered BS, it will simply
update the contents of its local data with the new data. Then the MS proceeds to
compute the new BS to register to by finding the BS with the smallest hop count.
It also keeps track of the current next hop to its nearest BS. In order to reduce the
vulnerability of the control path nodes will not register if the hop count exceeds a
particular threshold. The MS then sends a RegReq to the nearest BS computed,
by forwarding the request to its current next hop to that BS. Each MS has the
additional responsibility of forwarding such control packets also on behalf of other
nodes. Further, as the request is being propagated toward the BS each node will
append its address into the Path field of the request packet to facilitate routing of
the RegAck packets. When the RegReq has reached the intended BS, it will then
generate a RegAck to be sent to the MS that originated the request through the path
specified in the request packet. The acknowledgment proceeds in the reverse route
of the request, with the path being copied into the acknowledgment so that each MS
knows where to forward the acknowledgment. A MS is said to have completed the
registration when it receives the acknowledgment, only then can the MS participate
in routing and data transmission. Each MS will receive the Beacon from its neighbors
and will record the received power of the Beacon. If the difference between the newly
received power and the previously recorded power exceeds a particular threshold the
MS will have to send a NeighUpdt message to the BS informing it of the new power.
Each MS will periodically check to see if the update needs to be sent to the BS. Along
with the received power the MS also timestamps the recorded power with its local
system clock. If it does not receive another Beacon from the same neighbor within
a prescribed time interval then it decides that the neighbor has moved too far away
from it, and indicates this with some large negative value to the BS in the update.
During this periodic check that the MS performs, it also checks of any of the nodes
that it has recorded as a next hop to some BS have moved away from it, i.e., either
the received power is negligibly small or no Beacon has been received. In such a
case it has to update the local data to indicate the new status. The NeighUpdt is
forwarded to the BS in much the same way as the RegReq, in the sense that each
MS will forward the update through it next hop to the BS towards the BS. The BS
uses the neighbor information to determine the current network topology and uses
an Incidence Matrix to keep track of the received powers between neighboring nodes,
and this can be used as a distance estimate for the routing mechanism. In Figure 3.2
17
BS
MS
Route Request
Route Reply
Reg Request
Reg Ack
Neighbour Update
Figure 3.2: SMRP control routing
we observe the routing of control packets over multiple hops, as opposed to using a
high range control channel. Under a high mobility scenario the next hop information
that each MS maintains may become obsolete, but the situation will stabilize within
a time interval equal to the period of the Beacon message, as the MS will receive
the current information from its neighbors. Each MS does not have any routing
information locally available except the next hop to the registered BS to transmit
control information. Whenever a packet arrives from the higher layers the MS will
send a RouteReq to its BS requesting the BS to send the path to the destination.
The BSs are assumed to know the set of MSs that are registered to one another, this
information can be transmitted over the wired network that interconnects the BSs.
The RouteReq and RouteRep mechanism is identical to the registration mechanism.
Once the RouteRep arrives at the source MS, it will send the packet to the destination,
using the source routing mechanism. Due to the constraint that we are working in a
single interface environment it is possible to reduce the control overhead by assuming
that each MS maintain a route cache to avoid congesting the network with too many
RouteReqs. When the route cache times out, a new RouteReq is sent. The destination
can optimize to a certain extent by copying the route through which it received the
packet, to reduce the number of RouteReqs that it generates while sending a packet
to the same source. If at an intermediate node, it is discovered that the route has
become stale then a new RouteReq is generated, to perform the route reconfiguration.
The frequency of route updates is dependent on the degree of mobility, at low mobility
the number of route re-configurations will be minimal. The reconfiguration can be
performed either locally by the node that discovered the route error, in which case
18
the sender is unaware of the route change, or it can be performed on an end-to-end
basis with the RouteRep reaching the source of the data packet.
3.5 Comparison of Control Overhead
In this section we analyze briefly the relative control overheads of the two protocols
under consideration. The protocols are analyzed under similar circumstances, i.e.,
similar load, number of cells, number of nodes and under no mobility.
3.5.1 SMRP Control Overhead
We present the control overhead of SMRP without the use of the route cache. The
notations used are as follows :
T : The total network functioning time under consideration
τh : The time period of the generation of hello messages
N : The number of nodes in the system
d : The average node density per cell
x : The average number of neighbors of a node
C : The number of cells
The total number of Beacon packets that are generated is
T
Nhello = ×N (3.1)
τh
Let p denote the probability that a control packet fails to reach the intended destina-
tion in an attempt. Let n denote the average number of request attempts made by the
sender waiting for an acknowledgment. Let n1 represent the average number of times
the responding node receives the request from the sender. These acknowledgments
are sent only when a request has been successfully received. The probability of not
re attempting to send the control packet (for RegReq and RouteReq)
psucc = (1 − p)2 (3.2)
pf ailure = 1 − psucc (3.3)

The quantities n and n1 can be expressed in terms of the psucc and pf ailure and p as
follows:
1
n= (3.4)
psucc
n1 = p × n (3.5)
The control packets will be re-sent for the RouteReq, RegReq and the NeighUpdt
messages. The total number of registration sent is
Nregrq = n × (N − Npartition ) (3.6)
19
where Npartition denotes the number of nodes that are isolated and cannot register.
Nregack = n1 × (N − Npartition ) (3.7)
Let Lavg denote the average number of UDP packets generated per node. The total
number of RouteReqs sent to the respective BSs will be
Nroutereq = n × Lavg (3.8)
The total number of RouteReps sent to the nodes will be
Nrouterep = n1 × Lavg (3.9)
3.5.2 BMBP Control Overhead
The notations used are as follows:

T : The total network functioning time under consideration
τhello : The time period of the generation of Hello messages
τbeacon : The time period of the generation of Beacon messages
N : The number of nodes in the system
d : The average node density per cell
x : The average number of neighbors of a node
C : The number of cells
M axhops : The maximum number of hops to which a Hello message can propagate
k : The average number of hops of a MS to the BS
Havg : The average number of Hello messages that go through a MS he total number
of Beacons generated, those originated at the BS and those that are propagated by
the MSs is
T
Nbeacon = × d × C × xM axhops −k (3.10)
τbeacon
The total number of Hellos generated, those originated at the source MS and those
that are propagated by the other MSs is
T
Nhello = × xM axhops (3.11)
τhello
The total number of Bridge message generated is
d−1
C ×d× 2
Nbridge = (3.12)
k
3.6 Simulation Results
We have simulated the SMRP and BMBP protocols using GloMoSim [14]. We have
used the free space propagation model and no-capture model for the radio layer. We
have simulated the protocols for different values of node densities and also varying
20
traffic loads. The simulations also include various mobility values ranging from 0 m/s
to 10m/s using the random waypoint model. The comparison between the BMBP
protocol and the SMRP protocol has been performed assuming that SMRP does not
use the route cache. However we have seen that there is a significant improvement in
the performance of SMRP with the route cache option added.
3.6.1 Performance Comparison of SMRP and BMBP
The simulation parameters that were used in the following comparison study are
presented in Tables 3.1. In Figure 3.3, we compare the overall performance of the
Table 3.1: Simulation parameters used for SMRP

Parameter Name Value Used (SMRP) Value Used (BMBP)
Terrain X range 2010m 2010m
Terrain Y range 2610m 2610m
Number of cells 11 11
Cell Radius 500m 500m
Power range 250m 250m
Beacon period 1s 1s
Hello period – 1s
M axhops – 4
Simulation time 5minutes 5minutes
SMRP and the BMBP schemes. The SMRP scheme not only outperforms the BMBP
protocol at various node densities, it also shows greater scalability, in the sense that
the performance degradation at larger node densities is not as great as in BMBP.
The possible reason for this could be the broadcast nature of the control packets in
the BMBP protocol. As a result the network bandwidth available for data traffic
is negligible at high node densities. In contrast, the SMRP scheme tries to send
the control packets as much as possible in unicast mode and performs significantly
better. We have also compared the performance of the two protocols at three different
mobility values in addition to the no mobility scenario. These results are presented
in Figure 3.4, which compares performances at low mobility of 2m/s, and in Figure
3.7, which compares the performance against mobility with the network size of 100
MSs. Figures 3.5 and 3.6 show the performance of the two schemes at varying locality
values and at varying load values. The locality represents the percentage of traffic
that is intended for a destination within the same cell. In both cases the performance
improves at higher locality values, an expected trend since the length of the wireless
path is lesser and traffic directed towards the BS is lesser. The load values shown
represent the mean inter arrival time of UDP packets, with payload 1900 bytes, in
milliseconds. We have compared the performances at loads ranging from 2ms inter-
arrival time (reasonably high load) to 50ms inter-arrival load (low load). We expect
21
0.9 0.8
"smrp" "smrp"
0.8 "bmbp" "bmbp"
0.7
0.7
0.6
Packet delivery ratio

0.6
0.5
0.5
0.4
0.4
0.3
0.3
0.2
0.2
0.1 0.1
0 0
100 200 300 400 500 600 700 800 900 100 200 300 400 500 600 700
Number of Nodes Number of nodes
Figure 3.3: Performance Vs node Figure 3.4: Performance Vs density

density at no mobility with limited mobility 2 m/s
0.9 0.9
"smrp" "smrp"
0.8 "bmbp" "bmbp"
0.85
0.7
0.6 0.8
0.5
0.75
0.4
0.3 0.7
0.2
0.65
0.1
0 0.6
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 5 10 15 20 25 30 35 40 45 50
Locality Load (mean interarrival time in ms)
Figure 3.5: Performance Vs locality Figure 3.6: Performance Vs load at

at 100 nodes at no mobility 100 nodes at no mobility
22
0.8 0.96
"smrp" "smrp with route cache"
"bmbp" "smrp without route cache"
0.75 0.94
0.7 0.92

0.65 0.9
0.6 0.88
0.55 0.86
0.5 0.84
0.45 0.82
2 3 4 5 6 7 8 9 10 200 250 300 350 400 450 500
Maximum mobility(m/s) Number of nodes
Figure 3.7: Performance Vs mobility Figure 3.8: Effect of route cache

at 100 nodes with UDP mean inter on packet delivery ratio with UDP
arrival time 30ms mean inter arrival time 30ms
the performance to improve slightly with decreasing load, and the trend is observed
for both the schemes. We suggested that the use of a route cache could help in
improving the performance of the single interface scheme, by reducing the number of
RouteReqs and RouteReps that are generated. Figure 3.8 compares the performance
of the SMRP protocol with and without the use of the route cache at varying node
densities, at a moderate network load of 30ms inter arrival time. The performance
enhancement is significant when the network size is larger, this is evident from the
plot, the reason is simply the fact that with larger network sizes the volume of control
traffic increases considerably, the route cache serves the purpose better.
3.7 Summary
We identified key issues in Single interface MCNs and tried to address some of these;
such as routing of control packets, reducing the control overhead with the use of
a route cache etc. and presented a routing protocol for the Single interface MCN
architecture called SMRP. We have studied through extensive simulations the perfor-
mances of SMRP and BMBP, and found a significant performance enhancement in
the SMRP protocol.
23
CHAPTER 4
Pricing in Multihop Wireless Networks
4.1 Introduction
Multihop wireless relaying can be used in a wide variety of domains and applications.
Ad hoc wireless networks [15] were intended for military, tactical, and emergency
search and rescue applications, where the need for an instant, infrastructure-less,
and reliable communication network that could be deployed with very low cost and
low time-investment, was felt. Gradually the applications have extended to civilian
domains, for providing low cost network access to homes and mobile users. Wireless
Mesh networks present an interesting use of multihop relaying for wide area networks
with predominantly domestic users. A number of hybrid cellular architectures aimed
at throughput enhancement such as [11], [2], and [1] have also been proposed, where
the issue of pricing is of utmost importance to both the user and the service provider.
The rest of this chapter is organized as follows. In Section 4.2 we broadly outline
some of the important issues in pricing in a multihop wireless network environment.
We then move on to different deployment scenarios of multihop relaying in wireless
networks, and identify and analyze the issues and existing solutions for pricing in
each of them. In Section 4.3 we examine the need for pricing in defence and strate-
gic applications. In Section 4.4 we consider some of the implications of a pricing
framework in a realistic, commercial deployment domain for multihop relaying, viz.,
the Wireless WANs. In particular, we focus on Wireless Mesh Networks, one of the
emerging network models for providing high-speed, low cost wireless network access.
The concept of multihop relaying is crucial to Ad hoc wireless networks, and pricing
is used more as a means to stimulate cooperation and ensure self-organization. Some
existing pricing proposals for Ad hoc wireless networks are studied in Section 4.5.
The issues and solutions for pricing for data and voice traffic in Multihop Cellular
Networks (MCNs) are examined in Section 4.6. We also identify some of the open
problems in the domain of pricing in multihop communication in Section 7.3, and
summarize the proposals in Section 4.7.
4.2 Issues in Pricing for Multihop Wireless Networks
1. Reimbursement: Some suggestions for pricing in Multihop Wireless Net-

works such as [16], [5] have been directed towards the concept of reimburse-
ment, i.e., every intermediate node that forwards a packet or participates in
voice traffic on behalf of another node is reimbursed for the power that it has
expended. The extent of reimbursement is a significant factor that will de-
termine the willingness of the intermediate nodes to expend some power for
others.
2. Fairness: One of the major concerns of pricing in MCNs and Ad hoc wireless
networks is fairness, the idea that every node pays an equal amount per unit
traffic that it has generated. Fairness can be viewed in multiple dimensions,
such as on a per flow basis or a per byte basis. However, fairness considerations
on a per byte basis with respect to data traffic and per second for voice traffic
seem more reasonable, as they are usage-based pricing approaches. The issue
of reimbursement leading to a profit in incentive-based (when the extent of
reimbursement exceeds the resource expenditure) schemes is unavoidable in
multihop relaying, as there can exist nodes that forward more packets than
they originate, and hence the received payments exceeds the total expenditure.
3. Service Provider’s revenue: The service provider’s revenue assumes signif-
icance in infrastructured networks such as MCNs and wireless mesh networks,
where a service provider is responsible for providing network access and hence
the profit earned by the provider is a prerequisite for the network to function.
All the pricing schemes must ensure that the revenue earned by the service
provider is above a certain minimum amount, below which it is infeasible for
the provider to sustain the network. This is especially true when we consider
incentive based schemes where it may happen that the service provider’s income
is meager.
4. Aggregation of pricing information: In traditional cellular networks ac-
counting is usually done at the Base Stations (BSs), that have complete in-
formation regarding the usage patterns with respect to both voice and data
traffic. One issue that is to be addressed, especially in the multihop domain is
how the pricing information is aggregated. Clearly it may not be possible for
the BSs to be a part of all the traffic that is generated in the network due to
the use of multihop relaying paths that exclude the BSs, and as a result the
BSs may be unaware of the amount of traffic that has been sent. The pricing
information such as the total call time or total data sent, if aggregated at the
nodes themselves, presents another dimension to the pricing problem, that of
trust. It may happen that the person operating the device can tamper with
the information either to make a profit for himself or ensure a loss for others.
5. Secure transfer of accounting information: We should also consider feasi-
ble means of transmitting the pricing information securely to a trusted account-
ing station (typically the service provider), security over wireless networks is a
major issue and this may necessitate that we have a dedicated secure channel
between the accounting stations and the Mobile Stations (MSs) dedicated to
transmitting the pricing information.
6. Translation of resource expended into cost: The power expended by a
25
node in forwarding packets for other nodes, has to be suitably converted into
a monetary entity. This may have to take into account the battery power
consumed for transmitting a unit amount of data, the life of the battery, and
the extent to which it affects the node’s status to transmit its own data.
4.3 Pricing in Military and Tactical Applications
In deployment scenarios such as military applications, search and rescue operations,

and tactical applications, the kinds of mobile nodes involved are largely homoge-
neous, dedicated nodes whose sole motive is to play an active role in the communi-
cation. Such scenarios do not involve “greedy” nodes, and hence pricing as a means
of stimulation for participation is redundant, as the service availability is guaranteed.
However pricing frameworks can be used for power optimization in such networks.
This is applicable when there are different kinds of mobile hosts, those that have a
good battery backup (for example vehicle mounted mobile devices) and those that
have low battery backup (such as handheld devices). Pricing can play an important
role in routing the packets predominantly through nodes that have greater battery
supply, and pricing mechanisms can be used for certain degree of power/throughput
optimization as suggested in [17].
4.4 Pricing in Multihop Wireless WANs
In metropolitan areas providing low-cost, high bandwidth Internet access with very
low deployment cost and setup time, may become a reality with the emergence of
wide area wireless networks that have a dependable infrastructure with high avail-
ability. Wireless Mesh networks are an emerging network model, that is projected as
a cost-effective and easily deployable network access model for Wireless WANs. Typ-
ically the Mesh network consists of a set of wireless transceivers installed at various
locations, with some of these acting as Access Gateways to the wired network (Inter-
net). Another network model is to use the Mesh network for local communication for
domestic use, in a community of houses. In the former case, the gateway nodes can
perform the required authentication and accounting mechanism, to charge the users
for the network access. This can be typically like the charging mechanisms employed
by Internet Service Providers (ISPs), either on a time usage or a byte usage basis. In
the other case, when the network is intended for the use of a local community, the
presence of a central coordinator cannot be assumed, and many of the problems that
are faced in Ad hoc networks, discussed in the following section need to be addressed.
Since Mesh networks are intended for commercial deployment, the pricing should be
as realistic as possible, with the charging units having a realistic correspondence to
actual monetary units. Also the network operator’s revenue is to be guaranteed to
be above a minimum threshold, so that the maintenance of the network is feasible.
26
4.5 Pricing in Ad hoc Wireless Networks
The primary motive in pricing for Ad hoc wireless networks is to stimulate participa-
tion, i.e., to ensure that mobile nodes act as routers in forwarding data and control
messages on behalf of other MSs. Such a pricing framework should be non-centralized,
due to the absence of any perceivable supporting infrastructure. The Packet Purse
and Packet Trade models have been presented as part of the Terminodes project [18]
to enforce service availability in Ad hoc wireless networks. The models [19] introduce
the concept of a virtual currency, called nuggets, that is used to stimulate coopera-
tion. The models assume a tamper-proof security module, a public key infrastructure,
greediness of nodes, and absence of infrastructure. In the Packet Purse model the
source node of a packet loads the packet with a certain number of nuggets. At ev-
ery intermediate node, the packet is forwarded if there is a non-zero nugget count in
the Pricing header of the packet, else the packet is dropped. Each forwarding node
reduces the nugget count in the packet by one, and also increases its nugget count
by one. The Packet Trade model does not suffer from the problems of the packet
being dropped due to insufficient nugget count in the packet and the loss of nuggets
by the source, by introducing a buy-and-sell transfer model. Each intermediate node
at a distance k hops from the source will sell the packet to the next hop for exactly
k nuggets, i.e., the next hop reduces the nugget count by k and the current node
increases the nugget count by k. Thus it can be seen that each intermediate node will
get exactly one nugget for the service rendered by it. The authors of [20] propose a
simple counter-based mechanism at each node in the Ad hoc wireless network in order
to stimulate cooperation. The model is studied both analytically and with the use of
simulations. Each node maintains a credit counter that is indicative of the level of
service it can expect from the network. When a node wants to send a packet over n
hops to a destination, it can do so only if its credit counter exceeds n, and whenever
a node forwards a packet its credit counter is incremented by one unit. Each node is
modeled has having two incoming flows INf (the packets that arrive for forwarding)
and INo (the packets that the node has originated), and two outgoing flows OU T
(the sent packets) and DRP (those packets that are dropped). Both the outflows
can be considered as a combination of the forwarded (outf and drpf ) and originated
(outo and drpo ) packets. The node’s state is described by the state variables b and c.
The latter is nothing but the credit counter, and the former is essentially the number
of packets that can be sent by the node under the battery power constraint. The
model can be formulated as one with linear constraints, and the selfishness can be
represented as the maximization of outo . It can be shown that the optimal value of
outo is B+C
N +1
, where B and C denote the initial values of b and c, and N is the ex-
pected number of intermediate nodes to the destination. Further, the authors of [20]
provide a decision mechanism, that will decide which packets will be forwarded, and
which ones will be dropped. Four forwarding strategies are presented which depend
on the current value of f , the number of packets forwarded so far. The authors of [21]
present a credit-based system to provide forwarding incentive for “selfish” users that
does not require tamper-proof hardware as in [19]. The essential idea is to make the
27
nodes keep a receipt for every message received and have a Credit Clearance Service
(CCS) to which a node reports receipts of messages that it has received/forwarded.
The two key aspects are that the system does not assume tamper-proof hardware,
and hence selfish users can maximize their utilities, and an incentive aspect (a node
receives sufficient credit for forwarding). Even though the system prevents cheating
without the use of tamper-proof hardware, the assumptions of fast and reliable access
to the CCS, and the requirement of the nodes to report all receipts, are unrealistic,
and these may not be valid in a practical Ad hoc wireless network.
4.6 Pricing in Hybrid Cellular Architectures
In the traditional cellular network model, pricing is not a major issue as the base
station acting as a representative of the service provider has the complete information
on the traffic being generated within a cell. Furthermore every byte of data has to be
forwarded through the BS directly without involving other mobile hosts. The above
scenario is not applicable for MCNs where the routing is far more complex and involves
relaying by intermediate nodes. The situation becomes far more complex if we are
to consider mobility also. Mobility may lead to multiple route re-configurations, and
the BS may be unaware of the path through which the packet reached the destination
if local reconfiguration is performed.
4.6.1 A Micropayment Scheme for MCNs
Micropayments are useful for stimulating cooperation among rational players, and can
be used to ensure routing of data and voice packets. Traditional schemes for micro-
payment presuppose the knowledge of the number of parties to be paid and how much
needs to be paid. This assumption may not be valid in a mobile environment. The
scheme proposed in [22] has four major components.
1. A strategy for users to determine how packets should be routed. Each node has
a threshold reward level, that needs to be satisfied in order for it to forward,
and each source accords each originated packet a reward level proportional to
the packet’s importance.
2. A verification module at the BSs to check for valid payments.
3. An aggregation technique, that works on the principle of probabilistic selection
of payment tokens.
4. An auditing technique that allows for the detection of cheating on part of the
nodes. The audit technique uses the information gathered from the winning
tokens and packet transmission information from the bases, in order to detect
cheating or colluding among nodes.
The scheme advocates one token per packet rather than one per payee, allowing all
nodes that transmitted the packet successfully to claim a winning ticket. Winning
28
tickets are communicated to the nearby BSs that forward the packet along the back-
bone after confirming the validity of the payment tokens. An interesting strategy
used is that the intermediaries profit from not only their own winning tokens but also
from that of their immediate neighbors. This scheme has the following advantages:
• The encouragement for both transmitting the packet and reporting the infor-
mation to the authority is provided.
• The systems ensures that fewer tickets need to be deposited, as there are mul-
tiple rewards per deposited ticket.
• It allows for an efficient cheat-managing system.
The proposal essentially charges the sources per packet generated, while the for-
warders are paid per winning ticket, by a central accounting authority. The routing
model presented in [22] describes the idea of an asymmetric MCN, in which the up-
link (from the node to the BS) is over multiple hops, whereas the downlink is a direct
wireless link between the BS and the destination. [22] identifies some of the common
forms of cheating or colluding that could occur in a multihop relaying environment
and seeks to address the problems. Some of the cheating techniques identified include
1. Selective Acceptance: An intermediary receives packets with winning tickets,

but not those without winning tickets.
2. Dropping of packets, by intermediate nodes after receiving them, irrespective
of whether or not a winning claim is made.
3. Packet Sniffing: A node can claim to have forwarded a packet with a winning
ticket by merely snooping on the wireless channel.
4. Greedy collection of tickets.
5. Tampering with claims and reward levels.
For each of the described cheating strategies, [22] presents a detection mechanism
within the proposed framework, thus providing a way to nullify the presence of ma-
licious nodes.
4.6.2 Pricing for Voice Traffic
In traditional cellular networks, voice traffic predominates over data traffic, and it is
essential to study certain pricing issues for such traffic. In [5] the authors identified
the use of multihop relaying as a useful throughput enhancement alternative to tra-
ditional cellular networks. Since intermediate nodes are involved in call relaying, it is
imperative that some form of cost reimbursement be provided. Christo et. al. have
proposed in [5], pricing schemes for call relaying in a multihop relaying architecture
for enhancing throughput in Wireless in Local Loop system. The schemes vary with
respect to the bill-rate and the cost-reimbursement factor, which are either constant
29
or vary with respect to the distance from the BS of an MH. These pricing schemes
do make certain simplifying assumptions such as uniform load and no mobility, and
this makes it inapplicable for realistic deployment scenarios.
4.6.3 Pricing for Data Traffic
4.6.3.1 Notations Used
For the proposed pricing schemes the commonly used notations are described below.
• Tcost : The total cost per byte paid by the source of the data traffic to the
service provider that will subsequently be distributed among the intermediate
nodes that forwarded on its behalf and the service provider.
• α : This is the incentive factor, that has two interpretations depending on
whether the end-to-end scheme or hop-by-hop scheme is applied. In either case
it represents the reimbursement factor or the incentive factor for successful
transmission.
• Cp : This is a measure of the cost incurred by the intermediate node per byte
of data forwarded.
• Pi : This represents the cost incurred by a node i for forwarding the packets
on behalf of other nodes.
• Rr : This is the reimbursement factor that is provided to the intermediate nodes
for all the retransmit attempts made by it excluding the successful attempts.
• Fsij : This represents the total number of bytes that a node i has successfully
forwarded for some source node j, the notion of success being specific to the
scheme under consideration.
• Frij : This represents the total number of retransmitted bytes that a node i has
forwarded on behalf of some source node j. Since these are the unsuccessful
the reimbursement will be less.
• Tti : This is the total number of bytes generated by a node to various destina-
tions.
• Nr : This represents the network operator’s net revenue after having disbursed
to the nodes their respective reimbursement amounts.
• Irepayi : The total amount that a node i has received in the form of reimburse-
ments.
• Texpi : The total amount spent, both for traffic generation and for forwarding
by the node i.
• Tpaidi : The total amount paid by a node i to the service provider.
• N et Expenditurei : The net expenditure of a node i in the network. A pos-
itive value indicates that the node has made a net profit in the system while
30
a negative value indicates that the node has spent more than it has earned
through reimbursements.
The network operator can ensure that the revenue it has obtained does not fall below
the threshold by suitably altering the reimbursement factors, either the success factor
or the retransmit factor. Since there is no dependence of the parameters on the nodes
location, the schemes described above are truly mobility independent. We suggest a
few possible pricing schemes for the MCN architecture for packet based best effort
traffic, which consider different types of cost reimbursement schemes for intermediate
nodes. In each of the following pricing schemes the total amount that each source
node pays per byte of data generated is fixed. This amount will be paid to the
network operator or equivalently the BS, that will distribute the revenue among
the intermediate nodes depending on the reimbursement scheme, at the same time
ensuring that the service provider’s revenue does not fall below a minimum threshold,
below which it is infeasible for the network to be sustained. Since the amount paid
by each source per byte of data traffic generated is a constant, all of the schemes
under discussion are inherently fair. Since the schemes do not assume any apriori
knowledge of traffic patterns or rates, they are also load independent. The schemes
also take into account the mobility dimension as the collection of pricing information
is done in such a way so as to ensure that the base always gets an accurate picture
of the traffic in the network.
4.6.4 EESR (End-to-End Success Reimbursement Scheme)
In this scheme the intermediate nodes are reimbursed only when the packets that they
forwarded reach the destination successfully. Since only successful transmissions are
considered, the pricing information needs to be aggregated only at the destinations.
Destinations are not involved in the transactions of that particular traffic generation,
as the source is the spender and the intermediate nodes, except the BSs are reim-
bursed. Therefore we feel that the problem of nodes providing the service provider
with incorrect information, for unfair personal gains, is ruled out to a certain extent.
The information that is sent to the BS, in this will consist of a list of paths along with
the number of bytes transferred along that path within that pricing period. For ex-
ample in Figure 4.1 if node Y is a destination and has received m bytes through path
P1 (X-D-C-Y) and n bytes through path P2 (Z-A-B-C-Y) in a particular time interval
then the information sent to the BS will consist of the two paths and the transferred
bytes. In case the route reconfiguration is performed locally, then the destination
needs to send the sender addresses, the data path through which it received the data
and the number of bytes received along the path, because the BS would not have the
recent most path that the packet could have taken. If end-to-end route reconfigura-
tion is performed and the source retransmits the data, then the BS has the current
information on the path that the traffic between the source and the destination and
it obviates the need for the destination to send the paths along which it received the
data. The pricing information can be sent along with the periodic neighbor updates
31
P1
P2
Z
BS B
D C
X Y
Figure 4.1: EESR pricing information reporting
that the destination generates, and forwarded to the BS. In order to ensure secure
and reliable delivery of the pricing information we may need to employ a dedicated
pricing channel, or alternatively the destination may send the pricing information for
two or more pricing intervals cumulatively. Equation 4.1 shows the amount that a
node gets reimbursed for its participation in forwarding packets for other MSs. Fij
here represents the total number of bytes that have been successfully forwarded to
the destination.
numXnodes
Irepayi = Fsij × α × Cp (4.1)
j=1,j6=i
The power expenditure of a node includes the power spent on the successful attempts
and the unsuccessful attempts, in the end-to-end notion of success.
numXnodes numXnodes
Pi = Fsij × Cp + Frij × Cp (4.2)
j=1,j6=i j=1,j6=i
Each MS has to pay for its usage of network resources, i.e., the total amount paid
to the service provider is proportional to the traffic it has generated. This is given by :
Tpaidi = Tti × Tcost (4.3)

The following equation represents the total expenditure that a node has incurred,
which includes the cost paid to the service provider per byte and the power cost
incurred by the node.
Texpi = Pi + Tpaidi (4.4)
The service provider’s income is given by the difference between the total amount it
has received from the nodes and the total amount it has reimbursed to forwarding
nodes.
numXnodes numXnodes
Nr = Tpaidi − Irepayi (4.5)
i=1 i=1
32
The net expenditure of the node is given by the difference between the total amount
received through reimbursements and the total amount spent as follows:
N et Expenditurei = Irepayi − Texpi (4.6)
A negative value of the net expenditure indicates that the total amount spent by the
node, both paid to the service provider for the data it generated and the power cost
it had incurred in forwarding exceeds the amount it has received through reimburse-
ments.
4.6.5 ERSR (End-to-end and Retransmit Attempts Scheme of Reim-

bursement)
This scheme allows for reimbursement to intermediate nodes for the successful end-
to-end delivery and also provide a fractional reimbursement for the retransmission
attempts made by these nodes. The reimbursement for the retransmissions also pro-
vides an added incentive for the intermediate nodes to expend some power to forward
data for other nodes. The primary motive for incentive based pricing was to give
intermediate nodes some incentive for expending power on behalf of other nodes.
The total number of successful bytes forwarded is only an approximate estimate of
the power expended by the intermediate node, because the intermediate node also
expends energy for every retransmit attempt that it makes. Hence it becomes es-
sential to consider the retransmit attempts also as part of the reimbursement policy.
The aggregation of the pricing information proceeds in a similar fashion to the EESR
scheme suggested above. The destination of a particular data traffic will keep track
of the bytes and the paths along which it receives data. However in addition to this
information, we need the information on the number of attempts made by each inter-
mediate node. This can be easily accomplished if each intermediate node also adds
the information on the number of retransmit attempts it has made into the source
route field of the IP header. The destination will have to necessarily inform the BS
of the paths and the number of attempts in addition to the number of bytes received.
The transfer of information to the BS is similar to the EESR scheme. Equation 4.7
shows the amount that a node gets reimbursed for its participation in forwarding
from the service provider. The Fij represents the total number of bytes that have
been successfully forwarded to the destination. In addition to this factor the MS also
gets partially reimbursement for the retransmit attempts made by it for successful
transmission.
numXnodes
Irepayi = Fsij × α × Cp +
j=1,j6=i
numXnodes
Frij × Rrepay × Cp (4.7)
j=1,j6=i
numXnodes numXnodes
j=1,j6=i j=1,j6=i
33
Equation 4.10 represents the total expenditure that a node has incurred, which
includes the cost paid to the service provider per byte and the power cost incurred
by the node.
Texpi = Tpaidi + Pi (4.10)
numXnodes numXnodes
Nr = Texpi − Irepayi (4.11)
i=1 i=1

The net expenditure of the node is presented in Equation 4.12. It is possible that
a MS that does not generate any traffic itself, may get a net profit by forwarding
packets, if the reimbursement exceeds the power cost.
4.6.6 HHSR (Hop by Hop Successful Delivery Reimbursement)
Often it may be the case that a node has successfully forwarded a packet on behalf
of some source to the next hop on the route but that packet has not reached the
destination successfully. This scheme reimburses the intermediate nodes for all suc-
cessful link level transmissions. Again this modification to the end-to-end schemes
is keeping in mind the motivation behind the incentive based pricing schemes. If an
intermediate node has successfully forwarded a packet on behalf of a source to the
next hop supplied in the IP source route, then it has performed its duty, and it needs
to reimbursed for the service that it has provided to the source irrespective of whether
the packet actually reaches the destination. One significant difference between this
scheme and the end-to-end schemes is that the pricing information needs to be aggre-
gated necessarily at all the intermediate nodes. It is here that the dimension of trust
has to be considered. Since the intermediate nodes will be reimbursed by the BS for
the traffic that it has forwarded, there is a possibility that the intermediate nodes
may provide spurious information and claim to have forwarded a lot more traffic on
behalf of some source than what it has actually done. Each node will periodically
inform the BS of the amount of traffic it has forwarded within the pricing interval
and the sources of that traffic. This information can be sent along with the neigh-
bor update packets. In order to ensure that the service provider is not exploited by
malicious nodes the source may also be forced to furnish the necessary information
regarding the traffic patterns generated by it, so that the BS can confirm the veracity
of the information provided by the intermediate nodes. As suggested in the earlier
schemes, the pricing information can be sent on a single hop dedicated channel to
the BS, or through multiple hops piggybacked on the update packets. In the latter
case, it may be necessary to provide redundant information to offset the possibility of
some information being lost due to network congestion. This redundancy may be in
the form of pricing details being sent to the BS for not one interval, but the previous
two or three intervals. Equation 4.13 shows the amount that a node gets reimbursed
for its participation in forwarding by the BS. The Fij represents the total number of
34
bytes that have been successfully forwarded to the next hop towards the destination.
This notion of success is slightly more rewarding for the intermediate nodes than the
end-to-end success criterion.
numXnodes
Irepayi = Fsij × α × Cp (4.13)
j=1,j6=i
numXnodes numXnodes
j=1,j6=i j=1,j6=i

The total expenditure of a node includes the amount paid to the service provider for
the traffic generated and the total power cost incurred in acting as an intermediate
relaying node in other data traffic.

numXnodes numXnodes
i=1 i=1
4.6.7 HRSR (Hop by hop Successful Delivery and Retransmit Attempts

Scheme for Reimbursement)
The last of the schemes we suggest, incorporates the features of HHSR scheme and
the concept of partial reimbursement for the retransmit attempts made by the inter-
mediate nodes. In this scheme too the pricing information has to be aggregated at
all the nodes in the network, each keeping track of the number of bytes it has suc-
cessfully forwarded to the next hop, and the total number of attempts it has made,
for each source for which it functions as an intermediary. This is the most general
scheme that takes into account the entire traffic that a node forwards, but it has the
drawbacks suggested in the HHSR scheme, i.e., the nodes may, through unfair means,
manipulate the BS, reducing the network operator’s revenue. Equation 4.19 shows
the amount that a node gets reimbursed for its participation in forwarding by the BS.
The Fij represents the total number of bytes that have been successfully forwarded to
the next hop. In addition to this each intermediate node gets partial reimbursement
for the retransmit attempts in order to give better incentive for forwarding.
numXnodes
Irepayi = Fsij × α × Cp +
j=1,j6=i
numXnodes
Frij × Rrepay × Cp (4.19)
j=1,j6=i
35
COST PER BYTE OF DATA GENERATED
MIN REVENUE
End To End Success Reimbursement
Hop level success Reimbursement
Retransmission reimbursement
Network Operators revenue
SCN EESR ERSR HHSR HRSR
Figure 4.2: Schematic representation of the pricing schemes
numXnodes numXnodes
j=1,j6=i j=1,j6=i

numXnodes numXnodes
i=1 i=1
The net expenditure in this scheme is likely to be more positive than the other schemes
(with the other parameters kept constant).
Figure 4.2 shows a simplified view of the different pricing schemes, and an approxi-
mate estimate of the relative earnings between the nodes and the BS, in each scheme.
4.6.8 Simulation Results for Pricing Schemes
For all the results presented below the pricing parameters are as follows :
Cp = 1, α = 2.5, Tcost = 3, Rrepay = 0.3.
All the above parameters are relative fractions whose value is in terms of Cp units of
money. All expenditures and revenues expressed in the results are in the units of Cp .
36
-4e+06 -1.14e+07
"eesr" "eesr"
-5e+06 "ersr" "ersr"
Average net expenditure of the nodes
"hhsr" "hhsr"
"hrsr" -1.16e+07 "hrsr"
-6e+06
Net wxpwnditure of the nodes

-7e+06
-1.18e+07
-8e+06
-9e+06 -1.2e+07
-1e+07
-1.22e+07
-1.1e+07
-1.2e+07
-1.24e+07
-1.3e+07
-1.4e+07 -1.26e+07
1.5e+08 2e+08 2.5e+08 3e+08 3.5e+08 4e+08 4.5e+08 5e+08 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Load (total traffic in bytes ) Locality
Figure 4.3: Average net expenditure Figure 4.4: Average net expenditure
of nodes of nodes
4.6.8.1 Uniform traffic results
The average net expenditure of the nodes is shown in Figure 4.3, comparing the
various pricing schemes at varying load values with a network size of 100 nodes
having 11 cells. In this comparison the UDP traffic generated is uniform throughout
the network, i.e., each node generates almost identical traffic and no nodes are idle. In
accordance with the expected trend, with increasing offered load the net expenditure
becomes more negative, indicating that they total amount spent, i.e. the sum of the
amount paid to the service provider for traffic generation and the power cost incurred,
exceeds the total reimbursement by a larger margin at higher loads.
In Figure 4.4 the average net expenditure of the nodes is seen at varying locality
values, at UDP mean inter arrival time 20ms with the network traffic being uniform.
An interesting feature observed is that except the EESR scheme the others tend to
be almost similar in their behavior with respect to locality of traffic. The EESR
scheme provides the lowest possible amount of cost reimbursement and that explains
why the average net expenditure decreases with increasing locality. As more traffic is
concentrated within the cell the probability of end-to-end success is slightly reduced,
and as a consequence the EESR scheme shows lower net expenditure. We are also
interested in studying the effect of the pricing schemes in affecting the expenditure of
the nodes, depending on the nodes distance from the BS. This can be found in Figure
4.5, where the net expenditures of nodes has been averaged over a wide variety of
locality values.
4.6.8.2 Non uniform load results
We also consider the scenario when the network load is not uniform, i.e., there are a
few nodes that are not originating any UDP traffic, and solely perform their roles as
intermediate relaying nodes. These results can be seen for varying fractions of inactive
nodes in Figures 4.6 to 4.10. It can be seen from the results that as more number of
nodes are idle, i.e. they do not generate data traffic, the average net expenditure tends
37
-460000 0
"eesr" "eesr"
-480000 "ersr" -200000 "ersr"
Average net expenditure of the nodes
"hhsr" "hhsr"
"hrsr" "hrsr"
Net expenditure of the nodes

-500000 -400000
-520000 -600000
-540000 -800000
-560000 -1e+06
-580000 -1.2e+06
-600000 -1.4e+06
-620000 -1.6e+06
-640000 -1.8e+06
1 2 3 4 5 6 7 8 9 10 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Distance from the BS Locality
Figure 4.5: Variation in net expendi- Figure 4.6: Average net expenditure
ture of nodes with distance at UDP of nodes with UDP mean inter ar-
mean inter arrival time 20ms with rival time 20ms with 10% nodes gen-
150 nodes and 6 cells Distance from erating traffic
Base = ((x-1)*50 - x*50 ) metres
-800000 -1.68e+06
"eesr" "eesr"
-1e+06 "ersr" -1.7e+06 "ersr"
"hhsr" "hhsr"
-1.2e+06 "hrsr" -1.72e+06 "hrsr"
-1.4e+06 -1.74e+06
-1.6e+06 -1.76e+06
-1.8e+06 -1.78e+06
-2e+06 -1.8e+06
-2.2e+06 -1.82e+06
-2.4e+06 -1.84e+06
-2.6e+06 -1.86e+06
-2.8e+06 -1.88e+06
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Locality Locality
Figure 4.7: Average net expenditure Figure 4.8: Average net expenditure
of nodes with UDP mean inter ar- of nodes with UDP mean inter ar-
rival time 20ms with 30% nodes gen- rival time 20ms with 50% nodes gen-
erating traffic erating traffic
to increase. This trend is observed Figure 4.6 and Figure 4.7, i.e. as number of nodes
generating traffic increases from 10% to 30% the average net expenditure becomes
more negative. This is quite obvious from the fact that if a node does not generate
data traffic, it does not have to pay the service provider any amount. Rather the net
expenditure is decided solely by the amount of traffic generated and the amount of
traffic successfully forwarded, and the reimbursement factors.
4.6.8.3 Service provider’s revenue
Another key aspect of the pricing scheme is the service provider’s income which is
quite significant as it decides ultimately the feasibility of such a system. The service
38
-2e+06 -3e+06
"eesr" "eesr"
"ersr" "ersr"
"hhsr" "hhsr"
-2.5e+06 "hrsr" -3.5e+06 "hrsr"

-3e+06 -4e+06
-3.5e+06 -4.5e+06
-4e+06 -5e+06
-4.5e+06 -5.5e+06
-5e+06 -6e+06
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Locality Locality
Figure 4.9: Average net expenditure Figure 4.10: Average net expendi-
of nodes with UDP mean inter ar- ture of nodes with UDP mean inter
rival time 20ms with 70% nodes gen- arrival time 20ms with 90% nodes
erating traffic generating traffic
1.4e+09 1.175e+09
eesr "eesr"
1.3e+09 ersr "ersr"
hhsr "hhsr"
hrsr 1.17e+09 "hrsr"
1.2e+09
Service providers income
Service providers income
1.1e+09 1.165e+09
1e+09
1.16e+09
9e+08
8e+08 1.155e+09
7e+08
1.15e+09
6e+08
5e+08 1.145e+09
1.5e+08 2e+08 2.5e+08 3e+08 3.5e+08 4e+08 4.5e+08 5e+08 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Load (total traffic in bytes) Locality
Figure 4.11: Service providers in- Figure 4.12: Service providers in-
come Vs load come Vs locality
provider’s revenue is shown at varying load values in Figure 4.11 and at varying
locality values in Figure 4.12.
From the service provider’s point of view the decisions regarding the reimburse-
ment factors is extremely crucial, as these will ultimately influence the net income
of the service provider. In particular we are interested in the variation of the service
provider’s income with varying α, as this constitutes the single largest reimburse-
ment factor. The reimbursement for retransmit attempts will not be as crucial as this
factor, though they are significant from the MS’s point of view.
Figures 4.13-4.16 present the variation of the service providers revenue at various
offered loads and with varying α values. We expect the service provider’s income
to reduce with increasing α because the total reimbursement distributed to relaying
nodes will increase.
39
eesr ersr
Service providers income Service providers income
1.4e+09 1.4e+09
1.3e+09 1.3e+09
1.2e+09 1.2e+09
1.1e+09 1.1e+09
1e+09 1e+09
9e+08 9e+08
8e+08 8e+08
7e+08 7e+08
6e+08 6e+08
5e+08 5e+08
5e+08 5e+08
4.5e+08 4.5e+08
4e+08 4e+08
1 3.5e+08 1 3.5e+08
1.5 3e+08
Load- total bytes generated 1.5 3e+08
Load- total bytes generated
2 2.5e+08 2 2.5e+08
2.5 2e+08 2.5 2e+08
Alpha 3 Alpha 3
3.5 3.5
4 1.5e+08 4 1.5e+08
Figure 4.13: Effect of α on service Figure 4.14: Effect of α on service

providers revenue providers revenue
hhsr hrsr
Service providers income Service providers income
1.4e+09 1.4e+09
1.3e+09 1.3e+09
1.2e+09 1.2e+09
1.1e+09 1.1e+09
1e+09 1e+09
9e+08 9e+08
8e+08 8e+08
7e+08 7e+08
6e+08 6e+08
5e+08 5e+08
4e+08 4e+08
5e+08 5e+08
4.5e+08 4.5e+08
4e+08 4e+08
1 3.5e+08 1 3.5e+08
1.5 3e+08
Load- total bytes generated 1.5 3e+08
Load- total bytes generated
2 2.5e+08 2 2.5e+08
2.5 2e+08 2.5 2e+08
Alpha 3 Alpha 3
3.5 1.5e+08 3.5 1.5e+08
4 4
Figure 4.15: Effect of α on service Figure 4.16: Effect of α on service

providers revenue providers revenue
40
90 75
"ersr" "ersr"
"hrsr" 70 "hrsr"
80
Percentage of Nodes with a profit

65
70
60
60
55
50 50
45
40
40
30
35
20
30
10 25
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Locality Locality
Figure 4.17: Percentage of nodes Figure 4.18: Percentage of nodes

making a profit Vs locality at 10% making a profit Vs locality at 30%
nodes generating traffic in ERSR nodes generating traffic in ERSR
and HRSR schemes and HRSR schemes
50 35
"ersr" "ersr"
45 "hrsr" "hrsr"
30
40
35 25
30
20
25
20 15
15
10
10
5 5
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Locality Locality
Figure 4.19: Percentage of nodes Figure 4.20: Percentage of nodes

making a profit Vs locality at 50% making a profit Vs locality at 70%
nodes generating traffic in ERSR nodes generating traffic in ERSR
and HRSR schemes and HRSR schemes
4.6.8.4 Nodes making profits
It is quite possible that a MS that is not a source of traffic, may end up with a net
profit. It is more likely in situations with the traffic pattern showing great diversity
between the nodes. We present the fraction of nodes that end up with a net profit
at the end of the simulation, and compare this fraction against the locality in Figure
4.17 to Figure 4.20 at varying values of the fraction of inactive nodes in the system.
It is unlikely that a node makes a net profit under the EESR and HHSR schemes,
and in most cases the percentage of profit making nodes in these schemes under
non-uniform traffic patterns was found to be zero.
There also seems to be a general trend from Figures 4.17 to 4.20 that show that
the number of profit making nodes increases with the number of idle nodes, this too
41
is an expected trend for the reasons mentioned above.
4.7 Summary
We identified some of the important pricing issues in the diverse deployment scenar-
ios for multihop wireless networks. In military applications pricing does not assume
significance, as the nodes are homogeneous, and are guaranteed to provide the re-
quired service to their peers. Wireless WANs present some of the commercial and
practical problems in pricing for a realistic deployment scenario, in which the users
need to charged suitably for their network usage, and also get reimbursed when they
forward for others. In Ad hoc wireless networks pricing is used essentially to stimu-
late cooperation. The Packet Purse and Trade models ensure that the packet itself
carries the required nuggets or a virtual currency that provides reimbursement. Mi-
croeconomic and micropayment models have been suggested for enabling forwarding
and stimulating cooperation in a multihop environment. In hybrid cellular architec-
tures such as TWiLL and MCN, different pricing schemes have been proposed for
voice and data traffic. The schemes for voice traffic essentially use a combination
of position dependent and independent billing and reimbursement strategies as seen
from PICR, PICR-PDBR, and PDCR-PDBR. Incentive based pricing for data traffic
was also addressed, and varying forms of reimbursement are presented, that differ
in notion of success (end-to-end and hop-by-hop) and reimbursement for retrans-
mit attempts. The four basic forms of reimbursements for packet-based traffic in a
multihop relaying environment are EESR (reimbursement for end-to-end successful
delivery), ERSR (reimbursements for end-to-end successful delivery and retransmis-
sion attempts), HHSR (reimbursement for next hop successful delivery), and HRSR
(reimbursements for next hop successful delivery and retransmission attempts).
42
CHAPTER 5
A Framework for Interoperability of

Wi-Fi Hotspots and Wide Area Packet
Cellular Networks
5.1 Introduction
Wireless Fidelity (Wi-Fi) Systems refer to high speed wireless LANs that were origi-
nally intended to extend the wired Ethernet in offices to wireless clients. The coverage
area and ability to support high bit rates are the two major reasons behind the name
Wi-Fi. Though the popular wireless LAN standards IEEE 802.11b and 802.11a [23]
are considered as the standard wireless LAN protocols for deployment of Wi-Fi net-
works, any high speed wireless LAN protocol such as HiperLAN can be used. Wi-Fi
networks operate in the unlicensed 2.4 GHz and 5 GHz radio bands, with an 802.11b
or 802.11a or with products that contain both bands (dual band), so that they can
provide enriched network experience. Wi-Fi systems are potential candidates for
provisioning high speed multimedia content delivery at areas such as indoors offices,
airport lounges, and shopping malls. The advantages of Wi-Fi systems are ease-of-use,
ubiquitous high speed computing, and low setup/deployment cost. The integration
of Wi-Fi hotspots (wireless LANs) with wide area wireless networking technologies
such as GSM and GPRS provides added advantage for the mobile nodes. Such an
integrated system provides secure, reliable, and high speed wireless connectivity. A
Wi-Fi network can be used to connect computers to each other, to the Internet, and to
wired networks. The major issues for seamless roaming across Wi-Fi systems require
technological solutions for routing, authentication, billing, and QoS provisioning. In
this proposal we essentially consider the Wi-Fi system to be a realistic and efficient
implementation of a Multihop Cellular Network (MCN), which has the advantages of
enhanced throughput due to multihop relaying as well as the presence of a central-
ized coordinator to enable routing and QoS provisioning. The rest of the chapter is
organized as follows. In Section 5.2 we present some of the work that has been under-
taken in the areas of Wi-Fi systems. Section 5.3 gives a description of the proposed
system architecture. In Section 5.4 we analyze the key issues involved in the routing
mechanism and also describe the proposed routing protocol. We present the system
parameters and simulation results in Section 5.5. We outline the key issues involved
in pricing for such a framework and also give a primitive solution in Section 5.6. In
Section 5.7 we summarize the new interoperability framework that we have proposed.
5.2 Wi-Fi Service Models
Some of the important service provider models for Wi-Fi systems are as follows.
• The Wi-Fi Micro Carrier Model

In this model, small business operators can setup their own access points and
maintain customer relations and billing with subscribers. An example of this
category is a restaurant operating a small Wi-Fi system with a set of APs in
its premises.
• The Franchisor-Franchisee Model
This model for Wi-Fi systems is that a Franchisor company making an agree-
ment with a Franchisee ( e.g., a restaurant which has an inbuilt Wi-Fi system
for its internal purposes) for providing Wi-Fi connectivity on a revenue sharing
basis. The external communication, access network costs, and back office soft-
wares may be supplied and maintained by the Franchisor. Hence the Franchisor
company can extend its services to the public.
• The Wi-Fi Carrier Model
In this model, a particular company referred to as Wi-Fi Carrier can own,
deploy, and operate a number of Wi-Fi system enabled APs at public places.
The subscribers can utilize the designated carrier’s network services in their
coverage area based on acceptable billing models.
• The Aggregator Model
This model refers to an abstract service provider which strikes wholesale part-
nerships with Wi-Fi operators. Such Aggregators mainly focus on two major
things: (i) Reselling of the services provided by the Wi-Fi operators and (ii)
Giving its subscribers access to large number of networks. The advantages of
this model are easy scale up of network coverage as the Aggregator does not
own infrastructure and increased coverage area hence increases customer base.
• The Extended Service Provider Model
The synergy with existing cellular systems especially 3G systems can increase
profits for cellular operators. This can even lead to reduction in the deployment
cost of 3G systems. The widespread deployment of Wi-Fi systems can be
considered as complementing the 3G systems. Also the availability of wireless
devices equipped with Wi-Fi and Cellular interfaces encourages the possibility
of switching to the Wi-Fi systems whenever an AP is detected. Vertical handoff
can be used to switch back to the wide area cellular networks as and when
necessary in such cases. Thus Extended Service Provider model envisions the
provisioning of Wi-Fi services as an extension to the existing service provided
by the cellular network operators. Such a system requires placement of APs
at crowded traffic junctions, public places, railway stations etc. The presence
of multiple service providers trying to use this model would result in managed
utilization of spectrum in the bands assigned for 802.11.
44
SINGLE HOP ACCESS
GATEWAY
MULTIHOP PATH
MOBILE STATION (MS)
GSM BASE STATION (BS)
HOTSPOT ACCESS POINT (AP)
Figure 5.1: The proposed architecture
5.3 System Architecture
The system under consideration would essentially consist of a set of Wide Area Packet
Cellular Network (WAPCN) Base Stations (BSs) that can provide wide-area coverage
to the Mobile Stations (MSs), and a set of Wi-Fi Access Points (APs) that act as
Wi-Fi hotspots that provide high-speed connectivity to the MSs. Each MS is assumed
to support only one wireless interface, that can switch between the WAPCN and Wi-
Fi mode of operation. The Wi-Fi APs are assumed to be interconnected with one
another, and with the WAPCN BSs by means of either a wired backbone network, or
by high bandwidth point-to-point wireless links. The WAPCN BSs are connected by
means of a high-speed infrastructure network. Figure 5.1 shows a schematic repre-
sentation of the system under consideration. The Wi-Fi hotspots are assumed to be
randomly distributed throughout the metropolitan area. The WAPCN in our system
is equivalently represented by a Single hop Cellular Network (SCN), in which the MSs
are in communication with the BS on the control as well as data channels, with a
transmission range equal to that of the cell-radius. One important issue to be noted
is that in SCNs, the problem of network partitions does not arise. As considered in
[5] and [16], in MCNs partitions may arise when an MS does not have a multihop
path to the BS. The Wi-Fi hotspots are considered as a multihop relaying environ-
ment that is similar to an MCN. The Wi-Fi AP acts as the coordinator for enabling
routing and reserving bandwidth for nodes in the hotspot. The MCN architecture as
described in [2] assumes a control interface of transmission range equal to that of the
cell-radius, and a data channel with a transmission range equal to half the cell-radius.
45
In our system, the Wi-Fi AP has a transmission range of R/2, and the power range
for the data channel in the hotspot is R/4. As is evident each node has the option of
operating either under the control of the BS or under the control of the Wi-Fi AP.
We identify two distinct types of user behavior in the current system. A Type 1 MS
is one which always operates in the WAPCN mode, i.e., it will choose not to register
with the Wi-Fi AP, and enjoys the network service from the long range transmission
alone. Such an MS will typically be charged more for the service rendered, as the
resource (time, bandwidth) is more crucial in the wide area cellular network, than in
the Wi-Fi hotspot. The perceivable advantage that a Type 1 MS enjoys is the rela-
tively low handoff rate (under mobility), lesser probability of disconnection, and lower
interference. The other type of MSs, a Type 2 MS is one which does not have any
preference. The Type 2 user enters that mode of operation in which network access
is possible. For example, if the hotspot is heavily congested and it cannot support
an additional user the Type 2 MS has no alternative but to use the WAPCN mode
of operation. However, the Type 2 MS will use only the hotspot mode of operation
whenever it is available. In a sense the Type 2 MSs are network friendly, and can be
billed at a lesser rate than the Type 1 MSs.
5.4 Routing Mechanism
[2] provides an efficient packet routing mechanism for MCNs. The protocol works es-
sentially as an infrastructure-aided source routing mechanism [7], that uses topology
information available at the BSs. We now present a brief description of the protocol
in [2], and also describe some of the required modifications needed for the new archi-
tecture. Each BS periodically generates Beacon messages that can be received by all
nodes within a distance R from it. An MS chooses to register with a particular BS
depending on the received signal strength. It then sends the RegReq, to which the BS
replies with an RegAck. Once the registration is complete (i.e., after the MS receives
the RegAck ), the MS will originate Beacon messages, and it updates the BS on the set
of neighbors that are within its transmission range. The routing mechanism is largely
uncomplicated as the BSs together have the entire topology information, and can eas-
ily compute the shortest paths between any two MSs. Whenever there is a packet to
be sent to a destination at some MS, the MS originates a RouteReq to its BS. The BS
responds with a RouteReply with the shortest path, and the MS can send the packet
with the path using the source routing mechanism. One obvious way to reduce the
control overhead is the use of a route cache, with an appropriate timeout, which can
be used to store the route information either from the RouteReplys or from packets
that the MS forwards for other sources. There is also a recovery mechanism to adapt
to mobility, wherein an MS on the source route from the source to the destination on
realizing that its next hop is out of its transmission range sends a RouteError to the
source of the packet. The source MS has to acquire a new route for the destination
after receiving the RouteError, by sending another RouteReq. However, there are
certain important issues to be handled which necessitate changes to the registration
46
and routing mechanism described above, as we have to deal with Type 1 and Type 2
MSs differently. Both the WAPCN BSs and the Wi-Fi APs will periodically generate
Beacons with transmission ranges R and r, where R is the cell-radius of the cellular
network, and r = R/2 is the transmission range of the control channel of the Wi-Fi
hotspot (modeled as an MCN). The crucial difference between the Type 1 and Type
2 MSs arises from the registration mechanism. The BSs are placed in such a man-
ner that the entire terrain is covered, while the hotspots are distributed randomly as
discussed earlier in Section 5.3. A Type 1 MS will necessarily register only with its
nearest BS, whereas the Type 2 MS will register to the nearest available infrastruc-
ture node. Essentially the Type 2 MS will register with a Wi-Fi hotspot whenever
it is within the transmission range of the AP, even though it may be closer to a BS.
This is the essence of the trade-off that the Type 2 MS is willing to make for a less
expensive network access, at the cost of greater handoff and disconnection probability.
Only in extraordinary circumstances will the Type 2 MS register with the WAPCN,
when there is no hotspot accessible to it. Further there is the additional requirement
that the Type 2 MSs also perform the required authentication mechanisms with the
cellular network for purposes of billing.
The network usage that we consider is essentially one of a Gateway Access, typ-
ically one of the BSs acts as a gateway to the Internet or as a content server. This
means that each MS needs to only find a route to its nearest infrastructure node
(either a BS or an AP), which can then connect to the gateway by means of the back-
bone network. For Type 1 MSs the routing is simple, as the shortest path routing
mechanism would always yield the single-hop route to the BS as the shortest path.
For Type 2 MSs the routing mechanism proceeds in similar fashion to the MCN
routing protocol discussed above. However, the problem of network partitions can
arise, especially if the node density in and around the hotspot is low. This essentially
means that the Type 2 MS cannot find a multihop path over the data channel (of
transmission range r/2) to its MS. In such a case the AP generates a PartitionMsg,
to indicate to the MS that it is in a partition, and cannot utilize the network. On
receiving the PartitionMsg the Type 2 MS can employ a suitable decision mechanism.
We identify three important scenarios
• The Type 2 MS can idle for sometime and wait until it gets closer to the AP.
• The AP may be able to provide a single-hop access (possibly over the control
channel) to certain Type 2 MSs possible at an extra service charge.
• The Type 2 MS can de-register from the AP, and instead use the nearest BS
to access the network.
Since we modeled the Type 2 user as one who expects the service from the network
at all times, we believe that the last scenario is likely to be more realistic. In our
implementation, the Type 2 MS on receiving the PartitionMsg actually switches to
a Type 1 mode of operation in order to prevent future disconnections also. Figure
5.2 shows schematically the network access mechanism for the different scenarios
47
TYPE 1 MS
TYPE 2 MS
AP (HOTSPOT)
CONNECTION FOR TYPE 2 MS WITHOUT HOTSPOT

ACCESS
TYPE 1 CONNECTION
POINT TO POINT (WIRED/WIRELESS LINK)
TYPE 2 MS IN A PARTITION IN A HOTSPOT
TYPE 2 MS USING HOTSPOT ACCESS
Figure 5.2: Routing scenarios
discussed above. The mechanism discussed for the new architecture can be easily
extended to any form of network access. In the general case a source MS tries to find
a route to a destination MS. It is assumed that all the BSs have the complete topology
information and also the current location of each MS in the network (where the MS
is registered). The MS sends a RouteReq to its BS/AP, which then computes the
shortest path as follows. In case the destination MS belongs to the same cell as the
source the BS/AP employs the shortest path algorithm. Note that it is possible for
the path to bypass the BS/AP if the node density is sufficiently high. There are two
types of PartitionMsgs that are generated in the general case, one where the source
is in a partition, and the other when the destination is in a partition. In each case
the respective BS/AP will notify the Type 2 MS of the fact that it is in a partition so
that the MS can take a remedial measure. Since the Type 1 MSs are always reachable
from a BS in a single hop they can never be in a partition.
We have simulated the system using GloMoSim[14]. We have used the free space
propagation model and no-capture model for the radio layer. We have simulated the
protocols for different values of node densities and also varying traffic loads. The
simulation parameters that were used in the following study are presented in Table
5.1.
5.5.1 Number of Hotspots
We first present the variation of network throughput (Packet Delivery Ratio) with
the number of hotspots in Figures 5.3 and 5.4. Figure 5.3 shows the performance of
the system when there are 300 nodes in the system, where all the MSs are assumed
to be Type 2 MSs. Similarly Figure 5.4 shows the performance variation when there
48
Table 5.1: Simulation parameters
Parameter Value Parameter Value
Terrain X range 2010m Beacon period 1s
Terrain Y range 2610m Bandwidth WAPCN Control 1Mbps
Number of cells 11 Bandwidth WAPCN Data 5 Mbps
Cell Radius 500m Bandwidth Hotspot Control 1 Mbps
Transmission range 500m Bandwidth Hotspot Data 5 Mbps
for WAPCN
Transmission range 250m Transmission range 125m
for Hotspot (Control) for Hotspot (Data)
0.966 1
"Percentage of Type 1 nodes = 0" "Percentage of Type 1 nodes = 0"
"Percentage of Type 1 nodes = 10"
0.964 "Percentage of Type 1 nodes = 20"
0.99
0.962

0.98
0.96
0.958 0.97
0.956
0.96
0.954
0.95
0.952
0.95 0.94
15 16 17 18 19 20 21 22 23 14 16 18 20 22 24 26 28 30 32
Numebr of hotspots Number of hotspots
Figure 5.3: Performance Vs number Figure 5.4: Performance Vs number

of hotspots of hotspots
are 400 Type 2 MSs. It can be seen that as the number of hotspots increases, even
though the congestion at the BSs gets reduced the performance shows a degradation.
This is due to the fact that with a greater number of hotspots (placed randomly) the
possibility of interference at the radio layer becomes larger. We have assumed that all
the hotspots operate in the same transmission band, which may imply a lower packet
delivery ratio.
5.5.2 Privileged Users
The network throughput is likely to be affected by the relative number of Type 1

and Type 2 MSs. Since the Type 1 MSs are likely to consume a greater amount
of network resource, it is imperative to study the network throughput as a function
of the number of Type 1 MSs. Figure 5.5 shows the variation in the network with
increasing percentage of the Type 1 users.
49
0.966 0.99
"per_vs_percent.gph" "Percentage of Type1 nodes = 0"
0.9655 "Percentage of Type 1 nodes = 10"
0.985
0.965
0.98

0.9645
0.964 0.975
0.9635 0.97
0.963
0.965
0.9625
0.96
0.962
0.9615 0.955
0 5 10 15 20 25 30 35 40 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Percentage of Type1 MSs Fraction of Active Nodes
Figure 5.5: Performance Vs number Figure 5.6: Performance Vs offered

of Type 1 MSs load
5.5.3 Varying Offered Load
The traffic we simulated was mainly sending UDP traffic with a mean interval time of
20ms, and a packet payload of 1900 bytes. The network throughput is likely to vary
with the total offered load, which is considered in Figure 5.6. Here the total offered
load is represented in terms of the fraction of active senders in the network, i.e., not
all MSs (both Type 1 and Type 2) actively originate UDP packets as described earlier.
It is evident that as the number of active senders increases the total network load
increases and as a result the packet delivery ratio shows a decrease.
5.5.4 Varying Node Density
The architecture under consideration has the capacity to support a large number of
MSs within the same terrain and still attain a reasonable network throughput. In
fact our results in Figure 5.7 indicate that as the number of MSs is increased the
packet delivery ratio actually increases. The explanation of this is as follows. In all
the simulations, we assume that the MSs behave as only Type 2 MSs. Whenever
the Type 2 MS finds itself in a network partition, it switches to the WAPCN mode
of operation. As the node density increases in a cell, the possibility of network
partition definitely reduces, and fewer Type 2 MSs would be required to use the
WAPCN service. Since the throughput of the MCN is increased in this case, the
packet delivery ratio increases with increasing network size. However, the increase
cannot obviously occur beyond a point, wherein the radio interference and congestion
would bring down the throughput when the network size exceeds a certain threshold.
5.5.5 Mobility
The simulations also include various mobility values ranging from 0 m/s to 20m/s
using the random waypoint model. Figure 5.8 shows the variation of the packet deliv-
ery ratio with mobility. The x-axis mobility values represent the maximum mobility
50
0.97 0.96
"Percentage of Type 1 nodes = 0" "Percentage of Type 1 nodes = 0"
"Percentage of Type 1 nodes = 10"
0.965 0.94
0.96
0.92

0.955
0.9
0.95
0.88
0.945
0.86
0.94
0.935 0.84
0.93 0.82
100 150 200 250 300 350 400 0 2 4 6 8 10 12 14 16 18 20
Number of MSs Maximum mobility(m/s)
Figure 5.7: Performance Vs number Figure 5.8: Performance Vs mobility

of MSs
speed in the random waypoint model. As expected the delivery ratio decreases with
increasing mobility, as the frequency of handoffs and disconnections increase.
There are four distinct cases of handoffs that can occur in the given architecture.
The first case of a handoff when a Type 2 MS currently in the cellular mode of oper-
ation (due to non-availability of an AP), moves into the domain of a Wi-Fi hotspot,
and registers with the AP. This is referred to as an LS handoff (Long transmission
operation to Short transmission). The second type of handoff is a traditional cellular
BS-BS handoff (also referred as an LL handoff), where a Type 1 MS or a Type 2 MS
that has switched over to cellular operation mode (due to a network partition), moves
into the domain of another BS. The other two types of handoffs pertain only to Type
2 MSs. These are the SS type of handoff and the SL type of handoff. The SS type
of handoff is the least likely to occur among the four types, because the probability
of finding a new AP in a given neighborhood is quite low. The SL handoff has two
major contribution scenarios. One scenario of a SL handoff arises when a Type 2 MS
receives the PartitionMsg and has to switch over to the cellular mode of operation.
The other scenario arises due to normal mobility, where the received signal strength
of the AP at the Type 2 MS falls below the acceptable threshold, and the MS cannot
find a nearby hotspot.
It is highly likely that under high mobility a number of Type 2 MSs will shift to
a cellular mode of operation. As discussed earlier, a Type 2 MS will behave like a
Type 1 MS after it receives a PartitionMsg, as a result of which the Cellular BSs are
likely to experience more congestion. The relative fraction of the number of modes
in cellular mode is presented in Figure 5.10 at various mobility values. All MSs are
initially assumed to be of Type 2.
5.6 Pricing Issues
• Billing: Billing schemes for Wi-Fi systems assumes importance as the com-
mercial viability is a major factor for the existence of the Wi-Fi systems. The
51
700 0.8
0.75
600
0.7
Fraction of Nodes in WAN mode

Total Number of Handoffs
500 0.65
0.6
400
0.55
0.5
300
0.45
200 0.4
LL handoffs 0.35
100 LS handoffs
SL handoffs 0.3
SS handoffs "Percentage of Type 1 nodes = 0"
0 0.25
0 2 4 6 8 10 12 14 16 18 20 0 2 4 6 8 10 12 14 16 18 20
Maximum mobility(m/s) Maximum mobility(m/s)
Figure 5.9: Total number of handoffs Figure 5.10: Fraction of nodes in cel-
Vs mobility lular mode Vs mobility
possible billing schemes include the following. In the case of Wi-Fi, the entity
that has the responsibility of customer care and billing can be different from
the one which actually provide network access service. Henceforth we referred
to that as billing agency. The billing agency can employ different methods to
accept payments from the customers. The major billing approaches that can be
employed in the case of Wi-Fi systems are flat rate schemes and volume based
pricing. In flat rate schemes the user is permitted to utilize network services
for a specified amount of time without restricting the bandwidth. The volume
based approach charges the customer based on the amount of data transacted
over the network. In addition to both these schemes, business establishments
can provide Wi-Fi services as a value addition to the customers visiting the
premises for the core business activity. In such cases the billing is not con-
sidered as the bandwidth provided for belongs to the organization’s unutilized
bandwidth hence it can even be considered without additional charging.
• Revenue sharing model: In the Franchisee-Franchisor model and the Aggrega-
tor model, the sharing of revenue is important as there exist multiple business
entities in the process of customer relationship, billing, and providing service.
Different revenue sharing models that include a constant fraction sharing model
(in which the amount shared among the parties involved is prefixed) volume
based sharing model (in which the percentage of revenue that goes to different
parties involved varies with the volume of data transferred) can be employed.
Such systems can consider a constant rate for the user per bit of data trans-
ferred and in the high traffic density environments, variable rate per bit of
data transferred can be used. In the variable rate per bit of data transferred,
application level mechanisms which communicate the cost of communication
at any particular location is essential.
We present a volume-based pricing proposal for the system, and also discuss di-
rections for pricing in the various Wi-Fi service models. The two key aspects of the
pricing scheme are volume-based billing and reimbursement for link-level successful
52
delivery. Since the traffic we considered is one of Gateway Access, the network gate-
way can act as an efficient accounting station. Also due to the nature of the traffic
we observe that there is no need to aggregate any packet information at the MSs (in
terms of number of bytes forwarded for other nodes or data for every packet orig-
inated/forwarded). This obviates the need for tamper-proof hardware, mechanisms
for cheat-proofing, and secure transfer of accounting information. Since a source-
routing mechanism is used in the system, the network gateway on receiving a packet
has complete information on the intermediary nodes involved, which can be suitably
reimbursed. Note that we do not provide reimbursement for the retransmission at-
tempts made by an MS, as this would require special mechanisms like those mentioned
earlier.
Table 5.2 gives a brief description of the quantities involved in our pricing pro-
posal. Equation 5.1 represents the total reimbursement that an MS receives from the
Table 5.2: Notations used

Rcost Total cost per byte received
paid by an MS to the service provider.
Ocost Total cost per byte originated
by an MS to the service provider.
α Incentive factor, represents the reimbursement
factor for successful transmission.
Cp Cost incurred by the intermediate node
per byte of data forwarded.
Pi Total cost incurred by a node
i for forwarding.
Fsij Total number of bytes that a node i
has successfully forwarded for node j.
Frij Total number of retransmitted bytes that
a node i has forwarded on behalf of node j.
To i Total number of bytes originated by a node.
Tr i Total number of bytes originated by a node.
Nr Network operator’s net revenue.
Repayi Total amount that a node i has
received from reimbursements.
P aidi The total amount paid by a node i
to the service provider.
accounting station. The reimbursement comes into the picture only for the Type 2
MSs that are intermediary nodes for other MSs. For the Type 1 MSs and the Type
2 MSs that switch over to the cellular mode of operation, the reimbursement Repayi
53
will be zero, as these are not involved in forwarding any packets.
numXnodes
Repayi = Fsij × α × Cp (5.1)
j=1,j6=i
Equation 5.2 gives the total power expenditure that an MS incurs from forwarding.
We need not consider the power spent for sending the originated packets or the power
needed for sending the control packets as these need not be considered as an extra
expenditure.
numXnodes numXnodes
j=1,j6=i j=1,j6=i
Equation 5.3 shows the total amount that an MS has to pay the service provider.
We consider a usage (volume) based pricing mechanism wherein the service provider
charges the MSs for both requests as well as responses. Typically the gateway would
provide a connection to an external content provider (such as a WWW website or an
exclusive content site as in i-mode [24]). The service provider will distinguish between
the Type 1 and Type 2 MSs by a differentiated charging mechanism. This means that
Ocost and Rcost for a Type 1 MS will be greater than that for a Type 2 MS.
P aidi = Toi × Ocost + Tri × Rcost (5.3)
The service provider’s revenue is given in Equation 5.4. This is a significant

entity, as the service provider should be able to generate a minimum revenue in order
to sustain the network services.
numXnodes numXnodes
Nr = P aidi − Repayi (5.4)
i=1 i=1
It is interesting to note that in an Extended Service Provider model, the service

provider generates revenue from both types of MSs and the relative proportions of
these do not affect the service provider’s revenue. However in the other models,
especially the Micro Carrier and Franchisor-Franchisee models, the proportion of
Type 2 MSs in the system will crucially affect the revenue generation at the hotspot.
The above pricing proposal can be easily extended to the other Wi-Fi models, by
assuming a suitable distribution of the generated revenue between the cellular and
Wi-Fi operators.
5.7 Summary
The rapid emergence of Wi-Fi hotspots that are aimed at providing broadband wire-
less access to users in and around places of commercial interest presents the unique
problem of integrating the existing Cellular networks with these. The traditional
Cellular networks have in-built mechanisms for billing, authentication, and resource
allocation. However, the Wi-Fi hotspots provide the user with instant, inexpensive,
54
and faster connectivity, and the user may prefer to connect to a locally installed Access
Point instead of the WAPCN BS. We have presented an interoperability framework
between Wi-Fi hotspots, which we model as a Multihop Cellular Network (MCN), and
the traditional Cellular network. We studied the architecture under various network
conditions, and also identified some of the key issues such as differentiated service
and pricing.
55
CHAPTER 6
On the Use of Directional Antennas and

Multihop Relaying in Wireless in Local
Loop Systems
6.1 Introduction
With recent performance improvements in computer and wireless technologies, ad-

vanced mobile wireless communication is expected to encounter extensive use and
application in the near future. The phenomenal growth of the Internet and wire-
less connectivity has caused an explosive need for higher capacity wireless networks
which can efficiently handle a variety of network loads, service highly mobile users
with smooth hand-offs, offer connectivity through a variety of access points, manage
both best-effort and real-time connections concurrently with QoS support for delay
sensitive applications and above all be extendible from the existing infrastructure to
form the basis of the 4G cellular systems. While cellular systems are designed to
serve mobile users another arena in which wireless communication has made a mark
is in the local loop which is the last hop in the connection between a fixed subscriber
and the Public Switched Telephone Network (PSTN). A local loop where a radio
link is used is called a Wireless Local Loop (WLL [25]). Several WLL technologies
such as Digital Enhanced Cordless Telecommunication (DECT) [26], Personal Access
Communication System (PACS) [27], and Personal Handyphone System (PHS) [28]
have been developed whose architectures directly depend on the stationary nature of
subscribers.
In the recent past there has been a rather heavy proliferation of mobile sub-
scribers. While the subscriber density increases, the electromagnetic spectrum’s
capacity remains the same thus limiting the number of subscribers who can be si-
multaneously served. This is the single biggest stumbling block faced by wireless
network operators in expanding their network and improving their subscriber base
thus boosting profits. Just as in cellular systems, this problem stalks WLL systems
also. This would be detrimental to WLL in particular since WLL systems though
a cheaper alternative to the copper wired local loops, are expected to provide the
same level of service as the latter. We refer to the simultaneous connection of several
more subscribers as throughput enhancement. The electromagnetic spectrum being
limited, throughput enhancement is mainly achieved through a more efficient use of
the bandwidth available.
The basic ingredient in most recent throughput enhancement attempts has been
the introduction of Ad hoc network characteristics which enhance bandwidth reuse.
This is shown by the development of architectures such as Integrated Cellular and
Ad hoc Relaying system (iCAR) [11], Hybrid Wireless Network (HWN) [12] and Mul-
tihop Cellular Network (MCN) [1], [2]. In Chapter 2 we presented a brief overview of
the existing work in the areas of Multihop Cellular Networks (MCNs), the Through-
put enhanced Wireless in Local Loop (TWiLL) architecture. The use of directional
antennas presents an useful technique for energy efficient transmission and throughput
enhancement in Ad hoc wireless networks. Directional antennas also provide added
advantages such as reduced probability of detection (crucial to military applications),
lesser influence of hidden and exposed terminals, and lesser interference which leads
to increased network throughput.
The rest of the chapter is organized as follows. Section 6.2 considers the proposals
on the use of directional antennas in wireless networks. Section 6.3 presents the
proposed architecture called DWiLL, and the routing and call-setup mechanisms for
the DWiLL system. In Section 6.4, we present the simulation results for the DWiLL
architecture and also present the parameters that affect the network throughput. We
summarize the chapter in 6.5 and give a brief overview of the issues and solutions
presented.
6.2 Directional Antennas
There have been suggestions [29], [30], and [31] towards the use of directional antennas
in for packet radio networks. Nitin Vaidya et. al. identified in [32], the inadequacy
of the traditional WLAN MAC protocols to work efficiently with the use of direc-
tional antennas. The omnidirectional MAC protocols waste the network resources by
reserving over a larger region than what is necessary. The authors of [32] propose a
new approach, Directional MAC (D-MAC), for using the directional capabilities for
better bandwidth utilization. The two approaches suggested are the use of either di-
rectional RTS (DRTS) and using both directional and omnidirectional RTS (ORTS).
In essence, directional MAC schemes improve the network performance by allowing
more number of simultaneous transmissions, when compared to traditional RTS-CTS
exchanges. [33] is one of the few suggestions toward the use of directional antennas
as an energy conserving strategy for Ad hoc wireless networks. The authors of [33]
identify the energy savings that can be achieved with the use of directional antennas.
The authors propose a four-step algorithm for synchronization which not only en-
ables efficient communication, but also optimizes the total energy consumption and
the network lifetime. The authors of [33] assume that each node is equipped with a
single directional antenna which is electronically steerable and can be pointed to any
direction in the azimuth plane.
57
MS C
MS D
MS A MS F
MS B
MS E
MS G
Figure 6.1: The DWiLL architecture
6.3 The DWiLL Architecture
We propose in this section a new architecture for Wireless in Local Loop Systems –
DWiLL that uses the dual throughput enhancement strategies of multihop relaying
and the use of directional antennas, to not only reduce the energy expenditure at the
FSUs but also provide enhanced throughput when the number of subscribers becomes
large. Suppose the calls that need to be established are between MSs A and B, C
and F, and E and G. In Figure 6.1, we observe the different types of routing and call
setup scenarios for the uplink in the DWiLL architecture.
If shortcut relaying were employed in the architecture then the MS A would be
able to get a directional multihop route to B as it is adjacent to A. FSU C would
be able to reach the BS through FSU D, using directional relaying at both C and
D. The call setup from the destination BTS (to which F is registered) will use omni-
directional relaying at the BTS using a transmission power equal to r. In case of FSU
E, since no multihop path is available to the BTS it uses directional relaying with a
transmission range equal to the cell radius. In addition to the uplink from the MS to
the BTS or the destination (if shortcut relaying were used), we also need to setup the
downlink from the BTS to the FSU, and a similar connection setup also needs to be
done at the destination FSU. The BTS will choose the appropriate transmission mode
(multihop/ single-hop) to the FSU. We assume that the BTS uses omnidirectional
relaying, though in practice one can assume that the BTS too is equipped with
multiple directional antennas (this can reduce the interference significantly and hence
improve the throughput). For example in Figure 6.1 the downlink from the BTS to
the FSUs F and G, uses omnidirectional relaying with transmission range r and R
58
respectively.
6.3.1 System Parameters and Issues
The system architecture is similar to the proposal in [5], where the spectrum is divided
into a number of channels. These include a long-range control transmission channel,
and several data channels (multihop, single-hop, and reserved). The key difference
is the use of directional relaying by the FSUs. We assume that the directionality is
determined by the relative position of the FSU and the BTS. The directional antenna
at the FSU needs to be oriented in the direction of the BTS. Since there is not a
significant requirement for the directionality to be changed, there is no need for a
sophisticated electronically and dynamically steerable antenna. The FSU will use
the directional antenna to transmit control information, beacon signals, and the data
messages. In our architecture we consider the directionality only in the azimuth
plane, but the extension to directional relaying in both the azimuth and elevation
should not be very different. We also note that due to the directionality, the wireless
link level connectivity between two nodes is not symmetric. The system works by
building the topology information at the BTS as in [2]. Each node will report the
set of nodes from which it receives a Beacon, along with the received power to the
BS. In addition to this, we have also modeled the interference that could result from
the wireless transmission in two dimensions, radial and directional. We assume that
the Beacon will be received with a certain power high enough to cause interference at
nodes that are within the directional sector of radius r × (1 + β) and angle θ(1 + γ),
where r is the multihop transmission range ( equal to half the cell radius), and θ is the
azimuth of the directional antenna (the angular extent of transmission measured with
respect to the radial line from the BTS to the FSU), and β and γ are the interference
parameters (Typically any directional transmission builds up primary and secondary
lobes, which are modeled using a simple interference model here). The BTS builds
up two topology matrices, the R- Incidence Matrix and the r- Incidence Matrix, and
the R- Interference Matrix and the r- Interference Matrix.
The Interference Matrix will contain all the entries in the Incidence Matrix and
the fringe receivers as discussed earlier. For an omnidirectional antenna system the
Incidence Matrix is symmetric, but this is not the case in the DWiLL architecture.
6.3.2 Routing and Call Setup
Whenever a source node needs to setup a call session with an another node, it will
have to not only obtain the route to the destination, but also reserve the multihop or
single-hop channels at the various intermediate nodes (including the BTSs) involved
in the route. The route is obtained by a simple shortest path computation by the
BTS using an appropriate metric. For a simplistic system we have assumed the
hop-count metric for the path selection, but as suggested in [2] the enhanced edge
weight (where the edge weight represents the number of affected transmissions) or
similar metrics may also be used. Unlike the proposal in [5], we have used a realistic
59
call setup mechanism that will ensure that the resources are reserved for the uplink
and downlink for both the source as well as the destination. The actual call setup
procedure we have used is given in 6.3.3. Any given channel in the system can
operate in four distinct modes: multihop, multihop-directional, single-hop, and single-
hop-directional. The pure multihop (range= half the cell radius) and single-hop
(range=cell radius) transmission modes are used by the BTS to transmit the call. As
the single-hop and multihop channels are disjoint sets, the transmissions are mutually
non-interfering. The FSUs can operate in either with transmission range equal to the
cell-radius and directionality θ (single-hop-directional), or with transmission range
equal to half the cell radius and directionality θ (multihop-directional).
6.3.3 The Call Setup Procedure

PROCEDURE CALLSETUP (SOURCE, DEST)
begin
// uplink from FSU to BTS
tryCall(SOURCE FSU, SOURCE BTS)
if(Source Uplink call setup was successful)
begin
//downlink from BTS to FSU
tryCall (SOURCE BTS, SOURCE FSU)
if(Source Downlink call setup was successful)
begin
// Uplink from destination FSU to its BTS
tryCall (DEST FSU, DEST BTS)
if(Destination Uplink was succesful)
// Downlink from destination BTS to FSU
tryCall(DEST BTS, DEST FSU)
end
end
if(All calls were setup)
Start Call
else
//free up allocated channels when call fails
Hangup all sub-calls
end \\
PROCEDURE TRYCALL (SOURCE, DEST)

begin
FindPath ( SOURCE, DEST, Matrix = r-Incidence )
if (Path was found)
begin
Check if there exists a non interfering
multihop channel at each intermediary node
in the path.
//Use any appropriate channel allocation mechanism
60
If at any node, there is no free channel
then return failure.
end
else
begin
Check if there exists a non interfering
single-hop channel between the source and
the destination.
If no such channel is found return failure.
end
end
The FindPath procedure is simply the shortest path algorithm which uses the
appropriate Incidence Matrix. One of the apparent disadvantages of our call setup
mechanisms is that it does not try the single hop call setup when the multihop path
fails. However, in the DWiLL system with a small θ we have found that the number
of multihop paths that exist from an FSU to the corresponding BTS is quite low.
When the source and destination FSU belong to the same cell, then it is possible to
setup a call using a multihop directional path. This was studied in [5] and the authors
referred to this as shortcut relaying, and this gives a performance improvement when
the locality of the call is one. Again, as the probability of finding a directional path
from the source to the destination is quite low our system does not employ this
mechanism.
We have used GloMoSim [14] to simulate the WLL and DWiLL architectures. It
gives accurate models with precise timing for the radio layer and the IEEE 802.11
DCF (Distributed Coordination Function [23]). We present details of the simulation
below. We have used the free space propagation model and no-capture model for the
radio layer. For both these architectures, we allow 50s for the nodes to get registered
at a BTS We have used equal resources for both the wireless local loop systems under
comparison. In particular, both systems have bandwidth equivalent to 42 voice WLL
systems are essentially meant to serve stationary users. Hence we have simulated
WLL and TWiLL under no mobility as well where we use 42 data channels, and
these channels in the case of WLL get clustered into 14 data channels per BTS.
6.4.1 Number of Single-hop Channels
The throughput parameter for the WLL and DWiLL systems is the Call Accep-
tance Ratio, which denotes the probability that a call can be established between
the source and the destination. The Call Blocking Probability is equal to 1 −
CallAcceptanceRatio. Figure 6.2, shows the variation in call acceptance ratio with
varying number of Single-hop Channels (SCs). The number of channels that are re-
quired to operate in the single-hop is in fact a dynamic parameter that a BTS has to
61
Table 6.1: DWiLL parameters
Description Value Description Value
Simulation area 2km × 2.6km Inter-call time 30s
Cell radius 500m Cluster size 1
802.11 DIFS 50µs Data channels 42
802.11 SIFS 10µs Beacon interval 1s
Control channel 1Mbps Beacon time-out 2s
bandwidth Control channel IEEE 802.11 DCF
BTS number 11
decide by taking into consideration the factors such as node density, offered load, the
directionality of relaying, and locality of the calls.
0.86 0.845
"DWiLL Theta = 40" "DWiLL Number of SCs = 26"
0.84 0.84
0.82 0.835
Call Acceptance ratio
0.8 0.83
Number of SCs
0.78 0.825
0.76 0.82
0.74 0.815
0.72 0.81
0.7 0.805
0.68 0.8
0.66 0.795
10 15 20 25 30 35 40 20 30 40 50 60 70 80 90 100
Call Acceptance Ratio Theta
Figure 6.2: Call acceptance ratio Vs Figure 6.3: Call acceptance ratio Vs
number of SCs theta (SCs= 26)
6.4.2 Varying θ
The azimuth angle of relaying θ is a significant parameter in the DWiLL system, as

it affects the network connectivity, and hence the relative usage of the different types
of channels. For a given DWiLL system, we expect the θ to be a fixed parameter. In
Figure 6.3 we observe that initially as θ increases, the call acceptance ratio increases,
as the probability of obtaining a multihop path increases. Increasing θ further reduces
the spatial reuse gained by directional relaying thereby causing a fall in the acceptance
ratio.
62
6.4.3 Varying Offered Load
The load on the system can be varied by either increasing the number of calls made
in a given interval of time, or by keeping the inter-call time constant and increasing
the actual call time. In Figure 6.4, the performance of the DWiLL system ( θ =20,
SC = 14), is compared with the traditional WLL system with varying values of call
time. We see an expected trend, as the acceptance ratio decreases with the offered
system load.
0.75 0.68
"DWiLL" "DWiLL"
"WiLL/SCN" "WiLL/SCN"
0.7
0.66
0.65
Call Acceptance Ratio

0.64
0.6
0.62
0.55
0.6
0.5
0.58
0.45
0.4 0.56
8 10 12 14 16 18 20 0 0.2 0.4 0.6 0.8 1
Load Locality
Figure 6.4: Call acceptance ratio Vs Figure 6.5: Call acceptance ratio Vs
load locality
6.4.4 Varying Locality
As discussed earlier, the locality of traffic refers to the probability that the destination
of a particular call lies in the same cell as the source. In Figure 6.5, we compare the
performance of DWiLL with θ = 20 and SC = 14, with WLL at varying locality
values. The locality does not affect the call acceptance significantly when shortcut
relaying is not employed in DWiLL.
6.4.5 Interference Parameters
As discussed earlier, the BTS maintains both the incidence as well as interference
matrices. The interference matrix assumes importance, as in a realistic system the
call should not be subjected to wireless interference from nearby FSUs. We have used
a simple interference model, which assumes that an FSU in the sector determined by
R × (1 + β) and θ × (1 + γ), will be in the interference matrix corresponding to the
source FSU. Figure 6.6 presents the performance degradation with increase in β and
γ in the DWiLL system with θ = 20, and SC = 14.
63
0.9
"DWiLL"
"DWiLL Theta= 40 SCs =26" "WiLL/SCN"
0.8
0.7
Call Acceptance Ratio

0.76
0.74
0.72 0.6
0.7
0.68
0.66 0.5
0.64
0.62
0.3 0.4
0.25
0.2
0 0.15 0.3
0.05 0.1 Gamma
0.1
0.15 0.05
Beta 0.2
0.25
0.3 0 0.2
300 350 400 450 500
Number of MSs
Figure 6.6: Performance with in- Figure 6.7: Call acceptance ratio Vs
creasing interference range node density
6.4.6 Node Density Results
One of the key motivations for the DWiLL system is the increase in spatial reuse of
channels that provides better performance when the number of subscribers is very
large. Figure 6.7 shows that the performance degradation of the DWiLL system
with increasing number of subscribers is not as drastic as for the WLL system. This
can be explained in terms of the reuse of both single-hop and multihop channels
due to the directional relaying. Also with increased node density the usage of the
multihop channels also increases, causing lesser node on the limited number of single-
hop channels.
6.5 Summary
The use of Wireless in Local Loop (WiLL) has generated considerable interest due to
the advantages it offers such as ease and low cost of deployment and maintenance.
With an increase in the number of subscribers in the network, it becomes expedient
to employ spectrum reusability techniques such as the use of multihop relaying and
directional antennas, in order to improve the capacity and throughput of the WiLL
system. In this chapter we proposed a new system for the WiLL called DWiLL
that employs multihop relaying and the use of directional antennas for throughput
enhancement. We studied the performance of the DWiLL system through extensive
simulations and identified some of the key issues involved in realistic deployment of
such a system.
64
CHAPTER 7
Conclusions and Future Work
In this work we have studied three novel hybrid cellular architectures, the issues
involved in routing and connection establishment, and the issues involved in pricing
and cost-reimbursement. The SMCN architecture obviates the need for a separate
long-range control channel, and the control and data routing protocol SMRP was
found through simulations to perform better than BMBP, an existing proposal for
a similar architecture. We have identified four major forms of reimbursements that
are possible in MCNs, that have natural applications in the domain of hybrid cellular
networks. The EESR and ERSR schemes provide limited reimbursement, but are
more cheat-proof than the HHSR and HRSR schemes. We believe that reimbursing
the retransmission attempts needs to be incorporated in pricing schemes in order to
truly be able to enable forwarding in multihop wireless networks. We have proposed
an interoperability framework that supports the interoperability of Wi-Fi hotspots
and Cellular WANS. An interesting use of multihop relaying is the implementation of
a hotspot as a Multihop Wireless LAN. We have identified two distinct user profiles,
one that always operates in the WAN mode, and the other that operates in the
“available access” mode. The system shows reasonably high throughput and also
displays a high degree of scalability. We have studied the use of directional and
multihop relaying as throughput enhancement techniques in Wireless in Local Loop
systems. Such an architecture is not only realistic and economical, but also provides
greater spatial reuse when the node density is very high. The simulation results have
shown that the call acceptance ratio in the DWiLL system is higher than in the
traditional WiLL system.
We now present directions for future work in the architectures that we have
explored.
7.1 The SMCN Architecture
• Partitions: In MCNs there is an added disadvantage in which a node is iso-

lated from the rest of the network and therefore cannot participate in multihop
routing. This problem referred to as partition in a network assumes greater
proportions in the single interface system due to the non-existence of the con-
trol channel. Allocating separate high transmission ranges for those nodes in
isolations will not only affect the system performance adversely, but it will also
compromise the low cost goal of the single interface system. It is not very
clear as to how the problem of partitions can be solved efficiently in the single
interface MCN architecture, without compromising the goal of achieving low
power consumption devices.
• Real-time support: The absence of a control channel makes extension of the
single interface architecture to provide support for real-time traffic difficult.
We are currently exploring TDMA based schemes to provide real-time support
for the Single interface MCN architecture
7.2 A Framework for Integration of MCNs and Ad hoc Wireless Networks
Wireless networks are very popular due to their flexible nature, and the inherent
possibility for wireless nodes to be mobile. Currently most wireless networks are in-
frastructured networks, where all communications go through a base station that acts
as a gateway between the wired and wireless domains. In Ad hoc wireless networks
there are no fixed routers or base stations, but instead all nodes have the capability
to forward packets for each other. Ad hoc wireless networks have been the primary
motivation for studying hybrid cellular architectures that employ multihop relaying.
One of the major hassles in the commercial deployment of such networks is service
availability. It has been suggested that Ad hoc wireless networks that have certain
infrastructure capabilities (such as the presence of fixed access points) would be more
feasible and realistic. The distribution of the access points in the network is an inter-
esting aspect that affects the network throughput. One such proposal for routing in
infrastructured Ad hoc wireless networks is a modified version of AODV (Ad hoc On
Demand Distance Vector routing protocol), with a new cost (edge weight) function
that takes into account the power capabilities and mobility of the nodes in a route.
This allows paths that involve the fixed relay points (potentially having a larger power
source) to be preferred, but does not use the fixed nodes for route discovery. The
SMCN architecture is ideally suited for an infrastructured Ad hoc environment as
it does not assume any special channels for sending control information to the base
stations. In the proposed framework, that provides seamless integration of MCNs
and the Ad hoc wireless networks, we identify four different types of nodes, the Base
Stations (BSs are the fixed wireless access points), Near nodes (NNs that are at hop
distance < 4 from a BS), Far/Gateway nodes (FNs that are at a distance = 4 hops
from a BS), and Ad hoc nodes (ANs that are far away from the BS). The essential
idea is to use the infrastructure as much as possible in the routing and route discov-
ery processes, and to control the flooding of Route Request packets. We identified
different scenarios of packet generation ( AN-AN, AN-FN, NN-FN, NN-AN etc) and
came up with an efficient route discovery mechanism that uses unicasting within the
“cell” and the flooding mechanism in the ad hoc region.
66
7.3 Open Problems in Pricing for Multihop Wireless Networks
1. Pricing obviously needs some currency units and in any commercial system,
the pricing needs to be done in absolute real-world monetary units rather than
in a virtual nugget like currency. The translation of the pricing parameters into
absolute monetary units requires a deeper understanding of the issues involved.
2. Most pricing systems will need to dynamically decide on the pricing parameters
such as the reimbursement factors and the type of reimbursement, in order to
take into account the network size and the offered load.
3. Typically, there may be multiple service providers arranged in a hierarchy in
order to provide the Internet access. In such scenarios, the interoperability of
such hierarchical systems, through a pricing and/or an authentication mecha-
nism needs to be studied.
4. There have been a proliferation of Wi-Fi hotspots, in areas of commercial in-
terest such as cafes, restaurant chains etc. that aim to provide easy Internet
access to customers. Such hotspots use an Access Point to which users, hav-
ing a wireless devices can connect using IEEE 802.11b technology. Pricing in
hotspots and across hotspots, and pricing issues in the integration of GSM and
Multihop Wireless LAN (MWLAN) [3] technologies, need to be addressed.
5. Security is a key aspect of pricing, as both nodes and the network operator are
likely to suffer if there are malicious users in the network. This can be either in
the form of tamper proof hardware/software modules on the mobile devices, or
cryptographic/authentication systems that can function even under worst case
considerations. Security in Ad hoc and other multihop wireless networks, need
further exploration, as they are bound by the limited storage and processing
capabilities of the mobile devices.
6. Since most schemes involve cost-reimbursement, pricing becomes closely linked
with routing, as the determination of the forwarders and the distance to the
destination (hop-count) are necessary. The dependence between the pricing
framework and the routing protocol is another key issue that is unaddressed so
far.
7.4 Interoperability Issues in Hybrid Cellular Networks
The architecture was observed to be able to support quite a large number of MSs
without any drop in network throughput. We identified two distinct types of users
in the network, who expect different service levels from the network. However in
a realistic scenario most of the assumptions we have made about the user mode
of operation, may in fact be decisions that are left to the users themselves. Also
in the presence of multiple Wi-Fi service providers, the authentication and billing
models need significant revision. There needs to be service discovery mechanisms
that help the MSs identify the presence of nearby hotspots and also the level of
67
service they can expect from these. A random distribution of hotspots may not be
realistic, as in commercial areas the density of Wi-Fi hotspots would exceed those
in residential areas. Performance considerations under specific hotspot distributions
deserves requires a detailed study of the commercial distribution scenarios. The
pricing proposal we presented is largely simplified by assumptions about the network
traffic, which we assumed to be one of gateway Internet access. Pricing in the presence
of multiple service providers, and differentiated classes of service definitely merits
greater study, as these are likely scenarios in the future.
7.5 Directional Multihop Relaying in WiLL Systems
We have proposed the use of multihop relaying with directional antennas for WLL
systems. The architecture called DWiLL employs the techniques such as multihop
relaying and directional antennas to increase the spatial spectrum reuse, and hence
provide enhanced throughput. Simulation results have shown that the DWiLL system
not only performs better than the traditional WLL systems, but is also scalable. We
would like to suggest some directions for future research in this area.
• The channel allocation strategies we used are typically on a first-available free

channel basis. It would be practical to consider a wider range of allocation
strategies.
• The transmission range r and the transmission directionality θ may have to
be dynamic parameters, that vary depending on the traffic load and the node
density.
• We have modeled the fringe interference using a simple model using the param-
eters β and γ. In practice however realistic interference models for directional
relaying need to be incorporated.
• Our call-setup mechanism has a few options for improvements. These include
the use of shortcut relaying and the use of an alternative mode of operation
when no free channel is available (e.g., use of a single-hop channel when a
multi-hop path exists but channel allocation fails).
• The optimum number of channels that need to operate in single-hop mode is
a dynamic decision to be taken by the BTS by taking to account the various
factors such as node density, θ, locality, and offered load.
• We have modeled the channels as being linear and non-interfering. In practice
however the channels are split in frequency and time domains.
68
Bibliography
[1] Y. D. Lin and Y. C. Hsu, “Multihop Cellular: A New Architecture for Wireless
Communications,” in Proc. IEEE INFOCOM 2000, Tel-Aviv, Israel, March 2000.
[2] R Ananthapadmanabha, B. S. Manoj, and C. Siva Ram Murthy, “Multihop
Cellular Networks: The Architecture and Routing Protocols”, in Proc. IEEE
PIMRC 2001, San Diego, USA, October 2001.
[3] Y. D. Lin, Y. C. Hsu, K. W. Oyang, T. C. Tsai, and D. S. Yang, “Multihop
Wireless IEEE 802.11 LANs: A Prototype Implementation ” in Journal of Com-
munications and Networks, Vol. 2, No. 4, December 2000.
[4] K. Jayanth Kumar, B. S. Manoj, and C. Siva Ram Murthy “MuPAC: MultiPower
Architecture for Wireless Packet Data Network”, in Proc. IEEE PIMRC 2000,
September 2002.
[5] Christo Frank. D, B. S. Manoj, and C. Siva Ram Murthy “Throughput En-
hanced Wireless in Local Loop (TWiLL) –The Architecture, Protocols and Pric-
ing Schemes”. in Proc. of IEEE LCN 2002, November 2002.
[6] M. Frodigh, P. Johansson, and P. Larsson, “Wireless Ad Hoc Networking: The
Art of Networking without a Network,” in Ericsson Review, No. 4, 2000.
[7] D. B. Johnson and D. A. Maltz, “Dynamic Source Routing in Ad hoc Wireless
Networks”, in Mobile Computing, Edited by T. Imielinski and H. Korth, Kluwer,
pp. 153-181, 1996.
[8] C. E. Perkins and E. M. Royer, “Ad hoc On-Demand Distance Vector Routing,”
in Proc. 2nd IEEE Workshop on Mobile Computing Systems and Applications,
New Orleans, LA, pp. 90-100, February 1999.
[9] S. Murthy and J. J. Garcia-Luna-Aceves, “An Efficient Routing Protocol for
Wireless Networks,” in ACM Mobile Networks and Applications Journal, Special
Issue on Routing in Mobile Communication Networks, Vol. 1, No. 2, pp. 183-97,
October 1996.
[10] Y. B. Ko and N. H. Vaidya, “Location-Aided Routing (LAR) in Mobile Ad hoc
Networks,” in Proc. ACM/IEEE MOBICOM 1998, October 1998.
[11] H. Wu, C. Qiao, S. De, and O. Tonguz, “Integrated Cellular and Ad Hoc Relaying
Systems:iCAR,” in IEEE Journal on Selected Areas in Communications, Vol. 19,
No. 10, pp. 2105-2115, October 2001.
[12] H. Y. Hsieh and R. Sivakumar, “Performance Comparison of Cellular and Multi-
hop Wireless Networks: A Quantitative Study,” in Proc. ACM SIGMETRICS
2001, Cambridge, MA, USA, June 2001.
[13] C. E. Perkins and P. Bhagwat, “Highly Dynamic Destination-Sequenced
Distance-Vector Routing (DSDV) for Mobile Computers” in Proc. ACM SIG-
COMM 1994, September 1994.
[14] X. Zeng, R. Bagrodia, and M. Gerla, “GloMoSim: A Library for Parallel Sim-
ulation of Large-scale Wireless Networks,” in Proc. PADS-98, Banff, Canada,
May 1998.
[15] E. M. Royer and C. K. Toh, “A Review of Current Routing Protocols for Ad-Hoc
Mobile Wireless Networks.” in IEEE Personal Communications, Vol. 6, No. 2,
pp. 46-55, April 1999.
[16] Vyas Sekar, B. S. Manoj, and C. Siva Ram Murthy, “Routing for a Single In-
terface MCN Architecture and Pricing Schemes for Data Traffic in Multihop
Cellular Networks” to appear in Proc. of IEEE ICC 2003, May 2003.
[17] N. Feng, S. C. Mau, and N. B. Mandayam, “Joint Network-Centric and User-
Centric Pricing and Power Control in a Multi-Cell Wireless Data Network” in
Proc. CISS 2002, Princeton, NJ, March 2002.
[18] http://www.terminodes.org
[19] L. Buttyan and J. Hubaux. “Enforcing Service Availability in Mobile Ad-hoc
WANs.” in Proc. of MobiHOC 2000, Boston, MA, USA, August 2000.
[20] L. Buttyan, J. P. Hubaux, “Stimulating Cooperation in Self-Organizing Mobile
Ad Hoc Networks”, to appear in ACM Journal for Mobile Networks (MONET),
special issue on Mobile Ad Hoc Networks, Vol. 8 No. 5, October 2003.
[21] S. Zhong, J. Chen, and Y. R. Yang, “Sprite: A Simple, Cheat-Proof, Credit-
Based System for Mobile Ad-Hoc Networks.” in Proc. of IEEE INFOCOM 2003,
April 2003.
[22] M. Jakobsson, J. P. Hubaux, and L. Buttyan “A Micro-Payment Scheme Encour-
aging Collaboration in Multi-Hop Cellular Networks” in Proc. Financial Cryp-
tography 2003, January 2003.
[23] IEEE Standards Board, “Part 11: Wireless LAN medium access control (MAC)
and physical layer (PHY) specifications,” The Institute of Electrical and Elec-
tronics Engineers Inc., 1997.
[24] http://www.nttdocomo.co.jp/english/p s/imode/
[25] P. Stavroulakis (Editor), “Wireless Local Loops, Theory and Applications”, Wi-
ley, June 2001.
[26] H. Ochsner, “DECT Digital European Cordless Telecommunications”, in Proc.
IEEE Vehicular Technology 39th Conference, pp. 718-721, May 1989.
[27] D. C. Cox, W. Arnold, and P. T. Porter, “Universal Digital Portable Commu-
nications: A System Perspective”, in IEEE Journal on Selected Areas of Com-
munications, Vol. 5, No. 5, pp. 764–773, June 1987.
70
[28] K. Ogawa, et. al., “Toward the Personal Communication Era – The Radio Ac-
cess Concept from Japan”, in International Journal on Wireless Information
Networks, Vol. 1, No. 1, pp. 17-27, January 1994.
[29] C. Lau and C. Leung, “A Slotted ALOHA Packet Radio System with Multiple
Antennas and Receivers” IEEE Transactions on Vehicular Technology, Vol. 39,
No. 3, pp. 218–226, August 1990.
[30] N. Pronios, “Performance Considerations for Slotted Spread-spectrum Random
Access Networks with Directional Antennas”, in Proc. of IEEE GLOBECOM
1989, November 1989.
[31] T.-S. Yum and K.-W. Hung,“Design Algorithms for Multihop Packet Radio Net-
works with Multiple Directional Antennas stations” in IEEE Transactions on
Communications, Vol. 40, No. 11, pp. 1716-1724, November 1992.
[32] Y. B. Ko, V. Shankarkumar, and N. H. Vaidya, “Medium Access Control Pro-
tocols Using Directional Antennas in Ad Hoc Networks” in Proc. of IEEE IN-
FOCOM 2000, March 2000.
[33] A. Spyropoulos and C. S. Raghavendra, “Energy Efficient Communications in
Ad Hoc Networks Using Directional Antennas ” in Proc. of IEEE INFOCOM
2002, June 2002.
[34] Vyas Sekar, B. S. Manoj, and C. Siva Ram Murthy, “Hybrid Cellular Networks:
Architectures, Protocols, and Pricing”, Technical Report HPCN Lab, Depart-
ment of Computer Science and Engineering, IIT Madras, April 2003.
71

BTP

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BTP

Hochgeladen von

Copyright:

Verfügbare Formate

Hybrid Cellular Networks:

Architectures, Protocols, and Pricing

submitted in partial fulfillment of the requirements

under the guidance of

Prof. C. Siva Ram Murthy

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Place: Chennai [Prof. C. Siva Ram Murthy]

Place: Chennai [Vyas Sekar]

List of Figures viii

2 Multihop Relaying in Cellular Networks 5

3 The Single Interface MCN Architecture 13

4 Pricing in Multihop Wireless Networks 24

5 A Framework for Interoperability of Wi-Fi Hotspots and Wide Area

6 On the Use of Directional Antennas and Multihop Relaying in Wire-

7 Conclusions and Future Work 65

2.1 MCN best-effort architecture . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Messages in BMBP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 EESR pricing information reporting . . . . . . . . . . . . . . . . . . . 32

5.1 The proposed architecture . . . . . . . . . . . . . . . . . . . . . . . . 45

6.1 The DWiLL architecture . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.1 Simulation parameters used for SMRP . . . . . . . . . . . . . . . . . 21

5.1 Simulation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1 DWiLL parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

1.2 Related Work

1.3 Our Work

1.4 Organization of this Report

Multihop Relaying in Cellular Networks

2.2 The MCN Architecture

Path from Node A to B is A−C−D−B

the control channel. An on-demand approach is used in routing best-effort traffic

2.3 The MuPAC Architecture

1. Partitioning in the network is avoided by using higher transmission power and

2.3.1 Routing Protocol in MuPAC

Figure 2.2: Packet transmission in a 2-channel MuPAC

2.4 Real-time Architectures

(a) (b) (c)

sender is appropriately informed by a unicast packet over the control channel.

Figure 2.4: Nodes affected by transmission in hop(A, B)

A channel ch that is already in use in hop(A, B) can be reused in hop(C, D) if the

In this section, we discuss RT-MuPAC (Real-time Multi-Power Architecture for Cel-

The Single Interface MCN Architecture

3.2.1 Messages used in BMBP

Figure 3.1: Messages in BMBP

currently associated with the AP.

3.2.2 Protocol Description

3.3 Issues in Routing for the Single Interface MCN Architecture

3.4 Single Interface MCN Routing Protocol (SMRP)

The main types of protocol messages are

• Registration Request (RegReq)

Figure 3.2: SMRP control routing

3.5 Comparison of Control Overhead

3.5.1 SMRP Control Overhead

psucc = (1 − p)2 (3.2)

pf ailure = 1 − psucc (3.3)

Nregrq = n × (N − Npartition ) (3.6)

Nregack = n1 × (N − Npartition ) (3.7)

Nroutereq = n × Lavg (3.8)

The total number of RouteReps sent to the nodes will be

Nrouterep = n1 × Lavg (3.9)

3.5.2 BMBP Control Overhead

The notations used are as follows:

3.6 Simulation Results