UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`UNITED STATES DEPARTMENT OF COMMERCE
`United States Patent and Trademark Office
`Address: COMMISSIONER FOR PATENTS
`P.O. Box 1450
`Alexandria, Virginia 22313-1450
`WWVI'.USpID.g0V
`
`APPLICATION
`NUMBER
`
`FILING or
`371(c) DATE
`
`GRP ART
`UNIT
`
`
`
`
`
`F
`
`61/000,729
`
`10/29/2007
`
`FEE REC'D
`
`105
`
`23364
`BACON & THOMAS, PLLC
`625 SLATERS LANE
`FOURTH FLOOR
`ALEXANDRIA, VA 22314
`
`ATTY.DOCKET.NO
`
`TOT CLAIIVIS IND CLAIMS
`
`WUCH3086P/EM
`
`CONFIRMATION NO. 3814
`
`FILING RECEIPT
`
`lullllllIllllljjljjjljjljjjljjjjjjllIllllllllllll
`
`Date Mailed: 12/27/2007
`
`It will not be examined for patentability and will
`Receipt is acknowledged of this provisional patent application.
`become abandoned not later than twelve months after its filing date. Any correspondence concerning the application
`must include the following identification information: the U.S. APPLICATION NUMBER, FILING DATE, NAME OF
`APPLICANT, and TITLE OF INVENTION. Fees transmitted by check or draft are subject to collection. Please verify
`the accuracy of the data presented on this receipt. If an error is noted on this Filing Receipt, please write to the
`Office of Initial Patent Examination's Filing Receipt Corrections. Please provide a copy of this Filing Receipt
`with the changes noted thereon. If you received a "Notice to File Missing Parts" for this application, please
`submit any corrections to this Filing Receipt with your reply to the Notice. When the USPTO processes the
`reply to the Notice, the USPTO will generate another Filing Receipt incorporating the requested corrections
`
`Applicant(s)
`
`Chunli Wu, Beijing, CHINA;
`Tsung-Liang Lu, Dali City, TAIWAN;
`Yen-Chen Chen, Jhongli City, TAIWAN;
`Li-Cheng Lin, Yilan City, TAIWAN;
`Chih-Wen Chang, Hsinchu City, TAIWAN;
`Power of Attorney: The patent practitioners associated with Customer Number 23364
`
`If Required, Foreign Filing License Granted: 12/18/2007
`The country code and number of your priority application, to be used for filing abroad under the Paris Convention,
`is US 61/000,729
`Projected Publication Date: None, application is not eligible for pre-grant publication
`Non-Publication Request: No
`Early Publication Request: No
`** SMALL ENTITY **
`Title
`
`Method for UL scheduling information
`
`PROTECTING YOUR INVENTION OUTSIDE THE UNITED STATES
`
`Since the rights granted by a U.S. patent extend only throughout the territory of the United States and have no
`effect in a foreign country, an inventor who wishes patent protection in another country must apply for a patent
`in a specific country or in regional patent offices. Applicants may wish to consider the filing of an international
`application under the Patent Cooperation Treaty (PCT). An international (PCT a lication oenerall has the same
`page 1 of 3
`
`NEC V. CELLULAR COMMUNICATIONS EQUIPMENT LLC
`
`EXHIBIT 2001
`EXHIBIT 2001
`NEC V. CELLULAR
`COMMUNICATIONS EQUIPMENT LLC
`IPR2014-01136
`|PR2014-01136
`
`

`

`effect as a regular national patent application in each PCT-member country. The PCT process simplifies the filing
`of patent applications on the same invention in member countries, but does not result in a grant of "an international
`patent" and does not eliminate the need of applicants to file additional documents and fees in countries where patent
`protection is desired.
`
`Almost every country has its own patent law, and a person desiring a patent in a particular country must make an
`application for patent in that country in accordance with its particular laws. Since the laws of many countries differ
`in various respects from the patent law of the United States, applicants are advised to seek guidance from specific
`foreign countries to ensure that patent rights are not lost prematurely.
`
`Applicants also are advised that in the case of inventions made in the United States, the Director of the USPTO must
`issue a license before applicants can apply for a patent in a foreign country. The filing of a US. patent application
`serves as a request for a foreign filing license. The application's filing receipt contains further information and
`guidance as to the status of applicant's license for foreign filing.
`
`Applicants may wish to consult the USPTO booklet, "General Information Concerning Patents" (specifically, the
`section entitled "Treaties and Foreign Patents") for more information on timeframes and deadlines for filing foreign
`patent applications. The guide is available either by contacting the USPTO Contact Center at 800-786-9199, or it
`can be viewed on the USPTO website at http://www.uspto.gov/web/offices/pac/doc/general/index.html.
`
`For information on preventing theft of your intellectual property (patents, trademarks and copyrights), you may wish
`to consult the US. Government website, http://www.stopfakes.gov. Part of a Department of Commerce initiative,
`this website includes self-help "toolkits" giving innovators guidance on how to protect intellectual property in specific
`countries such as China, Korea and Mexico. For questions regarding patent enforcement issues, applicants may
`call the US. Government hotline at 1-866-999-HALT (1-866-999-4158).
`
`LICENSE FOR FOREIGN FILING UNDER
`
`Title 35, United States Code, Section 184
`
`Title 37, Code of Federal Regulations, 5.11 & 5.15
`
`GRANTED
`
`if the phrase "IF REQUIRED, FOREIGN FILING
`The applicant has been granted a license under 35 U.S.C. 184,
`LICENSE GRANTED" followed by a date appears on this form. Such licenses are issued in all applications where
`the conditions for issuance of a license have been met, regardless of whether or not a license may be required as
`set forth in 37 CFR 5.15. The scope and limitations of this license are set forth in 37 CFR 5.15(a) unless an earlier
`license has been issued under 37 CFR 5.15(b). The license is subject to revocation upon written notification. The
`date indicated is the effective date of the license, unless an earlier license of similar scope has been granted under
`37 CFR 5.13 or 5.14.
`
`This license is to be retained by the licensee and may be used at any time on or after the effective date thereof unless
`it is revoked. This license is automatically transferred to any related applications(s) filed under 37 CFR 1.53(d). This
`license is not retroactive.
`
`The grant of a license does not in any way lessen the responsibility of a licensee for the security of the subject matter
`as imposed by any Government contract or the provisions of existing laws relating to espionage and the national
`security or the export of technical data. Licensees should apprise themselves of current regulations especially with
`page 2 of 3
`
`

`

`respect to certain countries, of other agencies, particularly the Office of Defense Trade Controls, Department of
`State (with respect to Arms, Munitions and Implements of War (22 CFR 121-128)); the Bureau of Industry and
`Security, Department of Commerce (15 CFR parts 730-774); the Office of Foreign AssetsControl, Department of
`Treasury (31 CFR Parts 500+) and the Department of Energy.
`
`NOT GRANTED
`
`No license under 35 U.S.C. 184 has been granted at this time, if the phrase "IF REQUIRED, FOREIGN FILING
`LICENSE GRANTED" DOES NOT appear on this form. Applicant may still petition for a license under 37 CFR 5.12,
`if a license is desired before the expiration of 6 months from the filing date of the application. If 6 months has lapsed
`from the filing date of this application and the licensee has not received any indication of a secrecy order under 35
`U.S.C. 181, the licensee may foreign file the application pursuant to 37 CFR 5.15(b).
`
`page 3 of 3
`
`

`

`
`\\\\\\\\'
`LO6ZOL
`
`5
`-
`COMMISSIONER FOR PATENTS
`P.O. Box 1450
`
`?,
`
`. a-
`
`Alexandria, VA 22313-1450
`
`4
`
`U.S. PTO
`61/000729
`10/29/2007
`
`Sir.“ .
`a:
`on
`
`PROVISIONAL APPLICATION COVER SHEET
`
`is is a request for filing a PROVISIONAL APPLICATION under 37 CFR 1.53 (c).
`
`d'90
`
`0
`LAST NAME
`
`FIRST NAME
`
`Tsung-Liang
`
`Atty. Docket
`Number:
`
`
`
`WUCH3086P/EM
`
`INVENTOR(S) / APPLICANT(S)
`lVIIDDLE
`RESIDENCE (CITY & EITHER STATE OR FOREIGN
`INIT.
`COUNTRY)
`
`new-1g, RR-c.
`
`Dali City, Taichung County, Taiwan, R.O.C.
`
`
`
`Jhongn City, Taoyuan County, Taiwan, R-oc.
`Yilan City, Yilan County, Taiwan, R.O.C.
`— Li-Cheng
`LIN
`Hsinchu City, Taiwan, R.O.C.
`CHANG
`Chih-Wen
`
`
`TITLE OF INVENTION (280 Characters Max.)
`
`\\\\\\\\\\\\\\/\\\\\i§l\\\\\\\
`
`
`
`
`
`
`
`
`A METHOD FOR UL SCHEDULING INFORMATION
`
`
`
`
`
`
`
`
`
`
`
`
`CORRESPONDENCE ADDRESS
`
`23364
`Customer Number
`
`DRAWINGS
`
`X
`
`SMALL ENTITY STATUS CLAIMED
`
`OTHER :
`
`
`
`
`METHOD OF PAYMENT (CHECK ONE)
`
`
`ENCLOSED APPLICATION PARTS (CHECK ALL THAT APPLY)
`NUMBER OF PAGES: [1|
`
`NUMBER OF
`ADS; Early Serial Number
`Postcard
`
`
`SHEETS:
`X
`
`
`
`
`
`
`
`x
`
`
`
`
`
`$210.00
`
`,
`_
`,
`Size Fee (If applicable):
`
`A CHECK IS ENCLOSED To COVER THE PROVISIONAL FILING FEES.
`PLEASE CHARGE ANY ADDITIONAL FEES, 0R CREDIT ANY
`OVERPAYMENT To DEPOSIT ACCOUNT NUMBER 02-0200
`
`
`
`THE COMMISSIONER Is HEREBY AUTHORIZED T0 CHARGE FILING FEES AND
`X
`CREDIT DEPOSIT ACCOUNT NUMBER 02-0200
`
`
`
`
`
`
`
`
`Small Entity (%50 reduction, if applicable):
`
`$210 00
`'
`
`$105.00
`
`$105.00
`TOTAL FEE SUBMIsz
`
`The invention was made by an agency of the US Government or under a contract with an agency of the US Government.
`No. I: Yes, the name of the Government agency and the Government contract number are:
`
`Respectfully Submitted,
`
`SIGNATURE: % 2&4 2g :2
`
`.
`
`'
`
`£544%
`
`Date: October 292 2007
`
`TYPED OR PRINTED NAME Richard E. Fichter -
`
`REG. No.
`
`l:| Additional inventors are being named on separately numbered sheets attached hereto.
`
`

`

`Application Data Sheet
`Application Information
`
`Application type::
`
`Subject matter::
`
`CD—ROM or CD—R::
`
`Number of CD disks::
`
`Number of copies of CD52:
`
`Sequence submission?::
`
`Computer readable form (CRF)?::
`
`'
`
`Number of copies of CRF::
`
`Title::
`
`Regular
`
`Provisional
`
`None
`
`0
`
`0
`
`No
`
`No
`
`0
`
`A Method for UL Scheduling
`Information
`
`Attorney docket number::
`
`V\HJK1F€E§C$§ZP¥?4EEL1
`
`Request for early publication?::
`
`Request for non—publication?::
`
`No
`
`Suggested drawing figure::
`
`Total drawing sheets::
`
`Small entity?::
`
`Applicant Information
`
`Applicant authority type::
`
`Inventor
`
`Primary citizenship countryz:
`
`P.R.C.
`
`Status:
`
`Given name::
`
`Middle name::
`
`Family name::
`
`Name suffix::
`
`Full capacity
`
`.
`
`Chunli
`
`.
`
`WU
`
`City of Residence::
`
`Beijing
`
`State or province of residence::‘
`
`Page # 1
`
`Initial
`
`

`

`Country of residence::
`
`P.R.C.
`
`Street of mailing address::
`
`10 xi Tucheng Lu, Haidian
`District,
`
`City of mailing address::
`
`Beijing
`
`State or province of mailing
`address::
`
`Country of mailing address::
`
`P.R.C.
`
`Postal or zip code of mailing
`address::
`
`Applicant Information
`
`Applicant authority type::
`
`Primary citizenship countryz:
`
`Status:
`
`Given name::
`
`Middle name::
`
`Family name::
`
`Name suffixzz
`
`Inventor
`
`Taiwan R.O.C.
`
`Full capacity
`
`Tsung—Liang
`
`LU
`
`City of Residencezé
`
`Dali City, Taichung County
`
`State or province of residence::
`
`Country of residence::
`
`Taiwan R.O.C.
`
`Street of mailing address::
`
`No.6, Lane 138, Sirong Rd.,
`
`City of mailing address::
`
`Dali City, Taichung County
`
`State or province of mailing
`address::
`
`Country of mailing address::
`
`Taiwan R.O.C.
`
`Postal or zip code of mailing
`address::
`
`412
`
`Applicant Information
`
`Applicant authority type::
`
`Inventor
`
`Page # 2
`
`Initial
`
`

`

`Primary citizenship countryz:
`
`Taiwan R.O.C.
`
`Status:
`
`Given name::
`
`Middle name::
`
`Family name::
`
`Name suffix::
`
`Full capacity
`
`Yen—Chen
`
`CHEN
`
`City of Residence::
`
`I
`
`Jhongli.City,'Taoyuaerounty
`
`State or province of residence::
`
`Country of residence::
`
`Taiwan R.O.C.
`
`Street of mailing address::
`
`2F., No.103, Longchuan 2nd
`St.,
`
`City of mailing address::
`
`JhongliCity,TaoyuanCounty
`
`State or province of mailing
`address::
`
`Country of mailing address::
`
`Taiwan R.O.C.
`
`Postal or zip code of mailing
`address::
`
`320
`
`Applicant Information
`
`Applicant authority type::
`
`Inventor
`
`Primary citizenship country::
`
`Taiwan R.O.C.
`
`Status:
`
`.
`
`Given name::
`
`Middle name::
`
`Family name::
`
`Name suffix::
`
`Full capacity
`
`Li—Cheng
`
`-LIN
`
`City of Residence::
`
`Yilan City, Yilan County
`
`State or province of residence::
`
`Country of residence::
`
`Taiwan R.O.C.
`
`Street of mailing address::
`
`2F., No.36—1, Lane 1,.Lising
`St.,
`
`Page # 3
`
`Initial
`
`

`

`City of mailing address::
`
`Yilan City, Yilan County
`
`State or province of mailing
`address::
`
`Country of mailing address::
`
`Taiwan R.O.C.
`
`Postal or zip coderf mailing
`address::
`
`260
`
`Applicant Information
`
`Applicant authority type::
`
`Primary citizenship country::
`
`Status:
`
`V
`
`Given namezz
`
`Middle name::
`
`Family name::
`
`Name suffix::
`
`Inventor
`
`Taiwan R.O.C.
`
`Full capacity
`
`Chih—Wen
`
`CHANG
`
`City of Residence::
`
`Hsinchu City
`
`State or province of residence::
`
`Country of residence::
`
`Taiwan R.O.C.
`
`Street of mailing address::
`
`No.7, Alley 98, Lane 446,
`Sec. 2, Dongda Rd.,
`
`City of mailing address::
`
`Hsinchu City
`
`State or province of mailing
`address::
`
`Country of mailing address::
`
`Taiwan R.O.C.
`
`Postal or zip code of mailing
`address::
`
`300
`
`Correspondence Information
`
`Correspondence customer number::
`
`23364
`
`Phone number::
`
`Fax number::
`
`703-683—0500
`
`703-683—1080
`
`Page # 4
`
`Initial
`
`

`

`E—mail address::
`
`mail@baconthomas.com
`
`Representative Information
`
`Representative customer number::
`
`23364
`
`Domestic Priority Information
`
`
`
`
`Application::
`
` Applicationzz Continuity Type:: Parent
`
`
`
`
`
`
`
`This application
`
`An application
`claiming benefit
`under 35 USC 119(e)
`
`
`
`
`
`Country:
`
`Application number:
`
`
`
`Foreign Priority Information
`
`
`
`Filing
`Priority
`D—te:—laimed.
`
`Assignee Information
`
`Assignee name::
`
`Street of mailing address::
`
`City of mailing address::
`
`State or province of mailing
`address::
`
`Country of mailing address::
`
`Postal or zip code of mailing
`address::
`
`Page # 5
`
`Initial
`
`

`

`A method for UL Scheduling Information
`
`reporting
`
`Section 1
`
`Introduction
`
`For the uplink traffic of current UMTS HSUPA and evolved UTRA (E-UTRA), a
`
`network-controlled scheduler mechanism is used. To enable the network side
`
`(uplink scheduler)
`
`to properly allocate resource between multiple user
`
`equipments (UEs), UEs should provide their own UL scheduling information to
`
`the scheduler. In UMTS HSUPA system, such information includes the 18-bit
`
`Scheduling Information (SI) and the 1-bit “Happy bit" field. The SI is “ used to
`
`provide the network with a better view of the amount of system resources
`
`needed by the UE and the amount of resources it can actually make use of." [1]
`
`And the Happy bit “indicates whether the UE could use more resources or not”.
`
`[1] For further information about current UMTS mechanism, please refer to [1].
`
`In E-UTRA, due to different multiple access schemes adopted and different
`
`system requirement compares with UMTS. more detailed uplink scheduling
`information is needed. For example,
`to achieve better coordination on
`
`resource allocation between different UEs and different logical channels within
`
`one UE, the buffer status of different radio bear groups (RBGs) are reported in
`
`E-UTRA, while only the buffer status of highest priority logical channel and
`
`total buffer occupancy status are reported in UMTS system. Also compared to
`
`the strict priority policy used in UMTS, the concepts of prioritized bit rate (PBR)
`
`and maximum bit rate (MBR) are introduced in E-UTRA to ensure that data on
`
`higher priority logical channel are transmitted earlier, while data on lower
`
`priority logical channel are prevented from starvation. For further information
`
`about concept of scheduling mechanism in E—UTRA, please refer to [2].
`
`Taking the above consideration into concern, the contents included in the
`
`uplink scheduling information provided by UEs in E-UTRA requires further
`
`optimization to meet the requirements while minimizing the overhead at the
`
`same time. This invention discloses a method for UL Scheduling Information
`
`reporting, including Complete Buffer Status Report (BSR) and Complementary
`
`Report (similar to “Happy bit") which is smaller and reported more frequently.
`
`Section 2
`
`Complete Buffer Status Report
`
`In this document we discuss on several aspects of the buffer status report:
`
`

`

`2.1 How to indicate the RBG status sent in the report?
`
`To indicate the buffer occupancy status of different RBG, we may adopt similar
`
`mechanism used in current UMTS system by using multiple bits to “indicates
`
`the amount of data in number of bytes that is available for transmission and
`
`retransmission." Some aspects could be further analyzed:
`
`a) Length of each status indication:
`
`One simple and straight—fonrvard way is to keep the status report length of
`
`all RBGs as the same, with a fixed granularity. Another way stands that,
`
`since different RBGs serve for different services and functionalities, it is
`
`possible that the status report length needed for different RBGs might be
`
`different. 80 that RBGs with smaller buffer sizes or with lower
`
`requirements in the accuracy of the report, e.g. different granularity, may
`
`adopt shorter length, while the others use more bits for the indication. This
`
`could save the total size of the report and make the system more flexible.
`
`One other alternative is to indicate the buffer occupancy status of overall
`
`buffer, and also indicate the relative occupied percentage of each RBG. As
`
`the method described above, the length used to indicate the occupancy
`
`status of different RBGs might vary. The granularity of the status report as
`
`well as the grouping policy of radio bearers could both be fixed specified in
`
`the specification or dynamically configured by the network.
`
`Examples can be found below:
`
`Table 1 shows the same-length indication, the 4 RBG have same length (5
`
`bits) in BSR, while in table 2 we assume RBG3 & RBG 4 require lower
`
`accuracy and reports shorter BSR (3 bits). The presentation of buffer
`
`status here adopts similar mechanism used in UMTS HSUPA,
`
`i.e., the
`
`value is a indicator denoting a specific size region the real buffer size falls
`
`into. For example, in HSUPA, the value "25“ and “13" of the “Total E-DCH
`
`Buffer Status" field indicate the real total buffer sizes are between 6853
`
`bytes and 9103 bytes, and 228 bytes and 302 bytes, respectively. [1] In
`
`HSUPA, only a logarithmic distribution for the buffer size coding is
`
`adopted, but in our proposal,
`
`it is also possible that different buffer size
`
`coding approaches may apply to different RBGs, either logarithmic or
`
`divided equally.
`
`
`3mm91.11299131999196
`
`
`
`Table 1
`
`

`

`
`
`wlmllmjjlwl
`
`Table 2
`
`b) The meaning of the indicated value:
`
`Besides the length of the indication, we may also take a look at the
`
`meaning of the indicated values. To enable the network have the idea for
`
`initial buffer status, there’s always a need to present the exact range of the
`
`occupied buffer bytes size. But
`
`if the RBG occupied buffer size won’t
`
`frequently change in wide margin, the report may not need to take same
`
`long size for bits to indicate the range in all cases. instead,
`
`the
`
`differential/relative presentation may be used to replace the absolute
`
`indication. By indicating the amount of increased/decreased buffer size of
`
`the same RBG compared with the latest status report, the differential-way
`
`may cost smaller report size since the increased/decreased amounts are
`
`not assumed to be large very often.
`
`Another possible way is to present the differential amounts of the different
`
`RBGs in the same status report if the granularity of all RBGs length is
`
`fixed to the same value and the difference of the occupied buffer sizes
`
`between RBGs are relatively small. As the other proposal mentioned
`
`above, this way also require smaller size.
`
`If both absolute and relative presentations exist, the network also needs to
`
`be able to identify the difference between each other.
`
`Examples can be found below:
`
`Table 3 shows the absolute presentation as an initial buffer status report
`
`sent by UE. 4 R863 are reported together. Please note here we also
`
`indicate the RBG id in the table. The RBG id presentation will be
`discussed next.
`
`
`
`IRBID1yBS 1JIRBID #38 2IRBID1’383 ’RBEPflIBS4W
`
`Table 3
`
`Table 4 shows a relative presentation as a following report of Table 3. In
`
`this report, only the buffer of RBG 1 and RBG 3 are slightly increased, so
`
`a differential scheme is adopted, and only 3 bits are needed for each RBG.
`
`Note that a 1-bit field is included to indicate the format of the report. Since
`
`

`

`two different formats might be sent in the BSR.
`
`I
`
`Format Indicator
`W
`
`WWWW...
`WM__i
`1
`
`l1 (Indicating a relative presentation);
`Table 4
`
`Table 5 shows the other alternative, presenting the differential amounts of
`
`the different RBG3 in the same status report. Assume that the buffer
`
`status of RBG1, 2, and 3 are included in the report, and the occupied
`
`amounts of three RBGs have only slight variation. In the table the RBGs
`
`are listed from the RBG with lowest buffer occupancy (RBG 2), and
`
`followed by increasing order in their buffer occupancy. The 1-bit field
`
`indicating the format is also needed.
`
`1
`
`
`
`
`
`
`Table 5
`
`2.2 How to indicate the different RBGs included in the report?
`
`Besides the length of the status report, how to indicate the RBGs included in
`
`the report could also be discussed. As for the length of the RBG id, one
`
`implementation is to set all RBG ids in the same fixed length. But in case the
`
`frequency of each RBG reporting varies a lot, this may be a waste in the total
`
`size.
`
`If the frequency of each RBG reporting could be determined, Huffman
`
`coding for RBG id according to frequencies of different RBG/services might be
`
`adopted. For example, assume there are 4 RBGs in total, and the frequency of
`
`each RBG reporting is 50% for RBG1, 25% for RBG2, 12.5% for both RBG3
`
`and RBG4, setting the RBG id as 0(RB1), 10(RBZ), 110(RBB), and 111(RB4)
`
`may save more total report length than setting the RBG id as 00, 01, 10, and
`
`11. The Huffman coding to be used would be determined depending on the
`
`overall frequency of each RBG reporting. The Huffman coding for each RBG
`
`lD could be specified in the specification or configured by Network.
`
`Another topic is how many RBG ids and status reports should be included in
`
`the report. The simplest way is to include all the R865 in the report for every
`
`condition. But if it is not the case that all RBGs' buffer sizes have changed or
`
`

`

`all the reporting criteria have been triggered, simply include all RBGs’ status
`
`could result in great redundancy in transmission. Thus the different ways in
`
`how to selectively indicate RBGs included in the report need investigation.
`
`a) RBG number indicator and RBG id:
`
`A simple way forward is to use a RBG number indicator, following by the
`
`RBG id and status report to reveal the information.
`
`if the total RBG
`
`number is low, e.g. 4 total RBG, a 2 bit indicator is enough to show the all
`
`possible RBG numbers included in the report. By reading the indicator, the
`
`network has an idea how many RBG status reports are included, and
`
`further information can be read in sequence.
`
`Example can be found below:
`
`Table 6 shows the combination of number-of-RBG indicator, RBG id, and
`
`buffer status. Note that a Huffman-coding based RBG id as mentioned
`
`above is illustrated in table 6.
`
`
`
`1Num§émlmmmmof RB groupsmijBIo 11E§11RBID 3 1B—g—11RBID4113—3—
`
`
`10 (three RB groups)1101111—01—11W1101E11L111—01—1
`
`
`
`
`
`
`
`
`
`Table 6
`
`b) Extension bit for each 'RBG:
`
`At the end of each RBG included, at the end of its RBG id, one extra
`
`extension bit can be included to indicate whether there are more R883 to
`
`be included in same report. If the extension bit is set, the network knows
`
`to read further buffer status information of other RBGs.
`
`Example can be found below:
`
`In table 7, an extension bit field is added after each appearance of RBG id.
`
`“1" indicates “more RBG id follows”, and “0" indicates “no more RBG". The
`
`last extension bit is followed by the buffer status fields of all RBGs.
`
`
`
`
`1—7“WWW
`Table 7
`
`
`
`c) Bitmap indicator:
`
`If the number of RBG is not large, a simple way is to include a bitmap
`
`indicator in the beginning ofthe report, so that the network could easily tell
`
`whether a RBG is included or not through the bitmap. Then the buffer
`
`

`

`status reports could follow in sequence with no confusion.
`
`Example can be found below:
`
`The bitmap field in table 8 indicates that only RBG 1 and 2 are included in
`
`the report, so no more RBG id is included in the BSR. Only the buffer
`
`status parts are included.
`
`SW“
`
`
`@TE
`Table 8
`
`2.3 Triggering related issues
`
`Triggering criteria similar to what is used in UMTS system could be adopted.
`
`Buffer status report might be triggered to sent when some specific periods
`
`expire (periodic report), when some specific event happen (event-triggered
`
`report), or when there’s enough space left in the MAC PDU to fit a report.
`
`For the periodic report, different periods may apply to different RBGs due to
`the characteristics of different services. Similarly, for the event-triggered report,
`
`different event may apply to different RBGs. When one period expires or one
`
`specific event happens, only the related RBGs' BSR are included. This could
`
`also shorten the length of the complete BSR. Another alternative is that even
`
`several RBGs’ BSR are triggered for the same period or same event, only one
`
`specific RBG would be selected and included in the complete BSR.
`
`In such
`
`case, the buffer status of total RBGs need to be indicated also.
`
`Example can be found below:
`
`In table 9 we assume only RBG 1 is triggered, and the BSR includes the RBG
`
`id, the total buffer status, and buffer status of RBG 1, which could be absolute
`
`value of buffer occupancy or percent to the total buffer occupancy.
`
`ITriggered RBG idflas 1% Total g
`z
`E
`;
`ll,
`00
`33101510011E
`
`
`
`
`
`Table 9
`
`

`

`Section 3
`
`Complementary Report
`
`The Complementary Report contains 2 bits, which could be included in the
`
`MAC header or transmitted in the Scheduling Request channel if it is available
`
`for 2 bits.
`
`When the 2 bits is included in the MAC header, it is transmitted every MAC
`
`PDU. When it transmitted in the Scheduling Request (SR) channel,
`
`it
`
`is
`
`transmitted when the SR channel is available for it.
`
`The content of the 2 bits Complementary Reporting divides how much UE is
`satisfied with the resource allocated to it into 4 levels.
`
`lfthere’s only 1 bit for Complementary Reporting, it could be set to 1 if the PBR
`
`of all RBs could be satisfied, otherwise set to 0.
`
`If there's more than 2 bits available for Complementary Reporting, there could
`
`be more than 4 levels according the criteria.
`
`The criteria and the division methods according to the criteria for more than
`
`4-level division could be similar to the ones for 4-level division.
`
`3.1 Criteria for 4 level division
`
`Criteria 1:
`
`Which level UE should set its Complementary Reporting is according to the
`
`following criteria:
`
`1. Whether the PBR or/and MBR of the Radio Bearer (RB) can be satisfied
`
`averagely with the resource allocated;
`
`2. Whether the data in the buffer can be emptied within a certain time with the
`
`resource allocated;
`
`3. The satisfaction of PBR or/and MBR of
`
`the different priority RB
`
`corresponding to different satisfaction level;
`
`4. The buffer of different priority RBs being emptied within a certain time
`
`corresponding to different satisfaction level.
`
`The UEs with PBR of higher priority RB can’t be averagely satisfied should
`
`

`

`report more urgent level than UEs with PBR of lower priority RB can’t be
`
`averagely satisfied.
`
`The UEs with date in the buffer of higher priority RB can't be emptied should
`
`report more urgent level than UEs with date in the buffer of lower priority RB
`
`can’t be emptied.
`
`Hence, when eNB doing the scheduling,
`
`The UEs reporting PBR can't be averagely satisfied should be allocated with
`
`resources prior to the UEs reporting PBR of same priority logical channel can
`
`be averagely satisfied.
`
`The UEs reporting the data in the buffer can't be emptied should be allocated
`
`with resources prior to the UEs reporting the data in the buffer of the same
`
`priority logical channel can be emptied.
`
`With these reporting criteria, the network could have better knowledge of UE’s
`
`buffer status of different priority RBs, hence the fairness among UEs is
`
`guaranteed. The UE with higher priority data to be transmitted is ensured to
`
`get resources first. The resource allocation efficiency is improved and the
`
`overhead of Complete Buffer Status Reporting is reduced.
`
`different
`some
`Here gives
`abovementioned criteria.
`
`4
`
`level
`
`division methods
`
`according to
`
`Example 1 according to Criteria 1:
`
`The details of 4 levels division are as follows:
`
`.
`
`Level 0: The content of the Complementary Reporting is set to 00 which
`
`means the PBR of the highest priority RB can’t be satisfied averagely and
`
`it’s because of inadequate resource allocated instead of there’s no enough
`
`data in the buffer to be transmitted. More resource required in this level,
`
`and it’s with highest priority compare to other UEs;
`
`.
`
`Level 1: The content of the Complementary Reporting is set to 01 which
`
`means the PBR of some RB (but not the highest priority RB) can’t be
`
`satisfied averagely and it's because of inadequate resource allocated
`
`instead of there's no enough data in the buffer to be transmitted. More
`
`

`

`resource required in this level, but not so urgent as UEs reporting 00;
`
`0
`
`Level 2: The content of the Complementary Reporting is set to 10 which
`
`means the buffer of highest priority RB can’t be emptied within Y1 TTls
`
`with current grant and the MBR (if configured) of the highest priority RB
`
`can't be satisfied averagely. More resource can be allocated if available,
`
`but with lower priority than UEs reporting 01 and 00;
`
`0
`
`Level 3: The content of the Complementary Reporting is set to 11 which
`means buffers of highest priority RB can be emptied within Y1 TTls with
`
`current grant or the MBR (if configured) of the highest priority RB is
`
`satisfied averagely. No more resource needed. Resource can be reduced
`
`if there are no sufficient resources for other higher priority UEs.
`
`The flow chart of how to set the 2 bits content of the Complementary Reporting
`
`as the 4 level divisions in Example 1 according to Criteria 1
`shows.
`
`is as Figure 1
`
`

`

`UL Grant recieved
`
`.. ether PBR of High-
`priority RB could not be
`satisfied averagely with
`current Grant?
`
`‘1 ether it’s because 0
`enough data to be
`transmitted?
`
`and MBR (if is configured) of
`
`hether PBR of any R :
`could not be satisfied
`r eragely with current Gra -
`
`‘
`
`ether it’s because 0
`enough data to be
`transmitted?
`
`Y1 TTIs with current grant
`
`Figure 1 Flow Chart of Example 1 according to Criteria 1
`
`Example 2 according to Criteria 1:
`
`If eNB has some mechanism in order to satisfy PBR of all RBs, the level 0 and
`
`level
`
`1
`
`in Method 1 would not happen frequently. These 2 levels could be
`
`combined together into 1 level. And a new level could be added in. Hence the
`
`four levels are as follows:
`
`.
`
`Level 0: The content of the Complementary Reporting is set to 00 which
`
`means the PBR of some RB can’t be satisfied averagely and it’s because
`
`of inadequate resource allocated instead of there’s no enough data in the
`
`buffer to be transmitted. More resource required in this level, and it's with
`
`highest priority compare to other UEs;
`
`

`

`0
`
`Level 1: The content of the Complementary Reporting is 01 which means
`
`the buffer of highest priority RB can’t be emptied within Y1 TTls with
`
`current grant and MBR (if is configured) of the highest priority RB can’t be
`
`satisfied averagely. More resource can be allocated if available, but with
`
`lower priority than UEs reporting 00;
`
`0
`
`Level 2: The content of the Complementary Reporting is set to 10 which
`
`means the PBR of all RBs can be satisfied and the highest priority RB can
`
`empty its buffer within Y1 TTls with current grant, but not all the buffers
`
`could be emptied within Y2 TTls. More resource can be allocated if
`
`available, but with lower priority than UEs reporting 00 and 01;
`
`0
`
`Level 3: The content of the Complementary Reporting is set to 11 which
`
`means buffers of all RBs can be emptied within Y2 Tris with Current grant.
`
`No more resource needed, and resource can be reduced if there are no
`
`sufficient resources for other higher priority UEs.
`
`The flow chart of how to set the 2 bits content of the Complementary Reporting
`
`as the 4 level divisions in Example 2 according to Criteria 1
`shows.
`
`is as Figure 2
`
`

`

`UL Grant recieved
`
`‘ ether PER 0f some >
`could not be satisfied
`averagely with current
`Grant?
`
`~
`- ether it's because 0
`‘
`'epo I I o
`enough data to be wtr n mitt
`7
`a 3
`ed
`
`Y1 TTls with current grant
`and MBR (if is configured) of
`
`‘ ether it’s because 0
`enough data to be
`transmitted?
`
`'epo 0
`‘k=
`
`o
`
`emptied within Y2 TTls
`
`all the buffers could be
`
`Figure 2 Flow Chart of Example 2 according to Criteria 2
`
`Criteria 2:
`
`If Token Bucket mechanism