Exhibit 1031
`
`ZTE Corporation and ZTE (USA) Inc.
`
`

`

`Inv. No. 337-TA-868
`
`RX-3302
`
`032/99
`
`3GPP RAN WGZ
`Helsinki
`
`20-22 January 1999
`Agenda item:
`Source: Motorola
`
`Benefits of the Uplink Shared CHannel (USCH)
`
`1
`
`Introduction
`
`Within the ETSI SMGZ/Layer 2/3 experts group, the requirement for a Downlink Shared CHaImel (DSCH) has been
`identified and an agreed description of the concept has been included in the documentation. Motorola believes that
`most of the reasons for using a shared channel in the downlink also apply in the uplink.
`
`Therefore, in this paper, a brief description of the Uplink Shared Cl-lannel (USCH) is provided. The advantages of
`using MAC to arbitrate access between packet data users on a shared channel compared to the alternative of using
`RRC controlled access to DCH's is explained. The qualitative discussion provided complements the more detailed
`simulation results and concept description presented in the previous meeting [1,2]. Finally, the consequences on
`complexity etc. of adopting the USCH concept are outlined,
`
`2 The Uplink Shared Channel
`
`In the case of the USCH there
`The DSCH represents a power and code resource which is shared between users [3].
`is no short code limitation (each UE will have its own scrambling code), however, there is still a limited power
`resource, hence the USCH represents a shared power resource. The motivation for the USCH is essentially the same
`as that for the DSCH, As with the DSCH it is proposed that access to the USCH is managed by a MAC-sh entity in
`the CRNC [l].
`
`3 Advantages of the shared channel concept for packet support
`
`In this section the benefits of the shared channel approach for supporting packet connections are listed. The benefits
`are described in comparison with the altemative of using DCH's controlled by RC.
`
`3.1 Spectral efficiency and packet call delay are much less dependent an
`imperfect admission control
`
`When RRC admits a new packet call on a DCH it has to assign a bit rate to the DCH on the basis of only minimal
`information (ie. admission is based on RRC's prediction of the connection's future requirements). If the assigned bit
`rate is too high then capacity will be wasted (there is a dis-continuous transmission). This problem is shown in
`Figure 1, see the case where the RRC chooses DCH rate #1. With the shared channel concept the resource will
`always be fully used in every frame (assuming of course that there are packets requiring transmission).
`
`In order to avoid the problem of assigning a DCH which is too large, RRC will sometimes assign a DCH which has
`a bit rate which tums out to be too low. In this case, the DCH is more likely to be fully used (and transmission will
`be more continuous), however, the packet call will take longer to complete, This problem is shown in Figure 1, this
`time look at the case where the RRC chooses DCH rate #4. With the shared channel, packet calls will always be
`completed at least as quickly as is the case with RC based control, and on the average will be completed more
`quickly [2].
`
`NK868ITCO’I7317090
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1031-00001
`
`

`

`Sometimes, the situation will occur where the assignment of a DCH would have been acceptable, see Figure 1, when
`DCH#3 is chosen. However, this will occur only very infrequently, being dependent on the actual packet arrival
`within the packet call and dependent on an imperfect RRC packet call admission procedure.
`
`It is worth making some comments with regards to whether there might be a way of assigning a high data rate DCH
`in such a way that the system can still be operated efficiently (ie when DCH bit rate #1 is chosen, Figure 1). Whilst
`it is true that dis-continuous transmission can be exploited (and extra packet calls admitted) it is only possible to do
`this efficiently if there are many users active such that it is possible to rely on statistical averaging. DTX is
`exploited in this way in voice-only CDMA systems where the number of simultaneously active users runs to many
`10's or 100's. However, the argument does not work well in a packet context. In a packet context if there are many
`users active then the bit rate of the assigned data pipes will have to be low, meaning that packet transfer times are
`increased (and essentially the transmission is not really dis-continuous anyway).
`
`Packets
`arriving
`from the
`NAS
`
`Bit
`rate
`
`DCH bit
`rate #1
`
`I
`
`
`
` DCH bit
`
`
`
`I
`I
`I
`
`
`
`
`
`
`
`
`II Gaps betweenI I I
`
`
`
`A/
`transmission of
`I I. H I.
`packets represents
`wasted resource
`
`
`
`DCH bit
`rate #2
`
`rate #3
`
`DCH bit
`rate #4
`
`I
`
`Q I
`
`Delay in completing the
`packet call is now large
`
`Figure 1) Figure showing the difficulty in assigning a DCH of the correct rate to carry packet data, if RRC assigns
`bit rate #1 or #2 then capacity is wasted, if it assigns bit rate #4 then the packet call takes much longer to complete
`
`Note that this paper includes an Appendix which describes the terminology used in this paper along with traffic
`models for some of the most popular existing services including email, FTP and Web browsing.
`It can be seen that
`packets will be delivered to the Access Stratum in a very bursty manner (as indicated in Figure 1), this emphasises
`the importance of using fast MAC layer scheduling in order that these services (and others not yet conceived) are
`supported efficiently and with the best possible QoS.
`
`3.2 Highest priority packets are always served first
`
`When RRC based control of packet users on DCH's is used then it will often be the case that a high priority packet
`call will be queued, waiting for a lower priority packet call to release its DCH (see Figure 2). By using the shared
`channel to support packet users, highest priority packets always get served first, irrespective of which UE the
`packets are going to/from and this therefore improves quality of service (see Figure 3).
`
`NK868ITCO17317091
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1031-00002
`
`

`

`Low priority packets being served even
`though high priority packem are queued
`
`Low priority
`
`High priority
`
`Queue for user I
`
` Queue for user C
`
`H
`
`H
`
`Queued packets
`from user A
`
`Queued packets
`from user F
`
`1
`
`Queue for user B
`
`
`
`
`
`
`4
`
`Newly arrived packet calls which have no
`DCH assigned through lack of capacity.
`The calls are queued whilst waiting for
`one of the assigned DCH's to clear down
`(or be forcibly re-assigned by RRC)
`
`I
`
`/
`
`I
`
`Queue foruserK
`
`I
`
`
`
`
`
`
`
`DCH assigned to user, but without any packets
`queued (eg. when awaiting for RRC timer to expire)
`
`T
`Individual
`DCH’s
`
`Figure 2) RC based scheduling between users on DCH's
`
`A T
`
`Low priority packets
`
` T
`
`High priority packem
`
`A single queue, in which packets
`from differentusers (A, D, F etc)
`can all be arranged in priority order
`
`TFat shared
`pipe
`
`Figure 3) MAC scheduling onto a fat shared pipe (using cross-user MAC/DSCH), note highest priority packets get
`served first (irrespective of user)
`
`NK868ITCO17317092
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1031-00003
`
`

`

`3.3 Capacity is not wasted whilst DCH's are being released and re-assigned
`
`It is worth re-iterating that with RRC based control on DCH's capacity will often go wasted whilst the RRC decides
`whether to either change the size of the DCH or release it (this is well demonstrated in Figure 2 in which the queue
`for User B is empty, but the DCH is still assigned awaiting for an RC timer to expire).
`
`When the decision is made to release the DCH, then it will be necessary to initiate a number of RRC procedures to
`firstly release the DCH and then to re-assign the capacity/code etc. to another user. There will be further delay
`whilst the PHY, MAC and possibly RLC are re-configured for the new 'owner' of the resource. All this time, the
`resource is not being utilised.
`
`It is also worth pointing out that RRC will on occasion release DCH's before the packet call is actually completed,
`this will also have a detrimental impact on packet call completion times.
`
`3.4 More efficient capacity packing - Better spectrum efficiency
`
`Downlink
`
`To explain this benefit of the shared channel approach consider the example of carrying packet data connections in
`the downlink. Consider first the case where multiple DCH's are used to carry packet connections. When a new
`packet call arrives from the NAS, then if the packet call can be admitted the UTRAN—RRC assigns a proportion of
`the total downlink power to that UE. However, in making that allocation it is necessary to include a margin to
`account for variations in the transmit power on each of the connections which will result from changes in
`propagation loss and interference as the call progresses (both fast and slow changes).
`
`With the shared channel concept it would be possible to take into account variations in mean propagation and
`interference conditions (with a resolution of a few 10's of ms) when performing the scheduling. It would therefore
`be possible to avoid having to use such a large margin. Put another way, the proportion of power assigned to the
`shared channel could be packed more efficiently and there would be an increase in capacity.
`
`M I
`
`n the uplink the situation is rather different, however, there are still similar opportunities to exploit. With the shared
`charmel concept the possibility exists to dynamically vary the size of the shared charmel in response to rapid changes
`in conditions. For example, the CRNC could temporarily increase the size of the shared channel for a period of a
`few frames if it knows, for example, that voice user DCH's are being re-assigned and that capacity would otherwise
`be wasted. Such responsiveness would not be so easy to achieve with an RRC-DCH based approach.
`
`4 Comments on the requirement for efficiency in the uplink
`
`Motorola believes that UMTS should be designed to make as efficient use of the uplink resource as possible.
`However, it is reasonable to raise the question, is there really a capacity limit in the uplink?, is there a service
`requirement for completing packet call transmissions quickly?
`
`In answer to the first question, mobile radio spectrum is a very valuable (and expensive) resource, naturally
`operators will want to ensure that it is well used.
`It should also be noted that it is always difficult to envisage what
`future service requirements will be, however, we should ensure that UMTS can efficiently support whatever services
`become popular. One can certainly anticipate, that once an operator has paid a lot of money for spectrum, his
`pricing strategy will be such as to encourage the use of uplink services so that the spectnnn is very well utilised.
`
`NK868ITCO17317093
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1031-00004
`
`

`

`In terms of the second question concerning delay aspects it must be noted that a pure best effort service with no
`constraint on delay will generally not be acceptable. For example, in the case of a typical internet connection where
`an end to end TCP protocol is in use it is important that certain delay targets be met in order to avoid TCP window
`size back-offs etc. which will affect the speed of completion of the call. Note, therefore that even when using an
`application which principally requires downlink transmission (eg web-page download), the TCP protocol will be bi-
`directional. Thus a poorly performing uplink could also have an affect on perceived QoS of not only uplink services
`but also downlink services.
`
`5 Costs associated with uplink shared channel
`
`There are many advantages to the shared channel concept, but these do come at some cost. In this section the
`requirements imposed in order to implement the USCH are discussed.
`
`An analysis of the implications of supporting the USCH depend to some extent on the method chosen for the UE to
`signal its requirements and for the network to signal allocations. Two alternatives have been proposed, either
`signalling can be conveyed over an associated DCH or else on a common signalling channel, eg. the Access Control
`CHannel (ACCH) as proposed by Motorola at the last meeting [1]. Motorola believes that there are many benefits
`to be gained by using the ACCH for signalling and we do not recommend the use of associated DCH's for
`signalling, the reasons are discussed in a companion paper [13].
`
`5.1 Requirement for fast signalling
`
`The MAC-sh scheduler will make assignments based on measurements of physical parameters such as interference.
`Capacity is improved as the delay is reduced between this measurement information becoming available and the
`signalling of the allocations. Therefore the current assumption is that, as with GPRS, MAC assignments would be
`sent in unacknowledged mode. A consequence of this is that there will on occasion be errors in the messages (which
`will be detectable), however, it means that occasionally resource will be unused and packets will have to be re-
`scheduled for a later time.
`
`Since capacity is re-allocated on the shared channel on a frame by frame basis the frequency with which signalling
`information is conveyed over the air will be greater than is the case with the RRC based control. However, the size
`of the signalling messages will be smaller than the RRC messages which will also be subject to re-transmission
`since they are generally sent in acknowledged mode.
`In [1] Motorola proposed to use a single common tertiary
`physical control channel for carrying both USCH and DSCH assignments and power control information.
`It was
`shown that it would be possible to send (in each frame) assignment messages and power control commands for 3
`UEs transmitting in both directions with a SF of only 128.
`It can be concluded that the signalling overhead
`associated with the USCH concept is not a significant factor.
`
`5.2 Multi-code impact on UE's
`
`Another concern that has been raised is whether there are any implications with regards to UE complexity in terms
`of multi-code transmission and reception requirements. In Table l, the number of uplink and downlink codes
`required for various service mixes is calculated for the case where signalling is carried over the ACCH. From Table
`1 it can be seen that the alternative of using shared channels with signaling on the ACCH compares very favourably
`to the situation where RRC is used to control access to DCH's (Table 2). The only difference is in the last row of the
`tables, where a UE may have to listen to 3 codes when using the USCH instead of 2. Since this is only the case
`whilst the voice call is active it will have little impact on battery life and from a complexity point of view this should
`not be a significant problem for the mid-range to high-end terminals capable of supporting simultaneous voice and
`packet connections.
`
`NK868ITCO17317094
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1031-00005
`
`

`

`Services carried
`
`Number of uplink codes to be
`transmitted by the UE
`
`Number of downlink codes to
`be received in UE
`
`
`
`Voice+ U/L packet
`
`2 (USCH--DCH)
`
`2 (ACCH+DCH)
`
`Voice+ U/L and D/L packet
`
`2 (USCH--DCH)
`
`3 (ACCH+DCH+DSCH)
`
`Table 1) UE multi-code requirements where the USCH is used to carry packet data and signalling is carried over the
`ACCH
`
`Services carried
`
`Number of uplink codes to be
`transmitted by the UE
`
`Number of downlink codes to
`be received by the UE
`
`Packet only
`
`1 (DCH)
`
`1 (DCH)
`
`Voice+ U/L packet
`
`2 (DCH-Hi QoS, DCH-Lo QoS)
`
`2 (DCH-Hi QoS, DCH—Lo QoS)
`
`2 (DCH-Hi QoS, DCH—Lo QoS)
`
`Voice+ U/L and D/L packet
`
`2 (DCH-Hi QoS, DCH-Lo QoS)
`
`Table 2) UE multi-code requirements where packets are conveyed on DCH‘s
`
`5.3 Layer 1 impacts
`
`Solutions for all of the PHY layer issues which were raised in the last meeting are presented in a companion paper
`[5].
`
`6 Conclusion
`
`Traditionally, one of the main functions of MAC has been to arbitrate access BETWEEN users (this is true of the
`vast majority of communication systems including ethernet,
`token ring, GPRS, HiperLAN etc. etc.).
`The
`requirement and benefits of MAC layer scheduling between users on the downlink has already been agreed and this
`is reflected in the DSCH concept. Motorola believes that very similar arguments apply in the uplink.
`
`The USCH channel provides a whole range of benefits which will ensure that packet connections are supported
`efficiently over UMTS.
`It is felt that the benefits of a shared channel in the uplink far outweigh the costs.
`
`Given the tight standardisation deadlines Motorola feels that the concept of the Uplink Shared CHannel (USCH) and
`its associated common channel signalling scheme (ACCH) should be included in the Layer 2/3 groups
`documentation as soon as possible. A companion paper contains some proposed change requests [14].
`
`7 Appendix -Traffic models
`
`In considering the requirement for fast scheduling on the MAC layer it is also necessary to have an appreciation of
`the packet call arrival statistics. In this section some models are described which have been used in previous studies
`by ETSI [6] and TIA[7]. The models describe Email, Web browser and FTP users.
`
`For this paper, a “Session” is considered to cover the time an individual logs on to a service until the time that the
`user terminates the service. A session is made up of one or more information transfers that shall be call “Packet
`Call” in the paper. A packet call further breaks down into packets. Packets are segmentation of the packet call. The
`application type determines the distribution of packet sizes. Over the air interface the packet are further segmented
`into frames the size of which is determined by the air interface.
`
`NK868ITCO17317095
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1031-00006
`
`

`

`Email and FTP usage are both defined as single packet call sessions. Session arrivals have a Poisson distribution.
`An email packet call has an average of 15 packets. Each packet is fixed at 158 bytes. An FTP packet call, on the
`other hand, is much larger and on average there are 525 packets in a packet call. Each of the FTP packets is fixed at
`338 bytes.
`
`Web Browsing Session arrivals are described by a Poisson distribution. However, the web browser model has an
`average of 5 packet calls per Session. A packet call for the web browsing can be viewed as the transmission of a
`page on the web. The time between packet calls should be viewed as the time taken by the requestor to read,
`analyse, save and/or print the content on the viewing screen. The number of packet calls in a session is described by
`a geometric distribution. For a mean ntunber of 5 packet calls per session, after each session there is a 20% chance
`the session terminates. Packet calls are described as having an average of 25 packets with the packets also being
`geometrically distributed. Because of the geometric distribution, the overall packet call bears a close resemblance to
`an exponential distribution for the packet call when the number of packets in a packet call are large as is the case for
`web browsing. The number of bytes per packet is fixed at 480 bytes for web usage.
`
`Session
`arrival
`
`Ave # of pkt Ave reading
`calls per
`time
`session
`between pkt
`calls
`
`Ave number
`of pkts in
`pkt call
`
`Ave inter-
`arrival time
`between
`pkts
`
`Packet sizes
`
`
`
`___flm
`email
`Poisson
`15
`10 msec
`15 8
`
`Poisson
`
`W
`
`5251TZJ
`
`10 msec
`
`338an
`
`Table 3) Traffic models for different services
`
`8 References
`
`[1] Motorola, “Mechanisms for Managing Uplink Interference and Bandwidth”, Tdoc SMG2-L23 535/98
`
`[2] Motorola, “Channel Bandwidth Allocation Strategy”, SMG2 UMTS L23 534/98
`
`[3] Motorola, “Shared Channel Options for Downlink Packet Data Transmission,” SMG 2 UMTS L23 533/98
`
`[4] ETSI/SMGZ/Layer 23 EG, ' Liaison to Layer 1 expert group on USCH', SMG 2 UMTS L23 581/98
`
`[5] Motorola, 'Methods for operating the uplink shared channel', SMG 2 UMTS L23 16/99
`
`[6] “Proposal for Changes of ETR04.02, Annex 2”, ETSI SMG2Ad Hoc UMTS Meeting, July, 1997: pp.257-259.
`
`[7] Sarath Kurnar and Sanjiv Nanda, “Traffic Model for Packet Services”, TIA, TR45.4 MAC Ad Hoc Meeting:
`March, 1998
`
`[8] A. Erik and J. Zander, “A traffic Model for Non-Real-Time Data Users in a Wireless Radio Network”, IEEE
`Communications Letters, Vol.1, No.2: March, 1997.
`
`[9] Technical Report, “Evaluation Criteria for the GPRS Radio Channel”, ETSI/STC SMG2Ad Hoc SPRS Meeting:
`February , 1996.
`
`[10] Ronald W. Wolff, Stochastic Modeling and the Theory of Queues, Englewood Cliffs, NJ:
`
`[1998] Prentice Hall
`
`[11] S. Deng, “Empirical Model of WWW Document Arrivals at Access Link”, IEEE [CC ’96
`
`NK868ITCO17317096
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1031-00007
`
`

`

`[12] P. Newman, T. Lyon and G. Minshall , “Flow Labeled IF: A Connectionless Approach to ATM”,
`Inforcom ’96, pp 1251-1260.
`
`IEEE
`
`[13] Motorola, 'Benefits of the ACCH for signalling fast assignments', Jan 18-19 1999, Helsinki, SMG2 UMTS L23
`/99
`
`[14] Motorola, 'Change requests related to the Uplink Shared CHannel', Jan 18-19 1999, Helsinki, SMG2 UMTS
`L23
`/99
`
`NK868ITCO17317097
`
`ZTE Corporation and ZTE (USA) Inc.
`Exhibit 1031-00008
`
`