Global Interoperability of National Security and
Emergency Preparedness (NS/EP)
Telecommunications Services
Frank J. Suraci
Arye R. Ephrath
John R. Wullert II
Technical Director
Fellow, IEEE
Member, IEEE
National Communications System
Mythology, Inc.
Telcordia Technologies
Arlington, VA 22201
Clifton, VA 20124
Piscataway, NJ 08854
Abstract - Emergency telecommunications services, which
provide priority access to public telephony for those responding
to emergency situations, have previously been offered in the U.S.
and other countries around the world in the public switched
telephone network and more recently in cellular telephone
networks. This paper describes the implementation of these
national security and emergency preparedness (NS/EP) services
in a next-generation network (NGN) Internet-Protocol
Multimedia Subsystem (IMS) environment. The implementation
was tested during a global interoperability event. The tests'
results, and implications of the analysis of the test data to future
developments, are discussed.
I. I
NTRODUCTION
The Government Emergency Telecommunications Service
(GETS) was established in the United States in the mid-1990s
as a result of an Executive Order of the President [1]. The
purpose of this program has been to provide federal, state, and
local officials, as well as other authorized personnel associated
with national security and emergency preparedness (NS/EP)
with the means of obtaining priority in placing telephone calls
via the public switched telephone network (PSTN) during
times of emergency or when the telephone network is
otherwise congested.
In the wake of the terrorist attacks on the U.S. of 11
September 2001, the GETS program was expanded to include
a wireless priority service (WPS), whereby authorized NS/EP
callers may gain priority in accessing the cellular network and
placing priority calls by dialing a special prefix.
The GETS and WPS programs are managed by the National
Communications System (NCS) [2], an agency of the U.S.
Federal government. The NCS contracts with commercial
wireline and wireless telephony carriers to provide GETS and
WPS priority services on their networks. The NCS also
authorizes potential GETS and WPS users and issues each
user a unique personal identification number (PIN), which can
then be used to place priority telephone calls in a manner
similar to placing a calling-card call.
The priority of a GETS call in the PSTN is indicated by the
user through the dialed access number and signaled through
the network through the settings of specific parameters in
Signaling System 7 (SS7) set-up messages. High probability
of call completion of priority-signaled calls in a damaged or
congested telephone network is achieved through a set of
specialized treatments including routing calls to certain GETS-
enabled public carriers, queuing calls to overcome temporary
blocking situations, additional re-routing attempts to overcome
link damage or route congestion, and exemption from
restrictive network controls. In addition, SS7 signaling
message associated with GETS calls are themselves routed
with higher priority than are signaling messages associated
with non-priority calls.
The number of authorized GETS users has been growing
steadily; at present there are about 150,000 NCS-authorized
GETS/WPS users. GETS/WPS users include officials of the
federal, state and local governments, community and business
leaders, and first responders such as fire-fighters, medical
personnel and law-enforcement organizations.
In anticipation of the emerging migration of the public,
circuit-switched telephony networks to Internet-Protocol (IP)-
based packet infrastructure, the NCS embarked on an effort to
develop and implement priority capabilities in the packet-
network environment similar to the priority capabilities
currently available in the circuit-switched PSTN. These
efforts address not only voice telephony (thus extending the
existing GETS features into the new infrastructure) but also
take advantage of the high bandwidths and intelligent
terminals associated with these next-generation networks
(NGN) to define additional session-based priority
telecommunications services, such as video teleconferencing
over the managed public IP networks.
In recent years the NCS has been prototyping and analyzing
alternate network configurations designed to achieve its
objectives. These prototypes, based on existing and emerging
international standards and on commercially-available
networking equipment, have been used to test and demonstrate
several methods of authorizing and processing priority
sessions in the next-generation, IP-based network. The
remainder of this paper describes the priority features and their
implementation in these prototypes, the tests that the NCS
conducted along with 26 commercial vendors in the context of
a global, 3-continent, IP network, the results of these test and
the implications of the analysis of the test data to future
developments.
II. T
HE
N
ETWORK
The Internet-Protocol Multimedia Subsystem (IMS), defined
by the Third Generation Partnership Program (3GPP), is a
functional architecture for implementing connection-oriented
communication services over an IP network infrastructure. An
IMS communications network is divided logically into layers:
A communication service's payload (e.g., voice, video, text
messages) is transported via the transport or bearer layer;
end-to-end connections and sessions are set up in the signaling
or control layer; and service-specific logic and processing are
provided by the application or service layer. The separation
of the network into layers is only a logical one; the packets
and messages associated with the various layers in fact share
the network's physical resources.
Ensuring that NCS's priority NS/EP sessions have a high
probability of being established and maintained requires
special features in each of the network's layers: The authority
and identity of the originator of a priority session are verified
by an application server (service layer) prior to connecting the
session, the session is established with special priority features
(control layer) and the payload is transported with elevated
priority through the network (transport layer). The priority
functions of all three layers have been prototyped, tested and
demonstrated by the NCS. Some of this testing occurred
during a recent Global Interoperability test event sponsored by
the MultiService Forum (MSF) [3] that was designed to
demonstrate deployable, operationally-ready, end-to-end IP
services and networks.
The test event, known as "Global MSF Interoperability"
(GMI2006) event, brought together over two dozen network
equipment manufacturers and commercial carriers, and
spanned four major test centers (see Figure 1). The test
centers were located in the research laboratories of four global
telecommunications carriers (the UK's British
Telecom/Vodafone, Korea's Korea Telecom, Japan's Nippon
Telephone & Telegraph and the U.S.'s Verizon), with a fifth,
smaller test center provided in the U.S. by the Interoperability
Laboratory of the University of New Hampshire. The network
complied with the MSF R3 service architecture [4] which, in
turn, is compatible with the 3GPP IMS functional architecture.
Prior to the commencement of testing, the participants
developed a series of mutually-binding implementation
agreements. Based on established international standards, the
implementation agreements specified in detail the specific
functions and interfaces to be employed in GMI2006. The
overall results of the GMI event are described in a white paper
produced by the MultiService Forum [5].
III. TESTS AND
RESULTS
NCS prototyped and demonstrated several priority services
and features during GMI2006 under two overall scenarios: the
first scenario ("Scenario 2") represented a network where all
session participants were connected within a single network
domain, while the second ("Scenario 5") addressed delivery of
services to nomadic session participants roaming in network
domains other than their own service provider's.
NCS demonstrated the signaling of priority status during a
session's initial set-up, multiple methods of performing the on-
line authentication of the session originator's identity and
priority privileges, and the realization of priority treatment of
properly authorized sessions via preferential admission. These
were demonstrated for both telephony (priority voice) and
multimedia (priority video teleconferencing) services. In
Figure 1: Topology of GMI2006 Test Centers
High Capacity QoS Enabled
IP Global Test Network
addition, the NCS demonstrated the interoperability of priority
features between an IP-based IMS network and a circuit-
switched legacy network, as well as an "origination
identification restriction" (i.e., anonymity) feature. These tests
are described in more detail below.
A. Resource Priority
The session initiation protocol (SIP), the signaling protocol
used to establish communication sessions in IMS networks,
has been extended in 2006 to support a "resource priority"
header (RPH) [6]. The presence of a properly authenticated
RPH in SIP messages conveys a priority status and the need
for priority treatment in the establishing and maintaining
associated session. In addition, a standard mapping exists [7]
between the RPH in a SIP-based VoIP network and the
priority indicators in SS7 call set up messages in the circuit-
switched PSTN. As shown in the sample SIP message at
right, the terminal indicates the need to have RPH supported
with the SIP “Require” header and indicates the priority
requested using the “Resource-Priority” header with a
namespace (“ets”) and a corresponding value (“0”)
Several tests conducted by the NCS during GMI2006 were
designed to demonstrate the generation and inclusion of a
proper RPH in the signaling messages during the
establishment of a priority NS/EP session. In addition, the
behavior effected in network elements by RPH-carrying SIP
messages was verified, as the presence of an RPH is expected
to invoke specific actions in certain network elements, while
all network elements are expected to propagate the RPH
indicator downstream unchanged.
INVITE sip:6172802222@10.104.26.250:5060 SIP/2.0
SIP/2.0/UDP 10.80.2.10:5060; branch=z9hG4bK0dB0
From: "6172801111" <sip:6172801111@10.104.26.234>;
tag=gK0d0144c1
To: "6172802222"
<sip:6172802222@10.104.26.235:5060>
Call-ID: 17629360_1095@10.80.2.10
CSeq: 18585 INVITE
Max-Forwards: 70
Require: resource-priority
Resource-Priority: ets.0
Contact: "6172801111"
<sip:6172801111@10.80.2.10:5060>
Content-Type: application/sdp
Content-Length: ...
Of special significance is the fact that these tests were
conducted with commercial global equipment vendors, on a
test network comprised of commercial, standards-compliant
devices. The positive results of these tests enhanced the
NCS's confidence that the next-generation network will be
able to support NS/EP priority communications schemes.
B. Authorization
To ensure that the use of priority capabilities is restricted to
NCS-authorized users, users must be authorized prior to
session establishment. In the circuit-switched PSTN the user's
identity is authenticated via the touch-tone entry of a 12-digit
PIN; this authorization method, which must also be supported
in the IP-based NGN for reasons of backward compatibility,
was demonstrated during GMI2006. Earlier NCS testing had
demonstrated that the transport of digits as dual-tone, multi-
frequency (DTMF) audio signals over IP-based protocols
User
Equipment
Proxy
CSCF
Serving
CSCF
Data
SBG
Proxy
CSCF
Data
SBG
Parlay
Gateway
Parlay
AS
HSS
Bandwidth
Manager
User
Equipment
Media
Server
Signaling
Bearer
Figure 2: Partial MSF GMI Network Architecture indicating layering
Application Control Bearer
poses a special challenge since dropped packets (which can be
common in a congested network) can result in the corruption
of the transported digits at the receiving end. Specific means
to overcome this difficulty have been devised and
standardized [8].
Two additional authorization methods were demonstrated.
The profile-based method relies on the session originator's
profile, stored in the home subscriber server (HSS) in the
subscriber's home network, to verify the originator's identity
and privileges during registration, followed by validation
during call setup. In this method, the user terminal provides
an encrypted digest of portions of registration message
concatenated with the user ID and password. The application
validates the user by calculating the same digest and
comparing the results. In the challenge-response method, the
originator's intelligent terminal is challenged to provide
authorization data when attempting to place a priority call,
using HTTP digest authentication [9]. The challenge includes
an application-generated nonce as a security measure. The
intelligent terminal then creates the security digest based on
the message parameters, the nonce and the user ID and
password. This digest is processed by an application server to
authorize the user. This SIP messages used in this challenge-
response operation are illustrated in the upper highlighted
section of Figure 3.
All three authorization methods require the use of a
specialized GETS application which ran on a Parlay [10]
application server and was accessed via a Parlay gateway. All
three authorization schemes were demonstrated to function
successfully.
The Parlay gateway implements the Parlay programming
interfaces, a standardized set of APIs that provide protocol
independent control of capabilities used to construct
communications services. For the purposes of these
experiments, the Parlay Multiparty Call Control (MPCC) API
[11] was used to implement the authentication features and the
Parlay User Interaction API [12] was used to prompt the user
and collect digits for the in-band PIN scenarios. The SIP RPH
value was mapped onto the High Probability Completion field
in the MPCC API to communicate the priority information to
and from the application. The generic information fields
within the MPCC API were used to communicate the
information used to perform the digest authentication. The
application interacted with stored information (i.e., the
customer profile) to validate the user information submitted
either as touch-tones or SIP parameters and would then allow
or reject the call as appropriate.
Figure 3. Partial SIP signaling flow for priority video call using challenge-response authorization
Challenge-
Response
Authorization
Admission
Control with
Priority
C. Connection Admission Control
At the session set up layer, priority treatment is provided by
the policy decision function (PDF) at the network's border
gateways or by a "bandwidth manager" network element. As
the network's available bandwidth or other resources near
exhaustion, new session set-up requests for non-priority
sessions may be denied during an admission control process.
As demonstrated at GMI2006, however, the bandwidth
manager can utilize the value of the RPH parameter to
discriminate among set-up requests. In particular, as
illustrated in the highlighted section of Fig. 3, the RPH value
was translated from the SIP message to the Resource Priority
field of the DIAMETER-based bandwidth manager interface.
Alternatively, the bandwidth manager can interpret the RPH
value directly if the bandwidth manager is in the SIP signaling
path. The bandwidth manager is configured to assign a higher
priority to calls with an RPH value set. This higher priority is
then taken into account during the admission control decision.
Consequently, session set-up requests for NS/EP priority
sessions will be granted up to and beyond the capacity limits
defined for non-priority calls. During the testing, the
bandwidth manager was normal calls were established up to
the limit configured within the bandwidth manager.
Additional non-priority calls were rejected, while priority calls
were admitted.
More complex bandwidth management rules could limit
priority calls to a specific fraction of the available bandwidth
and/or to differentiate between priority calls with different
values set in the RPH field.
D.
Transport Priority
Priority treatment may be provided to data packets in the
transport layer in several ways, such as special markings of
each packet (which provides the packets with priority handling
at the network's routers), reserving a portion of each link's
bandwidth for priority traffic, or establishing separate,
reserved priority routes through the network. This priority
transport treatment must be provided not only to the bearer
packets which carry the voice, video, or data associated with
the service, but also (and perhaps more importantly) to the
packets which carry the signaling messages used to control
each priority session. This capability was not tested during the
current effort because the emphasis of the GMI event was
signaling interoperability; testing systems under load was not
part of the overall test plan. However, initial prototyping and
testing of transport priority had been the focus of an earlier
effort and are also planned to be investigated more thoroughly
in the near future.
E.
PSTN Interoperability
During the expected transition from circuit-switched public
telephony to the IP-based NGN, the two technologies will co-
exist and interoperate. In this hybrid environment it is
imperative that NS/EP priority services function seamlessly on
calls between circuit-switched and IP domains.
Interoperability implies that priority sessions which originate
in one domain and cross or are terminated in the other domain
maintain their priority markings and priority status. Signaling
and transport gateways between these two domains must
perform appropriate protocol mappings, including the priority
indicators, because priority is signaled via SS7 parameters in
the PSTN and via the SIP RPH in an IMS domain. The proper
mappings between SIP RPH and the corresponding SS7
messages were demonstrated during GMI2006 in both
directions (SS7 to SIP and SIP to SS7). For example, the
mapping rules from SS7 to SIP depend on the values of the
Called Party Number, the Calling Party Category (used to
indicate priority) and the precedence parameter (used to carry
priority level). The portion of mapping decision table (from
[7]) is included at the end of this paper.
F.
Video Teleconferencing
For the past decade, the GETS program has provided priority
in placing voice telephone calls via the PSTN. The ongoing
migration to the NGN infrastructure has provided the NCS
with an opportunity to develop and implement additional
session-based priority telecommunications services, such as
priority video teleconferencing.
The establishment of a priority video teleconferencing session
requires the proper authentication of the originator's identity
and privileges, in a manner similar to GETS's. One difference
is that a video conferencing terminal cannot be assumed to
have the capabilities to generate touch tone signaling, so the
in-band transmission of PINs was not tested in this case. The
priority treatment of video connections includes connection
admission control and transport priority. These were verified
and demonstrated by NCS at GMI2006. It should be noted
that the SIP call flows for voice and video sessions look nearly
identical; the sole difference is in the session description
protocol, contained in the body of the SIP messages that
describes the media types and codecs to be used for the
session.
Beyond the current testing, the establishment of a multimedia
priority session also presents additional options, such as a
trade-off in a congested, bandwidth-limited network between
the bandwidths allocated to the video and audio components
of the priority multimedia session. While the NCS has not yet
formulated a position on such additional options, various
alternatives have been considered. One approach is to
separate the bearer traffic associated with video from that of
audio, providing different priority levels to each. An
alternative is to adjust the allocation of bandwidth during
session establishment by controlling the selection of audio and
video codecs. While it might be assumed that the audio is
more important than the video, this is not true in all situations.
In-depth usability analysis is required to ensure that the
resulting system fulfills the communication needs of the
NS/EP user community. Future work will need to determine
the proper trade-off between the video and audio channels.
