throbber
Exhibit 1006
`
`ZTE Corporation and ZTE (USA) Inc.
`
`

`
`Inv. No. 337-TA-868
`
`RX-3305
`
`ETSI SMG2 UMTS L1 Expert Group
`
`Tdoc SMG2 UMTS—Ll 683/98
`
`Espoo, Finland
`14-18 December 1998
`
`Source: Motorola
`
`Mechanisms for managing uplink
`interference and bandwidth.
`
`Abstract
`
`This paper introduces the concept ofdynamic persistence as a backoff algorithm for the RACH reducing the risk
`of outages and improving RACH performance. Also, an uplink shared channel
`is proposed for providing
`scheduling flexibility to better support mixed traffic types.
`Finally, the size and structure of a composite
`downlink common control channel is discussed supporting feedback and control for both uplink and downlink
`packet data transfers.
`
`1.0 Introduction
`
`Recent papers regarding the RACH have concentrated on remedies for open-loop power control suggesting both
`faster feedback mechanisms and power ramping as solutions [l][2][3]. Power control is an important factor that
`should not be neglected, however, the impact of congestion and the interaction of mixed traffic types has not
`received adequate attention. This Tdoc proposes two strategies to aid interference and bandwidth management
`on both the RACH and during b11lk transfers. The congestion and mixed traffic may impact the RACH chamiel
`in the following ways.
`
`0
`
`0
`
`Periods of high load will cause congestion on the RACH. Although CDMA greatly reduces the likelihood
`of an irresolvable collision,
`the aggregate interference power produced by a score of subscribers can
`potentially exceed the allowable noise rise at the Node B. As a result, all users in the cell would experience
`an outage that the Node B cannot mitigate.
`
`The interaction of mixed traffic may reduce the average quality of service by favoring users making bulk
`transfers on the uplink while relegating the shorter interactive messages to a congested RACH. With the
`currently defined mechanisms, file transfers or large emails would be assigned DCHs and could effectively
`consume the majority of the uplink packet data capacity during periods of high loading. Moderate and small
`transfers would be relegated to a congested RACH and suffer from undue delay.
`
`2.0 Congestion Management of RACH channel
`Local Area Networks [LANs) carrying packet data have traditionally relied on distributed backoff algorithms for
`managing congestion on the system. Likewise, cellular systems employ distributed backoff algorithms for the
`common access channel e.g. GSM’s RACH. For FDMA systems, the impact of congestion is tolerable. A
`congested access channel will
`increase the call set-up time by escalating the backoff delay of backlogged
`subscribers until congestion is eventually resolved (even o11 an ill tuned system).
`In an FDMA system,
`subscribers assigned channels will be not be affected by the congestion because the quality of their circuit is
`protected by the frequency separation.
`In a CDMA system congestion on the RACH will increase the noise rise
`at the Node B and, at times, may produce outages that effect all users in the system, both backlogged users and
`those assigned dedicated channels.
`As a precaution,
`the parameters of the backoff algorithm may be
`conservatively assigned to reduce the likelihood of destructive congestion, however, the cost would be an overall
`reduction in performance. What’s more, the variety of data services and the potential for new yet unknown
`services may make it
`impossible to identify the appropriate parameters for a well-tuned RACH backoff
`algorithm. A more sensible approach would take advantage of the centralized architecture of a cellular system
`
`NK868|TCO17317124
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1006-00001
`
`

`
`and allow the system to dynamically manage the backoff of all subscribers based on estimates of the congestion
`in the cell.
`In essence, a closed loop backoff algorithm could be formed where the system proactively prevents
`destructive interference from occurring during times of high load without compromising the mean performance
`of the system.
`
`A dynamic persistence algorithm is proposed for managing interference and minimizing delay by controlling
`access to the RACH channel of the system. On a common downlink channel,
`the system will publish a
`persistence value, p, the value being dependent on the estimated backlog of users in the system [4]. The
`persistence value would be broadcast at regular intervals e. g. once per frame. A UE in an active data session
`would first read the current persistence value and transmit on the next available RACH slot with a probability, p.
`When the system detects congestion on the RACH, the published persistence value would be reduced decreasing
`the number of users transmitting on the RACH in any given frame. During periods of inactivity the probability
`would be increased in order to improve the overall access delay. The elegance of the approach is that the
`backoff is handled deterministically based on a noise rise at the Node B. Whats more, the system may take
`multiple factors into account when calculating the persistence value such as data traffic patterns, recent history,
`and adjacent cell loading. Furthermore, having the system compute the dynamic persistence rather than the UE,
`provides the system operator greater flexibility in managing the RACH.
`
`The cost of publishing a dynamic persistence value would be small in terms of both complexity and capacity.
`Previously, a common channel for providing fast power control feedback to UEs accessing the RACH has been
`discussed [5]. A persistence value could be conveyed by using a few bits in a common downlink channel.
`Furthermore, the power assigned to this common channel could be conservative. UEs at the fringe of coverage
`pose a smaller threat of causing an outage and therefore the system will tolerate the diminished integrity of the
`persistence information. Although UEs near the center of the cell would pose a greater risk for causing outages,
`the risk would be mitigated by a more reliable downlink common channel carrying persistence information.
`
`Variations on dynamic persistence may provide other benefits such as a solution for managing different QoS
`data streams. UEs with a higher QoS might augment the persistence value they employ by an assigned QoS
`factor and transmit with a higher probability than the bulk-rate traffic.
`
`3.0 Managing mixed traffic types
`An earlier Tdoc [6] presented analysis and simulation that showed that “Internet” users will receive the optimum
`perceived quality of service when packets are scheduled using the broadest pipe possible.
`Several Tdocs
`[7][8][9][l0] presented methods for providing a broad pipe on the downlink using a shared channel. On the
`uplink a similar mechanism is required to allow scheduling of the uplink resource using the broad pipe.
`
`Currently in the specified mechanisms for managing the uplink resource, it is only possible to react to changes in
`user requirements very slowly (especially if time-outs are employed). This results because of the need for
`signaling negotiation between cell-specific RRC in the CRNC(s) and user specific RRC in the SRNC every time
`that the power assigned to a user is to be changed.
`It is important that the percentage time spent releasing and re-
`assigning resource is kept to a miiiiiiiuiii in order for the uplink capacity to be well utilized. Therefore, the above
`observation implies that in order to minimize the percentage time spent in re-assignment of capacity, users
`should hold the channel for a relatively long period of time (in other words transmit at a low rate).
`In addition,
`the current documents state a UE is autonomously allowed to decide at what bit rate it will transmit at (within
`the allowed TFCS). This tends to imply a reliance on a statistical averaging of bandwidth requirements between
`the transmissions of different packet users. Reliance on statistical averaging is only possible when the number
`of users is great. Clearly, the current mechanisms for managing access to the uplink resource implicitly imply
`the use of multiple thin pipes. To summarize, it is clear that there are a number of problems with the current
`proposals for managing access to the uplink resource for packet users:
`
`1. Lack of fast access control (assignment and re-assignment) will result in poor utilization of uplink
`capacity.
`
`2. The currently defined mechanisms are biased toward the use of multiple thin pipes
`
`0 Resulting on average in a longer delay for packet transmissions as perceived by the user (see
`companion paper [6]).
`
`0 Resulting in a loss of flexibility in prioritizing the transmission of packets from different users.
`
`The loss of flexibility in prioritizing the transmission of packets from different users occurs because current
`uplink packet data procedures tend to favor bulk transfers over infrequent acknowledgements or requests. The
`problem is exacerbated when the system is under a condition of high loading. As an illustration consider the
`
`NK868|TCO1731 7125
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1006-00002
`
`

`
`case where one UE, referred to as UEemai1, is transferring large email on a heavily loaded system and where
`several other UEs have moderate-sized infrequent traffic (moderate-size is greater than a few RACH bursts).
`UESW,-1 would typically be assigned a DCH for the transfer.
`In the absence of other traffic, the system should
`assign the broadest pipe possible to expedite the transfer. Learning the interference margin at the base, users
`making infrequent transfers (which may be of higher priority) would be relegated to the lowest data-rate
`available for the duration of Uiemaifs transfer. Of course the system could reserve more capacity for the
`infrequent transfers, but this would be sub-optimum solution since capacity would go unused prolonging
`UESIW-1’s transfer. Overall system performance could be improved by providing a scheduling mechanism that
`allowed uplink capacity to reallocate in an expeditious manner.
`
`4.0 Proposed MAC based scheme for dynamic scheduling between users
`Before discussing the motivation for performing dynamic scheduling between users on the MAC layer it is first
`worth stating that it is assumed that the uplink shared channel (USCH) to be described will be used by packet
`users.
`It is an assumption (as is the case for the DSCH and as was assumed in the evaluation documents) that
`packet users can be operated efficiently in hard hand-off due to the extra delay budget available and the
`consequent capability to use ARQ.
`
`A method for allocating uplink capacity is proposed that mimics the features of the downlink shared channel
`which allow for a broad pipe and nimble scheduling. Unlike the downlink, there is no shortage of orthogonal
`codes to manage, however, there is finite allowable noise rise at the Node B.
`It is proposed that the system
`apportion interference power for uplink packet scheduling in a similar manner to how codes are assigned in the
`downlink. This differs from noise rise published on the BCCH in that the system budgets UE access based on
`the known UE queue depths in a deterministic rather than a probabilistic manor. Ideally, the UE would transmit
`at the maximum data rate that is commensurate with the apportioned noise rise at the Node B. The maximum
`data rate is a function of the apportioned noise rise and the total interference power incident at the Node B.
`From these variables, the system can calculate the target Eb/Nt on the uplink and with the knowledge of link
`performance calculate the maximum sustainable data-rate. The spreading factor could be assigned on a common
`downlink broadcast transport channel called the Access Control Channel (ACCH) which will be described in
`more detail later. Each allocation would be valid for the duration of one frame allowing for the flexible
`reassignment of resources. With this fast assignment mechanism in place, bandwidth could be managed more
`efficiently allowing a scheduler to multiplex a mix of traffic types.
`
`Table 1 examines the overhead associated with conveying the uplink resource assignments. An assignment may
`be made in as few as 12 bits consisting of a Temporary UE ID (TUEID), a Spreading Factor Assignment (SFA),
`and Power Control Position Assignment (PCPA). A 6-bit TUEID would provide resolution equivalent to the
`GPRS slot assignment plus USF. A TUEID would last the duration the UE was in the active state. The NRA
`(Noise Rise Apportionment) value would represent a quantized assignment of the noise rise apportioned to the
`UE for the duration of one frame. Finally, the PCPA assigns a position in a common power control channel for
`the duration that a NRA is valid [1 1].
`Table 1
`
`
`
`PCPA
`
`Total
`
`Bits
`
`6
`
`3
`
`3
`
`1 2
`
`Reference
`
`A 6-bit temporary ID providing equivalent resolution
`as GPRS (Slot+USF <=> 3 + 3) used to identify an
`allocation.
`
`Assigns the spreading factor for the next frame.
`
`Assigns a position in the common power control
`channel for the duration of the transfer.
`
`UEs with data to send would perform the following procedure:
`
`1) At the beginning of a session or packet call the UE would send an initial request on the RACH carrying a
`reservation request containing the queue depth. The exact encoding of the queue depth information and
`other information which may be required is FFS_
`
`2) A TUEID would be assigned
`
`NK868|TCO1731 7126
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1006-00003
`
`

`
`3) UEs would then monitor the ACCH for a SFA.
`
`4) Upon receiving an assignment, UEs would use measured information on the path loss and SFA to calculate
`the initial transmit power.
`
`5) The UEs would then transfer the data on the USCH while performing fast power control using a common
`power control channel as indicated on the PCPA. As part of the transfer the UE may also piggyback queue
`depth information, this and other potential techniques for uplink signaling are FFS.
`
`6) The UE would continue to monitor the ACCH for subsequent SFAs until the queues are empty.
`
`The use of the ACCH for managing multiple traffic types in the uplink provides many benefits to the UMTS
`system. Scheduling of traffic is centralized allowing the system to better manage utilization. System control
`allows the scheduling to be adjusted on a frame by frame basis accommodating new reservation requests with
`varying levels of QoS. UEs with a higher priority and lower delay tolerance could be apportioned power before
`users transferring bulk-rate traffic. Finally, the system is better able to manage varying traffic types during
`periods of congestion.
`
`5.0 Sizing the Downlink Shared Control Channel
`It
`is proposed to aggregate the functions of power control, dynamic persistence, downlink OVSF code
`assignment and uplink noise rise apportionment onto the downlink access control channel (ACCH) .
`It is
`proposed that the ACCH transport channel be carried over a third common control physical channel referred to
`as the Tertiary Common Control Channel Physical Channel. This tertiary CCPCH is efficient in terms of code
`usage and provides scheduling flexibility.
`
`The tertiary CCPCH would carry Common
`illustrates a proposed structure for a Tertiary CCPCH.
`Figure 1
`Transmit Power Control (CTPC) information, a Dynamic Persistence Indication (DPI), Common OVSF Code
`Assignments [12] and uplink spreading factor assignments (SFA). For flexibility, it is assumed that the tertiary
`CPCCH may operate at multiple spreading factors and be sized appropriately depending on tie traffic load in the
`cell (the rate and spreading factor of the tertiary CCPCH would be broadcast on the BCH). Each Power Control
`Group (PCG) slot will contain pilot information and 8 power control feedback bits for each of a maximum of 8
`individual UEs transmitting on the uplink.
`The remaining bits per PCG may be encoded with rate l/3
`convolution code and interleaved over the 10 ms frame to enhance the reliability of the DPI, and the DSCH and
`USCH assignment information. The tertiary CCPCH is not power controlled and is transmitted over the entire
`cell.
`
`‘NPi1Ot* NTPC <eND,,,T>
`TPC
`TPC
`TPC
`TPC
`TPC
`TPC
`TPC
`TPC
`.
`.
`Pilot
`
`
`
`#0
`#1
`#2
`#3
`#4
`#5
`#6
`#7
`Coded Assignment Information
` 0.625 ins, 2o*2k bits (k:O..6)
`
`
`
`Frame #72
`
`Figure l The structure of the Tertiary CCPCH
`
`Starting with a
`Table 2 examines the number of UEs that can be serviced for varying spreading factors.
`spreading factor and considering the structure of the tertiary CPCCH illustrated in Figure l, the table first
`calculates the available coded information bits per PCG slot, Ndata_ The fields Npilot and NTPC represent the
`number of bits assigned to pilot and power control feedback, respectively. Next, the maximum number of
`available information bits per frame is calculated based on the frame rate, CRC, tail, and coding rate. Finally,
`the number of assignments per frame is calculated by dividing the difference of information bits minus DPI by
`
`NK868|TCO1731 7127
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1006-00004
`
`

`
`the sum of one DOCA and UPA assignment. The Downlink OVSF code Assignment per user is defined in [12].
`The UPA was defined earlier in Table 1.
`
`At a minimum the tertiary CCPCH will require a spreading factor of 128 accommodating 3 UEs in both direction
`or 6 UEs in one direction. A spreading factor of 64 should be large enough to service most needs
`accommodating 11 UEs. As an alternative, a rate 1/2 code is considered providing an assignment of 6 UEs in
`both directions or maximum of 12 in either.
`
`Table 2 Calculation of the number of UEs supported for various spreading factors and coding rates.
`
`S"’ea"'“9
`Factor
`256
`128
`64
`128
`
`N
`
`pm
`8
`8
`8
`8
`
`N
`
`WC
`8
`8
`8
`8
`
`Ndata
`4
`24
`64
`24
`
`Re itition
`p
`1
`3
`1
`0
`
`9
`
`Codin
`1/3
`1/3
`1/3
`1/2
`
`(ms)
`10
`10
`10
`10
`
`CRC
`16
`16
`16
`16
`
`Tail
`8
`8
`8
`8
`
`'”f° MS
`available
`.3
`103
`317
`168
`
`DPI
`10
`10
`10
`10
`
`DOCA/user UPA/user
`13
`12
`13
`12
`13
`12
`13
`12
`
`Users
`o
`3
`12
`6
`
`6.0 Conclusion
`
`Several mechanisms for managing bandwidth and interference have been proposed. A dynamic persistence
`mode offers a sensible approach for controlling congestion on the RACH taking advantage of the centralized
`architecture of a cellular system and allowing the network to dynamically manage the backoff of all subscribers
`based on estimates of the congestion in the cell. A centralized uplink packet scheduling policy was proposed
`that apportions noise rise to UEs allowing the system to schedule traffic on the broadest possible pipe and
`allowing scheduling to be adjusted for varying levels of Quality of Service. As a result, the system is better able
`to manage varying traffic types during periods of congestion. Finally, the size of a common downlink control
`channel supporting all UCD traffic inechanisins is examined showing that all
`the assigrniierits may be
`accommodated on a channel operating at a spreading factor of 64 or 128.
`
`7.0 Proposed modifications to standards
`
`Add a section after section 5.3.2.2 ofXX. 03
`7.1
`5.3.2.x Tertiary Common Control Physical Channel
`
`The tertiary CCPCH is used to carry downlink access control channel (ACCH) information. The ACCH
`aggregates the functions of uplink power control for packet data users, OVSF code assignment, dynamic
`persistence and noise rise apportionment. The ACCH is a low fixed rate channel (32 ksps or 64 ksps) which is
`coded and interleaved. The rate of ACCH may be different from cell to cell. The rate and spreading factor of the
`ACCH is broadcast on the BCCH. The frame structure of the ACCH is shown in Figure x {refer Figure 1 of
`above}. The ACCH is not power controlled and is transmitted over the entire cell when there are data packets to
`transmit on downlink or uplink or on both directions.
`
`NK868|TCO17317128
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1006-00005
`
`

`
`7.2
`
`Modijfjz thefigure 11 in section 6 ofXX. 03
`
`Transport Channels
`
`Physical Channels
`
`BCCH Primary Common Control Physical Channel (Primary CCPCH)
`
`FACH
`PCH _:
`ACCH Tertiary Common Control Physical Channel (Tertiary CCPCH)
`
`Secondary Common Control Physical Channel (Secondary CCPCH)
`
`RACH Physical Random Access Channel (PRACH)
`
`DCH Dedicated Physical Data Charmel (DPDCH)
`
`Dedicated Physical Control Channel (DPCCH)
`
`Synchronisation Channel (SCH)
`
`Figure11: Transport-channel to physical-channel mapping.
`
`
`
`7.3
`
`Add abbreviation in Section 3.3 ofXX.07
`
`ACCH
`
`Access Control Channel
`
`7.4
`
`Addfollowing steps to the random access procedure in Section 6 ofXX. 07
`
`3. The mobile station reads the ACCH to get information about:
`
`3 .1 The current dynamic persistence Value.
`
`8.0 References
`
`[1] Ericsson, “Modifications of the current RACH scheme for increased throughput”, SMG2 UMTS-L1 455/98.
`] Philips, “Modification to the RACH Scheme”, SMG2 UMTS-L1 533/98.
`]
`\/lotorola, “Comparisons of power ramping schemes for RACH”, SMG2 UMTS-L1 564/98.
`] Sampath, Mandayam, and Holtzman, “Analysis of an Access Control Mechanism for Data Traffic in an
`Integrated Voice/Data Wireless CDMA System”, VTC 1996
`\/lotorola, “Comparison of techniques for fast power control in FDD”, SMG2 UMTS L1 565/98
`]
`\/lotorola, “Channel Bandwidth Allocation Strategy”, SMG2 UMTS L23 534/98
`]
`\Tol<ia, “Efficient Radio Resource Usage with Shared Channels”, SMG2 UMTS L1 423/98
`]
`] Lucent, “Downlink Shared Channel (DSCH) Transmission”, SMG2 UMTS L1 436/98
`] Sony lntemational, “Multiplexing packet Data in FDD mode”, SMG2 UMTS L23 266/98
`0]\Iortel, “Analysis of the available proposals for shared channels and proposed merged solution”, SMG 2
`UMTS L1 584/98
`
`[11]\/lotorola, “Common power control charmel for UMTS FDD”, SMG 2 UMTS L1 440/98
`[12] \/Iotorola, “Shared Channel Options for Downlink Packet Data Transmission,” SMG 2 UMTS L23 533/98
`
`NK868|TCO1731 7129
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1006-00006

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