ADAPTING AD HOC NETWORK CONCEPTS
`
`to LAND MOBILE RADIO SYSTEMS
`
`by
`
`Duncan Scott Sharp
`B.Sc.E.E., University of Alberta, 1972
`
`PROJECT SUBMITTED IN PARTIAL FULFILLMENT OF
`THE REQUIREMENTS FOR THE DEGREE OF
`MASTER OF ENGINEERING
`in the School
`of
`Engineering Science
`
`© Duncan Scott Sharp 2002
`SIMON FRASER UNIVERSITY
`December 2002
`
`All rights reserved. This work may not be
`reproduced in whole or in part, by photocopy
`or other means, without permission of the author.
`
`Apple Inc. 1018
`U.S. Patent No. 9,445,251
`
`

`

`
`
`
`
`
`
`
`
`
`Name:
`
`
`Degree:
`
`
`Title of project:
`
`
`
`Examining Committee:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Date Approved:
`
`Approval
`
`Duncan Sharp
`
`
`Master of Engineering
`
`
`Adapting Ad Hoc Network Concepts
`to Land Mobile Radio Systems
`
`
`
`
`
`
`
`
`Dr. Paul Ho
`Chair
`
`
`
`____________________________
`Dr. Ljiljana Trajkovic
`Senior Supervisor
`
`
`
`____________________________
`Dr. Joseph Peters
`Supervisor
`
`
`
`
`
`
`
`
`. December 9, 2002 .
`
`ii
`
`
`
`

`

`
`
`ABSTRACT
`
`
`Ad hoc networks are self-organizing networks of user terminals that form without the need for
`prior infrastructure. In theory, an ad hoc network could deliver adaptable, robust, and rapidly
`deployable communication services to meet the needs of public safety related agencies for
`emergency response and disaster recovery operations. In this project, I investigated the potential
`to develop a next generation land mobile radio system for public safety communications using ad
`hoc network architectures and concepts. I applied a four step methodology: (i) identify the
`communication requirements of public safety agencies in terms of the types of services, traffic
`characteristics, and quality of service; (ii) explore current technology and research relating to
`mobile ad hoc networks; (iii) conceptualize a design for a hypothetical next generation network
`by selecting approaches from the literature that should provide good results against the needs of
`public safety; and (iv) assess the potential performance of this hypothetical design. Among the
`many factors considered, the following four had a major influence on the design: (i) the dominant
`communication need is half duplex multicast voice; (ii) in most instances users have access to a
`vehicle; (iii) location information is becoming economically available through the Global
`Positioning System; and (iv) satellite-based mobile communications
`is available.
` The
`hypothetical network I propose is hierarchical with single hop "cluster nets" that are
`interconnected by a dominating-set based "backbone net". A satellite network tier simplifies
`routing across large geographic distances and provides a backbone of last resort for sparse
`networks. For the cluster net media access control, I applied the well known Packet Reservation
`Multiple Access protocol. The delay performance of this approach was investigated by applying
`genuine traffic traces to a software model of the cluster net. Before a complete terrestrial-based
`backbone net can be developed, further work is required; particularly in the area of multi hop
`routing. A central conclusion is that, although there are major challenges (e.g., spectrum, network
`self configuration algorithms, routing protocols, standards, and security), enough critical elements
`are available that prototypes and simple first generation systems can be built.
`
`
`
`
`iii
`
`
`
`

`

`
`
`Table of Contents
`
`
`Approval
`Abstract
`Table of Contents
`List of Tables
`List of Figures
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
`1
`Introduction
`2
`Operational Requirements for Public Safety Related Agencies.
`. . . . . . . . . . . . . . 3
`2.1 Missions, Agencies, and Groups of Users
`2.2
`General Operational Requirements and Context
`2.3
`Communication Services and Applications
`2.4
`User Terminals
`2.5
`Quality of Service
`2.6
`Network Management
`3
`Traffic Characteristics of Public Safety Networks
`
`3.1
`Voice Traffic Source
`
`3.2
`Traffic Analysis
`
`3.3
`Overall Voice Traffic Characteristics
`
`3.4
`Detailed Analysis of Call Holding Times
`
`3.5
`Detailed Analysis of Call Inter-arrival Times
`
`3.6
`Geographic Distribution and Mobility
`
`3.7
`Data Traffic
`. . . . . . . . . . . . . . . . . . . 31
`4
`Conceptual Design of a Hypothetical Ad Hoc Network
`
`4.1
`System Elements, Basic Organization, and Topology
`
`4.2
`Radio Frequency Spectrum
`
`4.3
`User Terminals
`
`4.4
`Addressing Scheme
`
`4.5 Media Access Control Protocol
`
`4.6 Multi Hop Routing
`
`4.7
`Network Management
`
`4.8
`Application Design
`
`4.9
`Conceptual System Design Summary
`
`. . . . . . . . . . . . . . . . . . . . . . . 11
`
`
`
`iv
`
`
`
`

`

`. . . . . . . . . . . . . . . 52
`
`Preliminary Feasibility of the Hypothetical Ad Hoc Network
`5
`5.1
`Performance Evaluation Scenarios
`
`5.2
`Connectivity Performance
`
`5.3
`Capacity Performance
`
`5.4
`Delay Performance
`
`5.5
`Cost Estimates
`
`5.6
`A Possible Phased Development Program
`
`Conclusions
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
`6
`Appendix A Selected Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
`Appendix B Primer on Ad Hoc Networks
`. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .67
`Appendix C Primer on Mobile Radio Systems
`. . . . . . . . .. . . . . . . . . . . . . . . . . . . . .83
`List of References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
`
`
`
`
`v
`
`
`
`

`

`
`
`List of Tables
`
`
`Table 2.1 Operational elements and basic terminology.
`Table 2.2 Typical voice service types.
`Table 2.3 Typical mobile data service types and applications.
`Table 2.4 Representative service level specification.
`Table 3.1 Relevant traffic data fields from the call activity detail and summary files.
`Table 3.2
`Summary of Vancouver system user count and channel capacity.
`Table 3.3 Average daily, average peak hour, and highest peak hour system traffic.
`Table 3.4
`Per unit traffic summary.
`Table 4.1 Addressing space build up.
`Table 4.2 Voice packet build up.
`Table 4.3
`Summary of the proposed ad hoc network system design concept.
`Table 5.1 Approximate radio ranges at 700 MHz and 4,900 MHz.
`Table 5.2
` Voice call delay build up.
`Table 5.3 Cost estimate comparison.
`
`
`
`
`4
`5
`5
`8
`14
`15
`19
`19
`39
`40
`50
`56
`60
`62
`
`
`
`vi
`
`
`
`

`

`
`
`List of Figures
`
`
`12
`Figure 3.1 Trunked mobile radio system concept diagram.
`17
`Figure 3.2 Average hourly traffic.
`17
`Figure 3.3 Hourly traffic averages for all Wednesday during the 51 day study period.
`18
`Figure 3.4 Hourly traffic averages for all Fridays during the 51 day study period.
`19
`Figure 3.5 Summary of daily traffic for all days of the week in the 51 day study period.
`21
`Figure 3.6 Frequency chart of the hourly traffic in Erlangs across the 51 day period.
`21
`Figure 3.7 Cumulative distribution of hourly traffic across the 51 day study period.
`22
`Figure 3.8 Frequency chart (histogram) of the number of talk.
`22
`Figure 3.9 Cumulative distribution of the number of talk groups.
`24
`Figure 3.10 Lag plot, call holding time (Tc) in seconds, 10 talk groups, 1 day.
`24
`Figure 3.11 Distribution plots, call holding time (Tc), all Vancouver system, 1 day.
`25
`Figure 3.12 Autocorrelation plot, call holding time (Tc), 10 talk groups.
`26
`Figure 3.13 Lag plot, call inter-arrival time (Ti) in seconds, chat talk group, 1 day.
`Figure 3.14 Lag plot, "inter-session" call inter-arrival time (Ti) in seconds, chat talk group,
`genuine traffic trace, 1 day.
`26
`Figure 3.15 Lag plot, "intra-session" call inter-arrival time (Ti) in seconds, chat talk group,
`genuine traffic trace, 1 day.
`27
`Figure 3.16 Lag plot, call inter-arrival (Tc) in seconds, 10 talk groups, 1 hour.
`28
`Figure 3.17 Distribution plots, call inter-arrival time (Ti), 10 talk groups, 1 hour.
`28
`Figure 3.18 Autocorrelation plot, call inter-arrival time (Ti), 10 talk groups, 1 hour.
`29
`Figure 3.19 Variance-time plot, call inter-arrival time (Ti), 10 talk groups, 1 hour.
`29
`Figure 4.1 Global view of the system elements and how they form into a logical hierarchy. 32
`Figure 4.2 Example of user and group spatial distribution.
`32
`Figure 4.3 Overview of major system elements.
`33
`Figure 4.4 Network hierarchy for scalability in size (number of nodes) and span (physical
`distance across).
`34
`Figure 4.5 Time slot concept for the cluster access network (cluster net).
`41
`Figure 4.6 Hexagonal grid based reuse plan.
`43
`Figure 5.1 Probability of network connectivity .
`56
`Figure 5.2 Comparison of the channel set up delay performance.
`59
`
`
`
`vii
`
`
`
`

`

`
`
`Chapter 1
`Introduction
`
`
`Geographically distributed teams involved in real-time operations typically coordinate their work
`using mobile radio. Messages are often broadcast (multicast) among the team, and when a
`situation is changing rapidly and real-time reactions between team members becomes critical,
`voice calling dominates. Typically, these work groups are involved in public safety operations
`(e.g., police,
`fire,
`rescue, and ambulance agencies), utility operations
`(e.g., electric,
`telecommunications, and pipeline networks), and other team operations (e.g., construction sites,
`special event coverage, emergency response, and disaster recovery). A characteristic of many of
`these applications is that operations tend to be sporadic, with high activity for a period of time in
`an area, then no activity for an extended period.
`
`Ad hoc networks are self organizing networks of user terminals. The user terminals form the
`infrastructure. Because these networks are self organizing, they have the potential to be
`adaptable, robust, and fault tolerant. Because no prior infrastructure is needed, a network can be
`rapidly deployed. These characteristics are an excellent fit for pubic safety, emergency response,
`and disaster recovery communication applications.
`
`Currently, the communication needs of public safety related agencies are met by land mobile
`radio systems. This technology has changed slowly over the past three decades and tends to lag
`commercial cellular telephone technology by at least a decade. In addition to cellular and ad hoc
`network technology, other potential enabling technology for future land mobile radio systems
`includes satellite based mobile systems (e.g., MSAT, Iridium, and Globalstar), 3rd generation
`cellular developments, adaptive antennas, software defined radios, the Internet, mobile, and
`pervasive computing, Global Positioning System (GPS) receivers, and high-powered, compact
`Personal Digital Assistants (PDAs). In particular, the availability of low cost GPS receivers has
`stimulated its use for navigation support and to support location-aware applications.
`
`This report consolidates the findings of my investigation into the potential for next-generation
`mobile radio systems to exploit recent advances in mobile ad hoc network technology.
`Specifically, the objective of the project was to identify evolving technologies, algorithms,
`protocols, and architectures for mobile ad hoc networks that may be adopted by next generation
`- 1 -
`
`

`

`land mobile radio systems – and, in particular, by mobile radio systems designed for public safety
`communication applications.
`
`The report follows the general sequence of the project. Chapters 2 and 3 present a needs analysis
`for public safety mobile communications covering operational requirements and
`traffic
`characteristics, respectively. Chapter 4 hypothesizes a system design based on current approaches
`from the literature and covers radio channel, media access, routing, and network management
`aspects. Chapter 5 is a preliminary feasibility assessment of the hypothetical system design.
`Chapter 6 concludes the report with a synopsis of the findings. Appendix A lists selected
`terminology used in this report. Appendix B and C are primers on ad hoc networks and land
`mobile radio, respectively.
`
`Interest in radio based ad hoc networks extends back to the 1970's. Development languished
`somewhat in the 1980’s; partly because we lacked the low cost processors and memory needed to
`run algorithms for ad hoc routing. Since about 1995 interest has been rekindled. The reference
`list in this report is a small sample of the vast and rapidly growing literature. Throughout the
`project, I drew heavily on this extensive literature base. References to specific source material
`are made throughout the text. Although I hesitate to highlight one reference, the "Handbook of
`Wireless Networks and Mobile Computing", edited by I. Stojmenovic, was an inspiration and a
`broad source of recent and highly relevant information from many contributors to the field
`[Stoj02].
`
`This project contributes to the subject by focusing on a specific application (public safety
`communications) and drawing together a synopsis of the current state-of-the-art as it applies to
`this application. The synthesis of an example design and the assessment of its potential
`performance illustrates what is achievable today as well as where more work is needed. In
`addition, during the course of the project, some potentially useful work on characterizing
`multicast voice traffic was undertaken. The report could also provide a starting point for research
`topics or product development studies relating to ad hoc networks.
`
`
`
`
`
`
`- 2 -
`
`

`

`
`
`Chapter 2
`Operational Requirements for Public Safety Related Agencies
`
`
`This chapter and Chapter 3 (on traffic) provide an analysis and characterization of the needs of
`public safety related agencies for mobile radio communications. These two chapters establish the
`requirements for the system design described in Chapter 4.
`
`2.1 Missions, Agencies, and Groups of Users
`
`Various organizations are deployed, generally by government, to protect the public against threats
`to life, safety, and property damage. These agencies include police, fire, rescue, and ambulance.
`Effective and efficient response to public safety incidents requires the coordination of teams.
`Without adequate communications, the initial response to a situation, and the ongoing response as
`the situation changes, is neither effective nor efficient.
`
`Within the overall role of public safety, each agency has a specialized mission to accomplish,
`usually across a defined jurisdiction or geographic area. This mission, and the context within
`which it is accomplished, gives rise to different operational support and communication needs.
`Notwithstanding these differences, in the event of a large scale event (e.g., an earthquake or wild
`fire that affects a wide area), communication is essential within teams, and between teams. These
`teams may be in the same or different agencies, or with external groups including utilities (e.g.,
`electric power, gas and telecommunications) and the military. The importance of this
`communication inter operability for joint operations and mutual aid cannot be overemphasized.
`
`For the purposes of this project, the “users” can be defined as comprising agencies, each with one
`or more user groups, populated by individual users that are equipped with user terminals. Slightly
`more formal definitions appear in Table 2.1.
`
`
`
`
`
`
`- 3 -
`
`

`

`
`
`Term
`Agency
`Groups
`
`Table 2.1
`Operational elements and basic terminology.
`Description
`A single administration comprising one or more user groups or teams.
`Teams or work groups (usually corresponding to multicast or talk groups)
`whose membership may grow or shrink as users come and go and/or
`subdivide or merge depending on activities.
`A common voice channel where the above groups can coordinate their
`operations (functionally similar to a party-line or chat-line).
`Individual users that generate and absorb information (i.e., traffic sources and
`sinks); each user has one or more user terminals.
`User terminal A communication device that includes as a minimum a radio transmitter and
`receiver (transceiver) and some user interface (e.g., handset/headset,
`keypad, and displayed).
`
`Talk group
`
`Users
`
`
`
`2.2 General Operational Requirements and Context
`
`In all instances, work forces are mobile. Work is spatially distributed including indoors and
`outdoors, and may be dangerous from natural or man-made causes. Response must be rapid and
`in all types of weather. Although users are vehicle borne, they often work outside the vehicle.
`The work will generally involve handling tools and/or weapons. The form factor of user
`communication terminals must consider this, and terminals must also be intuitive and easy to use
`as users may be distracted by the tasks at hand as well as by risk and stress. Not all work will be
`urgent; there will also be periods, often long periods, when mainly routine work is undertaken.
`
`Although users may be geographically dispersed, command-and-control will usually be
`centralized. This centralization may be to one or to a hierarchy of points – e.g., a dispatch room
`or a local command post and/or emergency operations center. Information on the location and
`disposition of users and equipment is often vital to optimize the deployment of available
`resources.
`
`Communications security is important. Obviously, protection against unauthorized usage and
`disruption of communications, including denial of service attacks, is essential. In many instances,
`security of information to prevent eavesdropping is required (e.g., through encryption).
`
`
`
`- 4 -
`
`

`

`2.3 Communication Services and Applications
`
`Communication services can be divided into voice and data. In general, voice communication
`takes priority over data. The types of voice and data communications are identified and briefly
`described in Table 2.2 and Table 2.3, respectively.
`
`
`Table 2.2
`Typical voice service types.
`Description
`A call on a user selected talk group (channel) that is heard by all
`users that have that talk group selected.
`A call to all users in an Agency – i.e., all talk groups operated by the
`specific agency.
`A call amongst all agency or system users in a defined geographic
`area.
`A group call in a talk group or channel that has been designated for
`joint operations or mutual aid between agencies.
`A call between any two users, or between a user and another
`network (e.g., the public switched telephone network).
`A call, invoked by pressing the "emergency" call key that results in a
`channel opening immediately to a monitoring point (e.g., dispatch),
`the identity (and, if possible, location) of the user is forwarded, and
`the radio unit microphone opens for a preset time.
`A key on suitably equipped or configured radio units that, when
`invoked, signals the dispatcher of a request. Once invoked, the
`request is queued until answered.
`
`Application
`Group Call
`
`Agency Call
`
`Zone Call
`
`Inter-agency Call
`
`Individual Call
`
`Emergency Call
`
`Request to Talk
`
`
`
`
`Application
`Status Messaging
`
`Instant Messaging
`
`Short Message
`Service
`
`E-mail
`
`Paging
`
`Computer Aided
`Dispatch
`
`Fleet Management
`
`Table 2.3
`Typical mobile data service types and applications.
`Description
`A remote (field) user forwards one of a set of predetermined
`("canned") messages to a dispatcher or host application (often
`relating to user status – e.g., enroute, on-site)
`Short text exchanges between users that can be held in near real
`time.
`A short text message that is prepared then sent between users;
`similar to e-mail but limited to a maximum message size (e.g., 140
`characters).
`The exchange of e-mail messages, including attachments, between
`users in the field and/or corporate and/or public e-mail systems.
`One way messaging – often to alert or inform a specific user or
`group of users (e.g., advise of an alarm condition).
`A type of host application that ranks, formats and delivers
`information required by field personnel to perform specific tasks
`(e.g., respond to incidents, pick up loads).
`A set of applications that involve monitoring, and in some instances,
`remotely controlling vehicle functions.
`
`- 5 -
`
`

`

`Information Query
`and Retrieval
`Reporting
`
`Automatic Vehicle
`Location
`Mobile Office
`
`Image
`
`Video
`
`A host application that may include data base access, web
`browsing, and operating procedure look-up.
`Host applications that allow field users to remotely update
`databases or reports and file information.
`Used for asset tracking, navigation support, personnel safety and
`other applications requiring or benefiting from location awareness.
`Word processing, spreadsheets, remote file transfers, Internet
`access, and other office type applications.
`The transfer of medium and high resolution images; often from a
`central point to a remote (field) user.
`Slow scan or full motion video; often from the remote (field) user to a
`central dispatch or command point.
`
`
`Important features for voice and/or data communication include the following:
`§ Provision of priority levels (e.g., head of queue and/or ruthless pre-emption)
`§ The ability of the dispatch or command point to preempt a call
`§ Security – including authentication to prevent unauthorized service access and
`encryption to prevent unauthorized message interception
`§ Caller identification (caller ID)
`§ Recording of communications for debriefing, training and legal purposes
`§ Inter operability (communication between agencies)
`§ Voice performance in high noise environments (this is also a terminal issue)
`§ Ability to guarantee delivery and to know about late delivery (knowing who received a
`message and when, and who did not receive it)
`§ In general, status messages are short and high priority and should be combined with
`position reports
`§ Provision for remote radio signal strength check capability
`
`
`All voice applications (Table 2.2) are in widespread use over land mobile radio systems. Many of
`the data applications (Table 2.3) are in general use over private and public data radio networks,
`with the exception of video which is inhibited by the lack of spectrum and equipment. Note that
`group calling is the dominant mode of communication. These calls are half duplex as the call
`originator (source) activates a push to talk key for the duration of the transmission (talk spurt or
`call).
`
`
`
`
`
`
`- 6 -
`
`

`

`2.4 User Terminals
`
`The ultimate success of a communication system is absolutely dependent on how the user
`interfaces with the service. This interface is the user terminal. Generally, all user terminals
`should have the following characteristics:
`
`
`§ Rugged and capable of reliable service under heavy-duty industrial and public safety
`operations
`§ A minimum number of easy to understand and operate controls
`§ Easy to read and understand displays (including in low light and bright sunlight
`conditions)
`§ Integral radio signal strength indication (RSSI)
`§ Compact and lightweight
`
`
`Although ideally in an ad hoc network, every terminal has equal capabilities, this is not an
`essential condition, nor even desirable, in the context of public safety operations. As a minimum,
`I expect there will be five types of user terminals, as follows:
`
`
`§ Personal Radios: User terminals carried (or worn) by personnel and forming the primary
`field user interface.
`§ Vehicle Radios: Vehicle mounted user terminals that are normally interfaced through
`the Personal Radio but also need provision for direct user interface.
`§ Transportable Radios: User terminals that are self contained and intended for
`unattended operation at locations to supplement connectivity.
`§ Fixed Radio: User terminals that are intended for fixed location installation to provide
`access to the network (e.g., at dispatch and operations centers), to interface with other
`networks (e.g., gateways), and in some instances, to supplement coverage.
`§ Control-point Radios: User terminals that have added capabilities to support resource
`management functions covering both field resources (personnel, vehicles, equipment)
`and network resources (i.e., for dispatch/command purposes and for communication
`services management). This would be a split or two component device that allows
`mounting the radio unit separately from the interface (console) unit.
`
`
`
`- 7 -
`
`

`

`The Personal Radios require long battery life – at least 12 hours, and preferably days, under
`normal duty cycles. In standby mode, weeks between charging is desirable. Charging procedures
`and equipment should be simple and foolproof. The Personal Radio needs to be provided with a
`range of accessories to facilitate different operational modes (e.g., for motorcycle and snow-
`mobile users). Vehicle Radios should be modular, easy to install and de-install, and relatively
`energy efficient. Control-point Radios will feature a computer workstation-like interface to
`support various operational and network management applications (e.g., mapping and dispatch
`per Table 2.3 above and per Section 2.6 below).
`
`Finally, user terminals should be available in tiers with different levels of packaging and
`robustness to enable various user group needs to be economically met, including, for example: (i)
`low tier for lower cost, less demanding user groups, (ii) high tier for heavy-duty use by user
`groups with bigger budgets, and (iii) intrinsically safe units for use in hazardous environments.
`
`2.5 Quality of Service
`
`In general terms, communication systems must provide timely, accurate and dependable voice and
`data message delivery. Table 2.4 provides a reference service level specification. These metrics
`are from the users perspective.
`
`
`
`Table 2.4
`Representative service level specification.
`These metrics apply during expected operational busy periods and within the operations area.
`Service level specifications should also stipulate how each metric is measured.
`Metric
`Definition
`Performance
`Network
`Probability of having connectivity to
`At least 97% per [TIA96] and
`Availability
`workgroup and/or incident or agency
`preferably 99% of locations
`
`control (dispatch) point.
`Service
`Probability that the network has
`Availability
`sufficient capacity to carry offered
`traffic.
`Probability at any given time that a user
`terminal with a charged battery is
`capable of operating to specification.
`Probability that set up time will NOT
`exceed 1 second.
`
`Network capacity shortfalls are
`manifested as set-up delay. See
`metric 4.
`At least 99.95% (e.g., 3 years
`mean time between failure and
`12 hours mean time to replace).
`At least 99.9% for priority traffic.
`At least 97% for non priority.
`
`User
`Terminal
`Availability
`Session Set-
`up Delay
`
`#
`1
`
`2
`
`3
`
`4
`
`- 8 -
`
`

`

`5 Message
`End-to-end
`Delay
`
`Probability that end-to-end delay from
`source user terminal to destination user
`terminal will NOT exceed (a) 600 ms for
`voice and high priority data messages;
`(b) 5 sec for other messages.
`
`
`At least 99.9% for high priority
`talk groups and data messages.
`
`At least 97% for other.
`
`6
`
`7
`
`Voice
`Fidelity
`
`Position
`Accuracy
`
`Probability of having to repeat a
`message due to poor fidelity (i.e., a
`distorted and/or incomplete message).
`Probability that a location fix is more
`than some amount in error or is stale.
`
`At least 97% and preferably 99%
`of locations (relates to voice
`codec and packet loss ratio).
`Requirements are application
`specific; to be determined.
`
`
`It should be noted that packet loss ratio is also an important metric. However, from the user's
`perspective, packet loss manifests itself as (i) delay for non real-time applications where the
`transport protocol assures delivery (i.e., through a repeat request procedure), and (ii) fidelity or
`data integrity for real-time applications (e.g., for voice or high priority, time-sensitive data).
`
`2.6 Network Management
`
`Agencies and/or user groups must be able to configure the services within network limits and
`within the bounds of fairness to other users. Configuration changes could include, for example,
`the following:
`§ Talk group configuration including priorities and membership rules
`§ User terminal configuration (e.g., interface preferences)
`§ Remote enable and disabled user terminals
`§ Remote (over-the-air) reprogramming
`
`
`The system must have provisions for security and to detect malicious, fraudulent or unauthorized
`use. At some level, there should be access to various system support and network management
`functions including:
`§ Alarm and trouble reports
`§ Remote diagnostics
`§ Performance monitoring
`§ Configuration monitoring, statistics and reports
`§ Traffic monitoring, statistics and reports
`
`
`
`- 9 -
`
`

`

`Ideally, and perhaps essentially, user equipment will be available from multiple manufacturers.
`The equipment must be warranted and supported by the supplier including user documentation,
`training and repair/replacement capability.
`
`- 10 -
`
`

`

`
`
`Chapter 3
`Traffic Characteristics for Public Safety Networks
`
`
`This chapter summarizes the methodology and results of analysis undertaken during the project to
`characterize public safety mobile radio voice traffic. This was necessary because information on
`this traffic is not well represented in recent research literature. Earlier work is available [Hess81],
`[Cohe83], [Heer92], [Hess93], and [Ston96], but it is based on non-trunked (conventional access)
`radio and trunked radio systems operating in message trunking mode (the channel is held for the
`duration of a message exchange session and not released after each talk spurt).
`
`3.1 Voice Traffic Source
`
` I
`
` obtained real traffic data from E-Comm, a large public safety mobile radio network operator. E-
`Comm serves public safety agencies in the lower mainland of British Columbia with an "EDACS"
`system from M/A-Com (formally Comnet-Ericsson).
`
` A
`
` trunked mobile radio system, such as E-Comm’s, consists of a central system controller,
`repeater sites, fixed user sites (e.g., dispatch locations), and user radios. User radios include both
`portables and mobiles (i.e., hand-held and vehicle mounted radio units, respectively). The system
`elements are shown in Figure 3.1.
`
`Each repeater site has a control channel and several working or traffic channels – typically up to
`20 or 30 channels. Obviously the number of channels required depends on the traffic load and
`desired quality of service. Each repeater site typically covers a radius from one to over 25
`kilometers, depending on traffic as well as terrain and propagation issues. To provide wider area
`coverage, additional repeater sites are used.
`
`
`
`
`- 11 -
`
`

`

`
`
`
`
`Repeater Site
`Antenna
`
`Channels
`
`Dispatch
`Location
`
`Site Controller
`
`Repeater
`Site
`
`Repeater
`Site
`
`Network
`Management System
`
`System
`Controller
`
`User
`Radios
`
`Repeater
`Site
`
`Repeater
`Site
`
`System
`Coverage
`Area - A
`
`Area - B
`
`Figure 3.1
`Trunked mobile radio system concept diagram.
`
`
`Similar to other large scale trunked radio systems, the E-Comm system is divided into several
`coverage subsystems. Although all subsystems form a part of the overall system and are managed
`by a central controller, each subsystem forms a separate pool of channel resources for traffic
`purposes.
`
`Users wishing to communicate with others in their work group must have their radios set to the
`appropriate "talk group". Then, when the user presses the push to talk (PTT) key on their radio, a
`signal is sent over a control channel to the central controller. The central controller looks up all
`other units that have selected the same talk group and it verifies that there are channels available
`on all required repeater sites. The central controller then assigns a channel on each repeater site
`that is needed for the call and signals every radio in the talk group to tune to the appropriate
`repeater frequency for the call.
`
`Assigning and setting up a channel takes typically 500 milliseconds, after which the caller can
`begin talking. The call is received by all radios on the talk group that are within signal coverage.
`When the PTT key is released, the central controller releases the channel at each repeater site. If
`no channels are available, then the PTT request is put in a queue and served on a first-in-first-out
`- 12 -
`
`

`

`(FIFO) basis within each priority level. In some systems, including E-Comm's, recent "talkers"
`may be given priority over new calls to insure low delay to existing call sequences during
`conges