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

`

`
`
`
`
`
`
`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
`
`
`
`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.
`
` APPLICATION NUMBER: 60/784,680
`
`FILING DATE: March 2], 2006
`
`CONVENTION, IS US60/784, 680
`
`'
`
`
`
`
`THE COUNTRY CODE AND NUMBER OF YOUR PRIORITY
`
`
`APPLICATION, TO BE USED FOR FILING ABROAD UNDER THE PARIS
`
`
`By Authority of the
`
`Under Secretary of Commerce for Intellectual Property
`and Director of the United States Patent and Trademark Office
`
`
`Certifying Officer
`
`
`g
`
`y
`
`C/L/f gig/(fl;
`
`M. SIAS
`
`_., f 7
`mmzm
`
`
`
`04914
`
`04914
`
`

`

`.
`
`G)
`a "
`0
`g 0’
`E
`8m 3
`'0,
`Preteens (10-05)
`'3g c:
`Approved for use through oriatrzoos. OMB 0651-0032 3
`'
`0 g in
`U.S. Patent and Trademark Office: us. DEPARTMENT OF COMMERCE
`OD
`-
`.‘i g "'3' the Papenrrottt Reduction Act at 1936. no portions are required to respond to a oolledion of Information unless it displays a valid OMB control number. g
`0
`PROVISIONAL APPLICATION FOR PATENT COVER SHEET - Page 1 of 2
`3!,
`This Is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 CFR 1.5303).
`—
`Expreae Mall Label No.§ymy§___w_____
`
`
`
`60/784680MOIBEEW'
`
`
`
`
`
`
`
`
`
`
`Given Name (first and middle [If anyD
`
`Family Name or Surname
`
`and either State or Foreirt Count 1
`
`..
`
`You rig-Dee
`
`Myung-Cheul
`
`Sung-Jun
`
`Additional inventors are being named on the __2no__.._._._.seperateiy numbered sheets attached hereto
`TITLE OF THE INVENflON (500 characters max):
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Direct all correspondence to: CORRESPONDENCE ADDRESS
`The address corresponding to Customer Number:
`'
`035854
`
`
`
`OR
`
`mam” Name Lee. Hons. Degerrnan. Kong iii Sehmadeita
`
`
`Address 301 South Figueroa Street, 14th Floor”
`
`
`
`.
`.
`:a
`
`
`cur
`
`Loo Mates
`
`_
`
`
`
`-
`
`T°'°"“°"°213-623-2221
`
`
`
`
`
`
`
`
`
`[3 Application Data Sheet. See 31 CFR 1.76
`III Spedilcetlon Numberof Pages 17
`D Drawingts) Numberoi'sneets
`It the specification and drawings exceed 100 sheets of paper. an application size tee is
`Fees Due: Filing Fee of $200 {$100 tor email entity).
`also due. which is $25.0 ($125 for email entity) for each additional 50 sheets or traction thereof. See 35 U.S.C. 41(a)(1)(6) and 37 CFR 1.1B(s).
`
`D cots). NumberoiCDs
`
`D monstrosity)
`
`METHOD OF PAYMENT OF THE FILING FEE AND APPLICATION SIZE FEE FOR THIS PROVISIONAL APPLIGA‘HON FOR PATENT
`
`
`
`
`
`
`- Applicant claims small entity status. See 3? CFR 1.27.
`
`
`
`'
`'
`n A check or money order is enclosed in cover the thing fee and application size fee (it applicable).
`TOTAL see AMOUNT is:
`'3 Payment by credit card. Form PTO-2038 is situated
`
`
`El The Director Is hereby authorhed to charge tire tiling tee and application size too (it applicabie) or credit any overpayment to Deposit
`
`
`
`Account Number: m—. A duplcettve copy at this form is endosed for tea processing.
`USE ONLY FOR FILING A PROVISIONAL APPLICATION FOR PATENT
`This collection or information is required by 31 OFR1.51. The information is Wredteobtsin or retain a benefit by the public VII'IIG'I ie'to file (and by the USPTO
`to process) an application. Confidentiality is governed by as U.s.c. 122 and 37 CFR 1.11 and 1.14. This ooiiedion le eatirrrated to take a hours to complete.
`including glittering. preparing. and atibnrttting the completed application term to the USPTO. Time will vary depending upon the Individual case. Any comments
`on the eniourit at time you require to complete this term andior auggeetions for redudng this burden. should be sent to the ('ihietI Information Officer. U3. Patent
`and Trademark Otnce. us. Department orOor-nrneree. P.O. Bear 1450. Alexandria. VA 22313-1450. DO NOT SEND FEES OR COMPLETED FORMS TO THIS
`ADDRESS. SEND TO: Commissioner for Patents. P.o. Box 1450, Alexandria. VA 22313-1450.
`'
`ityou need assistance in compiet'ng the teen. cert r-eoa-PTo-etae and select option 2.
`
`Copy provided by USPTO from the IFW thabeee on 01i1312007
`
`04915
`
`

`

`PROVISIONAL APPLICATION COVER SHEET
`Page 2 of 2
`
`worsens (10-05)
`tor use through 07mm. OMB 0651-0032
`0.5. Patent and Trademark Office: us. DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1905. no parser“ are required to respond to a collection of inton'natton unless it displays a valid OMB control number.
`
`The invention was made by an agency of the United States Government or under a contract with an agency of the United States Government.
`No.
`.
`
`D Yes. the name of the U.8. Gwemment agency and the Govemment contract number are:
`
`WARNING:
`,
`Petitionerlapplicant is cautioned to avoid submitting personal Information in documents tiled 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 information is included in documents submitted to
`the USPTO, petitionerslapplicants should consider red-sting such personal Information from the documents before submitting
`titem t0 the USPTO. Petitioneriappiieant 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(a) 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
`
`4
`
`TYPED or PRINTED NAME Lew Edward V. Maflgal
`
`REGISTRATION "0.55 “a
`(if appropriate}
`
`
`TELEPHONE 213-623-2221
`'
`
`Docket Number: 2191-91 as
`
`
`
`_ Copy provided must-tic lrom the IFW Wilts-taboos on omerzoo'r
`
`04916
`
`

`

`PROVISIONAL APPLICATION COVER SHEET
`Additional Page
`
`PTorsano (12-04)
`for use through ommooa. OMB 0651-0032
`us. Patent mu Trademark Office: us. DEPARTMENT OF COMMEROE
`Under the Paperwork Reduulon Act a! 1995. no person are reamed to respond to e oulledlon ol' lnfonnelion unless it deploys a wild OMB control number.
`
`
`lNVENTOR‘SNAPPLIOANTlS)
`m— “°"“°"°'
`Given Name first and middle ten
`Famll or Surname
`c and either State or Foroi 5 n Coo
`
`
`
`
`
`
`
`
`
`Number
`
`1
`
`of__J_._
`
`WARNING: Infomalion on lhle form may become public. Credit card Information should not be
`included on this form. Provide cradli card Information and authorization on PTO-2038.
`
`
`
`Copy provided by HSPTOIrom Ihe IFW Wbeiehaee on' amazon
`
`04917
`
`

`

`PROVISIONAL APPLICATION FOR
`
`UNITED STATES PATENT
`
`IN THE NAMES OF
`
`Young-Dee LEE, Myung-Cheul JUNG,
`Sung-Duck CHUN. Sung-Jun PARK,
`Patrick FISCHER and Dragan Vuicic
`
`for
`
`OVERALL ASPECTS FOR L'I'E SYSTEM
`
`prepared by:
`
`Lee. Hong. Degerman. Kang 8: Schmadeka RC.
`801 s. Figueroa Street, 14‘“ Floor
`Los Angeles. CA 90017
`Tel: (21 3) 623-2221
`Fax: (213) 623—221 1
`
`Customer Number 035884
`
`- Attorney Docket No.: 2101-9196
`
`Express Mail No.: EV 656512188 US
`
`Total Number of Pages: 17 (including cover)
`
`BEST AVAILABLE (tn-'3"
`
`Copy provided by USP'I'O from the IFW IUIWatabm on 0111812007
`
`04918
`
`

`

`R2-05xxxk
`
`
`
`Agenda Item : 11
`
`Source
`
`: LG Electronics
`
`: Considerations on LTE mutticast & broadcast
`Title -
`Document for : Discussion and Decision
`
` 1
`
`Introduction
`
`This document proposes some considerations on LTE multicastlbroadcast.
`
`
`'2 Bandwidth scenarios and UE'capabi'lity for
`multicastlbroadcast
`
`At this moment, whether multicastfbroadcast is mandatory or optional is not clear in the UE side. Decision on this
`would impact on specification of LTE multicastfbroadcast.
`
`[f multicasu'broadcast is mandatory in the UE side, minimum UE capability for multicastlbroaclcast is 10 Mhz
`because it was decided to be 10 Mhz last month. In this case, if cell bandwidth is larger than to Mhz, UE may need to
`select which service it should receive when multicastlbroadoast and unth services are simultaneously transmitted.
`In. some cases, UE may lose the multicastlbroadcast in case the multicastlbroadcast service has a lower priority than
`the unicast service.
`
`if we wish to avoid this situation, every LTE UE needs to support a larger than 10 Mhz with multicast/broadcast (10
`Mb: + multicastfbroadcast service bandwidth). Furthermore, if there is a dedicated carrier for multicastfbroadcast
`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 multicastlbroadcast services. If it is difficult to mandate
`larger minimum UE bandwidth than lOMhz or dual receiver to LTE UE, then multicastfbroadcast may need to be
`optional in the UE side.
`
`Based on the discussion above, we think that
`fmulticastfbroadcast transmission:
`
`the following points should be decided before design of
`
`Q1) Should UE support multitastlhroadeast in a mandatory or optional manner?
`02) What is minimum UE bandwidth with multicastlbroadcast?
`
`03) Should UE supporting muttioastlbroadeast feature support dual receiver in a mandatory or optional
`manner?
`‘
`-
`
`
`3 Multicast/broadcaSt service, scenarios
`
`The current discussion on MBMS requirements [I] show there are two types of service scenarios: cell specific
`contents and cell group contents. The cell specific contents. could be R99 CBS-like service Le. 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 multicastfbroadcast services is somewhat different from a BL shared channel which is used
`for most of cases. And multi-‘cell trenSmission of a multicastlbroadcast service would cover multiple eNode 35.
`Therefore, a central node is needed as a source of multi-cell transmission. (NOTE: In this case. one PDCP entity
`exists for one service in aGW.)
`-
`
`JGPP
`
`
`
`'
`
`cppy provldedbijSETO from the new :mfgoatsbsssoq mama
`
`
`
`04919
`
`

`

`0n 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 BL shared
`channel could support the single cell transmission. instead of introducing another single cell transmission channel.
`And single cell transmission covers only one-cell or one e‘Node B. In this case, locating single cell transmission at the
`center node is questionable. However, one common architecture may be preferable for both single and multi-eell
`transmissions. (NOTE: In this case, one PDCP entity exits per cell/eche B or per a group of cells for one service in
`aGW. FPS)
`.
`
`Furthermore, if a text message distribution like R99 CBS is supported. it is questionable whether a L2 entity like at
`BMC entity is needed or not. R99 BMC did storing, formatting, scheduling, transmitting and repeating CBS
`messages. 0n 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 e.g.
`for safe distribution of text or multimedia messages, ARQ layer at E-Node B could do repetition of
`broodcastlmulticast packets like R99 BMC.)
`
`Q1) Should LTE support both muItI-ceil and single cell transmission?
`
`02) 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 MBMS and LTE MBMS is feasible:
`
`I)
`
`2)
`
`In the case a UE supporting both WCDMA MBMS and LTE MBMS moves from a WCDMA MBMS area to a
`LTE MBMS area or moves from LTE MBMS to WCDMA MBMS while receiving the same MBMS service
`
`In the case a UE camping on a WCDMA cell receives MBMS from a LTE cell e.g. on a dedicated carrier to LTE
`MBMS.
`
`3)
`
`In the case a UE camping on a LTE cell receives MBMS from a WCDMA cell e.g. on a preferred layer.
`
`We need to discuss if one or more of the scenarios above need to be supported or not. The first point above may shew
`a possibility to share the same BM-SC node between LTE MBMS and WCDMA MBMS for one MBMS service.
`
`
`5 Conclusion
`
`We propose in this document
`multicastfbroadcast.
`
`that some points should be discussed before detailed discussion on LTE
`
`
`
`References
`
`[I] RP-OGOZ 15, “Introduction of specfic requirements for support of Broadcast mode in MBMS in LTE", Orange
`
`so»
`
`
`
`' stabs» on omslzoor
`Copy-provided by'usn'ronpminotrm
`
`
`.
`
`
`
`p =<
`
`04920
`
`

`

`R2-06xxxx
`
`Agenda Item
`
`: joint meeting 3.2
`
`Source
`
`: LG Electronics
`
`Title
`Document for : Discussion and Decision
`
`
`: Scenarios of synchronized Random Access
`
`Introduction
`
`After Denver meeting. the discussion on RACH has discussed via e-mail reflector. Then some possible
`points are clarifiedand captured into -}'P on RACH. However. some points to be clarified still exist. One of
`them is when a UE uses synchronized RACH. So. the purpose of this document is to clarify that point and
`discuss the scenarios on it.
`
`
`
`Discussion
`
`According to the TP on RACH. the synchronized random access is used when a UE upiink is time
`synchronized by the node B. And the purpose is for the UE to request resource for upiink data transmission.
`
`in our understanding. since uplink data to be transmitted arrive to buffer of a U5. the UE would use
`synchronized random access when itdoes 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. when a DB has uplink data
`
`In this case. the UE is transmitting the uplink data to network. Therefore. since RR
`(Resource Request) can be sent over in-band signaling. synchronized RACH prosedure is
`not needed.
`
`Case 2. when a UE does nothave 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. ACKINACK. Regarding
`allocation for this resource. there would be three possible methods.
`
`One is to continuously assign resource for it. However. the cost of this scheme seems to
`be large since there is a need to reserve resource regardless existence of downllnk data.
`But if a UE uses this resource by means of 1 bit indicator or RR. synchronized RACH
`procedure is not needed.
`
`ll.
`
`Second one is 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
`RACH procedure should be needed.
`
`Last one is to periodically assign resource according to a sort of downlink traffic. It a sort
`of downlink trellis is periodical :e.g. MPEG and VoIP. a UE can predict when the next
`downllnk traitlc will arrive. In other words. the UE can torecast next SR. Therefore.
`synchronized RACH procedure might be needed according to interval of trailic.
`
`JGPP
`
`Copy provided by USPTQIIoIn lite lFWIfiImDatsbsse on “1’12””
`
`04921
`
`

`

`Case 3. when a UE does not have uplink data and the UE is not receiving downlink data from
`network. but the UE has not moved to DRX cycle yet.
`
`Although this case looks like DRX due to no uplink and downlink traffic, 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 UE. the UE frequently sends
`uptick reference signal to get UL synchronization while a stationary UE rarely sends uplink
`reference signal because the situation of the channel remains unchanged. Thus the UE 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
`
`
`
`DRX
`
`synchronized
`RACH
`
`Not needed
`
`
`
`
`is the UE having
`DL transmission ?
`is the UE receiving
`
`uplink data to be
`
`transmitted?
`
`
`
`Continuousassignment
`INotneeded
`
`
`
`
`should be needed
`
`Event —triggered assignment
`
`might be needed
`
`Periodical assignment and
`according to interval of traffic
`
`According to UE mobility
`_ might be needed
`According to length of DRX cycle
`_- might be needed
`
`
`Conclusion
`
`We propose to discuss the scenarios in this paper and to capture the agreeable parts in the TR.
`
`SGPP
`
`Copy provided by U5PTO from the IFW lWatabaee on 0111012007
`
`04922
`
`

`

`R2-060xxx
`
`Agenda item:
`
`x.x
`
`Source:
`
`LG Electronics Inc.
`
`Title:
`
`UE state transition in LTE_ACTIVE
`
`Document for:
`
`Discussion, Decision
`
`
`
`1 .
`
`Introduction
`
`At last joint meeting with 8A2 and RANS in Denver, it was agreed that power saving performance of UE in
`LTE_ACTIVE should be comparable to that of UE in LTE_‘ldle. In this document. we look into UE in LTE_ACTIVE.
`
`
`
`2.
`
`Discussion
`
`2.1 Synchronization in LTE_ACTIVE UEs
`
`in-OFDM system, it is important that transmissions li’om all was should be synchronized at cNB. 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 UE mobility or channel condition, the synchronization status should be
`monitored continuously and UE. transmission timing has to be adjusted according to the measurement.
`
`But this does not come without cost. To measure the transmission synchronization status in uplink direction, UE have to
`transmit among uplink data. pilot, CQl. or ACKINACK. etc. Thus, to keep UE. in synchronized state. the eNB should
`schedule uplink transmission even when there 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 UE.
`
`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 not to maintain synchronization in uplink.
`
`2.2 Transition from Non-sync to Sync of LTE_ACTIVE UE
`
`if we 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 seen. First event is when a UE has upllnk 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 notifiy upcoming traffic to the UE. If DRX‘ mechanism for LTE_ACTIVE is used for LTE_ACTIVE
`UE. to save power consumption, the eNB will indicate the pending downlink traffic at the wake-up timing of the UE. As
`a simple solution, UE temporary ID assigned by eNB will be indicated by LllLZ control information.
`
`Next procedure is to synchronize UE uplink transmission. Without synchronized uplink. paging ofincoming data will be
`useless. it’s because low error ratio of data transmission will be ensured by using HARQ and HARQ requires feedback
`fiom receiving side. Additionally, receiving side needs to report CQI information to assist transmittcr’s selection of
`
`
`
`, Copy provided byKUSP‘fTD iron) the Inn! [Wombats on 011mm“)?
`
`-
`
`.
`
`04923
`
`

`

`resource block. To guarantee reliable reception ofthese pieces of information at eNB, it is required to synchronize
`uplink before actual downlink traffic transmission.
`
`But to let UB to synchronize uplink by using RACI-l will not be optimal. Because RACH is contention based channel, it
`isnot flee 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, e'NB 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. lfeNB allocates radio resource for CQI also, then it will
`be useful to eNB’s scheduling.
`
`Conclusion:
`
`Dedicated ratilo resource ls 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 upiink of non-synchronized LTE_ACTIVE UE.
`
`
`
`4.
`
`Reference
`
`[1] R2-060xxx, LTE, LG Electronics
`
`Copy moulded by USPTerom the II?” ImDeteluse on o1fl8t2t107
`
`04924
`
`

`

`R2-05xxxx
`
`Agenda Item : 3.1
`
`Source
`
`: LG Electronics
`
`Title
`
`: Dlsucssion on LTE Paging and DRX
`
`Document for : 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 power saving.
`
`
`
`Differences between Paging and 'DRX
`
`live-consider that the paging procedure is used by aGW to find at which cell in a tracking area a UE is 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-RNTI) allocated by a cell, a paging message will carry a longer UE id e.g. lMSl and TMSI.
`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
`procedure is applied only to a UE in active mode. if DLIUL traffic 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-RNTl)
`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 foilewa:
`
`
`— P in- Procedure
`idle mode
`aOW: paging initiation
`
`eNode B:
`..; "a transmission
`
`
`
`
`
`
`.
`Controlling network node
`Sinailed Area
`.
`.
`.
`5'93““ ”E “my
`
`
`DRX Proced’t'lre
`
`
`A short identity (e.g. C-RNTI)
`
`
`allocated b AS in eNode a
`
`eNode B
`
`A long identity ('e.g. IMSi, TMSI)
`allocated b NAS
`
`What long 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 tong 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 procedures are different. We think the differences between them
`should be considered when we design the LTE air interface.
`
`At this moment, the PCH channel is defined in TR 25.813 for transmitting a paging message. However, it is not so clear
`whether or not PCH is also used for DRX of an active UE.
`
`JGPP
`
`Copy provided by USPTOI'rorn the IFW IWSDatabm on_01l1dl2007
`
`04925
`
`

`

`In case of the DRX procedure. a short UE identity which may be equal to or less than l6 bits could be easily embedded
`into Lll2 control information at the first symbol of a sub-frame. it is because L112 control information e.g. for DLIUL
`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 L112 control information.
`
`On the other hand, a long UE identity which may be 32 bits may not be compatible with L112 control information. it is
`because L112 control information e.g. for DUUL SCH would not use the long UE identity. Thus, a paging message with
`the long UE identity could not be embedded into 1.1/2 control information. However. if PlCH is necessary. PlCH could
`be embedded into L112 control information because PlCH would carry a short size of quick indications.
`
`Therefore, the following points could be concluded.
`
`1) Only a UE in idle mode shall monitor a PCH channel based on a long UE identity for U8 power saving.
`
`2) A UE in active mode may monitor L112 control information with a short UE identity in a cycle set by eNode B
`for U8 power saving.
`
`3)
`
`4)
`
`If an active UE with DRX is scheduled, eNode B will insert the short identity of the UE into LUZ control
`information including scheduling information according to the set cycle.
`
`If an active UE with DRX is not scheduled, . eNode B will not insert the short identity of the UE into LUZ
`control information according to the set cycle.
`
`
`
`Paging Indicator Channel
`
`PlCH may have a benefit for UE battery saving because UE is quickly able to check its own paging by simply decoding
`Paging Indications on PlCH. Decoding a paging indication will be quicker than decoding a paging message. Thus. the
`PlCH channel may be need in LTE for efficient UE power saving. Furthermore, PlCH could do frequency hopping for
`frequency diversity. The hopping information could be given from system information. Alternatively, LUZ control
`information could be used instead of PlCH.
`
`I’m not sure whether there is really a gain from the receiver Aoperation, and the message decoding should not be too
`long. so i 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:
`
`0
`
`0
`
`o
`
`Two UE power saving schemes are used based on RRC mode i.e. the paging procedure for idle moe and DRX
`procedure for active mode.
`
`The paging procedure for idle mode relies on the PCH channel. possibly with short indications such as PlCH
`or 1.10 control information.
`
`The DRX procedure for active mode relies on Ll/2 control information which is used for DUUL SCH.
`
`as»
`
`
`
`Copy provided by USBTO from the lFWlWatebaee on 0111312007
`
`
`04926
`
`

`

`R2-060890
`
`Source:
`
`LG Electronics
`
`Title:
`"Agenda Item:
`
`LTE Random Access Use Cases
`Joint03.2 - Random Access
`
`Discussion 8. Decision
`Document for:
`
`
`1. Introduction
`
`RACH has been discussed in RAN2 in RANZ #53, and a LS has been sent to RANI 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 secess to obtain Ll
`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 U5 mobility.
`Theses use cases can be classified into 3 different states:
`
`0
`
`o
`
`Idle mode UE I Detached modeUE/ UE Mobility
`
`Synchronized active UE without resources
`
`0 Non- Synchronized active UE without resources (under FFS in RANZ)
`I The different possible procedures for each state are discussed in following.
`
`3.
`
`idle mode UE I Detached UE l 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 ”B“! 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 as which is sufficiently smaller than the typical CP duration (approximately 5 us). For BW
`less titan 1.25MHz, for instance BW of 375 KHz the 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,
`although the this can be advantageous in order to take advantage of the fi'equency selectivity of the channel.
`“seconds-don
`
`
`2009 me me 2750 , case
`2m 2000
`2‘50
`3000
`
`Figure 1: Comparison between localized random and equidistant distribution
`
`' if atabase on comma-r
`7_ copy provided by USPTD'hom the le_'i .
`_
`
`
`04927
`
`

`

`According to 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 channel at 3 kmfh. However it is important to agree on the
`assumptions for the simulations.
`
`Proposal:
`in order to decide on the above points it is necessary to make assumptions on:
`o
`The required precision for the timing
`0
`The maximum achievable SNR in the UL at the NodeB, i.e. the necessary assumptions on the link
`budget
`Based on these assumptions it should be possible to estimate the number of symbols necessary for the
`transmission of the preamble for the different bandwidths, and different speed and channels alter further
`simulations in the Mai or June meeting.
`
`Different possible procedures
`Three random access procedures are possible as illustrated in Figure 2 below:
`
`UE
`
`Network
`
`Preamble -r (rand id FFS + Estcause + RR)
`
`UL- DltaAilocato resources + C-RNTI FFS -r TA t-
`
`W1
`
`Optionz
`
`Preamble
`
`SR resource allocation -r c-RNTI FFS + TA t- Poster
`Art stment
`
`RRC message on LIL-SCH
`
`RR + C-RNTi + EsLCsuse + - it of RRC moses-s
`
`UL-SCH Resource Allocation if it is needed
`
`Figure 2: Options for the unsynchronized RACl-l procedure
`
`in option l 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 of contention, are combined together. Afier 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-L3 messages, MAC data or control 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 and to treat priorities corre