ABSTRACT
TitleofThesis: INTELLIGENT NETWORK BASED WIRELESS
SERVICES FOR TELEMEDICINE
Degree candidate: Abhijeet S Bisain
Degree and year : Master of Science, 1998
Thesis directed by: Professor John S. Baras
DepartmentofSystemsEngineering
This thesis proposes an architecture for wireless services in telemedicine. The
scenario visualized is of an ambulance carrying a trauma patient and sending
medical data#28video, ultrasound, ECG#29 to its corresponding hospital. It needs to
knowinadvance the approximate bandwidth available to it after every hando#0B.
This thesis attempts to solve this problem with Intelligent Network signalling
which aids fast implementation of new services. It is assumed that the ambu-
lance uses a TDMA#28GSM#2FPACS#29 based phone with multiple slot connection
capability. New signalling procedures are suggested which attempt to provide
this service with minimum delay and load.
Some slot allocation schemes implemented at the base stations are designed
and evaluated. Bu#0Ber management schemes at the mobile to manage packets
from various data streams are proposed and compared. All queuing systems are
simulated in Opnet.
INTELLIGENT NETWORK BASED WIRELESS
SERVICES FOR TELEMEDICINE
by
Abhijeet S Bisain
Thesis submitted to the FacultyoftheGraduate School of the
University of Maryland, College Park in partial ful#0Cllment
of the requirements for the degree of
Master of Science
1998
Advisory Committee:
Professor John S. Baras, Chairman#2FAdvisor
Professor Scott Corson
Professor Carlos Berenstein
DEDICATION
To my parents and Ritu for their and love and support.
ii
ACKNOWLEDGMENTS
I wish to express my thanks to some of the many individuals who made this
work possible. Foremost among these is my advisor, Professor John Baras, who
gave me the opportunitytowork on a very interesting and practical problem as
part of the research for my thesis.
I am grateful to Dr. Carlos Berenstein and Dr. Scott Corson for kindly
consenting to join the defense committee and review this thesis. I am also
grateful to the Center for Satellite and Hybrid Communication Networks for the
support of my research.
I wish to thank my friends and co-workers for their support and encourage-
ment, especially Jagdeep and Varma.
Finally,Iwould like to thank my familyfor their love and support throughout
my studies.
iii
TABLE OF CONTENTS
LIST OF TABLES vii
LIST OF FIGURES viii
1 Introduction 1
1.1 Telemedicine and its bene#0Cts . . . . . . . . . . . . . . . . . . . . . 1
1.2 Proposed Telemedicine Service . . . . . . . . . . . . . . . . . . . . 3
1.3 Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . 6
2 PACS and Intelligent Networks 7
2.1 PACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 System Architecture . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Bene#0Cts of PACS . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Intelligent Networks . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 IN service processing model . . . . . . . . . . . . . . . . . 12
2.2.3 IN architectural concept . . . . . . . . . . . . . . . . . . . 13
2.3 Service Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
iv
2.4 Global Functional Plane . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Global Functional Plane modeling . . . . . . . . . . . . . . 15
2.4.2 Basic Call Process . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Points of Initiation and Points of Return in IN-CS1 . . . . 17
2.4.4 Service Independent Building Blocks . . . . . . . . . . . . 20
2.5 Distributed Functional Plane . . . . . . . . . . . . . . . . . . . . . 22
2.5.1 Distributed Functional Plane Model . . . . . . . . . . . . . 22
2.5.2 DFP Functional Entities . . . . . . . . . . . . . . . . . . . 23
2.6 Physical Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.1 General requirements . . . . . . . . . . . . . . . . . . . . . 25
3 Service Architecture 27
3.1 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 New SIBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 SIB description . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.2 SHORTEST PATH SIB . . . . . . . . . . . . . . . . . . . 31
3.2.3 UNIQUE LIST SIB . . . . . . . . . . . . . . . . . . . . . . 32
3.2.4 MULTIPLE SCP SSP SESSION SIB . . . . . . . . . . . . 32
3.2.5 ADJUST EDGE-WEIGHT SIB . . . . . . . . . . . . . . . 33
3.3 Information Elements . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Functional #0Dow diagram . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 The Service Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6 Best-Path Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.1 Service Logic Program . . . . . . . . . . . . . . . . . . . . 40
3.7 Design Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
v
4 Evaluating Slot Allocation Schemes #28for RPCU#29 and Queue
Management Schemes #28for Ambulance#29 46
4.1 Slot Allocation at the RPCU . . . . . . . . . . . . . . . . . . . . . 47
4.1.1 Single slot users to busiest channel . . . . . . . . . . . . . 49
4.1.2 Reallocation of Single slots users . . . . . . . . . . . . . . 51
4.1.3 Multi-channel allotment . . . . . . . . . . . . . . . . . . . 53
4.1.4 Dynamic Addition of slots . . . . . . . . . . . . . . . . . . 55
4.1.5 Reservation . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.1.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Ambulance Queue Management . . . . . . . . . . . . . . . . . . . 59
4.2.1 Single Queue without Priority . . . . . . . . . . . . . . . . 61
4.2.2 Priority Queuing . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.3 One Queue per Slot . . . . . . . . . . . . . . . . . . . . . . 63
4.2.4 One Queue per data source . . . . . . . . . . . . . . . . . 65
4.2.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5 Conclusions and Future Work 67
5.1 Contributions of the Thesis . . . . . . . . . . . . . . . . . . . . . 67
5.2 Service Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3 Slot Allocation Schemes . . . . . . . . . . . . . . . . . . . . . . . 70
5.4 Mobile Queue ManagementSchemes . . . . . . . . . . . . . . . . 71
Bibliography 72
vi
List of Tables
1.1 Typical Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Typical FE to PE mapping . . . . . . . . . . . . . . . . . . . . . 26
4.1 Arrival and Service Rates . . . . . . . . . . . . . . . . . . . . . . 50
4.2 Arrival Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
vii
List of Figures
1.1 Service Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 PACS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Typical IN service processing model . . . . . . . . . . . . . . . . . 12
2.3 IN Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Modeling of Global Functional Plane . . . . . . . . . . . . . . . . 17
2.5 Key components of the BCSM . . . . . . . . . . . . . . . . . . . . 18
2.6 Originating BCSM for CS1 . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Graphic representation of SIB . . . . . . . . . . . . . . . . . . . . 21
2.8 SIB example: Screen SIB . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Functional Entities and Relations in the DFP . . . . . . . . . . . 23
3.1 Hospital Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 RPCU Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Service Information Flow Diagram . . . . . . . . . . . . . . . . . 34
3.4 The Service Logic Program . . . . . . . . . . . . . . . . . . . . . . 36
3.5 The Service Logic Program . . . . . . . . . . . . . . . . . . . . . . 43
4.1 RPCU Queuing System . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 State diagram for the base station queue . . . . . . . . . . . . . . 49
viii
4.3 Basic FIFO Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Reallocation Algorithms . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Multi-channel Algorithm . . . . . . . . . . . . . . . . . . . . . . . 54
4.6 Dynamic slot addition algorithms . . . . . . . . . . . . . . . . . . 55
4.7 Comparison of schemes by varying the SS inter-arrival rates . . . 57
4.8 Comparison of schemes by varying the MS inter-arrival rates . . . 58
4.9 Mobile's Queuing System . . . . . . . . . . . . . . . . . . . . . . . 60
4.10 State diagram for the mobile queuing system . . . . . . . . . . . . 61
4.11 Results of Mobile Queuing system . . . . . . . . . . . . . . . . . . 63
4.12 Results of Mobile Queuing system . . . . . . . . . . . . . . . . . . 64
4.13 Results of Mobile Queuing system . . . . . . . . . . . . . . . . . . 65
ix
INTELLIGENT NETWORK BASED WIRELESS
SERVICES FOR TELEMEDICINE
Abhijeet S Bisain
August 3, 1998
This comment page is not part of the dissertation.
Typeset by L
A
T
E
X using the dissertation class by Pablo A. Straub, University of
Maryland.
0
Chapter 1
Introduction
Telemedicine is the use of telecommunications for medical diagnosis and pa-
tient care. It involves the use of telecommunications technology for providing
medical services to sites that are at a distance from the provider. This concept
encompasses everything from the use of standard telephone service, through high
speed, wide bandwidth transmission of digitized signals in conjunction with com-
puters, #0Cber optics, satellites, and other sophisticated peripheral equipment and
software. Telemedicine literally means, #5Cmedicine at a distance". The term was
coined in the 1970s by Thomas Bird.
Telemedicine is a system that combines computer, video, and network com-
munications and cost e#0Bective quality care. It includes diagnostic instruments
designed to provide information for digital transmission and reproduction.
1.1 Telemedicine and its bene#0Cts
Telemedicine can be divided into three areas: aid to decision-making, remote
sensing, and collaborative arrangements for the real-time management of pa-
tients at a distance. As an aid to decision-making, telemedicine includes areas
1
such as remote expert systems that contribute to patient diagnosis or the use
of online databases in the actual practice of medicine. Remote sensing consists
of the transmission of patient information, such as electrocardiographic signals,
X-rays, or patient records #28history of illness etc.#29 from a remote site to a collab-
orator at a distant site. Collaborative arrangements consist of using technology
to actually allow one practitioner to observe and discuss symptoms with another
practitioner whose patients are far away. Two-way work stations which provide
smooth digital motion pictures have been integral to the long distance, real-time
treatment of patients #5B1#5D.
One such applicationoftelemedicineis when medics inan ambulancecarrying
a trauma patient collaborate with the doctors in their parent hospital. These
medics transmit medical information #28images, X-rays, ECG#29 to the doctors on
the way to the hospital and receive operational instructions from them. This
application falls in the mix of remote sensing and collaborative categories of
telemedicine. We will concentrate on this aspect of telemedicine in this thesis.
Some of the potential bene#0Cts of telemedicine can be summarized as :
1. Improved access: Telemedicine can provide an improved access to health
care in previously unserved or under-served geographical areas.
2. Reduced cost: The travel cost of the patients for specialty care, the travel
cost of the health care professionals for continuing education or consulting,
the personnel#2Fequipment cost for not having to keep specialty care facility
in rural hospitals, and other costs can either be eliminated or reduced.
3. Reduced isolation: Telemedicine provides a peer and specialist contact for
patient consultations and continuing education. It has also been reported
2
that color, full-motion video is critical to the health professionals for simu-
lating face-to-face communication between colleagues in consultations and
between patients and physicians.
4. Improved quality of care: Telemedicine allows the consultation among the
referring physician, the consulting physician, the patient, and the patient's
family through interactive video with critical information of the patient
available on-line. Also, the physicians or other personnel at remote loca-
tions can be educated during the consultations with specialty physicians
and other experts, increasing their ability to treat other similar cases in the
future. It helps the doctors to be better prepared for incoming patients.
1.2 Proposed Telemedicine Service
As we stated in the previous section, we will concentrate on the application of
telemedicine, where an ambulance needs to collaborate with its parent hospital.
In this thesis we propose a service to transmit high bit-rate medical data over
the existing terrestrial wireless network from an ambulance #28carrying a trauma
patient#29 to the hospital. Studies have indicated that advance availabilityofthe
information about the patient's condition increases the chances of the treatment
being successful by 20#25. The doctors are better prepared when the patient
arrives, with the right kind of instruments and medication, and they can better
utilize the time in the ambulance by giving suggestions to the medics on-board.
The doctors need the patient's video, X-Rays, ECG and other information
to make good decisions. In order to send this information, the ambulance needs
to have a high-speed wireless communication link to the hospital. A study of ex-
3
pected data rates #28obtained from Anaesthlab, UMBC#29 #5B2#5D of medical information
is shown in the Table 1.1.
A Motion Detection image 2kb#02#288 to 30#29frames#2Fsec
#18
= 16 to 60 kbps
B High Resolution X-Ray #28static#29 250kb #284in.#024in. image#29
C Chest X-Ray #28static#29 1-2Mb #284#02#28B#29#29
D Good Quality Image 8kb #28same motion requirement as #28A#29#29
E ECG 1kbps - 10kbps
F Ultrasound 250kbps
G Audio 9.6kbps
Table 1.1: Typical Data Rates
Atypical data connection in today's cellular network #5B3#5D infrastructure pro-
vides at most 19.2 kbps. A TDMA based standard called Personal Access Com-
munication System #28PACS#29 #5B4#5D promises a higher data rate capability of 28.8
kbps per TDMA slot. PACS also has the feature of multiple slot packet con-
nections, making higher data rates #28upto 214.6kbps#29 possible. Hence, PACS is
chosen as the wireless network standard for our application.
In this thesis, we de#0Cne a new service architecture for the mobile as shown
in Figure 1.1. This service architecture makes high bit rate connections for the
ambulance and informs it about the future availability of bandwidth. This is
required because the bit-rate does not remain constant with time as the ambu-
lance is handed o#0B from one base station to another, with di#0Berent base stations
having varying capacities. The present network architecture lacks the signaling
mechanism and the logic programs to perform this task.
As shown in Figure 1.1, we include Intelligent Network #28IN#29 as an integral
4
PSTN/ISDN
Network
PSTN/ISDN
modems
Doctor?s
Terminal
V.42/V.42bis
Serial
Information
gatherers
PC
Cellular
Modem
Serial
Network
Intelligent
PACS/GSM
Cells
PACS/GSM
Cells
PACS/GSM
Cells
PACS/GSM
Cells
Ambulance 
Trajectory
AMBULANCE
HOSPITAL
PREMISES
Figure 1.1: Service Architecture
element in our Service Architecture. We add features in IN such that it aids
the ambulance in choosing optimal routes from the location of the patienttothe
hospital and in designing an optimal transmission schedule. IntelligentNetworks
#28IN#29 #5B5#5D are a means of implementing new services over PSTN and ISDN net-
works. Under the present IN standard speci#0Ccations, it is not possible to provide
such a service; thus, new modules need to be added to support this service. This
thesis outlines these modi#0Ccations.
Other aspects of this service to an ambulance are also studied. The base
stations in the PACS architecture need optimal slot allocation algorithms to
maximize the slots allocated to the ambulance. We propose some slot allocation
schemes and evaluate their performance. The ambulance requires mechanisms
to optimally utilize its limited resources #28memory space to queue packets and
5
available time slots#29. We propose various queuing disciplines for the medical
data to maximize the utility of information transmitted. Suggestions about the
best slot allocation policies, queuing disciplines and network architecture for this
service are made.
1.3 Organization of the Thesis
Chapter 2, in this thesis, introduces the Intelligent Network architecture and
PACS air interface standard. Chapter 3 gives the details of the modi#0Ccations
to the present network architecture needed to provide this service to the ambu-
lance. It includes the Service Independent Building#28SIB#29 blocks, functional #0Dow
speci#0Ccations, and Service Logic Programs needed to implement this service.
In Chapter 4, several slot allocation algorithms for the base station and bu#0Ber
management algorithms for the mobile are discussed. These are simulated in the
Opnet simulation tool. We conclude in Chapter 5 with suggestions for future
work.
6
Chapter 2
PACS and Intelligent Networks
In the previous chapter we highlighted the advantages of PACS and Intelligent
Network standards. This chapter describes the relevant features of these stan-
dards needed to implement our service. PACS architecture and its bene#0Cts are
introduced followed by a description of the CS-1 standard for IN.
2.1 PACS
2.1.1 Introduction
The Personal Access Communications System or PACS #5B4#5D, is a low tier#2Flow
power radio system that has been standardized for operation in the 1850-1990
MHz licensed PCS band. It is being developed by Bellcore, HNS, NEC Amer-
ica, Parasonic, PCSI and Seimens. PACS provides an approach to PCS that
is compatible with the local exchange telephone network and inter-operable
with existing cellular systems. The system was designed to support mobile and
#0Cxed applications at low installation and operating costs while providing very
high quality voice and data services. PACS capabilities include pedestrian and
7
vehicular-speed mobility, data services, licensed and unlicensed systems, simpli-
#0Ced network provisioning, maintenance and administration.
2.1.2 System Architecture
Figure 2.1 shows the PACS network architecture #5B6#5D. Three major elements
in this architecture are the radio system, the Integrated Services Digital Net-
work #28ISDN#29#2FIntelligentNetwork #28IN#29 switch, and the IN Service Control Point
#28SCP#29. The radio system and switch communicate via ISDN protocol. The
switch and the SCP communicate via AIN protocol. The AIN switch and the
AIN SCP communicate with the public switched telephone network via Sig-
nalling System No. 7 #28SS7#29 protocol.
The radio system consists of Subscriber Units #28SU#29, Radio Ports #28RP#29, and
Radio Port Control Units #28RPCU#29. The SUs communicate with the network
through the RPs. The PACS air interface signal uses Time Division Multiple
Access #28TDMA#29 on the up-link #5Bfrom SU to RP#5D and Time Division Multiplexed
#28TDM#29 on the down-link #5Bfrom RP to SU#5D. Multiple RPs #28e.g. 24-100#29 are con-
nected to a RPCU through the Port #28P#29 interface. The coverage area of an RP
ranges from approximately a quarter of a mile to a mile. Transmission facility
options for the P interface include E1, T1, high-speed digital subscriber line
#28HDSL#29 and digital subscriber line #28DSL#29 technologies. The RPCU provides
management and control functions between the RP and the local exchange net-
work. RPCUs are connected to a standard class 5 switch through the Control
#28C#29 interface. The C interface uses an ISDN Basic Rate Interface #28BRI#29. The
RPCUs operate seamlessly with service providers subscriber database. This en-
ables access to advanced intelligent network #28AIN#29 services and features. The
8
RPs function largely as RF modems, depending on the centrally located RPCUs
for most of the functionality. An advantage of locating most of the functionality
in the RPCU is that service upgrades to support new data services or improved
speech coders do not require visits to RP sites. The RPCU system automatically
selects the best frequency for use by each RP, eliminating the need of detailed
frequency management#28Algorithm QSAFA#29.
RPCU
STP
SS7
AIN
ISDN
Subscriber
Unit
AM
HLR
VLR
AIN
Radio
Ports
Radio System
AIN SCP
 PSTN
ISDN/AIN
   switch
 IP
Trunk
Figure 2.1: PACS Architecture
An Access Manager #28AM#29 inthe SCP supports multipleRPCUs withnetwork-
related tasks such as querying remote databases for visiting users, assisting in
network call setup and delivery, and coordinating hando#0B between RPCUs.
The PACS air interface standard includes protocol speci#0Ccations for an indi-
vidual messaging service, a circuit mode data service, a packet mode data service
as well as an interleaved speech#2Fdata service.
9
2.1.3 Bene#0Cts of PACS
Key features of PACS include:
1. Voice and data services comparable in quality, reliability and security with
wire-line alternatives.
2. Very cost e#0Bective for serving high tele-tra#0Ec areas, small, inexpensive,
line-powered radio ports forpoleorwall mounting.
3. Low transmit power and e#0Ecient sleep mode requiring only small batteries
to power portable subscriber units.
4. PACS is a low tier, low power technology. Antennae can be constructed
quite inconspicuously, piggy-backing on existing structures. This avoids
the high costs and delays attendant on permitting high towers.
5. PACS is based on Bellcore's WACS #28Wireless Access Communications
System#29, developed for wireless local loop replacement, and on Japan's
Personal Handy-phone System #28PHS#29. Several vendors are designing Sub-
scriber Units for installation on subscriber premises.
6. Bellcore has designed PACS to support the full range of AIN services #5B6#5D,
including custom calling features, terminal and personal mobility, etc. As
new AIN features are developed, the Bellcore standards de#0Cning this tech-
nology evolve to facilitate incorporation of the new services into PACS.
7. Control of frequency utilization lies at the RPCU, which is directly con-
nected to the AM. The RPCU has abilities to mark channels for particular
kind of users.
10
8. PACS supports priority and Emergency calling services. These calls can
supersede ordinary calls and get access when they need.
2.2 Intelligent Networks
2.2.1 Introduction
The term Intelligent Network #28IN#29 #28 #5B5#5D, #5B7#5D #29 is used to describe an architectural
concept applicable to all telecommunications networks. It provides a complete
framework for the uniform creation, provision and management of advanced
communication services. This is achieved by taking the data required for a par-
ticular service #28e.g Free-phone, optimal routing,conference calling, call barring#29
and the service logic, outside the telephone switching network, and putting it
into intelligent nodes.
Before IN, introduction of a new service required a change in the call han-
dling software of every switch in the network. IN remedies this problem by
taking the #5Cintelligence" away from the switches, into the #5Cintelligent modules".
Each switch executes a Basic Call Process #28BCP#29 for a call, and if it senses the
requirement of a higher intelligence to support the call, it contacts the #5Cintelli-
gentagent". This agentcontains the necessary processing tools and information
#28service logic#29 to understand the request made by the call and guide the switch
on how to proceed with the call. These agents are called Service Control Points
#28SCP#29 and the switches which know SCPs exist are called Service Switching
Points #28SSP#29.
11
2.2.2 IN service processing model
The IN service processing model describes how any call gets processed in the
network. The elements of this model are: the Basic Call Processes #28BCP#29, the
#5Chooks" that allow the BCP to interact with IN service logic, and IN service
logic that can be #5Cprogrammed" to implement new services #28 #5B8#5D, #5B9#5D, #5B10#5D, #5B11#5D #29.
The main principles for these elements are described below.
IN  SERVICE   LOGIC
Fast   Service  Implementation
Node A Node B Node C
hooks hooks hooks
BCP BCPBCP
BCP  Basic Call Processing
Figure 2.2: Typical IN service processing model
The basic BCP is available in all switches and is designed to support, with
optimal performance, services that do not require special features. In order to
achieve #0Dexibility in service processing, the BCP is modularized into services-
independent sub-processes such that these can be executed autonomously #28with-
out interference from the outside during execution#29.
#5CHooks" are added to the BCP forming the links between the individual basic
call sub-processes and the service logic. For this, the switches should continu-
12
ously check the BCP for the occurrence of conditions on which an interaction
session with IN service logic should be started. During an interaction session
the BCP can be temporarily suspended.
The IN service logic uses a programmable software environment to execute
the service logic. New supplementary services can be created by means of #5Cpro-
grams" containing the logic for the desired service. It interacts with the BCP via
the #5Chooks". It can decide to terminate an interaction session with the BCP.The
basic call process will then resume its execution as speci#0Ced by the IN service
logic.
Thus, by changing the logic at the SCP and modifying network data, anew
service that uses existing network capabilities can be readily implemented.
2.2.3 IN architectural concept
A key objective of IN is to provide service-independent functions#2Fblocks #28SIB#29
that can be used as #5Cbuilding blocks" to construct avariety of services.
The second objective is network implementation independent provision of
services. This objective aims to isolate the services from the way the SIBs are
actually implemented in various physical networks, thus providing services that
are independent of underlying physical network infrastructure.
The IN Conceptual Model #28INCM#29 #28Figure 2.3#29 #5B12#5D is a framework for the
design and description of the IN architecture which achieves the above objec-
tive. The INCM #28Figure 2.3 #29 consists of four #5Cplanes" where each plane repre-
sents a di#0Berent abstract view of the capabilities provided by an IN-structured
network. These views address service aspects, global functionality, distributed
functionality and physical aspects of IN. IN Capability Set 1 #28IN-CS1#29 is the
13
#0Crst standardized stage of the Intelligent Network as an architectural concept
for the creation #5B13#5D and provision of telecommunication services. Thenextfew
sections will discuss each plane shown in Figure 2.3.
Service Plane
SF1
SF2
SF3
SF2
Service X
Service Y
Global Functional Plane
BCP
SIB1
SIB2
SIB3
POI
POR
chain of
SIBs
Network
Distributed Functional Plane
Network
SMF
SCF
SDF
SRFSSF
CCF
IFs
FEs
Physical Plane
PE1
PE2
PE3
PE4
P1
P2
P3
Figure 2.3: IN Conceptual Model
2.3 Service Plane
The service plane illustrates IN-supported services by means of a set of generic
blocks called #5CService Features". A service is a stand-alone commercial o#0Bering,
14
characterized by one or more Service Features #28core SF#29.The service plane rep-
resents an exclusively service-oriented view. This view contains no information
regarding the implementationof the services in the network. All that is perceived
is the network's service-related behavior as seen, for example, by a service user.
The presence of multiple services results in the interaction between the ser-
vices and other supplementary services. Service interaction applies to all inter-
actions of the service being described with other services already identi#0Ced. An
IN structured network handles multiple services for the same call. The service
interaction is part of the speci#0Ccation of services.
2.4 Global Functional Plane
2.4.1 Global Functional Plane modeling
The Global Functional Plane #28GFP#29 models network functionality from a global
or network-wide point of view. The IN Structured Network is viewed as a single
entity in the GFP. In this plane, Services and Services Features are rede#0Cned in
terms of the broad network functions required to support them. These functions
are neither Service nor Service-Feature speci#0Cc and are referred to as Service
Independent Building blocks #28SIB#29.
The Global Functional Plane contains the following:
1. Basic Call Process #28BCP#29: identi#0Ces the normal call process from whichIN
services are launched. This includes Points of Initiation #28POI: a point in
the call where the service is triggered#29, and Points of Return #28POR: where
the service logic returns and the BCP continues execution#29 which provide
the interface from the BCP to the Service Logic Program. For a given
15
service, at least one POI is required; depending upon the logic required to
support the service, multiple PORs maybede#0Cned.
2. SIBs: are standard reusable network-wide capabilities used to realize Ser-
vices and Service Features
3. Service Logic Program #28SLP#29: which describes how the SIBs are chained
together, how they branch and the how the branches rejoin to describe
Service Features. The SLP also describes interaction between the BCP and
the SIB chains. Various network elements #28SSP,SDP#29 can be contacted by
the SCP during the execution of the SLP.
In order to chain SIBs together, knowledge of the connection pattern, decision
options, and data required bySIBsmustbeavailable. SIBs, including BCP, are
service independent and cannot contain knowledge of subsequent SIBs. There-
fore, SLP is the only element in the GFP which is speci#0Ccally service dependent.
2.4.2 Basic Call Process
The BCP is represented in terms of a high level #0Cnite state machine known as
the Basic Call State Model #28BCSM#29. The BCSM identi#0Ces points in basic call
#28PIC#29 and connection processing when IN service logic instances are permitted to
interact with the basic call and connection control capabilities. PICs identify the
activities required to complete one or more call#2Fconnection tasks of interest to
IN service logic instances. Detection Points #28DP#29 or the #5Chooks" indicate points
in basic call and connection processing at which transfer of control #28to the SLP#29
can occur #28Figure 2.5#29. The transitions from one PIC to another indicate the
normal #0Dow of basic call.
16
SIB1 SIB2 SIB3 SIB4
SIB5
POI POR POR
Figure 2.4: Modeling of Global Functional Plane
The BCSM also re#0Dects the functional separation between the originating
#28Figure 2.6#29 and terminating portions of calls. Each of them is managed by a
functionally separate BCP in the SSF#2FCCF. For IN-CS1, the following BCSM
#28Figure 2.6#29 is de#0Cned.
2.4.3 Points of Initiation and Points of Return in IN-CS1
The following set of POIs has been identi#0Ced for CS1:
1. Call Originated.
2. Address Collected.
3. Address Analyzed.
4. Prepared to Complete Call.
17
Transition
Events associated
with a transition
Detect Point : DP
Point In Call : PIC
Figure 2.5: Key components of the BCSM
5. Busy.
6. No Answer.
7. Call Acceptance.
8. Active State.
9. End of Call.
The following set of PORs has been identi#0Ced for CS1:
1. Continue with existing data: BCP should continue with no modi#0Ccation.
2. Proceed with new data: BCP should proceed call processing with only a
data modi#0Ccation.
3. Handle as transit: BCP should treat the call as if it had just arrived.
18
O_NULL &
Autherize Origination
Attempt
Collect Information
Analyze Information
Routing and Alerting
O_Active
DP 1
DP 2
DP 3
DP 4
DP 9
DP 10
DP 4
DP 5
DP 6
Analyzed
Information
Collected
Information
Origination
Attempt Authorized
O_Abandon
O_Exception
Route Select Failure
O_Called Party Busy
O_No Answer
O_Answer
O_Disconnect
O_Mid Call
Figure 2.6: Originating BCSM for CS1
4. Clear Call: BCP should clear the call.
5. Enable call party handling: BCP should perform functions to enable call
control for call parties.
6. Initiate Call: a call should be initiated independently or in the context of
the call.
19
2.4.4 Service Independent Building Blocks
A SIB is a standard reusable network-wide capability residing in the Global
Functional Plane used to create Service Features. SIBs are of a global nature
and their detailed realization is not considered at this level but can be found in
the Distributed Functional Plane #28DFP#29 and the Physical Plane. Data required
by each SIB is de#0Cned by Service Support Data #28SSD#29 parameters, and Call
Instance Data #28CID#29 parameters, as shown in Figure 2.7.
CID de#0Cnes dynamic parameters whose value will change with each call in-
stance. They are used to specify subscriber speci#0Cc details like calling or called
line information. This data can be made available from the BCP #28e.g. Calling
Line Identi#0Ccation#29 generated by a SIB #28e.g. a translated number#29, or entered
by the subscriber #28e.g. a PIN code#29.
SSD de#0Cnes data parameters required by a SIB which is speci#0Cc to the service
feature description. When a SIB is included in the SLP of a service description,
the SLP will specify the SSD values for the SIB.
The following set of SIBs of the IN-CS1 have been identi#0Ced as required to
support the list of targeted services:
1. Algorithm: apply mathematicalalgorithmto data to produce data result.
It has been limited to an increment or decrement operation on the data.
2. Charge: determine special ways to charge for the call.
3. Compare: compare avalue against a speci#0Ced reference value.
4. Distribution: distribute calls to di#0Berent logical ends based upon param-
eters.
20
SSD Paramenters
Logical
Start
Logical
Ends
CID Input
Parameters
CID Output
Parameters
SIB
Figure 2.7: Graphic representation of SIB
5. Limit: limit the number of calls which use an IN provided service.
6. Log Call Information: log detailed information for each call into a #0Cle.
7. Queue: provide sequencing of IN calls to be completed to acalledparty.
8. Screen: determine if a supplied value exists in a list.
9. Service Data Management: replace, retrieve, modify user speci#0Cc data.
10. Status Noti#0Ccation: inquiry about the status and#2For status changes of
network resources.
11. Translate: determine output information from input information based
on a translation #0Cle.
12. User Interaction: information exchange between the network and a call-
ing#2Fcalled party.
21
13. Verify: syntactical consistency check of received information.
Figure 2.8 shows the representation of the screen SIB. Other SIB structures
can be found in #5B12#5D.
Screen List Indicator
CIDFP-Locatiopn of 
value to be screened
Start
Match
No Match
Error
Error
Caused
CID-Value to
be screened
SCREEN  SIB
Figure 2.8: SIB example: Screen SIB
2.5 Distributed Functional Plane
2.5.1 Distributed Functional Plane Model
In this plane the network architecture is represented in terms of Functional
Entities #28FE#29. A FE #28Figure2.9#29 is a unique group of functions ina singlelocation
and a subset of the total set of functions required to provide a service. One or
more functional entities can be located in the same Physical Entity #28de#0Cned in
the physical plane#29. Di#0Berent functional entities contain di#0Berent functions, and
22
SDF SMF
SMAF
SCEF
SRF SCF
CCAF
SSF
CCF
SSF
CCF CCF
CCAF
Figure 2.9: Functional Entities and Relations in the DFP
may also contain one or more of the same function. In addition, one functional
entity cannot be split between two physical entities.
Each interaction between a communicating pair of functional entities in the
model is de#0Cned by a set of Information Flows #28IF#29.
2.5.2 DFP Functional Entities
The Call Control Agent Function #28CCAF#29 provides access for users. It
is the interface between user and network call control functions and receives
indications relating to the call or service from the CCF and relays them to the
user as required.
The Call Control Function #28CCF#29 provides call#2Fconnection processing
and control. It provides the capability to associate and relate CCAF functional
23
entities that are involved in a particular call and#2For connection instance. It
contains trigger mechanisms to access IN functionality #28e.g. passes events to the
SSF#29.
The Service Switching Function #28SSF#29 interacts between the CCF and
a SCF. It modi#0Ces the call#2Fconnection processing functions #28in the CCF#29 as
required to process requests for IN provided service usage under the control of
the SCF. The SSP sends tra#0Ec data including real time information to the SCP.
The Service Control Function #28SCF#29 commands call control functions in
the processing of IN provided or custom service requests. The SCF mayinteract
with other functional entities to access additional logic or to obtain information
#28service or user data#29 required to process a service instance. The typical response
time of an SCP for a service logic is less than 300ms.
The Service Data Function #28SDF#29 contains customer and network data
for access by the SCF in the execution of an IN service.
The Specialized Resource Function #28SRF#29 provides the specialized re-
sources required for the execution of IN provided services #28e.g. digit receivers,
announcements, conference bridges, etc.#29. It may contain logic and processing
capability to receive#2Fsend and convert information received from users.
The Service Creation Environment allows services provided in IN to
be de#0Cned, developed, tested and input to SMF. Output of this function would
include service logic, service management logic, service data template and service
trigger information.
The Service Management Agent Function #28SMAF#29 provides a man-
agement interface between service managers and the SMF.
The Service Management Function #28SMF#29 allows deployment and pro-
24
vision of IN provided services and allows the support of ongoing operation. It
manages, updates and administers service related information in SRF, SSF and
CCF.
2.6 Physical Plane
2.6.1 General requirements
The Physical Plane of the IN Conceptual Model identi#0Ces the di#0BerentPhysical
Entities #28PE#29 and the interfaces between these entities. One or more functional
entities may be mapped onto the same physical entity.
The following selection of PEs has been de#0Cned to support IN.
1. Service Switching Point #28SSP#29
2. Service Control Point #28SCP#29
3. Service Data Point#28SDP#29
4. IntelligentPeripheral #28IP#29
5. Adjunct #28AD#29
6. Service Node #28SN#29
7. Service Switching and Control Point #28SSCP#29
8. Service Management Point#28SMP#29
9. Service Creation Environment Point #28SCEP#29
10. Service Management Access Point #28SMAP#29
25
Table 2.1 outlines a mapping from the FEs in the DFP to the PEs in the
physical plane. The information#0Dows between the FEs #28in the DFP#29 are mapped
to the TCAP messages between the PEs #28in the Physical Plane#29. TCAP stands
for Transition Capability Application Part.
SCF CCF#2FSSF SDF SRF SMF SCEF SMAF
SSP O C O O - - -
SCP C - O - - - -
SDP - - C - - - -
IP - O - C - - -
AD C - C - - - -
SN C C C C - - -
SSCP C C C O - - -
SMP - - - - C O O
SCEP - - - - - C -
SMAP - - - - - - C
Table 2.1: Typical FE to PE mapping
C: Core O: Optional -: Not allowed
26
Chapter 3
Service Architecture
In the previous chapter, we described the PACS and IN standard chosen for the
network. Now we model the network architecture on which the new service is
proposed. We talk about our design of the new Service Independent Building
#28SIB#29 blocks, functional #0Dow diagrams, and service logic programs needed to
implement the service. Various implementation issues of the additional SIBs are
discussed. The design of the SLP is critical for the proper functioning of the
service. We propose two SLPs for two di#0Berent services, di#0Bering in complexity
and features provided. In designing the new SLPs, we emphasize particularly
on the inputs and outputs of each SIB in the control sequence of the SLP. We
identify the POIs and PORs for each SLP.
3.1 Network Architecture
For the development of the service proposed in this thesis, we #0Crst model the
system we are working with. The system consists of the following entities :
27
1. The ambulance which has data capturing equipment connected to a PC
through its ports. The PC software for compressing each data source to
#0Cxed size packets, and forwarding them to the wireless modem. The PC
also has software to automatically re-dial when it looses the call, it has
the facility to determine the location of the ambulance using GPS or other
TDMA self location schemes and transmit this information to the network
when requested.
2. PACS air interface is used between the wireless modem and the Radio Port
Control Unit.
3. The Radio Port Control Unit is connected to the intelligentISDNnetwork
through appropriate adaptors.
4. At the terminating end, the doctor's PC has ISDN equipment to receive
calls and demultiplexing software to separate packets into ECG, video etc.
ISDN Lines
Display
Multiplexer
n
lines
that allows
multiple data
rates(PPP)
Demultiplexer
""
Some kind
of interface
Computer 
for the doctors
from local switch
Figure 3.1: Hospital Hardware
28
In the network, the hospital has a set of ISDN lines coming into a lab as
shown in Figure 3.1. It's software supports the BONDing protocol to setup a
single connection using multiple lines and demultiplex the incoming data from
multiple lines to the displays. The header of each packet has a data type #0Celd,
and a packet number #0Celd. These are su#0Ecient for the demultiplexing software
to separate packets of di#0Berentdatatypes and sequence them before display. No
end to end retransmission schemes are needed. Corrupt packets are dropped. If
any data source in the mobile, generates a packet with size less than one time slot
worth of bits, the remaining packet is stu#0Bed with nonsense bits or checksums.
ISDN lines 
to the switch
TDMA
slots
Multiplexer
Demultiplexer
Base Station
Figure 3.2: RPCU Hardware
The RPCUs #28Figure 3.2#29 have the ability to setup a single connection on mul-
tiple ISDN channels and demultiplex data from one mobile #28ambulance#29 to those
channels according to some pre-speci#0Ced algorithm. In e#0Bect, the base station
receives data from the ambulance at multiples of 28kbps, which it transmits on
multiple ISDN lines to the hospital. The number of ISDN lines chosen is depen-
dent on the number of time slots allocated to the ambulance. For example, if
29
the ambulance was allocated 4 slots, its consolidated bit rate would be 112kbps.
So the RPCU will need 2B channels on the ISDN side to send the data of the
ambulance to the hospital.
Since the connection of the ambulance is asymmetric, more bandwidth is
required in the uplink than the downlink. This is exactly opposite to the re-
quirements of some other applications which require more downlink and less
uplink. This implies that the downlink channels can be shared with other users
that need more downlink than uplink.
The Intelligent Network informs the ambulance about the bandwidth avail-
able to it after every hando#0B, helping it to formulate an optimal transmission
schedule. With this information, the ambulance software can decide which data
to send when, what coding scheme to use, what frame rate of video capture to
choose etc.
It is envisioned, that this service can be implemented in two possible ways.
In the #0Crst approach, the ambulance initiates the call setup from the patient's
location. In this case, the SCP needs to determine all the SSPs on its route
using its Geographical Information System #28GIS#29. In the second approach the
call is initiated when the ambulance leaves the hospital to pick up the patient.
In this scenario, the base stations that the ambulance goes through, identify
themselves to the SCP, send their present resource availability and reserve that
resource. After the reaching the destination, the SCP sends this information
to the ambulance. The latter is simpler to implement and guarantees higher
bandwidth #28advance reservation of capacity#29 to the ambulance, but is expensive
because of the excess airtime. In this thesis the former approach will be dicussed
in details.
30
3.2 New SIBS
3.2.1 SIB description
We described the Service Independent Building blocks in the previous chapter.
The SCP executes these SIBs in a sequence given by the Service Logic Program
to provide a service. In order to provide the service described in this thesis,
we de#0Cne additional SIBs not de#0Cned in CS-1. The new SIBs are described
according to the following templates:
1. De#0Cnition: A detailed description of the purpose of the SIB.
2. Operation: A brief outline of the operation of the SIB.
3. Input: A list of input information required for the proper functioning of
the SIB in terms of the SSD and CID speci#0Ccations.
4. Output: A list of outputs #28CID#29 generated by the SIB after its operation
is complete and its output branches#28SIBs#29.
CID stands for Call Instance Data and SSD stands for Service Speci#0Cc data,
as described in the previous chapter. Information is exchanged between SIBs, in
terms of CID File Pointers #28CIDFP#29.
We have attempted to design these new SIBs service independent.
3.2.2 SHORTEST PATH SIB
This SIB provides the shortest path between two nodes in a graph.
The inputs to this SIB are: the CIDFP to the source node, to the sink
#28destination#29 node and to the address of the graph data structure.
31
The output is a CIDFP to an ordered list of edges on the shortest path. The
output is an Error if the path could not be found.
3.2.3 UNIQUE LIST SIB
This SIB takes a matrix as an input and outputs a new matrix in which no two
consecutive rows are equal; keeping one copy of the repeated rows.
The input to this SIB is a CIDFP, pointing to the matrix and the row and
column lengths of the matrix.
The output is a CIDFP, pointing to the result matrix and its dimensions.
3.2.4 MULTIPLE SCP SSP SESSION SIB
This SIB initiates multiple sessions between one SCP and several SSPs. The
sessions are parallel or serial depending on the implementation.
The input is a pointer to list of SSP ids that need to be contacted and a
pointer to the TCAP message.
When the SIB is multithreaded, it spawns multiple threads depending on
the number of SSPs supplied. In case of serial sessions, no multithreading is
required, instead a loop is executed as many times as the number of SSPs.
During each loop, the current SSP is contacted, its response is obtained, the
session is terminated, and the current SSP id is set to the next SSP id in the
input list.
The outputs of this SIB is a list of CIDFPs pointing to the data obtained
from the various SSPs, or Error if any of the SSPs did not respond within the
speci#0Ced time interval.
32
3.2.5 ADJUST EDGE-WEIGHT SIB
This SIB modi#0Ces the weights of the edges in a graph depending on the data
provided to it.
The input to this SIB is a pointer to a list of edges, a pointer to an n#02m
matrix containing `m' attributes of `n' edges, and a pointer to a function for
calculating the weight of an edge depending on the attributes of that edge.
The ouput is alistofedgeswith the updated weights.
3.3 Information Elements
As described in Chapter 2, Information Elements are the packets #28TCAP#29 ex-
changed between two functional entities. To ensure proper functioning of this
service, some new information elements are required.
1. Between the RPCU #28SSP#29 and an SCP, an IE about the emergency call
#28which is a trigger query to distinguish this call from other regular phone
calls#29.
2. From the SCP to an SSP to invoke and inquire about their bandwidth
availabilities. The Register #28P-INFO#29 message format can be used to do
this.
3. From all SSPs that receive the above message, to notify the SCP, about
their resource availability #28Return Result Monitor Resource message in
TCAP#29.
4. From SCP to an SSP to release reserved resources.
33
3.4 Functional #0Dow diagram
The functional #0Dow diagram of the service is depicted in Figure 3.3. It shows the
di#0Berent components of the networks and the information #0Dows between them.
Ambulance SSP SCP SDP SSP SSP
Call Setup
Service request
User interface(query)
User Response
Database queries
DB query responses
Monitor Resource Invoke
Monitor Resource Response
Bandwidth Availability Information
Figure 3.3: Service Information Flow Diagram
The following messages are exchanged between the physical entities.
1. The SSP, when realizes that the call is a special one, sends a message to
the SCP.
2. After receiving this message from the SSP, the SCP #28User Interface SIB#29
queries the user for data.
34
3. After receiving this message from the SSP, the SCP sends database queries
to the SDP to obtain data required by its SIBs.
4. Using the SSP ids provided by the SDP, the SCP sends a message to all
the RPCUs, requesting them to provide the maximum bandwidth available
and reserve that bandwidth.
5. The RPCUs reply back with a Return Result message containing the band-
width data. The RPCUs have the capability to mark availible tra#0Ec chan-
nels as busy and use them for emergency calls. If further slots become
availible before the ambulance enters it region, the RPCU can mark those
slots busy too.
6. The SCP #28User Interface SIB#29 sends this information to the mobile.
3.5 The Service Logic
When the ambulance makes a call, the IN switch #28SSP#29 sends aqueryto the IN
SCP. Based on the trigger type and the parameters of the message the query is
processed by the SLP in the IN SCP. The SSP detects a special call after the
AnalyzeInfo PIC and before the route is selected and triggers the service logic
#28Figure 3.4#29. AIN0.1 has trigger points for N11 type calls. In our Service Logic,
the following SIBs are used in the service logic:
1. The Screen SIB is used to authenticate the user. The inputs are :
#28a#29 Screen List Indicator #28SSD#29:List of users #28telephone numbers#29 sub-
scribing to this service.
35
SCREEN USER INTERFACE TRANSLATE TRANSLATE MAPPING TRANSLATE
BCP
POI
POR
Multiple
SCP_SSP session
USER INTERFACE
UNIQUE LIST
Clear Call (Select Route)()POR
(Analyze Info)
Figure 3.4: The Service Logic Program
#28b#29 CIDPF:Location of the value #28telephone number of the ambulance#29
to be screened.
The output is a #5CMatch" if the user is found and the control goes to the
next SIB decided by the SLP. It is a #5CNo Match" if the user has not
subsribed to the service; the control goes back to the BCP in the Clear
Call PIC and the call is cleared.
2. The User Interface SIB is used to obtain the ambulance's longitude and
latitude and the hospital's telephone number. The inputs to this SIB are:
36
#28a#29 SSD-Activity: Play announcement and collect data.
#28b#29 SSD- Announcement Indicator.
#28c#29 CIDPF-Location of announcement parameter: #5C Give latitute and
logitude of your location".
#28d#29 CIDPF-Location of the collected information: CIDPF 1.
The output of this SIB is always a #5CSuccess".
3. The Translate SIB is used to obtain the crossroads closest to the Lon-
gitude and Latitude provided by the ambulance. The inputs to this SIB
are:
#28a#29 SSD-Translate File Indicator: Longitude,Latitude to crossroads.
#28b#29 CIDPF-Location of the value to be translated: CIDPF 1.
The output is CIDPF 2pointing to the name of the crossroad if the trans-
lation is a success, else an error and the control returns to the BCP to
continue the call #28Select Route#29.
4. The Translate SIB is used to obtain the crossroads closest to the hospital
phone number provided by the ambulance. The inputs to this SIB are:
#28a#29 SSD-Translate File Indicator: Hospital phone numbers to crossroads
list.
#28b#29 CIDPF-Location of the value to be translated: Hospital phone num-
ber.
The output is CIDPF 3pointing to the name of the crossroad if the trans-
lation is a success, else an error and the control returns to the BCP to
37
continue the call #28Select Route#29.
5. The Shortest Path SIB is used to #0Cnd the shortest route between these
crossroads. The city is represented in the form of a #5CGraph" #5B14#5D with the
street intersections as the #5CNodes" in the Graph, and the streets connecting
these intersections as the #5CEdges" in the Graph. The edges are weighted by
the length of the streets they represent. The shortest distance is calculated
by applying Djikstra's algorithm #5B14#5D .
Inputs to this SIB are:
#28a#29 SSD-Database: Graph which maps the city.
#28b#29 CIDPF-Location of the source and destination points #28CIDFP 2 and
CIDFP 3#29.
The output is a CIDFP 4 pointing to a list of edges on the shortest path.
If there is an error, the control returns to the BCP to continue the call
#28Select Route#29.
6. The Translate SIB is used to translate the edges obtained from the Short-
est Path SIB to cell ids and the RPCU ids in the PACS network that these
streets come under. The inputs to this SIB are:
#28a#29 SSD-Translation File Indicator: Streets #28edges#29 to cell ids and RPCU
ids.
#28b#29 CIDPF-Locationof the valuesto be translated:Listofedges #28CIDPF 4#29.
The output #28#5CSuccess"#29 is CIDFP 5 pointing to an n#022 array with RP
ids and RPCU ids covering the path of the ambulance. Consecutive rows
38
in this list correspond to a hando#0B between cells. It is possible that two
consecutive edges map to same cells. This corresponds to one RP covering
di#0Berent streets. This situation is possible in reality, but we must remove
such entries from our list because they do not represent a hando#0B. If an
error, the control returns to the BCP to continue the call #28Select Route#29.
7. The Unique List SIB is used to form a modi#0Ced list from the list provided
by the previous Translate SIB. The input to this SIB is CIDFP 5andthe
output is a unique-elements list CIDFP 6.
8. The Multiple SCP SSP Session SIB contacts the RPCUs in this unique
list to get the bandwidth availibility in the speci#0Ced RPs in its control.
The message is the Monitor Resource message to inquire about bandwidth
availabilityatthe RPCU. The inputs to this SIB are:
#28a#29 CIDPF:the message to be sent to the RPCU.
#28b#29 CIDPF:The list of the RPCUs #28with the cell ids#29 to be contacted
#28CIDFP 6#29.
The responses obtained fromthe SSPs are pointed to by the output pointer:
CIDFP 7. An AIN0.1 SCP has the capabilities to monitor resources. This
enables the SCP to request the switching system to monitor the busy#2Fidle
status of a particular line and re#0Dect changes.
9. The User Interface SIB conveys this message #28CIDFP 7#29 to the ambu-
lance. The SCP sends a #5Csend to resource" message to the switch system
to have the IP play an announcement. The SSP connects the ambulance
to the IP via SSP-IP ISDN interface. The inputs to this SIB are:
39
#28a#29 SSD-Activity #28play announcement#29.
#28b#29 SSD-Announcement Indicator.
#28c#29 CIDPF-Location of announcement parameter. #28CIDPF 7#29
#28d#29 CIDPF-Location of collected information #28NULL#29.
The control returns to the BCP at the Select Route PIC.
Now, that the O SSP and the T SSP know how many channels are needed
for connection, they setup a standard ISDN call on all these channels.
3.6 Best-Path Service
In this section, we describe another service, that is more complex than the
previous but provides a better result. This service #0Cnds the best path for an
ambulance, that is, a path with the best combination of distance and bandwidth.
The Information Flow for this service is similar to Figure 3.3.
3.6.1 Service Logic Program
The following are the SIBs executed in the order given, to perform the logic for
the service.
1. Screen: This SIB verify that the calling party #28the ambulance#29 subscribes
to the service.
2. User Interface: This SIB connects to the user, and obtains the logtitude
and latitude of its location and the phone number of the hospital.
3. Translate: This SIB translates the hospital phone number to its longitude
and latitude information, using approriate tables. The table are supplied bythe
service logic.
40
4. Service Data Management: This SIB performs the Retrieve operation
twice to retrieve the graph of the part of the city lying in the rectangle enclosed
by the longitude-latitude of the ambulance and the longitude-latitude of the
hospital. The inputs, are the CIDFPs to the longitude-latitude information and
the database containing the city's map. The output is a list of the nodes and
the edges in the graph.
5. Translate: This SIB translates the names of the edges obtained from
"4" to the RPCU and cell ids covering those edges. The inputs are the CIDFPs
pointing to the list of edges obtained from "4" and the CIDFP pointing to the
table mapping the edges to the cel and RPCU ids. The output is a list of cell
and RPCU ids #28CIDFP 5#29.
6. Multiple SCP SSP Session: This SIB contacts all the RPCUs pointed
to by the CIDFP 5. The input is CIDFP 5 and a pointer to the message to be
sent to the RPCUs. The output #28CIDFP 6#29 is a pointer to the results obtained
from the RPCUs.
7. Adjust Edge-weight: This SIB is a HLSIB, which uses the Algorithm
SIB multiple times to adjust the weight of the edges. We use this SIB to manip-
ulate the weights of the edges in the graph, so that , the weight is a function of
the length #28time#29 required to traverse an edge, and the bandwidth available on
the edge. This function is a Cobb-Douglas production function of the form :
Weight = a
0
Distance
a
1
Bandwidth
a
2
Where, a
1
, and a
2
depend on the importance of Distance and Bandwidth.
The medic can decide the Marginal Rate of Substitution #28MRS#29 for the system
and using the MRS, the relative values of a
1
and a
2
can be determined. The
41
exact values are not required because the Weights will be used for comparison
between edges.
The Bandwidth value in the above equation, is the average bandwidth avail-
able on an edge, because, in real cellular systems that, an edge may be served
by multiple RPs and each RP has a di#0Berent amount of bandwidth available. If
any edge has no available bandwidth, on even a small portion of its total stretch,
the edge must be given zero Weight. Because, this means that the ambulance
will be dropped and it will have to redial. Redials are extremely costly, as the
new call has to go through the same process again, and must be avoided.
The output of this SIB is CIDFP 7, which points to the updated graph.
8. Translate: This SIB translates the longitude-latitude information of the
ambulance's position to the closest node. The output CIDFP 8 points to the
result node.
9. Translate: This SIB translates the longitude-latitude information of the
hospital to the closest node. The output CIDFP 9points to the result node.
10. Shortest Path: This SIB #0Cnds the shortest path between the nodes
pointed to by CIDFP 8 and CIDFP 9 in the graph pointed to byCIDFP7. The
output CIDFP 10 is a list of nodes and edges de#0Cning the path from ambulance's
present location and the hospital.
11. Translate: This SIB translates the edges in the path #28pointed to by
CIDFP 10#29, to the cell-ids and RPCU ids serving those edges. The output
#28CIDFP 11#29 is a list of cell ids and RPCU ids.
12. Multiple SCP SSP Session: This SIB sends a "reservation release"
message to the RPCUs in the list CIDFP 5andnot in the list CIDFP 11. This
will free the extra reservation done in step 6. Another way to achieve this goal
42
SCREEN
BCP
POI
POR
USER INTERFACE
TRANSLATE
SERVICE 
DATA MGMT.
Multiple
SCP_SSP session
TRANSLATE
SHORTEST
PATH
TRANSLATE
Multiple
SCP_SSP session
Clear Call (Select Route)()POR
(Analyze Info)
USER INTERFACE
TRANSLATE
TRANSLATE
ADJUST
EDGE-WEIGHT
ERROR
SUCCESS
Figure 3.5: The Service Logic Program
is to tell the RPCUs in CIDFP 11 that their services will be required and the
other RPCUs free their resources after a timeout. The downside of this approach
is that, if the connection between an RPCU #28in CIDFP 11#29 and the SCP goes
down the RPCU will not realize that its services are needed and will free its
resource after a timeout.
13. User Interface: This SIB sends the list CIDFP 11 to the ambulance.
43
3.7 Design Analysis
We have given a comprehensive description of the service architecture in the
last section. In this section, we analyze the design critically, and explain why
the new elements mentioned, are required. We also discuss other applications of
these elements and why they should be included in the standards.
The importance of the bandwidth information has been discussed before.
In the PACS standards, there is no provision for inter-RPCU signaling. An
Access Manager controls some functions in the RPCU but lacks access to RPCUs
beyond its domain. This is one very important reason whywe included IN in our
architecture. The signalling of IN makes possible such communication between
the SCP and RPCUs as required by the service.
In the current IN standards, there are only a few limited SIBs, and the
standards await #0Cnal decisions. The standards de#0Cne new modeling constructs
called, High-Level SIBs, which are "entities composed of SIB operations and#2For
other SIBs". These are like macros, and consist of one or more of the 16 basic
SIBs. The SIBs we proposed can also be viewed as HLSIBs and be constructed
by using the 16 basic SIBs. This construction, however, was found to be very
complex and a separate de#0Cnition was deemed essential.
The informationelements that our service architecture used, are not currently
available in their exact form. In the present standards, the SCP can request an
SSP to monitor a resource, and send information about the resource. But these
resources are usually, the telephone lines, or the peripheral equipment. For our
"wireless network" application, the resources are the frequency channels and the
TDM slots on these channels. So, a message format to request informationabout
a speci#0Cc channel and a slot must be devised. This message has other frequency
44
planning applications too.
The J-STD-014 standard for PACS, supports multislot priority calls. These
calls receive access even if all the channels are currently being used. The RPCU
can mark slots for priority users and can set information in the downlink broad-
cast channel for available services on eachchannel. This is crucial for our appli-
cation, where we require the RPCUs to reserve channels for the ambulance. If
all the tra#0Ec channels are busy, then a priority or emergency caller can commu-
nicate its request to the RPCU, through the uplink of the Systems Broadcast
Channel and gain access to a tra#0Ec channel.
45
Chapter 4
Evaluating Slot Allocation Schemes #28for
RPCU#29 and Queue Management
Schemes #28for Ambulance#29
In the earlier chapters, we developed the network architecture to provide the
telemedicine service over the terrestrial wireless loop. This approach can be eas-
ily modi#0Ced to serve other similar applications, where high bitrate data needs
to be exchanged between distant locations. By incorporating Intelligent Net-
works, wehaveachieved the signaling capabilitytoachieve the information #0Dow
required by the service implementation.
The introduction of the multislot capability at the RPCU raises a need for
optimal slot allocation schemes. There are two kinds of customers at the RPCU,
the single slot users, namely the normal telephone calls, and the multislot users,
namely,theambulance and other high data rate users. In this chapter we eval-
uate some slot allocation algorithms to optimize the slot allotment to the am-
bulance.
Presence of multiple sources of medical data at the ambulance and limita-
46
tions in its bu#0Bering capacity necessitates design of optimal queue management
algorithms #5B15#5D. We propose and evaluate some queue managementschemes for
the ambulance. The simulation results for these algorithms are obtained using
the Opnet simulation tool.
4.1 Slot Allocation at the RPCU
For the analysis of the slot allocation problem, we assume that the RPCU #28Fig-
ure 4.1#29 contains n frequency channels, eachcontaining c TDM slots. There are
be two types of users arriving in the system. The #0Crst type is a single slot user,
which is the common cellular phone call. The second type is a multislot user
which needs as many slots#28#14c#29asavailable. In this case, the ambulance trying
to send medical data, is a multislot user.
We study and simulate di#0Berent slot allocation algorithms. In these simu-
lations we assumed 8 channels each containing 8 TDMA slots. We chose these
numbers because the PACS air interface standard speci#0Ces the use of 8 slots
per channel, and each RPCU allocates approximately 8 channels per RP. Three
statistics of each algorithm are recorded and compared. The three statistics
chosen are:
1. The average number of slots allocated to the multislot users .
2. The blocking probabilityforsingle slot #28SS#29 users.
3. The blocking probabilityformultislot #28MS#29 users.
Our state diagram #28as implemented in Opnet#29 of this queuing system is
shown in Figure 4.2. It consists of #0Cve states: init,which initializes the queues
47
Multislot user
arrival
Departure of single slot
Departure of multislot user
No queues
Channel-1
"c" slots
Channel-2
Single slot user
arrival 
Channel-n
in each channel
user
Figure 4.1: RPCU Queuing System
and statistic vectors; arrival, which allocates slots to arriving calls decided by
the speci#0Cc algorithm; svc st, which initiates the service of the call; svc cpl,
which terminates a call; and idle, where the system waits for an event to oc-
cur. The arrows in the diagram de#0Cnes the transition relation between the
states. The transitions are : ARRIVAL, which indicates the arrival of a cus-
tomer;SVC COMPLETION,which indicates the end of a particular call; in-
sert ok, which indicates that an arriving call was successfully allocated chan-
nel#28s#29; and default, which indicates that no event took place.
The arrival processes are assumed to be Poisson and service rate #28 Table 4.1 #29
are assumed to be Exponential. The queue size is equal to the number of servers.
So, this is an M#2FM#2Fm#2Fmsystem #28where m =n#02c#29, except that the service policy
is di#0Berent from the conventional FCFS #28First Come First Serve#29. Hypothetical
48
init arrival
idle
svc_st svc_cpl
(ARRIVAL)
(default)
(insert_ok)
(default)
(ARRIVAL)
(SVC_COMPLETION)
Figure 4.2: State diagram for the base station queue
arrival rates are chosen to di#0Berentiate the performance of the algorithms and
are close to the real situation numbers.
4.1.1 Single slot users to busiest channel
In the simplest scheme, the single slot user is allocatedthe #0Crst availabletime slot
and the multislotuser is allocated all the free slots on the #0Crst availablefrequency
channel. This scheme can be made more e#0Ecient by allocating the single slot
user, a slot from the busiest channel, i.e., the channel that has maximum number
of busy slots and atleast one idle slot. The multislot user is allocated the channel
that has maximum number of free slots. The advantage of this scheme is that it
49
Arrival rate of Multislot users 0.2
Service rate for Multslot users 150#2F9.6
Arrival rate Single slot 2.5
Service rate for single slot users 2
Number of channels 8
Table 4.1: Arrival and Service Rates
concentrates the single slot users to a minimal set of frequency channels leaving
other channels relatively free for the multislot user.
This can be implemented by broadcasting the number of slots busy in each
channel on the logical broadcast channels, and allowing the single slot user to
choose the channel which is the busiest and contend for it. The same broadcast
message can be used by the multislot user to contend for the most lightly loaded
channel. In another approach, the mobile senses all the channels and chooses
the least#2Fmaximum loaded one without waiting for the base station to provide
this information. The callers are dropped when all the slots in all the channels
are busy.
The simulations results for this approach are shown in Figure 4.3. The #0Crst
plot indicates the average number of slots allocated to the MS over time. The
X-axis indicates the simulation time. The second plot shows the blocking prob-
abilityofa Single Slot #28SS#29 user. And, the third plot shows the blocking prob-
ability of a Multi Slot #28MS#29 user. We observe that and MS receives 6.78 slots
on a average for the arrival rates chosen. The SS users are blocked 2.4#25 of the
times and the MS users are blocked 2.3#25 of the times. The blocking probabili-
ties obtained above are close to the design objectives of the PACS radio system
50
Figure 4.3: Basic FIFO Algorithm
layout. Later, wevary the arrival rates and measure the same statistics to show
the e#0Bect of the arrival rates. This scheme converges in a short period of time
compared to the other schemes.
4.1.2 Reallocation of Single slots users
Another allocation algorithmis based on an optimal reallocationpolicy for single
slot users. Reallocation means moving a user from one frequency channel to
another. One such policy is to move a single slot user from the most lightly
loaded channel to a heavily loaded channel when amultislot caller arrives. This
wayamultislot user obtains more slots on the lightly loaded frequency channel.
51
The SS is not moved if no other channel has free slots.
Figure 4.4: Reallocation Algorithms
Reallocation is performed only if the number of busy slots in a lightly loaded
channel are below some threshold number. This threshold must be carefully
selected and some rule-of-thumbnumbers will be deduced from simulations. We
chose avalue of 6 for the threshold in our simulations.
The reallocation scheme involves using a unicast message from the Base Sta-
tion to the mobile user, instructing it to change its frequency channel and time
slot. The mobiles need the capabilitybuiltinto them to change their frequency
channels and time slot with minimum disturbance to the user.
The results for this approach are shown in Figure 4.4. The MS receives 6.85
52
slots on average. The SS users are blocked 4.0#25 of the time and the MS users are
blocked 4.1#25 of the time. The percentage increases because more slots are now
occupied by the MS users. The increase in the slots per MS over the previous
scheme is only 0.07. This makes the policy less appealing.
Reallocation is possible in the present PACS standard. RPCU can force a
user #28SS or MS#29 to change its RP to some other RP using the PERFORM ALT
message. ALT is Automatic Link Transfer, which is equivalent to a hando#0B from
one RP to another.
4.1.3 Multi-channel allotment
Instead of moving a single slot user to another channel, the multislot user can
send data on di#0Berent slots on di#0Berent frequency channels. That is, the multislot
user is allocated non-overlapping sets of slots on di#0Berent frequency channels.
The mobile switches between these frequencies within each 8-slot frame.
This system may be limited bythelatency in switching between frequencies
and the mobile might need to skip a slot when it is switching between the fre-
quencies. This allocation scheme increases the complexity for call setup between
the base station and the mobile. The mobile needs the capability to switch
between frequencies.
Identifying non-overlapping sets of slots on di#0Berent frequency channels was
acheived by using an n #02 c matrix. The rows indicate the channels and the
columns indicate the slots. The algorithm used was the folowing:
Step 1 The elements in the matrix were marked '0' for available slots, and
'-1' for busy slots.
Step 2 Start from the most idle row #28max. no. of '0's#29, all the free columns
53
Figure 4.5: Multi-channel Algorithm
in that row were marked '2', indicating that these slots will be allocated to the
MS.
Step 3 For each element marked '2' in Step 2, all the elements in the same
column of the other rows were marked '-1'.
Step 4 Steps 2and3were repeated till there is no '0' left in the matrix.
Step 5 All elements containing '2' are the chosen slots for the MS.
The results for this approach are shown in Figure 4.5. The MS receives 7.08
slots on average. The SS users are blocked 3.4#25 of the time and the MS users
are blocked 3.35#25 of the time. This scheme performed better than the previous
schemes because it made the best use of available time slots.
54
4.1.4 Dynamic Addition of slots
An addition to the previous schemes is a dynamic addition of slots to an existing
allocation. That is, during a multislot user's call, if a single slot user drops or
ends a call, that free slot can be additionally allocated to the multislot user. The
dropping SS must be on the channel currently used by the MS.
Figure 4.6: Dynamic slot addition algorithms
This scheme adds complexity to both, the base station and the mobile. The
multislot user must have an adaptive software to use the additional slot, and
generate more data. The base station must be able to add more B channels to
the hospital if required. The e#0Bectiveness of a new slot depends on how long
the ambulance is going to stay in that cell, and how much data is the mobile
55
generating at that particular moment.
The results for this approach are shown in Figure 4.6. The MS receives 7.83
slots on average. The SS users are blocked 7#25 of the time and the MS users
are blocked 6.8#25 of the time. Again, the increase in the blocking probabilityis
because the MS users are getting more slots on average leaving fewer free slots
for arriving MS and SS users. The tremendous increase in the slots per MS is
very promising. But, if we take into account the fact that the additional slots
are useful to the MS only if it receives them for a long enough period. If the
slots get freed as the MS is leaving the cell, the additional slot will not be very
useful.
The results shown in Figure 4.6 are for dynamic addition on the reallocation
policy. Dynamic addition on Multi-channel allocation is complex because the
RPCU must follow all the #0Cve steps mentioned in Section 4.1.3 every time an
SS leaves.
4.1.5 Reservation
A brute force method is to always reserve one frequency channel for multislot
users. This might lead to wastage of the precious resource #28bandwidth#29 if the
multislot calls are not frequent enough. So this decision depends on the fre-
quency, or arrival rates of such calls at a base station. If such a reservation is
used, the Intelligent Networks signaling will be required because, there will be
multiple multislot users in a city and the ambulance will need to know which
cells have the channels free and choose their paths accordingly.
In another approach, the base stations could request single slots users to
volunteer and release their slots. Some sort of incentive could be provided to
56
them. This is completely a business#2Fpolitical#2Fphilosophical decision.
Reservation can be acheived in the present PACS standard by commanding
the RPCU to mark a channel solely for priority or emergency users.
4.1.6 Conclusions
We observe from the graphs that the dynamic slot addition when combined with
the single slot user reallocation policy, gives the maximum number of channels
on average to the ambulance #28MS#29. But the complexity and hence time required
to allocate slots is higher than the simpler schemes.
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6
4.5
5
5.5
6
6.5
7
7.5
8
Number of slots
Inter?arrival rate for single slot users
Basic           
SS Reallocation 
Multichannel    
Dynamic addition
Figure 4.7: Comparison of schemes by varying the SS inter-arrival rates
When the simulations were run on a Sun Ultra 1, the excess time taken to
complete a simulation #28due to the dynamic slot addition algorithm#29 was 30 mins
for 50,000 arrivals. So, the di#0Berence in time for slot allotment per caller is 0.036
57
sec #28= 30*60#2F50,000#29. Since this di#0Berence in time is not signi#0Ccant compared to
the increase in average slots per MS, we believe that the RPCUs must implement
the dynamic slot addition scheme in conjunction with reallocation of single slot
user. The problem of latency in switching between frequencies makes the Multi-
channel allocation an undesired option; otherwise, it performs better than the
reallocation scheme.
0 2 4 6 8 10 12
2
3
4
5
6
7
8
Number of slots
Inter?arrival rate for multiple slot users
SS Reallocation 
Basic           
Multichannel    
Dynamic addition
Figure 4.8: Comparison of schemes by varying the MS inter-arrival rates
Figure 4.7 compares all these schemes #28in terms of average slots allocated
per MS user#29 when the inter-arrival time of the single slot user is changed. As
expected, the slots per MS user increases with decrease in the inter-arrival time.
The di#0Berence between the schemes becomes less noticeable at low arrival rates.
The dynamic slot addition scheme, however, remains at least 0.2 slots above
the rest at even reletively high inter-arrival times. Figure 4.8 compares these
schemes when the inter-arrival time of the multiple slot user is changed. The
58
results indicate similar trends as in Figure 4.7. All the schemes merge at low
arrival rates and become as good as the dynamic slot addition scheme.
We conclude that under low tra#0Ec conditions, the simpler techniques perform
as good as the more complex ones. So, the implementation should really depend
on the tra#0Ec expected at system deployment time. The RPCUs can switch
between the algorithms when the tra#0Ec changes.
4.2 Ambulance Queue Management
As discussed in Chapter 1, the ambulance has various types of sources, generating
data with di#0Berent arrival data rates. The data generated by these sources
must be transmitted on the slots that the mobile gets #28Figure 4.9#29. There are
several ways in which this can be achieved and eachhasitsown advantages and
disadvantages. Since the mobile typically has a very little amount of memory,
it must manage the queuing of its packets e#0Eciently. The schemes must also
be fair to low rate data, like heart beats and ECG. Some types of data sources
are less tolerant to losses than are others. For instance, heart rate must reach
correctly and no loss is tolerable. While an occasional loss of a packet may not
signi#0Ccantly a#0Bect the video and voice quality.
The mobile must have some mechanism to divide the data it is generating
into di#0Berent groups, each to be transmitted on one time slot. There are several
ways in which this can be done. Some of these algorithms are simulated in Opnet
and two statistics were recorded and compared, namely, the average delay per
packet and the packet drops per stream. The latter is done to estimate the
fairness of the algorithm with respect to the di#0Berent data streams.
59
TDMA Time Slots
1
2
3
4
5
6
7
8
1
2
3
4
5
6
7
8
S1
S2
S3
Sm
SOURCES
Queueing System
Figure 4.9: Mobile's Queuing System
There were assumed to be #0Cve di#0Berent types of sources, namely, Video,
Voice, ECG, Ultrasound and Data. The arrivals #28Table 4.2#29 are assumed to be
Poisson. The service rate is constant because each packet is assumed to be of
same size and is transmitted in one time slot. The number of time slots are
changed for every run of the simulation.
The state diagram of our queuing system model is shown in Figure 4.10. It
consists of #0Cve states: init, which initializes the queues and statistic vectors;
arrival,which enqueues the arriving packets decided by the speci#0Cc algorithm;
svc st which removes a packet from the head of the queue and transmits it; idle,
where the system waits for an event to occur; and clock,whichprovides a timing
mechanism for implementingthe TDM system. The arrows in the diagram de#0Cne
the transition relation between the states. The ARRIVAL transition indicates
60
the arrival of a packet from one of the sources. The TIMER INTRPT transi-
tion indicates that a timeslot has passed. We used one timeslot as a unit of time
to simplify the simulation implementation. The default transition occurs when
no other transition is enabled. The #28#28!QUEUE EMPTY#29&&#28#28clock#258#29 #3C
no slots#29#29 transition indicates that the queue is non-empty and the present
clock corresponds to a time slot that has been allocated to the MS. no slots
is the number of slots allocated to the MS and clock#258 is the slot number
at any given time instant. Though in reality, the allocated slots need not be
consecutive, we assume so in the simulation for simpli#0Ccation.
init arrival svc_st
clock
idle
(ARRIVAL)
((!QUEUE_EMPTY)&&((clock%8)<no_slots))
(TIMER_INTRPT)
(default)
(default)
(default)
(TIMER_INTRPT)
(default)
(ARRIVAL)
(TIMER_INTRPT)
((!QUEUE_EMPTY)&&((clock%8)<no_slots))
(ARRIVAL)
Figure 4.10: State diagram for the mobile queuing system
The algorithms studied are described in the following sections.
4.2.1 Single Queue without Priority
The mobile contains one queue and the packets generated from each source are
inserted into that queue. Whenever a time slot that has been allocated to the
61
Video 1#2F7
Voice 1#2F9
ECG 1#2F13
Ultrasound 1#2F8
Data 1#2F15
Table 4.2: Arrival Rates
mobile appears, it removes the #0Crst packet in the queue and transmits it. This
policy is unfair to the low bit rate applications. For instance, the heartbeat
packets #28low bit rate#29 may be dropped if the video packets #28high bit rate#29 have
clogged up the queue.
The results are discussed in Section 4.2.5.
4.2.2 Priority Queuing
In this system, the high priority data can replace the already existing low priority
data in the queue. The priorityofapacket is calculated as follows:
The priority is directly proportional to the waiting time of the packet. The
dependence is di#0Berent for di#0Berent data types. For example, the heartbeat
packet's priority increases faster with time than that of the voice packet. In
case of a full queue, an arriving high prioritypacket can replace a lower priority
packet at the tail of the queue.
The results for this and the previous schemes are shown in Figures 4.11, 4.12
and 4.13.
62
0 2 4 6 8
0
0.2
0.4
0.6
0.8
1
VOICE
P(block)
Number of slots
0 2 4 6 8
0
0.2
0.4
0.6
0.8
1
ECG
P(block)
Number of slots
0 2 4 6 8
0
0.2
0.4
0.6
0.8
DATA
P(block)
Number of slots
0 2 4 6 8
0
0.2
0.4
0.6
0.8
1
VIDEO
P(block)
Number of slots
PRIORITIES   
NO PRIORITIES
Figure 4.11: Results of Mobile Queuing system
4.2.3 One Queue per Slot
In this scheme, the queue management software maintains one queue per TDMA
slot that it receives. Since the amount of memory dedicated for bu#0Bering remains
the same in all these cases, we need to decide the capacity for each queue.
Intuitively, the system will be the fairest when the total arrival rate at any
queue is equal to the arrival rates at every other queue #28the service rate of all
the queues is the same#29. That is,
if S
i
= Set of sources pouring data into the queue of slot i.
X
i2S
1
#15
i
#18
=
X
i2S
2
#15
i
#18
= :::
#18
=
X
i2S
7
#15
i
63
1 2 3 4 5 6 7
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
ULTRASOUND
P(block)
Number of slots
PRIORITIES   
NO PRIORITIES
Figure 4.12: Results of Mobile Queuing system
The problem de#0Cnition is an optimization problem of the following nature:
There are n queues each of length L
i
, where i=1,2,...n.
And we need to design con#0Cguration of these L
0
i
s that minimizes
w
1
P#28block#29+w
2
#28Avg delay#29
where P#28block#29 is the probability of an arriving packet being blocked. This
optimization requires use of complex clustering algorithms, to group sources of
data.
This scheme become more complex when slots are dynamically added to the
ambulance during a call. The clustering algorithm must be run again and the
new clusters must be determined.
64
1 2 3 4 5 6 7
0
100
200
300
400
500
600
700
800
QUEUING DELAY
Delay(sec)
Number of slots
PRIORITIES   
NO PRIORITIES
Figure 4.13: Results of Mobile Queuing system
4.2.4 One Queue per data source
This scheme maintains one queue for every data source. In this case the issue
is to design the optimal round robin or similar algorithm for serving each queue
fairly. This system makes retransmission management more e#0Ecient, because
each source has its unique characteristics and some of them need retransmissions
and some do not. Some can tolerate retransmissions only within a time frame
and beyond that time, the packet becomes useless.
4.2.5 Conclusions
Figures 4.11 shows the blocking probabilities for Voice, ECG, Video and Data,
Figure 4.12 shows the blocking probabilities for Ultrasound, and Figure 4.13
shows the average delay that each packet su#0Bers.
It is observed fromthe graphs #28Figures 4.11, 4.12, 4.13#29 that the simplequeue
65
has smaller blocking probabilities than the priority queue for Voice, Ultrasound
and ECG. For Video and Data, the priority queuing scheme is better. The
di#0Berence between the performances of the two techniques becomes negligible
when more slots are available#28more than 5#29. The average delay per packet is
smaller in priority queuing, because a lot of the packets are dropped. Given
the importance of the Data source and its delay sensitivity, the priority queue
technique is preferred.
66
Chapter 5
Conclusions and Future Work
In the earlier chapters, we outlined the architecture for development and imple-
mentation of our service that provides high bandwidth connection to an ambu-
lance. We discussed several implementation aspects of the new modules designed
for this service. In this chapter, we identify the work that can be done in the
future to improvetheperformance of our system.
5.1 Contributions of the Thesis
This thesis proposed a network architecture toprovide wireless services intelemedicine.
The application is of an ambulance sending medical data #28video, ultrasound,
ECG, images, X-rays#29 of a trauma patient over terrestrial wireless channel to
the doctors on its way to the hospital. Research has indicated that transmission
of critical medical data to the doctors before the patient reaches the hospital,
increases the chances of the patients survival by 20#25. The ambulance needs a
high bandwidth wireless connection to the hospital to be able to transmit the
data. In case the bandwidth does not remain constant on its route, it needs to
knowinadvance the approximate bandwidth available to it after every hando#0B.
67
This information is used to schedule the transmission of data. For example, the
ambulance postpones transmission of video if it knows that it is going to receive
higher bandwidth later, or chooses between compression schemes. The ambu-
lance also expects the network to at least reserve the presently free bandwidth
for it and avoid new users from using that bandwidth. The ambulance needs to
know the best path from the patient's location to the hospital. The best path
must provide high bandwidth and take less time.
Presently, ambulances use multiple phones to obtain high bandwidth and
have no knowledge of future bandwidth availability. Because each phone makes
a separate connection to the hospital, the same data is sent on each line. The
ambulances choose the shortest path from the patient's location to the hospital
without knowing bandwidth availabilityonthat path. If the call gets dropped,
the phone contends for another channel till it receives one.
This thesis attempts to provide a new service to the ambulance with the
aid of Intelligent Network #28IN#29 architecture. IN was designed to make fast im-
plementation of new services possible. We design the service for a PACS and
IN based network architecture. Instead of designing a distributed algorithm,
where the RPCUs would communicate with each other to provide the service,
we choose IN, which has a centralized control. This choice avoids making ex-
pensive changes in all the RPCUs and uses the simpler IN service deployment
platform. Moreover, the centralized control obviates the problem of maintaining
relevant databases in each RPCU.
It is not possible to implement this service under the present PACS and
IN standards. The changes in these standards were identi#0Ced and addition of
each element was evaluated. We proposed the new Service Independent Build-
68
ing #28SIB#29 blocks required for this service. We proposed the information #0Dows
between the IN network elements. We designed two Service Logic Programs
#28SLP#29 for executing this service. Our new SLPs included detailed description of
the SIBs and the control and data #0Dow sequence. We proposed implementation
techniques for each SIB and propose a service independent implementation for
them. We proposed the relational database tables required and the queries they
must serve. Weevaluated our proposed changes in terms of their implementabil-
ity and complexity. New signaling procedures were suggested which attempt to
provide this service with minimum delay and load.
Presence of two kinds of users #28single slot and multiple slot#29 at the RPCU
raises issues of designing optimal slot allocation techniques. In the presentPACS
standard, the slot allocationsolely depends on whichchannel the mobileaccesses.
In this thesis, we proposed some novel slot allocation algorithms which maxi-
mize the bandwidth allocationfor telemedicine applications #28multiple slot users#29.
We evaluated these schemes through Opnet simulations for various arrival and
service rates. We discussed the complexity of each algorithm and suggested im-
plementation techniques for each. We measured the blocking probability for the
single slot and multiple slot users and the average slots allocated to a multislot
user under each scheme.
The ambulance must multiplex a variety of information sources to be sentto
the hospital. Each source has properties that make it unique. The ambulance
is limited by the bandwidth it receives from the RPCU and the memory it
possesses to queue packets waiting for transmission. We designed and evaluated
some queue management schemes at the mobile to optimally manage packets
from various data streams. The simulations were performed in Opnet for a
69
variety of data streams with varying arrival rates. We measured packet dropping
probabilities, and queuing delays for the packets under each scheme.
5.2 Service Architecture
An optimalprotocol needs to be de#0Cned between the ambulance and the hospital.
Since the data is critical and bandwidth limited; minimum overhead must be
used. The packet header should include data type, packet number, checksum.
The Mapping SIB must make use of dynamic tra#0Ec conditions on the streets
before #0Cnding the optimal route. These conditions should include construction
on the path, busy#2Fidle streets etc. The exact form of database structure to store
the SRF information must be studied further to improve query times, for the
queries generated bytheSCP.For instance, these databases can be implemented
in relational, or object oriented or many other forms.
5.3 Slot Allocation Schemes
The schemes evaluated in our work maximize the slots allocated to the ambu-
lance. This may not be the most preferred objective when it comes to optimizing
commercial systems where numerous other users are involved and all of them de-
mand higher bandwidth. An all encompassing optimization scheme will include
all types of users and their demands. We did not study such a problem in this
thesis.
70
5.4 Mobile Queue Management Schemes
Weevaluated two out of the four schemes outlined due to the complex algorithms
required in two of the other schemes. The exact priorities for each information
source is for further study. The optimal compression algorithms for each kind of
information source have not been discussed in our work. It is a topic of extensive
research as multimedia wireless services gain market importance.
71
Bibliography
#5B1#5D D. Kim, J. E. C. Jr., and Y. Kim, #5CNetworking Require-
ments and the Role of Multimedia Systems in Telemedicine,"
http:#2F#2Ficsl.ee.washington.edu#2Fprojects#2Fgsp9#2Fspie1095#2F.
#5B2#5D Y. Xiao, W. Gaasch, P. Hu, C. Mackenzie, and T. Stair, #5CTelemedicine
and Distributed Decision Making: The Thrill and Issues Beyond,"
http:#2F#2Fwww.hlfrp.ab.umd.edu#2Ftelemed.html.
#5B3#5D W. Cobb, #5CThe circuit Switched Solution to Cellular Data," SPIE Volume
2601#2F17, 1995.
#5B4#5D Technical Ad Hoc Group 3 of the TI#2FTIA JointTechnical Committee, Per-
sonal Access Communications System Air Interface Standard:J-STD-014.
Not generally available.
#5B5#5D W. Ambrosch, A. Maher, and B. S. #28Eds.#29, The Intelligent Network: A Join
Study by Bell Atlantic, IBM and Seimens. Springer-Verlag, 1989.
#5B6#5D Y.-B. Lin, #5CPACS Network Signaling Using AIN#2FISDN," IEEE Personal
Communications, June 1997.
#5B7#5D J. Norgaard and V. B. Iversen, Intelligent Networks and New Technologies.
Chapman and Hall, 1996.
72
#5B8#5D T. Hariu, J. Akiba, T. Kishida, and Y. Kondo, #5CStudy on Call Model of Ad-
vanced Intelligent Network for Controlling B-ISDN," IN Workshop , 1996.
#5B9#5D V. Carmagnola, M. Ferretti, and E. Scarrone, #5CAn integrated IN#2FB-ISDN
Reference Architecture for the support of Multimedia services," IN Work-
shop , 1996.
#5B10#5D T. Eckardt and T. Magedanz, #5CPersonal Communications Support based on
TMN and TINA Concepts," IN Workshop , 1996.
#5B11#5D K. Takami, H. Sekiguchi, T. Sugiyama, M. Honda, and I. Ushijima, #5CAn
Application of Advanced IntelligentNetwork Technology to Personal Com-
munication Services," IN Workshop , 1996.
#5B12#5D P. Csurgay, #5CService Creation and Deployment in an Intelligent Network
Laboratory," Master's thesis, Norwegian Institute of Technology, University
of California, Berkeley,CA94720,May 1987. Memorandum No. UCB#2FERL
M87#2F33.
#5B13#5D B. Ste#0Ben, T. Margaria, A. Claben, and V. Braun, #5CAn Environment for
the Creation of Intelligent Network Services," IEC: IN#2FAIN Technologies,
Operations, Services and Applications - A Comprehensive Report , 1996.
#5B14#5D T. H. Cormen, C. E. Leiserson, and R. H. Rivest, Introduction to Algorithms.
MIT Press, 1989.
#5B15#5D L. Kleinrock, Queuing Systems. Volumes I and II. John Wiley and Sons,
1976.
73