throbber
2001-11-12
`
`802.16abc-01/61
`
`Project
`
`IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
`
`Title
`
`Fast and Efficient BW Request Mechanism for IEEE 802.16a OFDM PHY
`
`Date
`Submitted
`
`Source(s)
`
`2001-11-08
`
`Jerry Krinock, Manoneet Singh, Mike Paff,
`Vincent Tien, Arvind Lonkar, and Lawrence
`Fung
`Radia Communications, Inc.
`275 N. Mathilda Avenue
`Sunnyvale CA 94305
`
`Re:
`
`BW Request Mechanism
`
`Voice: 408 830 9726 Ext 239
`Fax:
`408-245-0990
`Email: jkrinock@radiacommunications.com
`
`Abstract
`
`This document presents the results of a detailed simulation and analytical study of various bandwidth
`request mechanisms for the IEEE 802.16a OFDM PHY.
`
`Purpose
`
`Improving current 802.16a standard
`
`Notice
`
`Release
`
`Patent Policy
`and
`Procedures
`
`This document has been prepared to assist IEEE 802.16. It is offered as a basis for discussion and is not
`binding on the contributing individual(s) or organization(s). The material in this document is subject to
`change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or
`withdraw material contained herein.
`
`The contributor grants a free, irrevocable license to the IEEE to incorporate text contained in this
`contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright
`in the IEEE’s name any IEEE Standards publication even though it may include portions of this
`contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the
`resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution
`may be made public by IEEE 802.16.
`
`The contributor is familiar with the IEEE 802.16 Patent Policy and Procedures (Version 1.0)
`<http://ieee802.org/16/ipr/patents/policy.html>, including the statement IEEE standards may include the
`known use of patent(s), including patent applications, if there is technical justification in the opinion of the
`standards-developing committee and provided the IEEE receives assurance from the patent holder that it
`will license applicants under reasonable terms and conditions for the purpose of implementing the
`standard.
`
`Early disclosure to the Working Group of patent information that might be relevant to the standard is
`essential to reduce the possibility for delays in the development process and increase the likelihood that the
`draft publication will be approved for publication. Please notify the Chair <mailto:r.b.marks@ieee.org> as
`early as possible, in written or electronic form, of any patents (granted or under application) that may cover
`technology that is under consideration by or has been approved by IEEE 802.16. The Chair will disclose
`this notification via the IEEE 802.16 web site
`<http://ieee802.org/16/ipr/patents/notices>.
`
`1
`
`HONDA 1017
`
`

`

`2001-11-12
`
`80216abc-01/61
`
` Fast and Efficient Bandwidth Request Mechanism for
`IEEE 802.16a OFDM PHY
`
`Jerry Krinock, Manoneet Singh, Mike Paff, Vincent Tien, Arvind Lonkar and Lawrence Fung
`Radia Communications
`
`1. MOTIVATION FOR THIS STUDY
`
`The IEEE 80216ab-01_01r2 working document states that access to the uplink air interface in the OFDM mode
`of 802.16a shall be contention based [1, pp. 196]; however, details of the contention mechanism to be used for
`this purpose have not yet been specified. No performance results or MAC primitives to support any particular
`mechanism have been provided either.
`
` In this contribution, we perform a detailed, PHY-level evaluation of various contention-based techniques that
`may be used for bandwidth request in the OFDM PHY. The result of our investigation is the development of an
`optimal, contention-based BW request mechanism, which we propose and describe here.
`
`2. INTRODUCTION
`
`The key desirable features of a BW Request mechanism in any data network can be heuristically summarized
`as follows [2]:
`
`•
`
`•
`
`•
`
`•
`
`It should be contention-based in order to handle bursty data traffic with low overhead.
`
`It should function robustly under the constraints imposed by the physical channel (in terms of multipath
`spread, interference from other users, etc.).
`
`It should guarantee low delays in order to support delay-sensitive traffic.
`
`It should (preferably) be optimized using the features of the underlying PHY, so as to leverage the
`opportunities afforded by a particular type of PHY layer. At the same time, it must be simple enough to
`ensure that neither Base Station (BS) nor SS (Subscriber Station) are computationally overloaded.
`
`We shall now examine various BW request schemes for IEEE802.16a in light of the above observations.
`
`2.1 Background
`
`The Single Carrier mode in the 802.16a PHY uses a slotted-ALOHA-based BW request mechanism [1, pp. 58].
`According to this method, any SS that requires access to the uplink air interface must contend by transmitting
`a short packet during a reserved portion of the uplink frame. Collision-free transmissions are received as valid
`requests at the BS, which can then allocate specific slots to successful SSs to uplink during subsequent frames.
`The basic motivation for using such a scheme comes from DOCSIS, where a similar mechanism is used for
`controlling subscriber access among several simultaneous, bursty data terminals [3].
`
` While the slotted ALOHA based method offers reasonable performance in the Single carrier mode, the
`efficiency of this scheme is dramatically reduced when combined with multicarrier transmission at the PHY layer
`[4]. This is because, unlike DOCSIS, where the contention slots are all of relatively short duration ( minislots ),
`an OFDM (OFDMA) symbol is, by definition, much longer than a single carrier symbol. Furthermore, decoding a
`contention packet requires the BS to have an estimate of the SS s channel, which would require an additional
`preamble to be transmitted before each contention packet, adding further redundancy to the request process.
`Both these factors put together drastically reduce1 the efficiency of the ALOHA based scheme for
`OFDM/OFDMA.
`
`
`1 We quantify this loss more precisely in Section 5.
`
`2
`
`

`

`2001-11-12
`
`80216abc-01/61
`
` In a multi-carrier transmission, besides the time dimension, the frequency dimension is also available to
`design a BW request scheme. This observation has been used in OFDMA mode of the 802.16a PHY to design
`a BW request mechanism based on CDMA codes [5]. The proposed scheme seeks to accommodate more
`than one contending user per OFDMA symbol by providing a set of frequency domain codes that control uplink
`access via contention. We have already analyzed the PHY level robustness of this scheme in an earlier
`contribution [6], and identified several issues.
`
` The scheme that we propose in this document is based on (time) differential modulation of codes across
`disjoint frequency partitions. The use of differential transmission effectively eliminates the influence of the
`frequency selective channel, so that the use of specific codes across (frequency) subcarriers can then help to
`multiplex several contending SSs within a single symbol. In the remainder of this document, we describe this
`scheme in detail, and study its PHY-level performance over the various SUI channels [7]. We show that a three-
`dimensional grid of time, frequency and codes provides optimal performance2 as compared to other approaches
`for BW access.
`
`3. DESCRIPTION OF PROPOSED MECHANISM
`
`The proposed mechanism operates by setting up a time-frequency partition of the contention window within any
`OFDM uplink frame (cf. Fig. 1):
`
`• Along time, symbols are grouped into pairs ( contention slots ) across which differential keying takes
`place. For purposes of description, the first symbol in each contention slot is labeled 0 , and the
`following symbol in the pair is labeled 1 .
`
`• Along frequency, each symbol is divided into sets of subcarriers ( bandwidth request channels ) that
`carry the bits of a differentially keyed code. The division of the available 200 subcarriers (for 256 point
`OFDM) into bandwidth request channels is a static one i.e. determined and specified once during
`system design3. For purposes of description, the total number of subcarriers in a bandwidth request
`channel is labeled K , and the index k is used to refer to a particular subcarrier in the set.
`
`To contend for bandwidth, a SS must choose, at random:
`
`(i)
`(ii)
`(iii)
`
`A contention slot within any particular uplink frame;
`A bandwidth request channel (i.e., a set of subcarriers) within that contention slot; and
`A K-bit code, to be transmitted differentially across the subcarriers in the given contention slot.
`
`For example, let b0(k,n) denote the first (randomly chosen) bit transmitted on the kth subcarrier in the nth
`contention slot. Then
`
`
`
` ),( nkb
`1
`
`=
`
`
`
` )( ),( nkbkC
`0
`m
`
`
`
`(1)
`
`denotes the bit transmitted on the same (kth) subcarrier during the second symbol in that contention slot. Here
`{Cm(k)}k are the bits of the (K-bit) mth code, selected by the SS to transmit in that frame.
`
`The transmitted bits b0(k,n) and b1(k,n) are then received by the BS (across the frequency-selective channel) as
`r0(k,n) and r1(k,n), where
`
`
`
` ),( nkr
`0
`
`
`
` ),( nkr
`1
`
`=
`
`=
`
`
`
` ),( ),( nkHnkb
`0
`
`
`
`
`
` ),( ),( nkHnkb
`1
`
`
`
`η+
`(
`
`k
`
`),
`
`η′+
`(
`
`k
`
`).
`
`(2)
`
`(3)
`
`)(kη′
`)(kη and
` denote uncorrelated additive Gaussian noise, and H(k,n) denotes the channel transfer
`Here
`function at the kth tone, assumed to be invariant across two OFDM symbols, i.e.,
`
`2 High efficiency, simple implementation, and low false alarm rate.
`3 We discuss some performance results for various divisions later on in this document.
`
`3
`
`

`

`1
`l
`τ and complex gain
`where we have considered an L path channel with delay
`nl ,
`associated with the l th path during the nth contention slot interval [7].
`
`80216abc-01/61
`
`(4)
`
`h
`,
`nl
`
`=
`
`I
`
`h
`,
`nl
`
` hj.+
`
`
`,
`nl
`
`Q
`
`=
`
`f
`
` Tk /
`
`
`s
`
`−
`
`τπ
`.
`.2
`f
`,
`nl
`
`j
`
`nl eh ,
`
`
`
`=∑
`
`L
`
`2001-11-12
`
`
`
` nkH ),(
`
`=
`
`It is now straightforward to detect the presence (or absence) of the code C(m) on any particular bandwidth-
`request channel. A simple detection strategy that may be used for this purpose is described in the Section 4.
`
`
`
`3.1 Notation
`
`Fig. 1: Contention Slots and BW Request Channels
`
`A formal definition of the various entities introduced in this section is as follows:
`
`We define a bandwidth-request signal as the two consecutive differentially encoded OFDM symbols required
`to attempt a bandwidth request.
`
`We define a contention slot as a time duration equal to that of two OFDM symbols. We do this because there
`are two consecutive OFDM symbols required for a contending user to transmit its bandwidth-request signal in
`the proposed Multichannel Bandwidth Request Scheme. (It is coincidental that a slotted ALOHA scheme would
`also require two consecutive OFDM symbols for contention; however, in that case, the first is a preamble for
`training, and the second is a MAC header.)
`
`We define a bandwidth-request code as sequence of bits from the alphabet {1, -1} which the SS selects at
`random from an available pool to use in coding its signal. In our proposed realization, this pool contains 32
`sixteen-bit codes. The first sixteen codes are the rows of a 16x16 Hadamard-Walsh matrix. The other sixteen
`codes are their bit-wise complements.
`
`4
`
`

`

`2001-11-12
`
`80216abc-01/61
`
`We define a bandwidth-request seed as another sequence of bits from the alphabet {1, -1} which the SS
`selects at random from another available pool. In our proposed realization4, this pool contains 256 sixteen-bit
`codes, which are generated from a pseudonoise generator by taking subsequent output sequences of 16 bits.
`
`We define a bandwidth-request channel as the set of tones that form one member of a partitioning of the
`available used OFDM tones in the uplink channel. In one proposed realization, we partition the available 200
`tones of the default 256-point OFDM uplink into twelve bandwidth-request channels of sixteen tones each. The
`tones in each bandwidth-request channel are distributed uniformly across the OFDM symbol, except that eight
`tones are unused5, since 16 x 12 = 192. Note that the number of carriers in each bandwidth-request channel
`must equal the number of bits in each bandwidth-request code and seed.
`
`4. DESCRIPTION OF THE SIMULATION
`
`Simulations were done to show the performance of the proposed Multichannel Bandwidth-Request Scheme at
`the PHY level.
`
`4.1 Stimulus Generation
`
`The simulation operates by first realizing a schedule of transmissions for the desired number of contention slots
`in the simulation. The simulation operates on a system sample time = (OFDM symbol duration) / (number of FFT
`points). At each sample time, a single bandwidth-request signal may or may not occur, depending on the
`probability of such a signal at the data point being simulated. Because each contention slot is two OFDM
`symbols, this probability is equal to the average number of contending transmissions per contention slot, divided
`by twice the number of FFT points. Note that allowing only one signal per sample ignores the possibility that
`there may be multiple signals at one sample time. However, since there are hundreds of samples and only a
`handful of average bandwidth-request signals in each contention slot, this assumption results in negligible error.
`
`For each bandwidth-request signal so generated, a bandwidth-request seed, a bandwidth-request code and a
`bandwidth-request channel are randomly selected from the available pools. Finally, a SS transmitter power
`level is randomly selected from the range of ± 1.0 dB from nominal, and the signal is marked to occur in the
`contention slot nearest the instant sample time. This latter behavior mimics actual SS operation, assuming that
`the SS are already ranged well enough to delay its bandwidth-request signal so that will be received within the
`cyclic-prefix tolerance of the system, and also that it knows which OFDM symbols are available for transmitting
`the first and second symbols of a bandwidth-request signal.
`
`After the schedule of transmissions is generated, the actual simulation is run, one contention slot at a time.
`
`The first step in the actual simulation is generating the received signals. For each contention slot, the active
`bandwidth-request signals are picked out of the schedule.
`
`For each active bandwidth-request signal, a ± 1 representing the BPSK modulation of each bit in the seed is
`generated for each tone of the its bandwidth-request channel. This begins the signal received in the first OFDM
`symbol. Similarly, a ± 1 representing the BPSK modulation of each bit in the seed is generated, but in this case
`the code bit is XORed with the corresponding seed bit, effecting differential modulation. This begins the signal
`received in the second OFDM symbol. All signals are multiplied by the randomly-selected tx power level.
`Finally, a random channel is realized from the desired SUI model, and the modulation in each tone, for both the
`first and second signals, is multiplied by the complex frequency-domain channel gain from the random channel
`realization. Thus the received signal due to each active bandwidth-request signal is two vectors of complex
`numbers, one for the first OFDM symbol and one for the second.
`
`If there is more than one active bandwidth-request signal in the instant contention slot, the received signals due
`to the others are generated in the same way, and all signals are added together to form a composite receive
`signal. Note that if all active bandwidth-request signals in a given contention slot have chosen different
`bandwidth-request channels, the additions will occur on different tones, and assuming no intercarrier
`interference in the BS receiver, there will therefore be no interference among these bandwidth-request signals.
`
`4 The choice of the seed bits {b0} does not seem to affect the performance of the proposed scheme.
`5 The eight unused tones can be used very effectively for initial ranging, as will be shown in the sequel.
`
`5
`
`

`

`2001-11-12
`
`4.2 Signal Detection
`
`80216abc-01/61
`
`After so generating the received signal for a given contention slot, a BS receiver is simulated for each available
`bandwidth-request channel, for each available code in in the contention slot. The receiver computes two
`metrics. The first metric measures the error in the received signal correlated to the expected code:
`
`errCode
`
`(
`
`m
`
`)
`
`= ∑
`1
`K
`
`k
`
`where
`
`−
` ),( )( ,),( nkrkCnkr
`0
`1
`m
`
`
`
`
`
`
`
`(5)
`
`K = number of carriers in a bandwidth- request channel (proposed = 16)
`k = index on carriers
`) =
`(
`n k
` BS rx FFT output, first OFDM symbol, contention slot n, carrier k
`r
`(
`) =
` BS rx FFT output, second OFDM symbol, contention slot n, carrier k
`n k
`r
`( ) =
` code bit, code m, bit k
`C km
`
`0 1
`
`, ,
`
`The second metric measures the error in the power level relative to the expected power level of 1.0:
`
`errPower
`
`(
`
`
`
`)m
`
`= ∑
`1
`K
`
`k
`
`
`
` ),( nkr
`0
`
`2
`
`−
`
`.1
`
`(6)
`
`) could have been used as well, since both signals suffer the same
`,(Note that, in the above expression, r k n
`2
`
`0
`tx power variation and same channel instance.
`
`Finally the two errors are added together to develop a sufficient statistic:
`
`errComposi
`
`
`
`(mte
`
`)
`
`=
`
`errCode
`
`(
`
`m
`
`)
`
`α+
`
`errPower
`
`(
`
`
`
`),m
`
` (7)
`
`which is then compared with a decision threshold to determine whether or not a bandwidth-request signal is
`declared to be detected or not.
`
`For each such receiver (contention slot, bandwidth-request channel, bandwidth-request code), if the
`errComposite exceeds the allowed threshold, the result is ignored. If it does not exceed the allowed threshold,
`the result is tallied as either a (valid) detection or a false alarm. To determine which, the schedule of active
`bandwidth-request transmissions is examined. If there was only one bandwidth-request signal transmitted
`during the instant contention slot, on the instant bandwidth-request channel, using the instant bandwidth-request
`code, a valid detection is tallied. Otherwise, a false alarm is tallied. Note that if more than one SS transmit a
`bandwidth-request signal in the same contention slot, on the same bandwidth-request channel, using the same
`bandwidth-request code, and the resulting receiver errComposite is within the allowed threshold, the BS will
`make an allocation which will be claimed by all SS sending such a signal, resulting in a subsequent collision.
`Our simulation correctly models such occurrences as false alarms.
`
`After all receivers in all contention slots have been thus simulated, the final tally of detections is divided by the
`total number of bandwidth-request signals transmitted in the schedule, resulting in the probability of detection.
`The final tally of false alarms is divided by the number of contention slots simulated, resulting in the number of
`false alarms per contention slot.
`
`4.3 Summary of Basic Parameters
`
`The basic parameters common to all simulation results in this study are shown in Table 1.
`
`6
`
`

`

`2001-11-12
`
`80216abc-01/61
`
`Number of Points In FFT
`Number of lower-frequency guard tones
`Number of higher-frequency guard tones
`Channel Width
`Subcarrier Frequency Spacing
`
`Ratio of signal power to additive white Gaussian noise in
`each receiver FFT output bin
`Distribution ot SS received power levels
`Channel Model
`Number of Contention Slots simulated per scenario
`
` Table 1. Basic Parameters Common To All Simulations
`
`256
`28
`27
`6.0 MHz
`(7/6)*(6.0MHz/256) =
`27.34 KHz
`Varied from 15-99 dB
`
`Uniform over ±1.0 dB
`SUI-1, SUI-4, SUI-6
`1000 to 5000
`
`4.4 Modeling of Slotted ALOHA for Comparison
`
`The proposed scheme is similar to conventional slotted ALOHA when the number of request channels is
`reduced to one. Therefore, our simulation engine can also be used to make a fair comparison with slotted
`ALOHA. The only difference in the model is that while our model sends two differentially coded signals in the
`two symbols of the contention slot, a slotted ALOHA system sends a preamble and MAC header instead.
`However, it was verified, not surprisingly, that the 200-bit codes in our model perform exactly as the preamble
`and MAC header; that is, signals are always detected when there is no collision, and never detected when there
`is a collision. Thus, the slotted ALOHA system can be modeled, for all practical purposes, as the proposed
`Multichannel bandwidth-request system with all used carriers allocated to a single bandwidth-request channel.
`The parameters used for each system are shown in Table 2.
`
`Walsh codes are the rows of a square Hadamard-Walsh matrix. Complemented-Walsh codes are their bit-wise
`complements.
`
`Bandwidth Request
`Scheme
`Number of carriers
`per request channel
`Number of
`bandwidth-request
`channels (for 256 pt.
`OFDM)
`Codes
`
`Conventional slotted
`ALOHA
`200
`
`1
`
`8
`
`24
`
`Proposed Scheme - Options
`
`16
`
`12
`
`32
`
`6
`
`One 200-bit PN codes
`(used for convenience;
`the code choice has
`no effect)
`
`16 8-bit Walsh
`and
`complemented-
`Walsh codes
`
`32 16-bit Walsh
`and
`complemented-
`Walsh codes
`
`64 32--bit Walsh
`and
`complemented-
`Walsh codes
`
` Table 2. Simulation Parameters For Proposed Scheme vs. Slotted ALOHA
`
`4.5 Retransmissions
`
`To verify the results, we extended the simulation to include retransmissions. For these simulations, we set the
`threshold to the optimum value previously determined, and then triggered an additional bandwidth-request
`signal to be transmitted whenever one failed to be detected. A simple backoff algorithm was used, with the
`retransmission equally likely to occur in either of the following three contention slots. Again, the bandwidth-
`request code and bandwidth-request channel were selected at random from the available pools.
`
`7
`
`

`

`2001-11-12
`
`80216abc-01/61
`
`5. SIMULATION RESULTS
`
`5.1 Raw Performance (no retransmissions)
`
`The raw detection probability is a first measure of contention system performance. In this case, retransmissions
`are disabled, and thus the receiver sees only the constant average stream of bandwidth-request signals from
`the originally generated schedule.
`
`We begin with the results obtained using 32-bit bandwidth-request codes on 6 bandwidth-request channels.
`Figure 2 shows the performance at high SNR. The green curves beginning at the top left are the detection
`probability indexed on the left axis, as is the blue slotted-ALOHA curve. The red curves are the false alarm
`rates indexed on the right axis. Note that the plot has been stopped where the probability of detection falls to
`75%, since the system is becoming unuseable at this point, and the BS must start restricting traffic. Using this
`criteria, it can be seen that the slotted-ALOHA system can handle only a fifth of the traffic carried by the
`proposed scheme. Equivalently, the BS must schedule five times as many contention slots to achieve the same
`throughput as the proposed scheme.
`
`Figure 2. Performance, Proposed System with 32-bit codes, 99 dB SNR, no retransmits.
`
`The false alarm rates in this case were used to set the receive decoder s threshold, as explained in Section 6.3,
`for this code length.
`
`Figure 3 shows the performance with 15 dB additive white Gaussian noise (AWGN). Note that both detections
`and false alarms are reduced in this very noisy environment, with the false alarms in particular falling to zero.
`Obviously, if the threshold could be adapted as a function of SNR, our proposed scheme would perform even
`better. However, that may be difficult to do, since we are decoding short bursts, only two OFDM symbols, of
`unknown codes from unknown users.
`
`8
`
`

`

`2001-11-12
`
`80216abc-01/61
`
`Figure 3. Performance, Proposed System with 32-bit codes, 15 dB SNR, no retransmits.
`
`It is assumed in all figures that the slotted-ALOHA system will be completely unaffected by channel response
`and noise. That is why the blue curve and purple baseline showing, respectively, detections and false alarms,
`are the same in all figures. The blue curve agrees with some closed-form back-of-an-envelope analysis we
`have performed for this simple case, helping to validate our simulation engine.
`
`Figs. 4 through 6 show the performance of the system using 16-bit codes. Note that in these cases the
`abscissa is extended to 4 average bandwidth-request signals per contention slot, to show the additional
`capacity. This is attributed to doubling the available number of bandwidth-request channels from six to twelve.
`
`Finally, Figure 7 and Figure 8 show performance with 8-bit codes. Note the further extension of the abscissa.
`Figure 7 is stunning, showing how the proposed system can sift out six users per contention slot with 75%
`probability, while conventional slotted-ALOHA has completely died. This performance comes with a noise
`penalty, however, which is to be expected.
`
`9
`
`

`

`2001-11-12
`
`80216abc-01/61
`
`Figure 4. Performance, Proposed System with 16-bit codes, 99 dB SNR, no retransmits.
`
`Figure 5. Performance, Proposed System with 16-bit codes, 21 dB SNR, no retransmits.
`
`10
`
`

`

`2001-11-12
`
`80216abc-01/61
`
`Figure 6. Performance, Proposed System with 16-bit codes, 15 dB SNR, no retransmits.
`
`Figure 7. Performance, Proposed System with 8-bit codes, 99 dB SNR, no retransmits.
`
`11
`
`

`

`2001-11-12
`
`80216abc-01/61
`
`Figure 8. Performance, Proposed System with 8-bit codes, 27 dB SNR, no retransmits.
`
`5.2 System Performance with Retransmissions
`
`In actual system operation, the BS must control congestion in the contention channels by adjusting the
`retransmission backoff parameters and frequency of contention slots. As congestion increases, the BS may
`allocate more symbols for contention, until the UL capacity is fully utilized, but then must increase the minimum
`and maximum backoff exponents, limiting traffic.
`
`To get some idea how the different schemes would perform in practice, simulations were run with
`retransmissions enabled as described in Section 4.5. The fixed backoff exponents do not allow the BS to
`dynamically limit traffic, and although such a system would eventually melt down in practice, it was used to
`compare performance of the two schemes.
`
`Simulations were configured for each of the schemes. The proposed scheme was operated with 16-bit codes
`over a SUI-4 channel. To measure when the system was starting to melt down , triggers were set to tally a
`counter each time that more than twenty bandwidth-request signals were transmitted simultaneously on a single
`bandwidth-request channel. Twenty transmissions contending for a channel which can only carry nominally one
`is a ridiculous number, and this is taken as an indication that indeed things are starting to melt down . After
`512 such counts, a melt down was declared and the simulation aborted.
`
`To compare the two schemes, simulations of 2,500 contention slots duration were run successively with each
`bandwidth-request scheme. The melt-down counter was reset at the beginning of each simulation. In each
`simulation, the average number of contending bandwidth-request signals per contention slot (the abscissa of all
`figures in the previous section) was increased from the prior simulation. In the first simulation, it was 0.1. In the
`eight subsequent simulations, it was 0.2, 0.4, 0.8, 1.6, 2.0, 3.0, 4.0, 5.0 and 6.0 signals per contention slot.
`
`The result was that the conventional slotted ALOHA scheme melted down with 0.2 signals per slot, while the
`proposed scheme did not melt down until 2.0 signals per slot with 15 dB SNR, and not until 6.0 signals per slot
`with 99 dB SNR.
`
`12
`
`

`

`2001-11-12
`
`6. DISCUSSION
`
`6.1 Multipath Robustness
`
`80216abc-01/61
`
`We have shown in an earlier work [6] that the performance of code-based schemes on dispersive channels can
`suffer dramatically due to the frequency selectivity introduced by the channel. That study did not consider any
`additive noise, and assumed perfect power control. In the presence of such impairments, the performance can
`be expected to be further degraded.
`
`However, it is easy to see that the proposed scheme is not affected by the presence of a frequency selective
`channel, as seen in the similarity of the curves for SUI-1 and SUI-4. The performance in SUI-6 is worse but this
`is due to the fact that the present standard [1] does not accommodate the delay spread encountered on this
`channel even for its largest Cyclic prefix size. The use of differential modulation is able to show acceptable
`performance as far as bandwidth requests are concerned, even on this channel.
`
`6.2 Optimum Code Length
`
`It is apparent from the discussion and results in sec. 5 that code lengths of 8, 16 or 32 bits offer a steady
`tradeoff between capacity and robustness. In all cases, the performance is superior (by 5-20 times), when
`compared to the conventional method.
`
`6.3 False Alarm Pathology
`
`In our simulations, we tally false alarms into three categories. Recall that the BS receiver is, in fact, composed
`of multiple receivers , in a matrix of bandwidth-request channels times bandwidth-request codes. Three types
`of false alarms may be identified:
`
`(a) False alarms which occur when no bandwidth-request signal as transmitted on the receiving bandwidth-
`request channel. These false alarms are caused by noise only.
`
`(b) False alarms which occur when bandwidth-request signal(s) were transmitted on the receiving
`bandwidth-request channel, but none of them were of the receiving code.
`
`(c) False alarms which occur when two or more stations actually did transmit on the receiving bandwidth-
`request channel, using the receiving bandwidth-request code. However, these are tallied as false
`alarms since they are useless to the operator, and in fact the most undesirable type of false alarm. they
`will cause the BS to send a ranging response (RNG-RSP) message which will be answered by multiple
`SS in a subsequent collision.
`
`A typical breakdown of false alarms is shown in Figure 9.
`
`For completeness, note that between cases (b) and (c) are the cases of true detections, when only one
`bandwidth-request signal was transmitted using the receiving bandwidth-request code on the receiving
`bandwidth-request channel. If a signal such as this is detected, it is a true detection, whether or not there were
`other codes interfering with it. In most cases, interference from these other codes will prevent detection.
`
`13
`
`

`

`2001-11-12
`
`80216abc-01/61
`
`Figure 9. Typical Pathology of False Alarms. SUI-4 Channel, 15 dB SNR.
`
`6.4 Receiver Threshold Setting
`
`In simulating a receiver as we have described, the allowed threshold of errComposite setting is, of course,
`critical. Higher thresholds increase detection probabilities but also increase false alarms; lower threshold
`settings do the opposite. We assume that a conventional slotted-ALOHA system will have no false alarms; that
`is, it is virtually impossible for an OFDM preamble and MAC header to combine with other interfering
`preamble(s) and MAC header(s) and/or noise to be detected as a valid preamble and MAC header by the BS.
`The essence of our proposed scheme, however, is use the contention resource as efficiently as possible instead
`of using overkill. In such an efficient system, false alarms are possible. We expected from experience, and
`verified, that false alarms are increased at high signal-to-noise (S/N) ratio, so we set our thresholds for each
`code-length option by requiring that the false alarm rate be acceptably low when operating at a high SNR of 99
`dB. We have somewhat arbitrarily set our criteria to the following: False alarms shall occur at a rate less than
`.01 per contention slot, with the traffic frequency adjusted so that the ultimate raw probability of detection, i.e.
`that limited by collisions and not threshold setting, is greater than 75%. The latter condition comes from the
`realization that once traffic has increased to the point where the raw detection probability is less than 75%, the
`system is definitely in the danger zone and the BS is going to have to act fast to reduce congestion. The former
`condition of .01 false alarms per contention slot is admittedly, arbitrary. It seems that such a number would not
`impose too much congestion and is thought to be conservative.
`
`It was found that the longer the code (recall that we simulated 32, 16 and 8 bits), the higher the error tolerance
`threshold should be.
`
`We also tried some simulations using fewer codes, and using more codes which are available from a
`pseudonoise (PN) generator. The performance was found to be not as good, and these studies were
`discontinued.
`
`14
`
`

`

`2001-11-12
`
`7. CONCLUSIONS AND REMARKS
`
`80216abc-01/61
`
`A fast and efficient bandwidth request mechanism is presented for the OFDM mode of the IEEE

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket