04913
`
`Ex. 2001
`T-Mobile USA, Inc. v. Intellectual Ventures II LLC
`IPR2018-01775
`
`

`

`PA 7048696
`
`
`
`
`
`OFFICE OF THOSE PAPERS OF THE BELOW IDENTIFIED PATENT
`
`APPLICATION THAT MET THE REQUIREMENTS TO BE GRANTED A
`
`FILING DATE UNDER 35 USC 111.
`
`FILING DATE: March 21, 2006
`
`
`
`
`
`UNITED STATES DEPARTMENT OF COMMERCE
`
`
`United States Patent and Trademark Office
`
`
`January 24, 2007
`
` THIS IS TO CERTIFY THAT ANNEXED HERETO IS A TRUE COPY FROM
`
`
`
`THE RECORDS OF THE UNITED STATES PATENT AND TRADEMARK
`
`
`
`
`
`APPLICATION NUMBER: 60/784,680
`
`
`THE COUNTRY CODE AND NUMBER OF YOUR PRIORITY
`
`
`APPLICATION, TO BE USED FOR FILING ABROAD UNDER THE PARIS
`
`
`
`
`
`CONVENTION,IS US660/784,680
`
`By Authority of the
`Under Secretary of Commercefor Intellectual Property
`and Director of the United States Patent and Trademark Office
`Ag
`fe,
`
`orLLA Cho
`Certifying Officer
`
`M. SIAS
`
`Saracen
`ens
`
`04914
`
`
`
`04914
`
`

`

`Se 2a
`©
`i
`wh
`9°
`=a
`a
`See °
`PTOVSB/16 (10-08)
`N = c
`‘
`Approved fer usethrough 97/31/2006. OMB 0651-0032 =
`oS =e wo
`oO
`U.S. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`= Urtaprthe Paperwork ReductionAct of 1995, ng persons are required to respond to a collection ofinformation unless it displays 6valid OMB contre! number. N
`oO
`PROVISIONAL APPLICATION FOR PATENT COVER SHEET — Page1 of 2
`Bs
`This is a requestfor filing a PROVISIONAL APPLICATION FOR PATENT under 37 CFR 1.53(c).
`_
`
`Express Mail Label No.EV.G5651218BVS ~
`
`60/784680cE
`
`
`
`
`and either State or Foreign Country)
`
`
`
`
`ee
`a
`
`
`
`
`
`Ce
`
`
` Direct all carrespondance to:
`CORRESPONDENCE ADDRESS
`
`Tha address corresponding to Customer Number:
`036864
`
`OR
`ratios Name Lae, Hong, Degerman, Kang & Schmadeka
`
`Address 301 South Figueroa Street, 14th Floor
` City
`
`Los Angeles
`
`
`Country u.5.A.
`ENCLOSED APPLICATION PARTS (check allthatanph)
`
`
`
`(_] Apptication Data Sheet. See 37 CFR 1.76
`CJ cfs), NumberofCDs
`[v] Specification NumberofPages 17
`| Other(specify)
`
`
`CJ Drawing(s) NumberofSheets
`
`
`If the specification and drawings exceed 100 sheets of paper, an application size fee is
`Fees Due: Fiting Fee of $200.($100 for small entity},
`also dua, which is $250 ($125 for sma!l entity) for each additional 50 sheets or fraction thereof. See 35 U.S.C. 41(a}(1)(G) and 37 CFR 1.18(s}.
`
`
`METHOD OF PAYMENT OF THE FILING FEE ANDO APPLIGATION SIZE FEE FOR THIS PROVISIONAL APPLICATION FOR PATENT
`
`
`|_| Applicant claims smal! anilty status. See 37 CFR 1.27.
`
`Lv} A check or money orderis enclosed to coverthe filing fee and application sizefee (if applicable).
`
`TOTAL FEE AMOUNT($}
`[] Payment bycredit card, Form PTO-2038 Is attached
`
`
`The Director is hereby authorized to changethefiling fee and application size fee {if applicable) or credit any overpayment to Ceposit
`
`
`
`
`Account Number:_§02290==Ss A dpiicative copy of this form is enclosed for fee processing.
`USE ONLYFOR FILING A PROVISIONAL APPLICATION FOR PATENT
`This collection of information is required by 37 CFR 1,51. The information Is required to obtain or retein a benefit by the pubilc which isto fle (and by the USPTO
`to process) an application. Confideniality is governed by 36 U.S.C. 122 and 37 CFR 1.11 and 1.14. This collection la estimated to lake 8 hours to compicia,
`including gathering, preparing, and submitting the completed application form to the USPTO, Time will vary depending upon the individual case. Any comments
`on the amount of ima you require to complete this form and/or suggestions for reducing this burden, should be sent to the Chief Information Officer, U.S. Patent
`and Trademark Office, U.S. Department of Commerce, P.O. Box 1460, Alexandria, VA. 22313-1480, DO NOT SEND FEES OR COMPLETED FORMSTO THIS
`ADDRESS. SEND TO: Commissionerfor Patents, P.O. Box 1450, Aloxaridrla, VA 22313-1480,
`:
`ifyou need assistance In completing the form, call 1-300-PTO-9199 and select option 2.
`
`
`
`Additional inventors are being named onthe ______2nd____seperately numbered sheets altached hereto
`TITLE OF THE INVENTION (500 characters max):
`
`OVERALL ASPECTS FOR LTE SYSTEM
`
`
`
`
`
`
`Copy provided by USPTO from the IFW InppgeDatabase on 01/18/2007
`
`04915
`
`

`

`PROVISIONAL APPLICATION COVER SHEET
`Page 2 of 2
`
`PTOYSE/16 (10-08)
`for use through 07/31/2008. OMB 0851-0032
`U.S. Patent and Trademark Office: U.S, DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1895, no persons are required to respond to a collection of information uniess it displays a valid OMB contro! number.
`
`‘The invention was made by an agency ofthe United States Government or under a contract with an agency of the United States Government.
`No.
`
`CI Yos, the name of the U.S. Government agency and the Govemment contract number ore:
`
`WARNING:
`.
`Petitioner/applicant is cautioned to avoid submitting personal information in documents filed in a patent application that may
`contribute to identity theft. Personat information such as social security numbers, bank account numbers, or credit card
`numbers {other than a check or credit card authorization form PTO-2038 submitted for payment purposes)is never required by
`the USPTO to support a petition or an application.
`If this type of personal informationis included in documents submitted to
`the USPTO,petitioners/applicants should consider redacting such personalinformation from the documents before submitting
`them to the USPTO. Petitioner/applicant is advised that the record of a patent application is available to the public after
`publication of the application (unless a non-publication request In compliance with 37 CFR 1.213(8} is made in the application)
`or issuance of a patent. Furthermore, the record from an abandoned application may also be available to the public if the
`application is referenced in a published application or an issued patent (see 37 CFR 1.14). Checks and credit card
`authorization forms PTO-2038 submitted for payment purposes are not retained in the application file and therefore are not
`publicly available.
`SIGNATURE
`
`Date_March 21, 2006
`
`e
`
`TYPED or PRINTED NAMELew Edward V. Macapagal
`
`REGISTRATION NO.55.416
`(# appropriate)
`TELEPHONE .213-923-2221 Docket Number: 2101-9196
`
`
`
`_ Copy provided byUSPTO trom the IFW imageDatabase on 01/18/2007
`
`04916
`
`

`

`PROVISIONAL APPLICATION COVER SHEET
`Additional Page
`
`PTOMSBN6 (12-04)
`for use through 07/31/2006. OMB 0651-0052
`U.S. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`‘Under the Paperwork Reduction Act of 1895, no persons are required to respond to a collection of information unless it displays a valid OMB control number.
`
`INVENTOR(SVAPPLICANT(S}
`
`
`
`
`
`
`[henName(standmiddleenyp|____—FamityorSumame|‘Siateor
`
`Given Name(first and middie [if an:
`
`Family cr Surname
`
`City
`
`and either State or Foreign Cou
`
`
`
`Number
`
`1 ff
`
`WARNING:Information on this form may become public. Credit card information should not be
`included on this form. Provide credit card Information and authorization on PTO-20358.
`
`Copy provided by USPTO from the IFW imageDatabase on 01/18/2007
`
`04917
`
`

`

`PROVISIONAL APPLICATION FOR
`UNITED STATES PATENT
`IN THE NAMES OF
`
`Young-Dae LEE, Myung-Cheul JUNG,
`Sung-Duck CHUN, Sung-Jun PARK,
`Patrick FISCHER and Dragan Vujcic
`
`for
`
`OVERALL ASPECTS FOR LTE SYSTEM
`
`prepared by:
`
`Lee, Hong, Degerman, Kang & Schmadeka P.C.
`801 S. Figueroa Street, 14" Floor
`Los Angeles, CA 90017
`Tel: (213) 623-2221
`Fax: (213) 623-2211
`
`Customer Number 035884
`
`- Attorney Docket No.: 2101-9196
`
`Express Mail No.: EV 656512188 US
`
`Total Number of Pages: 17 (including cover)
`
`BEST AVAILABLE CNP*’
`
`Copy provided by USPTO from the [FW ImageDatabase on ot8/2007
`
`04918
`
`

`

`R2-O5xxXxx
`
`
`
`Agenda Item : 11
`Source
`: LG Electronics
`
`: Considerations on LTE multicast & broadcast
`Title .
`Document for : Discussion and Decision
`
` 1
`
`Introduction
`
`This document proposes some considerations on LTE multicast/broadcast.
`
`
`2 Bandwidth scenarios and UE capability for
`multicast/broadcast
`
`At this moment, whether multicast/broadcast is mandatory or optional is not clear in the UE side. Decision on this
`would impact on specification of LTE multicast/broadcast.
`
`If multicast/broadcast is mandatory in the UE side, minimum UE capability for multicast/broadcast is 10 Mhz
`because it was decided to be 10 Mhz last month. Inthis case, if cell bandwidth is larger than 10 Mhz, UE mayneed to
`select which service it should receive when multicast/broadcast and unicast services are simultaneously transmitted.
`In.some cases, UE may lose the multicast/broadcast in case the multicast/broadcast service has a lower priority than
`the unicast service,
`
`‘If we wish to avoid this situation, every LTE UE needs to support a !arger than 10 Mhz with multicast/broadcast (10
`Mhz + multicast/broadcast service bandwidth). Furthermore, if there is a dedicated carrier for multicast/broadcast
`services which is different from a carrier for unitcast services, every LTE UE needs to support a dual receiver to
`receive a carrier for unicast services and another carrier for multicast/broadcast services, If it is difficult to mandate
`larger minimum UE bandwidth than 10 Mhz or dual receiver to LTE UE, then multicast/broadcast may need to be
`optional in the UEside.
`
`the following points should be decided before design of
`
`Based on the discussion above, we think that
`multicast/broadcast transmission:
`Q1) Should UE support multicast/broadcast in a mandatory or optional manner?
`Q2) Whatis minimum UE bandwidth with multicast/broadcast?
`Q3) Should UE supporting mutticast/broadcast feature support dual receiver in a mandatory or optional
`manner?
`.
`
`
`3 Multicast/broadcast service scenarios
`
`The current discussion on MBMS requirements [1] show there are two types of service scenarios: cell specific
`contents and cell group contents. Thé cell specific contents could be R99 CBS-like service i.e. message distribution,
`which are a single cell transmission. The cell group contents could be TV broadcasting services, which is a multi-cell
`‘transmission,
`
`“We think multi-cell transmission should use a combining technique (desirably soft combining), so that a channel for
`multi-cell transmission of multicast/broadcast services is somewhat different from a DL shared channel which is used
`for most of cases. And multi-cell transmission of a multicast/broadcast service would cover muitiple eNode Bs.
`Therefore, a central node is needed as a source of muiti-cell transmission. (NOTE: In this case, one PDCP entity
`exists for one service in aGW.)}
`.
`
`3GPP
`
`
`
`“Copy providedbyUSPTO fromthe IFW iqagpPalabaseon 01/16/2007
`
`
`
`04919
`
`

`

`On the other hand, single cell transmission dose not need any combining. Thus, characteristics of the single cell
`transmission channel seem to be different from the multi-cell transmission channel. We think that a DL shared
`channel could support the single cell transmission, instead of introducing another single cell transmission channel.
`Andsingie cell transmission covers only one-cell or one ¢NodeB.In this case, locating single cell transmission at the
`centor node is questionable. However, one commonarchitecture may be preferable for both single and multi-cell
`transmissions. (NOTE:In this case, one PDCPentity exits per cell/eNode Bor per a group ofcells for one service in
`aGW.FFS)
`«
`Furthermore,if a text message distribution like R99 CBS is supported, it is questionable whether a L2 entity like a
`BMCentity is needed or not. R99 BMC did storing, formatting, scheduling, transmitting and repeating CBS
`messages. On the other hand, in R6 MBMS,such functions were mostly done at BM-SC. Thus, we need to discuss
`need for a specific handling of message distributions in Layer 2. (NOTE:if repetition at lower layer is necessary ¢.g.
`for safe distribution of text or multimedia messages, ARQ layer at E-Node B could do repetition of
`broadcasi/multicast packets like R99 BMC.)
`‘Q1) Should LTE support both multi-cell and single cell transmission?
`Q2) Does message distribution service like R99 CBS require a L2 entity like R99 BMC layer in the LTE
`access network?
`
`
`4 Interworking with MBMS on WCDMA
`
`It is questionable whether or not the following scenarios between WCDMA MBMSand LTE MBMSisfeasible:
`1)
`In the case a UE supporting both WCDMA MBMS and LTE MBMS moves from a WCDMA MBMSareato a
`LTE MBMSarea or moves from LTE MBMS to WCDMA MBMSwhile receiving the same MBMSservice
`Inthe case a UE camping on a WCDMAcell receives MBMSfrom a LTE cell e.g. on a dedicated carrier to LTE
`MBMS.
`
`2)
`
`Inthe case a UE camping on a LTEcell receives MBMS from a WCDMAcell c.g. on a preferred layer.
`3)
`Weneed to discuss if oné or more of the scenarios above need to be supported or not. The first point above may show
`a possibility to share the same BM-SC node between LTE MBMS and WCDMA MBMSfor one MBMSservice.
`
`5 Conclusion
`
`We propose in this document
`multicas/broadcast,
`
`that some points should be discussed before detailed discussion on LTE
`
`
`
`References
`
`[1] RP-060215, “Introduction of specfic requirements for support of Broadcast mode in MBMSin LTE”, Orange
`
`3GPP
`
`uaaarenRR
`
`# Database on 01/18/2007
`
`04920
`
`

`

`FR2-O6XXXX
`
`Agenda Item : joint meeting 3.2
`Source
`: LG Electronics
`
`: Scenarios of synchronized Random Access
`Title
`Documentfor: Discussion and Decision
`
`
`
`Introduction
`
`After Denver meeting, the discussion on RACHhas discussed via e-mail reflector. Then some possible
`points are clarifiedand captured into TP on RACH. However, some points to be clarified still exist. One of
`them is when a UE uses synchronized RACH. So, thepurpose of this documentis to clarify that point and
`discuss the scenarios onit.
`
`
`
`Discussion
`
`According te the TP on RACH, the synchronized random accessis used when a UE uplinkis time
`synchronized by the node B. And the purposeis for the UE to request resource for uplink data transmission.
`
`in our understanding, since uplink data to be transmitted arrive to buffer of a UE, the VE would use
`synchronized random access whenit.does not have valid uplink resource. Therefore, we are assuming that
`new data arrive to the UE’s buffer in below cases in this paper.
`We describe possible cases In synchronization as follows.
`Case 1. whena UE hasuplink data
`
`In this case, the UE is transmitting the uplink data to network. Therefore, since RR
`(Resource Request) can be sent overin-band signaling, synchronized RACH procedureis
`not needed.
`
`Case 2. when a UE does not have uplink data but the UE is receiving downlink data from network.
`
`In this case, although the UE doest not have uplink data, uplink resource should be allocated
`to send control signals associated downlink data such as CQI, ACK/NACK. Regarding
`allocation for this resource, there would be three pessible methods.
`
`i.
`
`ii.
`
`iii.
`
`Oneis to continuously assign resource forit. However, the cost of this scheme seems to
`be large since there is a need to reserve resource regardless existence of downlink data.
`But if a UE usesthis resource by meansof 1 bit indicator or RR, synchronized RACH
`procedure is not needed.
`
`Second oneis to assign resource when downlink data is sent. The information of
`SR(Scheduled Resource) could be sent along with downlink data. In this case, since a
`UE cannot know when downlink data will be sent and the SR will be indicated, UE can not
`wait to use the SR until downlink data arrives. Therefore,in this case, synchronized
`RACHprocedure should be needed.
`
`Last oneis to periodically assign resource according to a sort of downlinktraffic. If a sort
`of downlink traffic is periodical : e.g. MPEG and VoIP, a UE can predict when the next
`downlink traffic will arrive. In other words, the UE can forecast next SR. Therefore,
`synchronized RACH procedure might be needed according to intervaloftraffic.
`
`IGPP
`
`Copy provided by USPTO.from the IFWImageDatabase on 01/18/2007
`
`04921
`
`

`

`Case 3. whenaUE does not have uplink data and the UEis not receiving downlink data from
`network, but the UE has not moved to DRX cycle yet.
`
`Althoughthis case lookslike DRX due to no uplink and downlinktraffic, it could be assumed
`that this is when UE is moving from ACTIVE to DRX.In this case, a UE should periodically
`send uplink reference signal to maintain UL synchronization. This interval could be
`determined by mobility of the UE.If there is a fast moving VE, the UE frequently sends
`uptink reference signal to get UL synchronization while a stationary UE rarely sends uplink
`reference signal becausethe situation of the channel remains unchanged. Thus the VE can
`predict next time of uplink reference signal. Therefore, in this case, synchronized RACH
`procedure might be needed according to mobility of the UE.
`
`Case 4. when a UE does not have uplink data and the UE is not receiving downlink data from
`network and the UE has moved to DRX cycle.
`
`In this case, the UE would send uplink reference signal according to DRX cycle. This case
`can be treated as CASE 3. Accordingly, in this case, synchronized RACH procedure might
`be needed according to the length of DRX cycle.
`
`
`
`Summary
`
`The following table summarize the Random Access scenarios in synchronized case.
`
`Table 1. Summary on the scenarios on synchronized Random Access
`
`
`comments
`is the UE receiving|DRX|Synchronized
`is the UE having
`
`DL transmisston 7
`uplink data to be
`
`
`transmitted?
`
`peeParteTR
`
`CH
`
`
`
`
`
`
`
`
`
`
`
`
`
`Yes
`
`Not needed
`
`Continuous assignment
`
`should be needed
`
`Event -triggered assignment
`
`might be needed
`
`Periodical assignment and
`accordingto intervaloftraffic
`
`might be needed
`
`According to UE mobility
`
`
`
`
`might be needed
`
`Accordingto length of DRX cycle
`
`Conclusion
`
`Wepropose to discuss the scenariosin this paper and to capture the agreeable parts in the TR.
`
`3GPP
`
`Copy provided by USPTOfrom the IFW Image,Databaee on 01/18/2007
`
`04922
`
`

`

`R2-O060xxx
`
`Agenda item:
`
`x.X
`
`Source:
`
`LG Electronics Inc.
`
`Title:
`
`UE state transition in LTE_ACTIVE
`
`Document for:
`
`Discussion, Decision
`
`
`
`1.
`
`Introduction
`
`Atlast joint meeting with SA2 and RANG in Denver, it was agreed that power saving performance of VE in
`LTE_ACTIVEshould be comparable to that of UE in LTE_Idle. In this document, we look into UE in LTE_ACTIVE.
`
`
`
`2.
`
`Discussion
`
`2.1 Synchronization in LTE_ACTIVE UEs
`in-OFDMsystem,it is important that transmissions from all UEs should be synchronized at eNB. To achieve this, eNB
`send command to the UE to advance or delay the UE’s transmission timing based on the received UE signal. This
`operation does not occur only once..Due to VE mobility or channel condition, the synchronization status should be
`monitored continuously and UE transmission timing has to be adjusted according to the measurement.
`
`Butthis does not come without cost. To measure the transmission synchronization status in uplink direction, UE have to
`transmit among uplink data, pilot, CQI, or ACK/NACK,etc. Thus, to keep VE in synchronized state, the eNB should
`schedule uplink transmission even whenthere is no uplink and downlink data for the UE. This will not only limit the
`usable radio resources but also reduce the standby or talk-time of the VE.
`
`Thus, when there is no traffic for a UE, to keep a UE synchronized in uplink direction does not seem good approach.
`Furthermore, if the transition time from non-synchronized state to synchronized state is small, then this impact on the
`user experience will be quite small.
`Accordingly, it is proposed to allow for a LTE_ACTIVE UE notto maintain synchronization in uplink.
`2.2 Transition from Non-sync to Sync of LTE_ACTIVE VE
`Ifwe agree to allow non-unsynchronized LTE_ACTIVE UE,then there should be a mechanism to bring back the UE to
`synchronized state. Two use scenarios are scen. First event is when a UE has uplink data to transmit and the second case
`is when eNB has downlink data to transmit.
`
`In first case, because a UE has no dedicated resource, it has to first perform RACH procedure to synchronize uplink and
`to notify its buffer status. After that, a UE can transmit uplink data using allocated dedicated resource.
`
`in the second case, following procedures should be performed before actual downlink transmission.
`
`First procedure is to notify upcomingtraffic to the UE. If DRXmechanism for LTE_ACTIVEis used for LTE_ACTIVE
`UEto save power consumption, the eNB will indicate the pending downlinktraffic at the wake-up timing of the UE. As
`a simple solution, UE temporary ID assigned by eNB will be indicated by L1/L2 contro} information.
`
`Next procedure is to synchronize VE uplink transmission. Without synchronized uplink, paging of incoming data will be
`useless. [t's because low error ratio of data transmission will be ensured by using HARQ and HARQrequires feedback
`from receiving side. Additionally, receiving side needs to report CQI informationto assist transmitter’s selection of
`
`_ Copy provided byUSPTO from the IFW Image,Database on 01/18/2007 ——
`
`04923
`
`

`

`resource block, To guarantee reliable reception of these pieces of information at eNB, it is required to synchronize
`uplink before actual downlink traffic transmission.
`
`But to let UE to synchronize uplink by using RACH will not be optimal. Because RACH is contention based channel,it
`isnot free from conflict. Then following two options can be pursued to reduce time in achieving synchronization.
`
`Option 1: To assign UE dedicated RACH signature.
`
`In this option, eNB allocate special RACH signature while notifying pending downlink traffic. Because it is a UE
`dedicated signature, it’s easier for ENB to react. And because it’s UE dedicated signature, there will be no confliction
`between multiple UEs.
`
`Option 2: To assign UE dedicated resources.
`
`In this option, eNB allocate a dedicated radio resource. That resource is used to synchronize UE uplink transmission.
`Thus, its subframe format will be quite similar to that of RACH. Because the resource is used only by that UE,the
`detection is reliable and synchronization will be quite small. [fFeNB allocates radio resource for CQI also, then it will
`be useful to eNB’s scheduling.
`
`Conctusion:
`
`Dedicated radio resource is used to regain uplink synchronization for non-synchronized LTE_ACTIVE UE.
`
`
`
`3. Conclusion
`
`It is proposed to discuss and agree to:
`
`-
`
`Use of dedicated radio resource to re-synchronize uplink of non-synchronized LTE_ACTIVE UE.
`
`
`
`4.
`
`Reference
`
`(1) R2-060xxx, LTE, LG Electronics
`
`Copy provided by USPTOfrom the IFW ImageDatabase on 01/18/2007
`
`04924
`
`

`

`R2-O5xxxx
`
`Agenda Item : 3.1
`Source
`: LG Electronics
`
`: Disucssion on LTE Paging and DRX
`Title
`Documentfor : Discussion and Decision
`
`
`
`Introduction
`
`This document discusses how to specify Paging and DRX procedure and PCH channel in LTE.In this document, the
`DRX procedure is defined as a procedure controlling inactivity of a UE in active mode for UE battery powersaving.
`
`
`
`Differences between Paging and DRX
`
`We.consider that the paging procedure is used by aG'W to find at which cell in a tracking area a UEis and to offer
`efficient UE battery power management. The paging procedure is applied only to a UE in idle mode. Since a paged UE
`has no short UE id (e.g. C-RNTDallocated by a cell, a paging message will carry a longer UE id e.g. IMSI and TMS.
`This paging procedure should be distinguished with the DRX procedure for an active UE.
`
`The DRX procedure for active mode is used by eNode B to offer efficient UE battery power management. The paging
`procedureis applied only to a UE in active made. If DL/ULtraffic is temporarily inactive, eNode B may apply this
`DRX procedure to a UE in active mode. If this DRX procedure is applied, the UE would discontinuously monitor DRX °
`signaling sent on DL according to a cycle set by the eNode B. Since an active UE has a short UE id (e.g. C-RNTI)
`allocated by a cell, eNode B can lead a UE with DRX to wake up by indicating the short UE id.
`In summary, Idle mode Paging and active mode DRX are different as follows:
`
`
`
`
`nenepeePagingProcedure DRX Procedure
`
`
`Idle mode
`
`
`aQW:paginginitiation
`eNode B
`eNode B: paging transmission
`
`
`A cell
`A short identity (e.g. C-RNTID
`A longidentity (e.g. IMS], TMS1}
`
`
`allocated by ASin eNode B
`atlocated by NAS
`
`:
`Controlling network node
`Signalled Area
`.
`.
`.
`Signalled UE identity
`
`Whatlong and short identies are needs to be further studied. However, we think that UE identies for idle and active
`mode would be different.
`
`It might be a good idea to use the long identity all the time in order to avoid the problems that we had where UEs go to
`idle mode, and theNodeB believes that they are in connected mode and vice versa... That's a patent that I wanted to
`make some time from now...
`
`
`
`Air Interface for Paging and DRX
`In the section above, we discuss how paging and DRX proceduresare different. We think the differences between them
`should be considered when we design the LTEair interface.
`
`At this moment, the PCH channelis defined in TR 25.813 for transmitting a paging message. However,it is not so clear
`whether or not PCHis also used for DRX ofan active UE.
`
`3GPP
`
`Copy provided by USPTOfrom the IFW inppge-Database on 01/18/2007
`
`04925
`
`

`

`In case of the DRX procedure, a short UE identity which may be equalto or less than 16 bits could be easily embedded
`into L1/2 control information at the first symbol of a sub-frame, It Is because L1/2 control information e.g. for DL/UL
`SCH would use the short UE identity as well. Thus, wake-up signaling of active UEs with a short UE identity may be
`compatible with L1/2 control information.
`
`On the other hand, a long UE identity which may be 32 bits may not be compatible with Li/2 control information. It is
`because L 1/2 control information e.g. for DL/UL SCH would not use the long UE identity. Thus, a paging message with
`the long UE identity could not be embedded into L,1/2 control information. However,if PICH is necessary, PICH could
`be embedded into L1/2 control information because PICH would carry a short size of quick indications.
`
`Therefore, the following points could be concluded.
`
`1} Only a UEin idle mode shail monitor a PCH channel based on a long UEidentity for UE power saving.
`
`2} A UE inactive mode may monitor L1/2 control information with a short UE identity in a cycle set by eNode B
`for UE power saving.
`
`3)
`
`4)
`
`Ifan active UE with DRX is scheduled, eNode B wilt insert the short identity of the UE into LI/2 control
`information including scheduling information accordingto the set cycle.
`
`[fan active UE with DRX is not scheduled, , eNode B will not insert the short identity ofthe UE into L1/2
`control information according to the set cycle.
`
`
`Paging Indicator Channel
`PICH may have a benefit for UE battery saving because UE is quickly able to check its own paging by simply decoding
`Paging Indications on PICH. Decoding a paging indication will be quicker than decoding a paging message. Thus, the
`PICH channel may be need in LTE for efficient UE power saving. Furthermore, PICH could do frequency hopping for
`frequency diversity. The hopping information could be given from system information. Alternatively, L1/2 control
`information could be used instead of PICH.
`i’m not sure whetherthere is really a gain from the receiver operation, and the message decoding should not be teo
`long, so 1 am not sure where there is a gain. Sending a small block is difficult to protect for a coding point of view,
`therefore a big block with th identities immediately might not be a bad idea.
`
`
`
`Conclusion
`
`It is proposed to discuss the following points:
`
`©
`
`e
`
`©
`
`Two UE power saving schemes are used based on RRC modei.e. the paging procedure for idle moe and DRX
`procedure for active made.
`
`The paging procedure for idle mode relies on the PCH channel, possibly with short indications such as PICH
`or L1/2 control information.
`
`The DRX procedure for active mode relies on L1/2 control information which is used for DL/UL SCH.
`
`3GPP
`
`
`
`Copy provided by USPTO from the IFWImageDatabase on 01/18/2007
`
`
`
`04926
`
`

`

`R2-060890
`
`Source:
`
`LG Electronics
`
`Title:
`‘AgendaItem:
`
`LTE Random Access Use Cases
`Joint03.2 - Random Access
`
`Discussion & Decision
`Documentfor:
`
`
`1.
`
`introduction
`
`RACHhas been discussed in RAN2 in RAN2 #53, and a LS has been sent to RAN] in [1] order to progress
`the discussion we give our view in the following, and provide proposals for further study for different
`issues.
`
`2. Random Access Use Cases
`
`initial access to obtain L1
`It has been identified that random.access procedure can be used for
`synchronization, for resource request when no UL resources are available and for control of UE mobility.
`Theses use cases can be classified into 3 different states:
`
`*
`
`e
`
`Idle mode UE / Detached modeVE / UE Mobility
`
`Synchronized active UE without resources
`
`e Non- Synchronized active UE without resources (under FFS in RAN2)
`The different possible procedures for each state are discussed in following.
`
`3. Idle mede UE / Detached VE / UE Mobility
`
`Considerations on the Bandwidth and the preamble length
`In these states the main purpose should be to detect the UE, calculate the necessary timing alignment, and
`allocate uplink resources for the UE. According to our understanding the minimum BW for non-
`synchronized random access transmission should be 1.25 MHz. Indeed as shown in figure below the
`autocorrelation function presents a lobe for localized mapping scheme which offers better timing estimation
`than equidistant mapping scheme. The lobe width is approximately equal to 1/BW which should be a
`fraction of the cyclic prefix for timing uncertainty. For a BW of 1.25 MHz, the autocorrelation lobe is in
`the order of 0.8 ys which is sufficiently smaller than the typical CP duration (approximately 5 ps). For BW
`less than 1.25MHz, for instance BW of 375 KHzthe uncertainty increases threefold and thus if such a BW
`would be used it is necessary to evaluate the impact of the timing uncertainty on the uplink transmission,
`althoughthe this can be advantageousin order to take advantage of the frequency selectivity ofthe channel.
`
`autocorrelation
`
`04927
`
`

`

`Accordingto our analysis [2] it should be possible to have a reasonable performance for the detection in the
`case of 3 symbols in the case of the TU channetat 3 km/h. Howeverit is important to agree on the
`assumptions for the simulations.
`
`Proposal:
`In order to decide on the above pointsit is necessary to make assumptions on:
`*
`The required precision for the timing
`«
`The maximum achievable SNR in the ULat the NodeB,i.e. the necessary assumptions on the link
`budget
`Based on these assumptionsit should be possible to estimate the number ofsymbols necessary for the
`transmission ofthe preamble for the different bandwidths, and different speed and channels after further
`simulations in the Mai or June meeting.
`
`Different possible procedures
`Three random access procedures are possible as iJlustrated in Figure 2 below:
`UE
`Network
`
`Preamble + (rand [Id FFS + Est.Cause + RR}
`
`UL DataAllocate resources + C-RNTIFFS + TA +
`
`Option 1
`
`Option 2
`
`RRC massage on UL-SCH
`
`Preamble
`
`SR resource allocation + C-RNTI FFS + TA + Power
`Adjustment
`
`RR +(C-RNTI + EstCause + part of RRC message
`
`UL-SCH Resource Allocation if it is needed
`
`Figure 2: Options for the unsynchronized RACH procedure
`
`In option | on contention channel the preamble and message payload including X bits message (TBD)
`containing some information on UL resources needed,priority, establishment cause, and possibly random
`Id to assist in resolution cf contention, are combined together. After the X bits have been decoded by the
`network,
`it responds with the necessary timing advance information to be used on the UL SCH and
`requested scheduling grant, evt other required information. In a case when no resource request can be sent
`(due to some coverage issue) the necessary amount of UL resource to allocate can be either constant
`regardless the random access cause, or based on the preamble linked to the access cause, When getting
`uplink allocation the UE transmits the 1.3 messages, MAC data or contro! PDU,on the scheduled resources.
`In option 2, only the preamble is transmitted by the UE on contention based channel. When detected by the
`network signalling resources are allocated to the UE. Then on scheduled resources the UE send the
`scheduling grant. The network adjusts the resource allocation depending on the UE needs for message
`payload part transmission. This procedure avoids that the network allocates inadequate resources for the
`transmission of the RRC message andto treatpriorities correctly.
`
`
`
`Copyprovided by USPTO from the IFW ImageDatabase on01/18/2007
`
`04928
`
`

`

`The choice between the possible options is a trade off between the time that is used for the additional
`transmission of information to request UL SCH resources and the resources wasted and the interference
`created by transmitting the resource request toget