`
`lVllLCOlVi 97
`
`
`lVllLCOlVl 97
`
`Proceedings
`
`Volumel OT 3
`
`Volume 1
`
`Monday 3 November
`
`Volume 2
`
`Tuesday 4 November
`
`Volume 3 Wednesday 5 November
`
`Sessions 1 Through l4
`
`Sessions 15 Through 28
`
`Sessions 29 Through 42
`
`
`
`
`
`
`
`lVllLCOM 97 is sponsored by The lE,EE,ThelEEECommunicoTions SocieTy,
`dnd AFCEA (Armed Forces CommunicoTions ond EleoTronics AssooidTion).
`
`
`
`-lllliiilll
`
`Ericsson Exhibit 1004
`
`Page 1
`
`Ericsson Exhibit 1004
`Page 1
`
`

`

`MILCOM Q7
`
`
`MILCOM 97 Proceedings
`
`Integrating Military and Commercial
`Communications for The Next Century
`
`Copyright and Reprint Permission: Abstracting is permitted with credit to the source. Libraries are
`permitted to photocopy beyond the limit of US. 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 Copyrights Manager, IEEE Service
`Center, 445 Hoes Lane, PO. Box 1331, Piscataway, NJ 08855-1331. All rights reserved. Copyright © 1997
`by the Institute of Electrical and Electronics Engineers, Inc.
`
`IEEE Catalog Number
`Library of Congress
`ISBNeSoftbound Edition
`ISBN—Cascbound Edition
`ISBN—Microfiche Edition
`ISBN—CD ROM Edition
`
`‘
`
`’
`
`_
`
`‘
`
`'
`
`1
`
`_
`
`- 97CH36134
`-
`97*80126 L
`0-7803—4249—6
`0—7803-4250-X
`0—7803-4251-8
`0-7803-4252-6
`
`Additional copies of this publication are available from:
`
`IEEE Service Center
`445 Hoes Lane
`PO. Box 1331
`
`Piscataway, N] 08855—1331
`
`1—908-981-0060
`1-800—678—IEEE
`
`1—908—981—1721 (fax)
`
`
`
`1
`
`
`
`
`
`Ericsson Exhibit 1004
`
`Page 2
`
`Ericsson Exhibit 1004
`Page 2
`
`

`

` MlLCOM 97
` General Chair, MILCOM 97
` Firmlire/Registration Chair, MILCOM 97
`Robert Crouse
`Lockheed Martin Missiles and Space
`1111 Lockheed Martin Way
`67-71, B / 158
`Sunnyvale, CA 94088-3504
`Phone: 408-756-6303/408‘74370992
`Fax: 4087566336
`eeinail: bob.Crouse@liiiro,com
`
`
`
`Security CU'ChHlT, MILCUM 97
`Tim Bechtel
`Lockheed Martin
`1111 Lockheed Martin Way
`2772, 13/104
`Sunnyvale, California 94089
`Phone: 408-756-6017
`Fax: 40875670750
`e-mail: timothy.a,beclitel@lnico.com
`
`Registration CarChair, MILCOM 97
`Lailaiii Madruga
`Lockheed Martin Missiles & Space
`1111 Lockheed Martin Way
`27—31, B / 154
`Sunnyvale, CA 94089
`Phone: 408—756-6499
`Fax: 408756—3336
`e-mail: lailani,inadruga@lincocom
`
`Lm'ul Arrangements Chair, MILCOM 97
`Nobie Tsukida
`Lockheed Martin
`,
`Western Development Laboratories
`R0. Box 49041
`San Jose, CA 95161-9041
`Phone: 408473—7670
`Fax: 40841734464
`eemail: nobuko,tsukidafblincorcom
`
`'
`
`Lora] Arrangements CU‘Chlu‘)’, MILCOM 97
`Mary, Redigan
`Lockheed Martin
`Western Development Laboratories
`17.0. Box 49041
`San Jose, CA 95161-9041
`Phone: 408—473—4587
`Fax: 408473-4278
`e—rnail: marya.redigantfilmcocom
`
`Publications Chair, MILCOM 97
`Bob Wilson
`Lockheed Martin Missiles and Space
`1111 Lockheed Martin Way
`H2420, 13/158
`Sunnyvale, CA 94089
`Phone: 408—756-6394
`Fax: 408—756—6550
`e -mail: bob,wilson@lincorcom
`
`Publicity Chair, MILCOM 97
`Lee Flanagin
`Mathews and Clark Communications
`' 710 Lakeway Drive, Suite 170
`Sunnyvale, CA 94086
`Phone: 408-73671120
`Fax: 408—736—2523
`e-mail: fianagiri®mathewsandclark.com
`
`Patron/Erizibits Chair, MILCOM 97
`Becky Nolan
`,
`AFCEA
`4400 Fair Lakes Court
`Fairfax, VA 22033
`Phone: 703-631-6170
`Fax: 703—631-6169
`email: p1ans®afcea.org ,
`
`Security Chair, MI'LCOM 97
`Tom Hughes
`Lockheed Martin
`Western Development Laboratories
`PO. Box 49041
`San Jose, CA 9516179041
`Phone: 40841735355
`Fax: 408473-4112
`e—inail: thoiiiasrw.huglies@lmcorcom
`
`Security CneChair, MILCOM 97
`Patrick D uim
`Lockheed Mdl [in
`Western Development Laboratories
`17.01 Box 49041
`San lose, California
`Phone: 40847346961
`Fax: 408473—4112
`e-mail: patrick.1.dumi@lrncorcoin
`Exhibits CmChah‘, MILCOM 97
`Beth Cain
`J. Spargo & Associates
`4400 Fair Lakes Court
`Fairfax, VA 22022
`Phone: 800564-4220 or 703631-6200
`Fax: 703-818-91 77
`evmailzjspargo@aol.com
`Prototn/ Chair, MILLIOM 97
`Bill Wilt
`Lockheed Martin Missiles and Space
`1725 Jefferson Davis Highway
`Suite 403
`Arlington, VA 22202
`Phone: 703413-5925
`Fax: 703—413-5923
`email: bill.wilt@lmco.com
`
`Prui‘miol CirCI'Irlir, MILCONI 97
`Mary In Higgason
`Lockheed Martin Missflcs and Space
`1111 Lockheed Martin Way
`H3—50, B / 101
`Sunnyvale, CA 94088-3504
`Phone: 408-742-2733
`Fax: 408‘756-8966
`e»mail: maryjo.higgason@lincocom
`
`DuD Liaison, MlLCOM 97
`Doug Hudson
`C41 Integration Support Activity
`Crystal Gateway Three-Suite 1101
`1215 Jefferson Davis Highway
`Arlington, VA 22207
`Phone: 703»602‘9962
`Fax: 703-602-5890
`e—mail: hudsond@osd.pentagonmil
`
`AFCEA Liaison, MILCOM 97
`Bob Landgraf
`M / S: WROZ
`Digital Equipment Corporation
`2575 Augustine Drive
`Santa Clara, CA 95054
`Phone: 408323—8838
`Fax: 408623—8839
`email: landgraf©mailtlec.com
`
`Ericsson Exhibit 1004
`
`Page 3
`
`Mike Henshaw, President
`Lockheed Martin Missiles & Spare
`1111 Lockheed Martin Way
`Sunnyvale, CA 94089
`(408) 74276211
`
`Executive COMM/HEP Chair, MILCOM 97
`Judson B. Grubbs, 11
`Lockheed Martin Missiles and Space
`1111 Lockheed Martin Way
`11Mv01, B/104
`Sunnyvale, CA 940886504
`Phone: 408-5113731131
`Fax: 408-543—31 04
`email: jiid.grubbs@lmco.com
`
`Executive Committtw Deputy, MILCOM 97
`Kathy Lukens
`Lockheed Martin Missiles and Space
`1111 Lockheed Martin Way
`MO—Ol, B/ 158
`Sunnyvale, CA 94088-3504
`Phone. 408—75676196/4087756—4018
`Fax: 40875676139
`,
`,
`e—mail: kaihy.1ukens@lmco.com
`
`‘I‘L’clmical Program Chair, MILCOM 97
`Doug Bender
`Lockheed Martin
`Western Development Laboratories
`1101 Box 49041
`San Jose, CA 95161—9041
`Phone: 1108-4734549
`Fax' 40874735529
`e-mail: douglas.f.bender@1mcoicorn
`
`Unclassified Program Chair, MILCOM 97
`Don Fulop
`Lockheed Martin
`Western Development Laboratories
`PO, Box 49041
`San Jose, CA 9516149041
`Phone: 408734—6133
`Fax. 408-73476657
`email, doriald.g.fulop@lmco.com
`
`Classified Progmm Chair, MILCOM 97
`Dana Wal dman
`Lockheed Martin
`Western Development Laboratories
`PO. BOX 49041
`San Jose, CA 95161-9041
`Phone: 408473 4761
`Fax: 408473—4097
`ermailr dana.r.waldman@lmco.com
`
`Panels and Tutorials Chair, MILCUM 97
`Sastn‘ Kota
`Lockheed Martin Telecommunications
`1111 Lockheed Martin Way
`68-70 B/ 551
`Sunnyvale, CA 94089
`Phone: 40875436140
`Fax: 408—54373104
`e»iiiail: sastri.kota@lmco.com
`
`'
`
`Registration Chair, MILCOM 97
`Marti Vasquez
`Lockheed Martin
`1111 Lockheed Martin Way
`25-33, B/ 104
`Sunnyvale, CA 94089
`Phone: 408* 75676499
`Fax, 40875643336
`e»rnailr inarti.vasquez@lrnco.com
`
`
`
`Ericsson Exhibit 1004
`Page 3
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Unclassified Technical Sessions
`M l LCOM Q7
`Tuesday 4 November 7997
`
`Performance of an OFDM Spread Spectrum Communications System Using Lapped Transforms ............................... 608
`Gary 1. Saulnier, Rensselaer Polytechnic Institute and Mike Mettke, Rome Laboratory
`
`i l
`
`Session 17
`Chair
`
`Information Dissemination
`
`Dr. Joe Rockmore, Cyladian Technology Consulting and Dr. Robert Douglas, DARPA
`
`Communications System Considerations for Unattended Army Battlefield Munition and Sensor Systems ................ 613
`Thomas ]. McAdams, The MITRE Corporation, Thomas L. Thomas, The MITRE Corporation, and Robert Wade, United States
`Army Armaments Research, Development and Engineering Center (ARDEC)
`
`Intelligent Decision Aids for let Century C41 Architectures ............................................................................................... 618
`Ram Voruganti, GTE Laboratories Incorporated, Che-Fri Ya, GTE Laboratories Inc., Nabil Hinnawi, GTE Laboratories Inc.,
`Nabil Bitar, GTE Laboratories Inc, and Brian Rivera, Army Research Laboratories, Georgia Institute of Technology
`
`Scheduling Information Dissemination by Satellite Broadcast ............................................................................................. 623
`Robert ]. Wellington, Computing Devices International
`
`Scheduling Algorithms for Message Transmission Over aNSatellite Broadcast System .................................................... 628
`Eytan Motlitlnu, Massachusetts Institute of Technology, Lincoln Laboratory
`
`IIDS: Intelligent Information Dissemination SérVer ,L ............................................................................................................. 635
`[on Dukes—Schlossberg, Lockheed Martin Missiles 65% Space, Yongwon Lee, Lockheed Martin Missiles Er Space, and Nancy Lehrer,
`ISX Corporation
`-
`
`AFRTS Commercial Off the Shelf (COTS) Worldwide Digital Video Broadcast Network ............................................... 640
`Shahid Rahman, Scientific—Atlanta, Incorporated and Steve Richeson, ScientificeAtlanta, Incorporated
`
`Network Interface to Tactical Communications ..................................................................................................................... 645
`Ning 11. La, ITI‘ Aerospace/Communications Division
`
`Mobile Wireless Information Systems
`Session 18
`Chair
`Dr. Kevin Mills, DARPA
`
`Future Army Mobile Multiple-Access Communications ...................................................................................................... 650
`Don Torrieri, Army Research Laboratory
`
`Design Considerations for Mobile Wideband Wireless Network Architectures
`Michael E . Humphrey, Motorola
`
`............................................................. 655
`
`Mobile Internetworking Protocols for Wireless Networks with ATM Backbones ............................................................. 660
`Subhashini Rajagopalan, Bellcore, Ravi ]ain,_Bel_lcore, and Li Fung Chang, Bellcore
`
`C41 Mobility Architectures for 2] st Century Warfighters ...................................................................................................... 665
`Ram Voruganti, GTE laboratories Incorporated and Allen Levesque, GTE Laboratories Incorporated
`
`Modeling 2] st Century TacticalCommunications Networks ............................................................................................... 671
`Ed Harrington, GTE Government Systems, Bill Josephson, GTE Government Systems, and John Paclik, GTE Government
`Systems
`~
`~
`~
`,
`
`Wireless Networks of Opportunity in Support of Secure Field Operations ....................................................................... 676
`Roy H. Stehle, SRI International and Mark G. Lewis, SRI International
`
`Session 19
`Chair
`
`Architecture and Protocols 2
`
`Dr. Edward Chandler, Titan Linkabit
`
`A Fault—Tolerant Real~Time Commercial LAN ...... .................................................................................................................. 682
`Doug Rhoades, Hughes Aircraft Company
`
`A Dynamic Packet Reservation Multiple Access Scheme for Wireless ATM ...................................................................... 687
`Deborah A. Dyson, Cornell University and Zygmunt]. Haas, Cornell University
`
`
`
`
`
`
`
`
`
`
`Networking Protocols for Space Data Communications ....................................................................................................... 694
`Rafols Ramirez, The MITRE Corporation
`
`. xiii
`
`Ericsson Exhibit 1004
`
`Page 4
`
`Ericsson Exhibit 1004
`Page 4
`
`

`

`A DYNAMIC PACKET RESERVATION MULTIPLE ACCESS SCHEME FOR
`WIRELESS ATM
`
`Deborah A. Dyson and Zygmunt J. Haas
`Cornel1 University, School of Electrical Engineering
`Ithaca, NY 14853
`
`Abstract
`
`Dynamic Packet Reservation Multiple Access (DPRMA)
`is a medium access control protocol for wireless mul-
`timedia applications.
`It allows the integration of both
`constant bit rate and variable bit rate trajjic through a
`single access control mechanism that permits users to
`specify their bandwidth requirements. Users are allowed
`to repeatedly update this information in order to refEect
`any changes in their data rates. A base station analyzes
`the mobiles’ requests, determines which can be accommo-
`dated, and conveys the resulting bandwidth assignments
`to the users. The ability of a mobile to initially reserve
`a portion of the channel capacity and to then dynam-
`ically alter this reservation is a primary feature of the
`system. In DPRMA, an attempt is made to match the
`capacity assigned to the user zoith the user generation
`rate. Furthermore, this capacity can be allocated using
`fractional or multiple slot assignments. The scheme is
`shown to provide improved performance over a system
`with a modified version of the Packet Reservation Mul-
`tiple Access (PRMA) scheme.
`1. Introduction
`
`One primary focus of today’s communication network
`technology is on the efficient integration of multime-
`dia traffic such as voice, computer data, video, and
`other traffic types. A current state-of-the-art technique
`for achieving such integration is via the Asynchronous
`Transfer Mode (ATM) protocol. The success of ATM
`has engendered the desire to extend multimedia net-
`works beyond t heir current capabilities. Consequently,
`there has been considerable interest in incorporating
`multimedia applications such as ATM into a wireless
`network. Before this can be accomplished, however,
`there are certain issues unique to wireless systems that
`must be addressed. One specific area is that of efficient
`Medium Access Control (MAC).
`A new MAC protocol for the cellular environment
`must be designed based on features that are inherent to
`the system. It is assumed in this work that the cellular
`network is made up of a grid of cells, each of which con-
`
`tains a centralized base station. Wireless mobile users
`communicate via the base station using an uplink (mo-
`bile to base station) and a downlink (base station to
`mobile) channel. Since the base station is the sole trans-
`mitter on the downlink channel, efficient resource alloca-
`tion on this channel is a relatively easy task and no MAC
`protocol is necessary. On the uplink channel, however,
`a MAC scheme is required.
`A considerable body of research has already been per-
`formed on the topic of MAC protocols, especially for
`voice and data applications. However, the Time Division
`Multiple Access (TDMA) schemes that are currently
`used are inappropriate and inefficient since they do not
`attempt to address the continuously changing needs of
`heterogeneous traffic types. One of the most notewor-
`thy schemes for packetized voice transmission has been
`the Packet Reservation Multiple Access (PRMA) pro-
`tocol [l]. Although PRMA is suitable for systems with
`voice and data traffic, there is no mechanism for accom-
`modating users with changing transmission rate require-
`ments. Furthermore, the system is optimized for a single
`traffic type, namely voice. Therefore the PRMA proto-
`col is inappropriate for multiple real-time Variable Bit
`Rate (VBR) traffic users. Thus, a new MAC protocol
`that is more suited for the combination of both VBR and
`Constant Bit Rate (CBR) traffic needs to be devised.
`In this paper, Dynamic Packet Reservation Multiple
`Access (DPRMA), a novel MAC protocol, is introduced.
`It is based on the principles of PRMA, which allow reser-
`vations of periodic time slots. Unlike PRMA, however,
`this protocol allows dynamic resource allocation to take
`place based on information provided by each user about
`its current resource requirements. Each user can update
`its request whenever it determines that its requirements
`have changed. The base station is responsible for mon-
`itoring ail the rate requests and determining which can
`be accommodated at any given time. The base station
`then dictates which user will transmit in each slot of the
`uplink channel.
`The PRMA protocol is briefly reviewed in Section 2.
`The basic concepts of DPRMA are then presented in
`Section 3. In addition, a technique is described for al-
`
`0-7803-4249-6/97/$10.00 O 1997 IEEE
`
`Ericsson Exhibit 1004
`Page 5
`
`

`

`lowing each user to assess its current bandwidth require-
`ment and then update its resource request. Section 4
`details the system parameters that were used in the sim-
`ulation study. Also, results of the DPRMA simulation
`are outlined. Finally, in section 5 concluding remarks
`are presented.
`
`2. Packet Reservation Multiple Access
`
`The PRMA protocol allows multiple users to share the
`resources of one frequency channel. The channel is di-
`vided into time slots which are grouped into frames. The
`size of the slots and frames are set such that a voice
`user’s packet generation rate matches its transmission
`rate when it transmits during one slot in each frame. All
`users contend for access to the channel using a method
`that is similar to Reservation ALOHA, R-ALOHA [2].
`A user who needs to gain access waits for an unused slot
`and then transmits in that slot with probability p . If
`a collision occurs, the user waits for the next available
`slot and tries again with the same transmission probabil-
`ity. This continues until the user transmits successfully
`or decides to give up. If a voice user is successful in
`transmitting in a slot, the same slot in every subsequent
`frame is reserved for this user.
`Information about the availability of slots is provided
`by the base station on the downlink channel.
`In ad-
`dition, the base station indicates the success of a new
`transmission, so that the users know if a new reserva-
`tion has been obtained. Each user transmits in its re-
`served slot until it no longer has any more packets to
`send. Then the user leaves its next reserved slot empty.
`This informs the base station that the user releases its
`reservation and that slot can be made available for the
`transmission of other traffic. In the future, when the
`user has more packets to send, it will have to once again
`contend for a reservation.
`
`3. Dynamic Packet Reservation Multiple
`Access
`
`3.1 Medium Access Control
`
`The DPRMA protocol is more complex than PRMA in
`the way bandwidth is allocated. A base station us-
`ing DPRMA must arbitrate among all active mobiles
`to determine who has access to the channel at any given
`time. The primary goals of the protocol are to maximize
`throughput, to allow users ”fair” access to the chan-
`nel, and to provide some guaranteed Quality of Service
`(QOS) to each user based on the user’s traffic type. Two
`
`particular elements of QOS that are considered here are
`the probability of packet loss and the maximum trans-
`mission delay suffered by each cell. If any packet is not
`transmitted within the guaranteed specification, then it
`is dropped. In this work, excessive transmission delay
`is the only cause of packet dropping. All packets that
`are transmitted are assumed to be received by the base
`station without transmission error.
`The DPRMA protocol resembles PRMA in several
`ways. In DPRMA the frequency channels continue to
`be divided into slots and frames. The size and spacing
`of these remain such that a voice user needs t o reserve
`exactly one slot in every frame. Also like PRMA, the
`users of the system initially contend for access using the
`R-ALOHA-like method. A user who is successful in ac-
`quiring a slot and who requests to reserve a single slot
`per frame is allocated the same slot in which it suc-
`cessfully contended. This assignment continues for all
`subsequent frames until the user changes or releases its
`reservation. The mechanism for releasing a reservation
`for the DPRMA protocol is identical to that of PRMA;
`users simply leave the next reserved slot empty to in-
`dicate that they have no more packets to send. Thus,
`with only voice users present, the system reverts back
`into PRMA.
`The primary difference between the two protocols
`is the manner in which reservations are made and re-
`sources are allocated for VBR sources. The slots within
`a DPRMA frame are divided among the users based on
`the amount of bandwidth that each user requires. Users
`may reserve a number of slots within a frame or even
`slots in alternating frames, as long as that capacity is
`currently available. In addition, changes to a user’s al-
`location request can be easily accommodated.
`The base station in the cellular environment has the
`responsibility of dividing the bandwidth up among the
`active users. In order to accomplish this task, each mo-
`bile must be able to convey its requirements to the base
`station. In the D P W A scheme this is performed by set-
`ting aside several Reservation Request (RR) bits within
`the header of each uplink time slot. It is the user’s re-
`sponsibility to determine the appropriate rate reserva-
`tion required and set its rate bits accordingly.
`Each user can transmit at a limited number of dif-
`ferent transmission rates, c,. This limits the amount
`of overhead introduced by the presence of the RR bits.
`These rates are defined as:
`
`where C is the data rate of the channel in bits per sec-
`
`688
`
`Ericsson Exhibit 1004
`Page 6
`
`

`

`FramcN
`
`R
`
`FramcN+I
`
`R
`
`S
`
`R
`
`R
`
`R
`
`R
`
`S
`
`R
`
`R
`
`
`
`
`
`R
`
`R
`
`S
`
`S
`
`
`
`F r a "
`
`R
`
`R
`
`Frame N+i
`
`R
`
`D
`
`
`
`
`
`R
`
`R
`
`R
`
`D
`
`R
`
`R
`
`R
`
`D
`
`R
`
`R
`
`
`
`
`
`R
`
`D
`
`Figure 1: a) New user arrives and requests 4 slots. New
`slots are assigned according to Pa = Sn/S,. b) A user with
`8 slots wants to decrease its reservation to 4. Assigned slots
`are released according to P d = & / S T .
`
`ond, n is the number of slots in a frame, and i is an
`integer. The value for inin dictates the smallest possi-
`ble bandwidth allocation and can be set to any value
`that is appropriate for the system in question. For this
`study imin was set to -3.
`When a user has a new burst of information to trans-
`mit it must first attempt t o obtain a reservation. It
`sets the appropriate RR bits to indicate its rate request,
`contends for an empty slot, and monitors the downlink
`channel to determine its success or failure status from
`the base station. This is indicated via several Reserva-
`tion Acknowledge (RA) bits in the header of the down-
`link messages. When a successful transmission has oc-
`curred, the base station immediately attempts to accom-
`modate as much of the rate requested as is possible. If
`the total request cannot be fully accommodated, then
`a partial allocation is made. The base station keeps a
`record of any partial allocations so that the remaining
`Any changes to a user's reservation requirements are
`request can be accommodated whenever the bandwidth
`communicated by the user t o the base station via the RR
`later becomes available.
`bits. An increase in reservation is accommodated if the
`If a full allocation is possible, the base station must
`resources are available. The additional slots needed are
`determine which of the remaining unclaimed slots will
`be assigned. The base station first identifies which slots assigned according to equation 2. A decrease in
`vation is always accommodated immediately to prevent
`are currently unallocated and determines how many such
`the user from running out of packets to send and then
`slots exist. Next, the base station examines each of these
`losing its reservation.
`slots in sequential order to determine if the slot will be
`When a rate decrease is requested by a user, the base
`assigned to accommodate the new request. Throughout
`station first determines which slots are currently as-
`the process, the base station maintains a record of how
`signed t o that user. The base station then considers
`many slots, S,, the user still needs in order to have its
`each of these slots one at a time in sequential order for
`request satisfied. Every time a slot is successfully as-
`deallocation purposes. The number of slots yet to be re-
`signed, S, is decremented. In addition, the base station
`leased, s d , and the number of slots yet to be considered
`keeps track of the number of available slots, Sc, that
`for release, Sr, are constantly updated throughout this
`have not yet been considered for assignment. Each time
`process. Each slot is released with probability,
`a new slot is considered, S, is decremented. As the base
`station sequentially considers each available slot, it as-
`(3)
`Pd = s d / s r .
`signs each one with probability Pa, where
`As with the slot assignment algorithm, this process en-
`Pa = Sn/Sc.
`(2) sures that the necessary number of slots are always re-
`leased. An example of how the slot deallocation protocol
`Thus, the probability that a slot is assigned is dependent operates is shown in Figure lb.
`a user's
`needed to
`After the slots have been deallocated, the base station
`'POn how
`request. However, this Process
`that the
`determines if there are any users waiting for additional
`be
`the 'umber Of 'lots it requires* slots to be assigned. The backlog of such users is handled
`in a first come, first served manner, and as many
`Also, it tends to spread the allocation of slots randomly
`throughout the frame* An
`Of the operation Of as possible are accommodated. Any remaining backlog
`the 'lot assignment
`is shown is Figure la.
`is handled whenever additional slot reservations are re-
`Once a user has secured a reservation, it must mon-
`leased.
`itor the downlink channel to determine in which slots
`it is allowed to transmit. This is indicated via several
`Slot Reservation (SR) bits that are incorporated into the
`downlink message header.
`
`3.2 Rate Requests
`
`In the DPRMA protocol it is up to each user to deter-
`
`689
`
`Ericsson Exhibit 1004
`Page 7
`
`

`

`mine the appropriate reservation request that ensures
`timely delivery of traffic. For CBR traffic it is simply a
`matter of reserving the rate that is as close to the gen-
`eration rate as possible. At times it may be impossible
`to exactly match the generation rate to the reservation
`rate due to bandwidth quantization. Therefore, every
`so often, the user may have to increase or to decrease
`the reservation rate to avoid running out of packets to
`send or to avoid excessive transmission delay. Both cases
`are undesirable. Whenever a user runs out of packets to
`send it must give up its reservation, wasting one slot in
`the process. When the next packet is generated, the user
`must contend for a new reservation, thereby causing de-
`lay in transmission and wasting slots due to an increased
`probability for collisions. Excessive delay is undesirable
`since it causes packets to be dropped and deteriorates
`the system performance.
`The rate selection method proposed here allows newly
`generated packets to be queued in a buffer as they await
`transmission. As the size of the queue grows, the user
`increases its reservation request to avoid excessive trans-
`mission delay.
`If the queue length subsequently de-
`creases, the user then requests a lower reservation rate
`to avoid running out of packets. The buffer size that
`corresponds to an increase or decrease is defined as a
`threshold. The thresholds are set so that hysteresis ex-
`ists in the system, and a user does not rapidly oscillate
`between two rates.
`This threshold level protocol can also be adopted by
`users with VBR traffic. These traffic types, however, can
`have a large range of possible packet generation rates.
`Therefore, a system with multiple threshold levels is re-
`quired. An example of this rate request method with
`multiple thresholds can be seen in Figure 2.
`For this example the user in question is allowed t o
`specify one of three possible rates, R, 2R, and 4R. Ini-
`tially the user sets its request at R. When the user’s
`queue length first crosses the Lyp threshold, the user
`doubles its rate request to 2R. It can maintain this rate
`request until the queue length crosses the Lip threshold
`or the Lpwn threshold. Crossing Lip would cause the
`user to double its rate request to 4R, and crossing Lfmn
`would cause the user to halve its rate request to R. In
`the example shown, Lip is crossed next at time step 17,
`and the new rate becomes 4R. This rate is maintained
`is crossed at time step 21, at which time the
`until ,$Own
`rate request becomes 2R. Note that crossing L;p from
`above has no effect on the user’s rate request. Likewise,
`crossing LPwn from below at time step 30 has no effect
`since the user’s rate request is already set to 2R.
`
`690
`
`5
`
`10
`
`15
`
`20
`time
`
`25
`
`30
`
`35 40
`
`1
`
`4R
`
`5
`
`10
`
`15
`
`20
`time
`
`25
`
`30
`
`35 40
`
`Figure 2: a) User queue length in relation to threshold levels.
`b) Resulting rate request.
`
`4. Simulation and Results
`
`Users generating voice and video conferencing traffic
`were simulated for use in the DPRMA scheme. As de-
`scribed in what follows, the models that were used to
`generate the traffic are based on previous studies involv-
`ing these two traffic types.
`
`4.1 Voice Traffic
`
`Extensive study has already been done on voice traf-
`fic models. The model used here is based on the work
`done by Brady [3] and assesses that speech sources gen-
`erate periods of talkspurts and gaps. By assuming that
`a voice activity detector can be used to differentiate be-
`tween principle talkspurts and principle gaps, voice traf-
`fic can be characterized by the two-state Markov chain
`model displayed in Figure 3. The system alternates be-
`tween the ON and OFF states, which correspond to the
`talkspurts and idle periods of speech. In the ON state
`voice packets are generated at a constant rate. No pack-
`ets are generated in the OFF state due to silence de-
`tection. Time spent in each state is exponentially dis-
`tributed with means cr-l for the OFF state and /3-’ for
`the ON state. A voice source would therefore require a
`reservation while in the ON state, but then could release
`the reservation during the OFF state, since no packets
`are available for transmission.
`The ON-OFF voice traffic sources used in this study
`are modeled with the parameter values a-1 = 1.35 sec-
`= 1.0 second [4]. Since voice cells must be
`onds and
`delivered in real time, there is a maximum transmission
`
`Ericsson Exhibit 1004
`Page 8
`
`

`

`Figure 3: 2-state Markov model for voice
`
`delay allowed; any voice cell that has not been trans-
`mitted within 40 msec of its time of generation will be
`discarded at the source. For this study, the number of
`cells that are lost in this manner must not exceed 1% in
`order to provide an acceptable QOS level.
`
`4.2 Video Conferencing Traffic
`
`\ U-PY
`
`/ /
`
`Figure 4: Markov model for video
`
`packet dropping probability for video traffic was set to
`The model used to describe video conferencing traffic is
`0.01
`based upon work done by Heyman, et a1 [5]. In this
`study of actual video conferencing traffic, video frames
`(VF) were found to be generated periodically and to 4.3 Traffic Parameters
`contain a varying number of cells in each frame. The
`The system that was tested was designed to accommo-
`number of cells per video frame was determined to be
`date voice users generating traffic at 32 kbps in the ON
`approximately characterized by the negative binomial
`state. The transmission rate for this system was set at
`distribution. A Markov chain model can be constructed
`9.045 Mbps. The information traffic to be sent was for-
`that demonstrates the transition from one state to the
`matted in ATM-sized cells. In order to accommodate
`next. The transition matrix is calculated using the fol-
`traffic users in the manner described, each frame was
`lowing equation:
`divided into 256 slots and lasted 0.012 seconds. With
`these parameters, voice users were required to reserve
`exactly one slot in every frame in order to match their
`cell generation rate. Figure 5 contains a listing of all the
`variables relevant to this simulation study.
`Since the video conferencing traffic was VBR, it was
`necessary to use threshold levels to accommodate these
`users. The cell generation rate per VF ranged from 1 to
`220 cells. From equation 1 the video sources could be
`allowed to request transmission rates from 4.417 kbps
`to 9.045 Mbps. Since the maximum bit rate for these
`sources is 220 * 53 * 8/0.04 = 2.332 Mbps, however, the
`maximum rate reservation allowed for video was the next
`c; value above this; i.e., c7 = 4.523 Mbps. The minimum
`cell generation rate was 1*53*8/0.04 = 10.6 kbps, which
`implied that the lowest allowed transmission rate should
`be set slightly lower at c-2 = 8.833 kbps. However,
`since the probability of generating less than seven cells in
`one VF was 1.696 *
`these cases were ignored when
`selecting the lowest transmission rate. It was therefore
`assumed that the lowest bit rate required was 7 * 53 *
`8/0.04 = 74.2 kbps. The value of ci just below this was
`c1 = 70.667 kbps. The threshold levels used in these
`simulations are specified in Figure 6.
`
`where I is the identity matrix, p is the autocorrelation
`coefficient and each row of the Q matrix is composed
`of the probabilities (fo, . . ., f h ' , F ~ ) - The quantity fk
`has the negative binomial distribution and represents the
`probability that k cells are present in one video frame.
`The value of K in equation 4 represents the peak cel