NINETEEN NINETV-SIX
`
`5
`
`MILCOM 96
`
`Conference Proceedings
`
`Volume 3 of 3
`
`Volume 1
`
`Tuesday, October 22
`
`Sessions 1 through 14
`
`Volume 2 Wednesday, October 23 Sessions 15 through 28
`
`Volume 3
`
`Thursday, October 24
`
`Sessions 29 through 41
`
`MILCOM 96 is sponsored by the IEEE Communications Society and the
`Armed Forces Communications and Electronics Association. Security for
`the classified sessions is sponsored by the Department of Defense.
`
`lllllliillll
`
`
`
`Conference facilities are provided by the McLean Hilton Hotel and the MITRE Corporation.
`i
`
`RPX Exhibit 1229
`RPX Exhibit 1229
`RPX v. DAE
`RPX V. DAE
`
`

`
`MILCOM 1996
`
`Copyright and Reprint Permission: Abstracting is permitted with credit to the source. Libraries are permitted to photocopy beyond
`the limits of U.S. copyright law for private use of patrons those articles in this volume that carry a code at the bottom of the first
`page, provided the per—copy fee indicated in the code is paid through the Copyright Clearance Center, 222 Rosewood Drive,
`Danvers, MA 01923. For other copying, reprint, or republication permission, write to IEEE Copyright Manager, IEEE Service
`Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331. All rights reserved. Copyright © 1996 by The Institute of
`Electrical and Electronics Engineers, Inc.
`
`IEEE Catalog Number
`
`96CH3 6008
`96CB36008
`
`Library of Congress Number
`ISBN - Softbound
`ISBN —— Casebound
`Microfiche
`
`96-78416
`0-7803-3682-8
`0-7803-3683-6
`0-7803-3684-4
`
`Additional copies of this publication are available from
`
`IEEE Service Center
`445 Hoes Lane
`P.O. Box 1331
`
`Piscataway, NJ 08855-1331
`
`1-908-981-0060
`1-800-678-IEEE
`
`1-908-981-1721 (FAX)
`
`

`
`This material may be protected by Copyright law (Title 17 U.S. Code)
`
`

`
`protocols and technology. The network
`connectivity provided by these research
`projects consists of low data rate, radio
`frequency (RF) communication links.
`Both
`projects made
`use
`of
`connectionless, packet switched routing
`and data delivery protocols. CSNI
`utilized the International Standard
`
`Organization (ISO) Connectionless
`Network Protocol (CLNP) stack and the
`NRL DVI ATD used the TCP/IP protocol
`stack.
`
`Some experimental and commercially
`available computer applications have been
`developed
`to
`provide
`voice
`communication over connectionless
`
`InPerson,
`computer networks (e.g.,
`ShowMe, Visual Audio Tool
`(vat),
`Network Voice Terminal
`(nevot)).
`However, the use of relatively high data
`rate voice coding within these existing
`network voice applications places
`unnecessary demands on performance
`and limits participation for mobile users
`and network sites with relatively low
`bandwidth resources such as found in
`
`many tactical communication systems.
`Applying adaptive, low rate compression
`algorithms
`to
`network
`voice
`communications
`is
`an
`enabling
`technology for users with low bandwidth
`resources and enhances the performance
`of higher bandwidth systems under
`loaded conditions.
`This
`is
`the
`
`fundamental principle followed in the
`development of IVOX; use of advanced
`low data rate voice compression and use
`of open systems computer network
`protocols.
`
`Network Voice Delivery
`Requirements
`
`There are some fundamental differences
`
`between the synchronous, dedicated
`communication channels typically used
`for digital voice communication and the
`data delivery service provided by
`connectionless network protocols. These
`include:
`
`Error handling:
`Bit error rate vs. packet drop rate
`
`Communication delay:
`Deterministic vs. non—deterrninistic
`
`delay
`
`0 Data delivery:
`Synchronous bit stream vs.
`asynchronous packets
`
`Error Handling
`
`Previous digital voice communication
`systems integrate robust error handling
`within the speech coding algorithm
`because the voice terminal application has
`had direct access and control of the
`
`In
`physical communication media.
`contrast,
`the application layer within
`connectionless datagram networks
`maintains
`independence from the
`underlying communication media.
`In a
`global internetwork, this independence
`allows applications to communicate peer-
`to-peer across multiple, heterogeneous
`media. Lower layer protocols at the
`transport, network, and link layers
`usually assume the major responsibility
`for any error handling. Datagrams in
`error are either automatically retransmitted
`or dropped depending upon the protocol
`set used. As a result, the application
`layer (i.e. the voice terminal in our case)
`does not usually incur bit errors in its
`communication data stream but will need
`
`to be able handle undelivered packets and
`reconstruct packet ordering.
`IVOX is
`designed to appropriately handle and
`recover from dropped data packets and
`reorder received packets as necessary.
`
`Communication Delay
`
`Dedicated
`
`connection
`
`oriented
`
`communication channels can provide
`deterministic delay in the delivery of
`voice data. With connectionless datagram
`delivery,
`there can be a significant
`amount of nondeterministic variance in
`
`the inter-arrival times of data packets.
`Furthermore,
`it
`is possible that data
`packets are received in a different order
`than they were transmitted. Current
`Internet Protocol (IP) service provides
`"best effort" delivery where all data flows
`
`664
`
`

`
`are given the same quality of service
`(QoS). Research is being conducted and
`initial
`test systems are in place for
`standardized IP routing and data delivery
`techniques that bound factors affecting
`quality of service such as delay
`Variance[8, 9]. Such vendor-independent
`resource management techniques will
`provide proactive internetwork bandwidth
`allocation among and between application
`data streams. Until techniques are widely
`implemented throughout the Internet, for
`many media, the "best effort" service
`model can continue to provide adequate
`service for even real—time applications
`such as digital voice communication.
`IVOX has been designed and tested using
`network architecture with and without
`
`QoS and resource reservation capability.
`
`Data Delivery
`
`Current digital voice communication
`systems generally provide continuous
`synchronous delivery of voice data across
`a dedicated communication channel. The
`dedicated communication channel
`is
`
`typically designed to provide a fixed
`amount of bandwidth, and vocoding
`algorithms have been designed to provide
`the best voice quality for bit rates
`supported within this bandwidth.
`In the
`connectionless networking environment
`where communication bandwidth is
`
`dynamically shared in an asynchronous
`fashion among distributed users and
`applications, adaptive rate voice coding
`techniques (e.g., silence detection) can
`improve
`bandwidth
`utilization
`dramatically. Adaptive rate voice coding
`can allow for high voice quality while
`maintaining a lower average network
`throughput
`requirement.
`The
`synchronous nature of many current
`voice encoding schemes has led to a
`widespread perception that voice
`communication requires "stream" oriented
`data
`communications when
`the
`information content of conversational
`
`voice is actually bursty in nature. This
`low data rate, bursty source can be
`serviced effectively by an asynchronous,
`connectionless network fabric. In IVOX,
`NRL has utilized an adaptive rate
`enhancement
`to existing DoD voice
`
`digitization algorithms and uses this as
`the primary mode for network voice
`communication [10].
`
`DESIGN
`
`The design of IVOX was conducted with
`the features and limitations of network
`
`In particular, the
`data services in mind.
`additional limitations imposed by low
`data rate tactical connectivity were given
`special consideration. The following is a
`list of design goals for IVOX.
`
`1) Use existing computer platforms
`without modification.
`
`2) Provide a simple graphical user
`interface with familiar telephone
`call paradigm.
`
`3) Robust and efficient call setup and
`management protocol.
`
`4) Provide multiple data rate vocoder
`algorithms for multiple levels of
`voice quality and capability of
`operation over a wide range of
`network connections.
`
`5) Modular software design for easy
`integration of additional vocoders
`and other features.
`
`6) Multiple modes of operation (e.g.
`half-duplex/
`full—duplex, real-
`time/ non-real—time).
`
`7) Flexible set of user controllable
`parameters for evaluation over
`different data networks.
`
`Overview of Operation
`
`IVOX digitizes voice using the
`computer's built-in audio hardware and
`then, using specialized speech encoding
`algorithms, compresses the audio data to
`continuous data rates as low as 600 bits-
`
`per-second (bps). Additionally, IVOX
`employs a silence detection technique to
`reduce the average data rate to even lower
`rates. For example, IVOX uses the
`Federal Standard 1015 Linear Predictive
`
`Coding (LPC) speech compression to
`achieve a data rate of 2400 bps. With
`silence detection removing the gaps
`between words or during pauses in
`speech, the typical measured data rate
`
`665
`
`

`
`during active portions of conversational
`speech is reduced to approximately 1300
`bps. Longer pauses and exchanges in
`conversation make the longer term
`average data rate much lower than this.
`
`IVOX also supports operation with
`external voice compression hardware
`through a modular software interface [l1.
`This reduces the load on the workstation
`
`CPU during voice communication. The
`prototype hardware that has been
`currently demonstrated connects to the
`computer via the serial port.
`It
`is
`envisioned that the hardware compression
`circuitry could be packaged as a plug-in
`bus card (e.g. EISA, PCI, PCMCIA)
`depending
`on
`the workstation
`configuration.
`Use of
`the voice
`compression hardware has allowed IVOX
`to operate on platforms with no built—in
`audio capability.
`'
`I
`
`IVOX communicates over the Internet
`
`using the User Datagram Protocol (UDP)
`encapsulated in Internet Protocol (IP)
`packets.
`The connectionless UDP
`transport was chosen over the reliable,
`connection oriented TCP because TCP’s
`
`reliability and flow control mechanisms
`(ACK—based, go-back-n retransmission)
`were
`prohibitive
`to
`real-time
`communication over low data rate links.
`
`The UDP/IP suite provides unreliable,
`unordered best effort delivery of data
`packets. An in-band signaling protocol is
`used to negotiate call setupand for
`subsequent communication session
`control. IVOX also provides a number of
`user controllable parameters
`for
`evaluating low data
`rate voice
`communication with connectionless
`
`datagram delivery. Example parameters
`include:
`P
`~
`
`' Number of vocoder frames per packet
`
`0 Re»sequencing window time setting
`
`0 Half-duplex or full—duplex operation
`
`and »non—real
`°Real—time
`interactive modes.
`“
`
`time
`
`Features
`
`Graphical User Interface
`
`IVOX features a simple, easy-to—use
`graphical user interface for call setup and
`management. The main window of
`IVOX is illustrated in Figure 1. The
`IVOX user interface roughly follows the
`paradigm of placing a normal telephone
`call. To place a call to a remote IVOX
`terminal, the user types in the name of the
`remote host
`(or dotted decimal
`IP
`address) and clicks on the “CALL”
`button. The remoteuser is notified of the
`pending call with a ringing sound, and is
`given the option of accepting or rejecting
`the call. If the remote IVOX terminal is
`
`busy, the caller is notified. “Caller ID” is
`provided in the hostname display for
`incoming calls. Other telephone—like
`features such as “call waiting” and “voice
`mail” are planned for future versions of
`IVOX.
`
`
`
`Figure I : IVOX Graphical User Interface
`Main Window
`
`As an integral part of the user’s
`workstation environment, IVOX can
`potentially offer many features beyond
`that of a simple telephone service. This
`includes voice messaging integrated with
`other electronic mail services, and
`cooperation and direct synchronization
`with other teleconferencing tools such as
`
`666
`
`

`
`video, white-boarding,
`collaborative software.
`
`and other
`
`Point-to-Point and Conference Calls
`
`IVOX supports unicast (point-to-point)
`and multicast (conferencing) IP [12
`communications. The current IVOX user
`
`interface was originally designed for
`point—to—point operation and the capability
`for conferencing on an IP multicast
`address has recently been added. A
`future version of IVOX will include user
`
`interface additions that provide a listing of
`conference participants and indications of
`their activity.
`
`IP multicast routing allows conferences
`with potentially hundreds (or more) of
`participants receiving network traffic
`while making efficient
`use of
`communication resources (i.e., network
`traffic is duplicated only when absolutely
`necessary). To create an IP multicast
`conference in IVOX, the participants need
`to agree on an IP multicast address (e.g.,
`224.x.x.x) in advance. The participants
`then join the conference by entering the
`IP multicast group address into the IVOX
`“Remote Host” text field and click on the
`
`“CALL” button. Participants may join
`and leave the conference any time at will.
`The host workstations and routers take
`care of the rest.
`
`Multiple Voice Compression Rates and
`Communication Modes
`
`IVOX supports voice compression
`algorithms that operate at 32,000, 4800,
`2400, 1200, 800, and 600 bps.
`IVOX is
`also capable of operating with external
`voice compression hardware.
`For
`general purpose use,
`the 2400 bps
`algorithm is a good choice.
`This
`provides intelligible speech with modest
`throughput requirements. The lower
`throughput,
`lower
`intelligibility
`algorithms are provided for situations
`where the lowest data rate possible is
`necessary. Additionally, IVOX provides
`a non-real-time mode to allow for limited
`interactive voice communication when the
`
`network is not capable of supporting real-
`time voice at any data rate.
`
`half-duplex
`and
`Full-duplex
`communication modes are supported.
`With full-duplex operation, any party
`may speak at any time. A mode that
`enforces a half-duplex discipline on the
`users is provided for point—to—point
`operation. This half-duplex discipline
`facilitates productive conversations that
`may occur over long-delay network
`connections (e. g., satellite links).
`
`SUMMARY
`
`Accomplishments
`
`Since its conception and development,
`IVOX has become an operational fleet
`software component and has played a key
`role in numerous research projects and
`demonstrations. IVOX was adopted as a
`core feature of the Joint Deployed
`Intelligence Support System (JDISS).
`IVOX was used to demonstrate low
`
`bandwidth network voice capability from
`an operational NRL booth during the
`1995 Armed Forces Communications and
`
`Electronics Association (AFCEA 95)
`convention.
`
`Additionally, IVOX has been integrated
`into Tactical Aircraft Mission Planning
`System (TAMPS)
`and Common
`Operation Mission Planning and Support
`Strategy (COMPASS) workstation
`terminals for the 1995 Joint Warrior
`
`Interoperability Demonstration (JWID 95)
`demonstration. During JWID 95, IVOX
`generally provided good results with
`occasional degraded service being noted
`during periods of high network loading.
`This result was expected and future use
`of resource reservation techniques will
`allow IVOX to provide good voice
`communications even during these
`periods of high network loading. IVOX
`enhancements that included some unique
`resource reservation capabilities were
`successfully developed and demonstrated
`during the Phase 2 NRL DVI ATD field
`test on the Chesapeake Bay in the
`summer of 1995.
`IVOX continues to
`
`play a role in the CSNI project and has
`been demonstrated successfully in both
`real-time and non-real-time modes.
`
`667
`
`

`
`Future Directions
`
`With the increasing proliferation of
`distributed collaborative tools, awareness
`data, and integrated C41 networking for
`the warfighter, real-time network voice
`applications will become a software
`component of increasing value. IVOX is
`presently providing an early capability in
`this area with little or no additional
`
`system cost.
`
`Future efforts to enhance IVOX include
`
`support for emerging resource reservation
`setup protocols, such as the Resource
`Reservation Protocol (RSVP). RSVP
`will provide a standard method for
`applications to attain a guaranteed quality-
`of-service
`in
`a
`shared network
`environment.
`It
`is anticipated the
`importance of bandwidth efficient, voice
`conferencing utilizing multicast
`networking technology will increase.
`
`IVOX will provide a useful starting point
`for exploring options
`in session
`establishment and management
`for
`distributed conferencing and mission
`planning and coordination. IVOX has the
`potential to be closely coupled with other
`distributed communication applications
`and many of the techniques used attain
`robust, low data rate operation may be
`applicable to these other systems.
`
`the
`“IVOX,
`1 R.B. Adamson,
`Interactive VOice
`eXchange
`Application”, NEWLINK Global
`Engineering Technical Report 101,
`September 1995.
`
`2 W. Richard Stevens 1994. TCP/IP
`
`Illustrated, Volume 1. Addison-
`Wesley Publishing Company,
`Reading, Massachusetts.
`
`3. Communications Support System
`Requirements Document, U.S. Navy
`Space
`and Naval Warfare
`(SPAWAR) Systems Command,
`1995.
`
`“Voice
`Henning Schulzrinne,
`Communication Across the Internet:
`
`A Network ‘Voice Terminal,”
`University of Massachusetts, July 26
`1992.
`5
`
`R.B. Adamson, “Communication
`Systems Network Interoperability”,
`1995 NRL Review, pp. 146-149.
`
`E.L. Althouse, J.P. Macker, J.P.
`Hauser, and DJ. Baker, ”Integrated
`Services in Tactical Communication
`Systems,” 1995 NRL Review, pp.
`141-143.
`.
`.
`
`Data and Voice Integration Advanced
`Technology Demonstration (ATD):
`Execution Plan, submitted to ONR,
`16 June 1992.
`
`and
`"Link—Sharing
`S. Floyd,
`Resource Management Models for
`Packet Networks", Lawrence.
`Berkeley Laboratory, December 14,
`1994.
`
`L. Zhang, R. Braden, and others,
`“Resource ReSerVation Protocol
`
`- Version 1 Functional
`(RSVP)
`Specification”,
`Internet Draft,
`November 3, 1994.
`»
`
`J.P. Macker and R.B. Adamson, ”A
`Variable Rate Voice Coder using
`LPC—10E,” NRL Technical
`Memorandum, 5520-92, July 12,
`1994.
`
`J.P. Macker and R.B. Adamson,
`”Proposed Draft Application
`Programmers Interface (API) for the
`Interactive VOice eXchange (IVOX)
`Vocoder Processes,” NRL Technical
`Memorandum, 5520-59, April 19,
`1 994.
`
`S.E. Deering and D.R. Cheriton,
`“Host Groups: A Multicast
`Extensionto the Internet Protocol”,
`Internet RFC 966, December 1985.
`
`10
`
`ll
`
`12
`
`668