(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2004/0223455 A1
`(43) Pub. Date:
`NOV. 11, 2004
`Fong et al.
`
`US 20040223455A1
`
`(54)
`
`(75)
`
`(73)
`
`(21)
`(22)
`
`COMMUNICATING IN A REVERSE
`WIRELESS LINK INFORMATION
`RELATING TO BUFFER STATUS AND DATA
`RATE OFA MOBILE STATION
`
`Inventors: Mo-Han Fong, L’Orignal (CA); Jun
`Li, Richardson, TX (US); Sophie S.
`Vrzic, Nepean (CA); Ali Iraqi, Kanata
`(CA); Ashvin H. Chheda, Plano, TX
`(Us)
`Correspondence Address:
`TROP PRUNER & HU, PC
`8554 KATY FREEWAY
`SUITE 100
`HOUSTON, TX 77024 (US)
`
`Assignee: Nortel Networks Limited, St. Laurent
`(CA)
`10/800,119
`
`Appl. No.:
`
`Filed:
`
`Mar. 12, 2004
`
`Related US. Application Data
`
`on May 9, 2003. Provisional application No. 60/469,
`778, ?led on May 12, 2003. Provisional application
`No. 60/475,440, ?led on Jun. 3, 2003. Provisional
`application No. 60/478,792, ?led on Jun. 16, 2003.
`Provisional application No. 60/495,544, ?led on Aug.
`15, 2003. Provisional application No. 60/499,584,
`?led on Sep. 2, 2003. Provisional application No.
`60/452,370, ?led on Mar. 6, 2003. Provisional appli
`cation No. 60/454,714, ?led on Mar. 15, 2003. Pro
`visional application No. 60/457,215, ?led on Mar. 25,
`2003. Provisional application No. 60/459,534, ?led
`on Apr. 1, 2003. Provisional application No. 60/462,
`220, ?led on Apr. 11, 2003. Provisional application
`No. 60/468,442, ?led on May 6, 2003. Provisional
`application No. 60/469,106, ?led on May 9, 2003.
`Provisional application No. 60/469,778, ?led on May
`12, 2003. Provisional application No. 60/475,440,
`?led on Jun. 3, 2003. Provisional application No.
`60/478,792, ?led on Jun. 16, 2003. Provisional appli
`cation No. 60/495,544, ?led on Aug. 15, 2003. Pro
`visional application No. 60/499,584, ?led on Sep. 2,
`2003.
`
`Publication Classi?cation
`
`(63)
`
`Continuation-in-part of application No. 10/793,056,
`?led on Mar. 4, 2004.
`
`(60)
`
`Provisional application No. 60/454,714, ?led on Mar.
`15, 2003. Provisional application No. 60/457,215,
`?led on Mar. 25, 2003. Provisional application No.
`60/459,534, ?led on Apr. 1, 2003. Provisional appli
`cation No. 60/462,220, ?led on Apr. 11, 2003. Pro
`visional application No. 60/468,442, ?led on May 6,
`2003. Provisional application No. 60/469,106, ?led
`
`(51) Int. Cl.7 ................................................... .. H04L 12/28
`(52) US. Cl. ....................................... .. 370/229; 370/395.4
`
`ABSTRACT
`(57)
`A Wireless communications network includes a mobile sta
`tion and base station that are capable of communicating over
`a Wireless link. Information relating to a status of a buffer in
`the mobile station and information relating to a data rate
`over a reverse Wireless links is communicated over the
`reverse Wireless link.
`
`PROCESSOR
`
`STORAGE
`
`PACKET
`DATA
`NETWORK
`
`STORA GE
`
`
`
`HTC/ZTE Exhibit 1003
`
`

`

`Patent Application Publication Nov. 11, 2004 Sheet 1 0f 5
`
`US 2004/0223455 A1
`
`PACKET DA TA NETWORK
`
`32
`Y PCF
`48 PROCESSOR /_ \
`SCHEDULER 22 ~@ 2” @
`
`/
`
`PROCESSOR
`
`FIG. 1
`
`03
`B
`
`r41
`
`. to
`
`(J
`
`h
`
`‘
`
`HTC/ZTE Exhibit 1003-2
`
`

`

`Patent Application Publication Nov. 11, 2004 Sheet 2 of 5
`
`US 2004/0223455 Al
`
`SW
`
`Sd
`
`
`
`
`
`
`
`(HODIU-YFLVOOTIV)ONIDVSSIWdNLASTIVd
`
`1$5IN0IE
`
`901
`
`
`
`
`
`S3SYIHON!WOOHQYIHYIMOdHOGdAFH
`
`
`
`YFIYLLOILIG
`
`ISYFAFYGNISOL
`
`SNOLLVHNGVdYIMOdXVWHOGAIY
`
`
`
`“NOWWYNGWOOYQYIHHOGdAFY
`
`
`
`
`
`S35¥740I0YIMOdHddAFYWOOYQVIH
`
`
`
`
`
`‘(WSuF99MLHODIYHddAz)
`
`(S)FOVSSIW
`
`HO0F4-Y
`
`
`
`ONFINGFHISWYOIYId
`
`NOLVAYOININOGiSV
`
` FOVSSIW
`
`
`
`
`
`
`FOVSSIWLSINOIYISYIAFYNI
`
`éOld
`
`HTC/ZTE Exhi
`
`it 1003-3
`
`HTC/ZTE Exhibit 1003-3
`
`
`
`
`

`

`Patent Application Publication Nov. 11, 2004 Sheet 3 0f 5
`
`US 2004/0223455 A1
`
`FOR I: 0-N
`
`/— 202
`
`204
`
`TRIGGER 1 0R 3
`
`DETECT TYPE
`OF TRIGGER
`
`TRIGGER 2
`
`206
`
`212
`
`SETsr id=N
`
`v
`SET
`buffer_size = buffer_s ta tus [I]
`
`208 '
`
`210
`
`v
`ENC ODE BUFFER
`STATUS
`
`V
`ENCODE r 211
`TPR
`
`214
`
`V
`SET
`buffer_size =buffer_status[N]
`
`v
`ENCODE BUFFER
`STATUS
`
`216
`
`"
`ENCODE TPR
`
`/
`
`217
`
`FIG. 3
`
`HTC/ZTE Exhibit 1003-4
`
`

`

`Patent Application Publication Nov. 11, 2004 Sheet 4 0f 5
`
`US 2004/0223455 A1
`
`BS
`
`A
`
`CALL SETuP MESSAGING
`
`302
`/_
`
`_
`
`MS
`
`EXTENDED CHANNEL ASSIGNMENT MESSAGE f 304 _
`(REV_PDCH_MAx_A UTO_TPRS)
`
`/—305 4
`
`SERVICE CONNECT MESSAGE (REV_PDCH_AUTO_ALLOWEDS[1])
`
`306
`
`STDRE
`RECEIVED
`PARAMETERS
`V
`/——308
`
`DETECT '
`DA TA T0
`TRANSMIT
`DVER REVERSE
`WIRELESS LINK
`
`PREPARE DA TA T0 TRANSMIT
`FOR SERVICE SR_ID
`IF REV_PDCII_AuT0_ALL0WEDS [Sr_id]
`=1
`
`312
`/_
`SET DATA TRANSMISSION
`RA TE UP TO
`REV_PDCH_MAx_AuT0_TPR s
`
`‘
`
`PDCH
`
`O
`
`[314
`
`0
`
`AV
`AV
`
`AV
`.
`Av
`UNIVERSAL HANDOFF DIRECT/0N MESSAGE /—3 16 _
`(REV_PDCH_'MAx_AuT0_TPRs, REV_PDCH_AUT0_ALL0WEDs[i]) ’
`
`AV
`
`AV
`
`FIG. 4
`
`HTC/ZTE Exhibit 1003-5
`
`

`

`Patent Application Publication Nov. 11, 2004 Sheet 5 0f 5
`
`US 2004/0223455 A1
`
`Q:
`
`Q‘_________._.____.___.
`C)
`v
`
`Q
`Q:
`
`E”:
`
`&
`+
`
`._
`‘1
`
`“3
`E2
`
`_- - — — — ——
`
`_ --
`
`L1.
`
`‘
`
`B5
`C2
`
`:5
`Q
`
`_____E _ _ _ _ _ _ _ .g__
`
`___..__Y_____
`
`Q
`
`Q 5
`‘I1
`c:
`____
`
`R-REOCH
`
`HTC/ZTE Exhibit 1003-6
`
`

`

`US 2004/0223455 A1
`
`Nov. 11, 2004
`
`COMMUNICATING IN A REVERSE WIRELESS
`LINK INFORMATION RELATING TO BUFFER
`STATUS AND DATA RATE OF A MOBILE STATION
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`[0001] This claims the bene?t under 35 U.S.C. § 119(e) of
`US. Provisional Applications Ser. Nos. 60/454,714, ?led
`Mar. 15, 2003; 60/457,215, ?led Mar. 25, 2003; 60/459,534,
`?led Apr. 1, 2003; 60/462,220, ?led Apr. 11, 2003; 60/468,
`442, ?led May 6, 2003; 60/469,106, ?led May 9, 2003;
`60/469,778, ?led May 12, 2003; 60/475,440, ?led Jun. 3,
`2003; 60/478,792, ?led Jun. 16, 2003; 60/495,544, ?led
`Aug. 15, 2003; and 60/499,584, ?led Sep. 2, 2003.
`[0002] This is a continuation-in-part of US. patent appli
`cation, entitled “AUTONOMOUS MODE TRANSMIS
`SION FROM A MOBILE STATION,” ?led Mar. 4, 2004,
`Which claims the bene?t under 35 U.S.C. § 119(e) of US.
`Provisional Applications Ser. Nos. 60/452,370, ?led Mar. 6,
`2003; 60/454,714, ?led Mar. 15, 2003; 60/457,215, ?led
`Mar. 25, 2003; 60/459,534, ?led Apr. 1, 2003; 60/462,220,
`?led Apr. 11, 2003; 60/468,442, ?led May 6, 2003; 60/469,
`106, ?led May 9, 2003; 60/469,778, ?led May 12, 2003;
`60/475,440, ?led Jun. 3, 2003; 60/478,792, ?led Jun. 16,
`2003; 60/495,544, ?led Aug. 15, 2003; and 60/499,584, ?led
`Sep. 2, 2003.
`[0003] Each of applications referenced above is hereby
`incorporated by reference.
`
`TECHNICAL FIELD
`
`[0004] The invention relates to communicating, in a
`reverse Wireless link, information relating to buffer status
`and data rate of a mobile station.
`
`BACKGROUND
`
`[0005] A mobile communications netWork is typically
`made up of a plurality of cells. Each cell includes a radio
`base station, With each base station connected to a mobile
`sWitching center or a packet service node that manages
`communications sessions betWeen mobile stations and ter
`minals coupled to a public sWitched telephone netWork
`(PSTN) or a packet-based data netWork. Communications
`betWeen mobile stations and base stations are performed
`over Wireless links
`[0006] Traditional Wireless protocols provide for circuit
`sWitched communications. Such protocols include time
`division multiple access (TDMA) protocols and code-divi
`sion multiple access (CDMA) protocols. In a circuit
`sWitched netWork, a channel portion betWeen tWo endpoints
`(e. g., tWo mobile stations) is occupied for the duration of the
`connection betWeen the endpoints.
`
`[0007] HoWever, With the Wide availability of the Internet
`and intranets, packet-sWitched communications (e.g., Web
`broWsing, electronic mail, and so forth) have become more
`common. Generally, a circuit-sWitched connection is an
`inef?cient mechanism for communicating packet data. As a
`result, third generation (3G) and beyond Wireless technolo
`gies are being developed and implemented to provide higher
`bandWidth and more ef?cient packet-sWitched communica
`tions (of data as Well as voice and other forms of real-time
`data) over Wireless netWorks.
`
`[0008] One eXample of a packet-sWitched Wireless tech
`nology is de?ned by the CDMA 2000 family of standards,
`developed by the Third Generation Partnership Project 2
`(3GPP2). A CDMA 2000 Wireless communications netWork
`is capable of supporting both circuit-sWitched services and
`packet-sWitched services. For TDMA, packet-sWitched
`Wireless communications protocols have also been devel
`oped, such as the Enhanced General Packer Radio Service
`(EGPRS) protocol as de?ned by the 3GPP (Third Generation
`Partnership Project) UMTS (Universal Mobile Telecommu
`nications System) Release 1999 Standard, and others.
`
`[0009] Packet-sWitched data communications is inher
`ently bursty in nature. In other Words, data is sent in short
`periods of bursts folloWed by intervals Where no data is
`communicated. Abase station typically includes a scheduler
`to schedule channels for a mobile station to transmit packet
`data over a reverse Wireless link. HoWever, the scheduling
`mechanisms employed by conventional base stations do not
`ef?ciently manage loading of the reverse Wireless link for
`packet-sWitched communications.
`
`SUMMARY
`
`[0010] In general, according to one embodiment, a method
`for use in a Wireless communications netWork includes
`communicating, in a reverse Wireless link, information relat
`ing to a status of a buffer in the mobile station and infor
`mation relating to a data rate of transmission over the reverse
`Wireless link.
`
`[0011] Other or alternative features Will become apparent
`from the folloWing description, from the draWings, and from
`the claims.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0012] FIG. 1 is a block diagram of an eXample arrange
`ment of a mobile or Wireless communications netWork that
`incorporates an embodiment of the invention.
`
`[0013] FIG. 2 is a message How diagram of signaling
`betWeen a base station and a mobile station, in accordance
`With an embodiment.
`
`[0014] FIG. 3 is a How diagram of a procedure that
`triggers transmission of a reverse request channel
`(R-REQCH) over a reverse Wireless link, in accordance With
`an embodiment.
`
`[0015] FIG. 4 is a message How diagram of a procedure
`for enabling autonomous communication of data from the
`mobile station to the base station at a rate up to a maXimum
`autonomous data rate, in accordance With an embodiment of
`the invention.
`
`[0016] FIG. 5 is a timing diagram to illustrate timing
`relationships betWeen R-REQCH messages and frames
`transmitted on a reverse packet data channel (R-PDCH), in
`accordance With an embodiment.
`
`DETAILED DESCRIPTION
`
`[0017] In the folloWing description, numerous details are
`set forth to provide an understanding of the present inven
`tion. HoWever, it Will be understood by those skilled in the
`art that the present invention may be practiced Without these
`details and that numerous variations or modi?cations from
`the described embodiments may be possible.
`
`HTC/ZTE Exhibit 1003-7
`
`

`

`US 2004/0223455 A1
`
`Nov. 11, 2004
`
`[0018] Referring to FIG. 1, a Wireless or mobile commu
`nications network according to one embodiment includes
`components that operate according to CDMA (code-divi
`sional multiple access) 2000. CDMA 2000 is de?ned by the
`CDMA 2000 family of standards (including the TIA-2000
`standards, TIA-2001 standards, and the TIA-2000-D stan
`dards). HoWever, in other embodiments, other types of
`Wireless protocols can be used for communications in the
`Wireless communications netWork, including other versions
`of CDMA, TDMA protocols, UMTS (Universal Mobile
`Telecommunications System) protocols, and other proto
`cols.
`
`[0019] The Wireless communications netWork includes
`multiple cells 18, each including a base transceiver sub
`system (BTS) 20 for performing radio telecommunications
`With mobile stations Within the coverage area of the cell 18.
`The BTS entities 20 are connected to one or more base
`station controllers (BSCs) 22. Collectively, a BTS 20 and
`BSC 22 are referred to as a “base station”19. More generally,
`a “base station” refers to any entity (or collection of entities)
`that communicates Wirelessly With mobile stations and that
`exchanges control signaling With the mobile stations for
`establishing, terminating, or otherWise managing communi
`cation sessions (e.g., circuit-sWitched communications ses
`sions, and so forth). Note that, in some implementations,
`multiple BTSs can be connected to each BSC.
`
`[0020] For communicating circuit-sWitched voice traf?c,
`the base station 19 is coupled to a mobile sWitching center
`(MSC) 24, Which is responsible for sWitching mobile sta
`tion-originated or mobile station-terminated circuit
`sWitched traf?c. Effectively, the MSC 24 is the interface for
`signaling and user traf?c betWeen the Wireless netWork and
`other public sWitched netWorks (such as a public sWitched
`telephone netWork (PSTN) 26 or other MSCs. The PSTN 26
`is connected to landline terminals, such as telephones 28.
`
`[0021] In a voice call session betWeen a mobile station
`(such as mobile station 16) and a landline terminal (such as
`telephone 28), voice traf?c is routed through the air interface
`betWeen the mobile station 16 and a base station 14, and
`through the base station 14, MSC 24, and PSTN 26.
`
`[0022] The Wireless communications netWork 10 also sup
`ports packet data services, in Which packet data is commu
`nicated betWeen a mobile station and another endpoint,
`Which can be a terminal coupled to a packet data netWork 34
`or another mobile station that is capable of communicating
`packet data. Examples of the packet data netWork 34 include
`private netWorks (such as local area netWorks or Wide area
`netWorks) and public netWorks (such as the Internet). Packet
`data is communicated in a packet-sWitched communications
`session established betWeen the mobile station and the other
`endpoint.
`[0023] To communicate packet data, the base station 19 is
`coupled to a packet control function (PCF) module 32,
`Which manages the relay of packets betWeen the BSC 22 and
`a packet data serving node (PDSN) 30. The BSC 22 and PCP
`module 32 can be implemented on one platform or on
`multiple platforms. A “platform” generally refers to an
`assembly of hardWare and softWare that provides prede?ned
`tasks.
`
`[0024] The PDSN 30 establishes, maintains, and termi
`nates link layer sessions to mobile stations, and routes
`
`mobile station-originated or mobile station-terminated
`packet data traf?c. The PDSN 30 is coupled to the packet
`data netWork 34, Which is connected to various endpoints,
`such as a computer 36 or a netWork telephone 38 (Which is
`a telephone that is ?tted With a netWork interface card for
`communications over packet data netWorks). Examples of
`packet-sWitched communications include Web broWsing,
`electronic mail, text chat sessions, ?le transfers, interactive
`game sessions, voice-over-IP (Internet Protocol) sessions,
`and so forth.
`
`[0025] The Wireless communications netWork thus pro
`vides tWo different types of communications: circuit
`sWitched communications and packet-sWitched communica
`tions. Circuit-sWitched communications are routed through
`the MSC 24, While packet-sWitched communications are
`routed through the PDSN 30. In circuit-sWitched commu
`nications, a dedicated end-to-end channel is established for
`the duration of a call session. HoWever, packet-sWitched
`communications utiliZe a connectionless intranetWork layer,
`such as that de?ned by the Internet Protocol (IP). In packet
`sWitched communications, packets or other units of data
`carry routing information (in the form of netWork addresses)
`that are used to route the packets or data units over one or
`more paths to a destination endpoint.
`
`[0026] One version of IP, referred to as IPv4, is described
`in Request for Comments (RFC) 791, entitled “Internet
`Protocol,” dated Sep. 1981; and another version of IP,
`referred to as IPv6, is described in RFC 2460, “Internet
`Protocol, Version 6 (IPv6) Speci?cation,” dated December
`1998.
`
`[0027] In the ensuing discussion, reference is made to the
`transmission of packet data by a mobile station. HoWever,
`note that techniques according to some embodiments of the
`invention can also be applied to circuit-sWitched communi
`cations.
`
`[0028] In accordance With some embodiments of the
`invention, a reverse request message is sent in the reverse
`Wireless link from the mobile station to the base station. The
`reverse request message contains at least tWo types of
`information: the maximum supportable data rate of the
`mobile station, and the status of buffer(s) in the mobile
`station. Buffer status refers to an occupancy of a buffer or
`buffers.
`
`[0029] The buffer status and maximum data rate informa
`tion communicated in the reverse request message enables a
`scheduler 40 in the base station 19 to provision for the
`amount of ROT (rise-over-thermal) or load in the reverse
`Wireless link that is occupied by users. ROT, or rise-over
`thermal, is de?ned as the ratio of total interference over
`thermal noise poWer. ROT is basically a measure of the
`loading of the reverse Wireless link. In other implementa
`tions, other measures of loading of the reverse Wireless link
`can be used.
`
`[0030] A mobile station can transmit in one of tWo modes:
`autonomous mode and scheduled mode. In scheduled mode,
`an explicit assignment of the data rate is provided by the
`scheduler 40 in the base station 19 to the mobile station 16.
`In autonomous mode, a mobile station 16 containing data to
`transmit does not have to Wait for the scheduler 40 to
`schedule a channel for the mobile station 16. Instead, the
`mobile station 16 is able to autonomously send data over the
`
`HTC/ZTE Exhibit 1003-8
`
`

`

`US 2004/0223455 A1
`
`Nov. 11, 2004
`
`reverse Wireless link at a data rate that is less than or equal
`to a speci?ed maximum autonomous data rate (speci?ed by
`the base station 19). Effectively, in autonomous mode, the
`mobile station 16 is able to transfer packet data at a data rate
`up to the maximum autonomous data rate Without an explicit
`scheduled rate assignment received in either layer 2 signal
`ing or layer 3 signaling messages from the scheduler 40 in
`the base station 19.
`
`[0031] As further shoWn in FIG. 1, each mobile station 16
`includes a processor 42 and a storage 44. The processor 42
`provides a processing core on Which one or more softWare
`modules are executable to enable the mobile station to
`perform various tasks. Also, the mobile station 16 includes
`buffers 46 for temporarily holding data that are to be
`communicated over the reverse Wireless link to the base
`station 19. The base station 19 also includes a processor 48
`and a storage 50 (or multiple processors and storages). The
`scheduler 40 can be a softWare module that is executable on
`the processor 48.
`
`[0032] Because mobile stations are able to transmit
`autonomously, a base station 19 is unable to directly control
`through the use of data rate assignment messages the loading
`of the reverse Wireless link. Therefore, according to some
`embodiments, a mechanism that takes into account the
`autonomous transmitting capability of mobile stations is
`provided to enable the scheduler 40 in the base station 19 to
`ef?ciently schedule usage of the air interface betWeen
`mobile stations and the base station.
`
`[0033] To determine the bandWidth requirements of the
`mobile stations being served by the base station 19, the
`scheduler 40 uses the buffer status and maximum support
`able data rate information provided in the reverse request
`message. In this manner, the scheduler 40 can determine a
`data rate to grant each mobile station in scheduled mode.
`Also, in one implementation, the scheduler 40 can use the
`reverse request message information to determine hoW much
`of the bandWidth of the reverse Wireless link Will be taken
`up by the autonomous mode mobile stations (the mobile
`stations transmitting in autonomous mode). Any remaining
`bandWidth of the reverse Wireless link can then be allocated
`to scheduled mode mobile stations by the scheduler 40
`explicitly assigning data rates to the scheduled mode mobile
`stations. In scheduled mode, assignment of a data rate to a
`mobile station can be performed by the base station sending
`a grant message in a grant channel (GCH) to a mobile
`station.
`
`[0034] In accordance With an embodiment of the inven
`tion, the reverse request message is communicated from the
`mobile station to the base station on a reverse request
`channel (R-REQCH). Packet data is communicated from the
`mobile station to the base station in a reverse packet data
`channel (R-PDCH). In one implementation, the message
`format of a reverse request message is as folloWs:
`
`FIELD
`
`LENGTH (bits)
`
`RESERVED
`MAXIMUMiTPR
`SRiID
`EVENT
`
`1
`4
`3
`4
`
`[0035] The length of each ?eld is provided for the purpose
`of example. Other implementations can use other lengths of
`the ?elds. In the reverse request message, the MAXI
`MUM_TPR ?eld indicates the maximum traffic-to-pilot
`ratio for the reverse packet data channel. The traffic-to-pilot
`ratio represents the ratio of the energy of traffic channels to
`the pilot channel. The maximum traf?c-to-pilot ratio is used
`as an indication of the maximum supportable data rate,
`Where a higher traf?c-to-pilot ratio implies a higher data
`rate.
`
`[0036] The SR_ID ?eld in the reverse request message
`contains a service reference identi?er (sr_id) to identify a
`service instance. A mobile station is capable of being
`involved in multiple communications sessions to provide
`multiple respective services (each such service is also
`referred to as a service instance). Examples of services
`include a voice-over-IP service, a Web broWsing service, an
`electronic mail service, a text chat service, a ?le doWnload
`service, an interactive gaming service, and so forth. Multiple
`concurrent communications sessions for respective services
`can be set up by a mobile station 16. The SR_ID ?eld is set
`to the service reference identi?er of the service instance that
`caused generation of a trigger for transmission of a reverse
`request message. Alternatively, the SR_ID ?eld can be set to
`a predetermined value, such as “111,” if the trigger that
`caused the reverse request message to be sent is associated
`With a combination of service instances.
`
`[0037] Instead of, or in addition to the SR_ID ?eld, a
`service or scheduling class ?eld can also be included. A
`service class indicates a level of service the scheduler 40 in
`the base station should provide to the mobile station. The
`base station can assign the same service class to more than
`one service instance of a mobile station.
`
`[0038] Another ?eld, the EVENT ?eld, contains an event
`code that corresponds to the buffer status of the mobile
`station. The buffer status indicates the amount of data stored
`in a buffer for a service instance. The event code is derived
`from an event code table stored in the mobile station that
`associates ranges of data amounts With corresponding codes.
`In some implementations, the event code table is con?gured
`by the base station during call setup or Within an active call.
`Effectively, reporting the buffer status in the EVENT ?eld
`alloWs the base station to knoW hoW much data the mobile
`station has, and thus to decide the scheduling priority and
`What data rate to assign the mobile station in scheduled
`mode.
`
`[0039] In sum, the reverse request message contains infor
`mation to enable the scheduler 40 in the base station 19 to
`determine data rate requirements of a corresponding mobile
`station. The MAXIMUM_TPR value provides insight into
`the maximum data rate supportable by the mobile station,
`based on poWer constraints. The EVENT ?eld indicates the
`status of a buffer in the mobile station for a particular service
`instance. The buffer status can be used by the scheduler 40
`to determine an expected data rate requirement on a reverse
`channel (e.g., R-PDCH). Thus, Whereas the MAXI
`MUM_TPR ?eld provides an indication of a poWer-limited
`data rate for transmissions on R-PDCH, the EVENT ?eld
`provides an indication of a buffer-limited data rate for
`transmissions on R-PDCH.
`
`[0040] In alternative embodiments, other combinations of
`?elds in the reverse request message can be used. For
`
`HTC/ZTE Exhibit 1003-9
`
`

`

`US 2004/0223455 A1
`
`Nov. 11, 2004
`
`example, instead of having separate MAXIMUM_TPR and
`EVENT ?elds to represent power headroom and buffer
`status information, one ?eld can be employed. This one ?eld
`(referred to as a CODE ?eld) can convey either poWer
`related information (a code to represent the maximum TPR
`or a poWer-limited data rate) or buffer-related information (a
`code to represent buffer status or a buffer-limited data rate).
`Another ?eld, referred to as a STATUS ?eld, in the reverse
`request message can be used to indicate Whether the CODE
`?eld is carrying poWer-related information or buffer-related
`information. Thus, effectively, in this alternative embodi
`ment, if the STATUS ?eld has a ?rst value, then the CODE
`?eld contains information indicative of data rate that is
`based on buffer occupancy (the amount of data present in a
`buffer for a particular service instance). HoWever, if the
`STATUS ?eld has a second value, then the CODE ?eld
`contains information indicative of data rate that is based on
`poWer headroom.
`
`[0041] PoWer-related information can be in the form of (1)
`a maximum poWer-limited data rate, (2) a maximum poWer
`limited effective traf?c-to-pilot ratio, (3) the actual poWer
`headroom remaining in the mobile station in dBm, (4) the
`actual mobile station pilot transmit poWer in dBm, or (5) an
`encoded value representing any of the above. The buffer
`related information can be in the form of (1) a maximum
`buffer-limited data rate the mobile station can transmit, (2)
`the actual buffer occupancy in bytes or other units, (3) the
`quantized buffer level in the mobile station, or (4) an
`encoded value representing any of the above.
`
`[0042] In addition to enabling load management of the
`reverse Wireless link (e.g., R-PDCH), the reverse request
`messages sent by each mobile station also alloWs for outer
`loop poWer control on the reverse link, according to some
`implementations. Outer loop poWer control refers to con
`trolling the poWer of transmission over a Wireless link based
`on detected data error rates (such as errors in frames or in
`data bits). For example, the reverse request message sent on
`R-REQCH can be used for poWer control When actual data
`(such as data on R-PDCH) is not being transmitted for some
`extended period of time.
`
`[0043] FIG. 2 is a message How diagram of a procedure
`according to one embodiment for communicating reverse
`request messages containing buffer status and data rate
`information over a reverse Wireless link. Initially, call setup
`messaging is exchanged (at 102) betWeen the base station 19
`and the mobile station 16. As part of this call setup mes
`saging, the base station can allocate a reverse request
`channel (R-REQCH) to the mobile station. Allocation of
`R-REQCH enables the mobile station to communicate buffer
`status and data rate information to the mobile station. The
`base station sends (at 104) various messages to the mobile
`station, With such message(s) containing trigger parameters
`that are used by the mobile station to trigger the transmission
`of a reverse request message on R-REQCH. The message(s)
`sent at 104 can be performed as part of the call setup
`procedure, or the message(s) can be sent by the base station
`to the mobile station at any time during the active state of the
`mobile station. For example, the trigger parameters can be
`communicated Whenever a neW service is being instantiated.
`Usually, call setup needs to be performed only once, With the
`mobile station being able to provide multiple services in one
`call session. An example message that is sent by the base
`station to the mobile station to instantiate a neW service is a
`
`Service Connect Message (SCM). Messages containing the
`trigger parameters can also be sent during handoff proce
`dures, such as soft handoff procedures. An example message
`that is communicated during a soft handoff procedure is a
`Universal Handoff Direction Message (UHDM). Other mes
`sages can be used to communicate the trigger parameters in
`other embodiments.
`
`[0044] Examples of trigger parameters that are sent by the
`base station to the mobile station include REV_PD
`CH_REQCH_TRIGGERS[p] (Where i represents a particular
`service instance), REV_PDCH_POWER_HEADROOM
`_INCREASES, REV_PDCH_POWER_HEADROOM_DE
`CREASES, REV_PDCH_HEADROOM_DURNFIONS, and
`REV_PDCH_MAX_POWER_UPDATE_DURATIONS.
`[0045] The REV_PDCH_REQCH_TRIGGERS[i] param
`eter contains at least the folloWing ?elds: MIN_DURA
`TION, to indicate a minimum duration at Which a mobile
`station should send a reverse request message to the base
`station; and USE_POWER_REPORTS, to indicate if a
`change in poWer headroom by a speci?ed amount at the
`mobile station is to be used to trigger the transmission of a
`reverse request message for the particular service instance i.
`The REV_PDCH_REQCH_TRIGGERS[i].MIN_DURA
`TION ?eld is set at a value to prevent the mobile station
`from transmitting reverse request messages too frequently.
`[0046] The REV_PDCH_POWER_HEADROOM_IN
`CREASES and REV_PDCH_POWER_HEADROOM_DE
`CREASES parameters are used to de?ne respectively the
`amount of poWer headroom increase and decrease at the
`mobile station that Will trigger the transmission of a reverse
`request message. PoWer headroom refers to the available
`transmit poWer for transmitting data on a reverse traf?c
`channel, including the reverse packet data channel
`(R-PDCH).
`[0047] The REV_PDCH_HEADROOM_DURKFIONs
`parameter indicates another duration, different from
`REV_PDCH_REQCH_TRIGGERS[i].MIN_DURATION,
`for indicating Whether a reverse request message should be
`transmitted in response to detecting that a suf?cient change
`in poWer headroom has triggered transmission of a reverse
`request message. The REV_PDCH_HEADROOM_DURA
`TIONS is set at a value to prevent the mobile station from
`transmitting reverse request messages too frequently When
`triggered by poWer headroom changes.
`[0048] The
`REV_PDCH_MAX_POWER_UPDAT
`E_DURATIONS parameter is used to indicate a maximum
`duration after With the mobile station must transmit a reverse
`request message if other criterion(ia) is(are) satis?ed. This
`duration is provided to specify a maximum period betWeen
`transmissions of reverse request messages by a mobile
`station. In one speci?c embodiment, this periodic transmis
`sion of reverse request messages after every REV_PDCH
`_MAX_POWER_UPDATE_DURATIONS can be used for
`the purpose of reverse link outer-loop poWer control based
`on frame quality of the reverse request message.
`
`[0049] The parameters listed above are provided for pur
`poses of example, as other trigger parameters can be used in
`other embodiments.
`
`[0050] Next, the mobile station detects (at 106) Whether a
`trigger has occurred to send a reverse request message. If a
`trigger has occurred, based on the trigger parameters sent by
`
`HTC/ZTE Exhibit 1003-10
`
`

`

`US 2004/0223455 Al
`
`Nov. 11, 2004
`
`the base station to the mobile station, the mobile station
`sends (at 108) a reverse request message on R-REQCH.
`Next, the base station performs (at 110) scheduling based on
`information in the reverse request message.
`
`[0051] FIG. 3 is a How diagram of a process performed by
`a mobile station to determine Whether a reverse request
`message is to be sent to a base station. The mobile station
`iteratively performs (at 202) the process for all active service
`instances i, Where i=0-N (N-1 being a value from 0 to some
`predetermined maximum number of service instances that
`can be active in a call). The mobile station detects (at 204)
`if a trigger condition is satis?ed for the service instance i.
`
`[0052] There are at least three triggers for sending a
`reverse request message. A ?rst trigger is a buffer update
`trigger. This trigger involves determining Whether the state
`of the parameter ?eld REV_PDCH_REQCH_TRIGGERS[i]
`.USE_BUFFER_REPORTS is true, and Whether a current
`system time (the time provided by the clock of the mobile
`station) exceeds a time at Which a reverse request message
`Was last transmitted for the service instance i by the prede
`termined
`time
`duration
`speci?ed by REV_PD
`CH_REQCH_TRIGGERS[i].MIN_DURATION. The cur
`rent system time is saved in a parameter saved_sys_time.
`The time that a reverse request message Was last sent for the
`service instanc